MMOG (Massively multiplayer online game) : 第 1 回 インフラの規模をパフォーマンスに基づいて見積もる

次期オンライン・ゲーム・プロジェクトを構築するための、経験に基づく客観的なアドバイス

MMOG (massively multiplayer online game) は、今日開発されつつあるソフトウェア・システムのうち最も複雑なものの 1 つであり、多くの場合は何十人もの開発者や何百人ものアーティスト、そして真の意味で大規模なインフラを必要とします。この記事は、MMOG を実行するために必要なシステムやストレージ、ネットワークなどに注目するシリーズの第 1 回です。この記事では MMOG を紹介し、ゲームのインフラの規模を見積もるための 1 つの方法を説明します。どの程度のインフラが必要なのか、またどのように MMOG のオペレーションを行うのかを学びましょう。

George Dolbier, Executive Architect, Games & Digital Entertainment, IBM

George Dolbier は IBM のゲーム・チームの技術リーダーです。彼はゲーム業界に 10 年の経験があります。最初は入力システムの実装から始まり、次にゲーム用の音声チャットとテキスト・チャットを扱い、そこからやがて、オンライン・ゲームだけではなくサービス・プロバイダーなどのオンライン・オペレーションの実装と管理を行うようになりました。彼は Oracle や Informix、Sequent などの会社に対するソフトウェア・エンジニアリングの実績を持ってゲーム業界に入りました。彼は現在そうした経験を生かして、IBM とゲーム業界がお互いを理解し合うための支援を行っています。



2007年 4月 10日

MMOG は、技術者が現在取り組む課題として、ほぼ間違いなく技術的に最も複雑なものです。各ゲームの各インスタンスは複雑なシミュレーションであり、何百万行ものコードと何十億ものグラフィック要素から構成され、そのすべてが最新のコンピューターやストレージ、ネットワーク機器から成る巨大なクラスターの上で実行されます。こうしたすべての技術によって、人工的な世界のシミュレーションが実行され、そして同時にプレイする何百万人ものプレーヤー間の対話動作が処理されます。ゲームの開発者は、ゲームの中の、創造的な、そして技術的な、すべての詳細に注目する必要があります。また開発者の組織は、どのような技術をゲーム開発に採用するか、どのような種類の、どれくらいの量の技術がゲームのサポートに必要なのかに関して重要な決定を下すという課題があります。次のセクションでは、ゲーム業界やその用語が初めての人のために用語を説明します。またゲーム業界とその用語に慣れている人は、次のセクションをスキップし、遠慮なく「ゲームの規模を見積もる」のセクションに進んでください。

ゲーム業界の分類 (専門用語)

映画の業界では、映画はアクションものやアドベンチャー、ドラマ、ラブ・ストーリー、ホラー、コメディーなどのジャンルに分けられます。ゲームも数多くのジャンルに分けられ、一人称視点シューティングやパズル、カジュアル・ゲーム、ロール・プレイング・ゲーム、レース・ゲーム、シミュレーションなどがあります。しかしゲーム業界は映画業界とは異なり、別の次元でのジャンル分け、つまりゲームの遊び方と、複数のプレーヤーで遊ぶかどうかの区別によるジャンル分けを追加しました。

一人用ゲーム

最もおなじみのタイプの電子ゲームは、一人用ゲームです。このタイプのゲームは、コンピューター、あるいは何か変わったものを相手にして遊びます。ビジネスの観点から見ると、このジャンルのゲームの作成は、製品が出荷された後はビジネスには製品開発やオペレーションのコストを生じないという点で、他のコンシューマー製品と同じです。整備が必要なインフラとしては、販売やマーケティング、流通などを管理するためのインフラのみです。

MUD (multiuser dungeon、multiuser dimension、multiuser domain)

MUD (Multiuser dungeon、multiuser dimension、multiuser domain) ゲームは、通常はテキスト・ベースのマルチユーザーによるロール・プレイング・ゲームです。このタイプのゲームでは、複数の人が中央サーバーにログオンし、通常はテキスト・ベースのアドベンチャーを共有します。こうしたゲームの起源は、シリアル・コンソールやメインフレーム、ミニコンピューターの時代までさかのぼります。つまり MUD の起源は、PC ゲームどころか PC そのもの以前にまでさかのぼるのです。MUD に関する Wikipedia の記事によると、最初のゲームが始まったのは 1977年ということです (「参考文献」を参照)。インフラの観点から見ると、MUD は他の形式のオンライン・ゲーム (マルチプレーヤーのオンライン・ゲームや MMOG など) と比べて、ほとんどインフラを必要としません。

マルチプレーヤー・オンライン・ゲーム

マルチプレーヤー・オンライン・ゲームは、1 人のプレーヤーから何十人ものプレーヤーまでをサポートする、非常に広範な種類のゲームを含んでいます。カジュアル・ゲームでは、プレーヤーのチームの人数は 32 人までに制限されています。マルチプレーヤー・オンライン・ゲームに含まれるものには、チーム・ベースのものから一人称視点シューティング・ゲーム (Half Life や Unreal Tournament など)、さらには従来からの室内ゲーム (ポーカーやチェス、チェッカーなど) のオンライン版まであります。こうしたタイプのゲームに必要なインフラが MMOG ほど複雑ではないことは明らかです。

MMOG (massively multiplayer online game)

MMOG には、少し例をあげるだけでも、EverQuest や World of Warcraft、EVE Online、Guild Wars、Lineage II など、家庭でもおなじみの名前があります。これらのゲームは世界に広まっており、何百万人ものプレーヤーをサポートしています。このタイプのゲームが必要とするインフラは最も複雑で世界中に分散したデータ・センターの中に複製され、展開されます。開発コミュニティーでは、よく MMOG を Persistent World と呼ぶことがあります。インフラの観点から見ると、両者は同じです。

Persistent World

