ブラウザアプリの継続的パフォーマンスモニタリング (序) / Continuous Browser Application Performance Monitoring; Act 1

ToKyoto.js #03 の資料です

Transcript

1. © Timeleap Inc. CONFIDENTIAL ブラウザアプリの 継続的パフォーマンス モニタリング (序) Thu, 3 Sep 2026 ToKyoto.js #03 https://timeleap.co.jp/ @moznion 1
2. @moznion タイムリープ株式会社 ソフトウェアエンジニア プロダクト責任者 — はてなインターン2013参加者 ということで今⽇は京都陣営
3. 背景共有 WebRTCを使って遠隔接客を提供しているブラウザアプリを開発‧運⽤ © Timeleap Inc. 3
4. パフォーマンスモニタリング Google Meetとかにあるコレが欲しい © Timeleap Inc. 4
5. パフォーマンスモニタリング モチベーションは様々 「重い」「⾳が途切れる」「映像が固まった」などといったお客様の報告内容と 正確な事象発⽣時刻を対応させたい サーバーサイドやWebRTCコンポーネントのエラーとの突合をしたい 諸要因によるCPU逼迫、アプリのヒープ肥⼤、ネットワーク環境の劣化などを検出したい などなど…… © Timeleap Inc. 5
6. というわけで作って提供した © Timeleap Inc. 6
7. 計測できる項⽬ • CPU負荷 (利⽤状況) • メモリ使⽤量 (JavaScriptヒープ) • ネットワーク利⽤状況 (WebRTC) ◦ 送受信帯域 ◦ RTT ◦ Jitter ◦ パケットロスレート © Timeleap Inc. 7
8. CPU負荷 • Compute Pressure API ◦ nominal, fair, serious, criticalの4値でCPU利⽤状況が取れる† ◦ (主として) プライバシー保護の観点から精緻な利⽤率は取れない†† ◦ 今回はこれを採⽤ • chrome.system.cpu API ◦ Chrome拡張のAPIを使ってCPU利⽤率を取得する ◦ Compute Pressure APIとは違い、精緻な利⽤率が取れる ◦ Google Meetの機能はこれを使って実現されている ▪ Chromeがデフォルトで権限を付与しているからできる †† †: 良いデモ => https://w3c.github.io/compute-pressure/demo/ ††: 例えばFingerprinting等 †††: https://x.com/lcasdev/status/1810696257137959018 © Timeleap Inc. 8
9. メモリ使⽤量 • performance.memory ◦ ウェブページのメモリフットプリントを測定 ▪ JavaScriptのヒープサイズを返却する ◦ ⾮標準かつ⾮推奨: Chromeなど特定のブラウザのみ対応 とにかく使っちゃ駄⽬そうなムードがすごい ◦ が、今回は採⽤ © Timeleap Inc. 9
10. メモリ使⽤量 • performance.measureUserAgentSpecificMemory() ◦ performance.memoryの後継 ◦ JSヒープだけではなくページ全体のメモリを測定できる ◦ HTTPSの利⽤とcross-origin isolation (COOP + COEP) が必要 まだ若そうな機能 ◦ 実際にはこれを使った⽅が良かったと思う…… © Timeleap Inc. 10
11. WebRTCのネットワーク利⽤状況 • RTCInboundRtpStreamStats ◦ WebRTCのありとあらゆるStatsが取得できる ▪ 多すぎるので説明略 (ドキュメントを参照ください) ▪ これを取得して貯めておくと何かと便利 ◦ これを取得するには RTCPeerConnection.getStats() や RTCRtpReceiver.getStats() を呼ぶのだが…… ▪ ハングするケースがある ▪ Promise.raceなどを使ってタイムアウトを設けるのが安全 • getStats()⾃体はキャンセルされないのでin-flight 対応は別途必要 (さもなくばスタックする) © Timeleap Inc. 11
12. アーキテクチャ Infra 取得 CPU Pressure State Collector Scheduler ClientMetricsSampleをファンアウト performance memory usedJSHeapSize WebRTCStats 毎秒 Trigger Sink † Hydration Ring Buffer Chart UIへ †: WebRTCStatsは各コネクション毎にサンプル間の差分を返却 append-only IndexedDB JSON Dumpへ © Timeleap Inc. 12
13. アーキテクチャ上の特徴 • ⾊々と増やしやすい ◦ 取得したいメトリクスが増えたらinfraを増やせば良い ◦ 出⼒先が増えたらSinkを増やせば良い • IndexedDBに永続化†することによりハイドレーションができる ◦ リロード等をしたとしてもデータが残っているのでチャートに レンダリングができる†† ◦ 過去データのダンプ機能を提供できる †: 永続化といっても未来永劫残すわけではなく、⼀定期間に限定 ††: getAll + sliceすると⻑期保存時にエラいことになるので降順カーソルで maxSamples 件だけ辿る © Timeleap Inc. 13
14. Tips⾊々 • CPU PressureのPressureObserverはsampleIntervalごとに コンストラクタで渡したcallback経由でpressure stateを渡す ◦ callbackとcollectorは不必要なレンダリングを防ぐ⽬的で分離 ▪ callbackは値を (Reactなのでrefに) stashしておくだけ ▪ collectorはそのrefをgetしてくる 👉 PressureObserverのsampleIntervalと、collectorに対する Schedulerのtrigger intervalは噛み合っている必要がある © Timeleap Inc. 14
15. Tips⾊々 • IndexedDBはオリジン単位でTab間共有がされる ◦ 共有端末でのオペレーションが前提とされているとコンタミする ◦ IndexedDBのキーにセッションIDを含めるようにし、 それと共にオペレーションをすることでコンタミを防ぐ† †: と書いてて気付いたが、セッションIDよりユーザーIDのほうが良いのでは？ (セッションが変わってしまうと過去ぶんがダンプできなくなってしまう) © Timeleap Inc. 15
16. まとめ • ブラウザのAPIは充実していて案外サクッと作れる ◦ メモリ周りだけが決定版にはなっていない印象 • とはいえ素朴に作ると結構問題があった ◦ 雑にやると計測のたびにReactがレンダリングされて死ぬ ◦ WebRTCのgetStats()は油断するとハングする ▪ ハングするとモニタリング全体を巻き込んで⽌まる • IndexedDBがとにかく便利 ◦ 共⽤されうる端末の時には注意が必要 © Timeleap Inc. 16
17. 破に向けて • 現状すべてのメトリクス機構がローカルで完結している • メトリクスはリモートに送出して中央管理したい† ◦ 承前: Sinkを実装すれば良い ◦ あるいはIndexedDBのScheduled Exporterを作れば良い • どちらかというとメトリクスを受けて保管する側に課題がある ◦ Monitoring SaaSに素朴に突っ込むと⾼いし…… ◦ Prometheus的概念を⾃前で運⽤するのは…… †† ◦ DWHに⼊れるという選択も無いわけではない • 破でお会いしましょう †: 利⽤規約等のレベルでの解決‧同意が為されているという前提 ††: 嫌いではないが…… © Timeleap Inc. 17
18. © Timeleap inc. All Rights Reserved.