RUM と STM で実現する動画視聴における信頼性エンジニアリング
•
0 gostou•759 visualizações
This presentation illustrates how the video engineers in ABEMA practice reliability engineering in video QoS/QoE. It is basically done by measuring SLIs and discovering issues with SLOs. RUM helps us measure SLIs and decide SLOs, and STM helps us aggressively discover issues that are hard to detect with RUM only.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a RUM と STM で実現する動画視聴における信頼性エンジニアリング
Semelhante a RUM と STM で実現する動画視聴における信頼性エンジニアリング (20)
Mais de Yusuke Goto
Mais de Yusuke Goto (18)
RUM と STM で実現する動画視聴における信頼性エンジニアリング
- 2. 五藤 佑典 YUSUKE GOTO https://ygoto3.com/ @ygoto3_ ● California State University, San Bernardino グラフィックデザイン専攻 ● ソフトウェアエンジニア @ サイバーエージェント ● ABEMA 開発本部 ○ Cross Device チーム あらゆるデバイスにABEMA を展開するための技術を提供するチーム ○ Streaming Client チーム ABEMA の再生品質を軸にUX エンジニアリングにコミットするチーム ○ 動画技術エバンジェリスト 世界各国に足を運び動画技術に関する情報をキャッチアップし、 社内外の動画サービスの発展に貢献するロール ○ DesignOps 推進バックエンド 大規模組織でスケールできるプロダクトデザイン開発組織を構築する活動
- 3. in Video Technology and Product Design
- 5. 信頼性エンジニアリング
- 6. 信頼性エンジニアリング 元々はインフラ領域の運用上の問題に 拡張性と信頼性を作り出すためのエンジニアリング分野 ● 開発と運用のバランスを取るソリューションを生み出す ● この領域の開拓者は Google https://sre.google/books/
- 7. 動画視聴領域への転用 動画視聴に関わるシステムも日々拡張しながら運用されている ABEMA に必要な価値 24 / 365 日の可用性 新しい未来のテレビ に必要な機能拡張
- 10. 信頼性エンジニアリングの基本 計測する SLI を決める SLO を定める 課題を見つける
- 11. 計測する
- 15. サーバー側で検知できない不具合 正常なレスポンスを返しても視聴に失敗するケースは多くある ● 特定のバージョンでのみ発生 ● 特定の環境でのみ発生 ● 特定のデバイスでのみ発生 ● サーバーがリクエストを受け取る前にクラッシュ ● 出力マニフェストの変更によりリバッファリングの頻度増加 ● エンコーディングパラメータの変更によりデコード失敗 ● コンテンツ特性である区間だけ高ビットレート
- 17. 配信の仕組み Encoded files Transcoder HLS ingest Virtual manifests Manifest playout
- 18. ABEMA ストリーミングの特徴 2 つのストリーミングプロトコル 2 つのメディアフォーマット 20 以上のサポートプラットフォーム ● HTTP Live Streaming ● MPEG-DASH ● MPEG-2 TS ● fragmented MP4 ...
- 19. 20 以上のサポートデバイス ● iPhone ● iPad ● Apple TV ● Android Smartphone ● Android Tablet ● Android TV ● Fire Tablet ● Amazon Fire TV ● Google Chrome ● Mozilla Firefox ● Internet Explorer ● Microsoft Edge ● Apple Safari ● Google Chromecast ● Google Daydream View ● Amazon Echo ● LINE Clova Desk ● SONY BRAVIA ● Panasonic VIERA ● TOSHIBA REGZA ● LEOPALACE21 Life Stick ● CCCAIR Air Stick ● ...
- 20. DRM の組み合わせ HLS + TS MPEG- DASH + fMP4 FairPlay Streaming iOS Microsoft PlayReady
- 21. 低遅延のニュース ● 短いセグメント長 ○ 通常ストリーム： 5 秒セグメント → 低遅延ストリーム： 1 秒セグメント ● アグレッシブなインジェスト方式 ○ 通常ストリーム： Pull 型インジェスト → 低遅延ストリーム： Push 型インジェスト
- 22. パーソナライズされた広告挿入 ● ユーザーによって異なるマニフェスト ○ 再生されるコンテンツの順番が異なる ○ 再生される動画コンテンツ自体が異なる ● 通常経路と異なるメディアコンテンツ生成フロー ○ 動画のエンコードパスが異なる
- 25. 実際のユーザー環境で計測する
- 28. 動画プレイヤーの状態 動画プレイヤーの状態 ● Joining ● Playing ● Buffering ● Crashed ● Ended
- 31. 状態遷移から算出可能なメトリック例 ● Quality of Service を計測するメトリック ○ Startup Failure ○ In-stream Crash ● Quality of Experience を計測するメトリック ○ Buffer Ratio ○ Buffering Events ○ Join Time ○ Average Bitrate
- 32. 複合指標でユーザー ● メトリックの組み合わせでユーザーエンゲージメントを計測することも可能 ● Playtime ● Plays ● Join time ● Buffering ratio ● Buffering event %
- 33. メトリックをどう使うか
- 35. 低品質な視聴体験 Joining Playing 長い Join Time 短いが頻繁な バッファリングイベント Ended Buffering 1 回だけだが 長いバッファリング時間
- 36. 低品質な視聴体験 Joining Playing 長い Join Time 短いが頻繁な バッファリングイベント Ended Buffering 1 回だけだが 長いバッファリング時間 ユーザーにストレスを与える状態遷移
- 37. 低品質な視聴体験 Joining Playing 再生開始前にクラッシュ = Startup Failure Ended
- 38. 低品質な視聴体験 Joining Playing 再生開始前にクラッシュ = Startup Failure Ended ユーザーはコンテンツを視聴できていない
- 39. 低品質な視聴体験 Joining Playing 再生中にクラッシュ = In-Stream Crash Ended
- 40. 低品質な視聴体験 Joining Playing 再生中にクラッシュ = In-Stream Crash Ended ユーザーはコンテンツを最後まで視聴できていない
- 41. 高品質な視聴体験 Joining Playing 短かい Join Time クラッシュもバッファリングもなく再生終了 Ended
- 42. 高品質な視聴体験 Joining Playing 短かい Join Time クラッシュもバッファリングもなく再生終了 Ended メトリックをこの状態に近付ける
- 43. SLI を決める
- 44. SLI を決めるコツ ABEMA の視聴者にとって直接的な意味を持つキークエスチョンを用意する ● 視聴開始に成功したか？ ● 最後まで視聴できたか？ ● 映像／音声品質は良かったか？ ● 再生開始まで長い時間待つことはなかったか？
- 45. SLI を決めるコツ ABEMA の視聴者にとって直接的な意味を持つキークエスチョンを用意する ● 視聴開始に成功したか？ ● 最後まで視聴できたか？ ● 映像／音声品質は良かったか？ ● 再生開始まで長い時間待つことはなかったか？ キークエスチョンをメトリックを 組み合わせた数式で表現する
- 46. 再生開始に成功したか 再生セッションのうち Startup failure がないものと定義
- 47. 再生は完了したか 再生セッションのうち In-stream crash がないものと定義
- 49. 再生開始までの時間は短かったか 再生セッションのうち Join time が意図した時間より短かったものと定義
- 50. SLI が決まった
- 51. SLI が決まった 目指す SLO を定める
- 52. SLO を定める
- 53. SLO を定める 1. いま現在のファクトをデータで収集する 2. いま現在のサービスレベルを維持するための閾値を定める 3. 目指すべき理想の目標値を定める
- 54. 現在のファクト
- 55. SLO ドキュメントを作る Category SLI SLO <In-action> SLO <Ideal> QoS Startup success rate 99% 99% QoS Playback completion rate 95% 99% QoE Rendition distribution success (>= 1080p 60%) rate for TV 70% 90% QoE Join time success (<= 3 secs) rate for Linear 70% 90%
- 56. 課題を見つける
- 57. 信頼性エンジニアリング実践の課題 定めた SLO を下回らないように何ができるのか ● SLO を下回るリスク ○ 障害により SLO を下回るリスク ○ 徐々に品質が低下して定常的に SLO を下回るような状態になるリスク ○ 外れ値的なノイズやサンプルサイズの揺れにより SLO を下回るリスク
- 63. 避難訓練を行う 臨場感を出す Wheel of Misfortune 方式による ランダムアサインメントで 避難訓練実施者が決まる
- 65. 信頼性エンジニアリング実践 徐々に品質が低下して定常的に SLO を下回るような状態になるリスク 定期的に SLO を振り返る
- 68. SLO を振り返る
- 69. SLO を振り返る 月の振り返りのタイミングに SLO を割っていることに気付く SLO を割りそうな兆候があったら 振り返りを待たずに知りたい
- 70. SLO アラートを設定する ● Burn Rate を設定する https://sre.google/workbook/alerting-on-slos/
- 71. 適切な Burn Rate をシミュレート
- 72. 適切な Burn Rate を探る 過敏に反応しすぎても 徒労に終わってしまう
- 74. 原因が特定できるケースばかりではない ● Startup Failure ● In-stream Crash ● Buffer Ratio ● Buffering Events ● Join Time ● Average Bitrate RUM で計測できるメトリクスは表面的
- 75. RUM が得意とするところ ● 統計的な分析ができる ○ 地域条件や端末種別などの複数のセグメントの組み合わせを比較できる ● ユースケースを絞る必要がない ○ 実際にユーザーが使った事実のみが記録される ● 優先順位が高い課題が検知できる ○ 条件にあてはまるユーザーシェアなどを基準に優先順位を決定できる
- 76. RUM が苦手とするところ ● 分析やデバッグに必要な詳細情報は取得できない ○ プロファイリングなど解析が必要な情報はユーザー端末に負荷をかける ○ 分析／デバッグする情報が不足する ● 実ユーザーのアクセスがなければデータを得られない ○ データから発見できる事柄は常に事後になる ● 特定条件に対するベンチマーク
- 77. RUM が苦手とするところ ● 分析やデバッグに必要な詳細情報は取得できない ○ プロファイリングなど解析が必要な情報はユーザー端末に負荷をかける ○ 分析／デバッグする情報が不足する ● 実ユーザーのアクセスがなければデータを得られない ○ データから発見できる事柄は常に事後になる ● 特定条件に対するベンチマーク RUM の不得手な部分の監視を 補完する手段が必要
- 78. STM による補完 STM（Synthetic Transaction Monitoring） ● スクリプト等によるユーザー活動をシミュレートし、その結果を監視する手法
- 79. STM が得意とするところ ● 事前に課題を検知できる ○ 想定シナリオを事前にシミュレーションできる ● 数字の中身を詳細に分析できる ○ 実ユーザー環境への負荷をかけることなく、ウォーターフォールチャートのように数 字を可視化できる ● 複雑なユースケースを定点観測可能できる ○ 観測ポイントを自由に設定でき、複数のアクションで構成されるユースケースを何 回も繰り返すシミュレートが可能
- 80. STM が苦手とするところ ● ユーザーの実体験を反映していない ○ あくまでシミュレーションによる結果であり、ユーザーに同じ結果が起きる／起きて いるとは限らない ● 予測不能な変数による課題発見に弱い ○ 人が考えうるシミュレーション条件が網羅の限界になる
- 81. STM が苦手とするところ ● ユーザーの実体験を反映していない ○ あくまでシミュレーションによる結果であり、ユーザーに同じ結果が起きる／起きて いるとは限らない ● 予測不能な変数による課題発見に弱い ○ 人が考えうるシミュレーション条件が網羅の限界になる RUM 同様 STM も得手不得手がある
- 82. RUM と STM 両者の強みを活かす ● RUM による受動的／俯瞰的な監視 ○ 実ユーザーが得ている視聴品質の事実を 統計的に監視 ● STM による能動的／詳細な監視 ○ システム変更に対するユーザー影響の事前シミュレーション ○ 重要なユースケースにおける詳細データの収集 ○ 複数のユーザー行動が伴う複雑なユースケースの定点監視
- 83. STM システムを構築する ユーザー活動をシミュレーションする環境を構築する ● デバイスファーム ● スクリプトによるトランザクション自動実行 ● パフォーマンス計測 ● 主観指標の計測
- 84. STM システムを構築する w/ ● デバイスファーム ○ Android / iOS / Web ブラウザに対応したデバイスファーム ● スクリプトによるトランザクション自動実行 ○ Appium / Selenium によるスクリプト実行機能 ● パフォーマンス計測 ○ コンピューティング、通信のパフォーマンス計測 ● 主観指標の計測 ○ AI エンジンによる映像品質の Mean Opinion Score 推測
- 87. 定期的な視聴セッション実行
- 88. 定期的な視聴セッション実行
- 89. 映像に対する主観指標計測
- 91. STM によって何が可能になるか ● 主観指標のシミュレーション ● ステージング環境での事前監視 ● 限定条件下の動画視聴品質監視 ● 異常／障害発生時の能動的デバッグ情報の収集／解析
- 93. MOS (Mean Opinion Score) 受信側で知覚されるメディアの品質の評価を数値で表す古くからある方法 5 Excellent 4 Good 3 Fair 2 Poor 1 Bad 人々に実際に映像を見てもらい映像品質を 5 段階評価された 評点を算術平均する AI にパターンを学習させて 自動的に算出する - 平均オピニオン評点
- 94. 主観指標のシミュレーション
- 95. 主観指標のシミュレーション
- 96. ステージング環境での事前監視 視聴品質は動画配信の入りから出までの全ての変更に影響を受ける ● アプライアンス／物理的設備の変更 ● エンコードパラメータの調整 ● 配信経路の変更 ● プレイリスト／マニフェストの変更 ● 動画再生クライアントの再生アルゴリズム変更 ● ．．．
- 101. 限定条件下の動画視聴品質監視 固定する変数例 ● 実行デバイス ● アプリケーション実装 変動的な環境とアプリケーション実装から切り離したリファレンス動画視聴 可変させる変数例 ● 通信速度 ● 地域 ● 配信アルゴリズム ● 動画プレイヤー 外部要因と動画視聴課題を切り分けて、調査の初期速度を上げる
- 102. まとめ ● 信頼性エンジニアリングの動画視聴領域への転用で開発の攻めと守りを決定する ● SLI は RUM メトリックからユーザーに直接意味があるインジケータを作る ● RUM の受動的／表面的な情報では SLO を達成するための課題発見に課題がある ● STM で RUM の弱い側面を補完して SLO の達成率を上げる