わずか3日で全世界販売本数800万本突破！ モンスターハンターワイルズにおけるTiDBの導入背景と役割［PR］

今年（2025年）2月にカプコンからリリースされた「モンスターハンターワイルズ」は、ハンターとなったプレイヤーが荒野を舞台にモンスターと戦いながらストーリーを進めていくオンラインゲームです。

人気シリーズ「モンスターハンターシリーズ」の最新作として、PlayStation 5、XBOX SERIES X|S、PC用ゲームプラットフォームのSteamに対応。プレイヤーのゲーム機器が異なっても同一のオンライン空間内で一緒にプレイできるクロスプラットフォームにもシリーズとして初めて対応しました。

本作は発売からわずか3日で全世界の販売本数が800万本、1カ月で1000万本を記録する超人気ゲームタイトルとなっています。

絶対にシステムを落とさない、負荷試験に6カ月

その同時接続プレイヤー数は、多いときにはSteam版だけで100万人超になったと発表されており、オンラインゲームを支えるバックエンドシステムに非常に大きな負荷がかかったことは想像に難くありません。

しかも本作ではオンライン上でプレイヤーが会合する「ロビー」と呼ばれる場所の人数を最大で100人にまで引き上げたことなどにより、従来よりもバックエンドにかかる負荷が大きくなることが予想されました。

バックエンドシステムを担当するチームでアーキテクチャの設計など品質を維持する責任を持つリードサーバエンジニア 筑紫啓雄（つくし あきお）氏と、同チームの戎脇涼（えびすわき りょう）氏は、開発工程における負荷試験だけで6カ月をかけたと説明しました。

それは「どう考えても負荷が大きな問題になることは分かっていた」からだと筑紫氏。

マイクロサービスアーキテクチャで構成されたバックエンドシステム

バックエンドシステムはほぼ全てがAmazon Web Services（AWS）上でマイクロサービスアーキテクチャにより構築されました。

その上で、ロビーのような同期的な処理を必要とするノード群はオートスケーラーのKarpenterを用いて制御。東京、アメリカ、ヨーロッパなど複数のリージョンに分散配置することでプレイヤーそれぞれが近いリージョンに接続でき、遅延が発生しにくい構成になっています。

非同期で済む処理を行うノード群はAmazon Fargateを用いて制御されています。

「最盛期にはc7g.8xlarge（32vCPU、64GBメモリ）と呼ばれる大きめのサーバが600台起動し、その上でロビー用のポッドが30万個ぐらい稼働していました」（戎脇氏）。

しかもあるリージョンの最盛期には、そのリージョンにおいて同種のサーバが売り切れるほど大量のコンピューティングリソースを消費するという事態が発生します。

こうした状況もあらかじめ想定されており、ある程度の遅延を覚悟の上で、リソースが豊富な米国内のリージョンでインスタンスを起動してリージョンをまたいで接続し代用する仕組みを発動させたことで対応したとのことです。

このようにして、モンスターハンターワイルズのバックエンドシステムは100万を超える大量の同時接続プレイヤーからの負荷を問題なくさばき切っています。

データベースにはDynamoDBとTiDBを採用

このバックエンドシステムを支えるデータベースとして採用されたのが、NoSQLの「Amazon DynamoDB」とNewSQLの「TiDB Cloud Dedicated」（以下、TiDB：タイデービー）です。

DynamoDBはキーバリューストアとして非常に高いスケーラビリティと可用性を備えるマネージドデータベース。一方のTiDBはMySQL互換のリレーショナルデータベースであり、水平分散による高いスケーラビリティなどを実現するマネージドデータベースです。

モンスターハンターワイルズはDynamoDBをメインデータベースとしており、プレイヤーのデータを含むほとんどのデータがDynamoDBに格納され、処理されています。

しかしDynamoDBでは処理できないと考えられる要件がありました。ゲーム内で「救難信号」と呼ばれる機能の実装です。

救難信号とは、プレイヤーがモンスターと戦う際に、他のプレイヤーに向けて救難要請の信号を発する機能です。

救難信号は全世界のプレイヤーが受信可能となっています。各プレイヤーはそのとき発信されている救難信号について、クエストの種類や難易度、プレイヤーの使用言語などのさまざまな条件で検索し、選択したプレイヤーの救難へと駆けつけることができます。

DynamoDBは高性能なデータベースではありますが検索条件の指定に制限があり、柔軟な検索を得意としていません。