Persistent World は、プレーヤーがログインしているか否かにかかわらず実行し続けるシミュレーションです。Persistent World と MMOG との主な違いは参加者です。Persistent World は少数の参加者をターゲットとし、従来とは異なる顧客群、あるいはビジネス・モデル群を持っています。Linden Lab 社の Second Life は Persistent World の好例であり、MMOG とは見なされません。Persistent World は多くの場合、エンターテインメント業界以外 (天気予報や戦闘シミュレーション、全球気候モデル、海洋学シミュレーションなど) で使われるシミュレーションやゲームの技術に関する分類として適切です。

massively social game

MMOG でプレイする最高な点の 1 つは、大勢の本当の人間と、協力的な、そして競争的な状況で対話動作できるという点です。これによって、地理的にも社会経済的にも膨大な広がりの中から、多くの人がオンライン・ゲームに引きつけられています。ゲームの中で、1 人の人間は社会的にも地理的にも経済的にも他のプレーヤーと平等な、アバターとして表現される (少なくとも最初はそのように始まります) ため、ゲームはそのゲームで遊ぶコミュニティーを民主化する効果を持っています。この効果によって、多くの場合は地理的な距離やさまざまな理由から物理的には不可能な、対話動作が可能になります。グローバルなコミュニティーを構成するゲームの機能を活用して、MMOG の比較的新しいサブカテゴリーである、massively social game と呼ばれるゲームが生まれてきました。ゲームのプレーヤーは、例えばデスクトップからデスクトップへメッセージを運ぶために飛び回る仮想ペットや、あるいは仮想 3D チャットの世界といったゲーム要素を利用して、実際にソーシャル・ネットワークを形成します。こうしたゲームのユーザーは、彼らのアバター、つまりキャラクターのルック・アンド・フィールや、そのアバターにどんなことが起こるのかを決定し、そして物理的な世界では不可能な方法でそのアバターの世界へのアクセスをコントロールするようになります。

プラットフォーム

ゲームのプラットフォームは、エンド・ユーザーがゲームにアクセスするための機器であり、技術的にはクライアント・サイドとして知られています。ゲーム・プラットフォームとして主なものには、ゲーム・コンソールや PC、ハンドヘルド機器、モバイル機器などがあります。もう 1 つ、通常は見過ごされがちなプラットフォームとして、アーケード機器があります。米国でのアーケード業界は、1970年代後期から 1980年代初期にかけての全盛期から、いまだに回復できていません。しかしアーケード・ゲームは、日本さらにはアジアでは相変わらず人気があります。最近では、ハンドヘルド機器、モバイル機器が着実に本格的なビジネスになりつつあります。こうしたプラットフォームが一般的なのは主にアジアとヨーロッパですが、最近の買収劇に見られるように、これらのプラットフォームはようやく業界大手企業の注目を集めるようになりました。しかしこの記事では、最も一般的なゲーム・プラットフォームの上位 2 つである、ゲーム・コンソールと PC に焦点を絞ることにします。

ゲーム・コンソール

現在まで、特に過去 25 年間のどこかの時点で子供を持っていた人達であれば、このテレビ用基本アクセサリーに関する詳しい知識を持っているはずです。1980年代の初期には Atari と Intellivision がありました。同じ 1980年代の後半には Nintendo (訳注: 任天堂から発売された「ファミリーコンピュータ」の海外向けバージョンの愛称) と Sega (訳注: セガ・エンタープライゼスから発売された「メガドライブ」を指していると思われます) が登場しました。そして現在では、Sony® PLAYSTATION® と Microsoft® Xbox、そして Nintendo (訳注: 任天堂から発売された「Wii」を指していると思われます) があります。

コンソール・ゲーム・システムは、アメリカ、日本、そして一部のヨーロッパで、ゲーム・マーケットの巨大な部分を構成しています。常に進化を続けるマーケットとして、今までの、現世代そして次世代のすべてのコンソール・ゲームは、ブロードバンドに接続できる機能を持っています。しかし、このブロードバンド領域でのコンソール・ゲームの採算性は、まだ実証されていません。

20 年前に Nintendo Entertainment System (訳注: 任天堂から発売された「ファミリーコンピュータ」の海外向けバージョンの名称) が最初にマーケットに登場して以来、多くの人達が繰り返し PC ゲームの終焉を予測してきました。そうした人達は、ソフトウェアを作成することの採算性を理解していません。PC が生活に必要なものである限り、PC 用にゲームを開発することには経済的な魅力があるのです。

「Gaming」

皆さんは Nevada Gaming Commission のことを聞いたことがあれば、それと韓国製のゲーム、Lineage II とがどんな関係にあるのかと思ったことがあるかもしれません。しかし一言で言えば、何の関係もありません。「Gaming」はこの業界によく見られる微妙な区別の 1 つであり、現金を危機にさらすゲーム、つまりギャンブルのことを意味します。

PC

毎年のように、PC ゲームの終焉を予測する、あるいは嘆く記事が書かれているようです。著者のつたない意見では、PC ゲームは当分の間なくなることはないと思います。それには非常に多くの理由があります。例えば、開発者にとって PC ゲームは最も敷居が低いのです。また PC は、何と言ってもアジア全体で最も一般的なゲーム・プラットフォームです。さらに、ネットワーク・ベースのゲームは PC で遊ぶことで人気が出ました。PC の持つオープンな性質によって、さまざまな会社が、新しい、そして革新的なハードウェアやソフトウェアで実験を行うことができます。PC はゲームで遊ぶこと以外のための基本的なユーティリティーを備えているため、PC のインストール・ベースは常に膨大であり、それによってマーケットが形成されます。PC 用に開発された技術は、PC ゲーム用にも採用され続けているようです。例えばマウスから始まって、カラー・グラフィックスや PC ベースの技術 (3D アクセラレーターやマルチチャネル・オーディオ、ネットワーク・サポート、Web ベースのゲーム、オーディオ入力、リアルタイムのテキスト・チャットと音声チャット、さらにはマルチスレッドまで) があげられます。冒険心に満ちた PC ゲーム開発者は、こうした技術をすべて採用し、ゲームのエクスペリエンスを高めてきました。この動きが近いうちに変化するという兆しはありません。そのため今後も当分の間、PC はあらゆるタイプのゲーム用の、世界的に一般的なプラットフォームであり続けると期待することができます。

