コンテンツ配信ネットワーク（CDN）を置き換えるクロスクラウド動画配信システム

概要

インターネットが誕生した当時、それから数十年後にそこに行き交うデータ量を想像できた人はほとんどいなかったでしょう。インターネットとその最初のプロトコルは、コンピューターAからコンピューターBに、電子メールメッセージのような小さなデータパケットをネットワーク経由で送信するために設計されていました。
今や、インターネットトラフィックの一部を動画が占めるようになり、その流量は他のすべてのコンテンツをはるかに超えています。

Ciscoは、2022年までに82%がインターネットプロトコル（IP） 動画コンテンツで専有されるとし、さらに、インターネット動画、IP VoD、ファイル共有で交換される動画ファイル、ゲームの動画配信、ビデオ会議など、あらゆる形態のIP動画の合計が、IPトラフィック全体の80～90%の範囲で推移すると予測しています［1］。
このようなIP動画トラフィックの増加により、企業は既存のインフラの大幅に変更を伴わない新しいプロトコルを研究開発する必要に迫られました。その結果、ライブ映像のストリーミングであっても、コンテンツ配信ネットワーク（CDN）の能力を最大限活用するために、シンプルなHTTPベースのプロトコルが選ばれたのです。このアプローチは、当初は合理的であったものの、今日ではもはや有効ではありません。
CMAF、低遅延HLS、Appleの低遅延HLS など最新のHTTPベースのプロトコルでは遅延を3秒以下に抑えられないため［2］、ユーザーはライブストリームとのインタラクションができず、Eスポーツ、一般的なスポーツ中継、オークション、ライブイベントといった複数のシナリオで使いものにならないのです。
この遅延の問題を解決する方法は、WebRTCやSRT（Secure Reliable Transport）のような、そもそも非常に低い遅延をゴールに設計された、より洗練されたプロトコルを使用することです。

このコラムではまず、HTTPベースのプロトコルとCDNの組み合わせが、その遅延のために、ライブ動画ストリーミングに関しては将来性がないことを示します。
そして対案として、WebRTCやSRTを使用したクロスクラウド配信システム（CCDS）と、Red5 Proでそれを実装する方法についてご説明します。具体的には、1つまたは複数のクラウドプラットフォーム（プライベートネットワークを含む）を使って相乗効果を発揮させ、世界中のどの地域でも高い信頼性と可用性を備えたデプロイメントを実現する方法をご紹介します。加えて、カスタムセキュリティルールをサポートしながらエンドツーエンドで500ミリ秒以下の遅延でライブストリームを数百万のユーザーに提供する方法もご説明します。

このコラムの目的

ワールドワイドウェブは1989年にティム・バーナーズ・リーによって発明されました。彼はまた、GETメソッドを使ってサーバーからページを読み込むことしかできないHTTPの最初のバージョンも発明しています。その後HTTPの開発はさらに進み、より多くのデータ型がサポートされるようになりました。
HTTPは、クライアントとサーバーの2つのエンティティによるリクエスト-レスポンス・モデルに基づいています。クライアントはサーバーにリクエスト（要求）を送り、サーバーはそれを処理してレスポンス（応答）を提供する。このモデルは、ウェブページの読み込みや電子メールの送信をとても良く処理できる、インターネットの初期段階に適したものでした。このことによってインターネットは拡大し、それをサポートするインフラがどんどん構築されることで、またたく間にHTTPはインターネットの基礎となりました。

過去10年間、インターネットのトラフィックは、図1に示すように、ライブ動画ストリーミングやVODを含むIP動画ソリューションに使われることで急激な伸びを示しました。
当初のアプローチは、既存のHTTPベースのプロトコルとインフラの拡張によって動画コンテンツをサポートすることでした。その理由は、あらゆる種類の HTTPトラフィックの配信を高速化できるコンテンツ配信ネットワーク（CDN）がすでに存在したからです。図2に示すように、IP動画のトラフィックが増加するにつれてCDNの利用も増加しました。
CDNは、世界中に分散するエッジと呼ばれるサーバーで構成される大規模なシステムで、オリジンサーバーからコンテンツをキャッシュし、エッジサーバーに最も近いユーザーにコンテンツを提供しまする。クライアントがCDNに接続するオリジンにリクエストを行うと、リクエストはクライアントに最も近いCDNエッジサーバーにリダイレクトされ、以前にキャッシュされたリクエスト済みのコンテンツが提供されるのです。
このソリューションは、ウェブページのような静的コンテンツやビデオオンデマンド（VOD）サービスに最適です。しかし、ライブ動画のような非常に動的なコンテンツでは、ストリームが届くまでに大きな遅延が起きるために非効率的です。これは、動画用にCDNを使用する場合、システムが最初にビデオをキャッシュする必要があり、そこで不要な遅延が発生するためです。CDNで動作させるのに適したストリーミングプロトコルはいくつかあり、その種類によって遅延の大きさも変わります。
最も一般的なHTTPベースのプロトコルはHLSとMPEG DASHで、遅延は10秒から30秒程度です。その対策として、低遅延HLS、Appleの低遅延HLS、CMAFといったストリーミングプロトコルの最新の改良版が登場しました。

