【CEDEC2012】シリーズ初のオンラインゲーム「ドラゴンクエストX」のサーバシステムの構成と負荷分散の仕組み

8月20日～22日の3日間にわたって、パシフィコ横浜にてゲーム開発者向けカンファレンス「CEDEC2012」が開催された。ここでは3日目の22日に行われた、スクウェア・エニックス開発部 プログラマの森山朋輝氏によるセッション「ドラゴンクエストXの舞台裏」のリポートをお届けする。

シリーズ最新作にして、初のオンライン作品である「ドラゴンクエストX　目覚めし五つの種族　オンライン」（以下「ドラゴンクエストX」）。この国民的人気RPGがテーマとあって会場には多数の聴衆が来場。立ち見が出るほどの盛況となった。

セッションのテーマは「ドラゴンクエストX」のサーバシステムについて。本作ではプレイヤーのセーブデータをはじめとする大量のデータをどのように管理しているのか。サーバシステムの概要や機能、現在の状況などをスクウェア・エニックス開発部 プログラマの森山朋輝氏が語った。

森山氏は日本オラクルというデータベース会社を経て2006年にスクウェア・エニックスに入社。さまざまなデータベースの設計や構築に従事した経験を持っていたことから、スクウェア・エニックス入社後も主にゲームサーバや課金システムの開発などを担当。「ドラゴンクエストX」のバックエンド（後述）の開発にも携わることとなった。また、同社のオンラインRPG「ファイナルファンタジーXIV」のサポートもしていたとのことだ。

「みんなが一緒に遊べる」バックエンドの構築を目指す

セッションでは、まず「ドラゴンクエストX」のサーバ群が以下の4つで構成されていることが説明された。

1.ロビーサーバ：冒険の書の作成や削除といったアカウントの管理を行う。
2.ゲームサーバ：モンスターを動かしたりイベントを制御したりするなど、ゲーム本体を担当する。
3.バックエンド：データベースやキャッシュから構成され、セーブデータの管理などを行う。
4.Web：ゲーム内のデータと連動するウェブサイト「目覚めし冒険者の広場」を管理する。

森山氏によるとサーバの構成自体はオーソドックスで他のMMORPGと大差はないが、「バックエンド」に大きな特徴があるのだという。多くのMMORPGは「ワールド」などと呼ばれる、ゲームサーバとデータベースをセットにしたものを複数運用するモデルをバックエンドに採用している。この構成は作品がヒットして多くのユーザーが集まるようになったらその都度セットを増やしていけばいいので、低リスクで拡張できるというメリットがあり、オンラインゲームにおけるサーバ構成の王道になっている。

しかし、この構成には異なるセットでプレイしているユーザー同士のやり取りが非常に制限されてしまうという問題点がある。そのため、「ドラゴンクエストX」では「同じゲームをプレイしているのに一緒に遊べないという事態はダメ」という発想のもと、データベースをすべてのワールドで共通にして一元管理しているのだという。

この構成は負荷を分散する現在のトレンドとは180度逆をいく手法で、最初に方針を聞いたとき森山氏は驚きのあまり「本気ですか？」と言ってしまったという。さらに、開発に参加した時点ではナンバリングタイトルだということも知らなかったとのことで、あとになってその事実を知り「愕然とした」と振り返った。

まず、データベースの仕様を固める

「世界はひとつ」というコンセプトの実現に向け、森山氏らはまずバックエンドに求められる第一の機能が、プレイヤーのセーブデータの保存であることを確認。データベースシステムには開発や運用のノウハウのあるOracleを採用すること、データベースはクラスタ化して拡張性を持たせると同時に、キャッシュサーバを併用して負荷を分散することを決定した。

データベースにはメインとなるC++のほかJavaやPHPなど、さまざまな言語によるプログラムでアクセスすることになるため、どんな言語からでも同じ処理が呼び出せる手法を導入。これは「ファイナルファンタジーXIV」の連動ウェブサイト「The Lodestone」の制作者が、ゲーム内のいろいろなデータへのアクセスに四苦八苦したことから採用されたのだという。

ゲームサーバとデータベースを中継する「データベース中継サーバ」を300～400ほど使用することも決められた。ゲームサーバからデータベースへのプロセスは数千に達するため、一度にすべてがアクセスするとメモリが枯渇してしまう恐れがあることから、このシステムが導入されることになったという。ゲームサーバは適当な中継サーバを選んでアクセスするので、いくつかが落ちてもまったく問題は生じないそうだ。

