スケーラブルなマルチサーバー構成向けにJitsi Videobridgeを設定する方法

Jitsi Meet の展開環境でメディア容量を増やすには、Jitsi Videobridge (JVB) サーバーを追加するのが一般的な方法です。既存の Meet ホスト上で Web、Prosody、Jicofo の各サービスを維持したまま、同じ Prosody ブリッジ検出ルームに登録する独立したブリッジマシンを追加します。Jicofo は、利用可能なブリッジに新しい会議を配置できます。この基本的な設計では、会議の参加者は選択された 1 つのブリッジを使用します。展開環境に複数の JVB サーバーがあるからといって、Octo が必要になるわけではありません。

このガイドは、2026年10月6日時点のJitsiハンドブックに記載されている、Debian/Ubuntuパッケージベースのスケーラブルなセットアップ手順に基づいています。パッケージの依存関係や生成される構成は、ディストリビューション、Jitsiパッケージのバージョン、サーバーがDockerでインストールされたか、他の方法でインストールされたかによって異なる場合があります。既存のデプロイメントには、対応する公式インストールガイドを参照してください。

Jitsiにおける「マルチサーバー」の意味を理解する

検証済み： 1つのJitsi Meetインストール環境で複数のビデオブリッジを使用できます。Jicofoはブリッジを監視し、新しい会議をブリッジに割り当てます。Jitsiハンドブックの簡略化された例では、Meetサービスを1台のサーバーに、3つのJVBを別のサーバーに配置しています。各ブリッジは、会議参加者がメディアにアクセスできるように、またMeetインフラストラクチャがシグナリングのためにアクセスできるようにする必要があります。

よくある誤解：「JVB の前にロードバランサーが必要だ」。ドキュメントに記載されているマルチブリッジ設計では、Jicofo がブリッジを選択し、クライアントはそのブリッジにメディアを送信します。UDP メディアの前に汎用 HTTP ロードバランサーを配置しても、ブリッジの検出や会議の配置は行われません。対処法：各 JVB を Prosody/Jicofo ブリッジプールに追加し、到達可能なメディア アドレスを公開してください。すべてのブリッジのメディア トラフィックを任意の 1 つの UDP VIP に向けないでください。

よくある誤解：「ブリッジの数を増やせば、1つの会議が自動的にすべてのサーバーにまたがる」。基本的な設定では、Jicofoは会議をブリッジに割り当てます。1つの会議の参加者を複数のリージョンまたはブリッジに分散させるのは、Octo（現在のJVBドキュメントではセキュアリレー）と呼ばれる別のリレートポロジです。対処法：同時接続する会議の数を増やすことが目的であれば、まず通常のブリッジプーリングから始めてください。1つの会議で複数の場所にあるブリッジを使用する必要がある場合、またはそのようなリレー動作が必要な場合にのみ、Octoを検討してください。

設置前にブリッジプールを計画する

各 JVB に対して、パブリックで安定したホスト名またはアドレスを 1 つ選択します。構成で XMPP MUC プレゼンスを使用する場合は、すべての VM に一意のオペレーティングシステム ID と一意の JVB インスタンスニックネームを割り当てます。すべてのブリッジは、同じ Prosody サービスおよびブリッジ醸造室にアクセスできる必要があります。バージョンを一致させてください。Jicofo は、同じ会議で異なるバージョンのブリッジを混在させません。現在のリレーのドキュメントでは、Octo についてもこの制約が繰り返されています。

環境によって異なります。VMあたりの参加者数は一律ではありません。Jitsiの要件に関するドキュメントでは、単一の固定サイズよりもネットワーク容量とワークロードを重視しています。コーデック、解像度、同時配信、パケットレート、同時会議数、プロバイダ帯域幅など、すべてが容量に影響します。対策：実際のワークロードに基づいてベースラインを設定し、ブリッジを1つずつ追加して、CPU、ネットワークスループット、パケット損失、会議品質を監視してください。

複数のJVBサーバーを段階的に構成する

1. 既存のMeetホストが正常であることを確認します。

マシンを追加する前に、既存の Meet ページが読み込まれること、Prosody と Jicofo が実行されていること、および現在のブリッジを介してテスト通話が完了することを確認してください。Jitsi パッケージのバージョンを記録してください。コアサーバーでシグナリングまたは証明書の設定に問題があると、ネットワークが正常であっても、新しいブリッジの設定が間違っているように見えることがあります。

Debian/Ubuntu パッケージのインストールでは、サービスを調べてsystemctl status prosody jicofo jitsi-videobridge2サービスログを確認してください。インストール環境に存在するサービス名を使用してください。コンテナ化された環境では、コマンドとログの場所が異なる場合があります。

