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

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

はじめに

OpenSimulator (http://opensimulator.org) は、汎用仮想世界シミュレーターを構築するためのオープンソース・プロジェクトです。仮想世界のスケーリングに関する研究の一環として、インテル・ラボでは、マルチユーザー仮想世界システムにおけるサーバーの設計要件を理解するためのテストケースとして OpenSimulator を使用しています。

この記事のパート 1 では、OpenSimulator のアーキテクチャーについて説明しました。ここでは、さまざまなワークロードの処理に対するアーキテクチャーの影響について見ていきましょう。

ワークロード

シミュレーターの限界を測定する 1 つの方法に耐久テストがあります。これにより、シミュレーターの処理能力の上限と実装の潜在的な脆弱性が分かります。

ここでは、スクリプト、物理特性、アバターの 3 つの耐久テストを行いました。

スクリプトテストは、CPU が飽和状態になるまで、動的にスクリプトを生成し続けます。ここでは、立方体の生成にかかる時間がある限度を超えるまで、スクリプト化された立方体群を生成し続けるテストを行いました。

計算集約型のスクリプトを使ってテストすることもできますが、一般に仮想世界のオブジェクト内で記述されるスクリプトは、タイマーやセンサーによって駆動される小さなものです。多数の小さなスクリプトの限界を測定するため、ここではタイマーで駆動する小さなスクリプト・オブジェクトを生成しています。スクリプト処理自体は、色を変更し、オブジェクトの向きを変えるだけの単純なものです。

物理特性テストは、フレームレートが許容レベル以下になるまで、動的に相互作用可能な物理オブジェクトを生成し続け、その数を測定します。物理オブジェクトの数は、フレームレートの制限に達するまで徐々に増えます。

アバターテストは、フレームレートが許容レベル以下になるまで、アクティブに動き回るアバターをシミュレーターに追加し続けます。アクティブなアバターはランダムに動き回ります － 目的地を選択し、そこに到達するまで歩き続け、目的地に到達したら、別の目的地を選択し、そこに向かって歩き始めます。

この処理はアバター駆動ルーチンによって実行され、アバターが目的地に到達するまでユーザーが「直進」コマンドを実行しているかのように動作します。これにより、アクティブなアバターが多数存在するシミュレーターの実行負荷と通信負荷の両方が分かります。

スクリプトテスト

スクリプト・オブジェクトは 400 個を 1 セットとし、その生成時間がしきい値を超えるまで生成され続けます。これにより、CPU が飽和状態になるおおよその時点が分かります。

図 1 のように、スクリプト・オブジェクトが増えるに従って CPU 使用率が上昇し、やがて利用可能な計算リソースの 100% 近くに達します。CPU 使用率 100% というのは、クアッドコアを 2 つ搭載したサーバー (インテル® Xeon® E5540 プロセッサーを 2 つ搭載したシステム) において、CPU が 16 個のハードウェア・スレッドすべてをフル活用していることを意味します。

つまり、スクリプトエンジンがマルチスレッド化され、プロセッサーの処理能力を最大限に利用して複数のスクリプトが実行されています。フレームレートには変化が見られないため、スクリプトエンジンはメイン・シミュレーターのハートビート・ループとは関係なくスケジュールされていることが分かります。

物理特性テスト

ゴルトンボード (http://wikipedia.org/wiki/Galton_box (英語)) では、ピンがボードに規則的に並べられており、ボードの最上部から落とされたボールは、ピンに跳ね返りながら 2 項分布に従いボードの底に落ちていきます。

物理特性エンジンの限界をテストするため、ここでは、仮想世界に 3D のゴルトンボードを作成し、ボードの上部から何百ものボールを落としました。これにより、多くの物理的相互作用と個別の物理アクターを生成し、すべての相互作用が正しいかどうかテストする方法が得られました。

ボールはゴルトンボードから出たら消滅するようにし、ボード外の物理オブジェクトがテスト結果に影響しないようにしています。耐久テストでは、正確さは求められず、物理エンジンがオーバーロード状態になるまで、ゴルトンボードに落とされたボールの数が重要になります。

OpenSimulator では、物理エンジンのパフォーマンスはスケールされた「フレームレート」で測定されます。パート 1 で説明したように、物理エンジンはシミュレーターのハートビート間隔ごとに起動されます。ここでは互換性の理由から、これは 46 にスケールアップされています。

何回かテストを行ったところ、物理フレームレートが 30 以下になるとシミュレーター全体のパフォーマンスが低下しました。そのため、この耐久テストの評価基準は、物理フレームレートが 30 以下になったときにゴルトンボードで物理的に有効なボールの数となります。

図 2 のように、ゴルトンボードの物理オブジェクト数が増えるに従って、フレームレートは低下します。ここでは、新しいボールを作成し、ゴルトンボードの上部から落とすという 処理をしばらく繰り返した後に、新しいボールの追加を停止しています。ボールはボードから出ると消滅します。そのため、ボールの数は最初は増え続け、新しいボールが追加されなくなると減少し始め、やがてボード外に出て消滅します。「Objects」曲線の形状が図のようになっているのはこのためです。

一方、シミュレーターのフレームレートを表す「FPS」曲線は「Objects」とは逆になっています。フレームレートは、物理オブジェクト数が増えるに従って減り、その後物理オブジェクト数が減るに従って増えます。

図 2 の赤い線は CPU 合計使用率 (16 ハードウェア・スレッドの使用率) を示したものです。ここでは、物理エンジンでハードウェア・スレッドを 1 つしか使用していないため、CPU 合計使用率は 10% 以下になっています。この図の 1 つの解釈として、物理オブジェクトは 1 CPU スレッドの使用率が 100% になるまで追加することができ、それ以上追加した場合はシミュレーターのフレームレートが低下すると見ることができます。

ここでは、およそ 400 物理オブジェクトで物理フレームレートがしきい値以下になっています。

アバターテスト

前述のように、アバターテストでは、シミュレーターのパフォーマンスが低下し始めるまで動き回るアバターを追加します。アバターの作成および動作ルーチンは、ユーザーによる通常のログインとナビゲーション操作を介したアバターの作成と操作を模倣します。例えば、「前進」というアクションは、ユーザーがキーを押してアバターを動かす場合と同じプロトコル要求により実行されます。

アバターは動き回ることによってアクティブな状態を保持します。つまり、それぞれのアバターを操作するためのメッセージがクライアントからサーバーへ送られ、更新情報がサーバーからすべてのクライアントへ送られます。アバターが動いたら、新しい位置情報をすべてのクライアントへ送信する必要があります。これにより、実際のユーザーの負荷およびネットワーク要件を部分的にシミュレーションできます。

図 3 は、シーンに追加したアバターの数とシミュレーターのフレームレートの関係を示したものです。アバターの数が増加し一定量を超えると、シミュレーターのフレームレートは低下し始めます。ここでは、初期化に伴うオーバーヘッドを分散するため、アバターは 25 個を 1 セットとしてログインさせています。

クアッドコアのサーバーでは、OpenSimulator でアクティブなアバターが 350 を超えたあたりからシミュレーターの応答性が低下し始め、アバターがおよそ 450 に達するとシミュレーターのフレームレートが 30 以下になります。

考察

スクリプトテストと物理特性テストのワークロードから、アーキテクチャーについて対照的な見解を得ることができます。スクリプトエンジンでは 2 つのことが分かります。1 つ目は、スクリプトエンジンがマルチスレッド化されていて、すべての CPU スレッドを利用してスクリプトを実行していることです。2 つ目は、スクリプトエンジンがハートビート・スレッドの実行に縛られていないことです。

つまり、スクリプトエンジンは、シミュレーターの応答性に影響を与えることなく、多数のスクリプトを実行できることが分かります。これは図 1 でも明らかです。スクリプト数の増加に伴い、CPU 使用率は 100% に上昇しますが、シミュレーターのフレームレートは変わりません。

一方、物理ワークロードでは、クアッドコアを 2 つ搭載したサーバー (16 ハードウェア・スレッド) の 7% しか利用できていません。これは、物理エンジンがシングルスレッドであることを示しています。パート 1 で説明したように、物理エンジンはシミュレーターのハートビート・ループ (1 秒間に何回か物理特性とオブジェクトの更新を起動するメインループ) で起動されます。

これは、OpenSimulator の物理特性の実装に、次の 2 つの設計上の問題があることを意味します: 1) 利用可能な複数のハードウェア・スレッドを活用できない、そして 2) 物理特性の実行がハートビート・スレッドで行われるため、物理エンジンの負荷が増大すると、シミュレーターが遅くなる。

これは、仮想世界サーバーの設計において考慮すべき点をいくつか示しています。まず、シミュレーターの各関数 (物理特性、スクリプト、通信など) をマルチスレッド化して、最新のサーバーで利用可能なすべてのハードウェア・スレッドを活用できるようにするべきです。そして、それぞれの関数を個別にスケジュールすることで、その処理が互いに影響しないようにする必要があります。

これらを考慮すると、サーバーの設計として適しているのは、中央集約型データ構造のロックに依存し、個別にスケジュールされる複数のモジュールであるといえるでしょう。

まとめ

ここでは、OpenSimulator の耐久テストを行い、その結果、サブシステムのマルチスレッド化と個別のタスク・スケジューリングが必要であることが分かりました。この 2 つは両方とも、仮想世界サーバーのスケーラビリティーを向上させます。パート 3 では、仮想世界サーバーに関係のあるプラットフォームの電力効率とネットワーキングについて取り上げます。

関連記事

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

著者紹介

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