WebRTC SFU Sora 2025.1.0 リリースノート

2025 年 6 月 25 日に WebRTC SFU Sora 2025.1.0 をリリースしました。今回はスケールアップとスケールアウトを中心に改善しました。また、アプリ側で実現するのが面倒な仕組みを Sora 側で完結できるような機能も追加しています。

スケールアップの効率化

Sora では 1 台で多くのクライアントへ配信できるよう、いわば複数のワーカーを配置して配信を少しずつ分担させるような仕組みになっています。

これまではこのワーカーの数を事前に予測して設定しておく必要がありました。そのため、予測よりも接続が大幅に少ないような場合は、本来必要のないワーカーのリソースを使ってしまうという課題がありました。

今回のリリースからは、ワーカーの数を事前に設定することなく、今現在の接続数に応じて動的にスケールする仕組みを追加しました。これにより、リソースの無駄を最小化し、効率的に運用できるようになります。

さらなるスケールアウト

Sora は、分散合意アルゴリズムである Raft をベースにした分散システムとして動作します。これにより、複数台の Sora でクラスター構成を組んだ場合、どの Sora に繋いでも同じチャネルへ接続することが可能です。

これまでは複数のノード間で配信をリレーする場合、一つのノードだけがリレーを担当する仕組みになっていました。この方法では配信先のノードが増えるにつれてその担当ノードの負荷が高まるため、サーバーのスペックを上げる必要があり、コスト面で課題がありました。

今回 Plumtree と呼ばれる以下の図のような仕組みを導入して複数の Sora でツリー構造を実現することにより、リレーを行う際に特定のノードだけに負荷がかかることなく、複数のノードで負荷を分散できるようになりました。これにより、Sora の耐障害性がさらに向上しています。

チャネル単位での厳密な接続制限

Sora では、認証ウェブフックを並列で処理しているため、これまで 1 チャネルあたりの接続数の厳密な制限は、お客様のシステム側で行っていただく必要がありました。今回のリリースでは、Sora 側で厳密な接続制限を行える仕組みを追加しました。

この接続制限は「認証成功後」に適用される仕組みであり、これまで認証時に接続制限を行っていたシステムでも、Sora 側での制御へ容易に切り替えられるようになっています。接続制限を有効にした場合、お客様のシステム側では認証が成功しても、接続数の上限を超えている場合は Sora 側での制御により接続が失敗します。

たとえば、接続数の上限まで残り 1 接続というチャネルに、以下の図のようにクライアント A とクライアント B の両方がほぼ同時に接続を試みたとします。

このとき、クライアント A とクライアント B の認証要求は並列で処理されるため、お客様のシステム側では二人とも認証が許可される可能性があります。しかし、今回の Sora で追加した厳密な接続制限機能により、その後 Sora 側でクライアント A のみが接続許可となり、クライアント B の接続は拒否されます。

なお、Sora によってクライアント B の接続が拒否された場合、そのことを Sora はシステムにウェブフックで通知します。

また、この接続制限は、複数台の Sora でクラスターを構築している場合でも、厳密に適用されます。

チャネル単位でのクライアント ID 重複時の既存接続の追い出し

クライアントが不安定な回線によって切断され、再接続した際に「切断前の自分」がセッション内に残ってしまう場合があります。  

Sora では、クライアントまたはアプリ側で自由に設定できる「クライアント ID」を接続ごとに付与できるようになっています。また、このクライアント ID は同じ値を複数の接続で共有できる仕組みになっています。  もともとは、PC とモバイルの両方からログインしている際に、同一人物かどうかを識別する目的で実装された機能です。

しかし近年、ウェブサービスでもよく見られるように、一人のユーザーが同時に複数接続する「複数ログイン」を防ぎたいという要望が増えてきたことから、今回、Sora 側で「後勝ち」の接続制御ができるようになりました。

この仕組みは非常にシンプルで、同一のクライアント ID を持つ接続がすでに存在する場合、既存の接続を切断し、新たな接続を受け入れるというものです。

さらに、ミーティングツールなどでよく求められる「画面共有は常に一つだけ」といった要件も、この仕組みを活用することで Sora の機能だけで実現することができます。

帯域推定機能

WebRTC SFU Sora では、これまで帯域推定機能はクライアント側の実装に依存していました。今回、Sora に libwebrtc 互換の帯域推定機能を搭載したことで、Sora 側でも帯域推定ができるようになりました。

帯域推定とは、簡単に言えば WebRTC クライアントがどの程度の帯域を利用できるかを推定し、それに基づいてクライアントから WebRTC SFU へ映像を送る際に、どのくらいのビットレートで送信すべきかを判断する仕組みです。  当然ながら、自身の回線が 1 Mbps しか利用できないのに 5 Mbps で映像を送信したら、配信は破綻してしまいます。

これは視聴側でも同様です。Sora には「サイマルキャスト」と呼ばれる、複数の画質を視聴側で選択できる仕組みがあります。  この機能を利用する際、視聴側のクライアントが帯域推定を行うことで、自身の環境でどの画質を選択すれば問題なく視聴できるかを判断できるようになります。

今回の対応では、帯域推定機能の実装に加えて、視聴側クライアントへの「推定結果の通知」も実現しました。  

さらに、次回のリリースでは、どの画質を選択すればいいかを Sora が自動で判断する仕組みを提供できる予定です。

レガシーストリームの廃止

今回、Sora を初めてリリースした 2015 年から約 10 年間提供してきた「レガシーストリーム機能」を廃止しました。

レガシーストリーム機能は、片方向かつ 1:N の配信のみを実現する仕組みで、WebRTC が登場した当初は、この方式しか存在しませんでした。

現在では「マルチストリーム」と呼ばれる、より柔軟に、かつ双方向の配信も実現できる仕組みが提供できるようになったため、レガシーストリーム機能を廃止することにしました。

2025.2.0 に向けて

2025 年 12 月リリース予定の Sora に向けて、Sora はより便利に利用できるような仕組みを追加して行きます。

サイマルキャスト利用時の視聴側での自動画質切り替わり機能

サイマルキャストを利用する場合、視聴側で画質を切り替えるには API を利用する必要があります。  

今後はこれに自動で画質を切り替える仕組みを追加する予定です。  手動切替と自動切替のどちらでも選択できるようにする計画です。

この仕組みを導入することで、回線が一時的に不安定になった際には低画質の映像に切り替わり、回線が安定すれば自動的に高画質に戻すといったことが自動でできるようになります。

データチャネルを利用した API 実行の仕組み

Sora では、これまで HTTP API ベースでコントロールを行うことを前提としていました。 しかし、データチャネルを利用して API を実行したいという要望が増えたため、一部の API をデータチャネル経由で RPC (Remote Procedure Call) として実行できる仕組みを今後追加していく予定です。

この仕組みは、データチャネルの上で JSON-RPC 2.0 を利用し実装する予定で、試験的に一部の API を実装したところ、利用者側の自由度が上がり便利なことが分かりました。たとえば、Push API をクライアントから実行することで個別にメッセージを送信したり、ホストが悪意のあるクライアントを切断したりすることが可能です。 

今後はさらに、ユーザー単位で利用できる API の権限を付与できる仕組みも導入する予定です。たとえば、特定のユーザーのみが切断 API を RPC 経由で実行できるといったようにする予定です。