SkyWayが遭遇したWebRTC の可観測性に関する問題と開発者向け可視化サービス提供までの道のり

© NTT Communications Corporation All Rights Reserved. 1 2024年8⽉4⽇ NTTコミュニケーションズ株式会社
SKYWAY推進室 SkyWayが遭遇したWebRTC の可観測性に関する問題と開発者向け可視化サービス提供までの道のり

© NTT Communications Corporation All Rights Reserved. 2 SkyWayにDevOpsエンジニアとして参画 WebRTC
R&Dチームの⽴ち上げ WebRTC R&Dチームのリーダー次世代のWebRTCに関する技術調査 SkyWay推進室 WebRTC Researcher 内⽥裕貴(X: @yuki_wtz) 2019.04 2020.09 2022.11 2024.01

© NTT Communications Corporation All Rights Reserved. 5 SRE領域に興味のある⽅々に MonitoringからObservabilityへ踏み込み
本セッションのゴール

Observabilityをユーザーに提供することになった例として本セッションのゴール

Observabilityをユーザーに提供することになった例として課題・想い・解決までの道のりを本セッションのゴール

Observabilityをユーザーに提供することになった例として課題・想い・解決までの道のりを参考にして頂く本セッションのゴール

© NTT Communications Corporation All Rights Reserved. 9 WebRTCとSkyWayとは WebRTCで発⽣する不具合
WebRTC Platformとして求められる責任 MonitoringからObservabilityへ SkyWay Analytics β まとめ⽬次

Web Realtime Communicationの略

Web Realtime Communicationの略 ZoomやMicrosoft Teamsのようなビデオ通話サービスを実現するためのプロトコルの集合体

Web Realtime Communicationの略 ZoomやMicrosoft Teamsのようなビデオ通話サービスを実現するためのプロトコルの集合体 2011年に仕様草案がW3Cに提出され、2021年に勧告化(標準化)

WebRTC機能をユーザーが仕様追従・サーバ運⽤などのコストを負担することなく、ビデオ通話を簡単に実現するためのマネージドサービス

WebRTC機能をユーザーが仕様追従・サーバ運⽤などのコストを負担することなく、ビデオ通話を簡単に実現するためのマネージドサービス 2013年から10年以上提供

© NTT Communications Corporation All Rights Reserved. 18 WebRTCで発⽣する不具合
INTRODUCTION

• 通話が始まらない • 映像や⾳声が⾒えない・聞こえない • 映像や⾳声が途切れる

• 通話が始まらない • 映像や⾳声が⾒えない・聞こえない • 映像や⾳声が途切れるこれらはなぜ起こってしまうのか？

© NTT Communications Corporation All Rights Reserved. 23 WebRTCで発⽣する不具合はなぜ起こってしまうのか？ 1.
インターネットという不安定な物を酷使してリアルタイム通信を実現 2. 複雑かつ多機能

インターネットはベストエフォート(専⽤線のように常に同じ品質ではない)

インターネットはベストエフォート(専⽤線のように常に同じ品質ではない) 快適に通話をするためには⾼品質なNW環境が必要

インターネットはベストエフォート(専⽤線のように常に同じ品質ではない) 快適に通話をするためには⾼品質なNW環境が必要 • 遅延が⼩さい(250ms未満が望ましい) • パケットロスが発⽣しない(10%未満が望ましい) • 帯域幅が⼗分⼤きい(1Mbps以上が望ましい)

インターネットはベストエフォート(専⽤線のように常に同じ品質ではない) 快適に通話をするためには⾼品質なNW環境が必要 • 遅延が⼩さい(250ms未満が望ましい) • パケットロスが発⽣しない(10%未満が望ましい) • 帯域幅が⼗分⼤きい(1Mbps以上が望ましい) 上記は以下の要素によって左右される • 相⼿との物理的な距離 • デバイス性能 • NW機器・ISPの混雑・障害 • Wi-Fi利⽤やCellular回線の利⽤

• FEC(Forward Error Correction) • ロスしたパケットの復元

• FEC(Forward Error Correction) • ロスしたパケットの復元 • GCC(Google Congestion Control) • 帯域幅推定と映像エンコード時のQP値やフレームレートの制御

• FEC(Forward Error Correction) • ロスしたパケットの復元 • GCC(Google Congestion Control) • 帯域幅推定と映像エンコード時のQP値やフレームレートの制御 • DTX(Discontinuous Transmission) • 送信量削減(無⾳パケット除去)

• FEC(Forward Error Correction) • ロスしたパケットの復元 • GCC(Google Congestion Control) • 帯域幅推定と映像エンコード時のQP値やフレームレートの制御 • DTX(Discontinuous Transmission) • 送信量削減(無⾳パケット除去) • HWA(HardWare Acceleration) • デバイス負荷軽減

