分散 WebRTC SFU の話
自社製品についてざっくり紹介します。
自社で開発している WebRTC SFU は 2021 年頃からクラスター機能を実装してきました。このクラスター機能は主に冗長化を目的としており、いずれかのノードが落ちても他のノードでサービスを継続できるようになっています。
WebRTC はロードバランスが非常に難しい技術ですが、このクラスター機能だけでも大きな恩恵があります。さらに 2023 年から準備を進め、2024 年には「どのノードに接続しても同じチャネル（ルームのようなもの）に参加できる」という機能を実現しました。しかも、Redis などの外部ストレージを一切利用しない仕組みです。
とはいえ、この「どのノードに接続しても同じチャネルに参加できる」機能にはまだ課題があります。たとえばノード数が 1000 など非常に多くなる場合、ノード間のリレーコストが高騰する問題です。
簡単に言えば、1000 ノードそれぞれに視聴クライアントがぶら下がっている状況では、配信クライアントが接続しているノードは、残りの 999 ノードへ映像や音声をリレーしなければなりません。結果として、そのノードに非常に大きな負荷がかかります。
これを解決するために、2025 年には「リレーのリレー」による多段リレー機能を導入してリレーの効率化を実現する予定です。これにより、1 ノードあたりのリレー数を減らし、全体で負荷を分散できるようになります。
また、分散機能を活用し、ロードバランス機能も実装しました。負荷を特定のノードに集中させるのではなく、「暇な」ノードに処理を割り振ります。ただし、リアルタイム性を重視する WebRTC らしく、1 ノードが受け持つ同一チャネルの接続数には上限を設けています。たとえば 1 ノードにつき 10 接続までは同じチャネルを同一ノードに寄せる、といった仕組みです。
これらの仕組みにより、当社の WebRTC SFU は大規模運用や冗長化など、従来の WebRTC SFU が抱えていた課題をほぼすべてクリアできるようになりました。
実際、社内では Akamai Connected Cloud の月 5 ドル（1 コア / 1 GB）のサーバーを複数起動してクラスターを組み、安定した配信を実現しています。この仕組みならば、100 台のクラスターを構築しても月 500 ドル程度で運用可能です。
自社 WebRTC SFU を支える技術
これらの分散機能を支えているのは、主に以下の 3 つの技術です。
- Erlang/OTP
- Raft
- Plumtree
Erlang/OTP
マルチコア環境を簡単に扱え、Erlang VM 間で標準的に用意されている RPC 機能により、分散ノード間通信を容易に実装できます。Erlang/OTP の真骨頂といえる部分です。
Raft
分散システムでの合意アルゴリズムとして Raft を採用しました。これにより、「どのノードにどのチャネルがあるか」などの情報を強整合性で管理できます。
Raft ライブラリは自作せず、Erlang/OTP で開発された分散 MQ「RabbitMQ」が利用している Raft ライブラリを使用しています。今後は独自の Raft ライブラリを検討する可能性もあります。
Plumtree
ノード間通信の効率化と耐障害性を両立するアルゴリズムです。以前から注目していましたが、実際に自社の WebRTC SFU に組み込んだところ、期待どおりの動作を得られました。
まとめ
自社の WebRTC SFU は、これまで WebRTC SFU が課題とされてきた大規模運用や冗長化をほぼすべて解決しています。スケールアウトが容易で、低コストのサーバーを複数立ち上げるだけで拡張できるため、運用コストを抑えながら柔軟に対応可能です。
この分散機能をフル活用することで、 自社のサービス のさらなる安定化と低価格化を実現できています。