Top Trends in Cybersecurity for 2024 | 
ライブスポーツは見るのがエキサイティングである。 特に、試合に勝つためにどこからともなくシュートが出てきたときなど、重要な瞬間に。 これらの瞬間は、流動的でリアルタイムのアクションを提供する技術チームにとっても刺激的である。 スポーツのライブストリームは、いくつかの技術的な考慮事項とトレードオフのバランスを取らなければならず、フィールド上のライブゲームより平均30秒遅れている。 なぜ遅れているのか？
コンテンツ配信ネットワークは不可欠だが、動画ワークフローの他の部分によって引き起こされる遅延を減らすことはできない。 例えば、画像が信号に変換されたときにインジェストした瞬間からレイテンシが追加される。 生の信号は圧縮されたフォーマットに変換され、ビデオ処理センター（通常はオフサイトでしばしばクラウド内）に送信される。 次に、さまざまなデバイスや帯域幅のコンテンツをトランスコーディングしてパッケージ化する。 最後に、ストリームが再生されているとき、広告は、インターネットのラストマイルを通過して視聴者のデバイスに移動する直前に、ストリームに動的に挿入される。 ここでは、プレーヤーのバッファは最終的なビデオセグメントをデコード、解凍、レンダリングする。 これは、チームのゲームを勝ち抜く目標とコンテンツ配信ネットワークの間にある多くのステップである。 特に何百万人もの視聴者が一度に起こる必要がある場合には、それらは合計することができる。 スーパーボウルのライブストリームでのレイテンシは平均28秒から47秒。
遅延の低減は、ストリーミング・サービス・プロバイダーの焦点となっている。 競馬のような瞬時のゲームベットに結び付けられたスポーツでは、ストリームの遅延により、遠隔地の参加者は会場の参加者にとって不利になる。 会場の視聴者やニュースキャスターからのライブツイートは、テレビやライブストリーミングで視聴するファンにとってエキサイティングな瞬間を台無しにすることができる。 そして、スポーツのライブ視聴中に2番目の画面を使用する視聴者が増えているため、ライブの遅延時間を短縮することが、競争力を維持し、優れた視聴体験を提供するための重要な要件になっているのも不思議ではない。
レイテンシーの低減はEdgecast、現Edgio社の注力分野である。 この取り組みには、各処理ステップとライブストリームの配信に関連するその他の要因について、調査と実装が含まれる。 この記事では、レイテンシー削減の1つの特定の側面に関連するもの、つまり、ますます人気の高い低レイテンシー戦略に起因する増加した要求量に当社のコンテンツ配信ネットワークがどのように対処するか、つまりセグメントサイズを縮小する方法について説明する。
ストリーミングサービスプロバイダーは、ライブ配信にかかる時間を短縮するために、HLSまたはDASHセグメントの期間を短縮することを受け入れ始めている。 これによりレイテンシは大幅に減少するが、オーバーヘッドの増加や再バッファリングのリスクの増大などのトレードオフが生じる。 これらのトレードオフが価値があるかどうかは、他のQoE考慮事項と比較してレイテンシに置かれる優先度に完全に依存する。 上記のように、低レイテンシが最優先事項である状況もあれば、パーソナライズされた広告や4Kプログラミングを配信したり、ライブコンテンツを編集したりするために現在のレイテンシレベルを許容できる状況もある。
レイテンシーにおけるセグメントサイズの役割
ストリーミングビデオ業界では長い間アダプティブビットレート（ABR）技術を使用しており、ストリームを複数のビデオセグメントまたはチャンクに分割している。 各セグメントは同じ長さまたはサイズを持つが、異なるビデオ品質レベルまたはビットレートでエンコードされるため、ストリームは新しいセグメントが要求されたときに視聴者の利用可能な帯域幅に適応できる。 主要なABRプロトコルであるAppleのHLSとMPEG-DASHの両方が、セグメントサイズを調整するための制御を提供する。
ライブストリームの再生を開始する前に、あらかじめ設定された数のセグメントをダウンロードしなければならないため、レイテンシーにおいてセグメントサイズが大きな役割を果たす。 これは、クライアントのビデオプレーヤーが十分なビデオをバッファし、ネットワークに輻輳がある場合に再バッファリングすることなくスムーズなビデオ再生を保証できるようにするために行われる。 しかし、これはまた、最初からライブに遅れてストリームを置く。 一般に、iOSデバイスやWebブラウザの埋め込みビデオプレーヤーは、再生を開始する前に3つのビデオセグメントをバッファする。 セグメントの長さが4秒で、再生を開始する前にプレイヤーが3つのセグメントをバッファしなければならない場合、クライアントはすでにライブから12秒遅れている。 DASHプロトコルは、マニフェストファイルがバッファされる必要があるファイルの量を指定できるようにすることで、ある程度の柔軟性を提供する。 それでも、多くのDASHプレイヤーやデバイスはまだこの機能を実装していない。
稼働開始後の時間を短縮する
3つのセグメントのバッファリングはデファクトスタンダードであるため、ライブ後の時間を短縮する最も一般的な手法は、各セグメントのサイズまたはデュレーションを縮小することである。 以下の例では、セグメントサイズを4秒から2秒に縮小することで、ライブの遅延時間はわずか6秒に短縮され、4秒セグメントの半分になる。
セグメントが小さいと再バッファが発生する
セグメントサイズを小さくする場合、バッファのないライブビデオストリーミング体験を提供するために、ビデオワークフローの応答性を高める必要がある。 これは、次の2つの要因によるものである。
まず、セグメントサイズを小さくすることで、一定数のセグメントを格納するプレーヤーが、より少ないビデオを格納するようになった。 また、セグメントサイズが短いほどファイル数が増えるため、動画ワークフローと最も重要なことは、コンテンツ配信ネットワークが、指定されたストリーム期間中にプレーヤーからのファイルリクエストを処理して配信する必要があることである。 ネットワーク輻輳時にプレーヤーにバッファされるビデオが少ないため、輻輳によって再バッファが発生する可能性が高い。 プレイヤーは、より小さな輻輳イベントの間でさえも、輻輳に敏感になる。
第二に、最近の技術記事Optimizing the CDN for Live Streamingで説明したように、ライブスポーツでは人気のイベントが始まったとき、または近いゲームが最後の数分に近づいたときに視聴者が急増するのが一般的である。 ファイル要求の数が増加するにつれて、CDNは同じ時間にさらに多くのファイル要求に対応する必要がある。 このタスクは、適応ビットレートパラメータで指定される様々なデバイスタイプと接続速度によって複合される。
ファイルボリュームの増加を示すために、図2は、異なる長さのセグメントで配信された16秒のビデオセグメントを示している。 4秒のセグメントでは、16秒のセグメントを配信するために必要なファイルは4つだけである。 しかし、2秒のセグメントに移行する場合、8つのファイルが必要になる。つまり、CDNで処理する必要があるファイルの数は2倍になる。
ホットファイリングによりセグメント配信のパフォーマンスを向上
多くのライブ視聴者が同時にストリームに参加したときのいわゆる「フラッシュクラウド」現象に対処するために、Hot Filingという機能を作成した。 この機能は、人気のあるセグメントまたは「ホットファイル」をPOP（Point of Presence）内の追加サーバーに迅速に複製することで、需要が急速に増加したときに視聴者に配信できる。
負荷を多くのサーバに分散することで、Hot Filingはファイル要求が突然急増するため、1つのサーバが圧倒されるのを防ぐ。 DoS攻撃と同様にサーバが過負荷になると、サーバはファイル要求への応答が遅くなり、潜在的にクライアントプレーヤーの再バッファリングにつながる。 ホットファイルを迅速に識別して複製することで、単一サーバーの過負荷のリスクを大幅に低減できる。 急な需要の変化にも遅延なく対応できるようになった。
図3は、ホットファイリング(図3.b)がサーバの過負荷を防止してパフォーマンスを向上させる方法を示している。 ホットファイリングを使用しない場合（図3.a）、セグメントのすべてのトラフィックはサーバ1（S1）に送信される。 視聴者の需要が急増すると、追加のトラフィックがS1に流れ、S1は100ユーザのキャパシティを超える。 状況は悪化し続け、S1はピーク時に200人の視聴者にサービスを提供している。 一方、ホットファイリング(図3.b)は、ファイルを2つのサーバ(S1とS2)に複製し、ファイル要求を新たに利用可能なサーバに再ルーティングすることで、この追加の負荷を処理する。
ホット・ファイルの識別が高速化
最近、ホットファイルを複数のサーバーに移動する時間を1秒短縮することで、ホットファイル処理を強化した。 PoP内でホットファイルを識別する方法を変更することで、応答時間を改善した。 解析のためにファイル要求とバイト数を集約するために中心的なプロセスを使用する。 以前は、データは各サーバ上のWebサーバプロセスからプルされていた。 これは問題なく動作していたが、低速なWebサーバがホットファイルデータの集約を遅くする可能性があることがわかった。 この問題に対処するために、サーバは要求とバイトカウントをディスクに毎秒書き込むようになった。 その結果、中央プロセスがデータを取り出すとき、データはすでにソリッドステートディスクに書き込まれているため、Webサーバプロセスで待つ必要がない。 この変更だけで、ほとんどのライブイベントの負荷に対応できる。
ライブイベントの応答時間を短縮することの重要性を図3.cに示す。このことは、ホットファイリングプロセスがどのように機能して追加リソースを募集するかについての洞察を提供する。 図3.cに示す例では、S1サーバが100ユーザの容量を超えると、容量に達するとファイルがS2にすばやく移動される。 これにより、200人のユーザすべてに迅速かつ効率的に対応し、利用可能なサーバの全容量を使用できる。
複数のポートでのホット・ファイリング
プロサッカーのプレーオフ試合や主要な国際サッカーの試合のような非常に人気のあるイベントでは、トラフィックのスパイクとサージは非常に重要である場合もある。 このレベルの需要を満たすには、サーバ容量を増やすためにファイルセグメントの複製方法を変更する必要もある。 以前は、コンテンツ配信ネットワークはセグメントをサーバごとに1つのポートに複製することに制限されていた。 しかし今では、各サーバの複数のポートにファイルを複製できる。 これにより各サーバのスループットが大幅に向上し、各PoPがより多くのリクエストを処理できるようになり、ライブイベントが以前よりもはるかに大きくなる。
我々のシステムでは、ロードバランシングはCache Array Routing Protocol (CARP)ハッシュによって処理される。 通常のコンテンツでは、複数のサーバー間でファイルを複製するというアプローチを取っており、各サーバーから単一のポートを選択するためにCARPハッシュを使用している。 これは、重複したリクエストがオリジンサーバに送信されないようにし、プロセス間の通信を制限するためである。
ファイルが十分に熱くなると、CARPはサーバごとに複数のポートを選択し、さらに多くのリクエストをサポートする。 このアプローチは、ホットファイルに対してうまく機能する。なぜなら、ホットファイルはサーバーによって提供されるユニークなファイルのごく一部であるからである。 開かれているポートの数は、ホットファイルの要求に依存する。 このアプローチにより、サーバごとに処理されるデータ量と、これらの要求を処理するために使用できるCPU電力量が増加する。
結論
ストリーミング・サービス・プロバイダーが動画セグメントのサイズを縮小して低レイテンシのライブ・ストリームを配信する中、Edgioのプラットフォーム・ホット・ファイリング機能は、特に人気のあるスポーツイベントの視聴者数が増加するにつれて、増加する動画ファイルの要求をコンテンツ・デリバリー・ネットワークが管理するのに役立つ。
