console.lealog();

@leader22のWeb系に関する勉強めもブログですのだ

mediasoupのスケーラビリティについて

実際に調べたわけではなくてその前段。

公式のドキュメントに記述があるので、そこを抜粋したメモです。

mediasoup :: Scalability

そもそも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の帯域を消費することになる
  • 視聴者が増えれば増えるほどそのリスクは高まる
  • これを回避するためには、サーバー側で再エンコードする仕組みが必要
    • つまりは配信者と同じバックエンド上で、帯域の制約を無視しつつ配信者にメディアを配るレイヤー

まとめ

  • 利用者の数が読めないのであれば、制約を設ける必要がありそう
  • 無限にスケールする実装を設計するのも手だが、ユースケース的にコスパが悪そう
  • やろうと思えば数千人単位への配信も可能なはず
  • なにはともあれ要実証