BigBlueButton Kurentoメディアサーバーが負荷時にクラッシュする問題を修正する

BigBlueButtonの会議が混雑している最中にKurento Media Server（KMS）プロセスが終了すると、録画が中断したり、古いインストール環境ではライブ音声やビデオが中断したりする可能性があります。最初に役立つのは、単にサービスを再起動することではなく、影響を受ける機能をどのメディアスタックが処理しているか、終了前にどのリソースまたは障害が発生したか、そして修正によって次の同様の会議が安定して実行されるかどうかを把握することです。

まず、BigBlueButton のリリースバージョンと、このサーバーにおける Kurento の役割を確認してください。BigBlueButton 2.5 以降では、ライブ WebRTC メディアにデフォルトで mediasoup が使用されます。Kurento は録画用、または管理者がレガシー設定やカスタム設定を維持しているために、引き続き使用されている可能性があります。したがって、「Kurento がクラッシュした」というだけでは、KMS が過負荷の Web カメラを扱っているとは断定できません。バージョンによる違いについては、公式のBigBlueButton トラブルシューティング ガイドを参照してください。以下の詳細な KMS 対策は、バージョン管理されたBigBlueButton 2.7 サーバーカスタマイズ ガイドから抜粋したものです。適用する前に、インストールされているリリースバージョンに対応するドキュメントを確認してください。

まず、何が失敗したのかを確認してください。

サービスを繰り返し再起動する前に、証拠を収集してください。ユーザーが最初に問題に気づいた時刻、影響を受けた会議、音声、ウェブカメラ、画面共有、録画のいずれが失敗したか、サーバー全体または特定のメディア機能のみが低下したかを記録してください。サービスを再起動すると、一時的にプロセスが復旧する可能性がありますが、クラッシュとネットワークまたはクライアントの問題を区別するタイミングの手がかりが失われてしまいます。

BigBlueButtonホスト上で、まず読み取り専用のチェックから始めます。

sudo bbb-conf --check
sudo systemctl status kurento-media-server --no-pager
sudo journalctl -u kurento-media-server --since "1 hour ago" --no-pager
sudo ls -lt /var/log/kurento-media-server/ | head

リリースおよびデプロイメントには、該当するユニット名を使用してください。サービスが複数の KMS ユニットに分割されている場合は、ユニットを調べて、失敗したプロセスをログに記録してください。systemd ジャーナルのタイムスタンプを最新の KMS ログと比較してください。明示的な終了、再起動ループ、メディアパイプラインの失敗、またはリソース関連のメッセージを探してください。一致する失敗がない「警告」行が 1 つだけでは、原因を特定するには不十分です。

ユーザーが実際にトラフィック障害に Kurento を使用しているかどうかを確認してください。Firefox では、about:webrtcピア接続の詳細を表示できます。Chrome では、 が提供されていますchrome://webrtc-internals。BigBlueButton のトラブルシューティング ドキュメントでは、mediasoup のネゴシエートされたセッションの詳細を確認する方法について説明しています。また、設定されているメディア サービスと録画ワークフローも確認してください。ライブ メディアが mediasoup にあり、KMS が終了したときにのみ録画が停止する場合は、ライブ Web カメラの設定をむやみに変更するのではなく、録画/Kurento のパスを調整してください。

出口の手前の圧力を求めよ

「負荷がかかっている」とは、複数の異なるボトルネックを意味する可能性があります。代表的な会議がアクティブな状態でホストをサンプリングし、そのサンプルをイベント発生時間と比較してください。有用なチェック項目は以下のとおりです。

• free -hまた、vmstat 1利用可能なメモリ、スワッピング、および実行キューの負荷についても考慮します。
• mpstat -P ALL 1コアごとのCPU飽和度については、sysstatツールがインストールされている場合。
• df -hまた、iostat -xz 1利用可能な場合は、ファイルシステム全体またはストレージのレイテンシについても測定します。
• journalctl -k --since "1 hour ago"カーネルメッセージ（メモリ不足による強制終了メッセージを含む）について。
• systemdのステータスとKMSログから、繰り返し終了、パイプラインの障害、およびどのメディア操作がアクティブであったかを確認します。

