Google Cloud でライブイベントのホスティングを成功させる

※この投稿は米国時間 2023 年 4 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

ライブイベントのホスティングを成功させるには、相当なレベルの計画と準備が必要です。Google Cloud は、重要なライブイベントを世界規模で配信するお客様をサポートしてきました。最近では、2022 FIFA ワールドカップのサッカーの試合を Media CDN を使用して世界中に配信しました。予期せぬタイミングで大勢の人が同時に視聴するというこのワークロードの特性は特殊です。この記事では、数々のベスト プラクティスおよびメディア パートナーとの連携によって得た教訓について、インフラストラクチャの計画、セキュリティ、そして Google Cloud プロダクト（コード変換のための Live Stream API、送信元のための Google Cloud Storage、配信のための Media CDN、オペレーション要件のための Cloud Logging および Cloud Monitoring）の使用に触れながら説明します。

ライブイベントをホスティングする際の検討事項

ライブイベントのホスティングは、コンテンツの権利取得から始まり、ライブイベントの最終日まで続く長い道のりです。理解しやすく、順を追って把握できるように、この道のりを次の 6 つのステップに分けて説明します。

1. 動画配信アーキテクチャの最終決定

2. キャパシティ プランニング

3. セキュリティの実装

4. 構成の固定

5. 通知、特定、解決

6. フォールバック計画のテストと小規模なイベントからの開始

動画配信アーキテクチャの最終決定

Google Cloud の VPC とネットワークは独自のアーキテクチャを採用しています。VPC は各リージョンにサブネットがあるグローバル VPC であるため、サービスの可用性を高めるためのマルチリージョン アーキテクチャへの対応がかなり簡単になります。

ライブイベントのホスティングを準備する場合、本質的に多くの同時接続やアクセスが発生するため、以下のような設計デプロイのパターンを検討してください。

2. 取り込みに SRT を使用する: RTMP や RTP と比較すると、SRT（Secure Reliable Transport）は、テレポートから、または直接スタジアムから送られてくる送信元ストリームとして信頼性が高くなります。

3. 送信元として Google Cloud Storage を使用する: ジャストインタイムパッケージング（JITP）と送信元の代わりに Google Cloud Storage（GCS）を送信元として使用します。JITP の管理とスケーリングは、同時実行の多い環境では特に困難です。ユーザーの増加ペースに合わせたインフラのスケーリングが行われていない場合、送信元へのリクエストが突然急増すると、送信元から 5xx エラーが発生する可能性があります。他方で、GCS は、プロジェクトごとのデフォルトの帯域幅割り当てが 200 Gbps（Media CDN と Cloud CDN への下り（外向き）はこの割り当ての対象外）、QPS のソフトリミットが 30 万件で、スケーラビリティに非常に優れています。いずれもサポート チケットを発行して増量できます。

4. 配信のための Media CDN: Media CDN は、YouTube 動画や大規模なバイナリを配信するために数十年にわたって構築されてきたライブ Google の既存のインフラストラクチャおよびネットワークの上に構築されており、Google 独自のアプリケーションで毎日数百万人の同時接続ユーザーに対応しています。インフラストラクチャ（ローカルな都市部での何千ものデプロイ）とネットワークのメリットに加え、送信元のシールド、結合のリクエスト、送信元のフェイルオーバー、再試行とタイムアウト、リアルタイム ロギングなどの Media CDN の機能が、同時実行が多いイベントを管理する際に独自の強みをもたらします。

5. Cloud Armor: これらのスポーツ イベントのほとんどには、セキュリティが法的要件に含まれています。Google Cloud Armor のセキュリティ機能を使用することでこれらの要件に対応できます。

キャパシティ プランニング

Media CDN のキャパシティ プランニングにおける 2 つの主要な要件は、ピーク時の下り（外向き）レートと 1 秒あたりのピーク時のキュー（QPS）です。これらの要件はいずれも、構成パラメータとビジネスデータに基づいて算出できます。

