サーバ設計
 |
 |
スレッドの流れ
MMOのサーバ処理は、Webサーバ等と比較するとクライアントごとの処理の独立性が低いです。
ゲーム処理の大部分は排他制御が必要で「同時に複数スレッドでクライアントのゲーム処理をする」 ということは難しいでしょう。
また、サーバの処理に時間がかかってクライアントの処理ができないとか、 一つのクライアントの処理にかかりきりで 他のクライアントとの処理ができなくなる、ということは避ける必要があります。 なんらかの処理でブロックされることは避ける必要があります。
ゲームの処理で時間のかかる処理をしない、という以外に、 データベースの操作、ファイル入出力、通信などのI/O処理はスレッドがブロックされる可能性があります。
通信については、「ソケットのI/O戦略」の項でお勧めした方法であれば、 イベントやウインドウメッセージで同期処理ができます。
ファイル操作は初期化・終了処理のみにし、 稼働中はメモリ内にデータを保持するのが望ましいですが、 ログの記録などで必要になることもあると思います。 そのような場合には、オーバーラップI/Oを使用するか、 キューに貯めて別スレッドで処理する、などを行いブロックされないようにしましょう。
データベースの操作は、別のスレッドかプロセスで行うようにします。
ゲーム処理の大部分は排他制御が必要で「同時に複数スレッドでクライアントのゲーム処理をする」 ということは難しいでしょう。
また、サーバの処理に時間がかかってクライアントの処理ができないとか、 一つのクライアントの処理にかかりきりで 他のクライアントとの処理ができなくなる、ということは避ける必要があります。 なんらかの処理でブロックされることは避ける必要があります。
ゲームの処理で時間のかかる処理をしない、という以外に、 データベースの操作、ファイル入出力、通信などのI/O処理はスレッドがブロックされる可能性があります。
通信については、「ソケットのI/O戦略」の項でお勧めした方法であれば、 イベントやウインドウメッセージで同期処理ができます。
ファイル操作は初期化・終了処理のみにし、 稼働中はメモリ内にデータを保持するのが望ましいですが、 ログの記録などで必要になることもあると思います。 そのような場合には、オーバーラップI/Oを使用するか、 キューに貯めて別スレッドで処理する、などを行いブロックされないようにしましょう。
データベースの操作は、別のスレッドかプロセスで行うようにします。
|
|
スケーラビリティ
サーバは非常に多くのクライアントの処理が必要になるので、
スケーラビリティを要求されます。
サーバプログラムを複数のプロセスに分割して、 複数のコンピューターで分散処理できるようにするとよいです。
ただし、サーバを機能ごとに分割すると、 かなり処理が複雑になるので覚悟が必要です...
右図は、sandbox(仮)のサーバ構成です(SNS部分は除く)。
各サーバの名前は一般的なものかどうがはわかんないです。
サーバ間はTCP接続して、連携処理を行っています。 サーバ間の接続は非常に重要なので、万が一接続が途切れても再接続し、 メッセージがロストした場合には再送するようになっています。
統括サーバは、全体的な管理と各サーバ間のデータの中継を行っています。 各アカウントがログインしているかどうか、キャラがどのゾーンにいるか、 といった情報を管理しています。
ゾーンサーバでゲーム的な処理の大部分を行っています。 キャラの移動や各種アクションを処理し、他のクライアントに伝えます。 通常ゾーンサーバが最も負荷が高くなります。 そのためマップを分割し、複数のゾーンサーバが それぞれの地区を受け持つようになっています。
データベースサーバはデータベースに接続し、 アカウントやキャラの情報を取得・保存します。
その他、ゲーム内容によって、様々な分割方法が考えられると思います。 チャットサーバを分けたり、クエストやらNPCやらを分けてみたり...。
ただ、やたら分割すれば良いわけではないです。 分割すればサーバ間のやりとりでオーバーヘッドが発生しますし、 複雑になってバグも発生しやすくなります。
sandbox(仮)でクライアントがゾーンに移動するまでの メッセージの流れの概要を書いてみます。
(C:クライアント、I:統括サーバ、D:データベースサーバ、Z:ゾーンサーバ)
さらに、クライアントからの接続が途切れる、といった例外は どのタイミングでも起こる可能性があるので、 そのようなコトにも対処する必要があります。
それでもユーザー数が多ければ、上記のサーバ全体を１セットにして、 完全に別世界として、複数セット用意しても良いです。 実際運営されてる人気のあるMMORPGは、だいたい複数用意されてますね。
こちらは、負荷分散という意味もあると思いますが、 ゲーム的にフィールドの混雑緩和の意味もあるでしょう。
サーバセットを複数用意するのは技術的には簡単です。
サーバプログラムを複数のプロセスに分割して、 複数のコンピューターで分散処理できるようにするとよいです。
ただし、サーバを機能ごとに分割すると、 かなり処理が複雑になるので覚悟が必要です...
右図は、sandbox(仮)のサーバ構成です(SNS部分は除く)。
各サーバの名前は一般的なものかどうがはわかんないです。サーバ間はTCP接続して、連携処理を行っています。 サーバ間の接続は非常に重要なので、万が一接続が途切れても再接続し、 メッセージがロストした場合には再送するようになっています。
統括サーバは、全体的な管理と各サーバ間のデータの中継を行っています。 各アカウントがログインしているかどうか、キャラがどのゾーンにいるか、 といった情報を管理しています。
ゾーンサーバでゲーム的な処理の大部分を行っています。 キャラの移動や各種アクションを処理し、他のクライアントに伝えます。 通常ゾーンサーバが最も負荷が高くなります。 そのためマップを分割し、複数のゾーンサーバが それぞれの地区を受け持つようになっています。
データベースサーバはデータベースに接続し、 アカウントやキャラの情報を取得・保存します。
その他、ゲーム内容によって、様々な分割方法が考えられると思います。 チャットサーバを分けたり、クエストやらNPCやらを分けてみたり...。
ただ、やたら分割すれば良いわけではないです。 分割すればサーバ間のやりとりでオーバーヘッドが発生しますし、 複雑になってバグも発生しやすくなります。
sandbox(仮)でクライアントがゾーンに移動するまでの メッセージの流れの概要を書いてみます。
(C:クライアント、I:統括サーバ、D:データベースサーバ、Z:ゾーンサーバ)
- C→I 接続、暗号の鍵交換、アカウント・パスワード送信
- I→D アカウントが正しいか問い合わせ
- D→I データベースでアカウントの確認、キャラデータ等を送信
- I→C キャラデータを送信
- C→I 使用するキャラを選択
- I→Z クライアントの受け入れ準備を要求
- Z→I クライアントの受け入れ準備が完了したことを通知
- I→C ゾーンサーバに接続するように指示
- C→Z クライアントがゾーンサーバに接続
- Z→I クライアントがゾーンに接続完了したことを通知
さらに、クライアントからの接続が途切れる、といった例外は どのタイミングでも起こる可能性があるので、 そのようなコトにも対処する必要があります。
それでもユーザー数が多ければ、上記のサーバ全体を１セットにして、 完全に別世界として、複数セット用意しても良いです。 実際運営されてる人気のあるMMORPGは、だいたい複数用意されてますね。
こちらは、負荷分散という意味もあると思いますが、 ゲーム的にフィールドの混雑緩和の意味もあるでしょう。
サーバセットを複数用意するのは技術的には簡単です。
|
|
データベース
MMOで保持する必要があるデータとしては、
アカウントのデータ、キャラクターのデータなどがあります。
これらのデータを読み込み・保存が必要になる頻度はそれほど多くありません。 アカウントはだいたいログイン時のみ必要になりますし、 キャラクターデータもログイン時に読み込みして、ログアウト時に保存、というかんじになると思います。
なので、データベースを使用しなくても、 キャラデータを１キャラ１ファイルでHDDに保存する、とかも可能かと思います。
ただし、データベースを利用した方がいろいろとメリットがあります。
データベースにもいろいろ種類がありますが、 要件さえを満たしていれば、なんでもいける気がします...。 ちなみにmmo!ではMySQL、sandbox(仮)ではPostgreSQLを使用しています。
また、この項の最初の方で、キャラデータが ログイン時に読み込みして、ログアウト時に保存とか書きましたが、 サーバダウンのことも考慮して、一定時間間隔とかゾーン移動の タイミングでもキャラデータを保存した方が安全です。
これらのデータを読み込み・保存が必要になる頻度はそれほど多くありません。 アカウントはだいたいログイン時のみ必要になりますし、 キャラクターデータもログイン時に読み込みして、ログアウト時に保存、というかんじになると思います。
なので、データベースを使用しなくても、 キャラデータを１キャラ１ファイルでHDDに保存する、とかも可能かと思います。
ただし、データベースを利用した方がいろいろとメリットがあります。
- 信頼性が高い
- Webとの連携がやりやすい
- バックアップをとりやすい
- 別のコンピューターに設置して負荷分散できる
- 統計データをとりやすい
データベースにもいろいろ種類がありますが、 要件さえを満たしていれば、なんでもいける気がします...。 ちなみにmmo!ではMySQL、sandbox(仮)ではPostgreSQLを使用しています。
また、この項の最初の方で、キャラデータが ログイン時に読み込みして、ログアウト時に保存とか書きましたが、 サーバダウンのことも考慮して、一定時間間隔とかゾーン移動の タイミングでもキャラデータを保存した方が安全です。
