【イベントレポート】「ABEMA」のCTOが語る、「FIFA ワールドカップ カタール 2022」配信における5つの技術的挑戦

ライブストリーミング機能は大きく分けて2つのフェーズを通して提供されます。1つは、ユーザーに提供する映像ソースを集約後、制作を通して、視聴者に提供する映像ストリームを組み上げるContributionフェーズ。もう1つが、生み出された映像ストリームの内容自体は変更せずに、様々なデバイスやネットワーク環境を想定した変換処理を実行し、視聴者のデバイスへと映像ストリームを配信していくDistributionフェーズです。

「ABEMA」のContributionの構成を概念レベルで説明すると、まず配信対象となるイベントが行われる会場から始まり、そこから得られる複数の映像ソースを制作拠点まで伝送します。その後、それらを最終的な映像ストリームとして構築し、これらをメインの処理環境であるクラウドまで伝送するところまでがContributionにあたります。Contributionでの考慮事項は、視聴者に至るまでに発生する変換処理を考慮した上で十分な映像品質でデータを取り回すだけでなく、構成上発生しうる障害を考慮した冗長化を施すことです。施設内における機器故障はもちろんのこと、ディザスタリカバリを想定した地理的冗長化も検討する必要があります。

続いて「ABEMA」のDistributionの構成ですが、クラウド上で受けた映像ストリームに対し、まずアダプティブビットレート(ABR)と呼ばれる方式で、トランスコード処理を行います。次に、これらを再生プレイヤーにとって解釈可能な形式にパッケージングするのですが、「ABEMA」が利用しているフォーマットで言うとHLSまたはDASHに変換することを言います。

その後暗号化処理を経て、最終的な調整を行う独自のマニフェストマニピュレーターを通すことで、再生プレイヤーに向けた最終的なデータが完成します。クラウドで行う処理はこれで完了ですが、このデータをCDN及び視聴者のネットワーク環境を経由し、アプリケーション上のプレイヤーまで配信するところまでがDistributionにあたります。

Distributionでの考慮事項は、映像ストリームを変換処理する際に、特定のコンポーネントやロケーションでのトラブルを十分に想定した冗長化を施し、それらが遅延なく継続するだけの安定性を確保することです。また、変換処理が完了した後の配信では、同時に視聴するユーザー及びそのネットワーク的分布を考慮した上で、インターネットを経由して十分に安定した配信ができるだけのキャパシティを確保することも重要です。
 

2つめのスパイクアクセスの制御についてですが、決められた時間に配信されるライブコンテンツでは、配信開始タイミングやSNS上での拡散をきっかけに、瞬間的に非常に大きなアクセスが発生することがあります。昨今パブリッククラウドの規模が拡大し、必要な時に必要なだけのコンピューティングリソースを使用する、水平スケール可能なシステムを構築することは難しくない時代になりました。

しかしながら、こういった急激なスパイクアクセスでは、水平スケール処理が間に合わなかったり、動的なスケール処理を諦めてフルキャパシティで構えることで、非常に大きなコストがかかったりします。スパイクアクセスによるトラブルは、バックエンドに深刻な負荷を発生させ、またそれらが連鎖することでトラブルがより重大な規模に発展することさえあります。そのため、スパイクアクセスを許容する限界を予め決定しておき、それらを制御する仕組みを実装しておくことが重要です。

具体的には単純なレート制限機構を、サイト訪問や起動処理に適用したり、仮想待機室のような待ち受け処理を施すことで、これらの問題に対処することができます。ライブ配信が始まるタイミングにユーザーは視聴開始行動を起こし、CMタイミングなどで離脱したり、他のコンテンツに回遊したりしますが、非常に難しい問題として、これらの行動変化はコンテンツの内容によって生み出されるものです。サッカーで言えば、キックオフやハーフタイムなどの競技上の予め定められたタイミングや、ゴールなどの試合展開によって行動変化が発生します。これら行動変化のタイミングと行動内容を事前に予測し、それらの行動変化にシステムが十分に対応可能か、検証しておくことが重要です。

以上がインターネットで大規模なライブを配信する場合の基本的な構成と考慮事項です。次にW杯に向けてどのように準備してきたのか説明したいと思います。
 

最終的に我々は、品質を重視した映像ストリーム仕様「STRIKER」と、「STRIKER」の仕様に対してデコードや再生の安定性が追いつかないデバイスに向けた映像ストリーム仕様「DEFENDER」を作成しました。そしてこの2つの映像ストリームを、「ABEMA」が対応するデバイスにどのように割り当てるか、注意深く検証していきました。

従来の「ABEMA」のリニア配信機能はマニフェスト上でコンテンツを切り替えることによって、ライブコンテンツ、VODコンテンツをリニア編成型のチャンネルで提供する機能です。「ABEMA PPV ONLINE LIVE」の配信機能は、これをイベントごとに専用のチャンネルとして活用する形で応用し、生み出されました。これらの機能はこれまでの「ABEMA」を支えてきた中核となる機能でしたが、特定のライブイベントを最高品質かつ大規模のユーザーに提供する観点では、いくつか解決することが難しい課題を抱えていました。具体的には、ライブコンテンツごとの最適化を行うために、エンコーダーを変更・調整したり、特定コンテンツのみでストリームの安定性をさらに向上させるなど、コンテンツに特化した対応を施すことが仕組み上難しかったのです。

