実際に調べたわけではなくてその前段。
公式のドキュメントに記述があるので、そこを抜粋したメモです。
そもそもmediasoupの仕組み
- `mediasoup`自体はNodeのモジュール
- `Worker`という概念と`Router`という概念がある
- `Worker`はC++のプロセスで、単一のCPUコアで動作する
- `Worker`はNヶの`Router`を抱える
- `Router`はいわゆるRoomのようなもの
- そこに接続したエンドポイントが互いにメディアを送受信する
- `mediasoup`はSFUなので、送られてきたメディアをトランスコードしたりはしない
- SFUに対してメディアを送信することを`produce`すると表す
- 受信は`consume`すると表す
- それらを行う主体をそれぞれ`Producer`と`Consumer`と表す
ユースケース: 会議アプリ
- CPUの強さにもよるが、単一のC++プロセス = `Worker`が抱えられる`Consumer`の最大数は500が目安
- `Worker`はNヶの`Router`を抱えるが、そのトータル
- たとえば4人が互いにvideo+audioを送り合う場合
- その`Router`に`produce`されるのは、4人 * 2track = 8 producers
- 送られてくるのは自分を除く3人分のメディアなので、4人 * (3人 * 2track) = 24 consumers
- スケールさせるためには、複数のCPU、複数のホストで`Router`を配分する
参加者全員がvideo+audioを送り合う場合で、上限目安の500を考えた場合。
- N人の部屋: N * (N-1 * 2)
- 4人部屋: 24 consumers
- 10人部屋: 180 consumers
- 16人部屋: 480 consumers
- 17人部屋: 544 consumers
というわけで、参加者が全員audio+videoを送受信する場合、概算では1つの`Worker`で抱えられるのは16人まで。
そしてそもそも同じ部屋に入るためには同じ`Router`に属する必要があるので、16人会議をやるとなると、その`Worker`ではもうほかの会議は捌けない。
まあそんな全員がvideo+audioを送受信することはそうそうないと過程して、audioのみならどうか。
- N人の部屋: N * (N-1 * 1)
- 4人部屋: 12 consumers
- 22人部屋: 462 consumers
- 23人部屋: 506 consumers
ふむ。
改めて書くけど上記すべてはあくまで1コア = 1worker = 1routerでの試算。
ユースケース: 1:Nの配信
- 1 ~ 数人の配信者がvideo+audioを配信する
- 先述の上限で概算すると、
- 全員がvideo+audioを受信した場合、500 consumers = 250人で頭打ちになる
- これ以上をカバーするためのAPIとして、`Router#pipeToRouter()`というAPIがある
- その名の通り、`Router`同士をつなげる
- これにより、たとえば4コアのマシンであれば 250 * 4 = 1000人まで配信できる
- APIとしてはホストを超えてつなげることもできるので、4コア * 3台なら3000人まで配信できる
- もちろんリアルタイム
RTPの再送に関する注意
- この場合の構成は以下
- 1配信者 -> 1router -> Nrouter -> N視聴者
- 視聴者とNrouter間で、パケロスが起きた場合はその区間で再送される
- ただしRTCPのPLI or FIRは、配信者まで届く
- `mediasoup`としては1秒に1つ以上は届かないようになってるけど
- それでも2xから3xの帯域を消費することになる
- 視聴者が増えれば増えるほどそのリスクは高まる
- これを回避するためには、サーバー側で再エンコードする仕組みが必要
- つまりは配信者と同じバックエンド上で、帯域の制約を無視しつつ配信者にメディアを配るレイヤー
まとめ
- 利用者の数が読めないのであれば、制約を設ける必要がありそう
- 無限にスケールする実装を設計するのも手だが、ユースケース的にコスパが悪そう
- やろうと思えば数千人単位への配信も可能なはず
- なにはともあれ要実証