2021 年の 12 月にリリースする WebRTC SFU Sora (以降 Sora) にクラスター機能を試作しています。2021 年 7 月時点で試作中の Sora のクラスタ機能について雑に書いていきます。
まとめ
- クラスターが組まれているどれかの Sora に接続すると、利用したいチャネルが接続すべき Sora へリダイレクトする仕組み
- 複数の Sora に同一チャネルは存在しない
- フルメッシュでの RTP/RTCP/SCTP の転送はしない
- Sora SDK には複数のシグナリング URL が指定できるようになる
- 障害時の対応がかなり楽になる
課題
Sora 自体は落ちにくい製品ではありますが、そもそもクラウドやハードに障害があったときに切り替えるコストが高く、なんとかしたいと考えていました。
ただ、まずは Sora の WebRTC SFU としての機能に注力するという方針をとっておりましたが、ひとまず Sora 2021.1 でスポットライト機能や DataChanel シグナリグ機能が実現できたこともあり、必要な機能はそろってきました。
そこで Sora にクラスター機能を持たせることにしました。
仕様
とてもシンプルな仕組みを採用しています。少し大きめの変更としてはSora SDK 側に複数のシグナリング URL を登録できるようになります。ただ複数指定しておくことでより安定するというだけで、無理に複数指定する必要はありません。
クライアントはもし複数のシグナリング URL が指定されていたら、ランダムに シグナリング URL 選択し、Sora に接続を試みます。Sora は自分が担当していないチャネルの接続だった場合、担当する Sora のシグナリング URL を type: redirect で送ります。
クライアントは redirect で送られてきたシグナリング URL へ接続します。その Sora は担当するチャネルだったため接続を受け入れます。
障害
もし何らかが原因でクラスターに参加している Sora が落ちた場合、クライアントは再度どれかの Sora へ接続しに行きます。クラスターに参加している残った Sora のどちらかがクラスターから外れた Sora が担当していたチャネルを担当します。
効率
これはまだ採用するか検討中ですが、新規のチャンネルはできるだけ「接続数が少ない Sora 」を提案する方針です。
現実
今のところ１クラスターで最大 10 Sora としています。最小構成は 3 台でスプリットブレイン対策のため 3、5、7、10 での運用を推奨します。
将来
インターコネクト機能はこのクラスターとクラスターの同期を実現したいと考えています。これはかなり大変で実装や検証に時間はかかりますが、今後必要になる機能と考えています。
料金
クラスター機能を利用するための追加費用は一切ありません。
API
クラスターへの参加は HTTP API を用意する予定です。JoinCluster API を利用し、すでにクラスターに参加している Sora のクラスターに利用する IP アドレスとポート番号を指定して貰う予定です。
また、クラスターの情報がとれるようになる GetClusterInfo API も用意する予定です。
