世界規模に対応する新しいライブ配信オリジン

世界で最も多くの人が観戦するスポーツ。米国では soccer、それ以外では football と呼ばれ、英国では信仰に近い存在です。FIFA ワールドカップ2026を前に、英国の大手放送局が大きな決断をしました。廃止される AWS Elemental MediaStore から Momento へライブ配信オリジンを移行し、数千万人のファンに配信する準備を間に合わせたのです。

単純なリフト＆シフトではありませんでした。この放送局のライブ配信基盤は、24時間365日のリニアチャンネル、大規模な大会、ニュースのピークを長年支えてきた、成熟した実績あるシステムです。その中核となるメディアストレージとオリジン層を置き換えるには、既存のエンコーダー、パッケージャー、CDN、コントロールプレーンのツール群を支えながら、レイテンシ、信頼性、運用の可視性に関する厳しい基準を満たす必要がありました。

本記事では、既存アーキテクチャ、AWS Elemental MediaStore の互換代替としての Momento の導入、そしてワールドカップとその先に向けた基盤の強化を紹介します。

出発点：大規模なライブオリジン

この放送局は、24時間365日の多数のサイマル放送チャンネルに加え、HD と UHD の期間限定ライブイベントを頻繁に配信しています。配信方式は DASH と HLS です。冗長性のために複数の AWS リージョンへストリームを送信し、各ストリームを複数の CDN へ展開します。

データ量の目安として、ライブオリジンは常時稼働する40以上のライブチャンネルと、季節ごとの期間限定チャンネルを管理しています。大規模スポーツイベントでは後者が同時に最大40チャンネルになります。ライブチャンネルは H.264 と HEVC でエンコードされ、ABR ラダーには通常8〜11の映像エンコードプロファイルと4つの音声トラックがあります。セグメントとマニフェストは2つの AWS リージョンに配置されたメディアストレージサービスへ送られ、各リージョン内で AZ 間レプリケーションが行われます。再生側では、CDN がオリジンから直接、または内部のキャッシュ集約層を介して取得し、プロバイダーや地域にトラフィックを分散します。

当初、放送局は標準の S3 バケットへの移行を検討しました。しかし、既存のアーキテクチャと運用が依存している機能の中には、保証されないものがありました。

AWS Elemental MediaStore の廃止が決まったとき、放送局は「飛行中に飛行機を作り直す」という典型的な課題に直面しました。世界的なサッカー大会の1年前という重要な時期に、パッケージャー、CDN 設定、動画プレーヤー、コントロールプレーンを書き直すことなく、また新たな障害要因を持ち込むことなく、重要なサービスを置き換える必要がありました。新サービスに求められた原則は次のとおりです。

• ロンドンのクライアントからのライブエッジの高速な読み書き。PUT（エンコーダーからの公開）と GET（再生）の両方で、最初と最後のバイトを受け取るまでの時間を短く保つこと。
• 古いマニフェストを積極的に失効させる一時データポリシー。プライマリの公開が止まった場合に、バックアップオリジンへの自動フェイルオーバーを促すこと。
• ある高トラフィックサービスが他のサービスを圧迫しないためのコンテナ単位のリクエスト制限。
• CDN とパッケージャーから安全にオリジンへアクセスするためのコンテナ単位のアクセスポリシーと CORS。
• 公開レイテンシ、エラーコード、空オブジェクトの公開、リージョン別内訳を把握する詳細なアクセスログとメトリクス。
• 古いコンテンツを整理し、ホットキャッシュ内のストレージコストを制御するライフサイクル管理。
• アクセスレイテンシの安定性を損なわずに、内部で S3 ベースのストレージの耐久性を維持すること。

設計目標：MediaStore の互換代替

両社で定めた設計目標は、言葉にするのは簡単でも、実現は困難でした。「アプリケーションの変更を最小限に抑えてオリジンを Momento Media Storage に置き換え、現在依存している運用上の動作を維持、あるいは改善する」というものです。

具体的には、Momento に次の要件が求められました。

• 同等の HTTP インターフェース：同じ形式の HTTP PUT/GET の動作、セグメントが存在しない場合の404/50xの動作、ヘッダーとトークンによるオリジン側のアクセス制御を維持する。
• ロンドンから同等以上の性能：英国のクライアントに対し、eu-west-1（ダブリン）と eu-west-2（ロンドン）の両方で、既存オリジンと同等以上の GET/PUT レイテンシを実現する。
• 一時データポリシーを再現する設定可能なオブジェクト TTL：コンテナに対するパスベースのライフサイクルルールではなく、マニフェストやセグメントなどオブジェクトの種類ごとに細かく TTL を制御する。古いマニフェストがフェイルオーバーを起こす既存モデルを維持するためです。
• 現在のダッシュボードに対応する運用可観測性：既存の監視とアラートのワークフローで、公開レイテンシ、エラーコード、スロットリング、パス別メトリクス、ほぼリアルタイムのアクセスログを引き続き利用できること。
• 適切なマルチテナント保護策：サービス単位のリクエスト制限とリージョン SLA を、従来のプラットフォームでの理解に沿う形で適用する。

現在：キックオフの準備は完了

初期の性能テストから本格的な本番稼働まで、ほぼ1年かかりました。その間、放送局と Momento は幅広いテストを行いました。

• 数十のチャンネルを並行して使う分散した公開と再生。
• さまざまなビットレートとラダーで、ロンドンのクライアントから eu-west-1、eu-west-2 へのレイテンシ比較ベンチマーク。
• 短いマニフェスト TTL と404の動作によって、CDN とプレーヤーが引き続き正しく自動応答することを確認する負荷テストとフェイルオーバー訓練。
• クライアント側の非効率や計測上の見かけの現象を取り除く SDK とネイティブ HTTP の比較テスト。
• 動画基盤全体に単一のオーケストレーション層を設けることで得られる再現性と自動化。
• 既存の CloudWatch ベースのダッシュボードとアラートへ組み込める、ワークフロー全段階での運用可観測性。

何より、現在のオリジン層は廃止予定ではなく、活発に開発されています。放送局のロードマップや将来の要件に合わせて進化できる基盤です。

今の目標は明快です。ワールドカップ初戦の開始を告げる笛が鳴ったとき、英国をはじめとする数千万人のファンが Momento 上の新しいオリジンを通じて観戦し、その違いに気づかないこと。それが、あるべき姿です。