筑紫氏は、「DynamoDBでこのような検索処理を行うのは困難だろうと判断していたので、何かしらのSQL系データベースを採用することは最初から考えていました」と、当時を振り返ります。

よりスケーラブルなRDBを求めた結果、TiDBを採用

開発当初、救難信号の機能はAmazon Aurora Serverless V2で実装されました。しかし想定される大規模なプレイヤー数、しかもその増減幅も大きいこと、また今回はじめてクロスプラットフォーム対応することを想定すると、よりスケーラブルな仕組みを備えた分散型データベースが望まれました。

そこで注目されたのが、すでに同社の別のゲームタイトルで使われて実績のあった「TiDB」でした。

「稼働中でもアップデートできるためにメンテナンスウィンドウがないとか、ダウンタイムなしでサービスのスケールイン／スケールアウトができるなどの話を聞き、さらにTiDBの内部実装なども説明してもらい、これは使えそうだということで採用を決めました」（筑紫氏）。

すでにAmazon Aurora Serverless V2で開発が進んでいたため、MySQL互換が望ましかったこと、運用のコストを下げられるマネージドデータベースを選択できることも、TiDB採用の理由となりました。

Amazon AuroraからTiDBへ切り替え

Amazon Aurora Serverless V2からTiDBへの切り替えは負荷試験の直前に行われました。しかも開発メンバーに知らせることなく切り替えたところ、まったく気づかれなかったとのこと。

アプリケーションのコードは一切変えず、接続先の向きを切り替えるだけでTiDBが使えるようになったのです。

「結局は移行の手間がかかるんでしょう？ と思っていました（笑）」（戎脇氏）。

TiDBに対する負荷試験は、最大で500万人を想定した規模まで拡大しましたが、まったく余裕で対応できたとのことでした。

TiDBの稼働中にノードを減らしても問題なし

TiDBはコンピューティング部分を担う「TiDB」とストレージ部分を担う「TiKV」のクラスタシステムで構成されています。

ローンチ時は余裕を持って、16CPU／32GBメモリのノードをTiDBが10ノード、TiKVが9ノード割り当てられていました。

この構成でローンチ後を全く問題なく乗り切った後に、負荷に合わせてノード数をそれぞれ3ノードにまで削減していきます。

「サービスイン中、同時接続が5万くらいある状態でノードをごそっと外しました。けれども何も問題は起きない。ダウンタイムなしで性能の調整ができるというTiDBの特徴を本当に最大限活用させていただきました」（戎脇氏）。

TiDBは規模からするとかなり低コストに抑えられた

TiDBには「救難信号」の実装にぴったりな機能もあったと説明されました。それが、一定時間が超過したデータを自動的に削除してくれる「TTL」（Time To Live）です。

救難信号は、それを発信したプレイヤーがいるクエストの制限時間が過ぎれば不要となります。救難信号のデータを自動的に消してくれるTTLの機能があることで、いちいちデータを消し込むための作り込みが不要となったのは本当に助かったと戎脇氏は話します。

また、運用開始後のTiDBのチューニングにあたり、ダッシュボードが非常に使いやすかった点も評価されていました。

TiDBのコスト面でも、筑紫氏は「想定していたデータベースの数や規模からするとかなり低コストに抑えられたかなと思います」と期待以上だったことを明かしました。

理想のデータベースに近づくTiDB

今回、カプコンはモンスターハンターワイルズのバックエンドシステムにおいて、要件に合わせてDynamoDBとTiDBという2つのデータベースを使い分けています。

しかし理想的には「当然、安くて性能の高いデータベースひとつで済めば一番それがいい」と筑紫氏。今回のシステム構築を振り返ると「そもそもチャレンジしていなかったのですが、ひょっとしたらTiDBだけでいける可能性もあったのかな」と、TiDBの性能やスケーラビリティを高く評価していました。

戎脇氏も「もう少し規模の小さいゲームであれば、次にチャレンジしてみてもいいかもしれませんね」と同意します。

お二人ともTiDBはオンラインゲームとの相性が非常によいと高く評価しており、今後のTiDBの進化と可能性にさらなる期待を寄せています。

ゲーム開発の最前線にTiDBがどう貢献しているのか。詳しくは、2025年10月3日（金）開催の「TiDB User Day（TiUD）」 のセッションでご確認ください。

≫TiDB Cloud Dedicated

（本記事はPingCAP Japan提供のタイアップ記事です）