WebRTC 会議のアーキテクチャ：SFU、MCU、ハイブリッド構成

WebRTC の会議製品は、最終的に同じアーキテクチャの問いに答えることになります。クライアントの帯域やサーバーのキャパシティを使い果たすことなく、メディアストリームをすべての参加者に届けるにはどうするか。その答えが、コスト、品質、運用の複雑さを長年にわたって規定します。

本記事では、特定のベンダーを前提とせず、主要な構成とその実務的なトレードオフを説明します。

トランスポートの前提

WebRTC は UDP（TCP へのフォールバックを伴う）上で暗号化されたメディアを提供し、接続性には ICE、鍵交換には DTLS、メディアの暗号化には SRTP を用います。シグナリングは仕様化されていません。設計するのは自社です。

構成の選択を左右する2つの性質があります。

• クライアントにとってアップロードは高コストです。 参加者の上り帯域が通常は制約条件となり、とくにモバイルネットワークで顕著です。
• 規模を考えるとサーバーは避けられません。 ピアツーピアは2名には優雅ですが、12名には非現実的です。

メッシュ

すべての参加者が、他のすべての参加者と直接接続します。

• クライアントあたりのアップロード：n−1 本のストリーム。
• サーバーのメディア負荷：なし（シグナリングのみ）。
• 適する用途：1対1の通話、小規模なグループ通話、メディアがサーバーを経由してはならないケース。

メッシュの品質は急速に劣化します。10名がそれぞれ 1 Mbit/s を送信すると、各クライアントは約 9 Mbit/s をアップロードし、同じ量を受信します。モバイル端末や非対称リンクでは厳しく、ポリシーを適用する中心点もありません。

SFU（Selective Forwarding Unit）

各クライアントは1本のストリーム（または複数の simulcast レイヤー）をサーバーへパブリッシュし、サーバーが選択したストリームをサブスクライバーへ転送します。

• クライアントあたりのアップロード：通常1〜3レイヤー。
• サーバーのエグレス：概ね パブリッシャー数 × サブスクライバー数 × レイヤー数 で、ルーム規模とともに増加します。
• 適する用途：ほとんどの会議製品、双方向性を限定したウェビナー、選択的な購読が重要な大規模ルーム。

SFU はメディアをデコードしないため CPU コストは抑えられますが、DTLS/SRTP を終端するため、帯域と暗号処理の負荷を負います。キャパシティプランニングはエンコードではなくエグレスが支配的です。

simulcast と SVC

simulcast では、パブリッシャーが複数の解像度を送信し、SFU が各サブスクライバーのネットワークに適したレイヤーを転送します。SVC はレイヤー符号化によって同様の適応を実現します。どちらもトランスコードの必要性を減らし、輻輳時の挙動を改善しますが、パブリッシャーの上り帯域をより多く消費します。

SFU のカスケード

地理的に分散した大規模ルームでは、SFU をカスケードできます。ある SFU がパブリッシュされたストリームを別の SFU へ転送し、その SFU がローカルにファンアウトします。リージョン間トラフィックを削減できますが、レイテンシのホップが増え、ルーティングと障害処理が複雑になります。カスケードは最適化であり、既定の構成ではありません。

MCU（Multipoint Control Unit）

サーバーが音声とビデオをミックスし、合成ストリームを生成します。

• クライアントあたりのアップロード：1本。
• サーバーの処理：デコード、ミックス、エンコード。CPU を多く消費し、コーデックに敏感です。
• 適する用途：非常に大規模なブロードキャスト、多様なデバイス、受信側の帯域が厳しく制限される場合。
• 欠点：合成によりパーソナライズが制限され（すべての視聴者が同じレイアウトを見ます）、レイテンシが増え、サーバーが高コストなスケーリング点になります。

現代の会議製品は、すべての参加者に対してクラシックな MCU を使うのではなく、選択的転送を行う SFU に、録画やブロードキャストのためのサーバー側合成を組み合わせるのが一般的です。

比較

シグナリングの設計判断

構成は設計の半分にすぎません。シグナリングは信頼性と運用に影響します。

• 状態の所有権。 権威あるルーム状態は、クライアントのメモリではなく自社のサービスに保持します。
• トークンベースの認可。 短命の参加トークンを発行し、メディア層とシグナリング層で権限を検証します。
• 冪等な操作。 再接続と再試行は必ず発生します。参加とパブリッシュは安全に繰り返せるよう設計します。
• バージョンネゴシエーション。 ロールアウト中はクライアントとサーバーのバージョンがずれることを前提とします。
• 可観測性のフック。 参加試行、ネゴシエーション失敗、メディア品質のイベントを出力し、セッションを再現せずにデバッグできるようにします。

NAT 越えとリレー

ICE は経路を見つけますが、リレー経由の接続しか許さないネットワークもあります。TURN を計画します。

• 追加のレイテンシを抑えるため、リレーはユーザーの近くに配置します。
• リレー帯域は別枠で見積もります。リレーされるメディアは2回転送されます。
• リレーの利用状況を監視します。急増は通常の増加ではなく、ネットワーク変更を示すことがよくあります。

プライベートデプロイでは、TURN は内部専用で足りる場合もありますが、拠点間やリモートアクセスのシナリオでは通常エッジリレーが必要です。

録画と処理

録画はチェックボックスではなく、メディアパイプラインです。選択肢には、クライアント側の録画、サーバー側の合成、SFU でのストリーム単位のキャプチャがあります。それぞれ CPU、ストレージ、同意、保持に影響します。まずポリシーを決め、その後で実装を決めます。

構成の選び方

次の問いを用います。

1. 典型的な最大ルームと、想定される最大ルームはどれくらいか。
2. 参加者は主に管理されたネットワークにいるのか、モバイルやパブリックインターネットにいるのか。
3. 視聴者ごとの個別レイアウトが必要か、共通の合成映像で許容できるか。
4. リージョン間トラフィックにどこまでコストを払えるか。
5. 録画が必要か、誰がアクセスできるか。

多くのプライベートな企業会議では、TURN リレー、simulcast、明確なキャパシティモデルを備えた SFU ベースの設計が現実的な選択です。メッシュは例外的な用途で有用であり、MCU はブロードキャストで有用です。

まとめ

アーキテクチャの選択は、姿を変えた制約です。まずルーム規模、ネットワーク、コンプライアンスの境界を決めれば、構成はおおむねそれに従います。Feiyan RTC は SFU ベースでプライベートデプロイ可能な選択肢であり、どのベンダーを評価する場合でも同じ問いが当てはまります。