2. DNS、ルーティング、ファイアウォールルールを準備する

各ブリッジに固有のパブリックアドレスを割り当てるか、正しく構成された1対1のNATマッピングを設定してください。スケーラブルなセットアップガイドには、一般的なパスとして次のものが記載されています。パブリッククライアントはTCP 80/443でWebホストに接続し、JVBサーバーはTCP 5222でProsodyに接続し、クライアントはメディア用にUDP 10000で各Videobridgeに接続します。TCP 80は通常、証明書またはリダイレクトの設定に使用されますが、本番環境のMeetサイトではHTTPSを使用する必要があります。

• サービスがサポートする参加ネットワークからのすべてのブリッジに対して、受信UDP 10000を許可してください。
• JVBホストからProsodyへのブリッジ接続にTCPポート5222を許可し、ファイアウォールが許可する場合は、その接続をこれらのホストに限定してください。
• Prosody/XMPPサービスは、可能な限り、対象となるインフラストラクチャのみに限定してプライベートな状態に保ってください。
• JVBのプライベートHTTP/デバッグエンドポイントを一般公開しないでください。ColibriのパブリックWebSocketエンドポイントを有効化またはプロキシする場合は、そのデプロイメントに関する最新のJVBおよびリバースプロキシのドキュメントに従ってください。

ネットワーク環境によります。NAT、クラウドセキュリティグループ、IPv6、TURN、および制限の厳しい企業ネットワークでは、追加の候補またはパスが必要になる場合があります。デフォルトのポートリストは、特定のファイアウォールを介してメディアが機能することの証明にはなりません。対処方法：外部クライアントネットワークから各パブリックブリッジアドレスへのパケットフローを確認し、実際の通話をテストしてください。XMPP接続が成功しただけでは、UDPメディアの検証にはなりません。

3. 各ノードに同じJitsi Videobridgeパッケージをインストールします。

Meetホストのディストリビューションに合ったJitsiリポジトリとパッケージの手順を使用してください。新しいDebian/Ubuntuノードごとに、jitsi-videobridge2公式のスケーラブルなセットアップの指示に従って、パッケージをインストールし、パッケージ構成のプロンプトにMeetホスト名で応答してください。ハンドブックには、ドキュメントに記載されているパッケージベースのセットアップでは、インストール後のデフォルト設定以外にブリッジに変更を加える必要はないと記載されています。

意図的に独立した Meet デプロイメントを実現したい場合を除き、すべてのブリッジに完全な Jitsi Meet スタックをインストールしないでください。ブリッジ プールの場合、Web、Prosody、および Jicofo の役割はコア ホストに残し、JVB サービスを追加してください。プール全体で同じサポートされている JVB リリースを使用し、アップグレードを段階的に実行して、必要以上に長く異なるバージョンのプールが混在する状態にならないようにしてください。

4. 橋梁登録と身元を確認する

パッケージベースのセットアップでは、まず公式パッケージ構成で必要な設定を生成してください。JVBはProsodyに接続し、Jicofoが監視する同じbrewery MUCにブリッジの存在を通知する必要があります。現在のXMPPクライアント構成パスを使用している場合は、JVBドキュメントに、videobridge.statsおよびの下に関連する部分が表示されますvideobridge.apis.xmpp-client.configs。Jicofoはを使用して対応するbreweryに参加する必要がありますjicofo.bridge.brewery-jid。

一般的な最新の構成は次のようになります。すべての例示値をご使用環境の値に置き換え、共有シークレットを保護してください。

videobridge {
  stats {
    enabled = true
    transports = [{ type = "muc" }]
  }
  apis {
    xmpp-client {
      configs {
        xmpp-server-1 {
          hostname = "meet.example.com"
          domain = "auth.meet.example.com"
          username = "jvb"
          password = "REPLACE_WITH_SECRET"
          muc_jids = "JvbBrewery@internal.auth.meet.example.com"
          muc_nickname = "bridge-01"
        }
      }
    }
  }
}

各ブリッジで異なる名前を使用してくださいmuc_nickname（例：bridge-02およびbridge-03）。JVB プロジェクトでは、ニックネームはインスタンス間で一意でなければならないと警告しています。正確な設定ファイル名と、この明示的なブロックが必要かどうかは、パッケージと既存の設定によって異なります。インストール済みのバージョンのドキュメントを確認せずに、手書きの最新の設定を生成されたレガシー パッケージ設定の上に重ねることは避けてください。

5. サービスを開始し、ログを確認します。

