メタバースの技術限界
2021/12/23に行われたe-ZUKA Tech Night vol.53 -メタバース-というイベントで、「メタバースのビジネスモデルと技術限界」という題名で発表させてもらいました。
その発表後、Qiitaの方でも解説をして欲しい。という要望があったので、「メタバースの技術限界」について解説をしようと思います。
スライド：メタバースのビジネスモデルと技術限界
サンプルコードで学ぶVRMメタバース開発
先述したイベントでメタバース開発の解説書を執筆中。という告知をさせていただいたのですが、この度、技術書典12で販売開始いたしました。
サンプルコードで学ぶVRMメタバース開発
https://techbookfest.org/product/4515940253302784?productVariantID=5414675917307904
「サンプルコードで学ぶVRMメタバース開発」https://t.co/MEaXpQEVsz
— こたうち@VRMメタバース開発本販売中！ (@kotauchisunsun) January 22, 2022
という本を #技術書典12 で販売開始しました❗️❗️
🟢ソースコード完全無料公開
🟢改変可・商用利用可
🟢VRMアバター対応
『あなたのセカイはあなたの自由だ』#技術書典 #メタバース
書籍「サンプルコードで学ぶVRMメタバース開発」発売 ソースコード完全公開の解説書https://t.co/yNxUXFHLS4 pic.twitter.com/2XtjdqE98h
— PANORA (@panoravr) January 22, 2022
メタバースを…自分で作る！？マジで下地だけど、プログラミングで自由自在に対応可能な自分だけの世界！将来、一人一人が自分のプラットフォームを作るなんて未来も、あるのかもしれんな…
— リーチャ隊長🌱 (@rietzscha) January 24, 2022
↓こたうちさんの本
『サンプルコードで学ぶVRMメタバース開発』https://t.co/I8rWvlCAEx#VRC動画 #VRChat pic.twitter.com/Rw9QEZyIQl
メタバースとは何か
色々な方が色々な定義をしていますが、割とフラットな定義としてJOSYORIというサイトの定義を引用します。
多人数が参加でき、そのなかで自由に行動できる仮想空間。3D技術や拡張現実（AR）によって、インターネット上に構築される。ユーザーは、「アバター」と呼ばれる自分の分身を操作して、その空間内で、他のユーザーと交流できる。
ざっくりと言うと、
- アバターが使える
- 多人数でコミュニケーションがとれる
これらの2つが要素として挙げられます。
代表的なサービスとして、VRChatの動画を貼っておきます。
通信速度限界からみるメタバースの限界
日本のスマホ回線の通信速度
メタバースをスマホ回線で利用するとします。
総務省の「実効速度に関するガイドライン」に準拠した形で通信業者各社が、主要都市における通信速度に関する統計情報を公開しています。
au: https://www.au.com/mobile/area/effective-speed/#android
docomo: https://www.nttdocomo.co.jp/area/effective_speed/
softbank: https://www.softbank.jp/mobile/network/service/speed-survey/
これらの情報は、Android,iOSのOS毎に、通信速度の最小値、第一四分位数、中央値、第三四分位数、最大値が公開されています。
| キャリア | OS | 区分 | 最小値(Mbps) | 第一四分位数(Mbps) | 中央値(Mbps) | 第三四分位数(Mbps) | 最大値(Mbps) |
|---|---|---|---|---|---|---|---|
| au | android | 下り速度 | 26 | 93 | 123 | 161 | 405 |
| au | android | 上り速度 | 1 | 12 | 19 | 27 | 64 |
| au | ios | 下り速度 | 17 | 88 | 124 | 170 | 429 |
| au | ios | 上り速度 | 2 | 13 | 19 | 28 | 67 |
| docomo | android | 下り速度 | 13 | 168 | 237 | 299 | 430 |
| docomo | android | 上り速度 | 2 | 23 | 35 | 45 | 62 |
| docomo | ios | 下り速度 | 3 | 154 | 221 | 298 | 548 |
| docomo | ios | 上り速度 | 2 | 21 | 30 | 38 | 61 |
| softbank | android | 下り速度 | 36 | 97 | 140 | 172 | 284 |
| softbank | android | 上り速度 | 1 | 11 | 17 | 23 | 31 |
| softbank | ios | 下り速度 | 33 | 90 | 129 | 163 | 350 |
| softbank | ios | 上り速度 | 1 | 13 | 19 | 24 | 32 |
この表で、強調されているのは、上り最低速度と下り最低速度です。
第一四分位数ではauのiosの下り速度が88Mbpsで最低です。
また、同様に第一四分位数ではsoftbankのandroidの上り速度が11Mbpsで最低です。
ここから分かることは何でしょうか？上記3社で日本の通信インフラが近似できるのであれば、人口の25%程度は下り速度は88Mbps未満、上り速度が11Mbps未満です。
(Android,iOSのシェア割合と、各種通信社のシェアの重みづけで、おおよその四分位数は計算できますが、簡単のため最低値で近似しています)
少し乱暴な言い方をすると、下り速度を89Mbps、上り速度を12Mbps以上にすると、人口の25%がメタバースを快適に使えません。
したがって、日本の人口の75%にメタバースを普及させたいのであれば、下り速度は88Mbps未満、上り速度が11Mbps未満の通信速度にする必要があります。
もう一段上げるとすると、通信速度を下り123Mbps未満、上り17Mbps未満に抑えると、日本の人口の50%にアプローチ出来ます。
トラッキングに関わる通信量
では、トラッキングのデータ通信がどれくらい通信速度が必要なのかを考えます。
ここでは、float型4Byteとして考えます。1つのトラッキングポイントに対し、x,y,zの位置座標とそれぞれの角度が必要と考えて6つのデータが必要になります。
これらのデータを30fps,60fpsでデータを送ることを考えます。
| 1項目あたりのデータ量(Byte) | 1項目あたりの自由度 | トラッキング数 | fps | １人当たりのデータ通信量(kbps) |
|---|---|---|---|---|
| 4 | 6 | 3 | 30 | 16.88 |
| 4 | 6 | 10 | 30 | 56.25 |
| 4 | 6 | 3 | 60 | 33.75 |
| 4 | 6 | 10 | 60 | 112.50 |
これらの試算から、1人あたりのトラッキングによる通信量はおおよそ16.88kbpsから112.50kbpsと考えられます。
スター型ネットワークの場合
ここでメタバースでスター型のネットワークを採用することを考えます。
どのような構成かというと、クライアントがトラッキングデータをサーバーへ送信します。各クライアントへのトラッキングデータの送信はサーバーが行います。
こうした構成を行う場合、全てのクライアントのデータがサーバーを介し、各クライアントへ流れ込みます。そのため、通信速度は下り速度がボトルネックとなります。ここでは人口75%ラインの88Mbpsを上限として考えます。
先ほどの1人当たりのトラッキングに関わる通信量から算出すると、スター型の場合、801～5,340人が通信の限界になります。
フルメッシュ型ネットワークの場合
一方で、サーバーを介しないクライアント同士が直接つながるフルメッシュ型のネットワークの構築を考えます。
こうした構成を行う場合、クライアントは自分以外のクライアントへ、トラッキングデータを送る必要があります。一般的に下り速度>上り速度となるため、上り速度がボトルネックになります。ここでは、前節と同様に人口75%ラインの11Mbpsを上限として考えます。
前節と同様に算出すると、フルメッシュ型の場合、100～667人が通信の限界になります。
通信にかかるCPU負荷からみるメタバースの限界
前章では、スマホの通信速度の限界から人数の限界を考える取り組みを行いました。
この章では、CPU負荷という面から考えます。
メタバースのクライアントはスマホと似たスペックの端末で動くことを仮定します。
OSSのメタバースであるMozilla Hubsには、AWSのCPUインスタンスとその接続人数の目安が書かれています。
https://hubs.mozilla.com/docs/hubs-cloud-aws-estimated-ccu-limits.html
ここで、iPhone13のスペックを考えるとCPUは6コア、クロックは3.18GHz、メモリは6GBだそうです。
これと近いAWSのインスタンスを調べると、t3.large,t3.xlarge,t3.x2largeになります。これらのデータと近い値と比べると、CPU負荷の限界的には45～80人が限界である。ということが分かります。
もちろん、AWSのこれらのCPUはIntelですし、iPhoneはARMです。OSすらも違います。そのため、かなり強い仮定を置いています。そのため、この値は、参考にするならばこの値。一切情報がないよりマシ。ぐらいの精度の近似です。
キャラクター描画限界からみるメタバースの限界
先の定義で見たようにメタバースの要件としてアバターの利用というのがあるようです。
そこで、VRMを何体か表示する簡単なアプリを作り、スマホ上で動かしてみました。その結果、アバターの表示数とfpsがどのように変化するのか？をベンチマークしてみました。
手元にあった2端末でベンチマークを取りました。Pixel4は7体ぐらいまでは90fpsを保持していましたが、11キャラぐらいで60fpsを割り始めました。30fpsを保持できるのは22,23体ぐらいまでのようです。
SO-02Gは、14体ぐらいまでは60fpsを保持しています。それから、だらだらとfpsが下がり、30fpsを保持できるのが、大体25体ぐらいまでです。この2つの端末は少し古めなので、現行の端末であれば、もう少し数字が伸びると思います。
したがって、何もチューニングされていないVRMアバターの描画限界は15体から30体程度であることが分かります。
clusterのドキュメントでワールドには25人という制限がついています。(イベントとワールドの違い)
こう見るとかなり合理的な戦略であることが分かります。
メタバースの技術限界の総括
- アバター表示による同時接続の限界は15～30人
- 通信によるCPU負荷による同時接続の限界は45～80人
- スマホの通信による同時接続の限界
- メッシュ型100～700人
- スター型800～5,300人
したがって、
アバター表示による限界 > 通信によるCPU負荷 > スマホ回線の限界
という順番で、アバター表示による限界が一番ボトルネックになっています。
メタバースを適当に作ると意外にアバターの描画コストも辛いのです。
ハシラスさんがめちゃバースというPC向けのサービスを行っています。
簡易的なアバターではありますが、1インスタンス3,000人が入れるそうです。こういう事情を踏まえると、3,000人規模の同時接続では、端末のスペック的にも簡易アバターにせざるを得ない。ということが分かると思います。
メタバースの現実への適応
ディズニーランドをメタバースへ作る
2018年度のディズニーリゾートへの入場者数は3,255万人だそうです。リンク
開園時間が、ディズニーランドが9:00～21:00、ディズニーシーが9:00～21:00で、1日の営業時間が12時間です。
これらの値から立式すると、1分間の入場者数は、平均123人/分となります。
3,258万人 / 365日 / 12時間 / 60分 = 平均123人/分
いわゆるパレードなどの密集や繁忙期は難しいかもしれませんが、平均123人/分(=同時接続数123)であれば、簡易アバターであればハードの進化で5,6年ぐらいの間にスマホでメタバースのディズニーランドは再現可能かもしれません。
武道館ライブをメタバースで行う
武道館の収容人数は14,471人です。端的に言うと普通は無理です。
前述したとおり、一番緩いスター型の通信限界ですら、5,300人です。それも超えているので、全てを同期する武道館ライブは不可能です。
したがって、「ユーザーは完全な簡易アバターのみ」「近くにいる人のみトラッキングが同期する」「トラッキングは位置と回転のみで手足のトラッキングはなし」「クラウドレンダリングして動画だけストリームする」といった、結構な工夫がないと難しいということが分かります。
まとめ
この技術限界という話は割とたまたま生まれた内容です。
別のビジネス企画で事業計画を引いた時に、「多くの人がPCで作業できない。スマホしか持っていないから無理。」という話を聞きました。そういうことを考えていた場合、PCのVRによるメタバースは傍流ではないか？という疑念がありました。そんなことから色々な統計資料を漁っていました。
総務省のデータによると、PCの普及率は70.1%、スマホの普及率は86.8%です。確かに、PCの方が割合が少ないですが、大差であるか？と言われると、ちょっと微妙かな？というイメージがありました。
では、通信速度はどうなのだろうか？最近の5Gの流行もあるから、割合にいいデータが転がっているのではないか？という予感がありました。そうすると、かなり精緻なデータを見つけてしまったので、これをベースに"通信のインフラの限界"を語れるのではないか？と思い始めました。
また、Mozilla Hubsの公式のドキュメントを見ていると、AWSのインスタンス種別による同時接続数というなかなか貴重なデータが置いてあったので、"CPUの性能による限界"っていうのも、大体分かるなぁという感じでした。
以前、VZeroというメタバースを作ったときに、VRMアバターをそのまま普通に使ってしまうと描画コストが高い。ということはわかっていたので、割と早いうちに頭打ちになりそう。という予感はありました。では、実際のアバターの描画の性能限界は？と、なったわけですが、これが情報が無い。ゲームは、それぞれの中身によってチューニングするので、あまりこういうデータは外に出てこないようです。では、作るしかないか・・・と思って、ベンチマークをするソフトを作ってみたら、それが割合簡単にできてしまったので、じゃあ1つの章にまとめあげよう。と思ったのが、これです。
したがって、まとめ上げられたのは「イイ感じにピースが転がっていたことに気づけた。」という運みたいなところが多かったです。
こういう調査をすると、色んなサービスのドキュメントを見たり、大人数を謳うサービスの制限を見に行くことになります。そして、その内容と、自分のベンチマークが合い始めると、あぁ。やっぱり各社すごく調査をしていたり、それぞれの制約をかいくぐるために非常に努力しているのだな。というのが、よくわかります。
そうすると、技術の解像度が一気に上がって、サービスが行ってる変な制約は、何かしらのボトルネックがあるんだろうなぁ。ということが分かるようになってきます。今回、調べて見て、clusterの25人制約は、サーバー由来の通信負荷というより、おそらくスマホ側のアバターの描画負荷が辛いんだろうなぁ。ということを感じれたのは非常に勉強になったなぁと思いました。
この検証内容はあくまで仮定です。これは、何も考えずに素直に実装すると、この辺の制約に引っかかります。したがって、これ以上のことをしようとすると工夫が必要になるだろう。という見方をするとよいと思います。例えば、アバター描画検証であれば、30体以上のアバターを表示するには、LODの処理を行い、遠景のモデルは荒いモデルにすることでアバター表示数を稼ぐ。ということも考えられます。そういった機能の取捨選択に役に立てればよいなぁ。と思います。
なんにせよ。作ってみれば分かることも多いです。作ってみてベンチをとったりすると、各社の制約というものは、どれくらい合理的な選択であるかも見えてきます。そして、少なくとも「メタバースは作ること」はスタート地点に過ぎません。それを「どう育てるか？」「どう運用するか？」「どう進化させるか？」その難しさも感じてみるのもを良いと思います。