インフラの観点から見ると、これまではオンライン・ゲームのサーバー・インフラを構築すればよく、それによってオンライン対応のあらゆるクライアント・プラットフォームをサポートすることができました。しかし最近導入されたコンソール・プラットフォームによって、もはやそうした状況ではなくなったようです。この新しいプラットフォームでは、ゲーム開発者は複雑なレイヤーを新たに扱う必要が出てきました。しかしこの話題はこの記事の範囲を超えているため、ここでは触れないことにします。


オンライン・ゲームの流儀で世界を分割する

この業界では、オンライン・オペレーションの複雑さを扱うために、物理的な世界を管理可能なサイズの塊に分割するための、いくつかの用語と標準的な手法を使います。

グローブ (Globe)

マルチプレーヤー・オンライン・ゲームの会社は、伸び続ける世界的な需要に対応するために、投資に見合うだけの十分なマーケットがあると思われる地理的な場所にサイトを選択します。グローバルなプレーヤーのコミュニティーはそれぞれ、いくつかの戦略的な場所に置かれたデータ・センターによってサービスされます。各データ・センターは、1 つの地域あるいは国をサービスします。

サイト

マルチプレーヤー・オンライン・ゲームは多くの場合、MMOG よりもはるかに多くのゲーム・サイトを持っており、さらにはライセンス機構まで持っています。それによって各個人や会社 (ブロードバンド・オペレーターなど) は、彼らのゲームのインスタンスをホストすることができます。各サイトは、地理的な条件で制約されるプレーヤー・コミュニティーをサポートするように設計されています。プレーヤー・コミュニティーの規模や地理的な分布には非常に大きな幅があります。

ゲームの世界の規模を管理するためのパターン

マルチプレーヤー・オンライン・ゲームと MMOG では、マルチプレーヤーのエクスペリエンスを提供するために、2 つの異なる「パターン」が使われます。どちらのパターンも、プレーヤー・コミュニティー全体を分割します。

一般的にプレーヤー・コミュニティーは、ゲームの世界のコピー、あるいは戦場やレーストラックなどのインスタンスに分割されます。人類の歴史上、他のいかなる形式のエンターテインメントでも、スポーツ、あるいは物語に、何千人もの、さらには何百万人もの人達が同時にスポーツや物語にアクティブに参加することを許したものはありません。現状では、皆さんの同胞が 1 千万人も参加していると、ゲームのエクスペリエンスは楽しいと言えるようなものではありません。

MMOG の場合、「世界」の規模は、技術とマーケットの両方に基づいて決定されます。つまりゲーム設計者は、エンターテインメント面と採算面とを考慮した上で、「世界」がサポートできるプレーヤー数を選択します。ゲーム開発者は、インフラを削減するために、この数字を可能な限り大きくしようと懸命の努力をします。

マルチプレーヤー・オンライン・ゲームの場合、あるゲームのインスタンスで同時にプレイできる人数は、基本的に、エンジンに使用される技術によって決まります。スポーツ・ゲームや一人称視点シューティング・ゲーム、レース・ゲームなどのために作成されたマルチプレーヤー・オンライン・ゲームのエンジンは、16 人、あるいは 32 人、あるいは 64 人の同時プレーヤーを適切に処理することができます。

素晴らしい (単一インスタンスの) 新世界

いくつかの注目すべき会社 (例えば EVE Online を製作した会社である CCP など) が単一インスタンスの MMOG ゲームを作成しており、これまでのところ、そうしたゲームのエクスペリエンスは好評です。こうした会社は、単一シャード (single-shard) の MMOG のプレイのしやすさと技術的な問題に対する解決策を模索しています。こうした問題の中で、単一インスタンス MMOG 用のコンテンツを作成するという問題を解決する必要があります。どうやら、「プレーヤーによるコンテンツ作成」を実現することが解決策かもしれません。プレーヤーによるコンテンツ作成は、オンライン・ゲームでは新しい概念ではありませんが、プレーヤーがゲームの世界を拡張できるならば、単一世界のオンライン・ゲームにとっての最大の障害を克服することができます。しかしプレーヤーがゲームに何かを追加するとなると、ゲームのガバナンスの問題を含めて、あらゆる問題が生まれてきます。これまでゲーム業界の内外では、あるゲームに関して魅力を伝える裾野を劇的に拡大し、またそのゲームが利益を生む期間を拡大する上で、関連コミュニティーが有効であることが繰り返し示されてきました。

単一インスタンスの世界でのプレイのしやすさに関しては、他の問題にも対応する必要があります。例えば (クエストに対する) リソース不足の問題は、クエスト・リソースを要求するアクティブなプレーヤーの数に基づいてクエスト・リソースを管理するクエスト・システムなど、創造的なゲーム・アプリケーションによって解決できます。ベンダーや地域が集中する問題も、単一インスタンスの世界に一貫して存在する概念的な問題です。この問題は、交換のための方法を創造的に考え出すことで回避することができます。「仮想」ベンダーと、クエストを提供する NPC (non-player character) の 2 つは、そうした回避策の一例です。

単一世界のゲームの障害となる技術的な問題に対しても、取り組みは可能です。適切に文書化された手法を活用すれば、最適化グリッド・アプリケーションなどのソフトウェア・システムを動的に拡大したり縮小したりすることができます (例えば。「参考文献」を参照)。こうした技術によって、単一ゲーム・インスタンスをサポートするために必要な技術的なインフラを、既存のゲームを妨害せずに拡張することができます。そうすると、最後に残る技術的障害は 1 つ、遅延時間です。つまりプレーヤーの物理的な場所がゲームに及ぼす影響です。幸い、全世界にまたがるリアルタイム・システムに依存する他の業界が、この問題に対する解決策を持っています。世界各地に分散された金融取引所は、全世界にまたがったユーザーの対話動作にリアルタイムに応答するシステムの好例です。

開発者にとって単一インスタンスのオンライン・ゲームの利点は、開発やデプロイメント、オペレーションのコストが大幅に削減されることです。またプレーヤーにとっての利点は、プレイのしやすさが大幅に拡大されることです。


