【CEDEC2012】シリーズ初のオンラインゲーム「ドラゴンクエストX」の舞台裏
大規模オンラインゲームのバックエンドはどのように設計、構築されたのか
8月20日~8月22日にかけて、パシフィコ横浜にてゲーム開発者向けカンファレンス「CEDEC2012」が開催されている。
本稿では会期3日目の22日に行なわれた「ドラゴンクエストXの舞台裏」のセッションのレポートをお届けする。このセッションは立ち見が出るほど大盛況で、本タイトルに対する参加者の注目度が伝わってきた。
シリーズのナンバリングタイトルでありながら、初のオンライン作品である「ドラゴンクエストX」は、非常に多くのユーザーが接続することが想定できる。講演では、「ドラゴンクエストX」では、大量のユーザーのデータをどのように管理しているかが話されていった。
■ 大量のアクセスが想定されるMMORPG。セーブデータを裁くバックエンドの構築
株式会社スクウェア・エニックス 開発部の森山朋輝氏 |
森山氏がスクウェア・エニックスに入社したのは2006年。前職はデータベースベンダーのオラクルにいたそうで、大小様々なデータベースの構築・設計を行なっていたという。スクウェア・エニックスに入社してからもその経験を生かしモバイルゲームのサーバーや、課金システム周辺の構築を行なっていたという。直近では「ファイナルファンタジーXIV」プロジェクトのサポートも行なっていたという。
「ドラゴンクエストX」のサーバー構成は特に奇をてらったものではなく、他のMMORPGとほぼ同様の構成となっており、ユーザーのログインを受け付けたり、冒険の書を作成、削除する役割を兼ねている「ロビー」、モンスターを動かしたり、イベントを制御する「ゲームサーバー」、ユーザーのセーブデータを管理する「バックエンド」、そしてゲーム内と連動し掲示板など提供する「Web」だ。これら全てのサーバが「バックエンド」と連携することで「ドラコンクエストX」のサービスが成り立っている。セッションでは、この内主に「バックエンド」についてが語られていった。
「ドラゴンクエストX」のバックエンドサーバーは他のよくあるMMORPGとは大きく異っている。通常のMMORPGの場合はワールド毎に、ゲームサーバーとデータベースを1セットにし、それを並列的に構築するモデルを採用している。もし多くのユーザーが集まり、処理できなくなった場合は、そのセットを増やしていけば増加するユーザーにも対応できるという仕組みだ。
しかしこの構成には、違うサーバーセットでプレイしているユーザーとは一緒にプレイできないという問題点がある。MMORPGをプレイしたことがある読者なら、違うワールド(ゲームによってはサーバーとも呼ぶ)でプレイしている友達と一緒に遊べなかった経験もあるのではないだろうか。
「ドラゴンクエストX」では「違うワールドにいる友だちと一緒に遊べる」というコンセプトがあり、データベースが全てのワールドで共通となっている。しかしこれは分散して処理を行なうトレンドとは真逆の手法である。このコンセプトを聞いたとき、森山氏は思わず「本気ですか?」と聞き直したそうだ。ここから、「ドラゴンクエストX」データベースへの森山氏の取り組みが始まった。
■ 要求を満たすバックエンドの設計と構築、そして負荷テストまで
シリーズ初のMMORPG。多数のユーザーがサーバーに同時にアクセスする |
森山氏は、まず設計を始める段階で、バックアップの運用やデータの取り扱いやすさを考え、データベースを使うことを決めたという。プロダクトはノウハウがあったのでOracleを採用した。
そして拡張性を持たせるため、複数台のサーバーから構成されるクラスタ構成を採用したが、扱うデータ量が膨大なので、キャッシュサーバーも併用していった。
また「データベース中継サーバー」を使うことも決めていたという。これは名前通りデータベースとゲームサーバーを中継するサーバーだ。これを用意した理由としては、ゲームサーバー側でプロセスが数千以上動いており、全てのプロセスが直接データベースに接続するとメモリが枯渇することがわかっていたからだ。
「データベース中継サーバー」は多く用意されており、冗長化されている。もし数台の「データベース中継サーバー」に接続できなくても、自動的に代替サーバーに繋がるような仕組みになっている。
「ドラゴンクエストX」のセーブデータはプログラミング言語で使用する構造体の形で格納されているという。構造体とは様々な形のデータをひとまとめに格納する方法で、例えば「Status」という名前の構造体の中に「ヒットポイント」や「マジックポイント」という値が格納されているというイメージだ。
この構造体をデータベースに格納することでセーブデータを管理するのだが、構造体のサイズが大きく、単純にデータベースに保存するわけにはいかなかったという。
しかしデータのセーブやロードはゲーム開始時だけなく、洞窟に入るときなど随時行なわれる。そのためこの部分の処理がスムーズでないと、ゲーム進行の足を引っ張ることになってしまう。
そこで対策として利用したのがキャッシュサーバーだったという。キャッシュサーバーを複数台用意することで、レスポンスの高速化を実現できたという。
構築が終わった後はチューニングを行なう。「ドラゴンクエストX」ではチューニング用にプレーヤーの行動をシミュレートする負荷検証用のプログラムを作成し、それを並列に並べることで大規模な負荷試験を行なったという。最初は数百程度の接続で負荷がいっぱいっぱいだったが、テストから修正というプロセスを何度も行ない、ボトルネックとなっている箇所を特定、修正し、収容人数を増やしていき現在は数十万のアクセスも捌けるようになったという。
最後に森山氏はデータベースチューニングのポイントとして、「想定以上に特定の命令が何度も呼び出されていないか」を確認する必要があるという。時には、いつのまにかの仕様が変わっていたこともあったという。
またプレーヤーの動きをシミュレートして負荷試験を行なうのも重要だという。単体のテストでは見つからなかった問題を、組み合わせることで新たな問題に繋がることがあるからだ。
他に起きた問題としては、ネットワークの帯域をあげていた。先ほども紹介したように「ドラゴンクエストX」のセーブデータはサイズがかなり大きい。最初はその大きなデータを加工せずそのままやりとりしていたので、ネットワークの帯域を使いつぶしてしまったのだ。圧縮してデータを転送することでサイズを「1%~5%に削減することができた」そうで、トラブルになる前から早めにやっておけば良かったと悔やむほどだったという。
■ 入念な準備を行なったバックエンド、サービス開始後の状況は
適切にバックエンドで処理が行なわれないと、アイテムが消失したり、逆に増殖する可能性もある。重要な部分だけあり、トラブルが起こった際ののインパクトは非常に大きい |
なお多くの人が気になるであろう、サービス開始後の状況についても語られた。現在1秒あたり数万のクエリー(処理要求)が飛んできているが、10ms以下という迅速なレスポンスが返せているという。
この結果について森山氏は「負荷試験のシミュレーションの結果通り。しっかりとテストを行なって良かった」と話していたが、「アイテム売買のクエリーが想定の数十倍程度呼び出されているので、さらなるチューニングが必要と感じている」と、想定外の部分もあるという。
また「順調なだけだと面白くないので……」と前置きした森山氏はトラブル例を挙げた。今回のデータベースの肝となったバックエンドサーバーにはサービス開始以来大きな問題が起きていないそうだが、1度だけデッドロック(2つのプロセスがお互いの処理が終わるのを待ち、どの処理も終わらないこと)が発生してしまったという。原因は「絶妙なタイミングで同時にアクセスが起きた」からで、森山氏「パフォーマンス面で大きな問題が起きていなかったので、このトラブルは非常に悔しい結果だった」と話した。もちろん、現在はその問題は解消されている。
森山氏はバックエンドサーバーの構築と運用がうまくいっている理由を2つ挙げた。1つは、「丁寧に時間をかけた負荷試験」。サービス開始後、「ドラゴンクエストX」全体で見るといくつかトラブルは起きているが、原因を見ると、負荷試験が難しかった箇所か、テストから漏れていた箇所がほとんどで、大きなミスはなかったという。「ドラゴンクエストX」は森山氏が関わったプロジェクトの中で最も負荷試験に手間と時間をかけたプロジェクトだったそうだが、「それだけの価値はあった」とプロジェクトを振り返っていた。
もう1点が、バックエンドサーバーの開発に関わったメンバーが目標やビジョンを共有できたことだという。「『ドラゴンクエスト』がオンラインになること」、「正式なナンバリングタイトルになること」という意識を共有し、数百万のプレーヤー(クエリ)が接続されることを意識できたので、このように強靱なバックエンドサーバーが用意できたと振り返った。
最後に「プロジェクトに参加したときは、バックエンドサーバーだけが空白の状態からのスタートでしたが、非常にやりがいのあるプロジェクトでした」と振り返る森山氏の満足げな姿が印象的なセッションだった。
(C)2012 SQUARE ENIX CO.,LTD.All Rights Reserved.(C)2012 ARMOR PROJECT/BIRD STUDIO/SQUARE ENIX All Rights Reserved.
(2012年 8月 23日)