サーバーの平均CPU使用率だけに頼らないでください。メディア処理は、1つのコアがビジー状態である一方で他のコアはアイドル状態に見える場合があり、また、CPU使用率が長時間高くなくてもメモリ負荷によって強制終了されることがあります。逆に、UDPがブロックされているか、ブラウザがWebRTCパスを確立できないために、KMSが正常に動作しているにもかかわらず、ユーザーから「カメラがフリーズした」という報告がある場合もあります。BigBlueButtonは、制限的なネットワークへの対策としてTURNを文書化しています。TURNは接続性を改善する可能性がありますが、KMSの計算能力を追加するものではありません。サービスがアクティブなままで、ログにリソースイベントが表示されない場合は、メディア制限を引き上げる前に、ICE、ファイアウォール、およびクライアントの接続性を調査してください。

処理能力は、会議の参加人数だけでなく、実際のストリーム構成と処理能力によって決まります。公開および受信されるウェブカメラの数、画面共有、音声セッション、録画、合意された品質、会議のレイアウトなど、すべてが影響します。そのため、持続可能な上限は、無関係なサーバーからコピーするのではなく、組織独自の会議パターンに基づいて測定する必要があります。

証拠に合致する治療法を選択してください

従来の KMS 展開の場合、メディアワークロードを分離します。

BigBlueButton 2.7 のカスタマイズガイドでは、音声の再生専用、ウェブカメラ、画面共有処理それぞれに 1 つずつ、合計 3 つの KMS プロセスを実行する方法を説明しています。この方法の利点は、メディアの開始/停止処理を複数のプロセスに分散させ、いずれかの KMS プロセスがクラッシュした場合の影響を最小限に抑えることです。ガイドの設定では、BigBlueButton 構成スクリプトのenableMultipleKurentos設定を使用し、その後 BigBlueButton を再起動します。ご使用のリリースに合わせて手順に従い、再起動後に生成されるサービスユニットとログを確認してください。

この分離は、十分なCPU、メモリ、ストレージの代替ではなく、封じ込めと分散のための措置です。また、追加のプロセスが実行されるため、ベースラインのリソース使用量が増加する可能性があります。メンテナンスウィンドウをスケジュールしてください。sudo bbb-conf --restartアクティブなセッションが中断されます。生成されたサービスファイルを手動で編集したり、2.7用に文書化されたコマンドが新しいバージョンまたはベンダーによって変更されたインストールにそのまま適用されると想定したりしないでください。

サーバーがアクセス制限を必要とする場合は、メディアしきい値を設定します。

ドキュメントに記載されているオプションをサポートする KMS ベースのバージョンでは、BigBlueButton は、、、の値を指定できます。2.7ガイドmediaThresholdsでは、これらの値はパッケージのアップグレード後も保持されるように設計されたオーバーライド ファイルで示されています。ドキュメントに記載されている例では、ゼロは制限なしを意味します。設定されたしきい値に達すると、参加者が Web カメラを共有しようとしたときに「メディア リソースが利用できません (2002)」エラーが発生する可能性があります。globalperRoomperUser/etc/bigbluebutton/bbb-webrtc-sfu/production.yml

測定値と必要なサービス品質に基づいて値を選択してください。ドキュメントの例示を普遍的な安全限界値として貼り付けないでください。しきい値を設定することで、追加のメディアを拒否し、過負荷をより予測しやすくなりますが、バグ、メモリリーク、または無関係なオペレーティングシステムの制限によって引き起こされたクラッシュを修復するものではありません。展開する前に、ご使用のリリースのドキュメントで設定名と動作を確認してください。

容量想定を引き上げる前に、メディア需要を削減する

