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

設計概要

Red5 Proは、入力/出力の両方でWebRTCとSRTをサポートし、RTMP、HLS、RTSP、MPEG-TSなど他のプロトコルにも対応した、スケーラブルなライブストリーミングアプリケーションを開発するためのプラットフォームです。また、CDNではなく、クラウドベースのクラスタリングアーキテクチャを採用しています。これにより、500ms以下のエンドツーエンドの遅延を達成し、数百万人の同時ユーザーをサポートすることが弊社のライブデモで実証されています［3］。

WebRTCは、アプリケーションにリアルタイム通信機能を追加するための、フリーかつオープンソースの標準として構築されたプロトコルです。WebRTCは、3つのチャネルを使用して、ピア間で動画、オーディオ、汎用データを配信し、エンドツーエンドのデータ暗号化のためにDTLSとSRTPを使ったセキュリティが組み込まれています。WebRTCは、リアルタイムの動画ストリーミングに不可欠なUDP配信を使用することで、非常に低い遅延を保証しています。WebRTCの最大の利点の1つは、事実上すべてのモダンなウェブブラウザが対応していることです。

SRTは、もともとHaivisionによって開発されたUDPベースのオープンソーストランスポートプロトコルで、トランスポートエンドポイント間のリアルタイムのネットワーク状況に動的に適応することによって、不確定要素が多いネットワーク上のストリーミングパフォーマンスを最適化します。このプロトコルは、あらゆる種類のデータを転送できますが、特にオーディオと動画のストリーミングに最適化されています。
SRTは、ノイズの多いネットワーク上の輻輳によるジッターや帯域幅の変動を補正し、エラーリカバリーメカニズムによりパケットロスを最小化します。WebRTCと同様に、SRTはAESによるエンドツーエンドの暗号化をサポートしています［10］。SRTは、エンコーダー内蔵の低遅延トランスポートとして魅力的なプロトコルであるため、ハードウェアビデオエンコーダメーカーの間で広く採用されています。

Red5 Pro は、Red5 Proクラスターを複数のクラウドプラットフォーム上にデプロイして構成された高可用性（HA）デプロイメントを活用することで、500ms以下のエンドツーエンド遅延と数百万の同時接続ユーザーをサポートします。図3にクラスターのサンプル図を示します。

Red5 Proクラスターでは、各サーバーがオリジン、リレー、エッジのいずれのノードにもなり得ます。オリジンノードはインジェストに使用され、エッジノードはイグレスに使用されます。各オリジンサーバーは複数のエッジサーバーと通信し、数千人のユーザーをサポートすることができます。
リレーノードは、オリジンからストリームを受信し、それを複数のエッジに中継するもので、クラスターをさらに拡張し、数百万人のユーザーをサポートできるようにするために大規模な実装で使用されます。システムの各ノードは、比較的低消費電力のクラウドベースの仮想マシン上にデプロイすることができます。そのため、Red5 Proは高価で高性能なマシンを使用せずに水平方向に拡張することで高可用性を実現し、あらゆるクラウドプラットフォームに簡単に導入することができます。

Red5 Proのクラスターは、Cloud Controllerの管理下にある複数のStream Managerによって制御され、永続的なストレージとしてデータベースを使用します。Stream Managerはクラスターと対話するためのAPIを提供し、ノードの管理、ロードバランシング、何らかの理由で障害が発生した場合の交換を行うことができます。Stream Managerは、パブリッシャーがオリジンに接続してパブリッシュしたり、サブスクライバーが自分の近くにあるエッジを取得して再生したりする際にも使われます。
図4は、Stream Managerを備えたRed5 Proクラスターのサンプル図です。図5に示す自動スケーリング機能により、Stream Managerはネットワーク上の負荷を制御し、ユーザーの介入を必要とせずに、現在の負荷に基づいて新しいインスタンスをスピンアップまたはダウンさせることができます。短時間に接続数が急増することが事前に分かっているイベントの場合、Stream ManagerのScheduling APIを使ってクラスターを準備またはスケールアップし、イベント開始時までにはスケールアップが確実に完了するようにできます。