ゲームの規模を見積もる

MMOG が単一のアプリケーションであり、全世界に展開された何十もの、あるいは何百ものコピーを持ち、それらが何百万人ものユーザーをサポートするという事実を考えると、必要な技術の規模を見積もる作業は非常に困難です。他の複雑な問題を考える場合と同じように、最初に、もっと小さな手軽に処理できる問題にまで分割できないかを考える必要があります。しかし容易に理解できるレベルで考えたとしても、 MMOG の問題はあまりに多様なため、一体どこから手を付けるべきかを決めることさえ困難です。

「UI から始めるのが最善である」という定説があります。ゲームの場合、ユーザー・インターフェースは、複雑な 3D グラフィックスや 2D メニュー、動的にトリガーされるシンフォニーの 6 チャネル・サウンド、可変音量の音響効果、3D の位置決めと動き、そして 2D ナビゲーションから構成されています。このように大量にあるリッチなインターフェースを自由に使える中で、クライアントの技術的メトリクスとしてゲームのサーバー・インフラに影響を与えるのは、ネットワーク・スループットと遅延時間要件の 2 つのみです。そのため、MMOG を構築するために必要な物理インフラの規模を判断しようとする際には、この 2 つの問題を最初に理解する必要があります。

スループットは、指定されたインターバル内にシステムが処理できるトランザクションの量 (例えば、毎秒百万トランザクション、など) です。遅延時間、つまりパフォーマンスは、指定された任意のトランザクションを完了するためにシステムが必要とする時間です (例えば 40 マイクロ秒、など)。

スループットとパフォーマンスが別々の実体であることを強調しておく必要があります。1 秒間に百万トランザクションを実行すると言う場合、各トランザクションを百万分の 1 秒で実行できるという意味ではありません。1 分間に百万トランザクションを実行できるということは、1 分間かかるトランザクションを、並行して百万処理できることを意味します。つまりトランザクションの完了には相変わらず 1 分間かかるのです。TPS (transactions per second) は、かろうじて「リアルタイム」と分類される種類のアプリケーションには適切な尺度ではなく、オンライン・ゲームはそうした種類のアプリケーションなのです。

とは言え、ゲームが楽しいものであるための基本的で重要な尺度は応答時間です。そうした意味から、「妥当な応答時間はどのくらいか」と質問する人がいるかもしれません。チェスのようなゲームの場合、応答時間はプレーヤーのスキルによって大幅に変わります。ゲーム・コンソールからアクセスされるマルチプレーヤー・オンライン・ゲームには、表示デバイスの固定リフレッシュ・レートから生じる厳格なパフォーマンス・ルールがあります。具体的には、ゲーム全体を、次にディスプレイをリフレッシュする前に更新する必要があります。テレビの場合では、これはフィールドごと、つまり毎秒 24 フィールドです。PC ゲーム (現在はマルチプレーヤー・オンライン・ゲームのプラットフォームの大半を占めています) の場合、要求はもっと高度です。今日の大部分の PC ゲーム・プレーヤーは、毎秒 60 フレームをはるかに上回っています。

ゲームの場合、ユーザー入力をサンプリングし、その入力が環境に与える変化あるいは効果を計算する必要があります。またその時点で更新をサーバーに送信し、そうした変更とゲームの中で起きている他の変更とを調整する必要があります。そして最後に、サーバーはクライアントに結果を返送し、そうした結果が受信された時点で更新が視覚化されますが、このすべてが 60 分の 1 秒よりもはるかに短い間に行われます。幸い、最近の普通のプロセッサーは、こうしたオペレーションでのユーザー・アクションの影響を何マイクロ秒かで計算してしまします。


2 つの世界の物語 (タイプ)

さて、今日オンライン・ゲームをプレイする際の 2 つの主なモード (つまり一般的にマルチプレーヤー・オンライン・ゲームと呼ばれるモードと MMOP と呼ばれるモード) を明確にしたので、プレーヤーのエクスペリエンスとゲームのタイプに関して両者がどう異なるのか、また必要なインフラに対してそれぞれが与える影響の大きさを理解することが重要です。コンピューター科学を好む人にとっては、マルチプレーヤー・オンライン・ゲームと MMOG は、大幅に異なるオペレーション・モデルを生ずるアーキテクチャー・パターンを表します。この記事を執筆している時点で、まだ対話型エンターテインメント業界はマルチプレーヤー・オンライン・ゲームと MMOG のアーキテクチャーに対して標準的な名前を考え出していないため、ここではそれぞれを「同質型 (homogeneous)」と「階層型 (tiered)」と呼ぶことにします。次に、これが何を意味するのか、こうしたゲームに要求されるインフラの面から説明しましょう。

マルチプレーヤー・オンライン・ゲームのインフラ・レイヤー

同質型のアーキテクチャーの場合、サーバーは、階層化されていない機能を実行します。多くの場合、単純なオンライン・ゲームのいくつかのインスタンスが 1 台のサーバー上で実行され、ゲーム同士は通信し合う必要もありません。もう少し高度な場合、サーバーはマルチプレーヤー・オンライン・ゲームをサポートする場合と同じように、お互いに通信し合います。このアーキテクチャーでは、各サーバーによる貢献は平等です。ゲームが成長すると、既存のサーバー群に対して単純にサーバー群が追加されます。実装が適切であれば、ゲーム・エンジンは新しいサーバー群を自動的に利用し始めます。

MMOG のインフラ・レイヤー

同質型のアーキテクチャーとは対照的に、階層型、つまりシャード (shard) 型のアーキテクチャーを持つプレーヤーは、サーバーのあるレイヤーに接続されます。この階層は、サーバーの特定の機能を実行する別のレイヤーと通信し、そしてそのレイヤーは、また別の機能を実行する別の階層と通信します。そうしたものすべてが、ネットワークによって 1 つにまとめられます。また、ゲームの容量を拡張する必要が出てきた場合、それぞれのレイヤーにサーバー群が追加されます。

