発売からわずか1か月で世界累計1000万本を売り上げた、カプコンのゲームタイトル「モンスターハンターワイルズ」。リリース時には数百万件の同時接続を達成し、シリーズ初の試みとして「クロスプレイ」にも対応している。その“超高負荷”を支えるクラウドインフラは、どんな壁を乗り越えて構築されたのか。
「AWS Summit Japan 2025」のDay2（6月26日）に開催されたセッション「モンスターハンターワイルズ 100万以上のユーザー同時接続を支えたネットワークアーキテクチャ」では、大量トラフィックが見込まれるゲームサーバーをゼロから構築する中での、技術選定や独自の工夫、苦労話が語られた。登壇したのは、カプコンのCS 第二開発統括 システム基盤部 ネットワーク開発室 エンジニアである筑紫啓雄氏だ。
大規模ゲームサーバーをゼロから構築、マイクロサービスアーキテクチャ採用の良し悪し
モンスターハンターワイルズ（以下、モンハンワイルズ）は、2025年2月28日に発売された、「モンスターハンター」シリーズの最新作である。
今作では、ネットワーク面で2つの大きな挑戦をしている。ひとつは、同シリーズで初となる、プラットフォーム（Steam、Xbox SeriesX/S、PS5）が異なるユーザー同士でも遊べる「クロスプレイ」への対応。そしてもうひとつは、最大100人が集まれる「ロビー」を実装したことだ。
これらの新たな要素は、これまで同シリーズで利用していたプラットフォーマーのネットワークでは実現できなかった。そのためカプコン自身で、膨大なトラフィックが見込まれるゲームサーバーをゼロから構築する必要があった。
モンハンワイルズのサーバー群は、大きく2種類に分けられる。ひとつは、APIを提供する「APIサーバー」。もうひとつは、ユーザーの位置やキャラクターの情報を他のユーザーと同期するための「リアルタイムサーバー」だ。APIサーバーは、データベースなどを国内に集約しているため日本リージョンに設置。一方で、ユーザーの情報の受け渡しがメインとなるリアルタイムサーバーは、各国のリージョンに分散配置してレイテンシ（通信の遅延）を抑えている。
筑紫氏はまず、APIサーバーの舞台裏から紹介した。
APIサーバーは、マイクロサービスアーキテクチャで構成されている。その理由は、アプリケーションやサーバー数が巨大になるため、責任範囲を独立させて柔軟性を得ること、そして開発を高速化することだという。フロントのAPIサービスにhttpリクエストを集約して、バックサービスへの受け渡しはOSSのRPCフレームワークであるgRPCで通信している。
サーバーアプリケーションは、12サービスに分割した。「開発時はさらに多かったが、管理が煩雑になるので統合した。本来はドメインを定義して分割すべきだったが、意外と困らなかった。ただ、障害発生時の影響範囲が大きくなることには注意が必要だった」と筑紫氏。
マイクロサービスアーキテクチャの利点は、分散トレーシングによって、サービス単位でエラーやレイテンシ（遅延）が特定できることだ。加えて、各担当者がコンフリクトを気にすることなく実装でき、特定のサービスでバグが発生した場合も、更新が容易だったという。
その反面、難しかったポイントは「CI/CDの複雑化」だという。ビルドするアプリケーションが多いため、バージョン管理を行うCI/CDの構築・管理に手間がかかった。また、マイクロサービスでよく言われる「データ操作時のトランザクション」にも苦労したと振り返る。「アプリを極力『2層コミット』しないデザインで設計して、どうしても必要な場面は、データに状態を持たせることで解決した」（筑紫氏）
サービスメッシュにApp Meshを採用、しかし突然の「サービス終了」告知…！
APIサーバーのインフラには、ノード管理が不要な「Amazon EKS on Fargate」を採用した。ただし、サーバー（pod）の立ち上がりに1分ほどかかり、DaemonSetの技術が使えないのが難点だったという。「なぜコントロールプレーンをECSにしなかったというと、リアルタイムサーバーでミドルウェアの『Agones』を採用するため。APIサーバーだけをECSにするという手もあったが、バージョン管理などの手間を考えて統一した」（筑紫氏）
API GatewayやApp Runnerなどを用いたサーバーレス構成も検討したが、常にトラフィックが発生し続け、リクエスト数も多いため、コストが増大してしまう。コスト面を考えて、EKSを選択したという。
サーバー間通信をインフラ層で制御するサービスメッシュにおいても、管理コストを減らすために、AWSのマネージドサービス「AWS App Mesh」を選択している。この技術によって、サービス障害時に該当サービスのインフラだけを制御する「サーキットブレーカー」や、新バージョンの公開範囲を段階的に広げる「カナリアリリース」などが実装できる。
しかし、モンハンワイルズのオープンβテスト（2024年10月）の直前に、App Meshのサービス終了（2026年9月30日で終了）が告知された。やむを得ず、App Meshと同様にサービス間通信を制御できる「Amazon VPC Lattice」に置き換えることにして、負荷試験などをやり直した。
「（Latticeは）マイクロサービス以外での利用やVPC間の通信に強みがある、モンハンワイルズにとってはリッチなサービス。ただし、プロキシサーバー（envoy）が不要となり、その分のpodのリソースが浮く。サービスディスカバリーやアクセス制御、トラフィック制御など、（App Meshとは）完全に別物として扱う必要があったが、管理コストを減らすために、OSSではなくVPC Latticeへの移行を決断した」（筑紫氏）
App Meshのサービス終了までは猶予があったものの、第2回のオープンβテスト（2025年2月）までに、なんとか置き換えを完了させた。プロキシサーバーがなくなったことで、消費リソースは減少したが、代わりにレイテンシが増加してしまった。筑紫氏は、「これまでは1リクエスト30msec（ミリ秒）のレイテンシだったが、150msec程度に上昇した。ただ、それでもなんとか許容範囲だった。ゲームではUI表示に時間がかかるため、ユーザーへの影響はほとんどなかった」と振り返る。
「ロビー」サーバーは超高負荷、リージョンのインスタンスが“売り切れ”に…！
続いては、リアルタイムサーバーの舞台裏だ。
リアルタイムサーバーの役割は、最大100人まで同時参加できる、「ロビー」というオンライン空間（他のプレイヤーとマルチプレイや交流を行う“待合所”）を提供することだ。レイテンシを抑えるために、主要各国のリージョンに分散配置し、さらにロードバランサーなども通さずに接続している。
最大100人分のパケットをリレーするサーバーのため、“超高負荷”なのが特徴だ。アプリケーションをチューニングする余地も少ないため、解決策として、AWSの第3世代カスタムArｍプロセッサー「AWS Graviton3」を採用した。「Gravitonの“うたい文句”どおりに、実際にパフォーマンスが向上したのには驚いた」と筑紫氏。
クラスターあたりのpod数も数万を超えている。そのため、EKSクラスターの負荷対策として、クラスター自体を増やしており、リージョン内でも複数クラスター（多いリージョンでは5つ）を立てている。
リアルタイムサーバーは、「条件」ごとに動的にスケールする戦略をとっている。「条件」とは、各ロビーに設定された特徴（そこに集まるプレイヤーのプレイ傾向、使用言語、強さの目安など）を指す。例えば“初心者向け”ロビーが満員になったら、その条件だけスケールアウトするといったイメージだ。単純にCPUやメモリの消費量で制御するのではなく、人数によって制御しているのは、「消費リソースがユーザーの動きや接続数で大きく変わる」ためだという。
スケーラーサービスには、AWSが開発するOSSの「Karpenter」を利用。また、スケールアウトの仕組みは、ミドルウェアの「Agones」で実現した。
インスタンスに関しては、「Graviton3ベースのC7gインスタンスで運用していたが、リージョンのインスタンスを使い切ってしまったことがあった。一時期、本番環境では30万podほどを使っていた」という、驚異的なエピソードもある。これはAWSにも相談し、インスタンスの“売り切れ”を検知した場合は、リソースが豊富なリージョンにインスタンスを立てて、そこに接続する仕組みをつくった。
高負荷に耐えるデータベース、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も有力な選択肢になる」（筑紫氏）
NoSQLとNewSQLの使い分けに関しては、検索条件や結果表示に必要な情報だけをTiDBに保存し、そこからの詳細は、DynamoDBに保存している。これにより、TiDBに保存する情報やアクセス頻度を減らして性能を確保している。
モニタリング関しては、AWSがマネージする「Prometheus」や「Grafana」で構成している。マイクロサービスアーキテクチャを採用しているため、APMには、分散トレーシングが可能な「AWS X-Ray」を採用している。
安心して運用するために「AWS Countdown Premium」を利用
負荷試験では、リッチなウェブ画面が用意されている「Locust」を利用した。また、負荷をかけるクライアントとしては、Gravitonやスポットインスタンスを使うことでコストが抑えられる「Amazon ECS」を用いた。
試験の結果、最終的には「500万同時接続」相当まで達成。「唯一、救難信号の検索がヘビーなテストだった。もっとも、マネージドサービスをメインに構成しているため、全体的に困ることはなかった」（筑紫氏）
筑紫氏が「こうしておけばよかったかも」とこぼしたのは、APIサーバーの構成だ。「EKS on Fargateは、性能面では十分だったが、コスト面では、Gravitonとスポットインスタンスが利用できるECSの方が優れている。特に、開発環境でコストがかさんでしまった」と振り返った。
こうした未練もあるものの、モンハンワイルズは無事リリースされ、リリース時の同時アクセス数は数百万件を記録。サービスが落ちることはなく、結果は「大成功」だった。
サービス運用に万全を期すために、クラウド移行やピーク対応といった、ビジネスクリティカルなイベントを支援する「AWS Countdown Premium」を利用している。今回、AWS側には、事前にアーキテクチャや機能をレビューしてもらい、「EKSのインスタンス容量（EBS）のクォータ（リソースの制限）を引き上げたほうが良いのではないか」といったアドバイスをもらったという。
もちろん、トラブル時の緊急対応でもサポートを受けている。たとえば、オープンβテストの際に、監視システムで一部がクォータ制限に引っかかった際には、当日中にクォータが引き上げられた。「モンハンワイルズの規模になると、クォータ申請はかなりの数に上り、通常はその対応に数日かかる。大規模サービスやイベントを安心してリリースしたい場合には、おすすめのサービスだ」（筑紫氏）
最後に筑紫氏は、開発・運用まわりの体制について情報を共有した。所属部署共通で利用しているプログラミング言語はGo。チーム体制は8名で、それぞれに担当するマイクロサービスも割り当てていたが、基本的には各メンバーが横断的に動いているという。
筑紫氏は、「カプコンは、ゲームクライアントだけではなく、先端技術で品質の高い、トップクラスのネットワークも開発できることを、このチームを通じて示すことができた」と締めくくった。
コメント