意外と過疎なのか?メタバースの定員人数とは

意外と過疎なのか?メタバースの定員人数とは

パソコンやスマホからメタバースを訪問した人が共通して感じるのは「話題だと聞いてやって来たが、意外と参加者が少ない」ということかと思います。これはメタバースの仕組み上の制約によるもので、この制約は今後メタバースが普及するにつれ大きな課題になるポイントです。
メタバースプラットフォームのシステム構成について各事業者からの情報がほとんど公表されておらず、この定員人数の課題は利用者には理解が難しい状況ですが、この記事では、メタバースプラットフォームの構成から、この定員人数の制限について考えて行きます。

メタバースはデータが大量発生する?

メタバースプラットフォームの構成模式図
(「メタバースのシステム構成論」†1より)

上図は、1つのメタバース空間へ左端3人のクライアントが同時接続している様子を表しています。

メタバースはClient-Sever型の集中管理方式サービスで、従来から存在する一般的なネットワークサービスとシステム構成は同型です。

ただし性能面でメタバースは従来サービスとかなり違いがあり、特にクライアント端末間で大量の同期データが発生してサーバーに大きな負荷が掛かるのが特徴です。例えば3人のクライアントが同時に同じ空間(と互いに思っている場所)を見ているとすれば、誰か1人の行動は他の2人にも観察されるため、クライアント間で反映用のデータが大量発生します。

この同期によるサーバー負荷は、同一空間に何人のユーザーを収容するかにより極端に増減するので、メタバースプラットフォーム事業者としてはピーク性能を目安にサーバー設備を増強していたら過剰投資になってしまいます。そのため需要の変動に対応できるよう、サーバーは実ハードのマシンではなくアマゾンAWSなどのIaaS (Infrastructure as a Service)型クラウドサービスの仮想マシンを利用せざるを得ません。