階層ベース、つまりシャード・ベースの MMOG は、ゲームの世界を何十あるいは何百とコピーしたものを使って、膨大な数のプレーヤーをサポートします。「シャード(shard)」という用語は通常、従来のアプリケーション・パターンを前提に設計された個々のサーバー群を表現するために使われます。このパターンは、複数階層のMVC (Model-View-Controller) です。MMOG の各シャードは、3 つの基本的なレイヤーに分割されます。一番下にデータベース・レイヤーがあります。その上には、一般的にゲーム・エンジン(あるいはゲーム・サーバー) と呼ばれるレイヤーがあります。そのレイヤーの上には、一般的にフロント・エンドと呼ばれるレイヤーがあります。このフロント・エンド・レイヤーは多くの場合、いくつかの薄いレイヤーに分割されます(例えばログインやボーダー、境界、ロード・バランシングなど)。そしてすべての MMOG の一番上にはゲームのファイアーウォールがあり、そして当然ながらインターネットへの接続があります。

パフォーマンスの変数

MMOG のパフォーマンスには数多くの要因が影響します。そうした要因には次のようなものがあります。

  • 1プレーヤー当たり毎秒転送される平均データ量: これはネットワークとフロント・エンドのインフラを理解する上で非常に重要です。
  • 目標とするプレーヤーの総数: そのゲームを購入し、プレイするプレーヤーの数を正確に見積もる必要があります。
  • 同時にプレイする人の総数の目標: 登録されているすべてのプレーヤーのうち、任意の時に同時にオンラインになると思われるプレーヤーの人数を計算します。
  • 1 地域当たりのプレーヤー総数の目標: 世界中のさまざまな場所 (例えば上海、北京、ソウル、東京、シドニー、ロサンゼルス、シアトル、オースチン、ニューヨーク、ロンドン、パリ、ミュンヘンなど) でゲームをプレイする人数によって、地理的な地域を分割する必要があります。
  • 1 地域当たりの、同時にプレイする人の総数の目標: ゲームに従って世界を分割したら、各地域でオンラインになれるプレーヤーの人数を決定します。
  • インスタンス当たり同時にプレイできる人数の目標: これは通常、判断が難しいのですが、ゲームの各シャードがサポートすべきプレーヤーの人数を指します。
  • 「世界のデータ」の規模: これはデータベースに保管される情報の量を指し、コントロールできる尺度ですが、大幅に異なりがちです。
  • プレーヤーに関連するデータのサイズの範囲: これは、プレーヤーがプレイ中に生成するパーシスタント・データの量を指します。

要因を見積もる

一般的に、MMOG を見積もるための作業は、目標とする、全世界でのユーザー・コミュニティーの大きさを見積もることから始まります。次に、地域ごとにターゲットとするユーザー・コミュニティーを決定する必要があります。地域当たりのサイト数が決定できると、サイト当たりでサポートすべきユーザーの数がわかります。次にこの情報を、ゲームの世界の各インスタンスでサポートされるユーザーの数と組み合わせます。そうすると MMOG インフラの規模を見積もるために必要な最も基本的な情報が、従来のアーキテクチャー手法を使って得られます。


MMOG での個々の階層

MMOG の「M (massive)」に当たる膨大な数のプレーヤーをサポートするため、ゲームのサーバー・サイドは、さまざまな機能を実行する何十、あるいは何百ものサーバーから成る複雑な構成です。このインフラは多くの場合、ケーキのようにレイヤー、つまり階層に分割されます。各階層は、関連する一連の機能を実行します。通常、MMO は、あいまいに「n 階層アーキテクチャー」と呼ばれるアーキテクチャー・パターンに従います。このアーキテクチャーは、最も基本的な形式では、フロント階層と中間階層、そしてデータベース階層という 3 つの階層に分割されます。

フロント階層を見積もる

オンライン・ゲームは格好の攻撃対象であり、危害を加えようとする、あらゆる個人やグループにとって魅力的なようです。防御のための最前線として、ハイパフォーマンスのネットワーク・ハードウェアと適切なセキュリティー機能を組み合わせる必要があり、また、DoS (サービス不能) 攻撃やパケット・フラグメントなどインターネット・サイトに対する典型的な総当たり攻撃への防御に関して実績のある、ファイアーウォール・レイヤーを備えている必要があります。

中間階層を見積もる

中間階層の見積もりは、ゲーム・エンジン自体のアーキテクチャーに依存します。ゲーム・エンジン (つまりシミュレーションの心臓部) は、この階層にあります。この階層の見積もりは、ほぼ完全にゲーム・エンジンの実装に依存します。実際には、MMOG エンジンの大部分はサーバー当たり 200 から 600 人の間のプレーヤーを処理することができ、また多くの会社は、現世代のプロセッサーではゲーム・エンジン・サーバー当たり600 ユーザーを達成できると主張しています。さらに、従来とは異なるゲーム・エンジンの設計によって、そうした会社のサーバーはその数字の 10 倍をサポートできるようになっています。

データベース階層を見積もる

データベース階層は、可能な限り遅延時間ゼロの環境でトランザクションを処理する必要があります。プレーヤーによるすべての動き、そしてすべての項目、オブジェクト、怪獣などは、ゲームのデータベースの中では、少なくとも 1 つのデータ要素です。しかし奇妙なことに、最大規模のゲームの世界であっても、世界中の何千もの会社で使用されているデータ・ウェアハウスに比較すれば微々たるものです。また、ゲーム用のスキーマも非常に単純です。こうしたことから、マルチプレーヤー・オンライン・ゲームのエンジンは、並列データベース技術 (対称マルチプロセッサーなど) や他の大規模メモリー・システムの能力を活用することができます。少し注意すれば、マルチプレーヤー・オンライン・ゲームの動作セットを、大規模システムのメイン・メモリーの中に入れてしまうこともできます。

ゲーム・データベースに関する注意

ある人が MMOG からログオフしても、ゲームの Persistent World は、その人がいなくても実行を続けます。そのプレーヤーが行ったこと、プレーヤーが行ったことのある場所、そのプレーヤーが所有しているものに関するすべての情報は保存されます (MMOG の設計でのパーシスタンスについて詳しくは、「参考文献」のセクションを参照してください)。