© NTT Communications Corporation All Rights Reserved. 33 WebRTCで発⽣する不具合はなぜ起こってしまうのか？ WebRTCは様々な遅延や⽋損対策を⾏っているが、⼗分ではない
• FEC(Forward Error Correction) • ロスしたパケットの復元 • GCC(Google Congestion Control) • 帯域幅推定と映像エンコード時のQP値やフレームレートの制御 • DTX(Discontinuous Transmission) • 送信量削減(無⾳パケット除去) • HWA(HardWare Acceleration) • デバイス負荷軽減

WebRTCが技術として複雑すぎる

WebRTCが技術として複雑すぎる 2-1: プロトコルスタックが複雑

WebRTCが技術として複雑すぎる 2-1: プロトコルスタックが複雑 https://hpbn.co/webrtc/#real-time-network-transports

WebRTCが技術として複雑すぎる 2-1: プロトコルスタックが複雑 • プロトコルの集まりがWebRTC https://hpbn.co/webrtc/#real-time-network-transports

WebRTCが技術として複雑すぎる 2-1: プロトコルスタックが複雑 • プロトコルの集まりがWebRTC • ブラウザ内部で⾊々な処理が⾏われている

WebRTCが技術として複雑すぎる 2-1: プロトコルスタックが複雑 • プロトコルの集まりがWebRTC • ブラウザ内部で⾊々な処理が⾏われている https://zenn.dev/tetter/articles/rtptransport-first

WebRTCが技術として複雑すぎる 2-1: プロトコルスタックが複雑 • プロトコルの集まりがWebRTC • ブラウザ内部で⾊々な処理が⾏われている • シーケンシャルなフローに⾒えるが、実際は複雑に絡み合っている https://zenn.dev/tetter/articles/rtptransport-first

WebRTCが技術として複雑すぎる 2-2: ハードウェア・OS・ブラウザの実装に依存する

WebRTCが技術として複雑すぎる 2-2: ハードウェア・OS・ブラウザの実装に依存する https://zenn.dev/tetter/articles/rtptransport-first

WebRTCが技術として複雑すぎる 2-2: ハードウェア・OS・ブラウザの実装に依存する • メディア取得時: ハードウェア・OSの機能を通してカメラ・マイクにアクセス https://zenn.dev/tetter/articles/rtptransport-first

WebRTCが技術として複雑すぎる 2-2: ハードウェア・OS・ブラウザの実装に依存する • メディア取得時: ハードウェア・OSの機能を通してカメラ・マイクにアクセス • メディアエンコード時:ハードウェア・OSの機能を通してHWAのON/OFF https://zenn.dev/tetter/articles/rtptransport-first

WebRTCが技術として複雑すぎる 2-2: ハードウェア・OS・ブラウザの実装に依存する • メディア取得時: ハードウェア・OSの機能を通してカメラ・マイクにアクセス • メディアエンコード時:ハードウェア・OSの機能を通してHWAのON/OFF • メディアエンコード時:エンコード処理の設定をブラウザが動的に変更する https://zenn.dev/tetter/articles/rtptransport-first

WebRTCが技術として複雑すぎる 2-3: これ以外にも、拡⼤したユースケースに対応するために様々な機能を持つ

WebRTCが技術として複雑すぎる 2-3: これ以外にも、拡⼤したユースケースに対応するために様々な機能を持つ • P2Pではなくサバクラ型で数⼈〜数百⼈通話 • ビデオ会議以外にも、⾳楽のライブ配信やゲーム映像の送信など • ブラウザ以外のiOS/Android/Unityなどの対応

WebRTCが技術として複雑すぎる 2-3: これ以外にも、拡⼤したユースケースに対応するために様々な機能を持つ • P2Pではなくサバクラ型で数⼈〜数百⼈通話 • ビデオ会議以外にも、⾳楽のライブ配信やゲーム映像の送信など • ブラウザ以外のiOS/Android/Unityなどの対応元々の仕様ではP2Pで1対1のビデオ会議を前提としていたが、今となっては膨⼤な機能が持つようになった

© NTT Communications Corporation All Rights Reserved. 49 WebRTC Platformに
求められる責任 RESPONSIBILITY

不具合の説明責任

不具合の説明責任不具合が発⽣した際に、顧客に原因を説明し、解決⽅法を提⽰する。そして、解決できなかったとしても納得してもらう責任

不具合の説明責任不具合が発⽣した際に、顧客に原因を説明し、解決⽅法を提⽰する。そして、解決できなかったとしても納得してもらう責任しかし、この責任を全うするのは難しい

© NTT Communications Corporation All Rights Reserved. 54 WebRTC Platformに求められる責任を全うするのは難しい
なぜか？

なぜか？ • アンコントローラブルな事象が多い

なぜか？ • アンコントローラブルな事象が多い • 動きのほとんどがブラウザ・OS・ハードウェアによって隠蔽されている

