今日は、ストリーム配信を利用する際に、Web 上のライブ動画のエンドツーエンドのレイテンシーを短縮するための新しい手法である、同時ストリーミングアクセラレーションの導入をご紹介できることを嬉しく思います。
ライブストリーミングのレイテンシーがなぜそれほど重要なのか、そして、遅延を改善するために、どんな対応が行われてきたのかを掘り下げてみましょう。
「ライブ」動画の「生き生き」感はどのくらい？
ライブストリーミングは、ウェブ上の動画のシェアを増やしています。テレビ放送でもライブゲームショーでも、オンライン講義などでも、ユーザーは動画が迅速でスムーズに到着することを期待しています。そして、「ライブ」が保証することは、ユーザーがイベントで今起きている瞬間を見ているということです。しかし、「リアルタイム」にどれだけ近ければ、インターネット動画は「ライブ」ですか?
インターネット上でのライブ動画配信は依然として_困難_で、多くのレイテンシーが発生します_。_
コンテンツソースは動画を記録し、エンコードサーバーに送信します。
配信元サーバーは、このビデオを DASH、HLS、CMAF などの形式に変換し、数百万台のデバイスに効率的に配信できます。
CDNは通常、エンコードされた動画を世界中に配信するために使用されます。
クライアントのプレーヤーは、動画をデコードし、スクリーン上でレンダリングします。
そしてこのすべてで時間に制約があり、プロセス全体が数秒で起こる必要があります。さもなければ、ビデオ体験が損なわれることになります。動画が撮影されてからエンドユーザーのデバイスで視聴できるまでの合計遅延を「エンドツーエンドのレイテンシー」と呼びます（カメラのレンズから携帯電話の画面までの時間と考えてください）。
従来のセグメント化された配信
DASH、HLS、CMAF などの動画フォーマットは、動画を「セグメント」と呼ばれる小さなファイルに分割することで機能します。一般的なセグメントの持続時間は 6 秒です。
クライアントのプレーヤーが6秒のセグメント全体がエンコードされ、CDN 経由で送信され、デコードされるまで待機する必要があるとすると、長い待機時間となることがあります。クライアントがセグメントのバッファを構築して配信の中断を防ぐ場合は、さらに時間がかかります。HLS の一般的なプレーヤーバッファは、次の3 つのセグメントです。
_Clients may have to buffer three 6-second chunks, introducing at least 18s of latency_
クライアントは 3つの6秒間のチャンクをバッファリングする必要があり、少なくとも 18秒のレイテンシーが発生する可能性があります。
エンコードの遅延を考慮すると、インターネット上のライブストリーミングのレイテンシーが通常約 20 ~ 30 秒であった理由がよく分かります。当社はこれを向上させます。
チャンク転送エンコードによるレイテンシー短縮
この問題を解決する自然な方法は、クライアントのプレイヤーがダウンロード中、または作成中でもチャンクの再生を開始できるようにすることです。これを可能にするには、「チャンク・エンコーディング」と呼ばれる特別な方法でファイルをエンコードして配信するためにちょっと気の利いた連携が必要です。 これには、セグメントを小さな「一口サイズ」または「チャンク(塊)」に分割することが必要です。チャンクエンコーディングにより、ライブのレイテンシーを5秒または10 秒に低下させることができます。
分かりにくいのですが、「チャンク」という言葉は、次の 2 つの異なる意味で利用されます。
CMAF、またはHLS チャンク。セグメント（通常は 1秒）の小さな部分で、キーフレームに合わせたもの
HTTP チャンク。Web 経由で任意のファイルを配信する方法
チャンクエンコーディングはセグメントを短いチャンクに分割する
Webクライアントはデータストリームを処理する能力が限られているため、HTTP チャンクは重要です。クライアントのほとんどは、完全なHTTP 応答を受信した後か、少なくとも完全な HTTP チャンクを受け取った後にだけデータの操作ができます。HTTPチャンク転送エンコードを使用することで、動画プレーヤーが動画の解析とデコードを早く開始できるようになります。
デコーダーが実際にHTTPチャンク内のビットを_再生するために、_CMAFチャンクは_重要です。_慎重に動画をエンコードしないと、デコーダーは再生できない動画ファイルのランダムビットを持つことになります。
CDNが追加のバッファリングを実施
HLSとCMAF を使用したチャンクエンコーディングは今日、Web全体で使用されています。このテクニックが優れたものとなるのは、HTTPチャンクエンコーディングがCDNで広くサポートされているためです。これは20年に渡り、HTTPスペックの一部でした。
CDNのサポートで、レイテンシーの低いライブ動画をスケールアップし、数千人または数百万人の同時視聴者にリーチできるため、現在はHTTP以外の他のプロトコルでは非常に困難です。
残念ながら、チャンク化を有効にして配信を最適化しても、セグメント全体をバッファリングして、CDN が有害な動作をしている可能性があります。なぜかを理解するには、多くのユーザーが同時にライブセグメントを要求した場合に何が起こるかを考えてみてください。
ファイルがすでにキャッシュにあれば素晴らしい！CDNは、キャッシュファイルを非常に多数の対象ユーザーに配信する際に有用です。しかし、セグメントがまだキャッシュにない場合はどうなりますか?そしてご存知の通りこれはライブ動画の典型的なリクエストパターンです。
通常、CDN は配信元から「キャッシュミス時にストリーミング」ができます。図にすると次のようになります。
繰り返しますが、複数のユーザーが一度にファイルを要求するとどうなりますか?CDNは通常、追加のビューアにサービスを提供する前に、ファイル全体がキャッシュに取り込まれる必要があります。
動画をストリーミングできるビューアは 1 つだけで、他のクライアントは CDNでセグメントがバッファリングされるのを待ちます。
この動作は理解できます。CDNデータセンターは、多くのサーバーで構成されています。配信元のオーバーロードを避けるために、これらのサーバーは通常、1 つのサーバーだけが特定の時点で特定のファイルを配信元から要求できるようにする"キャッシュロック"(mutex)を使用して、その間で調整します。副作用的としては、ファイルがキャッシュに取り込まれている間は、ファイルを要求した最初のユーザー以外のユーザーに提供できないことです。残念ながら、このキャッシュロックもチャンクエンコーディングを使用する目的にそぐわないものです！
ここまでざっと振り返りましょう。
チャンクエンコーディングは、動画セグメントを小さな部分に分割する
これにより、配信元サーバでセグメントが生成されている場合でも、プレーヤーがチャンクをフェッチし、デコードできるようにすることで、エンドツーエンドのレイテンシーを短縮できる
一部のCDNは、クライアントに配信する前に CDN内のファイル全体をバッファリングすることで、エンコーディングの利点を中和してしまいます
Cloudflareの解決策:同時ストリーミングアクセラレーション
ご推測のとおり、当社はもう少しうまくできると考えています。簡単に言うと、キャッシュされていないファイルを複数のクライアントに同時に配信し、配信元サーバーからファイルを 1 回取り込むことができるようになったのです。
シンプルな変更のように聞こえますが、これを安全に行うには繊細な作業がたくさんがあります。見えないところで、キャッシュロックを削除し、ファイルが書き込み中に一つのファイルから複数のクライアントが安全に読み込めるようにして、当社のキャッシュインフラストラクチャに重大な変化をもたらしました。
一番嬉しいことは、Cloudflare全体がこの方法で進めているということです！オプトインする必要もなければ、効果を得るために構成を変更する必要もありません。
当社は二ヶ月ほど前にこの機能を発表し、これまでの結果に本当に満足しています。「キャッシュロック待ち時間」つまり、ある要求が他の要求を待つ必要がある時間（Tiime To First Byteの直接コンポーネント）によって成功を測ります。 OTTのお客様が、このメトリックが P99の1.5からほぼ0に低下するのを見ました。
これは、エンドツーエンドのレイテンシーで1.5秒の改善が直接変換されます。ライブ動画がもっと生き生きとします。
最後に
チャンクエンコーディングなどの新しいテクニックはライブ配信に革命をもたらし、サイトの所有者は低レイテンシーのライブ動画を大規模に配信できます。同時ストリーミングアクセラレーションは、CDNでこの技術の利点を引き出すのに役立ち、エンドツーエンドレイテンシーの貴重な数秒を短縮する可能性を持っています。
ライブ動画配信に Cloudflare を利用する場合は、エンタープライズセールスチームにお問い合わせください。
そして、このようなプロジェクトに取り組み、インターネット全体のライブビデオ配信を改善することに興味がある場合は、エンジニアリングチームに参加してください!