データベースに関する MMOG の動作は非常に特殊な性質を持っています。トランザクション負荷として、単純な更新や読み取りが大量に行われるという特徴があります。例えば、すべての動き、項目の属性、そしてキャラクターの属性は多くの場合、データベース内のデータ要素として保持されるという事実を考えてみてください。プレーヤーがゲームのキャラクターを動かすごとに、位置データがデータベース内で更新されます。MMOG では、文字どおり何十万ものプレーヤーが、常にこうした更新を行っています。

一般的に MMOG は、銀行や保険会社、金融取引所、医療記録システムなどと同じデータベース技術を利用します。しかし MMOG のデータ・スキーマは、通常のビジネス・システムとは異なり、故意に単純になっており、これらのテーブルに対して実行されるトランザクションは、単純な更新と読み取りのみです。残念ながら、MMOG の規模は、従来のデータベースのアーキテクチャー的な限界に達し始めています。多くの開発スタジオは、パフォーマンスと遅延時間の技術を提供できる、従来とは異なるデータベース・エンジンを使うことを検討しています。これまでの経験では、メモリー・データベースが素晴らしいパフォーマンスと低遅延時間を示しています。実際に、遅延時間が問題となるアプリケーションに対して ACID (Atomicity、Consistency、Isolation、Durability) トランザクションを提供する、非常によく理解されたデータベース・エンジン技術が存在します (ACID については「参考文献」を参照してください)。こうした技術は多くの場合、何台かのサーバーの間にデータを分散させ、システム全体にわたってクエリーを分散させます。そのためデータセットは完全にメモリーに常駐することができ、またいくつかのシステムが並行にクエリーを実行することができます。


単純な方法で見積もる

MMOG の規模を見積もる上での変数となう要素の大部分を理解でき、個々の階層の規模の見積もり方法に関して大まかな感覚がつかめたら、MMOG の規模を見積もるための最も重要な 2 つの要因、つまりネットワークのスループットと遅延に関する要件に焦点を移すことができます。

大規模なインフラの規模を見積もる作業は、それ自体が科学です。奇妙なことに、新しい高速道路システムの規模を見積もるための手法と同じ手法を、MMOGの規模を見積もるためにも使えるのです。この手法は簡単に言うと、鍵となる容量要因と、鍵となるパフォーマンス要因の両方を見つけるのです。言い換えると、最大のボトルネックを 1 つ見つけるのです。鍵となるボトルネックを見つける利点は、そのボトルネックの解決に費やされるリソースに比例して見返りが得られることです。理想的には、鍵となるボトルネックにリソースを費やすことによって、システム全体のパフォーマンスが 2 倍、10 倍、20 倍、100 倍というように改善されます。もしボトルネックが発見され、そのボトルネックに対応することで 5% か 10% しかパフォーマンスが改善されないとしたら、他のことに時間をかけた方が得策だと思うべきです。解決しても小さな効果しか得られないボトルネックなら、手間をかける意味はあまりありません。鍵となるボトルネックが見つかり、それを解決すればパフォーマンスが何倍も大きく改善されるのであれば、そのために費やされるリソースを容易に正当化することができます。

こうしたパラメーターを考えると、鍵となるボトルネックは、「いかに多く」と「いかに速く」の両方にとって最も制約となるボトルネックです。さらに明確に定義すれば、鍵となるボトルネックは通常、この 2 つの尺度によって特徴付けられるものです。この測定基準が見つかりさえすれば、それを 1 つの要因として MMOG のインフラ全体の規模を見積もることができます。

MMOG に従事したことのある誰にとっても、鍵となるボトルネックは痛ましいほど明白です。つまりゲーム・サーバーとクライアントとのリンクなのです。CPU やメモリー、ディスクなどは、ネットワークよりも何桁も高速だと考えても支障がありません。いくつものボトルネックがある場合には、それらをゲーム・サーバーとクライアントとのリンクというボトルネックと同じ影響とみなします。つまり、ボトルネックを特定できれば、インフラの規模を見積もるための鍵となるパフォーマンス・メトリクス (「いかに多く」と「いかに速く」) を判断できるのです。

「いかに速く」の要因となるのは、各クライアントに必要な毎秒のビット・レートです。残念ながら、多くの複雑な要因から、クライアントとサーバーとの間に必要な帯域幅は測定するまでわからない、という状況に陥ることがよくあります。これはつまり、完全なクライアントとサーバーが実際に必要になるまで帯域幅を決定できないということを意味します。

MMOG にとっての「いかに多く」の要因は、さらに複雑です。この場合の問題は、いったんゲームが起動したら、そのゲームでは何人のユーザーが同時にプレイするのか、ということです。その答えは、「不明」から何百万人までのどれかです。この判断基準は、ゲームの設計、あるいはビジネス・モデルによって決定されます。いずれにせよ誰かが数字を決める必要があり、その数字はある程度正確な見積もりである必要があります。

これを誤ってしまうと、次のような事態に陥ります。

  • シャード当たりのプレーヤーの数を過大評価すると、不必要な機器のために実際に費用を無駄にする危険をおかすことになります。
  • この数字を過小評価すると、ゲームを起動するための機器が足りなくなります。つまりゲームをしようとしても操作できず、簡単に得点を失うことになります。

そのゲームで何人がプレイするかを知るための正確で科学的な方法はありません。しかし何とかして費用を無駄にしないよう、実際の値に近づける必要があります。経験から、少し過大評価した方が、過小評価するよりも適切です。

何人のプレーヤーを同時にサポートするかを決定したら、MMOG の鍵となる要因の計算に焦点を移します。これは単純に、同時にプレイするプレーヤーの数に、プレーヤーごとに必要な帯域幅を掛けるだけの話です。この計算によって、インフラのフロント・エンドがサポートすべき、必要な毎秒の合計バイト数が得られます。この場合、フロント・エンド・サーバーが処理できる同時接続数と毎秒の連続バイト数を判断するためには、ネットワークの経験が必須です。