なぜか？ • アンコントローラブルな事象が多い • 動きのほとんどがブラウザ・OS・ハードウェアによって隠蔽されている • WebRTCのイベントや統計情報は多様で取捨選択が必要

なぜか？ • アンコントローラブルな事象が多い • 動きのほとんどがブラウザ・OS・ハードウェアによって隠蔽されている • WebRTCのイベントや統計情報は多様で取捨選択が必要従来のメトリクスモニタリングなどでは原因究明が困難であるため、⼯夫が必要

© NTT Communications Corporation All Rights Reserved. 59 Monitoringから Observabilityへ
CHANGE

『原因究明』のために内部状態を正確に取得することは、隠蔽されているので不可能

『原因究明』のために内部状態を正確に取得することは、隠蔽されているので不可能よって、WebRTCのイベント情報や統計情報から、WebRTC通信の動きを推測する必要があった

『原因究明』のために内部状態を正確に取得することは、隠蔽されているので不可能よって、WebRTCのイベント情報や統計情報から、WebRTC通信の動きを推測する必要があった MonitoringからObservabilityへ踏み込むということ

© NTT Communications Corporation All Rights Reserved. 66 MonitoringからObservabilityへ Observabilityとは
”外部出⼒の知識からシステムの内部状態をどれだけうまく推測することができるかの尺度” Charity Majors(2023) オブザーバビリティ・エンジニアリング

”外部出⼒の知識からシステムの内部状態をどれだけうまく推測することができるかの尺度” Charity Majors(2023) オブザーバビリティ・エンジニアリング

”外部出⼒の知識からシステムの内部状態をどれだけうまく推測することができるかの尺度” Charity Majors(2023) オブザーバビリティ・エンジニアリング “WebRTCのイベント情報や統計情報から、WebRTC通信の動きを推測する”

”外部出⼒の知識からシステムの内部状態をどれだけうまく推測することができるかの尺度” Charity Majors(2023) オブザーバビリティ・エンジニアリング “WebRTCのイベント情報や統計情報から、WebRTC通信の動きを推測する” そして開発したものが、WebRTC専⽤のObservabilityシステム SkyWay Analytics β

β

β SkyWayがWebRTC Platformとして、説明責任を果たすために WebRTCの通信状況をお客様に説明するプロダクト

β お客様端末・サーバーから情報を吸い上げ、集積し、簡潔に要約する

β お客様端末・サーバーから情報を吸い上げ、集積し、簡潔に要約するサーバやログ監視だけではなくEUMやAPM的な情報も含む

β お客様端末・サーバーから情報を吸い上げ、集積し、簡潔に要約するサーバやログ監視だけではなくEUMやAPM的な情報も含む EUM(End User Monitoring): 端末・OS情報など

β お客様端末・サーバーから情報を吸い上げ、集積し、簡潔に要約するサーバやログ監視だけではなくEUMやAPM的な情報も含む EUM(End User Monitoring): 端末・OS情報など APM(Application Performance Monitoring): NW品質やメディア品質など

β

β の評価

β の評価 SkyWayが10年以上蓄積してきたノウハウを活かして設計したことでお客様から「通話状況が理解しやすくなり、調査が捗った」と⾔って頂けるように

β の評価 SkyWayが10年以上蓄積してきたノウハウを活かして設計したことでお客様から「通話状況が理解しやすくなり、調査が捗った」と⾔って頂けるように βから正式サービス提供へ

WebRTCは様々な不具合が発⽣する • その不具合にはPlatformとして対応が困難なものも多い

WebRTCは様々な不具合が発⽣する • その不具合にはPlatformとして対応が困難なものも多い • サーバメトリクスやログの監視だけではなくAPM, EUMまでやる必要性

WebRTCは様々な不具合が発⽣する • その不具合にはPlatformとして対応が困難なものも多い • サーバメトリクスやログの監視だけではなくAPM, EUMまでやる必要性 • MonitoringからObservabilityへ

WebRTCは様々な不具合が発⽣する • その不具合にはPlatformとして対応が困難なものも多い • サーバメトリクスやログの監視だけではなくAPM, EUMまでやる必要性 • MonitoringからObservabilityへ • Platformとしての説明責任を果たすため、SkyWay Analytics βを提供開始した

WebRTCは様々な不具合が発⽣する • その不具合にはPlatformとして対応が困難なものも多い • サーバメトリクスやログの監視だけではなくAPM, EUMまでやる必要性 • MonitoringからObservabilityへ • Platformとしての説明責任を果たすため、SkyWay Analytics βを提供開始した • お客様にも使ってもらえるプロダクトに

SkyWayが遭遇したWebRTC の可観測性に関する問題と開発者向け可視化サービス提供までの道のり

SkyWayが遭遇したWebRTC の可観測性に関する問題と開発者向け可視化サービス提供までの道のり

More Decks by yuki_uchida

Featured

Transcript