そのためW杯及び、今後のライブ配信での活用を見据え、ライブイベント配信機能として周辺機能ごと新規に作成することにしました。ライブイベント配信機能では、前述の「地上波レベルの高画質」を実現する新しい配信システムを中心に、それらを複数活用する形でマルチアングル機能を構成しました。周辺機能として、従来のコメント機能をより効率的な処理に組み替え、試合情報としてスタッツ機能を新たに追加しました。

しかしながらこれまでの実績をはるかに上回る負荷が想定されるライブ配信に対して、新規に構築された機能をぶっつけ本番で安定稼働させることは現実的ではありません。そこで我々は、稼働実績とデータを収集するためにW杯前に「ABEMA」で生配信していた「プレミアリーグ」に注目しました。「プレミアリーグ」は最高峰のサッカーコンテンツであり、映像はもちろんのことサッカー視聴におけるユーザー行動の類似性が高く、ありとあらゆる面でW杯に使用するシステムのデータを得るには適したコンテンツでした。新システムによるプレミアリーグの配信にはトラブルの発生の可能性もあったため、従来の番組はそのままに、高機能βといった形で新システムで構成された番組を並行して展開する形でテストを実施しました。

これらの検証では 画質がリアルタイムで狙った通りの品質で表現されているか、そして様々なデバイスで 滞りなく再生されるか、スタッツなどの機能が意図した形で表現されているかなどを重点的にチェックしました。また、配信期間中に起こるイベントに対して ユーザーがどのような行動をとるかをチェックし、想定している負荷シナリオが実際のトラフィックに近いか、その負荷が十分に効率的に実装された結果であるかを確認していきました。「プレミアリーグ」での検証はW杯の開幕直前まで継続し、それまでの配信データの分析と改善によって、準備段階で考慮可能な範囲での信頼性を確保することができました。

さて、マルチデバイスというキーワードが「ABEMA」のコンセプトに存在しますが、そもそも我々は各種ブラウザやAndroidデバイス、iPhone / iPad、テレビ型デバイス、ゲーム機など様々なデバイスにサービスを提供しています。ではなぜW杯においてマルチデバイスがキーワードになったのか。これは、前述の通りほとんどの機能を新規で構築したことと、過去最高品質の画質を提供するために新しい映像ストリームを作成したことに起因します。新規の機能を従来のサポートデバイス全てに対して短期間で展開することは非常に挑戦的な取り組みです。また、新しい映像ストリームを各デバイスで安定して再生可能できるか検証することにも多くの時間を必要とします。「ABEMA」ではマルチデバイスに継続的な機能開発を実施するための共通化や効率化がいくつか存在しますが、正直な話W杯では開幕タイミングでいくつかのデバイスへの対応が間に合いませんでした。最終的に「Nintendo Switch」への提供が11月22日、「AppleTV」への提供が11月27日となりました。

続いて試合のハイライトの最速配信についてですが、我々がライブ配信の他に重要視していたことは、ライブで視聴できなかったユーザーや試合全体を見る時間がないユーザーに対してハイライトをいかに迅速に提供するかという点です。
今回の配信時間帯の多くが深夜から早朝に該当していることもハイライトを重視した要因の1つです。
 

1人あたりのビットレートは、「THE MATCH 2022」における配信実績データ、つまりは現在の出力仕様と実際の解像度取得分布から、ユーザーの視聴環境におけるネットワークパフォーマンスがどれくらい期待できるかで算出します。そのネットワークパフォーマンスに対してW杯における出力仕様から配信時にどのように解像度が分布するか、計算しました。

ピーク時の同時接続数の算出は非常に難しい課題でしたが、過去のW杯の地上波放送時の視聴率データから、対戦カードごとにどれくらいの注目度があるか、そして配信時間帯によってどれくらい変化するかを計算しました。そこから、仮に地上波で放送された場合の視聴率予測を算出しました。これに対し、地上波と「ABEMA」の同時配信時、または「ABEMA」単独配信時における地上波とインターネットでの視聴数比率を算出し、「ABEMA」におけるライブ同時接続数がどうなるかを予測しました。この各試合のピーク時の同時接続数に対し、前述の1人あたりのビットレートを掛け合わせ、定常的に発生する、普段のトラフィックを足し上げることでピークトラフィックを算出しました。

こうして予測されたピークトラフィックに対し、負荷に対する備えとして、機能の優先順位を整理し、コンポーネントごとの負荷係数を割り出しました。さらに、全体のキャパシティを設計するとともに、大規模な負荷試験を実施し、有事の際の流入速度の制限機構やトラフィック消費の制限機構を実装しました。

障害対策では、優先機能の稼働率目標を見直し、不足領域において、クラウド上のリージョンの冗長化やマルチCDNのバランシング・切り替え機構の開発、そして問題発生時の復旧速度の向上を目指しました。攻撃対策においては、エンドポイントが外部に公開されるサブシステムの脆弱性を全面的に精査しなおし、単純なDoS攻撃に対する防御機構の再設定、発生時のオペレーションの構築を行いました。

結果論からすると、これらの対策は開幕タイミングでの完成度は80%程度で、期間中に様々なデータの分析と改善を実施しました。各試合の配信を行いながら、システムの負荷を入念にチェックし、アクセスログを解析し、これまでの準備に用いた計算上の想定から、どれくらい乖離があるかを判断しました。さらにクライアント、サーバー両方の実装上の効率化ポイントを探り、適宜アプリケーションをリリースしていきました。我々にとって幸運だったことは、期間中徐々に視聴ユーザーが増加し、段階的なデータの計測と、改善が成立可能な流れになったことでした。