• ピーク時の下り（外向き）レート: 同時接続ユーザー数（または同時接続ユーザーの過去のデータ）と平均再生ビットレートのビジネス上の想定を使用して算出できます。

• 例: 500 万人の同時接続ユーザー x 平均 1 Mbps のビットレート = ピーク時の下り（外向き）レートは 4.76 Tbps～5 Tbps

• ピーク時の QPS: 同時接続ユーザーを 2 倍にしてセグメントの長さで割ります（各セグメントの終了時にプレーヤーが新しいマニフェスト ファイルと新しい動画セグメントをリクエストするため 2 つのリクエストが発生します。なお、音声と動画のセグメントが多重化されるため、これは HLS v3 のみに適用されます。他の個別の音声、動画、字幕の場合は、それぞれに応じた乗数を考慮してください）。

• 例: （500 万人の同時接続ユーザー x 2）/ セグメントの長さ 6 秒 = 166 万 QPS

セキュリティの実装

ほとんどのスポーツ団体には、盗用を避けるためのトークン認証、DRM の実装、ジオ ブロッキング、著作権問題など、コンプライアンスに関する要件があります。スケーリングのニーズに影響を与えることなく、これらの要件を管理する方法について説明します。

1. 盗用を避けるためのトークン認証: Media CDN は、有効期限の短いトークンと長いトークンを使用してリクエストを検証するデュアル トークン認証をネイティブにサポートしています。トークンの有効期限が切れる前にコンテンツにアクセスしようとする不正な行為者、同時実行ルールへの違反、著作権侵害行為の試行において特定の署名付き URL を無効にしたいお客様は、Network Actions を使用できます（限定公開プレビューの場合 - 限定公開プレビューの期間中にアクセスするには、Google のアカウント担当者までご連絡ください）。

2. 送信元の保護: Media CDN は、インターネットで接続可能なあらゆる HTTP(S) エンドポイントからコンテンツを取り込むことができます。場合によっては、お客様が Media CDN にのみコンテンツの取り込みを許可し、不正なアクセスを防止するために、送信元に向かうリクエストの認証を希望する場合がありますが、Cloud Storage は IAM 権限でこの要望に対応しています。

3. DRM の実装: 前述のように、JITP の管理とスケーリングは、同時実行が多い環境では困難です。ユーザーの増加ペースに合わせたインフラのスケーリングが行われていない場合、送信元へのリクエストが突然急増すると、送信元から 5xx エラーが発生する可能性があります。DRM インテグレーションをパッケージャだけで行うソリューションもあります。JITP は立ち上げ中にボトルネックになる可能性がありますが、Google Cloud の Live Stream API と一部の ISV パートナー ソリューションは DRM による事前パッケージング（この Live Stream API の機能は限定公開プレビューでの提供になります）と GCS バケットへの公開に対応しているため、JITP のスケーリング問題を管理するよりも操作がかなり簡単になります（DRM プロキシ サーバーのスケーリングを検討する必要がありますが、多くのパートナーが過去に問題なくこれを実現しています）。

4. ジオ ブロッキングと IP ブロッキング: Cloud Armor のエッジ セキュリティ ポリシーにより、キャッシュに保存されたコンテンツの位置情報と IP アドレスに基づいてフィルタリングおよびアクセス制御ポリシーを構成できます。

5. 著作権の申し立て: YouTube のような一般公開 OTT プラットフォームのほとんどは、著作権で保護されているコンテンツを簡単に識別して管理するためにコンテンツ識別システムを提供しています。コンテンツ権利チームにお問い合わせいただき、これらのプラットフォームのガイドラインに従ってください。

構成の固定

インシデントを回避するためには、次の重要な要素が大きな役割を果たします。ライブイベントを計画する際には、これらを適切に構成することが非常に重要です。

Live Stream API の構成:

• セグメントの長さ: セグメントの長さは、ユーザーが感じるレイテンシとエンドユーザーの QoE において重要な役割を果たします。セグメントの長さを短くすると、配信アーキテクチャを超えたエンドユーザー ネットワークでの輻輳により、再バッファリングが増加し、QoE が低下する可能性があります。理想的には、4～6 秒のセグメントが両者の間の最適なバランスであり、場合によっては、CDN が処理する HTTP リクエストの数を減らすことで、配信コストを削減することもできます。

• ビットレートの段階の最終決定: 平均ビットレートが高いほどピーク時の下り（外向き）レートが高くなることを理解したうえで、品質と平均ビットレートのバランスを取るためにビットレートの段階を最終決定します。承認された容量を超えないように、両方のバランスを取る必要があります。

• ライブイベント中に、ピーク時の下り（外向き）ユーザーや同時接続ユーザーが承認された数や最初に考慮した想定を超える場合は、上位のビットレートを削除することもできます。ただし、これはリスクが高いため、テストしたことがない場合は、ステージング環境で事前にテストしてからライブの本番環境に実装することをおすすめします（その場合、マスター マニフェストのキャッシュ TTL はセグメントの長さよりも短くしてください。短くしない場合、Live Stream API から上位のビットレートを削除したときに 4xx エラーが急増します）。

• パスとセグメントの体系: 送信元のフェイルオーバーのために、GCS バケットへのエンコーダの公開パスやセグメント体系、Vary、ETag、Last-Modified ヘッダーの動作を両方の送信元（プライマリとバックアップ）で統一してください。

Media CDN の構成:

次に重要なのは、フェイルオーバーを管理して最大のキャッシュ パフォーマンスを提供できるように Media CDN を構成することです。

送信元のフェイルオーバー: Media CDN の送信元構成のプライマリ送信元とフェイルオーバー送信元を構成して、次の送信元のフェイルオーバー構成を定義します。

サービス構成: Media CDN のサービス構成において、最適なキャッシュのために次のキャッシュ モードと TTL を定義し、必要に応じてビットレートの段階をその場で変更する柔軟性も定義します。

オブザーバビリティを設定し、イベントに備える

このセクションは、通知、特定、解決の 3 つで構成されています。

通知:

Google Cloud は、通知チャンネルを介してメール、SMS、Slack、Pub/Sub や PagerDuty などにアラート機能を提供していますが、あらゆるインシデントに関する通知を迅速に受け取るには、適切なポリシーを構成することが重要です。

ほとんどの場合、以下の 4 つの指標のトレンドが、インシデントを初期段階で特定するのに役立ちます。

1. 5xx エラーが総リクエスト数の 1% 未満であること

2. 3xx レスポンスが総リクエスト数の 1% 未満であること（サービスでリダイレクトが構成されている場合を除く）

3. 4xx エラーが総リクエスト数の 10% 未満であること（利用できない URL を試行しようとするユーザー、期限切れの署名付きトークンを使用して試行するユーザーなど、ハッキングの試行をするユーザーが該当します）

4. P95 レイテンシが 1 秒未満であること（セグメントの長さと平均再生ビットレートによります）

Google Cloud のアラート機能は、MQL を使用した比率ベースのアラートに対応しています。そこで、以下の MQL を使用して 5xx、4xx、3xx レスポンスに対するアラートを構成します。

コンソールを使用してレイテンシ急増のアラートを構成するか、以下の MQL を使用してレイテンシのアラートを構成できます。

これらの MQL を使用して、以下のようなモニタリング ダッシュボードも作成できます。このダッシュボードは、モニタリング チームが積極的にトレンドをモニタリングし、問題が見つかった場合にサポートケースを報告または登録するのに役立ちます。

特定

Media CDN は、クライアントとエッジ間の各 HTTP リクエストを Cloud Logging に記録します。Media CDN は、ログを準リアルタイムで配信することで独自の強みを発揮します。

• Cloud Logging のログ エクスプローラ機能とクエリ言語を使用して、Media CDN のログを迅速に掘り下げて問題箇所を特定できます。

• リクエストが大量である場合、すべてのリクエストに対してログをキャプチャするのではなく、ログをサンプリングし、予防的なモニタリングと調査のための指標を活用することをおすすめします。

