 を用いた分散型メタバースサーバにおけるレスポンス性能に関する評価
理学専攻 情報科学コース

松原 麻佑 指導教員  小口 正人
表 "   サーバモジュールの役割

はじめに
メタバースサービスは，インターネット上に構築された現実世界に似た仮想３次元空間を指す．その空間に接続することで，よりリアルに，より容易にコミュニケーションを実現出来る場所を提供するものである．
近年，ブログや  が浸透し，ユーザが情報サービスに対して発信者であり創作者になっている潮流から，メタバースサービスは大いに注目されている．世界最大規模のメタバースサービスとしては，米  社が提供している     が有名である ．一方で，クライアント端末，特にそのグラフィクスに要求されるスペックがある程度高いこと¶½ ，レスポンスが遅いことから，期待されている程は普及していないという現実が挙げられる．そのため本研究では，クライアントを含めたメタバースシステムにおけるレスポンス短縮を目的とし，そのボトルネックの解析を行う．

評価環境

本研究ではメタバースが将来  のように普及することを前提として期待しており，そのためメタバースサーバを分散型で構築し，評価を行っている．
メタバースサーバのオープンソフトである，  を用いてメタバースサーバを分散型で構築すると， つのサーバモジュールに分かれ，役割を分散させることが出来る 表 ．これらのサーバモジュールは，同一のマシン上で実行することも異なるマシン上で実行することも可能である．また実験で使用した各サーバとクライアントのスペックを表  に示す．

研究内容

本研究ではまず，広域分散環境における分散型メタバースサーバにおける評価を行った．しかしサーバモジュールが広域に分散したことによる性能への影響は少なかった．一方で，元々のログイン時間は，最速の場合でも約  秒かかった．ログインまでの時間としては， を基準に考えると明らかに長すぎる．そのため本研究では，メタバースサーバのログインレスポンスに関するボトルネックの解析を行う．分散型メタバースサー
バは，複数台のマシンが協調動作を行うため，振舞が複雑で様々なボトルネックが存在し得る．そこで本研究ではまず，個々のサーバモジュールのログイン時の働きとその連携がどのように行われているか調べた．その結果，レスポンスの遅い理由として，以下のような可能性が考えられる．

 ストレージアクセスが遅い  ! 負荷が高い，メモリの利用が飽和，ネットワー
クの帯域幅が不足¶½

  クライアントビューアの推奨動作環境はが  以上，メモリが  以上，グラフィックカードが は  以上， は  以上などとなっているǵȸȐȢǸȥȸȫࢫлȦȸǶᲢǢȐǿᲣƷሥྸUserǵȸȐ
ROBUSTǵȸȐǪȖǸǧǯȈƱǢȐǿƷਤƪཋƱǰȪȃȉƷˮፗƳƲƷሥྸ

MessagingǵȸȐȡȃǻȸǸϼྸƷሥྸRegionǵȸȐȪȸǸȧȳᲢ‫עם‬ᲦɟᑍƴƸ256m x 256mƷ᪸؏ᲣƷሥྸ

DatabaseǵȸȐȇȸǿșȸǹሥྸ表 " サーバとクライアントのスペックǵȸȐǯȩǤǢȳȈ

OS

Fedora Core12

Windows XP

CPUIntel Xeon 3.6GHzŴ2.4GHz

Intel Pentium 4 CPU 3.00GHz

Memory4GBŴ512MB

2.5GB

OpenSim

0.6.8

GraphicȸȸIntel 82945G Express Chipset Family# ノード間のデータ通信とデータ処理の累積時間が長い
本研究では，これらの問題がボトルネックになっているか確かめるための実験を行う．



ボトルネックの評価実験

レスポンスが遅い理由として挙げた，# つの可能性に対して，以下に述べる実験で確認を行った．



ストレージアクセス実験

