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

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

Transcript

1. Rustでマルチスレッドプログラミング！ 〜リアルタイム通信ではどのようにスレッドを立てるのか〜 Rust.Tokyo 2024 NTTコミュニケーションズ 株式会社 内田 裕貴
2. 内田 裕貴(Ucchy) X: @yuki_wtz NTTコミュニケーションズに2019年に新卒入社 WebRTC Platform SkyWayでResearchエンジニア Rustでメディアをリアルタイムにやり取りするプロトコルを実装(moq-wasm) IETFの相互接続試験に持ち込んで標準化貢献
3. セッションで話すこと(20分) マルチスレッドの必要性 ~Media over QUIC Transportを例に~ Rustでスレッドを立ててみる ~マルチスレッド化とメッセージのやり取り~ マルチスレッドの難しさとまとめ ~本セッションのコードの振り返り~
4. マルチスレッドの必要性 ~Media over QUIC Transportを例に~
5. Media over QUIC Transport(MoQT)とは
6. Media over QUIC Transport(MoQT)とは QUICをベースとしたリアルタイム通信のためのプロトコル 主に映像や音声などのサイズの大きいメディアを送受信できるように仕様が策定 されている
7. Media over QUIC Transport(MoQT)とは https://datatracker.ietf.org/meeting/interim-2023-moq-08/session/moq QUICをベースとしたリアルタイム通信のためのプロトコル 主に映像や音声などのサイズの大きいメディアを送受信できるように仕様が策定 されている
8. Media over QUIC Transport(MoQT)とは https://datatracker.ietf.org/meeting/interim-2023-moq-08/session/moq QUICをベースとしたリアルタイム通信のためのプロトコル 主に映像や音声などのサイズの大きいメディアを送受信できるように仕様が策定 されている 具体的なユースケースはビデオ会議・ライブ配信
9. Media over QUIC Transport(MoQT)とは 今のビデオ会議やライブ配信ではダメなのか？
10. Media over QUIC Transport(MoQT)とは 今のビデオ会議やライブ配信ではダメなのか？ 現在では、ユースケースによってプロトコルを使い分けている ビデオ会議 WebRTC: 超低遅延志向なプロトコル ライブ配信 HLS: 高品質志向なプロトコル
11. Media over QUIC Transport(MoQT)とは 今のビデオ会議やライブ配信ではダメなのか？ 現在では、ユースケースによってプロトコルを使い分けている ビデオ会議 WebRTC: 超低遅延志向なプロトコル ライブ配信 HLS: 高品質志向なプロトコル この二つのプロトコルでは遅延と品質のトレードオフを選択できない
12. Media over QUIC Transport(MoQT)とは 今のビデオ会議やライブ配信ではダメなのか？ 現在では、ユースケースによってプロトコルを使い分けている ビデオ会議 WebRTC: 超低遅延志向なプロトコル ライブ配信 HLS: 高品質志向なプロトコル この二つのプロトコルでは遅延と品質のトレードオフを選択できない Media over QUIC Transportはこれらのプロトコルの両取りを目指す
13. Media over QUIC Transport(MoQT)の難しさと マルチスレッドの必要性
14. Media over QUIC Transport(MoQT)の難しさと マルチスレッドの必要性 MoQTは、そのユースケース(ビデオ会議・ライブ配信)からわかるように、 リアルタイムに映像や音声が大量に流れる
15. Media over QUIC Transport(MoQT)の難しさと マルチスレッドの必要性 MoQTは、そのユースケース(ビデオ会議・ライブ配信)からわかるように、 リアルタイムに映像や音声が大量に流れる 映像は200kbpsから10Mbps 音声は32kbpsから256kbps
16. Media over QUIC Transport(MoQT)の難しさと マルチスレッドの必要性 MoQTは、そのユースケース(ビデオ会議・ライブ配信)からわかるように、 リアルタイムに映像や音声が大量に流れる 映像は200kbpsから10Mbps 音声は32kbpsから256kbps ビデオ会議では人数分のメディアが流れて約250kbps*人数分にもなる ライブ配信では4K映像流したりすると10Mbpsにもなる
17. Media over QUIC Transport(MoQT)の難しさと マルチスレッドの必要性 MoQTは、そのユースケース(ビデオ会議・ライブ配信)からわかるように、 リアルタイムに映像や音声が大量に流れる 映像は200kbpsから10Mbps 音声は32kbpsから256kbps ビデオ会議では人数分のメディアが流れて約250kbps*人数分にもなる ライブ配信では4K映像流したりすると10Mbpsにもなる メディアを中継するサーバーには非常に大きな負荷がかかる サーバーがどれだけメディアを捌けるかはサービスのコストに直結する
18. Media over QUIC Transport(MoQT)の難しさと マルチスレッドの必要性 MoQTは、そのユースケース(ビデオ会議・ライブ配信)からわかるように、 リアルタイムに映像や音声が大量に流れる 映像は200kbpsから10Mbps 音声は32kbpsから256kbps ビデオ会議では人数分のメディアが流れて約250kbps*人数分にもなる ライブ配信では4K映像流したりすると10Mbpsにもなる メディアを中継するサーバーには非常に大きな負荷がかかる サーバーがどれだけメディアを捌けるかはサービスのコストに直結する マルチスレッド処理を活用してCPUをフルに使う必要がある
19. Rustでスレッドを立ててみる ~マルチスレッド化とメッセージのやり取り~
20. Rustにおけるスレッド
21. Rustにおけるスレッド スレッドには2種類ある
22. Rustにおけるスレッド スレッドには2種類ある OSスレッド(std::threadなど) グリーンスレッド (tokio::spawnなど)
23. OSスレッド グリーンスレッド Rustにおけるスレッド スレッドには2種類ある OSスレッド(std::threadなど) グリーンスレッド (tokio::spawnなど)
24. OSスレッド グリーンスレッド CPUコアとスレッドが1:1対応 OSスレッドの上で複数のグリーンスレッドが動作 Rustにおけるスレッド スレッドには2種類ある OSスレッド(std::threadなど) グリーンスレッド (tokio::spawnなど)
25. OSスレッド グリーンスレッド CPUコアとスレッドが1:1対応 OSスレッドの上で複数のグリーンスレッドが動作 OSがスケジューリング ランタイムがスケジューリング Rustにおけるスレッド スレッドには2種類ある OSスレッド(std::threadなど) グリーンスレッド (tokio::spawnなど)
26. OSスレッド グリーンスレッド CPUコアとスレッドが1:1対応 OSスレッドの上で複数のグリーンスレッドが動作 OSがスケジューリング ランタイムがスケジューリング 作成・破棄・コンテキストスイッチが重い 作成・破棄・コンテキストスイッチが軽い Rustにおけるスレッド スレッドには2種類ある OSスレッド(std::threadなど) グリーンスレッド (tokio::spawnなど)
27. Rustにおけるスレッド これらの使い分けは、CPU処理が重いかI/O処理が重いか
28. Rustにおけるスレッド これらの使い分けは、CPU処理が重いかI/O処理が重いか 映像のエンコード処理やAI処理をやり続けるような場合 => OSスレッド I/O処理など待ちが多い場合 => グリーンスレッド
29. Rustにおけるスレッド これらの使い分けは、CPU処理が重いかI/O処理が重いか 映像のエンコード処理やAI処理をやり続けるような場合 => OSスレッド I/O処理など待ちが多い場合 => グリーンスレッド Media over QUIC TransportではI/O待ちが多いためグリーンスレッドを多用
30. スレッドを立ててみる
31. スレッドを立ててみる メディアの中継サーバーの処理から、スレッドを分けて処理するのが良い部分を検討
32. スレッドを立ててみる メディアの中継サーバーの処理から、スレッドを分けて処理するのが良い部分を検討 クライアントサーバー間でWebTransportコネクションを貼る WebTransportコネクションの中で、2種類のストリームが開かれ、それぞれ別の メッセージが送信される メッセージの種類に応じて、必要なものは送信者以外のクライアントにメッセー ジを転送する
33. スレッドを立ててみる メディアの中継サーバーの処理から、スレッドを分けて処理するのが良い部分を検討 クライアントサーバー間でWebTransportコネクションを貼る 数百以上のクライアントが接続してくると想定する WebTransportコネクションの中で、2種類のストリームが開かれ、それぞれ別の メッセージが送信される メッセージの種類に応じて、必要なものは送信者以外のクライアントにメッセー ジを転送する
34. スレッドを立ててみる メディアの中継サーバーの処理から、スレッドを分けて処理するのが良い部分を検討 クライアントサーバー間でWebTransportコネクションを貼る 数百以上のクライアントが接続してくると想定する WebTransportコネクションの中で、2種類のストリームが開かれ、それぞれ別の メッセージが送信される 双方向ストリーム: C-Plane用メッセージ メディア情報や配信処理などの制御系メッセージ データは少ない 単方向ストリーム: D-Plane用メッセージ 映像や音声のデータメッセージ メッセージの種類に応じて、必要なものは送信者以外のクライアントにメッセー ジを転送する
35. スレッドを立ててみる メディアの中継サーバーの処理から、スレッドを分けて処理するのが良い部分を検討 クライアントサーバー間でWebTransportコネクションを貼る 数百以上のクライアントが接続してくると想定する WebTransportコネクションの中で、2種類のストリームが開かれ、それぞれ別の メッセージが送信される 双方向ストリーム: C-Plane用メッセージ メディア情報や配信処理などの制御系メッセージ データは少ない 単方向ストリーム: D-Plane用メッセージ 映像や音声のデータメッセージ データメッセージのせいで制御メッセージの処理が詰まるのは避けたい メッセージの種類に応じて、必要なものは送信者以外のクライアントにメッセー ジを転送する
36. スレッドを立ててみる メディアの中継サーバーの処理から、スレッドを分けて処理するのが良い部分を検討 クライアントサーバー間でWebTransportコネクションを貼る 数百以上のクライアントが接続してくると想定する WebTransportコネクションの中で、2種類のストリームが開かれ、それぞれ別の メッセージが送信される 双方向ストリーム: C-Plane用メッセージ メディア情報や配信処理などの制御系メッセージ データは少ない 単方向ストリーム: D-Plane用メッセージ 映像や音声のデータメッセージ データメッセージのせいで制御メッセージの処理が詰まるのは避けたい メッセージの種類に応じて、必要なものは送信者以外のクライアントにメッセー ジを転送する スレッド間でのメッセージのやり取りを行いたい
37. スレッドを立ててみる クライアントサーバー間でWebTransportコネクションを貼る
38. スレッドを立ててみる クライアントサーバー間でWebTransportコネクションを貼る
39. スレッドを立ててみる クライアントサーバー間でWebTransportコネクションを貼る 数百以上のクライアントが接続してくると想定する
40. スレッドを立ててみる クライアントサーバー間でWebTransportコネクションを貼る 数百以上のクライアントが接続してくると想定する connectionごとの処理が完了しなければ次のconnectionを処理できない
41. スレッドを立ててみる クライアントサーバー間でWebTransportコネクションを貼る 数百以上のクライアントが接続してくると想定する connectionごとの処理が完了しなければ次のconnectionを処理できない tokio::spawnによってグリーンスレッドを作成することでawaitを待たず に次のコネクションの処理に移るように
42. スレッドを立ててみる クライアントサーバー間でWebTransportコネクションを貼る 数百以上のクライアントが接続してくると想定する connectionごとの処理が完了しなければ次のconnectionを処理できない tokio::spawnによってグリーンスレッドを作成することでawaitを待たず に次のコネクションの処理に移るように
43. スレッドを立ててみる WebTransportコネクションの中で、2種類のストリームが開かれ、それぞれ別のメッ セージが送信される
44. スレッドを立ててみる WebTransportコネクションの中で、2種類のストリームが開かれ、それぞれ別のメッ セージが送信される
45. スレッドを立ててみる WebTransportコネクションの中で、2種類のストリームが開かれ、それぞれ別のメッ セージが送信される
46. スレッドを立ててみる WebTransportコネクションの中で、2種類のストリームが開かれ、それぞれ別のメッ セージが送信される while文によってloop処理になっているため片方のhandle_関数が動き始めるとも う片方が動かなくなる
47. スレッドを立ててみる WebTransportコネクションの中で、2種類のストリームが開かれ、それぞれ別のメッ セージが送信される while文によってloop処理になっているため片方のhandle_関数が動き始めるとも う片方が動かなくなる これも別スレッドでloopさせるように変更
48. ここまでで立てたスレッド
49. ここまでで立てたスレッド WebTransportコネクションを待ち受け、Streamをそれぞれ別のスレッドで処理
50. スレッドを立ててみる ここまでで、中継サーバーの要件である3つのうち、2つまで完了
51. スレッドを立ててみる ここまでで、中継サーバーの要件である3つのうち、2つまで完了 クライアントサーバー間でWebTransportコネクションを貼る WebTransportコネクションの中で、2種類のストリームが開かれ、それぞれ別 のメッセージが送信される メッセージの種類に応じて、必要なものは送信者以外のクライアントにメッセ ージを転送する
52. スレッドを立ててみる ここまでで、中継サーバーの要件である3つのうち、2つまで完了 クライアントサーバー間でWebTransportコネクションを貼る WebTransportコネクションの中で、2種類のストリームが開かれ、それぞれ別 のメッセージが送信される メッセージの種類に応じて、必要なものは送信者以外のクライアントにメッセ ージを転送する
53. ここまでで、中継サーバーの要件である3つのうち、2つまで完了 クライアントサーバー間でWebTransportコネクションを貼る WebTransportコネクションの中で、2種類のストリームが開かれ、それぞれ別 のメッセージが送信される メッセージの種類に応じて、必要なものは送信者以外のクライアントにメッセ ージを転送する スレッドを立ててみる
54. ここまでで、中継サーバーの要件である3つのうち、2つまで完了 クライアントサーバー間でWebTransportコネクションを貼る WebTransportコネクションの中で、2種類のストリームが開かれ、それぞれ別 のメッセージが送信される メッセージの種類に応じて、必要なものは送信者以外のクライアントにメッセ ージを転送する スレッドを立ててみる
55. ここまでで、中継サーバーの要件である3つのうち、2つまで完了 クライアントサーバー間でWebTransportコネクションを貼る WebTransportコネクションの中で、2種類のストリームが開かれ、それぞれ別 のメッセージが送信される メッセージの種類に応じて、必要なものは送信者以外のクライアントにメッセ ージを転送する スレッドを立ててみる メッセージを受け取り、別のクライ アントの双方向ストリームを使って 送信したい
56. チャネルを使ってスレッド間通信 スレッド間でデータをやり取りして処理を行うために、Rustのtokioなどはチャネ ルという概念を用意されている
57. チャネルを使ってスレッド間通信 スレッド間でデータをやり取りして処理を行うために、Rustのtokioなどはチャネ ルという概念を用意されている スレッド間でメッセージを送信するためのパターンであり、 senderとreceiverのペアで構成される
58. スレッド間でデータをやり取りして処理を行うために、Rustのtokioなどはチャネ ルという概念を用意されている スレッド間でメッセージを送信するためのパターンであり、 senderとreceiverのペアで構成される sender / receiverはそれぞれ複数ある場合も 1対1: tokio::sync::oneshot N対1: tokio::sync::mpsc チャネルを使ってスレッド間通信
59. スレッド間でデータをやり取りして処理を行うために、Rustのtokioなどはチャネ ルという概念を用意されている スレッド間でメッセージを送信するためのパターンであり、 senderとreceiverのペアで構成される sender / receiverはそれぞれ複数ある場合も 1対1: tokio::sync::oneshot N対1: tokio::sync::mpsc チャネルを使ってスレッド間通信
60. チャネルを使ってスレッド間通信 スレッド間通信を実現するためにmpscが利用可能
61. チャネルを使ってスレッド間通信 スレッド間通信を実現するためにmpscが利用可能 スレッドAとスレッドBで通信する際には、senderとreceicerをそれぞれのスレッド に渡してあげれば良い
62. チャネルを使ってスレッド間通信 スレッド間通信を実現するためにmpscが利用可能 スレッドAとスレッドBで通信する際には、senderとreceicerをそれぞれのスレッド に渡してあげれば良い しかし、スレッドが増えてくると問題が発生する
63. チャネルを使ってスレッド間通信 スレッド間通信を実現するためにmpscが利用可能 スレッドAとスレッドBで通信する際には、senderとreceicerをそれぞれのスレッド に渡してあげれば良い しかし、スレッドが増えてくると問題が発生する
64. スレッド間通信を実現するためにmpscが利用可能 スレッドAとスレッドBで通信する際には、senderとreceicerをそれぞれのスレッド に渡してあげれば良い しかし、スレッドが増えてくると問題が発生する コミュニケーションパスが爆発する N*(N-1) チャネルを使ってスレッド間通信
65. スレッド間通信を実現するためにmpscが利用可能 スレッドAとスレッドBで通信する際には、senderとreceicerをそれぞれのスレッド に渡してあげれば良い しかし、スレッドが増えてくると問題が発生する コミュニケーションパスが爆発する N*(N-1) なので、管理するためのハブを用意する チャネルを使ってスレッド間通信
66. send_streamを管理するdispatcherを定義 チャネルを使ってスレッド間通信
67. send_streamを管理するdispatcherを定義 双方向ストリームが初期化されるごとに、mpscのsenderを登録し、必要になった らそれを使って送信する チャネルを使ってスレッド間通信
68. send_streamを管理するdispatcherを定義 双方向ストリームが初期化されるごとに、mpscのsenderを登録し、必要になった らそれを使って送信する チャネルを使ってスレッド間通信
69. send_streamを管理するdispatcherを定義 双方向ストリームが初期化されるごとに、mpscのsenderを登録し、必要になった らそれを使って送信する このdispatcherはWebTransportコネクションの中で双方向ストリームが開く たびに追加されるため、一番最初に初期化しておく チャネルを使ってスレッド間通信
70. send_streamを管理するdispatcherを定義 双方向ストリームが初期化されるごとに、mpscのsenderを登録し、必要になった らそれを使って送信する このdispatcherはWebTransportコネクションの中で双方向ストリームが開く たびに追加されるため、一番最初に初期化しておく handle_connectionの中でdispatcherへの登録と受け取り処理を実装 チャネルを使ってスレッド間通信
71. send_streamを管理するdispatcherを定義 双方向ストリームが初期化されるごとに、mpscのsenderを登録し、必要になった らそれを使って送信する このdispatcherはWebTransportコネクションの中で双方向ストリームが開く たびに追加されるため、一番最初に初期化しておく handle_connectionの中でdispatcherへの登録と受け取り処理を実装 チャネルを使ってスレッド間通信
72. send_streamを管理するdispatcherを定義 双方向ストリームが初期化されるごとに、mpscのsenderを登録し、必要になった らそれを使って送信する このdispatcherはWebTransportコネクションの中で双方向ストリームが開く たびに追加されるため、一番最初に初期化しておく handle_connectionの中でdispatcherへの登録と受け取り処理を実装 チャネルを使ってスレッド間通信
73. send_streamを管理するdispatcherを定義 双方向ストリームが初期化されるごとに、mpscのsenderを登録し、必要になった らそれを使って送信する このdispatcherはWebTransportコネクションの中で双方向ストリームが開く たびに追加されるため、一番最初に初期化しておく handle_connectionの中でdispatcherへの登録と受け取り処理を実装 チャネルを使ってスレッド間通信
74. チャネルを使ってスレッド間通信 最終的にはマルチスレッドで以下のような形で処理
75. チャネルを使ってスレッド間通信 最終的にはマルチスレッドで以下のような形で処理
76. チャネルを使ってスレッド間通信 最終的にはマルチスレッドで以下のような形で処理 ①クライアントからメッセージを受け取る
77. チャネルを使ってスレッド間通信 最終的にはマルチスレッドで以下のような形で処理 ①クライアントからメッセージを受け取る ②マネージャースレッドにmpsc経由でメッセー ジを送り、送りたいクライアントが動作している スレッドへのSenderを入手する
78. チャネルを使ってスレッド間通信 最終的にはマルチスレッドで以下のような形で処理 ①クライアントからメッセージを受け取る ②マネージャースレッドにmpsc経由でメッセー ジを送り、送りたいクライアントが動作している スレッドへのSenderを入手する ③Receiverから受け取ったメッセージをクライア ントに送信する
79. マルチスレッドの難しさとまとめ ~本セッションのコードの振り返り~
80. マルチスレッドの難しさ スレッドを立てて個別の処理をすることは簡単
81. マルチスレッドの難しさ スレッドを立てて個別の処理をすることは簡単 その処理の特性(CPU heavyかI/O heavy)でOSスレッド・グリーンスレッド の使い分けは必要
82. マルチスレッドの難しさ スレッドを立てて個別の処理をすることは簡単 その処理の特性(CPU heavyかI/O heavy)でOSスレッド・グリーンスレッド の使い分けは必要 複数スレッドから参照するデータをどう扱うか？が難しい
83. マルチスレッドの難しさ スレッドを立てて個別の処理をすることは簡単 その処理の特性(CPU heavyかI/O heavy)でOSスレッド・グリーンスレッド の使い分けは必要 複数スレッドから参照するデータをどう扱うか？が難しい 管理スレッドを立ててmpscでやり取りする Mutexで複数スレッドから操作できるようにする
84. マルチスレッドの難しさ スレッドを立てて個別の処理をすることは簡単 その処理の特性(CPU heavyかI/O heavy)でOSスレッド・グリーンスレッド の使い分けは必要 複数スレッドから参照するデータをどう扱うか？が難しい 管理スレッドを立ててmpscでやり取りする デッドロックは起きないがmpscの管理が複雑 Mutexで複数スレッドから操作できるようにする
85. マルチスレッドの難しさ スレッドを立てて個別の処理をすることは簡単 その処理の特性(CPU heavyかI/O heavy)でOSスレッド・グリーンスレッド の使い分けは必要 複数スレッドから参照するデータをどう扱うか？が難しい 管理スレッドを立ててmpscでやり取りする デッドロックは起きないがmpscの管理が複雑 Mutexで複数スレッドから操作できるようにする デッドロックのリスク
86. マルチスレッドの難しさ スレッドを立てて個別の処理をすることは簡単 その処理の特性(CPU heavyかI/O heavy)でOSスレッド・グリーンスレッド の使い分けは必要 複数スレッドから参照するデータをどう扱うか？が難しい 管理スレッドを立ててmpscでやり取りする デッドロックは起きないがmpscの管理が複雑 Mutexで複数スレッドから操作できるようにする デッドロックのリスク スレッドで行われる処理や扱うデータのサイズなどを考慮して設計する必要が ある
87. マルチスレッドの難しさ スレッドを立てて個別の処理をすることは簡単 その処理の特性(CPU heavyかI/O heavy)でOSスレッド・グリーンスレッド の使い分けは必要 複数スレッドから参照するデータをどう扱うか？が難しい 管理スレッドを立ててmpscでやり取りする デッドロックは起きないがmpscの管理が複雑 Mutexで複数スレッドから操作できるようにする デッドロックのリスク スレッドで行われる処理や扱うデータのサイズなどを考慮して設計する必要が ある 今回はマネージャー用のスレッドを立てたが負荷が偏ったら複数スレッドか ら操作できるようにMutex化するなどもありうる
88. 終わり X: @yuki_wtz (Follow me!)