「コントリビューション」「ディストリビューション」 ライブストリーミング機能の2つのフェーズ
西尾亮太氏：こんにちは。AbemaTV CTOの西尾です。「ABEMA Developer Conference 2023」をご視聴いただき、ありがとうございます。本セッションでは「FIFA ワールドカップ 2022における、ABEMAの技術的挑戦」と題して、全64試合無料生中継を完遂した「ABEMA」の技術組織が、準備段階から何を考え、どのように向き合ってきたのかについてお話できればと思います。
あらためて、「FIFAワールドカップ 2022」は、2022年11月21日にスタートして、12月19日までの約1ヶ月間にわたって進行されました。ABEMAでは全64試合をインターネット配信し、日本対クロアチア戦における入場制限を除けば、おおむね大きなトラブルもなく、安定かつ高画質な視聴体験をユーザーに提供できたと考えています。
さて、世界的なスポーツイベントであるワールドカップにABEMAがどのような技術を駆使し、対応したのか。その理解を深めるために、まずはインターネットで大規模なライブを配信する場合の基本的な構成と、考慮事項について説明したいと思います。
インターネットを通してユーザーにさまざまなデバイスでライブ視聴を楽しんでもらう場合、主に映像データ自体をユーザーにどう届けるかという「ライブストリーミング機能」と、デバイス上でその映像データの視聴に至るまでのUIやユーザー認証、視聴以外の付加価値を提供する「サービス機能」をどのように構成するかを考える必要があります。
ライブストリーミング機能は大きく分けて、ユーザーに提供する映像ソースを集約後、制作を通して視聴者に提供する映像ストリームを組み上げる「コントリビューション」と、生み出された映像ストリームの内容自体は変更せずに、さまざまなデバイスやネットワーク環境を想定した変換処理を実行し、視聴者のデバイスへと映像ストリームを配信していく「ディストリビューション」の2つのフェーズを通して提供されます。
コントリビューションの構成
ABEMAのコントリビューションの構成を概念レベルで説明します。まず、配信対象となるイベントが行われる会場から複数の映像ソースを制作拠点まで伝送します。その後、それらを最終的な映像ストリームとして構築し、メインの処理環境であるクラウドまで伝送する。ここまでがコントリビューションにあたります。
コントリビューションでの考慮事項は、視聴者に至るまでに発生する変換処理を考慮した上で、十分な映像品質でデータを取り回し、なおかつ構成上発生しうる障害を考慮した冗長化を施すことです。施設内における機器故障はもちろんのこと、ディザスタリカバリを想定した地理的冗長化も検討する必要があります。
ディストリビューションの構成
ABEMAのディストリビューションの構成を概念レベルで説明します。クラウド上で受けた映像ストリームを、アダプティブビットレートと呼ばれる方式でトランスコード処理します。
次に、これらを再生プレイヤーにとって解釈可能な形式にパッケージング、ABEMAが利用しているフォーマットでいうと、HLSまたはDASHに変換して、その後、暗号化処理を経て最終的な調整を行う独自のマニフェストマニピュレーターを通して、再生プレイヤーに向けた最終的なデータが完成します。
クラウドで行う処理はこれで完了ですが、このデータをCDNおよび視聴者のネットワーク環境を経由してアプリケーション上のプレイヤーまで配信するところまでがディストリビューションにあたります。ディストリビューションでの考慮事項は、映像ストリームを変換処理する際に特定のコンポーネントやロケーションでのトラブルを十分に想定した冗長化を施し、それらが遅延なく継続するだけの安定性を確保することです。
また、変換処理が完了したあとの配信は、同時に視聴するユーザーおよびそのネットワーク的分布を考慮した上で、インターネットを経由して十分に安定した配信ができるだけのキャパシティを確保することが重要です。
ライブストリーミング以外のすべてであるサービス機能に求められること
もう1つの観点であるサービス機能は、言ってしまえばWebサービスを提供する上でのライブストリーミング以外のすべての機能にあたります。サービスを提供する上で大前提となる、例えばWebサイト、認証、コンテンツカタログ、ライブコンテンツの視聴体験を豊かにするマルチアングル、コメント、スタッツ、プラットフォーム上のユーザーの行動を計測して分析するためのログの受信APIおよびデータ基盤などが該当します。ABEMAでは、これらのほぼすべてがパブリッククラウド上に展開されています。
サービス機能には、変動するユーザーアクセスに応じたスケール性の担保や、クラウド上での冗長化、キャパシティプランニングなどが当然必要です。特に大規模ライブ配信においては、視聴における前提機能の最適化、スパイクアクセスの制御、ライブ視聴ユーザーの行動予測という大きく3つの考慮事項があります。
考慮事項1 視聴における前提機能の最適化
1つ目の「視聴における前提機能の最適化」についてお話しします。実際にユーザーがサービス上でライブ配信を視聴開始するまでにいくつかのステップがあります。
ユーザーはアプリケーションを起動して、表示されたコンテンツカタログから対象のイベントを選択して、その後視聴開始アクションを実行します。この単純な過程の中も、アプリケーションの内部に多くのAPIを直列または並列に呼び出すことで実現されています。
これらのアプリケーション上におけるAPIの呼び出しで、本当に必要なもののみをシーケンス上で直列かつ、失敗した場合にアプリケーション上での重大なエラーとして取り扱い、そうではないものが高負荷や障害により応答不可になったり、フィーチャーフラグ上で停止された場合でも視聴開始に影響が出たりしないように統制していくことが重要です。
この「本当に必要なもの」に該当する機能は、想定される負荷に対して愚直に処理可能なキャパシティを確実に確保する必要があります。また、想定されるあらゆるトラブルに対して、可能な限りの耐障害性を持つことや、復旧時間を短縮することが求められます。
考慮事項2 スパイクアクセスの制御
2つ目の「スパイクアクセスの制御」ですが、決められた時間に配信されるライブコンテンツでは、配信開始タイミングやSNS上での拡散をきっかけに瞬間的に非常に大きなアクセスが発生することがあります。昨今はパブリッククラウドでの規模が拡大し、必要な時に必要なだけのコンピューティングリソースを使用する、水平スケール可能なシステムを構築することが難しくない時代になりました。
しかし、こういった急激なスパイクアクセスでは、水平スケール処理が間に合わなかったり、動的なスケール処理を諦めてフルキャパシティで構えることで非常に大きなコストがかかってしまいます。スパイクアクセスによるトラブルは、バックエンドに深刻な負荷を発生させ、それらが連鎖することでトラブルがより重大な規模に発展することさえあります。
そのため、スパイクアクセスを許容する限界を予め決定しておき、それらを制御する仕組みを実装しておくことが重要です。具体的には、単純なレート制限機構をサイト訪問や起動処理に適用したり、仮想待機室のような待ち受け処理を施すことで、これらの問題に対処できます。
考慮事項3 ライブ視聴ユーザーの行動予測
3つ目の「ライブ視聴ユーザーの行動予測」については、仮に大規模ライブ配信を行うサービスがライブ配信以外のオンデマンド配信を提供している場合、ライブ視聴ユーザーの行動はふだん観測されるユーザー行動とはまったく異なるものになることを想定しなければなりません。ライブ配信では、ユーザーはなにかをきっかけに同じタイミングで行動を起こします。
わかりやすい例を挙げると、ライブ配信が始まるタイミングにユーザーは視聴開始行動を起こし、CMタイミングなどで離脱したり、他のコンテンツに回遊したりします。そして非常に難しい問題として、これらの行動変化はコンテンツの内容、つまりサッカーの内容で言えば、キックオフやハーフタイムなどの競技上の予め定められたタイミングや、ゴールなどの試合展開によって生み出されるタイミングでも発生します。
これらの行動変化のタイミングと行動内容を事前に予測し、それらの行動変化にシステムが十分に対応可能かを検証しておくことが重要です。
以上がインターネットで大規模なライブを配信する場合の基本的な構成と考慮事項です。
（次回へつづく）
