SasSに依存しないWeb会議システム開発

2023/06/23 に開催された WebRTC Meetup Tokyo #24 で発表いたしました

SasSに依存しないWeb会議システム開発

の発表資料となります。
資料中の動画は下記の URL でご覧になれます。

https://drive.google.com/file/d/1uQMQNKwC7n_fegHIJOeNYANIzLjWPDD9/view

その他下記媒体でも発信しておりますので、併せてご覧いただければと思います。
twitter: https://twitter.com/meeting_dev
note: https://note.com/meetingdev
youtube: https://www.youtube.com/channel/UCaSd1LybkU2Ajv2h47F8TCw

WebMeeting Software Suite についてはこちら
https://meeting.dev/
体験は自動応答メールとなっており、入力いただいたメールアドレスへのセールスなどは行っておりませんのでお気軽にどうぞ！

Transcript

1. SasSに依存しない Web会議システム開発 テレコムプロフェッショナルサービス株式会社 みなもと たくみ
2. 自己紹介 みなもと たくみ 多分漢字まで一致する同姓同名はいないので、ひらがな表記にしました 仕事: ブラウザを使った WebRTC 開発 趣味: ブラウザを使わない WebRTC 開発 ISTP-T 型らしい
3. どの程度 WebRTC に詳しいの？ 無理やり Lyra を mediachannel に突っ込む悪行をやる程度には詳しいです
4. Web 会議システムを自社開発する理由 弊社には中国のオフショア子会社があるが近年の米中間の摩擦により、米国や中国で 様々な SaaS へのアクセスが制限されるようになってきた いずれは Zoom なども対象になるかもしれない Web 会議システムを自社開発すれば、このリスクを軽減しつつ、 同時に同じような懸念を抱えている会社に販売できるのではと考えた
5. Web 会議システムの機能
6. 会議周りの UI と機能 入室前画面 会議室画面 チャット 参加者一覧 画面共有 スマートフォン対応 仮想背景
7. 会議以外の機能 SMS 認証 外部システム連携 利用統計 会議ログ テナント機能 ダッシュボード 会議ログ詳細
8. Web 会議システムの構成
9. 概ね会議システムには以下のような要素が必要になる Web会議システムの必須要素
10. OSS SFU を用いた構成 OSS SFU は機能が豊富にもかかわらず認証や認可の機能がない場合がある できる範囲を狭める、別途必要な挙動を追加するために SFU コントローラを追加する 必要が生じることが多かった
11. 考えられる最小構成 SFU が Push メッセージングや状態保持ができる KVS のような機能を持っている場合 には、WebSocket サーバーを無くすことができ構成要素が減る SFU に TURN サーバーが内蔵されていると更に構成要素が減り、 Web アプリケーションの開発のみで会議システムを作ることが可能になる
12. Web アプリケーションの構成 WebRTC 周りは SFU が担当し、 SFU と Web アプリケーション間の連携は概ね HTTP で行われるため、 Web システム自体は特別なものにならない しかし、会議画面のフロントエンドは非常に複雑なシングルページアプリケーションとな り、Web システム本体コード量に匹敵することとなる 弊社のシステムでは大規模開発を円滑にすすめるため、 フレームワークに React を採用し、開発言語も TypeScript とした 弊社システムの構成 弊社システムのコード比率
13. 制御の例（入室シーケンス）
14. Web 会議システムの課題と解決策
15. なぜ SFU を使うのか P2P SFU 送信エンコーダ数 参加者数 - 1 1 CPU負荷 高 低 上りストリーム数 参加者数 - 1 1 下りストリーム数 参加者数 - 1 参加者数 - 1 参加者数上限 4-5 多 映像品質の最適化 ⚪ × 通信の確実性 × => ⚪(TURN) ⚪ サーバーコスト ⚪ × サーバー受信数 TURN利用者分 参加人数分 ※ Proxy を介した環境との通信は TURN サーバーが必須 P2P の場合 SFU の場合
16. Simulcast 送信元からは複数の画質でエンコードを行い SFU に送信しておき、 受信側の回線品質や負荷に最適な品質で配信を行うことで映像品質を保つ エンコード数は 3 本になるがエンコード量が3倍になるわけではない ※解像度やフレームレートを落とすので 1.3 倍くらいが目安 Simulcast あり Simulcast なし
17. 選択的配信 参加者の全員を表示すると、 画質を下げていても人数が増えた際に CPU や帯域の上限に達してしまう SFU とメッセージングを行い表示している ストリームのみ受信するなどして軽減する さらに Simulcast を組み合わせ発言者の みを高画質で受信することで制約の中で ユーザー体験の向上を測る ページングと SFU の協調動作 Simulcast とスピーカー表示
18. デモ動画 発表で表示した実際の Simulcast と選択的配信の動画はこちら https://drive.google.com/file/d/1uQMQNKwC7n_fegHIJOeNYANIzLjWPDD9/view
19. 音声ストリーム数上限 Chrome のオーディオ出力には上限数がありかなり厳しい値になっている Audio ストリームを audio や video タグに設定する度カウントが上がり、 上限を超えた分の Audio ストリームは出力されない 回避するには以下の手段が挙げられる • SFU 側で発言者のオーディオストリームを出力するように制御する • 発言者の Audio ストリームのみを出力するよう JavaScript で制御 ◦ ミュートを解除できる人数を 10 人に制御する ◦ SFU からの発話検出 Push メッセージをトリガーにする [46443:259:0116/001736.815182:ERROR:audio_manager_base.cc(214)] Number of opened output audio streams 50 exceed the max allowed number 50
20. サポートコストの軽減 様々な対策を行っても問題は起きる。代表的なものとしては • 遅延する • 画質が悪い • 音が聞こえない 原因は概ね以下に集約される • ネットワーク環境 • カメラ、マイク、スピーカーの問題 • OS、ブラウザの不具合 これらに迅速に対応するためシステム側で情報を収集しておく
21. WebRTC SFU 開発の検討
22. SFU を作るモチベーション コスパが悪いため、SFU を作るのは事業における最終段階で良いと思う • WebRTC のプロトコルスタックは重厚で人的リソースの消費が大きい • 通信コストが支配的で計算コストを削減してもメリットが小さい OSS を活用して初期開発コストを下げることもできる • ブラウザの更新によって発生する不具合への追従が難しくなる • 機能が多すぎてシステムとしての隙ができやすい • 開発するシステムが強く依存しリプレイスしにくい サポートコストや運用コストを考えると商用製品や SaaS を選んだ方が良い
23. WebMeeting Software Suite の SFU SFU には 時雨堂 Sora を採用している • 人件費に対してライセンスが安価 • ソフトウェアとして提供されるため自社運用可能 • KVS に当たる機能や Simulcast 制御も充実 • 多くの採用実績がありサポートも期待できる しかし海外企業へは販売していないため Sora 互換 SFU を開発することとした • ちょっとやってみたかった • システムが Sora に強く依存している • SFU 以外の部分を Sora を使って開発でき、問題の切り分けがしやすい • Sora の SDK が使える
24. SFU を作る ゼロから作るのは投資対効果が悪いと考え OSS をベースとすることとした しかし、これまで述べたような Sora 固有の処理も多用していたため、 OSS をそのまま使うのは早々に諦め、改造することを前提とした • mediasoup ◦ SFU ◦ node, C++, Rust • janus ◦ SFU ◦ C, GObject • LiveKit (ion) ◦ SFU ◦ Go • 開発言語の難度が高い • 機能も豊富 メンテナンスコストから難しいと判断 • フォーク元の ion は機能が多くない • ベースは WebRTC Client の pion でそれなりに疎結合 • GC がある言語だし、まだなんとかなりそう
25. Sora に近づけるための変更
26. ion と Sora の PeerConnection ion が送信と受信で PeerConnection が分かれているのに対し、 Sora は送受信に同じ PeerConnection を使っている そのため ion の構造を大幅に変えて PubSub に集約させて Sora 同様にした ion の PeerConnection Sora の PeerConnection
27. Simulcast とビットレート制御 ブラウザは Simulcast で送信している時、帯域が不足す ると高画質の配信を停止するが、この時に問題が発生す る ion の帯域推定の計算方法では、低画質に一度なると高 画質に戻ることができない ➡帯域推定は書き直す 高画質映像を停止した配信者の高画質映像を受信してい る受信者がいた場合、その映像は停止する ➡低画質に自動的に切り替えるようにする 200kbps 上限での帯域推定結果 発表後変更
28. その他の Sora を再現するための変更点 Sora に似せるための変更 • pion の Offer に Simulcast を追加する • シグナリング形式を同じに • 認証 WebHook、イベント WebHook、制御 API の追加 • Simulcast 制御をNACKカウントから任意制御に変更 • AudioLevel で Simulcast を制御する機能を追加 Sora はアプリケーションサイドの開発を容易にするために イベント WebHook やシグナリングに順序保証がある 同じ実装を行おうとするとデッドロックやパフォーマンスの原因になりやすい 発表後変更
29. コード量を減らすための妥協 メンテナンスコストの増加を避けるため、 表面的な挙動に影響がない機能については妥協することとした Sora にはあり使っているが実装しなかった機能としては、 • DataChannel 経由の Signaling ◦ WebRTC よりも WebSocket は切れやすい • 帯域推定 ◦ 所定の動作を満たすことを着地点として研究はしていない • 負荷の軽減 ◦ Sora のように不要な処理は止めて負荷を軽減することはできていない • Stats の収集 ◦ 会議ログ機能で十分と考えた 発表後変更
30. 最後に WebMeeting Software Suite はソースコードで販売する Web 会議システムです • 社内 Web 会議システムを持ちたい • 自社のサービスに Web 会議機能をつけたい • Web 会議のサービスを立ち上げたい といった、要望にお答えします。 これまで述べた以上のノウハウをたくさん詰め込んで、 きっと 1 から作るよりも、エンジニアを雇うよりも安い金額で販売しております ぜひ meeting.dev にアクセスして試してみていただければと思います！
31. EOF