「AWS Summit Japan 2025」レポート

カプコン担当者「リージョンにあるインスタンスを使い切ってしまったことも」

「モンハンワイルズ」の舞台裏　数百万同時接続の“超高負荷”に耐えるクラウド構築テクニック

高負荷に耐えるデータベース、NoSQL/NewSQLを使い分ける

　続いては、データ周りの構成だ。

　モンハンワイルズのデータ保存には、とにかく大量トラフィックに耐えられるデータベース（DB）が必要だった。ユーザー数も未知数だったため、スケールしやすい「NewSQL」や「NoSQL」が候補に挙がった。NewSQLは、RDBのACID特性、トランザクションやデータの堅牢性を持ちつつ、スケーラビリティに優れている。一方、NoSQLは、スキーマレスで柔軟なデータモデルのため、パフォーマンスに優れている。モンハンワイルズでは、この両方を使用している。

データベースの選定

　メインDBにはNoSQLを据え、高性能なキーバリュー型の「Amazon DynamoDB」に大半のデータを保存している。パーティションキーとソートキーを組み合わせたプライマリキーを指定することで、バリューを取得する形だ。モンハンワイルズでは、「自身のフレンド一覧」や「クエスト履歴」など、ユーザー1人が対象のデータを引き出す機会が多いため、DynamoDBをメインにしている。

　DynamoDBでは、キャパシティーユニット（CU）の値を設定することで、その性能が担保されるため、トラフィック耐性もある。特定のキーだけにアクセスが集中する「ホットスポット」が発生すると性能が発揮されなくなるため、その点を配慮してCU調整をしたという。

　ただし、キーバリュー型であるため、複雑な検索には弱い。モンハンワイルズでそれに該当するのが、プレイヤーが他のプレイヤーをクエスト（特定の課題）に呼ぶ「救難信号」実行時の検索だ。「自動決定される条件（モンスターやフィールドなど）」と「プレイヤーが設定する条件（参加人数など）」をもとに検索処理を行うが、クエストごとに複数のモンスターが存在し、フィールドやプラットフォームなどカーディナリティが低い（ユニークな値が少ない）検索条件もある。「レコード数が膨大になり、かなり（検索処理が）きついデータ条件」（筑紫氏）

モンハンワイルズでの複雑な検索（救難信号）

　複雑な検索を実行するために利用しているのが、NewSQLのひとつである「TiDB」だ。開発当初は「Amazon Aurora Serverless v2」で試したてみたものの、最大性能や、アプリで水平スケール（水平分散）を実行する複雑さを考えて、TiDBに方向転換した。

　TiDBのメリットは、メンテナンスウィンドウがなく、ダウンタイムなしでスペックを変更できることである。データのリバランス機能によって、データを意識することなく、水平スケールも可能だ。一方で、デメリットは、内部的に複数レイヤで構成されているため、実行速度で劣ることだ。ホットスポットがあると性能が活かせないのは、DynamoDBと同様である。「いまならば、Amazon Aurora DSQLやAurora Limitless Databaseといった、AWSが提供するNewSQLも有力な選択肢になる」（筑紫氏）

TiDB（NewSQL）の利用

　NoSQLとNewSQLの使い分けに関しては、検索条件や結果表示に必要な情報だけをTiDBに保存し、そこからの詳細は、DynamoDBに保存している。これにより、TiDBに保存する情報やアクセス頻度を減らして性能を確保している。

　モニタリング関しては、AWSがマネージする「Prometheus」や「Grafana」で構成している。マイクロサービスアーキテクチャを採用しているため、APMには、分散トレーシングが可能な「AWS X-Ray」を採用している。