次のレイヤー以降の規模の見積もりは、ゲーム・エンジンの実装方法に大きく依存するため、様々な要因が複合されて関係します。ゲーム・エンジン・レイヤーが適切に想定されていれば、実際にはボトルネックは通信ではなくメモリーと CPU の帯域幅に依存します。もしそうであれば、見積もり方法としては、CPU 世代 X でメモリー構成 Y を持つ 1 台の双方向サーバーが何人のプレーヤーを同時にサポートできるかを計算します。もし経験則を探しているのであれば、以下の方法が有効なようです。つまり、大部分のゲームでは、1 台のフロント・エンド・サーバーで少なくとも 4 台のゲーム・エンジン・サーバーに対応できます。この経験則を使えば、ゲーム開発の初期フェーズでは非常に手軽な置き換えによる見積もりができます。

これとは対照的に、データベース・レイヤーの規模の見積もりは比較的簡単です。答えは 2 台です。その理由は、これまで何十年もの間、リレーショナル・データベース技術が設計され、改善されてきているためです。最近のリレーショナル・データベースは、信じられないほどの容量を持ち、また複数 CPU のシステムで信じられないほどのパフォーマンスを発揮します。同時にプレイするプレーヤーの数を見積もることができれば、毎秒当たりのトランザクション数を見積もることができます。その計算が終わったら、単純にリレーショナル・データベースのパフォーマンス・ベンチマークのサイトに行き、おおざっぱな範囲で見て適切なシステムを見つけます。トランザクション要求を満たすだけの十分な CPU とメモリーを持つシステムを見つけたら、そうしたシステムを 2 台購入し、それらをアクティブ・アクティブのクラスタリング構成で実行すればよいだけです。理想的には、それぞれがゲーム・シャードの全負荷を処理できる規模であればよいのですが、採算性とリスクとのバランスも重要です。データベースとデータベース・サーバーは、他に故障する可能性があるものと比べれば、それほど頻繁に故障することはありません。アクティブ・アクティブのクラスタリングを選択する理由は、最近のデータベース・クラスタリング技術と比較的安価な FATA のストレージ・システムを考えれば、それ以外の方法を選ぶ理由が見あたらないからです。

すべてのゲーム開発者は、ゲームのデータベース全体をメモリーの中に入れたいと思っているのかもしれません。このシナリオでは、パフォーマンスは素晴らしく、トランザクションはファンクション・コール並の時間で完了するでしょう。しかしそれは、2、3 テラバイトの物理メモリーを持つシステムが必要ということでもあります。本当にそうでしょうか。実は「distributed shared nothing」と呼ばれるタイプのデータベースがあり、これは実際にデータベース全体をメモリーの中に入れられる可能性を持っています。この記事の執筆時点で、4GB のメモリーをシステムに搭載すると、大きな費用効果が得られます。shared nothing データベース・システムは、システムのデータとクエリーを一連のシステム全体に渡って分散させることができます。例えば、4GB システムを 12 台まとめると、40GB のデータベース全体と、さらにはオペレーティング・システムや他のタスクに十分な RAM が得られます。

注意: ゲームのトランザクションは、ビジネス・トランザクションとは異なります。ゲームの設計者は、データベースに対して何百万もの非常に小さな読み取りや更新をゲームのプレイ中に行わなければならないことを、知っています。ゲーム・エンジンには、スター・スキーマを大規模に結合したものなどは必要ありません。ゲームは DSS (decision support system) あるいは OLTP (Online Transaction Processing) システムとはまったく異なります。ゲームのワークロードはむしろ LDAP (Lightweight Directory Access Protocol) や電話帳の参照に似ており、単純な表に対して、非常に大量の小さなトランザクションを行うのです。

遅延時間はどうなのか

この記事ではこれまで、マルチプレーヤー・オンライン・ゲームと MMOG でのプレイのしやすさに影響する最も重要な問題、つまり遅延時間の問題を避けてきました。遅延時間をどうすべきか、そして遅延時間の見積もり方を最もうまく説明するには、車による輸送のたとえを使うことです。オンライン・ゲームの遅延時間は、買い物をしに家から店まで運転し、また戻ってくるまでにかかる往復時間にたとえることができます。容易に想像できるように、往復時間は、車がどのくらい速く走るか、どのくらい効率的に食料品を購入して車に積み込み、どのくらい速く戻れるかによって影響を受けます。馬力のない車、雑然としている上にレジの設計が悪く長い列ができてしまう店、あるいは道路の混雑など、すべてがこの運の悪い買い物客の往復時間に大きく影響します。

遅延時間を短縮したいのであれば、すべての要素の機能を拡張する必要があります。上のたとえで遅延時間を改善するには、ミニバンを捨て、巨大なエンジンと莫大な運搬容量、パフォーマンスに優れたサスペンションを誇る小型トラックに代えることです。また、道路を広げ、可能な限り多くの車線を追加して交通渋滞を減らす必要があります。また、事前に店に電話して食料品を注文しておきます。そうすれば店は、注文されたものを、その買い物客のトラックが店に到着する前に、3 層構造で衝撃吸収仕様の段ボールとプラスチックの輸送コンテナに詰め込んでおいてくれるでしょう。すると買い物客は、車を駐車場に停めず、停車せずに、「Shock and Awe (衝撃と畏怖)」という名前そのままの、非常に効率的な食料品積み込みシステムによって弾丸のように撃ち出される荷物のパッケージを荷台に積み込むことができます。新たに荷物を積み込んだ、スーパーチャージャー装備の小型トラックは、アクセルを緩める必要もなく飛ぶように高速道路に戻り、その車専用の高速車線を走っていくことができます。

このシナリオは、ばかげていると思えるかもしれませんが、ポイントを突いているのです。このシナリオのすべての要素は、ネットワーク技術の何らかのコンポーネントと、どうすれば遅延時間を改善できるか (例えば特別な設計のパケット (例えば IPv6 のジャンボ・パケットの利用) から、QoS プロトコル (利用できる場合であれば IP の QoS オプション) に至るまで) を表しています。もしクライアントとサーバーとの間を行き来するデータの設計が、遅くて扱いにくい車の設計のようになっており、またゲーム・サーバーは昔ながらの小さな家族経営の食料雑貨品店のように設計されているとすると、交換されるパケットの往復時間は最適にはなりません。その一方、クライアントとサーバーのヒント情報を活用できれば、サーバーは、最新モデルでハイパフォーマンスのスポーツ・カーが到着する準備を整えることができ、それによって往復時間を削減することができます。

