ライブ動画ストリーミングプロトコルと遅延ゼロへの競争
Red5 Pro Server
Red5 Pro Serverを使えば、完全にスケーラブルなリアルタイムのライブストリーミングアプリケーションを提供できます。オープンソースのRed5プロジェクトをベースに構築されたRed5 Pro Serverは、オープンソース版のすべての機能に加え、カスタムのストリーミングプラグインが追加できる、スタンドアロン型のサーバーディストリビューションです。また、WebRTC経由でRed5 Pro Mobile SDK、iOS、Androidと接続するだけでなく、Flash/RTMP（レガシー用）やHLSを経由したブラウザとの接続など、さまざまなエンドポイントをサポートしています。
クロスデバイスの互換性を確保するため、Red5 ProはHTML5 SDKを提供しており、主要ブラウザであるChrome、Safari、Firefox、および（自動RTMPフォールバック機能付き）Internet Explorerでサポートされるウェブアプリケーションの作成に使用することが可能です。Mobile SDKを使えば、完全な互換性を持つモバイルアプリケーションを開発できます。
Red5 Proには自動スケーリング機能があり、既存のクラウドインフラを活用しながらリアルタイムの状況に応じてシステムを自動的にスケールアップまたはスケールダウンします。鍵となるのはトラフィックを管理し、サーバーの使用状況を監視するRed5 Proサーバーアプリケーション「Stream Manager」で、この運用ロジックのもと、クラスターまたはノードグループ（1つ以上のアクティブなサーバーノードのグループ）がストリーミングがおこなわれるリージョンごとに設置されます。
アーキテクチャの各ノードは、エッジ、オリジン、リレーのいずれかの役割を持つRed5 Proサーバーインスタンスです。簡単に言うと、オリジンはブロードキャスター側にあり、エッジはサブスクライバー側にあり、リレーがその間を接続します。図7は、異なる要素間の接続で形成されたRed5 Proクラスターを示しています。ここでのStream Managerの役割は、リアルタイムでライブストリーム情報を処理し、現在のトラフィック需要に応じてサーバーノードを追加または削除し、ブロードキャスターとサブスクライバーにそれぞれオリジンまたはエッジエンドポイントを供給することです。つまり、複数のオリジンまたはエッジの間にリレーを作成したり、サブスクライバーやブロードキャスターを追加したりすることができるのです。これにより、現在の視聴者の体験を妨げることなく、より多くのユーザーがストリームに参加し、同期することができます。最も注目すべきは、この自動スケーリングソリューションが、数百万規模に拡張してもエンドツーエンドで500ミリ秒以下の遅延を維持していることです。
Red5 Proのクラスターは、AWS、Google Cloud Platform、Azure、Digital Oceanにデプロイすることができます。Digital Oceanの特筆すべき利点は、CDNが課す帯域幅のコストをHLSやMPEG DASH配信と同等かそれ以上まで、大幅に下げられることです。遅延に関して妥協せずに、より優れたパフォーマンスを競争力のある価格で提供できるわけです。さらに、Red5 Proは、対象となるクラウドAPIを変更するだけで、他のホスティングプロバイダーやCDNネットワーク（例：Limelight Networks）にも導入することが可能です。セキュリティの強化、コンプライアンス、パフォーマンスの向上などが必要であれば、カスタムサーバーサイドアプリケーションを使用したオフライン展開もサポートされます。こうした柔軟性とカスタマイズ性も兼ね備えているため、さまざまなニーズに対応する、使い勝手がよく高度に実用的なソリューションといえます。
クラスターアーキテクチャ
Red5 Proでは、図7に示すように、開発者はサーバーをクラスターに配置して、ライブストリーミングアプリケーションを無制限にスケーリングすることができます。Red5 Proは、Google Compute Engine、AmazonのAWS、MicrosoftのAzure、Digital Oceanなどのクラウドプラットフォームにデプロイ可能な自動スケーリングソリューションを備えています。
自動スケーリングとは、ネットワークトラフィックの規模が不明な場合やトラフィックの変化が大きい場合に、サーバーインスタンスを必要に応じてスケールする機能のことを指します。また、ネットワークの規模が安定しており、トラフィックの状況が事前に分かっている場合にも、自動スケーリングは有用です。また、自動スケーリングは、ノード（Red5 Pro Serverインスタンス）の監視やノードの追加・削除を行う自動クラスター管理により、運用コストを最適化し、効率的にサーバーを使用することで運用コストの削減を実現します。
自動スケーリングプロセスは、Red5 Pro Stream Managerに組み込まれたソフトウェアモジュールであるRed5 Pro「Autoscaler」によって実行され、リアルタイムでスマートなノード管理をおこなうことができます。簡単に言うと、Autoscalerは、手動で介入することなく、リアルタイムで負荷状況に基づいてノードグループからサーバーノード（エッジ、リレー、オリジン）を追加または削除します。スケールアウトとスケールインの手順を図8と図9に示します。図8は、既存のクラスターにエッジノードを追加するためにStream Managerが新しいイン スタンスをスピンアップしてプロビジョニングする手順を示し、図9はその逆の、エッジを削除する手順を示しています。
Red5 Proには、自動スケーリングのほかに、Stream ManagerイベントスケジューリングAPI［6］があり、あらかじめ決められた時間に開催される特定のイベントのために、クラスターのキャパシティを増やすために使用することができます。このプロセスは、イベントの開始前に新しいノードグループを自動的に作成するために使用される、特定のスケールポリシーと起動構成でスケジュールされたイベントを作成することで構成されています。スケジューリングAPIと自動スケーリングの主な違いは、後者は現在の負荷に基づいてのみクラスターをスケールすることができ、新しいサーバーの起動に約40〜90秒かかる場合があることです（スピンアップ時間は、クラウドネットワークの実装に依存します）。したがって、ライブストリーミングイベントの開始時にクラスターが過小評価されないようにするために、実シナリオでの運用では常にイベントスケジューリングAPIを使用することが望ましいといえます。
クラウドプラットフォームに依存しないアプローチ
Red5 Proは、カスタムプラグインをサポートし、任意のバックエンドに実装できる柔軟なAPIを特徴とする、プラットフォーム非依存のホスティングプラットフォームです。カスタムクラウドコントローラプラグインにより、Red5 Proは選択したクラウドプラットフォームやバックエンドのAPIに対して、Stream Managerの抽象コマンドを実行することができます。これにより、既存のアプリケーションをRed5 Proと統合し、バックエンド全体を再構築することなく、遅延時間の短縮とスケーラビリティの向上を実現することができます。この柔軟性の好例が、Limelightのネットワーク上にRed5 Proを実装し、世界のどこからでも1秒以下の遅延でライブ放送品質の動画を配信する「Limelight RTS」サービスです。Limelight Networksのソリューションは実際に500ミリ秒以下の遅延を達成できているものの、同社はこの遅延速度をサービス品質保証に含めていません。
また、セキュリティの強化、コンプライアンス、パフォーマンスの向上などの要件を満たすために、カスタムサーバーサイドアプリを使ったオフラインのデプロイメントもサポートされます。これは政府のユースケースに典型的で、分析ソリューション企業Novettaの「Ageon ISR」はRed5 Proサーバーのオフライン実装の好例といえます。
NACK
WebRTCはUDPベースであるため、すべてのパケットが受信者に配信される保証はありませんし、パケットが順番に配信される保証もありません。そのため、WebRTCはドロップされたパケットに対処する必要があり、これには最も重要なパケットを再送信する NACK、Forward Error Correction（FEC）などのパケットロス隠蔽手段、またはその 2つの組み合わせが有効です。
したがって、Red5 Proはネットワークパケット損失を克服するためにNACKアプローチを実装しています。送信者として動作する場合、Red5 Proは送信後 1 秒間パケットをキャッシュします。受信者は受信したパケットを検査し、シーケンス番号の欠落を検出すると、RTCP NACKパケットを送信者に送信します。送信側はNACKパケットを受信すると、送信中にキーフレームがあるかどうかをチェックします。そうでなければ、送信者はNACKされたパケットをキャッシュから取得し、再送信します。
可変ビットレート
可変ビットレートは、クライアントの帯域幅とCPUの能力を検出し、必要に応じてメディアストリームの品質をリアルタイムで調整するプロセスです。これには、単一のソースメディア（動画または音声）を複数のビットレートで同時にエンコード出力できるエンコーダーが必要です。その後、クライアント上のプレイヤーは、利用可能なリソースに応じて、異なるエンコーディングの間で切り替わります。
HLSやMPEG-DASHなどHTTPベースのライブストリーミングプロトコルは、HLSプレイリストやMPEG-DASHマニフェストに記載した各種ビットレートで動画セグメントをエンコードすることにより、可変ビットレートを実現します。この方法では、コンテンツの再生中に、クライアントはビットレート適応（ABR）アルゴリズムを使用して、再生中に中断や再バッファリングイベントを発生させずに再生に間に合うようにダウンロードできる、できるだけ高いビットレートのセグメントを自動的に選択します。
Red5 Proサーバーは、可変ビットレートにも対応しており、1 つの動画ストリームの複数のバリエーションをパブリッシュし、利用可能な帯域幅を考慮して最適なバリエーションをサブスクライバーに提供することが可能です。特に、Red5 Proでは以下のことが可能です。
- 複数のプロビジョニングされたストリームのパブリッシュ
- 利用可能になるセグメントのパートを予告する
- ネットワーク条件に基づいてストリーム品質の動的なアップグレードとダウングレー ドを可能にする可変ビットレートストリームにサブスクライブする
図10は、メディアエンコーダーを使用して同じストリームの異なるバリアントをパブリッシュする場合のシステムの概要を示しています。このプロセスは次のように動作します。
- Stream Managerに、パブリッシュされるストリームの異なるバリアントを指定するためのプロビジョンが提供される
- Stream Managerは適切なオリジンを選択し、同じストリームの複数のバージョンを期待するように設定
- Stream Managerは、ブロードキャストに使われるべきオリジンエンドポイントの詳細を含むJSONオブジェクトを返す
- ブロードキャスターは、メディアエンコーダーを使ってオリジンに配信する
図11は、トランスコーダーを使用した場合のシステムの概要を示しています。プロセスは以下のように動作します。
- ストリームマネージャにプロビジョニングが提供される。ストリームマネージャにプロビジョンが提供され、公開されるストリームの異なるストリームを公開する。次に、Stream Manager APIを使用してトランスコーダーのエンドポイントを要求します。
- Stream Managerは適切なオリジンとトランスコーダーを選択します。オリジンは同じストリームの複数のバージョンを想定してプロビジョニングされ、トランスコーダーは作成する必要のある異なるストリームバリアントの詳細とともにプロビジョニングされます。
- Stream Managerは、ブロードキャストに使われるべきトランスコーダーのエンドポイントの詳細を含むJSONオブジェクトを返します。
- ブロードキャスターは、トランスコーダーに対して1つのストリームのパブリッシュを開始することができます。
Stream Managerから利用可能なプロビジョンと、（メディアエンコーダーまたはトランスコーダーを介して）ストリームされている複数のバリアント放送があれば、可変ビットレートストリームにサブスクライブすることが可能になります。クライアントがサブスクライブすると、そのネットワーク条件下で最高の品質を持つストリームバリアントを受信します。これは、エッジがサブスクライバークライアントと対話することで実現されます。特に、エッジとサブスクライバーは、REMB（Receiver Estimated Maximum Bitrate）というRTCPメッセージを使用して、エッジが動画品質に対応する調整を行うために使用する帯域幅の推定を提供します。これにより、エッジは推定帯域幅を考慮した最高品質の動画を配信できるのです。
結論
この文書では、低遅延を実現するために動画ストリーミング業界で使用されている、または提案されている主なプロトコルを紹介しました。CMAF、LHLS、ALHLS は、標準的なHLSのスケール性を保ちつつその遅延を大幅に改善していますが、3秒から10秒の遅延は、特にインタラクティブな映像体験やリアルタイムな通信が求められるユースケースにおいてまだ十分に低いとはいえません。WebSocketとMSEをベースにしたWowzaのソリューションは、低遅延HLSと同等の遅延を実現していますが、可変ビットレートなどの機能がないことと、iOSデバイスで対応していないMSE APIに依存することなどから、採用のハードルはさらに高くなります。したがって、WebRTCが、遅延が1秒以内の動画ストリームの配信を実現する唯一の技術です。Red5 Proは、パブリッシャーとサブスクライバーの両方がWebRTCを使用して500ms以下のエンドツーエンド遅延のライブストリームを実現し、さらにそのクラスタリングアーキテクチャによって数百万の同時接続ユーザーにサービスを提供できることを示す最良の例といえます。
遅延ゼロに向けた競争は、現在も進行中です。Red5 Proを含めたWebRTCベースのソリューションが常にパックをリードしているため、HTTPベースのプロトコルは修正されたものの、引き続き遅れをとっています。常に進化し続ける市場は、新しいユースケースの出現を促します。Red5 Proは、柔軟性と拡張性を備え、リアルタイムレベルの遅延時間を実現するよう設計されており、次世代のライブ動画ストリーミングを強力にサポートすることでしょう。
参考文献
［1］https://mux.com/blog/the-low-latency-live-streaming-landscape-in-2019/
［2］https://www.akamai.com/us/en/multimedia/documents/white-paper/low-latency-streaming-cmaf-whitepaper.pdf
［3］https://mux.com/blog/the-community-gave-us-low-latency-live-streaming-then-apple-took-it-away/
［4］https://www.ibc.org/publish/the-impact-of-apples-protocol-extension-for-low-latency-hls/4395.article
［5］https://princiya777.wordpress.com/2017/08/19/webrtc-architecture-protocols/
［6］https://www.red5pro.com/docs/development/rest-api-v-310/smapi-events/
