多人数 RTC 会議のプライベートデプロイ：アーキテクチャ、帯域、運用

多人数の音声・ビデオは、5秒の障害がすべての参加者に即座に見える数少ないワークロードの一つです。メディア経路を自社ネットワーク内で運用すれば、データと構成を制御できますが、同時にキャパシティ、NAT 越え、アップグレードの責任も負います。

本記事では、プライベートな RTC 会議環境が実際の利用に耐えられるかを左右する計画作業を順に説明します。

プライベートデプロイで設計が変わる理由

マネージドサービスでは、キャパシティ、エッジ配置、ネットワーク経路はプロバイダーの責務です。プライベートデプロイでは、構成を自社で選び、障害モードも自社が引き受けます。その結果、次の3つの問いが中心になります。

1. メディアストリームはどこを流れ、どのネットワークセグメントを通るのか。
2. ピーク時に必要な帯域とメディアノードの数はどれだけか。
3. クラスタの運用、監視、アップグレードは誰が行うのか。

リファレンスアーキテクチャ

一般的なプライベート会議基盤は、メディアプレーンとコントロールプレーンを分離します。

クライアント SDK

キャプチャ、エンコード、パケットロス耐性、描画、ネットワーク適応を担います。モバイル、デスクトップ、ブラウザのクライアントはルームモデルを共有しますが、バックグラウンド移行やネットワーク変更時の挙動は異なるため、個別にテストします。

シグナリング／ルームサービス

ルームのライフサイクル、認証、メンバーシップ、ネゴシエーションを管理します。通常はステートレス、または軽度のステートフルで、標準的なロードバランサーの背後に配置できます。

SFU メディアサービス

各パブリッシャーのストリームを受信し、サブスクライバーへ転送します。n 名の参加者の会議では、メッシュ構成は各クライアントが n−1 本のストリームをアップロードする必要がありますが、SFU ではクライアントあたり1本のアップロードで済み、ファンアウトはサーバーが担います。会議のデプロイで SFU が主流である理由はここにあります。

TURN / リレーサービス

直接接続が失敗した場合にリレー経路を提供します。イントラネット内では限定的で足りる場合もありますが、ハイブリッド構成や拠点間のシナリオでは通常必要です。リレーのキャパシティは別枠で計画します。リレーされたトラフィックは同じ帯域を2回消費します。

任意のメディア処理

録画、トランスコード、ゲートウェイ機能は、独自のキャパシティ計画とストレージ計画を持つ別サービスとして扱うべきです。すべての環境に必要なわけではありませんが、構成上あらかじめ場所を確保しておけば、運用開始後の追加が容易になります。

帯域とキャパシティの見積もり

帯域計画は、前提を伴う算術です。参加者あたりの目標値から始め、設備要件を導きます。

一般的な計画手順は次のとおりです。

1. 主要な解像度とコンテンツ種別について、参加者あたりの平均送信ビットレートを決めます。
2. 同時パブリッシャー数を掛けます。
3. SFU の転送係数を加えます。転送されるストリームは、単一ルームでは概ね サブスクライバー数 × パブリッシャー数、クラスタ全体ではルームごとの合計になります。
4. TURN や拠点間リンクが関与する場合は、リレーのオーバーヘッドを加えます。
5. 再送とバーストに備えた余裕を加えます。これは丸め誤差ではなく、意味のある割合です。

明確に仮定であることを前提とした計算例を示します。

• 会議全体で同時参加者200名。
• 参加者あたり平均 1.0 Mbit/s のビデオと 0.05 Mbit/s の音声。
• SFU の転送係数 2.5（パブリッシュされたストリームあたりの平均サブスクライバー数）。
• 平均に対するピーク係数 1.5。

アップロードトラフィック ≈ 200 × 1.05 ≈ 210 Mbit/s。転送トラフィック ≈ 210 × 2.5 ≈ 525 Mbit/s。さらにピーク係数を考慮すると、クラスタ内のメディアトラフィックは約 800 Mbit/s を見込んでリンクとノードを計画します。これらの数値は例示です。解像度ポリシー、コンテンツの構成比、ルーム規模が結果を大きく左右します。

