【レポート】AWS 上で実装するライブ動画配信のアーキテクチャパターン〜 2022 年版 〜(AWS-31) #AWSSummit

AWS Summit Online 2022 のセッション『AWS 上で実装するライブ動画配信のアーキテクチャパターン〜 2022 年版 〜』のセッションレポートとなります。
2022.05.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、大前です。

今回は 2022年 5月25-26日の 2日間開催されている AWS Summit Online のセッションレポートをしていきます。セッションのサマリーを理解し、興味があるセッションをチェックすることにご活用ください。また、セッションのアーカイブも公開されますので、詳細はそちらをチェックしてください。

セッション概要

AWS メディアサービスには、 メディアワークロードのための機能セットが豊富に用意されており、 要件にあわせて各機能を組み合わせて使って頂けるような疎結合な設計思想となっています。 本セッションでは、 ライブ動画配信にスコープを当てて、 各社様事例、ユースケース毎のアーキテクチャパターン、具体的な配信基盤の設計方法、各メディアサービスの特徴や最新アップデート情報をご紹介いたします。

スピーカー

AWS 技術統括本部 インターネットメディアソリューション部 部長 シニアソリューションアーキテクト 廣瀬 太郎

セッションレポート

AWS Media Services とは

  • メディアワークロードの全体像について
    • メディアを一口に言ってもユースケースは多彩
      • コンテンツ制作
      • メディアサプライチェーン & アーカイブ
      • 放送
      • D2C & ストリーミング
      • データサイエンス & 分析
    • AWS はメディアワークロードに対する強力な機能群やソリューションを提供
    • 今回は放送やストリーミングの領域に焦点を当てていく
  • AWS Media Services
    • 放送品質の配信を実現するためのマネージドサービスとして Media Services
    • Twitch の技術をベースとした Amazon IVS
    • それぞれが疎結合になっていて、必要なものを組み合わせて利用できる

AWS Media Services x ライブ動画配信 のアーキテクチャパターン

  • 12個のユースケース
    • (1)シンプルな HLS ライブ配信
    • (2) HLS & DASH マルチフォーマット配信
    • (3) ライブ配信をアーカイブ
    • (4) ライブ配信中に巻き戻し(DVR)
    • (5) FILE/LIVE をスケジュール配信
    • (6) コンテンツの暗号化 / DRM
    • (7) サーバサイド広告挿入(SSAI)
    • (8) 同時配信数が増減(UGC)
    • (9) 超低遅延配信(ULL)
    • (10) ビデオミーティングのマス配信
    • (11) 高い信頼性で映像伝送
    • (12) 移動先でも安定打ち上げ
  • 1-5 は割愛するが、事例を紹介
  • コンテンツの暗号化/DRM
    • 最近は問い合わせの多いトピック
    • 暗号化の目的はコンテンツ流出の防止が大きい
    • AES-128 を利用して暗号化
      • メリットは構成をシンプルにできる
      • 鍵の用意と配布の仕組みだけ用意すれば良い
      • MediaLive 側で鍵の入力項目などがある
    • DRM を利用するパターン
      • DRM Key Provider の準備が必要
      • Provider に対して SPEKE という規格で鍵情報のやり取りを実施
      • SPEKE とは?
        • パッケージングシステムが DRM システムと連携するための標準規格
        • 幅広い再生環境に対応するため、DRM のシステムが多種多様であるため、こう言った標準規格が必要になる
        • SPEKE は CPIX をベースとしている
        • 昨年 SPEKE のバージョンアップがあり、機能が拡充している
        • 基本的には 3rd Party の製品を使うことが推奨されるが、動作を理解する目的で、AWS 上に SPEKE 連携するための実装サンプルを展開して触ってみることもおすすめ
  • サーバサイド広告挿入(SSAI)
    • ライブストリームに広告を挿入する場合、視聴体験を損なわないことが重要
    • わかりやすいのは特定のタイミングで広告のストリームにスイッチすることだが、デメリットもある
    • AWS では MediaTailor を利用することで動画コンテンツに広告動画を挿入することができる
    • MediaTailor がマニフェスト加工を動的に行うため、シームレスな広告挿入が可能
    • SCTE を解釈して広告を挿入するため、SCTE をどう挿入するかがポイント
      • MediaLive 側で SCTE を挿入することも可能
    • MediaTailor の Channel Assembly
    • MediaTailor は AD サーバーに VAST でリクエストを投げて挿入する広告について情報を連携する
      • VAST のリクエストが集中してスパイクすることがない様なアップデートが MediaTailor に追加されている
  • 超低遅延配信
    • 一般的には CMAF + Chunked Transfer Encoding が利用されることが多い
      • セグメントをより細かく分けて送信することができるため、低遅延につながる
      • エンコーダーやパッケージャー、CDN、プレイヤーなどで対応が必要
    • Amazon IVS
      • ライブ配信を簡単にセットアップできるサービス
      • 動画配信を実現するためのハードルを下げた
      • 超低遅延配信に必要なコンポーネントが一貫して提供されている
      • Twitch で実績のある技術を活用している
      • チャンネルの管理なども不要
      • 配信用の SDK がサポートされた
    • MediaStore と CloudFront は Chunked Transfer に対応しているため、エンコーダーやプレイヤーを準備できればこちらを活用することも可能
  • ビデオミーティングのマス配信
    • 相談が増えてきたユースケース
    • 配信レイヤーの手前に Chime SDK を利用
    • Chime SDK で実現したビデオ会議に対してキャプチャ用のユーザを参加させ、そこから MediaLive 等に配信
  • 高い信頼性で映像伝送
    • 手段は大きく 2つ
      • 通信衛星
      • Web 経由での伝送
        • コストは安価だが、品質担保に対する工夫が必要
        • 品質担保できるプロトコルを利用する
    • MediaConnect
      • 様々なプロトコルをサポート
    • E2E で対象外性を考慮する必要があるのが動画配信
      • 重要なイベントでは冗長性を持たせる必要がある
      • AWS で高い可用性を実現するためのアーキテクチャ
        • クラウドに入力するコンポーネントを冗長化する
          • 入力系統の不具合も考えられる
        • クラウド側のパイプラインを冗長化(MediaConnect)
          • AZ 障害に備える
        • MediaLive への冗長入力
          • こう可用性が求められ場合は STANDARD Channel を利用
        • MediaPackage
          • ライブ入力の冗長性をサポート可能
        • CDN
          • 必ず CDN を利用してオリジン保護を検討
          • ライブコンテンツであっても、同一リクエストを待機させる仕組みがあるため、CloudFront の利用は有効
          • Origin Shield を利用することにより Origin 負荷をさらに減らす
          • さらに大規模である場合は複数 CDN の利用も検討
  • 移動先でも安定打ち上げ

まとめ

  • 紹介したユースケースを頭に入れていただけると、今後アーキテクチャを検討する際に参考になるはず
  • Well-Architected Framework の Streaming Media Lens の活用も検討

おわりに

基本的な内容は以前の Summit と同じでしたが、近年の需要の変化やサービスアップデートなどに合わせて内容がアップデートされており、最新の AWS Media Services の状態や、できることの全体像を把握するためにとても参考になるセッションでした。

実際の配信ではアーキテクチャ図等も表示されていますので、気になる方は是非アーカイブの方を視聴ください。

以上、AWS 事業本部の大前でした。