なぜカプコンは超人気ゲームにTiDBを選んだのか？モンスターハンターワイルズを支えるDB基盤に迫る

ワークロードが変動するゲームサーバーでのTiDBの優位性

　ゲームのユーザーデータは「Amazon DynamoDB」をメインデータベースとし、大半のデータを管理している。その一方、「複雑な検索や負荷の高いアクセスが必要な一部のデータには、TiDBを利用しています」と戎脇氏。ゲーム内で実現される機能には、データ検索が必須なものがある。たとえば「救難信号の検索機能」では、他のユーザーが募集しているクエストをフィールドやモンスター、難易度などの条件で検索が必要だ。ここにTiDBが活用されている。

　開発当初からメインデータをDynamoDBで管理することは決まっていたが、要件として検索が必要になることも認識しており、「DynamoDBでは不可能だろう」と判断していたという。そのため、SQL系データベースの採用を検討。その候補には「Amazon Aurora」や「Elasticsearch」なども挙がる中、“使い慣れたMySQLベースのものを選択したい”との要望があった。

　そこで「Amazon Aurora Serverless v2」のMySQL互換エディションを検討するも、「単一のRDBであるため性能に限界があり、データベースの水平分散が必要になるという懸念もありました」と筑紫氏。特にユーザーの増減に対応するための管理コストが高くなることも予測されたため、分散データベースの管理をある程度自動化できるソリューションを求めていたという。

　そこで白羽の矢が立ったのがTiDBだ。既にTiDBは、社内の別プロジェクトで利用実績があり、運用コストの削減につながるマネージドサービスも提供されていた。加えて、メンテナンスウィンドウがなく、ダウンタイムなしでサービスのスケールイン／アウトができるとの情報も得られたため、TiDBのワークショップなどに参加。実装方法などの具体的な情報も得られたことで、「これは使えると判断し、採用を決めました」と筑紫氏は語る。

　また、モンスターハンターワイルズにTiDBを採用した、もう一つの理由に「TTL（Time To Live）」機能の存在があった。たとえば、ユーザーがゲームプレイをやめた際、サーバー上から消えてほしいデータがあるとき、通常は手動で該当データを検索・削除する必要があるなど、大きな手間がかかってしまう。しかしTTL機能ならば、レコードの最終更新時間を参照することで、指定した時間経過で自動削除できる。戎脇氏は「TTL機能には、かなり助けられました」と太鼓判を押す。実際にクエストの制限時間にあわせて、最終更新から1時間程度でデータが自動的に消えるよう設定されているという。

　さらに開発用データベースとして採用したAmazon Aurora Serverless v2では、1テーブルあたり100個ほどのインデックスを張ると性能不足に陥り、「性能確保のために100テーブル程度に垂直分割していました」と戎脇氏。TiDBに移行した際にも同様の設定を引き継いだが、TiDBではほとんど負荷が上がることはなかった。十分な性能があるため、TiDBではこれほどテーブルを分割しなくても対応できたとして、「もっとTiDBの性能を信じれば良かったです」と苦笑する。

　大部分の検索においては、APIサーバーからTiDBにアクセスして処理されるが、ユーザーインターフェースが表示されるまでに結果が得られれば良いため、それほどシビアなレスポンスは求められない。一方で、集会所やロビーといった同期通信が必要な部分では、遅延が許されない。そのため東京、アジア、米国、ヨーロッパの各リージョンにそれぞれロビーサーバーを配置し、各地域のユーザーは該当するリージョンに接続する設計となっている。

　これにより大きな遅延は発生しなくなるが、ユーザーの同時アクセスが大きく増加すると、リージョンによってはAWSのリソースが枯渇することも予測された。そこで特定のリージョンでリソースが切れた場合は、ある程度の遅延を許容して、他のリージョンに接続させる仕組みを用意。実際に発売直後にリソース切れが発生し、無事にリージョンを切り替えて運用できたという。こういうところからもモンスターハンターワイルズの人気ぶり、そして相当のスケーラビリティが求められていることがわかる。

　ところで、開発環境だったAmazon Aurora Serverless v2からTiDBへの移行は、「接続先を切り替えるだけで使えました」と戎脇氏。アプリケーションのコードを一切変更せずとも、極めてスムーズに移行できたのだ。特にデータベースを切り替えた際には、データベースが切り替わったことに気づかないメンバーがいるほどで、その負荷は極めて低かったという。

　なお今回のTiDBの検証においては、負荷試験に半年ほどの時間を割いて、綿密なテストが実施された。最大500万人までの同時接続を想定したテストが行われており、性能の問題がないことを十分に確認している。