あわせて計画すべき点：

• ノード単位の上限。 暗号化と転送のための CPU、ジッタバッファのためのメモリ、ネットワークインターフェースの容量。
• 障害時の余裕。 メディアノード1台の喪失で会議全体が落ちてはなりません。重要な箇所では n+1 で設計します。
• 拠点間トラフィック。 参加者が拠点に分かれている場合、メディアを WAN 越しに転送するか、各拠点で終端してブリッジするかを決めます。

ネットワークに関する考慮事項

• UDP が既定です。 メディア用のポート範囲とファイアウォールルールを明確にし、本番と同じファイアウォールポリシーでテストします。
• NAT と対称型ネットワーク。 イントラネット専用の構成ではパブリック STUN を避けられる場合がありますが、ハイブリッド構成では依然として TURN またはリレーが必要です。
• MTU とフラグメンテーション。 VPN やトンネルは利用可能な MTU を小さくする場合があります。大きなパケットの挙動を検証します。
• QoS マーキング。 ネットワークが対応している場合は音声とビデオのトラフィックをマーキングし、輻輳時に適切なフローから影響を受けるようにします。

コーデックと適応

コーデックの選択は、好みよりもブラウザとデバイスの対応状況に制約されます。会議用途では次の点を検討します。

• バッテリーと CPU のためのハードウェアアクセラレーション対応コーデック。
• SFU が受信者ごとに異なる品質を転送できるようにする simulcast またはスケーラブルビデオ。
• 音声処理とエコーキャンセレーション。体感品質には解像度よりも大きく影響します。

適応動作は明示的にテストします。パケットロスと帯域制限を強制し、ビデオが劣化しても音声が維持されることを確認します。

運用開始後の運用

プライベート RTC は導入して終わりではありません。次の点を計画します。

1. 監視 — 参加成功率、最初のフレームまでの時間、パケットロス、往復遅延、ノード単位の負荷。CPU だけでなく、ユーザーに見える症状でアラートを設定します。
2. アップグレード — コンポーネントの互換性、ローリングアップグレード、ロールバック経路。メディアノードは通話中に状態を持つため、ドレインには注意が必要です。
3. キャパシティレビュー — ピーク同時接続数を追跡し、四半期ごとの業務ピークの前に計画を更新します。
4. インシデント対応手順 — リレー障害、証明書の期限切れ、ノード喪失、ネットワークポリシーの変更。
5. 構成管理 — 構成とポリシーをコードとして扱い、環境間の一貫性を保ちます。

セキュリティ

• ルーム参加は、自社システムが発行する短命トークンで認証します。
• 転送中のメディアを暗号化します。エンドツーエンド暗号化が必要な場合は、サーバーが依然として観測できる範囲を確認します。
• 管理インターフェースは管理ネットワークに限定します。
• 録画およびメディアストレージへのアクセスは、アプリケーションログとは別に記録します。

POC の受入基準

有用な POC は小規模でも、意図的に厳しい条件を含めます。

• 混在するネットワークとデバイスで、10〜20名が参加する1つのルーム。
• メディア経路へのパケットロスと遅延の注入。
• 通話中のノード障害。
• 直前バージョンからのアップグレード。
• 計画ピーク時の帯域テストと、その後の監視結果のレビュー。

プライベート RTC が適さない場合

会議の利用が散発的である場合、キャパシティの予測が難しい場合、メディア基盤の運用チームがない場合は、マネージドサービスのほうが単位労力あたりの体験は通常優れています。プライベートデプロイは、データ管理、ネットワーク分離、統合の深さが運用負担を明確に上回る場合に報われます。

Feiyan RTC はプライベートデプロイ向けに設計されていますが、マネージドサービスのほうが状況に適している場合は、その旨を正直にお伝えします。