この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWS認定トレーニング講師の平野@おんせん県おおいたです。
Formula One社の動画配信に関するセッションに参加しましたのでレポートします。
動画配信の基本
まずは、一般的な動画配信の基本的な仕組みです
この動画配信を、AWSメディアサービスを利用する際の一般的な構成図です。
Formula One社について
Formula One社では、様々なF1関連のデジタルプロダクトを扱っています。 今日はこの中でも、F1TVの動画配信についてフォーカスします。
ここで、F1のマーケットについてです。F1の視聴者は世界中にいます。そのため、世界中に安定したコンテンツ配信を行うことが重要です。
F1コンテンツの特性
まず、レースのスタート時にをピークに新規接続要求が発生します。そして総視聴者は増加し続けます。
- 10分前
- 再生リクエスト数 > ピーク時の同時接続ユーザー数
- レース中の全リクエストの40%に対応
- オープニング2分前
- ピーク時の視聴者の30％が参加
- レーススタート
- 同時接続ユーザー数はピークの76%に到達
このような過酷な条件の中で、グローバルなビデオQoS指標は常に業界平均を上回っています。 このセッションでは、このクオリティを支える仕組みを紹介します。
コンテンツ配信の課題
コンテンツ保護については、F1TV ではストリーム・トークナイゼーションと DRM を採用しており、どちらのプロセスもユーザーごとに実行する必要があります。 セッション開始時に発生する膨大なトラフィックを考慮し、パフォーマンスとスケーラビリティのあるソリューションが必要です。 F1はAWS製品チームと協力して、現在CloudFront Functionsと呼ばれるGA前のサービスを開発しました。このサービスにより、トークン検証をエッジで行うことができ、各処理にかかる時間は実質1ミリ秒未満になりました。 関数の呼び出しは1分間に数千万回を超えることがあります。
参考:動画配信におけるコンテンツ保護の重要性とそれを実現する仕組みを自分なりにまとめてみた
コンテンツ配信のしくみ
ライブコンテンツのライフサイクルはこのようになります
- 本番前の活動
- チャンネル開始
- アセット、全ストリーム、機能検証済み
- ライブ化
- ステータスをライブに設定
- 可用性と再生の確認
- トリミング
- 新しいスタートポイントにトリミング
- 疑似FERへ移動
- トリムマーク設定
- P-FERに設定
- FERへ移動
- ハーベストジョブのトリガー
- ステータスをFERに設定
このライフサイクルを、AWSメディアサービスを利用して管理しています
- デフォルトのライブURLでライブ再生
- 開始と終了のクエリ文字列パラメータを指定したライブURLによる擬似再生。
- ライブからVODへのハーベスティング
- ライブからVODへのハーベスティングをVODアセットとして取り込む。
- VOD URLを介したイベント全体のリプレイ
また、耐障害性の高いライブワークフローを実現しています
- 冗長化されたグランドコントリビューション
- タイムコード同期されたRTP/FECメザニストリーム
- 2つの異なるがロックされたクラウドトランスコーディングパイプライン
- 入力タイムコードに基づき、HLS ABRの再編成を調整
- プレーヤーに対して透過的な入力フェイルオーバーによるパッケージング
- 単一の再生用URL
コンテンツ保護にはSPIKEを利用しています
参考：AWS MediaServices で DRM を使用する際に出てくるキーワード「SPEKE」を理解する
高度なメタデータ管理として、KLVを利用しています
- KLV = Key-Length-Value は、集中的なデータ伝送に最適化された柔軟なバイナリメタデータ保存形式です。
- KLVメタデータ・メッセージはビデオ・フレームに同期しています。
- メタデータのストリームを標準化し、プレーヤーの実装を容易にするために、スポーツごとに特定の KLV 辞書を作成することが可能（すべき）です。
- Contributionエンコーダは、KLVメタデータを含むSBRリニアTSを生成する。 メディアライブは KLV 付きの ABR HLS/TS を生成する。
- MediaPackageはKLVメタデータをDASHまたはHLS/CMAFストリームのMP4 emsgボックスにカプセル化する。
- エンドユーザーは、プレーヤーのインターフェイスで、どのデータポイントの視覚化に興味があるかを選択することができます。
- 選択されたKLVテレメトリデータポイントは映像の上にオーバーレイ表示されます。
エッジを使ったQoLの向上
今回利用するCloudFrontは世界中にアクセスポイントがあります
最大規模のイベント配信を実現するための構成はこのようになっています
- トラフィックルーティングによる負荷の分散
- 人気のあるオブジェクトはL1キャッシュにプロモート
- 同時リクエストに対応したリクエストの折りたたみ
- 中間層のリージョナルエッジキャッシュ
Origin Shieldを使ったCloudFrontのアーキテクチャです。 リージョナルエッジキャッシュをOrigin Shieldとして利用しています・
オリジンをOrigin Shieldにオフロードしたさいの、F1TVへのインパクトです。99.73%-99.86%のキャッシュヒット率を実現しています。
コンテンツ保護処理をエッジにオフロード
まず、トークンによるアクセス制御（トークン化）を利用しています
アクセス制限においては、下記を考慮する必要があります
- ビデオアセットへのアクセスのスコープダウン
- ビデオアセット独自のパスパターン
- パスのばらつきがある場合の課題
- トークンの使用を制限するための視聴者属性
- 視聴者の IP アドレス
- ユーザーエージェント
- リファラー
- セッションID
- 居住国または居住地域
エッジでのセキュアなメディア配信を行うために、このような構成にしています。
エッジでのセキュアなメディア配信をAWSで実現しました
- 簡単な統合
- オープンかつ拡張可能なパスベースのトークンインプリメンテーションで、クライアント側の統合依存はゼロです。
- パフォーマンスと拡張性
- CloudFront Funtionsの活用により、トークン検証をシームレスに拡張し、数百万の同時リクエストをサブミリ秒のコード実行時間でサポートすることが可能です。
- 強力な自動化
- 鍵のローテーションと不正なセッションの取り消しを自動化し、運用の負担を軽減します。
不正なセッションの取り消しを自動化を行ってます。例えば、同じセッションIDが異なるIPで使われていると疑わしいと判断しています。
不正セッションの取り消しはStepFunctionsを利用しています。
まとめ
Formula One社の動画配信に関するセッションについてまとめました。 コンテンツ保護とQoSを両立させるこの方法、今後有償動画配信を検討される方の参考になればと思います。
追記
このセッションがYoutubeで公開されていました。ご興味あればご視聴ください。
4
