WebRTC SFU Sora 2024 年ロードマップ

V
shiguredo
Published in
10 min readApr 9, 2024

--

WebRTC SFU Sora (以下 Sora) をリリースしてから昨年の 12 月で 9 年目に入りました。ここ最近は OBS を利用した WebRTC の配信に対応したり、より便利な録画機能を提供したりしています。

今回は 2024 年に提供を予定している機能を紹介していきます。今年の大きなアピールポイントは「クラスターリレー機能」と「マルチコーデック対応」の 2 つです。

クラスターリレー機能

現在の Sora のクラスター機能は耐障害性を目的としたものです。特定のクラスターノードに障害が発生しても、再接続すれば別のノードに接続でき、サービスが継続できます。

ただ、ある同一のチャネル (一般的にルームと呼ばれる概念と同じモノです) に参加するクライアントは特定のクラスターノードにしか接続できないという課題がありました。そのため、「どのクラスターノードに接続しても同一のチャネルに参加できる」ようにすることでチャネルのスケールアウトを実現したいと考えていました。

Redis などのデータベースを用意すれば、どのクライアントがどのノードに接続しているかなどの情報を共有することもできますが、Sora はパッケージ製品ということもあり、できるだけ他のプロダクトには依存せず、ノード間の同期についても Sora だけで完結できることを意識していました。

そのため、 2023 年の夏からクラスターの仕組みそのものを大幅に書き換えてきました(ただし互換性を維持しつつローリングアップデートができる仕組みは維持しています)。

始めに、安定したクラスターの分散のために Raft を利用することにし、RabbitMQ が公開している Raft ライブラリ Ra を採用しました。

そして 昨年 12 月リリースの Sora で、まずはチャネル情報の同期を実現しました。この段階で、「それぞれのクライアントはどのチャネルに参加するのか」、「そのチャネルに参加するにはどのノードに接続すればいいのか」の情報をクラスター内部で同期できるようになりました。

現時点の仕様では、以下の図のようにある特定のチャネル (Channel ID = egg) に参加したいクライアントが、そのチャネルを担当するノード (Sora 3) とは別のノードに接続した場合、そのチャネルを担当するノードにリダイレクトされるような挙動になっています。

Sora 2023.2.x までのクラスターのリダイレクト機能

そして 2024 年 6 月にリリース予定の Sora で実現するのが、クラスターリレー機能です。各ノード間どうしで双方向にリレーができるため、どのノードに接続してもそのまま特定のチャネルに参加できるようになります。

前述のとおり、現状は特定のチャネルは特定のノードにしか接続できない仕様ですが、どのノードにも接続できるようになることで、同じライセンス料金でも 1 つのチャネルあたりの最大同時接続数が増やせるというメリットが生まれます。

Sora 2024.1.0 で搭載予定のクラスターリレー機能

リレー機能を搭載することで、サービスを止めずに好きなだけスケールアウトできる WebRTC SFU が誕生します。もちろんスケールインもできます。

合計接続数維持機能

クラスターを利用するお客様向けに、合計接続数維持機能も提供する予定です。

Sora のライセンスでは「最大同時接続数」によってライセンスが異なります。具体的には、同じ時間に Sora に接続している WebRTC クライアントが最大でどの程度になるかというお客様の想定に基づいて 100 接続単位でライセンスを提供しています。

今のクラスターでは、特定のノードがハードウェア障害などで利用できなくなった場合、クラスター全体の合計接続数が減ってしまいます。例えば 3 ノード構成で 1 ノードあたり最大 100 同時接続だった場合、クラスター全体の合計接続数は 300 ですが、もし 1 ノードに障害が発生したらサービス全体での同時接続数は 200 に減ってしまいます。

合計接続数維持機能は、障害が発生しているノードの接続数を残りのノードが代わりに引き受けられるようにする仕組みです。

つまり先の例で言えば、 1 ノードに障害が発生したとしても、残りの 2 ノードで最大 300 接続を維持できるようにします。

障害発生時も合計接続数を 300 のまま維持する機能

障害が発生したノードが復旧したとしても、すでに他のノードに接続しているクライアントを切断したりはしません。100 をオーバーしている場合は、新規の接続をそのノード以外に促します。

ノードアフィニティ機能

リレー機能の実現に伴い、ノードアフィニティ機能も追加します。ノードアフィニティ (= 寄せ) とは、同一チャネルのクライアントはできるだけ同じノードに接続させるという仕組みです。

WebRTC SFU は低遅延であることが強みです。別ノードに分散させること自体は悪くないのですが、遅延という観点では同一ノードに寄せた方がより遅延は抑えられます。つまり、どのノードに接続しても同一のチャネルに参加はできるものの、基本的には最初から同一のチャネルに参加するクライアントを特定のノードに寄せることで、より低遅延を実現します。

