前回のオンラインゲーム業界を支える技術−Googleの掌中に？の続きです。
早速ですが、オンラインゲーム用のサーバーの技術的要件を整理します。一般的なマルチプレイヤーの場合を想定していますが、以下のような機能が必要になるかと思われます。（以降の用語、概念はすべてKAI個人が定義して使用しているものです）
(1)個人認証
(2)サービスの選択
(3)サービスの実行
(4)サービス環境の保存
(5)チャット（メッセンジャー）
(6)課金
インターネットからの大量の同時アクセスを制御しながら、これらの機能を実現する技術が、オンラインゲームを支える技術の要の技術になります。特に、ゲームという性格上、レスポンスが悪ければ誰も使ってくれませんし、中途半端なものでは面白さも半減です。そのためには、いわゆる負荷分散と言われる技術が必須となりますが、これは後ほど具体的に説明します。
さて、レスポンスが問題となるのは主に上記の(3)の機能ですが、これを実現するための基本的な考え方を説明します。オンラインゲームの実行には主にゾーン管理とセッション管理の二つの管理が必要です。
ゾーンとはゲームの空間的な単位です。プレイヤーはゾーンの中で決められたルールでプレイします。ゾーンに参加するプレイヤーの人数によって、一人のシングルプレイヤーか、2名から数名までの対戦型か、多人数のマルチプレイヤーか分類されます。セッションとはゲームの時間的な単位です。セッションは、更にターンとリアルタイムという2種類の単位に分類されます。ターンは、プレイヤーとプレイヤーあるいはプレイヤーとシステムの間の往復の時間が単位になります。リアルタイムはプレイヤー同士が時間を共有してプレーする場合の時間の単位です。
ゾーン管理およびセッション管理にとって一番難しいのが、マルチプレイヤーでリアルタイムのゲームの管理であるというのは、容易に想像できるでしょう。そのため、一般的にはゾーンの参加人数をサーバーの能力に合わせた人数に制限し、かつ、セッションはリアルタイムに進行するけれどブラウザ上のリアルタイムは保証しないことで、レスポンスを維持しています。
次に、これらゾーン管理およびセッション管理の、具体的な実現方法を説明しますが、これは大半の部分がインターネットでのアクセスを高速化するための基本的な考え方と同じやり方になります。
一般的なWebサーバーにアクセスする場合、まず、ブラウザとサーバー入口との間の問題があります。サーバーの中に入ってからは、コネクションと言われる接続の問題、アプリケーションサーバーの問題、データベースサーバーの問題等々が存在します。
ブラウザとサーバー入り口の間の問題とはいわゆる通信速度です。ADSL環境と言えども、アクションゲームのように画像情報自体を通信でやり取りしていたら、全く使い物になりません。そこで大半のゲームはフラッシュプレイヤーのようなサーバーとは独立したアクションコントロール機能を持ったプラグインのソフトを利用することで、オンラインを感じさせないゲーム専用機並みのレスポンスを実現しています。
次のコネクション問題ですが、これはインターネット特有の問題です。インターネットと言う通信の仕掛けは、耐障害性の考え方から1回1回のアクセスをすべて独立した通信として扱われます。そのために、いわゆるコンテキストを維持するためのクッキーのような仕掛けを利用しますが、クッキーとはあくまでブラウザの仕掛けです。サーバー側としてはコネクション周りのハードウェアを利用して、ロードバランシング、バッファリング、使いまわしなどでスループットの向上を図ります。
次にアプリケーションサーバーの問題です。通常はゾーン単位にサーバーを割り振るような仕掛けになるのですが、別の理由からサーバー自体の台数がアプリオリ（あえて言えば営業予算的）に決まりますので、結果的に1台のサーバーにそのサーバーの能力に応じた数十から数百のゾーンが割り当てられることになります。結果的に1台のアプリケーションサーバーで、場合によって千単位のセッション管理が必要になります。これに当然、1台2、30万のサーバーではサービスが不可能で、数千万のサーバーが割り当てられます。
残りのデータベースサーバーの問題は、DBエンジン開発ストーリー６に書いたように、通常の仕掛けではサービスの限界があり、同時にサービスを実現するためには前述のような高価なサーバーが欠かせません。
これらを、SunやIBMが、グリッド技術などを駆使して取り込もうと言うのが、前回のエントリーに取り上げたオンラインゲーム市場を狙う大手IT企業の思惑の記事だったのです。 KAI