トランスクリプト
Dincer氏: 今回は、Cloudflareにおける低遅延ビデオストリーミングについてお話します。ビデオストリーミングはブロードキャストの一種であり、データが撮影された現場からマスに向けて送信されます。これを行う一般的な方法は、米国のラジオやケーブルのように、空中の信号を通じて行います。空中を移動する信号について私が興味深いのは、可能な限りすべてのチャンネルにわたるすべてのデータが、視聴者に向けて同時に空中を移動しているということです。視聴者は、見たいものにチャンネルを合わせ、その情報を取得できます。ケーブルテレビと同じように、すべてのデータが常にテレビに流れ、すべてのチャンネルがテレビに流れ、テレビは見たいものにチューニングします。しかし、これがインターネットに移行しつつあります。ある意味、それは素晴らしいことです。なぜなら、パーソナライズされた、より自分にアピールするユニークなコンテンツを手に入れることができるからです。コンテンツのカタログを遡って、2010年の『Keeping Up with the Kardashians』シーズン5を見ることもできます。ライブコンテンツを視聴する場合、カメラからユーザーまでどうやってコンテンツを届けるのでしょうか？サーバー上のMP4ファイルをユーザーがダウンロードして再生することはできません。なぜなら、ライブニュースだとすると、そのMP4を配信するには番組が終わるまで1時間待たなければならないからです。その頃にはニュースは古いニュースになってしまいます。長い間、人々はライブビデオを配信するために独自の方法を作り上げ、そのためのプロトコルはたくさんありました。iOSはQuickTime Media Serverを使用しましたが、カスタムポートの使用、ファイアウォール、スケーラブルなインフラの欠如など、あまり良いものではありませんでした。
HTTPライブストリーミングプロトコル（HLS）
AppleがHTTP Live Streaming、つまりHLSプロトコルを発表したWWDCまで、ほぼ14年前にさかのぼります。HLSプロトコルは、オーディオ、ビデオといったメディアのライブストリーミングプロトコルです。HLSプロトコルには2つの部分があります。サーバーの責任とクライアントの責任です。サーバーの責務は、送られてくるデータをすべて受け取り、数メガバイトの大きさに分割することです。それをディスク上の小さなファイルとして利用できるようにし、サーバーはそれをURL付きのHTTPダウンロードとして利用できるようにします。サーバーはまた、これらのURLをクライアントがダウンロードできるリストにまとめます。クライアントはプレイリストと呼ばれるリストをダウンロードし、サーバーにリクエストするチャンクを選ぶのです。リクエストされたチャンクはビデオプレーヤーに送られ、プレーヤーはその一部をバッファリングし、ユーザーの画面に表示します。あなたが今HLSを使っている可能性は非常に高いでしょう。また、HLS は、ライブストリーミングと録画 VOD ストリーミングの両方において、以前から存在していたものに対して、いくつかの利点があります。2009年、AppleはiPhone 3GSを発表し、モバイルクライアントのインターネット接続速度は現在のように異なっていました。例えば、Edge、3G、Wi-Fiなどです。興味深いのは、HLSが異なる品質レベルを同時に利用できるようにしたことです。携帯電話は、表示するのに便利だと思う品質レベルを選ぶ。例えば、Edgeから3Gに移動すると、より高品質のストリームが表示されます。HTTPライブストリーミング（HLSプロトコル）のもう一つの利点は、ユーザーが再生するためにファイル全体をダウンロードする必要がないことが挙げられます。5時間のビデオの中で、最初の3時間のコンテンツを見ることなく、4時間目まで見ることができます。ダウンロードも必要ありません。HLSでは、オンデマンドで要求される代替音声や字幕を用意することも可能です。繰り返しますが、これらの余計なものをダウンロードする必要はなく、消費することを選択した場合にのみ、そういったものをダウンロードするということです。
HLS は非常にシンプルなプロトコルです。以下は、クライアントがサーバに送信する最初のリクエストの例です。見ての通り、URLは2つほどあり、それぞれ異なる帯域幅の値でタグ付けされています。これは、利用可能な帯域幅が十分でない場合、たとえばモバイル接続がかなり悪い場合でも、コンテンツを音声のみで視聴できることを意味します。これらのURLのいずれかにアクセスすると、このようなものが表示されます。これはスライドウィンドウです。クライアントがこのページを時々更新すると、新しいファイルが追加され、これらのファイルをダウンロードし、ビデオが終了するまでバッファに追加します。HTTPは、HTTPキャッシュ、プロキシサーバー、ファイアウォールといった既存のインフラを通してメディアを配信する素晴らしい方法です。HTTPを使うだけで、中身は関係ないのです。HTTPはまた、この方法でメディアを配信することが非常に安価であることを意味しています。サーバーはステートを保持する必要がなく、ただファイルを提供するだけだからです。既存のソリューションを使って、多くの視聴者に動画を配信するスケールが可能となります。繰り返しになりますが、2009年に開始された当時は、メディア配信ツールの量は、我々がウェブサイトを配信するのに使っていたツールに比べると非常に少なかった背景から、この存在は重大なことでした。HLSやDASHのような同様のプロトコルは、YouTube、Vimeo、TikTok、Instagram、録画、ライブを問わず、今日のオンラインビデオ視聴の方法となっています。
遅延
放送業界の人々は、インターネット経由のライブビデオは従来の放送より劣っていると言うでしょう。なぜなら、ケーブル経由のライブHTTPは、インターネットに相当するものよりレイテンシーが低いからです。彼らは、テレビスポーツは試合が終わる前に隣の人の歓声が聞こえてしまうので、インターネット経由の視聴者にとっては面白くないだろうと言うでしょう。アワードショーは、あなたが見る頃には受賞者がすでにTwitterにアップされているだろうから、楽しみが減るでしょう。テレビのニュースも同じです。これにはいくつかの要因があります。レイテンシーの差はかなり大きく、平均的なHLSストリームは、画面に届くまでにカメラから45秒から30秒程度の遅延が発生します。アメリカの通常のケーブルHTTPは5秒程度です。これは、コンテンツが放送中やケーブル内で常に利用できるわけではないからです。インターネット上では、何らかの双方向通信が必要なのです。インターネット上のパケットはベストエフォートで配信されます。パケットロスの発生、クライアントが利用可能な帯域幅の変動…これらのことを考慮し、コンテンツが途切れることなく表示されるように補正するためにバッファを使用します。さらに、HTTPでのビデオ配信をセットアップする方法はたくさんあり、その多くは非常に複雑です。平均的なセットアップでは、複数のエンコーダーやストレージレイヤーを使うことになります。多くの調整が必要で、複数のベンダーやツールを使っている場合もあるでしょう。様々な分野の知識があり、物事を動かすのは簡単ですが、最適化するのは難しいのです。視聴者がそれぞれ異なるコネクションを持ち、異なる場所にいるかもしれないのに、最適化するのは難しいです。また、視聴者がどこにいるかわからないため、視聴者からのフィードバックを集めるのも難しいでしょう。
新しいアプリケーション
この観点からすると、HLSは従来のインターネット経由の放送と競合しているか、あるいは置き換えようとしているに過ぎなません。そうではなく、もっと興味深いのは、インターネット上で独自に可能なあらゆる可能性だと思います。ここ数年、特にパンデミック以降、クールなウェブネイティブのものがたくさん出てきました。もちろんTwitchは新しいものではありませんが、Twitchは他の人がビデオゲームをプレイするのを見る方法を提供しています。プレイヤーの隣にはチャットルームがあり、視聴者同士や視聴者とチャットができます。ClubhouseやTwitter Spaces、表現が難しいですが、一種のポッドキャストのようなもので、ビデオや音声の会議を挟んで人々が語り合っています。この会議の結果は多くの人に放送されます。Twitter SpacesやClubhouseにいる聴衆の人たちをステージに上げて何かを議論させ、また聴衆に送り返すことができます。これはすべてリモートで行われます。HQトリビアも面白いもので、多くの人がライブストリームを同期して見ていました。彼らは同じコンテンツを見ていて、ゲームショーをプレイし、賞金を稼ぐ。参加者がコンテンツに反応して、その場に戻って貢献することができ、参加者として何が起こっているかを変えることができます。
新しいインフラが必要
このようなユースケースを実現するためには、新しいインフラが必要だと考えます。「ブロードキャストとインタラクトしたい」、あるいは「ブロードキャストになりたい」。視聴者であることと放送の一部であることのこれら2つの役割を飛び越えるため、文脈を見逃さないよう、放送と視聴者の間のレイテンシーを低くする必要があります。マルチテナント・システムに電力を供給するこの新しいインフラは、一度に多くの放送をサポートする必要があります。放送局や視聴者はさまざまな場所にいる可能性があります。アンテナ放送とは異なり、インターネットを介するため、視聴者は世界中に広がる可能性があります。インターネットだから、皆さんは多くの視聴者を獲得したいのかもしれません。もしかしたら、あなたはとても人気があり、この問題を解決するためにシステムを構築する必要があるかもしれない。私が考えるに、これに非常に近いソリューションはテレフォニーです。双方向で、低遅延です。違いはいくつかある。ほとんどの場合、似たようなものです。電話では低遅延を実現できます。システムは多くの電話会話をすることができます。ネットワークは一度に何度も電話で会話することができます。電話の場合、電話をしている人はさまざまな場所にいることができます。一度に何人もの人と電話をしているような電話設定はあまり見かけません。この問題を解決するために、ClubhouseやTwitter Spacesなどが複合的なアプローチを考えました。そのアーキテクチャは次のようなものです。皆さんは世界のどこかに集中型のサーバーを置き、おそらく参加者の多くがいる場所の近くにサーバーを置きたいでしょう。参加者はビデオ会議システムに直接接続し、コンポーザーとエンコーダーに送られ、一般的なHLS配信でコンテンツを出力します。聴衆と参加者の間を飛びたい場合は、システムのビデオ会議に接続し、HLSクライアントを落として、そのまま続けることになります。しかし、それは異なるストリームであり、レイテンシーギャップが発生する可能性があり、かなりの差が生じる可能性があります。より複雑なシステムなのです。
すべての視聴者が非常に低遅延であることを必要とするユースケースは他にもたくさんあります。今ここで示したHLS出力と組み合わせたアプローチとは別に、HLSをまったく使いたくない場合もあります。また、多くの参加者がいるビデオ会議システムを拡張するのは非常に難しいでしょう。ここにいくつかのユースケースがあります。ひとつは、スタジアム内での双方向性で、人々は基本的に遅延ゼロでコンテンツを目で拝見できます。同時に、スタジアムをさまざまな角度から見たり、携帯電話で試合をさまざまな角度から参照できます。非常に低遅延なデータ、メディアデータを配信するアーキテクチャはどのようなものでしょうか？まず始めに、ネットワークからの読み込みとネットワークへの書き込みを妨げるものは何もありません。これは様々な場所で行われています。CDNがHTTPでファイルを保存・転送するように、ディスクからビットを取り出してネットワークに置くことで、ネットワークからビットを取り出して別のネットワークポートに置くことが可能になります。HTTPのCDNとは異なり、配信はステートフルであり、サーバーがクライアントの状態を認識し続ける必要があります。これが課題です。これは以前にも解決した課題です。例えば、レイヤー4でTCPを処理する場合、我々はすでにクライアントの状態を追跡しており、これをスタックアップできない理由はありません。
Cloudflareネットワーク
Cloudflareは世界中に多くのサーバーを配置し、ユーザーから非常に近いところでビジネスを展開しています。歴史的に、これらのサーバーは様々なことができます。ウェブサイトの前に設置すれば、HTTPプロキシとして機能します。コンテンツを配信するためのHTTPキャッシュを提供します。セキュリティ上の脅威を検知し、ブロックもできます。有名なところでは、DDoS攻撃を緩和することが挙げられます。我々はまた、エッジコンピュートプラットフォームも運営しており、これらすべての場所でJavaScriptを実行し、ユーザーのすぐ近くで計算を行うことができます。Cloudflareのアーキテクチャで興味深いのは、Cloudflareが提供するすべてのサービスが、すべてのサーバーで同時に実行されることです。1.1.1.1でDNSレスポンスを提供し、ウェブサイトのHTTPコンテンツを提供しているマシンは、同時に他のことも行っている可能性があります。ファイアウォールを動かしているかもしれないし、今回のケースでは、ビデオトラフィックを配信しているかもしれません。このアーキテクチャでは、新しいポートを開いて新しいサービスを実行し、そのポートをリッスンすればよいからです。サービスが何をするにしても、HTTPアプリケーションかもしれないし、他のプロトコルかもしれません。開いたポートでTCPやUDPをリッスンし、やりたいことができます。低レイテンシーを追求するために、この設定を使ったシンプルなアーキテクチャを考えました。ここではサービスを作りました。このサービスは、メディアをCloudflareのネットワークに転送し、視聴者に向けて再生します。視聴者は最も近い場所に接続し、放送局は最も近い場所に接続する。私たちはこの2つを結びつけた。これがスケールするにつれて、繰り返しますが、これには複雑なことは何もなく、あるポートから別のポートにビットが流れるだけです。放送局とサーバー、そして視聴者とサーバー間の通信は、後で説明する既存のプロトコルに依存しています。新しい視聴者がここに加わり、再生したい場合、パリのサーバーはニュージャージーに連絡を取り、ビットを取得します。ここでも、重要なのは光速の遅延だけです。もう一人、今度はカリフォルニアの視聴者が加わると、興味深いことが起こります。カリフォルニアで利用可能なものは何でも、重複排除して、この新しい視聴者が上陸したサーバーにフィードバックし、その視聴者に送ることができます。システムの規模が大きくなればなるほど、視聴者がすでに別の視聴者にサービスを提供しているサーバーにリクエストを出す可能性が高くなります。そのサーバーのインメモリーで重複排除できるため、さらに簡単になります。
流れはこうです。サーバーは自分自身に、サーバーに何があるか、サーバーに何があるかを確認します。次に、同じデータセンター内にあるかどうかを確認します。そして、同じリージョンにあるかと確認します。もしそうでなければ、ソースサーバーに行き、そこからストリームを取得します。このフローで興味深いのは、すべてのビデオストリームについて、固有のツリー構造が形成されることです。同時に2つのストリームがあった場合、それらは非常にユニークなアクセスパターンを持つことになります。なぜなら、再生するサービスもコンテンツをインジェストできるからです。ビデオ視聴者や放送事業者は、どのサーバーにどのようにルーティングされ、どのように決定されるでしょうか？Cloudflareのレイヤー4ロードバランサーについてのブログ記事がありますが、我々はそれを使っているだけに過ぎません。いくつかのパラメータによってマシン間のロードバランスをとるだけですが、その多くはCPUです。多くの場合、コンテンツを取り込むために中央集中型のサーバーを使用し、コンテンツを配信するために多数のサーバーを使用します。これは理にかなっています。なぜなら、多数の放送局よりも多数の視聴者がいる可能性が高いからです。1つのセットアップで、視聴者がゼロでも多数の放送局を持ちます。他のシステムは、やはり再生とインジェストを同じサーバーに置かない、より厳格な構造を持つ必要がありました。例えば、よりローカルなサーバーを下位層とし、より地域的なサーバーをコンテンツを配信する上位層とすることができます。多くの場合、これは良い選択かもしれませんが、データを特定の国に置いておきたいとか、レイテンシーを最小にしたいといった要件がある場合は、これは良い選択でしょう。私たちのセットアップは、コンテンツが1つのデータセンターで超ローカルに保存できるため、良い選択です。1つのデータセンターで管理できるのですから。
このシステムを構築する際、我々はKafkaテクノロジーを多用しています。ここにあるものはすべてオープンソースか、我々が販売しているCloudflare製品です。例えば、どのサーバーが特定のストリームを持っているかを追跡するために、Durable Objectsを使っています。これはトランザクション可能なデータストアで、トランザクションを行い、物事を追跡できます。このデータストアは、自分自身へのレイテンシーを最小化するために、世界中のデータストアとのインタラクションに応じて動き回ります。もうひとつ興味深いのは、グレースフルアップグレードです。これについては、またブログ記事があります。マルチテナント環境では、ライブストリームがどれくらいの長さになるかわからないからです。なぜなら、ライブストリームがどれくらいの期間続くかわからないからです。そこからコネクションを流出させたい場合、ライブストリームのコネクションが終了するまで数週間以上待たなければならないかもしれません。Cloudflareのソリューションでは、ポートでリッスンするサービスを用意し、このサービスが新しいバージョンのサービスにエクゼキューションすします。そして、セッション記述子が新しいバイナリに渡されます。ステートもexec後に実行される新しいバイナリに渡されます。数秒しかありません。これは数ミリ秒しかかからないので、ビデオトラフィックが中断されることはありません。
ビデオプロトコル
ビデオプロトコルが話題になっています。それらはたくさんあり、多くの議論が交わされています。ビデオプロトコルには、レイテンシー、品質、互換性など、多くのトレードオフがあります。HLSは明らかに品質と互換性を優先していますが、いくつかの選択肢があります。我々はRTMP、SRT、WebRTCをサポートしています。サービス内部での活動は非常にシンプルで、いくつものプロトコルをサポートができます。なぜなら、プロトコルがUDPパケットまたはTCPセッションとしてサービスに入った直後に、これらのプロトコル内部で送信されるものを受け取り、配信前にポートオーバーまたは保存できる共通のフォーマットに変換するからです。例えば、この例ではSRT、RTMP、WHEPがリーダーに送られてくるのがわかります。また、Cloudflareの通常のHLS配信はすべてこのようにシステム内で処理され、共通のフォーマットからセグメンターがリーダーをリッスンしています。SRTやRTMP、WHEPをHLSやDASHに変換し、より互換性のある出力を提供もできます。これらは、システムにそれほどコストをかけることなく、同時に実行できます。誰かがその特定のプロトコルを聞きに来るたびに、その時だけライターが動作し、残りのシステムが動作します。システムは入力を読み取る以外は何もせず、ライターなしでループするだけです。
WebRTCについても少し話しましょう。WebRTCは非常に興味深いもので、IETFではWebRTC上のブロードキャストを標準化するための強力な取り組みが行われています。そうではありません。WebRTCは非常に柔軟です。WebRTCはまた、HLSのように複数の品質レベルを同時にサポートする唯一のプロトコルでもあります。WebRTCでは、品質レベルの選択はクライアント側ではなく、サーバー側で行われます。これら全てのプロトコルを一箇所にまとめ、メディアが入った直後から出る直前まで共通のフォーマットを使用することで、フォーマット間の互換性を維持し、新しいものを追加したり、変更したりすることが非常に簡単にできるようになりました。
結論
私は、これは素晴らしいアイデアだと思います。しかし、何かが現実になることは、アイデアと現実の間のすべての問題を解決するために誰かが取り組んだことを意味するので、より素晴らしいとも思います。多くの同僚がこれに取り組んできましたし、私とはあまり交流のない多くの同僚が、レイヤー4のロードバランサーやKafkaアーキテクチャ全般など、私が言及したコンポーネントに取り組んできました。今日からこれを使うことができます。ここに、コンテンツをプッシュしたりプルしたりできる2つのURL、SRT URLの実用例があります。