ノードアフィニティ機能

アフィニティ機能はチャネル単位またはコネクション単位で指定できます。

デフォルトは有効ですが、アフィニティ(寄せ) を行わない設定もできるようにします。

テンポラリーノード機能

クラスター構成の中でも特に 5 台 や 10 台といった大規模な構成のお客様向けに、スケールアウト/スケールインを手軽に行えるよう、テンポラリーノードという仕組みを追加します。

常に起動させておくノードとは異なり、たとえば同時接続数が多い時のみ一時的に起動させるノードをテンポラリーノードに設定しておけば、それらはクラスター構成を維持するためのノードとは認識されません。必要な情報は同期されますが、クラスターへの登録は一時的なものとして扱われます。

テンポラリーノードは起動するだけでクラスターへ一時的に登録され、テンポラリーノードを終了するだけでクラスターから削除されます。常に起動させておくノードとは異なり、必要に合わせて気軽に起動させたり終了させたりすることが可能です。

ここからは、2 つ目の大きなアピールポイントとなるマルチコーデック対応について紹介していきます。

マルチコーデック対応

マルチコーデック機能は昨今のブラウザが実現している仕組みです。簡単に言えば、 1 つの接続で複数のコーデックが利用できる仕組みです。

サイマルキャストマルチコーデック機能

このマルチコーデック機能により、Sora のサイマルキャストで複数コーデックを利用できるようになります。

たとえば、配信者は 1 接続で H.265 (HEVC) と H.264 との両方で配信できるようになります。以下の図のように、iPhone アプリで視聴するユーザーは H265 を、PC や Android の Chrome で視聴するユーザーは H.264 をといったように、視聴者は自身の環境に合わせてコーデックを選択できます。

サイマルキャストマルチコーデックの例 1

さらに、配信者の回線が不安定などの理由で H.265 による配信が停止した場合は、それまで H.265 で視聴していたユーザーも、途中で切断することなく H.264 での視聴に自動で切り替わります。

サイマルキャストマルチコーデックの例 2

他にもサイマルキャストマルチコーデックを利用して、解像度 1080p の映像は H.264 で配信し、360p の映像は AV1 で配信するといったこともできるため、ユーザーの多様な端末や通信環境に合わせた配信が実現できます。

それ以外の機能について紹介していきます。

MP4 対応

今まで Sora の録画機能で出力できるファイル形式は WebM のみでしたが、MP4 にも対応予定です。これは H.265 (HEVC) の録画へ対応するためというのが一番の理由です。

HEVC の録画は WebM では想定されていないこともあり、MP4 での出力に対応する必要があります。

Windows 11 の最新版ではプラグインなしで HEVC が利用できることや、Chromium (Chrome/Edge) でも WebRTC HEVC 対応が進んでいます。

OBS WHIP/WHEP 対応

2023 年は OBS が WebRTC での配信ができる WHIP に対応しました。そして OBS 30.1.0 では WHIP が AV1 に対応しました。

また、OBS 31 では H.265 (HEVC) への対応も予定されています。こちらについてはすでに Sora でも対応済です。

WHIP とは別に、WHEP を利用した WebRTC の音声と映像を OBS のソースとして利用できる仕組みが現在 Pull-Request として提案されていて、マージされると考えられるため、Sora でも対応していきます。

WHEP を利用することで、複数の WebRTC 配信を OBS で合成することができるようになります。合成した映像を SFU に WHIP で配信することで、リアルタイムな映像の合成と配信が実現できます。

また、OBS では WHIP/WHEP のサイマルキャストや TURN 、統計などへの対応も予定しており、時雨堂でも貢献できればと考えています。

OBS WHIP/WHEP と Sora を組み合わせた WebRTC による低遅延の配信例

まとめ

クラスター構成によりスケールアウトを実現するというのはリアルタイム配信にとって非常に重要です。

片方向配信のスケールアウトであればそんなに難しくはないのですが、実は WebRTC のような双方向配信でのスケールアウトはかなり難しいのが正直なところです。そのため、今回のリレー機能は自分たちにとってもチャレンジングな念願の機能と言えます。

スケールアウトする WebRTC SFU を提供できるようになることはとても楽しみです。

また、サイマルキャストマルチコーデックは、視聴者の多様な環境に合わせた柔軟な配信を実現できる画期的な仕組みということもあり、こちらも提供できることが楽しみです。

WebRTC SFU Sora は簡単にスケールアウト、スケールアップを実現でき、かつ最新の技術を利用できる安定した製品として提供していきます。

--

--