OpenSimulator 仮想世界サーバーのケーススタディー (パート 1)

この記事は、インテル® ソフトウェア・ネットワークに掲載されている「OpenSimulator Virtual World Server Case Study (part 1)」(http://software.intel.com/en-us/articles/opensimulator-virtual-world-server-case-study/) の日本語参考訳です。

はじめに

トレーニング、エンターテインメント、コラボレーションなど、さまざまな分野で仮想世界を使用する機会が増えています。仮想世界は、インタラクティブに利用したり、ユーザー間で交流できる 3 次元共有空間を提供します。

これまでこの分野では、クライアントの設計、アーキテクチャー、パフォーマンスにおいてさまざまな取り組みが行われてきましたが、多数のユーザーをサポートするシステム全体を見た場合、優れたユーザー体験を実現するためにはサーバーが重要なコンポーネントであるといえます。

インテル・ラボでは、以前から仮想世界のスケーラビリティーについての研究に取り組んでいます (http://techresearch.intel.com/ProjectDetails.aspx?Id=154)。仮想世界では、より優れたユーザー体験、高度なリアル感、新しい使用法 (仮想観客席でのプロスポーツ観戦など) へのニーズは高まるばかりで、これらに応えるために、現在の能力を超えるスケーリングが求められています。

今後、仮想世界アーキテクチャーでは、無数のオブジェクトが存在する世界で大勢のアバターが交流できることが求められるでしょう。そのためには、クライアント、ネットワーク、仮想世界サーバーのアーキテクチャーの変更が必要になります。

この記事は、仮想世界サーバーの設計、パフォーマンス、実行におけるいくつかの機能について取り上げたシリーズのパート 1 です。ここでは、例としてオープンソースの仮想世界シミュレーター OpenSimulator を使用しています。また、ここで紹介する設計要件は、OpenSimulator の処理から推定されたものです。

このパート 1 では OpenSimulator の設計を説明します。スレッディング設計や省電力機能についてはパート 2 および 3 で取り上げます。

OpenSimulator

OpenSimulator (http://opensimulator.org) は 3D 仮想世界シミュレーターを構築するオープンソース・プロジェクトです。構築した仮想世界では、ユーザー同士が交流したり、仮想世界のコンテンツを動的に構築することができます。

Second Life* や Blue Mars* に似ていて、別々の製作者による 3D 環境で、ユーザーはアバターを介して移動したり、ほかのユーザーとチャットしたり、協力したり、ゲームをプレイしたりできます。そのため、建物、雰囲気、ゲームの異なる地域や都市からなる多様な世界が作り出されます。

OpenSimulator サーバーの基本処理はその他の仮想世界システムと似ています － オブジェクトの相互作用はメイン・シミュレーターを介して行われ、メイン・シミュレーターがクライアントのアクションを調整し、オブジェクトのスクリプトを実行して、物理アイテムに物理特性を与えます。

仮想世界では、メイン・シミュレーターに接続するビューアー・アプリケーションを実行することで、ユーザー同士が交流できます。ビューアーとシミュレーター間の通信には、表示するオブジェクトの 3D 描写、他のユーザーの動作の最新情報、仮想世界内のオブジェクトの状態変更が含まれます。

図 1 は OpenSimulator の簡単なブロック図です。「Scene (シーン)」は領域のすべてのデータを保持するデータ構造で、「Scene Graph (シーングラフ)」は領域のオブジェクトを保持します。「Client Views (クライアント・ビュー)」はクライアントに提供される領域の表示内容を表します。

OpenSimulator は拡張しやすいように構築されており、動的にロードされるモジュール群がシーンに関連する処理を実行します。領域で発生するすべての関数は、この動的にロードされるモジュール群に実装されます。例えば、アバター同士のチャットを実装するモジュール、領域のオブジェクトを提供するモジュール、太陽や月の位置を管理するモジュールなどがあります。

ユーザーは、領域の仮想世界をカスタマイズするモジュールを提供することができます。例えば、ロボットの AI や複雑なオブジェクト相互作用 (たんぱく質の折りたたみシミュレーションなど) を実装できます。

それぞれのシーンには仮想空間への「クライアント・ビュー」があり、これは 1 ユーザーにつき 1 つです。この「クライアント・ビュー」がユーザーのクライアント・ソフトウェアと通信を行い、仮想空間の変更 (オブジェクトの描画、オブジェクトの更新、アバターの動作など) をクライアントへ送り、ユーザー入力を仮想空間に適用します。

OpenSimulator のグリッドサービスを図 2 に示します。この図では、2 つの OpenSimulator サーバーがそれぞれ複数の領域を実行しています。個々の領域は、仮想世界内の特定の 256 平方メートルの領域に対応します。この図には、シミュレーターの処理をサポートするいくつかのバックエンド・サービスもあります。

サポートサービスには、「User Service (ユーザーサービス)」 (ログイン、認証)、「Grid Service (グリッドサービス)」 (仮想世界のレイアウト、それぞれの領域空間の関係)、「Asset Service (アセットサービス)」 (仮想世界に配置可能なオブジェクトのストレージ)、複数のユーザー・サポート・サービス (ユーザーリスト、プロファイルのストレージなど) が含まれます。

これらすべてのバックエンド・サービスの背後には、すべてのオブジェクト、ユーザー、仮想世界のデータの固定記憶域としてデータベースがあります。

時間とシミュレーション

OpenSimulator は離散系リアルタイム・シミュレーション・エンジンなので、一定間隔で時間が進められます。シミュレーションのハートビート (時間間隔) はメインループによって処理され、間隔ごとに次の処理が行われます。

1) ユーザー入力を基にすべてのオブジェクトの更新

2) その間隔への物理エンジンの適用

3) 更新されたオブジェクト情報をクライアントへ送信

