新規投稿のお知らせを受信されたい方は、サブスクリプションをご登録ください:

ライブ動画がもっと生き生きと同時ストリーミングアクセラレーションの導入

2019-05-16

4分で読了
この投稿はEnglishFrançaisDeutschEspañol简体中文でも表示されます。

今日は、ストリーム配信を利用する際に、Web 上のライブ動画のエンドツーエンドのレイテンシーを短縮するための新しい手法である、同時ストリーミングアクセラレーションの導入をご紹介できることを嬉しく思います。

ライブストリーミングのレイテンシーがなぜそれほど重要なのか、そして、遅延を改善するために、どんな対応が行われてきたのかを掘り下げてみましょう。

「ライブ」動画の「生き生き」感はどのくらい?

ライブストリーミングは、ウェブ上の動画のシェアを増やしています。テレビ放送でもライブゲームショーでも、オンライン講義などでも、ユーザーは動画が迅速でスムーズに到着することを期待しています。そして、「ライブ」が保証することは、ユーザーがイベントで今起きている瞬間を見ているということです。しかし、「リアルタイム」にどれだけ近ければ、インターネット動画は「ライブ」ですか?

インターネット上でのライブ動画配信は依然として_困難_で、多くのレイテンシーが発生します_。_

  1. コンテンツソースは動画を記録し、エンコードサーバーに送信します。

  2. 配信元サーバーは、このビデオを DASH、HLS、CMAF などの形式に変換し、数百万台のデバイスに効率的に配信できます。

  3. CDNは通常、エンコードされた動画を世界中に配信するために使用されます。

  4. クライアントのプレーヤーは、動画をデコードし、スクリーン上でレンダリングします。

そしてこのすべてで時間に制約があり、プロセス全体が数秒で起こる必要があります。さもなければ、ビデオ体験が損なわれることになります。動画が撮影されてからエンドユーザーのデバイスで視聴できるまでの合計遅延を「エンドツーエンドのレイテンシー」と呼びます(カメラのレンズから携帯電話の画面までの時間と考えてください)。

従来のセグメント化された配信

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 つの異なる意味で利用されます。

  1. CMAF、またはHLS チャンク。セグメント(通常は 1秒)の小さな部分で、キーフレームに合わせたもの

  2. 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 を利用する場合は、エンタープライズセールスチームにお問い合わせください

そして、このようなプロジェクトに取り組み、インターネット全体のライブビデオ配信を改善することに興味がある場合は、エンジニアリングチームに参加してください!

Cloudflareは企業ネットワーク全体を保護し、お客様がインターネット規模のアプリケーションを効率的に構築し、あらゆるWebサイトやインターネットアプリケーションを高速化し、DDoS攻撃を退けハッカーの侵入を防ぎゼロトラスト導入を推進できるようお手伝いしています。

ご使用のデバイスから1.1.1.1 にアクセスし、インターネットを高速化し安全性を高めるCloudflareの無料アプリをご利用ください。

より良いインターネットの構築支援という当社の使命について、詳しくはこちらをご覧ください。新たなキャリアの方向性を模索中の方は、当社の求人情報をご覧ください。
Speed WeekCloudflare StreamVideoスピードと信頼性製品ニュース

Xでフォロー

Jon Levine|@jplevine
Cloudflare|@cloudflare

関連ブログ投稿

2024年10月08日 13:00

Cloudflare acquires Kivera to add simple, preventive cloud security to Cloudflare One

The acquisition and integration of Kivera broadens the scope of Cloudflare’s SASE platform beyond just apps, incorporating increased cloud security through proactive configuration management of cloud services. ...

2024年9月27日 13:00

AI Everywhere with the WAF Rule Builder Assistant, Cloudflare Radar AI Insights, and updated AI bot protection

This year for Cloudflare’s birthday, we’ve extended our AI Assistant capabilities to help you build new WAF rules, added new AI bot & crawler traffic insights to Radar, and given customers new AI bot blocking capabilities...

2024年9月26日 13:00

Zero-latency SQLite storage in every Durable Object

Traditional cloud storage is inherently slow because it is accessed over a network and must synchronize many clients. But what if we could instead put your application code deep into the storage layer, such that your code runs where the data is stored? Durable Objects with SQLite do just that. ...

2024年9月26日 13:00

Making Workers AI faster and more efficient: Performance optimization with KV cache compression and speculative decoding

With a new generation of data center accelerator hardware and using optimization techniques such as KV cache compression and speculative decoding, we’ve made large language model (LLM) inference lightning-fast on the Cloudflare Workers AI platform....