例えばアマゾン ウェブ サービス ジャパン主催のAWS SUMMIT ONLINE 2020でのメタバースプラットフォーム事業者Clusterの発表資料「バーチャルSNSの裏側」( https://pages.awscloud.com/rs/112-TZM-766/images/CUS-64_AWS_Summit_Online_2020_cluster-inc.pdf )によると、Clusterは仮想サーバーとしてAWSを利用しており、ユーザー間同期処理にIoT(Internet of Things、モノ同士でのネットワーク越しの通信)分野でよく用いられるMQTTという軽量通信プロトコルを利用した MQTTサーバーを導入しているとのことです。またこのMQTTサーバーを需要に応じて自動で動的スケールアウト(担当する仮想マシンを台数単位で増やすこと)する対応を行っていると発表しています。

 参考文献「メタバースのシステム構成論」
(総務省 https://www.soumu.go.jp/main_content/000822521.pdf

同期処理の負荷を軽減する対策とは?

メタバースの同一空間にどんどんユーザーを収容し続けていると、同期データは組み合わせ数爆発によりどんどん大量発生していきます。かといってメタバースで大規模なイベントを開催すれば、人気次第では数百人~数千人の集客が発生するので、そのままではいくらサーバー性能があっても足らない苦しい状況に陥ります。

サーバー負荷軽減対策として考えられるのは、

  1. 同一空間の収容人数に制限を設け、同期に必要なサーバー負荷を一定レベルに抑制する
  2. 複製空間を作り、ユーザーを分散収容する
  3. 良く言えば同期処理の間引き、悪く言えば手抜きをする

あたりとなります。

このうち1、2は、下図右側のように4人のクライアントを2人+2人に分け、それぞれを複製したメタバースに収容する対策です。これにより、同一空間4人で同期が必要な作業組み合わせ(計12通り)を、2つの複製空間×2人間の同期作業(計4通り)へ軽減することができます。

メタバースにおける仮想世界の複製
(「メタバースのシステム構成論」より)

ただこれを実行すると、本来4人が出会うはずの空間に、自分ともう1人の計2名しか見当たらないことになります(残り2人は別の複製空間にいる)。この現象が「メタバースは過疎?」という誤解を生むことになります。なお負荷軽減対策③については、後述のClusterの項で説明します。

負荷軽減対策の具体例を紹介

実際の事業者による負荷軽減対策①②の例について見て行きましょう。取り上げるのは、メタバースVRChatとClusterの2事例です。

VRChatの事例

下図は、VRChatの人気メタバース「Japan Shrine」での、ある日時の活動状況を表しています。表示からこの時点で96人のユーザーがメタバースへ参加していることが分かります。一方、このメタバースは同一空間あたりの定員が16人に制限されているので全員を同一空間に収容するのは不可能です。この時点では、1~14人で構成されるユーザーのグループが9個の複製空間に分かれて参加しています。既存の空間に参加したい場合、既存の複製空間の現ユーザーに招待(Invite)して貰う必要があります。もし知り合いがどの空間にもいなければ10個目の新規の複製空間を立ち上げることになります。

VRChatのメタバース同一空間・複製空間の選択

同一空間・複製空間どちらへ参入したいのか、VRChatはユーザーが選択できます。これは例えばメタバースを対戦ゲーム実行の場として取り扱うには、同一空間に仲間全員を丸ごと収容すること・部外者を同一空間に収容しないこと、が重要になるためと思われます。

VRChatの定員制限は柔軟に適用されています。「soft-cap」「hard-cap」という2つの制限値があり、通常、ワールドの説明文に表記されている定員数「Capacity」はsoft-capの方を示します。この制限を超えて同一空間に参入しようとすると、今度はsoft-capの2倍値(現状)であるhard-cap制限が適用され、ワールドの作成者・複製を実行した参入者・それらのフレンド(だとお墨付きを得ている招待された関係者)が優先して同一空間に収容されるしくみです。( https://docs.vrchat.com/docs/creating-your-first-world#step-5—building-your-world )。

Clusterの事例

別の事業者であるClusterにも、同一空間・複製空間どちらを選択するかの機能が備わっています。Clusterの人気メタバース「小小的海底世界」を例に、ユーザーがメタバースへ参入するときの選択肢について見てみます。

Clusterのメタバース同一空間・複製空間の選択

メタバースへの参入画面でそのまま「遊びに行く」を選択すると、なるべく同一空間へ参入させようとしますが、そのメタバースの定員制限に達していると別の複製空間への参入が促されます。ただし「新しいサーバで遊ぶ」を選択すると初めから別の複製空間へ参入させるよう対応が変化します。

Clusterの場合、定員制限の適用はVRChatよりもシンプルで、同一空間の定員は最大25人、ワールド作成時のデフォルト定員設定は10人となっています。

VRChatと比べると同一空間の定員数が少ないのでは?と感じますがClusterの場合、別の対策として独自の「イベント開催」という形態が用意されており、他事業者とは異る多人数ユーザーに対応した使い方ができるようになっています。

https://clusterhelp.zendesk.com/hc/ja/articles/360040448572-%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%81%A8%E3%83%AF%E3%83%BC%E3%83%AB%E3%83%89%E3%81%AE%E9%81%95%E3%81%84 )。

Clusterのイベント開催の定員数は、一般公開イベントなら500人、限定公開イベントなら50人まで同一空間に参加可能とあります(イベントスタッフ・ゲストについては別カウント)。

まじめにユーザー間同期を行おうとすると、特に一般公開イベントの方の人数制限500人は組み合わせ爆発によりサーバー負荷が心配になる数値ですが、Clusterではイベント参加者が先着順で100人を超えると、それ以降の参加者を同一空間に収容するものの「ゴースト」というメタバース空間に作用しない(アイテムを掴めない・他者と衝突が起こらない・入退出が検知されない)存在として扱われます。これにより同一空間あたりの同期データ量発生を100名参加レベル程度に抑え込むやりくりを行っています。

( https://docs.cluster.mu/creatorkit/event/event-world/ )。

まとめ

以上見てきたように、現状のメタバースプラットフォーム事業者は利用できるコンピューティングパワー制約のため、理想とは遠い状態でサービス提供しているのが実情です。この制約の緩和について、インテル社は「(世界規模で)メタバース需要が拡大し続けると、(データセンターの)計算効率を1000倍に向上させる必要がある」とコメントしています。

( https://www.intel.co.jp/content/www/jp/ja/newsroom/opinion/powering-metaverse.html )。

つまりメタバースによるサーバー需要の高まりがGAFAM(Google・Amazon・Facebook・Apple・Microsoft)への需要を爆発的に拡大させ、データセンター処理ビジネスの多くが同期処理で占められるようになるとの考察です。GAFAMへの処理需要が今後も現状レベルに留まるのか、それともさらに飛躍的に拡大するのかは、メタバースによる新需要が創出されるかどうか次第になります。GAFAMやインテルがメタバースを一時のブームと軽視せず、投資し続けている動機はこのあたりにありそうです。

今後もこちらでは、NFT関連の役立つ情報をお届けしていきます。NFTや暗号資産など、ブロックチェーン技術にご興味のある方は当社に是非ご連絡ください。

NFT解説カテゴリの最新記事

NFT GUIDEをもっと見る

今すぐ購読し、続きを読んで、すべてのアーカイブにアクセスしましょう。

続きを読む