Red5 Proは、これらのプロトコルとWebRTCを比較し、それぞれの長所と短所を調査しました［2］。その結果、上記のプロトコルはHLSやMPEG DASHに比べて大きく改善されたとはいえ、そのエンドツーエンドの遅延は最適な条件下で3秒程度が限界であることが分かりました。

ストリームで許容される最大遅延は、ユースケースによって異なります。例えば、リアルタイム通話および会議の場合、一般に、遅延が200ms（0.2秒！）を超えると体感速度が低下し始めると考えられており、この限界を超えると会話が困難になります［9］。スポーツのライブ中継も同様にデリケートで、視聴者が最も避けたいと思うのは、試合がライブストリーム上では続行中なのに試合結果のプッシュ通知を受け取ってしまうことです。
また、同じイベントでも配信プロバイダーにより遅延が異なる場合、先に結果を知った隣人がスポーツイベントのクライマックスを台無しにすることもあります。現在、ほとんどのスポーツ中継では、意図的に3～6秒の遅延をストリームに組み込んでいますが、スポーツベッティングのライブ中継やスタジアムにいるファンが友人にライブメッセージを送ることで、その数秒さえも体験の弊害となっています。
ギャンブルやオークション業界でもライブストリーミングは受け入れられており、リアルなディーラーを相手にするオンラインカジノが誕生したことで、ディーラーやプレイヤーの各アクションの間の待機時間を短縮してゲームの流れを維持することの重要性が強調されています。
さらに、オークションハウスはオンラインの視覚表現を拡張し、ユーザーはライブストリームを見ながらバーチャルに入札することができるようになりました。論理的には、正しく同期した入札を保証する唯一の方法は、1秒以下の遅延です。

動画ストリーミング業界が低遅延プロトコルに移行しない理由は、コンテンツ配信ネットワーク（CDN）がHTTPに依存する現在のインフラを長年にわたって構築してきたからにほかなりません。技術スタックを根本から見直すのではなく、小さな改善を重ねながら、まあまあの結果が出ることを期待するという、彼らにとっては理にかなったアプローチを選択したのです。

CDNを利用する際に考慮すべき2つ目の側面は、そのカバレッジです。CDNがクライアントにコンテンツを迅速に配信するためには、クライアントにできるだけ近いエッジノードを使用する必要があり、これはライブストリームで遅延を低く保つための基本です。したがって、CDNが世界中にサーバーを設置している場合にのみ、グローバルレベルでの高いパフォーマンスを実現することができますが、現実はそうではありません。ありとあらゆる主要都市にデータセンターを持つ単一のユニバーサルCDNは存在しないのです。
また、中国や南米のような地政学的な地域も配信の課題となっています。効果的なコンテンツ配信のためには複数のCDNネットワークの連携が必要ですが、それを実現するには地域ごとに提供するAPIや価格が大きく異なる事業者それぞれと連携しなければならないことを意味します。

1秒以下の遅延は、真にインタラクティブな映像体験に不可欠な要素です。スケーラブルなリアルタイム遅延を実現するためには、これまでと異なるアプローチが必要です。
これは、HTTPをベースとしたリクエスト-レスポンス型のプロトコルから、WebRTCやSRTのような、大きなデータストリームを最小限の遅延で処理するように設計されたストリーミングプロトコルへの移行を意味します。それだけでなく、CDNから、より効率的でキャッシュを必要としないインフラを構築できる、クラウドプラットフォームベースのソリューションへの移行も必要です。クラウドプラットフォームも、地域により異なる価格で提供され、中国や南米では地政学的な制約を受ける点ではCDNと変わりません。
しかし、重要な違いは、TerraformやKubernetesのようなツールのおかげで、複数のクラウドプラットフォームを連携させるアプローチがよりシンプルになりつつあることです。Terraformはクラウドプラットフォームごとに異なるAPIを1つのAPI（Terraform Cloud API）に抽象化し、Kubernetes はアプリケーションコンテナのクラスターへの展開、スケーリング、運用を自動化するためのプラットフォームとして機能します。また、クラウドプラットフォームを使えば、HTTPベースのストリーミングデータ配信のさらに先を行く機能を実現できます。
例えば、AWSはAWS Transit GatewayにIPマルチキャストのサポートを追加し、データのストリームを複数のインスタンスに同時配信できるようにしました。

このコラムでは、CDNを置き換えるソリューションとしてクロスクラウド配信システム（CCDS）を紹介します。
このソリューションは、Red5 Proをベースに、複数のクラウドプラットフォームを同時に利用し、エンドツーエンドの遅延時間500ms以下でライブストリームを数百万のユーザーに同時配信することで、最高のカバレッジとパフォーマンスを両立します。さらに、このシステムはプライベートネットワークもサポートし、それをクラウドプラットフォームと連携させることも可能で、加えて複雑さを抽象化しながら実装可能なカスタムセキュリティルールもサポートしています。