監視の結果、リソースが飽和状態になっていることがわかった場合は、まずサービスが処理しなければならないピーク時の作業量を減らしてください。モデレーターには、ウェブカメラを個別にオンにするよう依頼したり、不要な同時画面共有を避けたり、授業形式に合う場合は非常に大規模なインタラクティブセッションを小さな部屋に分割したりしてください。ウェブカメラのページネーションやストリーム制限がサポートされているバージョンでは、ドキュメントに記載されているオーバーライドメカニズムを使用してそれらを調整してください。受信するストリーム数を減らすとファンアウトを減らすことができ、カメラの解像度やビットレートを下げると処理能力と帯域幅の要求を減らすことができます。これらの変更は、安定性と引き換えに視覚的な詳細さや臨場感を犠牲にすることになります。会議の主催者にそのトレードオフを説明し、結果として得られるエクスペリエンスが許容範囲内であることを確認してください。

制限が戻ってきた場合は、アップグレードまたはアーキテクチャの変更を検討してください。

インストールされているリリースが古い場合は、KMS チューニングにさらに投資する前に、サポートされているアップグレード パスとメディア アーキテクチャを確認してください。BigBlueButton 2.5 以降、mediasoup がライブ メディアのデフォルトとなり、Kurento の役割は以前のリリースとは異なります。現在のサーバーで KMS が継続的にクラッシュする場合は、録画、カスタマイズされたメディア スタック、または特定の統合が原因である可能性があります。適切な制限とワークロードの変更後に測定された上限に繰り返し達するレガシー デプロイメントの場合、しきい値を上げるよりも、デプロイメントをアップグレードまたは再設計する方が効果的な場合があります。運用コストは、互換性テスト、移行計画、およびメンテナンス ウィンドウです。

同等の会議で変更を検証する

設定やワークロードの運用方法を一度に1つずつ変更し、通常のピーク時の使用状況に似た制御された会議でテストしてください。BigBlueButtonのリリース、参加者数、アクティブなWebカメラのおおよその数、画面共有、録画の有効/無効を記録してください。これにより、参加者数だけを負荷変数として扱うことなく、有用な比較が可能になります。

• 該当するKMSユニットがアクティブな状態を維持し、再起動ループに陥らないことを確認してください。
• テスト前とテスト中に、コアあたりのCPU使用率、利用可能なメモリとスワップ領域、ディスクアクティビティ、ログを比較します。
• Kurentoが実際に担う役割に応じて、音声、ウェブカメラ、画面共有、録画をそれぞれ個別に検証してください。
• 2002年のエラー、メディア設定の失敗、またはユーザーからの報告に変化が見られるかどうかを確認してください。単一の指標だけで修正が成功したことを証明することはできません。
• キャパシティ変更が成功したと判断する前に、予想される混雑時に再度テストを実施してください。

サービスがクラッシュする場合は、管理者またはサポートチームのために、正確なKMSログとジャーナルウィンドウ、カーネルメッセージ、インストールされているBigBlueButton/Kurentoのバージョン、およびアクティブな構成オーバーライドをキャプチャしてください。サービスが正常に動作しているにもかかわらずユーザーが接続できない場合は、調査対象をICE候補、ファイアウォールルール、TURNの可用性、およびブラウザ側のWebRTC診断に切り替えてください。望ましい結果は、無制限のストリーム数や、1つの構成がすべてのサーバーに適合するという保証ではなく、制限が明確な安定したメディアワークロードです。

出典およびバージョンノート

• BigBlueButton 2.7: サーバーのカスタマイズ— 複数の Kurento プロセス、メディアしきい値、および関連する設定。
• BigBlueButton: トラブルシューティングガイド— 現在のメディアスタックの識別、mediasoupのデフォルト設定、Kurentoに関する注意事項、およびネットワークのトラブルシューティング。
• BigBlueButton: 設定ファイル— 設定ファイルとオーバーライドファイルに関するガイダンス。

ドキュメントは2026年10月5日にレビューされました。上記のKurentoワークロードとしきい値の詳細な例は、BigBlueButton 2.7のドキュメントに明示的に関連しています。設定を他の場所に適用する前に、対応するリリースノートと管理者ガイドを確認してください。