Stream Managerとノード間のインタラクションには、Stream Managerの抽象的なコマンドを各プラットフォームの実際のAPIコールに変換するCloud Controllerを使用します。Red5 Proでは、AWS、Google Cloud Platform、Microsoft Azureそれぞれに特化したカスタムCloud Controllerを提供しています。
また、Terraform Cloud Controllerを使えば、上述のプラットフォームに加え、Terraformがサポートするその他のプラットフォームを利用することも可能です。Terraformは各クラウドプラットフォームのAPIをTerraform Cloud APIで抽象化し、バックエンドではTerraformプロバイダを使ってクラウドプラットフォームとの通信を行います。このように、Stream Manager が単一のCloud Controllerを使ってTerraformと通信することで、Terraformがプロバイダを持つ200以上のクラウドプラットフォームに自動的に対応することができます［1］。
図6は、Stream Managerがクラウドプラットフォームと直接やり取りする場合と、TerraformのCloud Controllerを利用する場合の違いを示しています。Terraformを利用することで、プライベートネットワークを含む複数のCloud Platformを同時に利用できるクロスクラウドな分散システムを実現することができます。これについては、以下のセクションで詳しく説明します。

クロスクラウド配信システム

Stream ManagerはTerraform Cloud Controllerを使ってTerraformと通信するため、Terraformがサポートする全てのクラウドプラットフォームに特に何もしなくても対応します。このアプローチは、機密性の高いデプロイメントに必要なプライベートネットワークにも拡張することができ、それがTerraformプロバイダーを含むクラウド構成である限り、サポートされます。VMware vSphere［4］、Apache CloudStack［5］、OpenStack［6］、OpenNebula［7］などがこれにあたります。このように、Stream Managerを用いて、それぞれのクラウドの独自要件を満たしながらクラスターを展開することで、複数のクラウドを組み合わせたクロスクラウド配信システム（CCDS）を構築することができます。

CCDSは、1つまたは複数のプラットフォームにデプロイされた1つまたは複数のStream Managerのセットによって制御されます。それらのStream Managerが同じデータベースを共有している限り、すべてのStream Managerがネットワーク全体の状態を把握することができます。さらに、あるStream Managerが停止した場合、新しいStream Managerが起動するまでの間、他のStream Managerが一時的にそのリクエストを処理することができます。システムの可用性を確保するため、データベースのデプロイメントについては、データ損失や単一障害点を回避するためにレプリケーション戦略を使用しています。

1：https://www.hashicorp.com/products/terraform/multi-cloud-compliance-and-management/#providers

クロスプラットフォームサポートの利点

クロスプラットフォームアプローチにより、企業はクラウドプロバイダーごとに異なる価格体系のうち最も有利なものを選択しつつ、全体の展開の可用性、信頼性、およびカバレッジを向上させることができます。さらに、あるクラウドに障害が発生した場合でも、別のクラウドを使用し、障害が発生した地域に新しいノードおよびクラスターをデプロイできるため、システムの可用性と信頼性は向上します。また、地域が違えば利用できるクラウドも異なり、その性能やカバレッジもさまざまです。
したがって、価格が大きな制約でなければ、このアプローチを取ることで、地域ごとに最善のクラウドプロバイダーを使い分け、世界のどこにでもリーチすることができます。図7は、AWS、GCP、Azure、DigitalOcean、Linodeを一緒に使用した場合のカバレッジを示しています。

逆に、予算が限られている場合は、それぞれの地域で価格的に有利なプラットフォームを選択し、パフォーマンスと価格のトレードオフを実現することもできます。CCDSのユーザーは、単一のAPIとStream Managerコントローラが使えるため、クラウドネットワークごとに異なるAPIを使い分ける必要がなくなるというメリットも得られます。

◎は既存のデータセンター、中空の◎は建設中のデータセンターを表しています。