ストレージアクセスが遅いという可能性に対し，$ % &'& $ ( を用いた実験で確認を行った．
$ とは，記憶媒体としてフラッシュメモリを用いるドライブ装置であり，高速アクセスが可能な，ハードディスクの代替として利用出来るものである．本研究では，%* &'&
インテル社の )*+ +'& ' ,-,$ (，容量は ./ タイプの $ を使用し，$'&''
サーバと /! - サーバの 0$$ を$ に替え，再度ログイン時間の測定を行った．
しかし，結果はどちらもログイン時間に全く変化はなかった．すなわち本実験環境の   システムによるログイン時間は，サーバ側のストレージアクセス時間はボトルネックになっていないと考えられる．

 ，メモリ，ネットワーク使用率の測定
 クラスタ管理ツールによる評価
 ! 負荷が高い，メモリの利用が飽和している，ネットワークの帯域幅が不足しているといった可能性に対し，実験で確認を行った．クラスタ管理モニタリング
ツール .'1%' を使用し，全メタバースサーバのログイン時における振舞を測定した．
結果は，どのサーバも  ! の使用率は低いが，メモ
リについては，/! - サーバと +'11 サーバが飽和している状態であり，ネットワークについては，! サーバと 1  サーバの通信量が多かった．しかし，ネットワークの帯域幅は飽和している状態ではない
ため， つの可能性として，メモリ利用における飽和が，ボトルネックかもしれないと考えられる．

メモリ増設によるログイン時間の測定実験

メモリ利用における飽和が，ボトルネックである可能性について，メモリを増設し，再度ログイン時間の測定

表 #" 1  サーバのスペック変更を行うことで確認した．すなわちメモリ利用が飽和している，/! - サーバと +'11 サーバにおいて，メモリ量を +/ から ./ に増やし，ログイン時間の測定を行った．
結果は，/! - サーバと +'11 サーバにおいて，メモリ量を増やしても，ログイン時間の短縮には繋がらなかった．すなわち本実験環境の   システ
ムによるログイン時間は，サーバ側のメモリ量はボトルネックになっていないと考えられる．
パケット解析

本実験において，クライアント端末のスペックを上げた場合に，ログインレスポンスの短縮に繋がることが明らかになった．本実験で使用したクライアント端末は，
& ! と & 対応  を搭載しているため一度に処理出来るデータ量が多く，更にメタバースでは重要なグラフィックの処理が速くなったことが要因だと考えられる．この詳細を調べるため，次節の実験を行った．



各サーバモジュールにおけるパケット解析

ログイン時間が短縮した際，各サーバモジュールにおける振舞の違いを検証した．その手順は，クライアント端末を高スペックに変更する前後で，& 2 コマン
ドによってパケットをキャプチャし，各サーバモジュー
ルのパケット数と時間を比較した．結果を図  と図 # に示す．1  サーバにおける処理パケット数とパケッ
ト通信時間が，他と比べて格段に大きいことがわかる．
また，クライアント端末の変更後，1  サーバにおけるパケット数と通信時間が減少していることがわかる．

8GB

‫୼٭‬Э

‫ࢸ୼٭‬

OSWindows XPWindows 7

CPUIntel Pentium 4 CPU 3.00GHzIntel Core2 Quad CPU 2.66GHz

memory2.5GB

8GB

Graphic

Intel 82945G Express Chipset Family

NVIDIA Quadro NVS 295

6040‫୼٭‬Э
‫ࢸ୼٭‬

200
2345678

ᚾᘍ

1500
ȑ
Ǳ 1000
ȃ
500
Ȉ
0ૠ

‫୼٭‬Э
‫ࢸ୼٭‬

Database䝃䞊䝞

Messaging䝃䞊䝞

Region䝃䞊䝞

ROBUST䝃䞊䝞

User䝃䞊䝞

図 " 各サーバモジュールにおけるパケット数଺᧓ [s]604020‫୼٭‬Э‫ࢸ୼٭‬

0Database䝃䞊䝞

Messaging䝃䞊䝞

Region䝃䞊䝞

ROBUST
䝃䞊䝞

User
䝃䞊䝞

図 #" 各サーバモジュールにおけるパケット通信時間1500
ȑ
Ǳ 1000ȃ500Ȉૠ0‫୼٭‬Э‫ࢸ୼٭‬
ARP , ICMPTCP䝕䞊䝍

UDP䝕䞊䝍

図 " 1  サーバにおけるパケット数を用いたログイン時間測定実験

考察Intel Quad-Core Xeon 2.6GHz

4GB

図 " クライアント端末変更時のログイン時間

パケット解析による結果を基に， 1  サーバとクライアントのマシンスペックを上げ，ログイン時間の測定を行った．
 高スペックな
 サーバとクライアント端末

Intel Xeon 3.6GHz

memory1

マシンスペック変更時のログイン時間測定
実験

表 # のように，1  サーバのスペックのみを上げ，ログイン時間の測定を行った．しかし，結果はログイン時間短縮には繋がらなかった．そこで，次はクライアン
ト端末の性能のみを上げ，ログイン時間の測定を行った．
使用したクライアント端末は表  に示す．
その結果，図  のように，ログイン時間は平均約 #秒になった．また，再現性も保たれている．

CPU表 " クライアントのスペック変更

ノード間のデータ通信とデータ処理の累積時間が長いという可能性に対し，パケット解析により確認を行った．
ログイン中にサーバ上に出てくるログを解析した結果において，ログイン処理の後半部分で，処理時間が長くかかっているものが多く見られた．そのため，通信パケットの後半部分に重点を置き，解析した．& 2 コマンドを用いて，全メタバースサーバのユーザログイン時における通信パケットをキャプチャした．そして，3 ア
ドレスを基に，どのサーバモジュールからどのサーバモジュールへパケットが送られているか確認した．
解析を進めると，処理時間が長いログインの後半のパケットは，全て 1  サーバとクライアント間のパケットであることが判明した．つまり，両者のやりとりが，ネットワーク遅延等により長い時間がかかっている可能性がある．

‫ࢸ୼٭‬
Fedora Core12ȭǰǤȳ଺᧓ [s]‫୼٭‬Э
Fedora Core12OS

そこで，具体的にどのようなパケットが減少しているのか，解析を進めた．結果を図  に示す．
この結果により，!$ 通信におけるパケットの数が極端に減少していることがわかる．  システム
において，サーバモジュール間の通信には - 0-- が用いられており，!$ 通信は，クライアントと 1 
サーバの通信のみで使われている．これはメタバースの土地やアバタに関する精細なグラフィクス等の膨大なデータを両者で細かく処理しながらやりとりしている部分であり，クライアントの性能向上が，  システムにこのような形で確かに影響を与えたことが確認出来た．



まとめと今後の課題

本稿では，  システムにおけるログインレスポンスのボトルネックが，本実験環境ではクライアントのスペックであることを確認した．このような状況では，クライアントのマシン性能を上げることがログイン時間を短縮するために最も効果的であると言える．しかし将来的には，クライアント側で行われている処理の一部をサーバ側で行うことにより，クライアントとして高スペックな環境を用いなくても，ログイン時間を短縮出来るようになることが望ましいと考えられる．

参考文献   ， &&"445 %  4
  2%'& ， &&"44 2%'&  14