- 日時
2022-09-16
- 作
- バージョン
2022.3.0
この資料は 2022 年 10月 25 日(火)・26日(水) に行われる SYNC 2022 の発表資料です。
WebRTC x Unity コトハジメ | SYNC 2022
時雨堂という会社でミドルウェア製品を担当しています。
Twitter ID は @voluntas です。
今回は WebRTC を取り巻く環境と Unity との組み合わせを簡単にお話できればと思います。
WebRTC はブラウザ上で音声や映像、その他データをリアルタイムにやりとりをすることを実現する技術です。
WebRTC の RTC は Real-Time Communication の略です。この技術はコミュニケーションに特化した技術です。 メジャーなブラウザはすべて実装しており、オープンな規格です。
特化といえば響きはいいですが簡単に言うならインターネット越しで会話をするための技術です。 皆さんが使われている Zoom や Teams や Google Meet、 Discord などが RTC 技術を利用しています。
WebRTC はこの RTC 技術の仕様を決めてブラウザ同士 (例えば Chrome と Safari) で利用できるようにしています。
コミュニケーションで一番重要なのは実は「遅延しないこと」です。相手の言ってることが 5 秒後くらいに送られてくるとコミュニケーションが難しくなります。
そのため WebRTC は「遅延しないこと」を最優先にしている仕組みです。
WebRTC では UDP を利用しています。つまり TCP のように「届いたかどうかを確認してから次を送る」のではなくもうひたすらデータを送ってしまいます。
UDP を利用する事で TCP で発生しうる詰また時に後続が待ち状態になるということが、 プロトコル上では起こらなくなり、遅延が起きにくい仕組みになっています。
ただ WebRTC はとても複雑な仕組みですので、そこを学ぶのにはかなりの覚悟が必要です。
WebRTC は P2P つまり 1 対 1 を前提とした技術になっています。 これはリアルタイムコミュニケーションを実現するのに一番最適な方法をとってるためです。
複数人数で WebRTC を利用する場合はそれぞれの人と 1 対 1 で通信を行う必要があります。 5 人いれば 4 人の人と通信をそれぞれに行うことになります。
人数が増えれば増えるほど通信する相手が増えていきます。ここは P2P の弱点でもあります。
WebRTC は Web とついてますがブラウザだけの技術ではありません。 むしろブラウザ以外の iOS や Android アプリ、デスクトップでも活用されています。
オープンなプロトコルとして一番利用されているというのが理由になると思います。
よく独自技術をうたう企業がありますが、独自技術は十分検証されていないことやベンダーロックになりがちです。 WebRTC はオープンな規格で、さらにメジャーなブラウザや多くの企業が採用しています。
またブラウザでリアルタイムを実現するには結局 WebRTC を使う必要があるためです。これは独自技術を採用している場合でも一緒です。
ここまで WebRTC の紹介をしてきました。 P2P でブラウザやライブラリがあるなら、それを使えばいいではないかと思われた方も多いのではないでしょうか。
ただ残念ながら WebRTC が商用で使われている環境では P2P はほぼ使われておらず、 サーバ経由の特殊な WebRTC が採用されています。 Discord や Google Meet では P2P を採用しておりません。 その代わりに SFU という仕組みが採用されています。
WebRTC SFU はすべての通信を P2P ではなくクライアントサーバーモデル、つまりサーバ経由にしてしまうという仕組みです。 下の図のようにすべての通信をサーバ経由で行います。
P2P が採用されず SFU が採用される理由は繰り返しになりますがクライアントの負荷が一番の問題です。 1:1 以上の参加者がある場合は結局残りの全員に音声と映像を送らなければならないという状況でのクライアント側の負荷を解決することが非常に難しいためです。
P2P の場合は 5 人が参加していたら 4 人に送る必要が出てきますが SFU を採用すれば SFU に送るだけで良くなります。 クライアントの負荷は送信だけで 1/4 になります。 SFU を採用することで参加者が増えれば増えるほど P2P と比較してクライアントの送信負荷が低くなっていきます。
また、サーバである SFU はマシンスペックや回線を上げることは出来ますが、端末は簡単にマシンスペックや回線を上げることはできません。 誰もが利用するリアルタイムコミュニケーションの場合は端末を指定するのは現実的ではありません。
もう一つの問題としてはコントローラブルではなくなるという問題があります。P2P で直接やりとりが入ってしまうと、 サーバー側が干渉することが難しくなります。 商用利用でサーバーが干渉できないのは致命的です。
このため元々の想定されていた WebRTC P2P は商用環境では採用されず、WebRTC SFU が採用されるのが一般的です。
SFU が出てきた当初は SFU はクライアントサーバならではの問題はいくつかありましたが、今ではほとんど解消されてきています。
時雨堂では WebRTC SFU Sora というパッケージ製品を提供しています。
世にある WebRTC as a Service はほとんどが WebRTC SFU を気軽に使えるようにするサービスです。
多くが従量課金方式で分単位や転送量での課金モデルを採用しています。
セットアップが不要で簡単に始められ、自分たちで WebRTC に関することを考える部分を減らせるというのがメリットです。 最近はよほどの理由がない限りはこのパターンを採用するのが多いと思います。
時雨堂では Sora as a Service という WebRTC SFU Sora の SaaS を提供しています。
Unity の世界でも WebRTC は有用です。ただ Unity の世界で使うにはなかなか大変です。 その大変さを肩代わりしてくれるのが Unity 公式が WebRTC ライブラリです。
libwebrtc という Google が主導で開発している、WebRTC ライブラリを Unity に向けてラップしたライブラリです。基本的にはこれを使えば困ることはありません。
ただし WebRTC を利用する際に情報を交換するために必要な「シグナリング」と呼ばれる部分は実装されていないため、この部分は自分で対応する必要があります。
シグナリング自体は難しい実装になることはほとんどありませんので、そこは心配する必要はありません。
WebRTC を利用するに当たってとても重要なのがハードウェアアクセラレーターです。 これは簡単に言えば「映像のエンコードやデコードを専用チップで行うことで CPU 使用率を抑えることができる」仕組みです。
このハードウェアアクセラレーターの恩恵はすさまじく、有り無しでは CPU 使用率が全く違います。 CPU 利用率が 1/10 になる場合もあります。
これらのハードウェアアクセラレーターに Unity 公式は対応しています。
Unity の魅力はマルチプラットフォーム対応です。ただ WebRTC が難しいのはマルチプラットフォームへの対応です。 つまり WebRTC を使うとマルチプラットフォームへの対応がとても大変になります。
iOS / macOS / Android / Windows / Linux と最低でも 5 環境に対応する必要があります。要望によっては Web にも対応する必要があるかもしれません。
これらの複数プラットフォームにも Unity 公式は対応してます。安心して Unity で WebRTC を採用することが出来ます。
WebRTC で Hololens2 を利用したいという話があったりします。 ただ Microsoft が公式ライブラリの開発を終了してしまいました。
そこで時雨堂ではお客様の支援を得て、Sora Unity SDK を Hololens2 に対応しました。
オープンソースで公開していますので、もし興味ある方がおられたら是非使ってみてください。