セキュリティルール

Red5 Proには、Round Trip Pluginを使用したストリーム認証のサポートが組み込まれています。このプラグインは、ブロードキャストやサブスクライブのリクエスト時にユーザー名、パスワード、オプションのトークンを受け取り、バックエンドのサービスに対してそれを検証し、そのユーザーがパブリッシュやサブスクライブを許可されるべきかどうかを確認するものである。

このソリューションは、ストリームに基本的なセキュリティ レイヤーを追加するには最適ですが、特定のデプロイメントでは十分でない場合があります。そのような場合、Red5 Proは、必要に応じて任意のカスタム機能を実装できるカスタム認証プラグインの開発をサポートします。

可変ビットレート

Red5 ProはWebRTCで可変ビットレート（ABR）ストリーミングをサポートし、ネットワークがサポートする最高のストリーム品質をクライアントに提供します。ABRソリューションは、クラスターの各リレーとエッジに配信されるストリームに対し、異なるビットレートを持つ複数のバリエーションをオリジンにパブリッシュすることで実現します。

エッジはREMB（Receiver Estimated Maximum Bitrate）というRTCPメッセージを使用して各クライアントの帯域幅を決定し、クライアントのネットワークがサポートできる上限の品質のバリエーションをストリーム配信することで、パケットの損失と輻輳を防ぎます。

Red5 Proオリジンにストリームの複数のバリエーションをインジェストするには、エンコーダーから直接送るか、トランスコーダーとして設定されたRed5 Proインスタンスを使います。後者の場合、トランスコーダーは単一の高品質なストリームをインジェストし、それより低品質のバリエーションを生成してオリジンに送ります。システムの図を図8に示します。

結論

このホワイトペーパーでは、HTTPベースのプロトコルが提供する遅延は、最新のものも含めて、ライブ動画ストリームの要求を満たすことができないことを示しました。実際、より多くのユースケースで、ユーザーがライブストリームとインタラクションできることが求められていますが、これは遅延が最小限に抑えられている場合にのみ可能です。具体的には、エンドツーエンドの遅延を500ms以下に抑える必要があります。HTTPベースのプロトコルでは、これほど低い遅延を実現することは不可能です。LL-HLSやCMAFなどのアプローチでも、遅延は3秒程度にまでしか短縮できません。解決策は、WebRTCやSRTなどのより高度なプロトコルを使用し、CDNをベースにしたHTTP中心のインフラからクラウドコンピューティングプラットフォームに移行することです。

この文書ではまた、異なるクラウドプラットフォームにデプロイされた複数のRed5 Proクラスターと、オプションでプライベートネットワークを活用し、クラウドプラットフォームの障害やダウンタイムに耐性のある、信頼できる高可用性システムを構築するクロスクラウド配信システム（CCDS）もご紹介しました。
CCDSでは、各プラットフォームごとに異なる性能と価格の最善の組み合わせを実現でき、エンドツーエンドの遅延をわずか数ミリ秒に抑えながら、各クラスターごとに数百万の同時ユーザとカスタム認証ルールをサポートすることが可能です。

参考文献

［1］https://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/white-paper-c11-741490.html
［2］https://www.red5pro.com/white-paper-gateway/?id=Red5Pro_White_Paper_Live_Video_Streaming_Protocols_and_
ゼロ遅延への挑戦
［3］https://www.red5pro.com/demo/
［4］https://www.vmware.com/products/vsphere.html
［5］https://cloudstack.apache.org/
［6］https://www.openstack.org/
［7］https://opennebula.org/
［8］https://aws.amazon.com/about-aws/whats-new/2019/12/run-ip-multicast-workloads-aws-transit-gateway/
［9］https://www.akamai.com/us/en/multimedia/documents/white-paper/low-latency-streaming-cmaf-whitepaper.pdf
［10］https://github.com/Haivision/srt/files/2489142/SRT_Protocol_TechnicalOverview_DRAFT_2018-10-17.pdf