OpenSimulator のハートビートは 1 秒間におよそ 10 回です。これが仮想世界の時間間隔になります。そして、これに沿って物理特性が進められ、オブジェクトのバッチ更新が行われます。

このハートビート・ループには、いくつかの影響があります。その 1 つは、ハートビート間隔ごとに更新が計算され、送信されることです。つまり、仮想世界への更新は常に遅れることになり、平均するとハートビート間隔の半分の遅れが生じます。この遅れを短縮しようとする試みがいくつかありますが (例えば、ハートビート間隔を待たずに、応答をすぐに送るなど)、一般に OpenSimulator は迅速なユーザー操作を必要とするゲームには向いていません。

別の影響として、ハートビート・ループで実行される何らかの処理 (更新や物理特性) の負荷が増大すると、すべてが遅くなることがあげられます。例えば、シーンの物理オブジェクトが多すぎて、そのハートビート間隔内に物理エンジンでシミュレートできない場合 (CPU 時間の方がハートビート間隔よりも大きい場合)、ハートビート・ループが遅くなるため、オブジェクトの更新も遅くなります。

OpenSimulator でハートビート・ループを使用している理由の 1 つは、データ構造へのアクセスをロックするためです。ハートビート・ループは、更新および物理特性のデータ構造へのシングルスレッド・アクセスを提供します。これにより、シミュレーターにおいて、ロック構造の設計が容易になります。

別の手法として、シングルスレッドにより物理特性とオブジェクトの更新を制御する代わりに、シミュレーター・コアで並列実行することも可能です。その場合 2 つのメリットがあります: 最近のサーバーで利用可能な多数のハードウェア・スレッドを利用できることと、1 つのサービスによりほかの複数のサービスが遅くならないようにできることです。

まとめ

OpenSimulator はオープンソースの汎用仮想世界シミュレーターで、その設計では異なるサーバー・アーキテクチャーの長所と短所を考慮する必要があります。次のパート 2 では、OpenSimulator の耐久テストについて検証し、異なるアーキテクチャーの影響について詳しく見てみましょう。

関連記事

OpenSimulator 仮想世界サーバーのケーススタディー (パート 2)
OpenSimulator 仮想世界サーバーのケーススタディー (パート 3)

著者紹介

Robert Adams はインテル・ラボのエンジニアで、Virtual World Infrastructure (仮想世界インフラストラクチャー) チームの一員としてスケーラブルな仮想環境を実現するためのシステム・アーキテクチャーについて取り組んでいます。

* その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。