Media over QUIC 実装で直面した 3 つの問題

Transcript

1. Media over QUIC 実装で直⾯した 3 つの問題 松井 大樹 2026年9月3日 Video Tech Conference
2. これまで、ライブ映像を届ける⽅法は 主に 2 つだった
3. 低遅延を求めるなら WebRTC — 2011 年、ブラウザでリアルタイム通信を実現するために⽣まれた — 遅延は数百ミリ秒で、Web 会議のデファクトになっている But... — ⼤規模配信は主戦場ではない (安価な CDN を利⽤できず、SFU を⾃前で並べる必要がある) — 踏み込んだ最適化には libwebrtc を触る必要が出てくる (⾼難易度)
4. 広く配るなら HLS/DASH — 2009 年、HTTP でライブ映像を配るために⽣まれた — 映像を単なるファイルとして扱うことで、既存の CDN を利⽤できる But... — 遅延は数秒〜数⼗秒 — LL-HLS / LHLS 等で遅延を縮めてきたが、あくまで HTTP の枠内
5. そんな中、QUIC が登場‧普及した 2012 Google 実験開始 2021 RFC 9000 QUIC 従来 — HTTP/3 を⽀えるプロトコルで、世界中の CDN で 本番運⽤されている HTTP/1.1, HTTP/2 HTTP/3, WebTransport — TCP がやっていたことを UDP の上に作り直した TLS QUIC (TLS 内蔵) TCP UDP IP IP — ブラウザから使える (WebTransport)
6. メディアを QUIC で流せばよいのでは? Meta Twitch Cisco RUSH (2021) Warp (2022) QuicR (2022)
7. そこで⽣まれたのが Media over QUIC (MoQ) — IETF に WG が⽴ち上がり、標準化が始まった — QUIC 上でメディアを運ぶための Pub/Sub プロトコルを定めている — 配信‧会議‧CDN の主要各社が参画
8. 世界的ですもんね、 乗るしかない、このビッグウェーブに
9. まず、作ってみた (nttcom/moq-wasm) — MoQ Transport を Rust でフルスクラッチ実装した — ブラウザ (TypeScript)‧ネイティブ (Rust) クライアントに対応した — リレー (Relay) を GCP 上にデプロイした
10. 作ってみたら、あちこちで詰まった 1 仕様 リレー間の配信情報管理 2 ライブラリ QUIC/WebTransport のポート共有 3 インフラ QUIC-LB によるロードバランシング
11. 今⽇のゴール — MoQ の仕様や解説記事を読むだけでは分からない、実際に作ろうとするとどこで詰まるかを共有する — それぞれで何を選んだか、なぜそう決めたかまで話す → ⾃分で実装をしなくても「MoQ は今こういう状態なんだな」と語れるようになってもらう
12. ⾃⼰紹介 — 松井 ⼤樹 (@mti_daiki) / Daiki Matsui — NTT ドコモビジネスにて WebRTC Platform SkyWay の開発 — 通信プロトコル‧好奇⼼駆動開発
13. 1 リレー間の配信情報管理 2 QUIC/WebTransport のポート共有 3 QUIC-LB によるロードバランシング
14. リレー間の配信情報管理 配信者と視聴者は、リレー越しに繋がる — 配信者が Track を配信する ※ 図は、簡略化しています (Namespace / 制御メッセージの詳細など)
15. リレー間の配信情報管理 配信者と視聴者は、リレー越しに繋がる — 配信者が Track を配信する — リレーが Track 情報を把握する ※ 図は、簡略化しています (Namespace / 制御メッセージの詳細など)
16. リレー間の配信情報管理 配信者と視聴者は、リレー越しに繋がる — 配信者が Track を配信する — リレーが Track 情報を把握する — 視聴者が Track を購読する ※ 図は、簡略化しています (Namespace / 制御メッセージの詳細など)
17. リレー間の配信情報管理 配信者と視聴者は、リレー越しに繋がる — 配信者が Track を配信する — リレーが Track 情報を把握する — 視聴者が Track を購読する — 配信者から視聴者へデータが流れる ※ 図は、簡略化しています (Namespace / 制御メッセージの詳細など)
18. リレー間の配信情報管理 でも、同じリレーに繋がるとは限らない → どの Track がどのリレーにあるか、どうやって知るか?
19. ⼤きく 2 つのアプローチがある 1. 中央集権的アプローチ 2. ⾃律分散的アプローチ
20. リレー間の配信情報管理 どこかに記録しておけばいい (中央集権的アプローチ) — 配信が始まったら、「この Track はリレー A にある」と記録する — 購読が来たら、それを引いてリレー A に転送する — 動くしシンプルだが、SPOF になるので冗⻑化が要る
21. リレー間の配信情報管理 しかし、配信元のリレーに負荷が集中してしまう — 「配信元がどこか」だけを記録している — 購読を受けたリレーは、そこへ直接繋ぐ — リレーが 50 台あれば、配信元リレーは同じ映像を 50 本送る
22. リレー間の配信情報管理 こうなってほしい (多段リレー構成) — 途中のリレーが受け取って、その先に複製する — 配信元リレーは、下流のリレーにだけ送ればいい
23. リレー間の配信情報管理 経路を記録すればいいのでは? — 「配信元は A」ではなく「上流は誰か」を記録する — 購読はその上流へ転送され、辿ると配信元に届く But... — この経路は誰がどう決めるのか — リレーが増減するたびに、組み直すことになる
24. リレー間の配信情報管理 隣に伝える⽅式にすればいい (⾃律分散的アプローチ) — 配信情報を隣に伝え、受け取った側もまた隣に伝える (リレー同⼠は任意のトポロジで繋がっている前提) — 各リレーは「その配信がどの隣から来たか」を記録する — 購読が来たら、適切な隣に転送 → 繰り返すと配信者に届く But... — 独⾃プロトコル (MoQLite) が必要 — 伝わるまでに時間差がある
25. リレー間の配信情報管理 何を選択したか 中央集権的アプローチ moq-wasm (我々) ◦ ◦ moq.dev Cloudflare ⾃律分散的アプローチ ◦ — PoC の⽬的は「動かして学ぶこと」。スケールを作り込む段階ではない — 選択肢を把握したうえで、⼀番軽いものを選んだ — マルチリージョン構成等、規模が⼤きくなれば、別の判断になる
26. 1 リレー間の配信情報管理 2 QUIC/WebTransport のポート共有 3 QUIC-LB によるロードバランシング
27. QUIC/WebTransport のポート共有 ブラウザは raw QUIC を直接使えない (WebTransport 経由) — ブラウザ以外のクライアント (Native) は raw QUIC を直接使える — 下はどちらも QUIC なので、ALPN (接続時にプロトコル名を伝える仕組み) で区別できる → 待ち受けポートを分ける必要がない
28. QUIC/WebTransport のポート共有 まず raw QUIC、次に WebTransport — raw QUIC ベースで MoQ を実装した quinn (Rust の QUIC 実装のデファクト) を採⽤ — その後、WebTransport 対応を進めた wtransport (quinn ベースの WebTransport 実装) を採⽤ → 同じ QUIC 実装 (quinn) だから、素直にポート共有できそうだ
29. QUIC/WebTransport のポート共有 QUIC Connection を渡す⼝がない → プロトコルの問題ではなく、ライブラリ API の問題
30. QUIC/WebTransport のポート共有 先⼈が同じ問題を解いていた — 既存の MoQ 実装も同じ問題に直⾯しているはずだ — moq.dev では quinn と組み合わせられるライブラリを⾃作していた (web-transport-quinn) — 我々も web-transport-quinn に乗り換え、1 ポートで両⽅受けられるようにした → 新しいプロトコルの実装は、既存ライブラリの想定から外れることがある
31. 1 リレー間の配信情報管理 2 QUIC/WebTransport のポート共有 3 QUIC-LB によるロードバランシング
32. QUIC-LB によるロードバランシング 実現したいこと — クライアントは⼀番近いリージョンに繋がってほしい — リージョン内の複数台に、負荷分散されてほしい — IP が変わってもコネクションが維持されてほしい (QUIC Connection Migration) → 前段に LB を置くのが素直だが、QUIC だとどうなるか?
33. QUIC-LB によるロードバランシング L7 LB は QUIC を終端してしまう — L7 LB は HTTP を前提にしていて、raw QUIC が使えない — WebTransport over HTTP/3 は使えるが、LB が HTTP/3 を終端する — LB とリレー間は HTTP/1.1 か HTTP/2 になり、QUIC が使えない → LB には終端させず、パケットをそのまま転送してほしい
34. QUIC-LB によるロードバランシング では L4 LB なら? — パケットをそのまま転送するので、クライアントとリレーが直接 QUIC で繋がる — しかし、普通の L4 LB は 5-tuple ハッシュで振り分ける — IP が変わる (Wi-Fi → LTE 等) と振り分け先も変わり、別のリレーに届いてしまう → 5-tuple ではなく、コネクション単位で振り分けてほしい
35. QUIC-LB によるロードバランシング これを解決するのが QUIC-LB — 5-tuple ではなく QUIC パケット内の Connection ID を⾒て振り分ける — IETF でドラフトを策定している — 対応しているのは AWS のみ (GCP‧Azure は未対応) → しかし、我々の基盤は GCP ベース...
36. QUIC-LB によるロードバランシング 選択肢 コスト 諦めるもの QUIC-LB ⾃前実装 — 実装‧運⽤が重い AWS / GCP のハイブリッド構成 — 2 クラウドを運⽤ リダイレクト⽅式 — 接続時に 1 RTT 増える、 ⾃前振り分けロジック GeoDNS 負荷に応じた分散 リレーの IP 直接公開、 台数増減に伴う DNS 運⽤ GCP L4 LB Connection Migration —
37. QUIC-LB によるロードバランシング 何を選択したか — Connection Migration を諦めて GCP L4 LB を採⽤した — LB の完成度より、動くものを早く作ることを選んだ — LB 構成はアプリケーションから独⽴しているので、後から変更できる → 新しい技術の価値を最⼤限活かしたくなるが、待てるものは待つ
38. まとめ 1 仕様 リレー間の配信情報管理 中央集権 / ⾃律分散 → 実装者が決める領域 2 ライブラリ QUIC/WebTransport のポート共有 新しいプロトコルは、 既存ライブラリの想定から外れることがある 3 インフラ QUIC-LB によるロードバランシング 環境が整うのはもう少し先 仕様‧ライブラリ‧インフラ、それぞれの観点で 「MoQ は今こういう状態なんだな」と持ち帰ってもらえれば X: mti_daiki Mail: mti.daiki@gmail.com