また、ログを保存する前にフィルタする（たとえば、関連するフィールドのみをキャプチャして、保存とクエリが必要なログ容量を減らすなど）には、ログの除外ルールを構成します。これにより、保存前にフィールドを含む（または除外する）クエリ（フィルタ）を定義できます。

また、複数のフィルタを設定することもできます。たとえば、すべてのキャッシュミス リクエストをキャプチャしたり、特定のホスト名に対するすべてのリクエストをキャプチャしたり、前述のようにすべてのログのサンプルだけを取得したりできます。

解決

過去の経験から、多くの問題は構成に関連しており、優れたエンジニアリング チームや DevOps チームが社内で対処してくれます。しかし、トラフィックの多いイベントの重要なフェーズをカバーするための Planned Event Support も欠かせません。Google Cloud の Planned Event Support は次のサービスなどを提供します。

• イベントの前に、Google テクニカル エキスパートがアーキテクチャの基本レビューを行い、割り当てやストレージ容量などの潜在的な問題を事前に特定して解決します。

• イベント中、P1 ケースでは応答時間が短縮され、15 分以内に最初の有意義な回答が返されます。

• イベントが終了すると、パフォーマンス サマリー レポートが提供されます。このレポートには、イベント時のクラウド環境のパフォーマンスに関する遡及的な分析が含まれます。また、今後のイベントを改善するための機会も特定しています。

Planned Event Support の詳細については、担当のアカウント チームまでお問い合わせください。

フォールバック計画のテストと小規模なイベントからの開始

次に、エンドツーエンドでテストを行います。比較的小さなライブイベントから始めましょう。

小規模なイベントから開始する前に、以下をテストして、問題が起こらないことを確認します。

1. プライマリ チェーン コンポーネントのフェイルオーバーを 1 つずつテストし、Media CDN の送信元のフェイルオーバー構成によって再生が中断されないことを確認します。

2. プライマリ エンコーダから上位のビットレートを削除してみてください。以前にマスター マニフェストをダウンロードしたユーザーが上位プロファイルを試行し続け、404 エラーが発生して低いビットレートのプロファイルを試すため、4xx エラーが急増することがあります（これはプレーヤーが適切に対処する必要があります）。

Google Cloud の CDN ポートフォリオ

Google Cloud のエンドツーエンドのコンテンツ配信プラットフォームは、ウェブの高速化、ゲーム、ソーシャル ネットワーク、教育、ビデオ オンデマンド、ライブ配信などさまざまなユースケースに対応しています。Google Cloud のコンテンツ配信プラットフォームは、さらに次のような追加機能で強化されています。

• HTTP/3、QUIC プロトコル

• Transcoder API または Live Stream API などのエコシステム インテグレーション

• Video Stitcher API を介したダイナミック広告挿入または Google CDN による GAM インテグレーション

• Google Cloud オペレーション スイートを介したリアルタイムなロギングとモニタリング

• Cloud Armor による WAF セキュリティ

Google Cloud Media CDN の詳細については、https://cloud.google.com/media-cdn をご覧ください。

お客様事例はこちらをご覧ください。

• Inshorts : Media CDN を使用して重要なリアルタイムの動画コンテンツをインドの果てまで配信する

• U-NEXT: 最新の CDN を使用して数百万人の利用者に動画をストリーミング

• ShareChat: 世界中の非英語話者に向けてスケーラブルでデータドリブンなソーシャル ネットワークを構築

• 17-Media : 急増するライブ配信の需要に対応する

• Tokopedia : Google Kubernetes Engine で大規模なショッピング イベントに対応するスケーリングを実現

• Wix : デザインから開発まで、誰もが必要とする高度なウェブサイトを作成できるように

• Nordeus: スケーラブルなインフラストラクチャで数百万人のユーザーに新しいゲーム体験を提供

- プロダクト マネージャー Prakash Daga

- カスタマー エンジニア Nazir Kabani