$30 off During Our Annual Pro Sale. View Details »

Rustでマルチスレッドプログラミング! リアルタイム通信ではどのようにスレット...

yuki_uchida
November 29, 2024
2.2k

Rustでマルチスレッドプログラミング! リアルタイム通信ではどのようにスレッドを立てるのか

Rust.Tokyo 2024 https://rust.tokyo/lineup/4 で登壇した際に利用した発表資料です。

yuki_uchida

November 29, 2024
Tweet

Transcript

  1. Media over QUIC Transport(MoQT)とは 今のビデオ会議やライブ配信ではダメなのか? 現在では、ユースケースによってプロトコルを使い分けている ビデオ会議 WebRTC: 超低遅延志向なプロトコル ライブ配信

    HLS: 高品質志向なプロトコル この二つのプロトコルでは遅延と品質のトレードオフを選択できない Media over QUIC Transportはこれらのプロトコルの両取りを目指す
  2. Media over QUIC Transport(MoQT)の難しさと マルチスレッドの必要性 MoQTは、そのユースケース(ビデオ会議・ライブ配信)からわかるように、 リアルタイムに映像や音声が大量に流れる 映像は200kbpsから10Mbps 音声は32kbpsから256kbps ビデオ会議では人数分のメディアが流れて約250kbps*人数分にもなる

    ライブ配信では4K映像流したりすると10Mbpsにもなる メディアを中継するサーバーには非常に大きな負荷がかかる サーバーがどれだけメディアを捌けるかはサービスのコストに直結する マルチスレッド処理を活用してCPUをフルに使う必要がある
  3. スレッドを立ててみる メディアの中継サーバーの処理から、スレッドを分けて処理するのが良い部分を検討 クライアントサーバー間でWebTransportコネクションを貼る 数百以上のクライアントが接続してくると想定する WebTransportコネクションの中で、2種類のストリームが開かれ、それぞれ別の メッセージが送信される 双方向ストリーム: C-Plane用メッセージ メディア情報や配信処理などの制御系メッセージ データは少ない

    単方向ストリーム: D-Plane用メッセージ 映像や音声のデータメッセージ データメッセージのせいで制御メッセージの処理が詰まるのは避けたい メッセージの種類に応じて、必要なものは送信者以外のクライアントにメッセー ジを転送する スレッド間でのメッセージのやり取りを行いたい
  4. マルチスレッドの難しさ スレッドを立てて個別の処理をすることは簡単 その処理の特性(CPU heavyかI/O heavy)でOSスレッド・グリーンスレッド の使い分けは必要 複数スレッドから参照するデータをどう扱うか?が難しい 管理スレッドを立ててmpscでやり取りする デッドロックは起きないがmpscの管理が複雑 Mutexで複数スレッドから操作できるようにする

    デッドロックのリスク スレッドで行われる処理や扱うデータのサイズなどを考慮して設計する必要が ある 今回はマネージャー用のスレッドを立てたが負荷が偏ったら複数スレッドか ら操作できるようにMutex化するなどもありうる