こうした説明の要点は、遅延時間が、ゲーム・エンジンとクライアント通信システムの心臓部に関する設計判断に影響されるということです。よく理解された方法を利用することによって、パケットを改善でき、パケットの数を削減でき、そしてパケットの往復時間を最適化することができます。キャッシングやデータの完全化、キューの最適化、順不同の送受信、レシート、コネクション・プーリング、ヒント情報、パラレル接続などは、どれもよく理解された方法であり、どのようなマルチプレーヤー・オンライン・ゲームにも、コントロール可能な遅延時間要素を削減するために採用することができます。

さて、ここまでは MMOG の遅延時間に対して中心となる問題を避けてきましたが、その問題というのはインターネットのスピードです。信じられないかもしれませんが、インターネットのスピードに関して打つ手はあるのです。基本的には、マーケット全体の中から複数のホスティング会社を選ぶことが重要です。そして、そうしたホスティング会社が特定マーケットにサービスを提供するブロードバンド・プロバイダーに低遅延の接続を提供していることを確認します。インターネットの遅延時間を減らすために最善の方法は、ブロードバンド・サービス・プロバイダーのインフラの範囲内でホスティングを行うことです。こうしたことは、プロバイダーがマルチプレーヤー・オンライン・ゲームのホスティングすることでネットワークに付加価値を付けようとしているため、より一層現実的になっています。またこれは、オンラインの一人称視点シューティングやレース・ゲーム、スポーツなどのゲームやカジュアル・ゲームに対しても現実的なオプションです (こうしたゲームでは Persistent World のデータはゲームの核心ではなく、またプレーヤーは多くの場合地理的な位置でグループ分けされます)。

バック・オフィスのインフラ規模を見積もる

ゲーム・エンジンのインフラの規模を見積もる作業は、MMOG 全体の規模を見積もる作業の半分にすぎません。請求、課金、アカウント管理なども同じくらい複雑であり、MMOG が成功するためには重要です (特に、こうした要素はプレーヤーがログオン中に利用されるため重要です)。請求システムの規模の見積もりに関しては、ユーザーの数と支払い方法がすべてです。

支払い方法は、地域によって大きく異なります。実は大いに驚くべきことですが、MMOG は、1 つのサービスが世界の全地域の人々に使われる、初めての真にグローバルなオンライン・サービスなのです。そのため、業界にはいくつかのユニークな困難が生まれています。例えば、北米ではクレジット・カードとデビット・カードのシステムがほとんどすべての支払いに使われており、一部例外的にプリペイド・カードが使われています。EU では、プリペイド・カードが、北米の大部分の人におなじみのクレジット・カード・システムと並行して使われています。アジア太平洋地域では、特に中国では、クレジット・カード・システムは実質的にほとんど存在せず、プリペイド・カード・システムが普通です。こうしたすべての地域において、どのような支払い方法が使われるにせよ、支払い処理と請求は伝統的にアウトソースされます。どの地域にも共通して、それぞれの地域に適切な方法で請求と支払い回収を専門に行う会社があるものです。ワシントン州 Bellevue にある InfoSpace や北京にある YeePay などは、そうした会社の一例です。

請求システム自体は、よく理解されたバック・オフィスのインフラ・コンポーネントです。テレコミュニケーションあるいはサービスの分野で料金に見合うコンサルティング実績を持つビジネス・コンサルタント会社であれば、どのような会社でも最小限の努力で規模を見積もれるはずです。MMOG の構築を検討している会社には、請求処理を行う請求システムの構築に経験を持つコンサルティング会社と契約することを真剣に検討するように、強くお勧めします。そうした方が短期的にも長期的にも費用効果が高く、また得策です。ビジネスの観点から見ると、MMOG の開発会社と提供会社が、インターネット対応サービスの購読に対して請求を行います。よくあることですが、成功事例を持つ会社の多くは、ゲームに合わせてスケーラブルな、またゲームとの統合に適した請求システムを構築しています。

ここまで読み進むと理解できると思いますが、規模の見積もりは簡単ではありません。この記事を読んだことで、規模の見積もりが芸術と言うよりも科学であり、少し研究した上で何回か推測を行うことで多くのリスクと費用を避けられることを確信できたと思います。経験豊富なベンダーがこのプロセスにもたらす価値を過小評価すべきではありません。またベンダーを選択する際には、期待レベルを高く設定する必要があります。優秀なベンダーは皆さんの環境を理解でき、また皆さんと協力して各インフラ・レイヤーの規模を見積もることができるのです。


まとめ

ここでは、MMOG パズルの中で最もリスクとコストの高い部分を適切に解決するための方法を学びました。次のクエストの征服に進む前に、もう 1 つ、注目すべき重要な部分があります。皆さんは最新で最高のシステムに時間と費用を投資しました。では、それらをどこでホストするのでしょう。ゲームのホスティングは簡単な作業ではなく、十分注意深く検討する必要があります。ホスティングの採算性の予測は、想像以上に複雑なのです。ホスティングに関して不適切な決断をしてしまうと、ゲーム会社は大きな災難に見舞われるかもしれません。このシリーズの第 2 回では、インフラの見積もりから離れ、実際に MMOG をホスティングし、オペレーションを行うことになった場合に考慮すべき、採算性の要因に関して掘り下げた解説を行います。

参考文献

学ぶために

製品や技術を入手するために

  • 皆さんの次期開発プロジェクトを IBM trial software で構築してください。developerWorks から直接ダウンロードすることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Web development, Multicore acceleration
ArticleID=250184
ArticleTitle=MMOG (Massively multiplayer online game) : 第 1 回 インフラの規模をパフォーマンスに基づいて見積もる
publish-date=04102007