各新規ホストで JVB を再起動または起動し、アクティブな状態が維持され、Prosody に接続されていることを確認してください。スケーラブルなセットアップ ガイドでは、ブリッジ接続と Jicofo がブリッジを検出していることを確認するために、Prosody と Jicofo のログを確認することを推奨しています。ブリッジが表示されない場合は、次の順序で確認してください。DNS 解決と TCP 5222 への到達可能性、XMPP 認証情報とドメイン、正確な醸造所 MUC のスペル、重複するニックネーム、そして JVB/Jicofo のバージョン互換性。

6. すべてのブリッジで外部メディアテストを実行する

複数の新しいテストミーティングを開始し、Jicofo がそれらを利用可能なプール全体に時間経過とともに配置することを確認します。1 つのミーティングが 1 つのブリッジに割り当てられるのは想定内の動作であり、負荷分散が失敗したことを示すものではありません。Jicofo のデバッグ インターフェイスが有効でアクセスが制限されている場合は、それを使用して利用可能なブリッジとアクティブな会議を検査します。JVB のドキュメントにcurl http://localhost:8888/debugはローカル デバッグの例が示されています。診断インターフェイスをバインドするかファイアウォールで保護して、プライベートな状態を維持してください。

サーバーネットワーク外のクライアントでテストしてください。音声とビデオが正常に動作することを確認したら、選択したブリッジのアドレスとUDPフローを調べます。ブリッジがJicofoに表示されるものの、そのブリッジを選択した場合のみ通話が失敗する場合は、そのブリッジのパブリックアドレス、NATマッピング、UDPファイアウォール、およびアドバタイズされた候補を調査してください。メンテナンス中は、インストールされているバージョンでサポートされているドレインまたは展開手順を使用してのみ、1つのブリッジをローテーションから除外してください。アクティブなブリッジを再起動すると、そのブリッジに割り当てられている会議が中断される可能性があります。

Octoを有効にすべきタイミングはいつですか？

Octoは、参加者が複数の地域に分散している場合など、単一の会議で複数のブリッジを使用する必要がある場合に最適なトピックです。通常の容量でJVBを追加する際の前提条件ではありません。現在のJVBリレーに関するドキュメントでは、参加する各ブリッジでのリレー設定、ブリッジ間の接続のためのColibri WebSocket、および適切なJicofoブリッジ選択戦略が必要です。地域認識動作は、提供されるMeet設定に正確なクライアント地域情報を提供することにも依存します。

リレー構成にはrelay-id、各ブリッジの固有のIDとリージョンが含まれます。JicofoではOctoを有効にし、などの戦略を選択しますRegionBasedBridgeSelectionStrategy。リレーWebSocketエンドポイントも、プロキシ経由で正しくルーティングされる必要があります。これらの設定はリリースやトポロジによって変更されるため、展開前に最新のリレーガイドに従い、正確なプロキシパスを確認してください。

対処方法：シンプルな単一リージョンのブリッジプールを使用する場合は、Octoを無効にしてください。複数リージョンが必要な場合は、ステージング環境でドキュメントに記載されている分割戦略をテストし、Jicofoのブリッジセレクタと会議の状態を確認してから、クライアントリージョンとリージョンベースの選択を設定してください。クライアントが一致するリージョンメタデータをどのように受信するかがわかるまでは、リージョンラベルを設定しないでください。

規模拡大時に監視すべき事項

• ネットワーク：送受信スループット、パケット損失、ジッター、および実際のクライアントネットワークからUDP 10000に到達可能かどうか。
• ホスト負荷： CPU、メモリ、JVMの状態、および持続的なパケットレート。想定される普遍的な通話数ではなく、代表的な会議数に基づいた規模。
• プールメンバーシップ： Jicofoにおけるブリッジの存在、バージョンの一貫性、および新しく作成されたカンファレンスがすべてのノードに着地できるかどうか。
• 参加者の体験：想定されるピーク時の同時接続数における音声の途切れ、映像のフリーズ、再接続、および品質。

ユーザーから特定のJVBでのみ問題が報告された場合は、クラスタ全体を拡張する前に、そのノードのネットワークパスと構成を正常に動作しているピアと比較してください。すべてのブリッジが同時に劣化する場合は、共有帯域幅、コアシグナリングサービス、または参加者ネットワークがボトルネックになっている可能性があります。スケーリングは、新しいブリッジが独立して到達可能で、正しく登録され、現実的なテスト中に負荷が測定可能なほど軽減される場合に有効です。

公式資料

• Jitsiハンドブック：DevOpsガイド（スケーラブルなセットアップ）
• Jitsiハンドブック：要件
• Jitsi Videobridge: MUC の設定
• Jitsi Videobridge: リレー (Octo) セットアップ
• Jitsi Videobridge: HTTPおよびRESTインターフェース