前回までのおさらい
本記事は、WebRTCをテーマにした連載の第3回（最終回）です。
これまでの記事では、通信確立の仕組みや帯域制御・Quality設定について取り上げてきました。
- WebRTCの基礎を理解する～ブラウザ同士がつながる仕組み～
- WebRTCの帯域制御とQuality設定 ～サンプルコードを用いて紹介～
- WebRTCのパフォーマンス品質の測定と監視について （本記事）
最終回となる今回は、WebRTCの通信品質をどのように測定・監視し、問題発生時にどう切り分けるかという、運用フェーズで非常に重要なテーマを扱います。
WebRTCのパフォーマンス・通信品質をモニタリングする方法
WebRTCの通信品質をモニタリングする方法は、大きく分けて以下の2つがあります。
- getStats() APIを利用した通信統計の取得
- Chrome のwebrtc-internalsを利用したリアルタイム監視
getStats() を使ったモニタリング
getStats() は WebRTC が提供する公式APIで、ビットレート、フレームレート、 パケットロス、RTT などの通信統計を取得できます。
この統計情報をログとして保存しておくことで、運用中に発生した品質劣化や、利用者からの申告だけでは判断が難しい問題の原因を統計的に分析できます。
webrtc-internals を使ったモニタリング
Chrome にはwebrtc-internalsという、WebRTC専用のデバッグ機能が用意されています。
Chrome の webrtc-internals 画面。
WebRTC通信に関する詳細な統計情報がリアルタイムで表示される。
webrtc-internals は、通信品質をグラフとして視覚的に確認できるため、試験・検証フェーズでの品質確認に非常に適しています。
以上のように、WebRTCの通信品質をモニタ-リングする2つの方法はそれぞれに特長があります。
プロジェクトのフェーズや目的に応じて、以下のように使い分けるのが効果的です。
- 統計的分析：getStats() APIを利用し、ログから統計的に分析する
- リアルタイム分析：webrtc-internalsを使い、リアルタイムで問題を切り分ける
運用環境でモニタリングする上で重要な観点
WebRTCの通信品質を見る際、すべての統計情報を網羅的に追いかける事は大変です。
画面共有を伴うWebRTCアプリケーションでは、以下の観点が重要になるので特に着目して見ていきます。
フレームレートが極端に低下していないか
- 映像がカクカクする
- 静止画のように完全に止まってしまう
- 操作に対する画面反映が遅い
解像度が極端に低下していないか
- 文字が潰れて読めない
- UIが判別できない
継続利用でCPU負荷が上がりすぎていないか
- 長時間利用で動作が重くなる
- 端末のファンが回り続ける
- 他アプリの動作に影響が出る
getStats() で確認すべき主な項目
| 観点 | Stats項目 | 内容 | 目安（許容範囲） |
|---|---|---|---|
| フレームレート | framesPerSecond | 送出されているfps | 10fps以上（画面共有） |
| 解像度 | frameWidth / frameHeight | 送信映像の解像度 | 文字が判読できる解像度 |
| 帯域 | bytesSent / bitrate | 送信ビットレート | 想定した maxBitrate 付近 |
| パケットロス | packetsLost | パケット損失数 | 1～2%以下が良好 |
| RTT | roundTripTime | 往復遅延時間 | 300ms以下 |
| CPU負荷 | totalEncodeTime | エンコード処理時間 | 継続的な増加がないこと |
webrtc-internals を使った実践的な確認
webrtc-internals の起動方法
Chrome のアドレスバーに「chrome://webrtc-internals」と入力すると起動できる。
通信品質が正常な状態
通信が安定している状態。
bitrate・fps・解像度が一定で推移している。
※ 多台数接続を加味して低レートで動画送信をしています
※ 画像は送信bitrateのスクリーンショット
clumsy でネットワーク制限をかけた状態
clumsyは、Windows環境でネットワーク状態を意図的に悪化させることができるツールです。
これを用いることで、帯域制限やパケットロス、遅延などを擬似的に発生させ、不安定なネットワーク環境下でのWebRTCの挙動を手軽にテストできます。
ラグやパケットロスを付与すると、bitrate や fps が低下し、解像度が自動的に下げられている様子が確認できる。
※ totalRoundTripTimeが跳ね上がった時刻からbyteSentの低下がみられます
※ 画像は送信bitrateのスクリーンショット
このように、ネットワーク劣化に応じて WebRTC が自動的に品質制御を行う挙動を、webrtc-internals では視覚的に確認できます。
まとめ
WebRTCの通信品質は、問題が発生してから対応するのではなく、事前に測定・監視する手段を用意しておくことが重要です。
- 運用時の原因調査には getStats によるログ収集
- 試験時の品質確認には webrtc-internals
- フレームレート・解像度・CPU負荷を重点的に監視
- 運用試験前に擬似的なネットワーク劣化でも挙動を確認しておく
本連載が、WebRTCを実務で扱う際の参考になれば幸いです。