また、プレイヤー同士のアイテム売買を仲介する「旅人バザー」、アイテムや手紙の送信を行う「郵便局」、ログアウトしている他プレイヤーの分身を仲間にする「サポートなかま」といった、プレイヤー間のやり取りを促進する機能をデータベース側に実装することも決定。これらの仕様に基づいてバックエンドの構築が進められていった。

バックエンドの最重要機能であるセーブデータの管理についても説明がなされた。「ドラゴンクエストX」のセーブデータはC++で書かれたデータの集合からなる構造体で、サイズが非常に大きいため、そのまま実装すると非常に重くなってしまうのだという。本作ではゲームの開始や終了時だけでなく、町や洞窟に入ったときなどゲーム中でも頻繁にセーブ・ロードを行うので、ここが重いとゲームが快適に動かなくなってしまう。

そこで、セーブデータをデータベースに直接保存するのではなく、いったんキャッシュサーバに保存する方式を採用。キャッシュサーバは高速でデータのセーブ・ロードができるとのことで、このキャッシュサーバを増やしていけばセーブ・ロードにかかる負荷をかなり軽減できるのだそうだ。

もちろん、最終的にはどこかのタイミングでデータベースに保存する必要がある。そのタイミングは「ログアウトするとき」「プレイヤー間でアイテム等が移動するとき」「定期的」の3つで、特に重視したのはアイテム等の移動時だという。これは、どちらかが保存せずに終了するなどして時間が巻き戻ってしまった場合、アイテムの消滅や複製が発生してしまうからで、このタイミングで必ずデータベースへの保存をする必要があるのだと森山氏は強調した。

慎重かつ入念に行われたバックエンドのチューニング

バックエンド構築後にはチューニングが必要になるわけだが、これがうまくいったと森山氏は語る。高性能な負荷検証用クライアントを作成し、大規模な負荷試験を長期にわたって実施。最初は数百のクライアントが接続しただけでサーバがいっぱいいっぱいになっていたが、テストを繰り返したことによって、現在では数十万のアクセスも問題なくさばけるようになっているとのことだ。

セーブデータの圧縮もチューニングの結果をもとに実施された。先述したとおり、本作のセーブデータはサイズがかなり大きく、そのままやり取りするとサーバ間のネットワークが耐えられないことが判明したため、データを圧縮することによりサイズを1～5％まで削減。これにより効率良くネットワークやキャッシュが使えるようになったそうだ。

サービスが開始された現在、1秒あたり数万単位のクエリー(処理要求)がくるが、負荷試験のシミュレーション通り問題なくさばけているという。ただ、「旅人バザー」と呼ばれるアイテム売買のクエリーが想定の数十倍になっているので、この部分はさらなる性能拡張が求められるだろうとのことだ。

順調なだけではおもしろくないだろうということでトラブルの例もあげてくれた。「旅人バザー」でアイテムの出品とアイテム購入の処理が千分の1秒未満くらいのタイミングで重なってしまい、デッドロックという処理が停止する現象が起きてしまったのだという。現在は解消しているが、こういったトラブルはほとんど出ていなかったので「個人的には非常に悔しい一件だった」と振り返った。

安定したバックエンドが構築できた理由

最後に森山氏は今回のバックエンドの構築・運用において負荷試験の重要性を再認識したとコメント。サービス開始後、いくつかトラブルは起きているが、原因は負荷試験が難しかった箇所か、テストから漏れていた箇所がほとんどで、かけた手間に見合った成果が出たと自賛した。

開発に携わったメンバーの間で目標やビジョンを共有できたことも大きかったという。「ドラゴンクエスト」がオンラインになること、正式なナンバリングタイトルになること、数百万のプレイヤーがアクセスすることを全員が意識できたから、安定したバックエンドが構築できたのではと述べた。

そして、「両手両足を縛られた状態からのスタートでしたが、本当に自由にやらせていただき、非常にやりがいのあるプロジェクトでした」と語り、本セッションを締めくくった。

(C)2012 ARMOR PROJECT/BIRD STUDIO/SQUARE ENIX All Rights Reserved.

※画面は開発中のものです。

本コンテンツは、掲載するECサイトやメーカー等から収益を得ている場合があります。