2026年の FIFA ワールドカップは、放送およびストリーミングプラットフォームを通じて何億人もの視聴者が夢中になると予想されており、わずか数分のダウンタイムでも深刻な影響を及ぼす可能性があります。
最悪の場合、主要イベントのライブストリーミングの失敗は、ソーシャルメディアでの激しい批判、大量のサブスクライバー離脱、大幅な収益損失というドミノにつながりかねません。しかし成功すれば、ライブイベントはビジネス成長に大きな影響を与えます。例えば、Ampere Analysis は、2024年11月に行われたジェイク・ポール対マイク・タイソンのボクシング試合で Netflix が約150万件のサインアップを記録したと推定しています。これは2018年の追跡開始以来最大のサインアップ数と見られています。
大規模なライブストリーミングを担当するエンジニアリングおよびオペレーションチームにとって、最大のリスクは、通常、ビデオ配信そのものではなく、それを取り巻くすべてです。大抵のインシデントは、CDN の帯域幅不足によって引き起こされるのではなく、ストリーム周辺の依存関係によって引き起こされます。
このブログでは、大規模なライブストリーミングイベントの準備で見られるよくあるミスと、それを回避する方法を紹介します。
1. 以前にうまくいったのであれば、イベント規模でもうまくいくはずだという思い込み
よく見られるリスクの一つは、思い込みによって引き起こされるものです。つまり、過去にうまくいったからといって、大規模なイベントでもうまくいくと思い込んでしまうことです。ライブイベントというものは、思い込みで準備するにはあまりにも多くの不確定要素を伴います。以下に、よくあるミスの例をいくつか示します。プライバシー保護のため、詳細については匿名としています。
主要イベントの直前に、新しいワークフローを導入：ある放送局が、年間最大のイベントの直前に新しい制作ワークフローを導入しました。小規模な環境では問題は起きませんでしたが、同時接続数がピークに達すると、予期せぬ動作に見舞われました。
トラフィックパターンが過去の需要と一致するとの思い込み：あるお客様は、大きなイベントが発生する前に、ブラジルからの需要が著しく増加したことを認識しておらず、過去の傾向を信じ切っていたため、トラフィックの急増を予測することができませんでした。
ビデオ配信にばかり焦点を当て、アップストリームの依存関係を見落とす：ある注目度の高いシリーズの立ち上げにおいて、多くのユーザーが認証を通れなかったため、CDN の準備状況に関係なくビデオにアクセスできませんでした。出鼻をくじいたこの問題は、認証を担当する API サービスに起因していました。
デジタル広告の挿入を、不可欠な依存関係としてではなく、単なるアドオンとして扱う：ある大規模イベントでは、収益化に不可欠であるにもかかわらず、DAI ソリューションが大規模負荷テストに含まれていませんでした。ピーク時には、そのことがリスクになりました。
クラウドインフラストラクチャがトラフィックスパイクを自動的に吸収するという思い込み：あるテストの結果、特定のロードバランサーの、急激な負荷変動への反応が鈍いため、最適な性能を発揮するには事前予熱が必要であることが判明しました。
ライブストリーミングは鎖のようなもので、最も弱い部分が視聴体験を左右します。一般的な単一障害点の例には、DNS、マルチ CDN セットアップにおけるグローバルロードバランシング/ステアリング、中間層のシールドレイヤー、およびオリジンリージョンなどがあります。これに加え、認証 API はプレイバックを妨げる重要な依存関係となっています。
2. 容量の計画にトラフィック速度ではなく総帯域幅を重視
ピーク帯域幅の数値はダッシュボード上では強い印象を与えますが、故障の予測指標としては最も信頼度が低いものです。トラフィックが数分でゼロから5Tbpsに急増し、その後も増加を続けることはよくあります。しかし、その増加が均等に分布することはめったにありません。ストリームは通常、グローバルに劣化することはなく、リージョンごとに劣化します。
ある大手放送局のお客様がスポーツ系ストリーミングサービスを開始したとき、最初の試合のトラフィックがチリで予想外に急増しました。この急増は予測されていませんでした。その後、ほとんどのトラフィックが海賊版ストリームであることが判明しました。全体的には健全な状況に見えていたものの、特定の地域では、システムが突発的な集中需要に対応できる必要があったということです。そのため、トラフィックエンジニアリングの調整がリアルタイムで必要となり、その後のイベントに対しては、緩和策が導入されました。
また、マルチ CDN ステアリングによってトラフィックが特定のプロバイダーに偏ってシフトしてしまうケースも確認されています。これは、イベントの規模が予測よりも大きかったからではなく、負荷時にルーティングの挙動が異なったためです。全体的な帯域幅の観点からは、すべて問題ありませんでした。しかし、特定のリージョンおよびプロバイダーごとの視点から見ると、負荷は急速に高まっていました。
システムを破綻させるのは、大量のスループットが続くことよりも、むしろ速度が関係します。マニフェストリクエストやエンタイトルメントチェックの突然の急増は、最初のビデオフレームが再生される前にオリジンを圧倒する可能性があります。
「平均的な全体トラフィック」を前提に計画するのは、間違った失敗モードを計画することになります。容量モデルは、突然の局所的なピークや、トラフィックが必ずしも礼儀正しく振る舞わない現実を考慮しなければなりません。
3. 実際の閲覧者行動をテストする代わりにトラフィックをテストする
大量のリクエスト/秒数の数値を生成するのは簡単です。しかし、大量にいる実際の閲覧者をシミュレートすることは簡単ではありません。
1万人の閲覧者がストリームを視聴するテストを行いたい場合、それは1万件のリクエストをできるだけ早く送信することを意味しません。これは、1万人の独立したプレイヤーをシミュレートし、それぞれの状態を維持し、適切な間隔でマニフェストを取得し、セグメントを順番にリクエストし、Cookie とデバイスの特性を維持しなければならないことを意味します。
これまでのテスト環境では、比較的低い持続的な RPS で事前エンコードされたコンテンツに依存し、VOD スタイルのワークフローを効果的にシミュレートしてきました。一方、ライブストリーミングは異なります。セグメントがエンコーダーによって動的に生成され、レイテンシや計算特性が導入されることを見落としてはなりません。
テストの目標は、単にトラフィックを生成することではなく、実際の閲覧者をシミュレートすることであるべきです。つまり、プレイヤーベースの負荷テスト、静的コンテンツではなくエンコーダーが生成するストリームでのテスト、そしてエンタイトル API から広告挿入、配信までの全ワークフローの検証を意味します。
多くのテストは、スループットとエラー率を測定するだけで合格します。しかし、これらのテストは実際の動作をシミュレートしないため、実情に合わないことがあります。テストの目的は安心感を与えることではなく、インターネットが限界に達する前にシステムがどこで限界を迎えるかを見つけることであるべきです。
4. 成功の準備にかまけて失敗のリハーサルをしない
アーキテクチャのレビューと負荷テストは、潜在的なリスクを浮き彫りにするのに役立ちます。しかし、イベント開催前の数週間において、本当に問われるのはリスクが存在するかどうかではなく、そのリスクが現実のものとなった時にチームが対応できるかどうかです。
優れた机上演習というものは、すべてがうまくいくことを前提とするのではなく、物事がうまくいかないことを想定して行われるものです。オリジンが遅くなってもエラーが出なかったらどうすればよいでしょうか？エンタイトルメントサービスが 403 エラーを頻繁に返し始めたらどうすればよいでしょうか？複数の CDN がその地域の容量限界に近づき、マニフェストから高ビットレートを削除する必要がある場合はどうすればよいでしょうか？
机上演習を行うと、最大の落とし穴はアーキテクチャルなものではなく、組織的なものであることが判明することがよくあります。インシデントを宣言するのは誰でしょうか？外部と連絡を取るのは誰でしょうか？冗長システムはどれくらい早く稼働できるでしょうか？誰も練習していない長い手順書に依存している冗長なコンポーネントは、単一障害点になりかねません。
私たちが見てきた中で唯一かつ真の大失敗は、世界的なスポーツイベントではなく、企業のタウンホールで起きています。この事例では、プライマリエンコーダーが故障し、セカンダリーエンコーダーがすぐに引き継ぐ準備ができていませんでした。そのため、30分を待たずにイベントは事実上中止となりました。これは帯域幅の問題ではなく、エンコーディングチェーン内の単一障害点によって引き起こされた問題でした。
5. 運用体制ではなく英雄的行為に頼る
ライブイベントには運用体制が不可欠です。つまり、イベント開始前に、関係者全員が自分の役割を理解していなければなりません。
問題が発生した際は、明確に決められたインシデントリーダーが全体を指揮し、問題をトリアージし、専門家を割り当て、コミュニケーションを取り続け、1つ1つ解決してゆく必要があります。複数の問題が同時に発生した場合は、それらをリアルタイムでトリアージし、適切なリソースを割り当てることが極めて重要です。
作戦室で最もよくある間違いの一つは、集中力を失うことです。物事が安定しているように見えると、おしゃべりが増えます。特にスポーツイベントは、長時間にわたり、感情的に深く引き込まれるものです。事前および事後カバレッジは数時間に及ぶことがあります。そのため、傍観者モードに陥ることがよくあります。そのような時に、しばしばエッジケースが表面化します。
いくつかの大規模なイベントを私たちがサポートした際、大抵のお客様はすべての主要なベンダーを同じ部屋に配置していました。そうすることで、物理的な近さがベンダー間の協調を加速し、組織間の壁が取り払われるのです。ベンダーが別々の仮想チャネルに孤立していると、コラボレーションは遅々として進まなくなります。
ライブイベントではヒーロー的な行動は報われません。規律のある連携こそが評価されます。
6. ダッシュボードに問題が表示されるまで何もしない
冗長性だけでは安定性は保証されません。結果を変えるのは結局、リアルタイムの可視性と迅速な対応能力です。
私たちはネットワークや ASN レベルでシグナルが現れるのを日常的に目にします。例えば、特定の都市の特定の ISP が速度が落ちることがあります。それも、これらのパターンがより広いダッシュボードに現れる前にです。場合によっては、異常は、エコシステム内の他の場所で広く認識される30秒から90秒前に目に見えることがあります。その初期段階の対応が、問題が封じ込められるか、あるいは拡大するかを左右するのです。
Fastly の Edge Cloud Platform は、ネットワークや地域を超えたリアルタイムの可視性を提供し、オペレーターが新たな問題を迅速に検出し対応できるようにします。
同様に重要なのは敏捷性です。ライブイベント中は、数分以内に調整が必要になる場合があります。例えば、過負荷を引き起こしている地域からのトラフィックをブロックしたり、エラーを引き起こしている予期しない URL パターンを書き換えたり、オリジンタイムアウトを調整したり、意図的にトラフィックをシフトしたりといった対応です。Fastly のプラットフォームなら、このような設定変更を数秒でグローバルにデプロイできるため、オペレーターはライブイベント中に柔軟に対応することができます。
大規模イベントでは、洞察の速さや変更する速さが、ロー容量と同じくらい重要なのです。
最後に
大規模なライブストリーミングの問題は単に帯域幅の問題ではありません。これはシステムの問題です。
これに対応するには、ビデオ以外の依存関係も重要であること、トラフィックの急増は突発的であること、現実的なテストは費用がかかり面倒なものであること、そして規律ある連携がアーキテクチャと同じくらい重要であることを認識する必要があります。
うまくいっているときは、視聴者は配信を視聴し、ダッシュボードは安定してコントロールされ、作戦室は平和そのものになるだけです。しかし、問題が発生したとき、それは物事がうまくいかなかったからではなく、システムが問題を緩和するように設計、テスト、運用されなかったからともいえます。
Fastly では、多くの大規模なライブイベントをサポートしており、入念な準備こをが成功に至る道であることを実感しています。Fastly が大規模なライブストリーミングをどのようにサポートしているかについて、詳しくはこちらをご覧ください。