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

カプコンの大人気ゲームを支えるサーバー環境

　カプコンが提供する「モンスターハンターワイルズ」は、オンラインプレイに対応したアクションゲームで、モンスターハンターシリーズの最新作。PlayStation、Xbox、PC（Steam）などのクロスプラットフォームに対応し、フレンド機能や最大100人が集まれるロビー機能などを通じ、プレーヤーが協力して遊べる点が特長だ。

　世界でも注目を集めており、発売から3日で800万本、1ヵ月で1000万本を売り上げた。Steamだけでも100万人以上が同時接続したことは大きな話題を呼び、多くの海外ユーザーもプレイしている。

　この大型タイトルを裏で支えているサーバー開発は、8人程度のメンバーで行われた。開発と運用チームは分離しておらず、「開発チームがそのまま運用チームに移行しています。アップデートが続くゲームのため、運用しながら開発も並行して進んでいるからです」と、モンスターハンターワイルズでリードサーバーエンジニアを務めた筑紫啓雄氏は語る。

　また、ゲームサーバーのデータベースに関する開発・運用にも、開発メンバー全員が携わっているという。サービスごとに担当者は決まっているものの、緊急時には横断的に対応できるよう、すべてのメンバーが全容を把握できる体制を敷いている。

　その中でリードサーバーエンジニアを務める筑紫氏は、サーバーのアーキテクチャ設計、各種レビューを担当。なお、ゲームリリース後は、開発実務を担当していた戎脇涼氏がリードサーバーエンジニアを引き継ぎ、サーバー運用の安定性確保やトラブル対応、アップデートへの対応などを担っている。

　今回、モンスターハンターワイルズには、主にAWSが用いられており、主要なサービスは、AWSのKubernetes環境「EKS（Amazon Elastic Kubernetes Service）」のコンテナプラットフォームで稼働している。各種機能を連携させるためのAPIサーバーは「AWS Fargate」、ゲーム内の同期通信が必要なロビーサーバーや集会所の機能部分には、OSSのKubernetesクラスターオートスケーラー「Karpenter」を用い、EKSのノードに展開することで実現した。

　サーバー台数について戎脇氏は、「ロビーサーバー向けに、全盛期には『c7gd.8xlarge』という大きめの物理ノードを600台確保し、その上に30万Podほどの規模で稼働していました」と説明。他にも、非同期通信のためのAPIサーバーが約500Podも稼働していたという。

ワークロードが変動するゲームサーバーでの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万人までの同時接続を想定したテストが行われており、性能の問題がないことを十分に確認している。

性能が高く、柔軟性があることが「コスト削減」にも貢献する

　大人気のゲームの立ち上がりは、極めてスムーズだった。ゲームリリース直後の週末には膨大なアクセスこそあったものの、戎脇氏は「何もトラブルは発生しませんでした」と振り返る。以降、ユーザー数の推移に合わせ調整を行い、当初9台ほどだったTiDB／TiKVの台数は、共に3台まで削減しても十分な性能を発揮しているという。これはコスト削減にも大きくつながっているとして、「柔軟性があり、TiDBの性能そのものが良いことが、コストを最適化できている要因だと思います」と筑紫氏も語る。

　当初想定していたデータベースの数や規模からすると、現状はかなり低コストに抑えられているという。特にゲームのようにユーザー数や負荷が変動しやすいシステムに対し、TiDBは非常に相性が良く、期待以上の費用対効果を発揮していると評価する。また、「アップデートでカラムを追加する際、ユーザー数が多いためレコード数も相当数あったのですが、コンマ何秒という速さで完了できました」と、TiDBの利点を挙げた。

　今回、TiDBが大きく貢献したこともあり、それだけに2人が寄せる期待も大きい。「オートスケールモードがあるとうれしい」と要望するのは戎脇氏。現在はTiDB Cloud Dedicatedを利用しているが、オートスケール機能がないためだ。急なユーザーの増減に対応するための運用コストをさらに下げるためにも、TiDB Cloud Serverlessにあるオートスケール機能が利用できると便利になるという。

　最後にあらためて筑紫氏は、負荷の変動が発生することが当たり前のオンラインゲームにおいて、ダウンタイムなしに拡張・縮退ができるTiDBは、「ゲーム業界とはかなり相性が良いデータベースだと思います」と強調する。時間帯による増減はもちろん、機能アップデートのタイミングでもアクセス状況が大きく変化する。だからこそ、TiDBの高い柔軟性が大きな強みになると語るのだった。