はじめに
AWS Summit Japan 2025に参加してきました！
国内最大級のAWSイベントということもあり、会場の盛り上がりは物凄く、人で溢れ返っておりました！
どのブースにも活気があり、夏場ということもありましたが会場の熱気は最高潮でした！
AWS Summit Japanとは？
AWS Summit Japanとは、AWSが主催する "AWSを学ぶイベント" です。先ほども述べたように 国内最大規模 のもので、毎年多くの人や企業が参加しています。
クラウド技術から最近のトレンドである生成AIまで、AWSや様々なスポンサー企業が活用事例を展示し、多くの人に向けてより実践的なヒントを得られる場であったり、情報交換やビジネスの場としての役割を果たしています。
レポートするセッションの紹介
さて、今回記事にさせて頂くセッションは、モンスターハンターシリーズなどでお馴染みのカプコン様によるセッション講演の、 『モンスターハンターワイルズ100万以上のユーザー同時接続を支えたネットワークアーキテクチャ』 です。
セッション講演で扱う題材は、シリーズ最新作である 「モンスターハンターワイルズ」 です。発売から約1か月で販売本数1000万本を突破し、非常に多くのユーザーにプレイされたゲームであり、グローバル同時接続数が100万人を記録しました。
そんな大量のユーザーアクセスを支えたAWSネットワークアーキテクチャについての工夫や苦労といった舞台裏についての内容でした。
セッション概要：グローバル100万人同時接続を支える技術
本セッションでは、2025年発売の**「モンスターハンターワイルズ」（以下、MH Wilds）における自社ネットワーク基盤の構築とスケーリング**に関する裏話が紹介されました。
なぜネットワークを自社運用に切り替えたのか？
- クロスプレイ（プラットフォームを超え一緒にゲームをプレイする仕組み）実現のため
- 従来のモンスターハンターシリーズはPlayStation Networkを使用していたため、サーバーが必要なかった
- 自社でのゲームサーバー構築は初挑戦
- 初挑戦ながら、グローバルで同時100万人という大規模アクセスに対応する必要があった
ネットワークアーキテクチャ構成の全体像
MH Wildsの構成は大きく分けて以下の2種類のサーバーで構成されています。
| サーバー種別 | 主な機能 | 配置リージョン |
|---|---|---|
| APIサーバー | Web API処理、認証など | 日本に集約（データベースなどがすべて日本に集約されている為） |
| リアルタイムサーバー | ロビー同期、位置情報などの低遅延通信 | 世界中（レイテンシを抑える為に複数リージョンへ展開） |
APIサーバー構成の特徴と工夫
■ 技術構成
- Amazon EKS on Fargate
- マイクロサービスアーキテクチャ（12サービス）
- 通信には gRPC を採用
-
サービスメッシュ：App Mesh → VPC Lattice へ移行
- MH Wildsの開発中に、App Meshが2026年9月30日にサービス終了というアナウンスがあり、急遽移行する必要が生まれた
■ マイクロサービス採用の狙い
- システムの疎結合化による、開発の柔軟性の確保と高速化
- 障害やレイテンシの切り分けを容易にする（分散トレーシング）
■ 課題と解決策
| 課題 | 対応・工夫 |
|---|---|
| サービス間トランザクションの管理 | 2相コミットを避ける設計と、状態遷移の管理で回避 |
| CICDの複雑化 | サービス統合で運用を最適化（最初はかなりの数があったが、最終的に12個へ縮小した） |
| App Meshが2026年9月30日にサービス終了 | Amazon VPC Lattice へ移行。パフォーマンス面も再検証 |
| レイテンシ上昇（30ms → 150ms） | 許容範囲内で、ユーザー影響なし。初期RPS制限はAWSと調整で解決 |
リアルタイムサーバー：100人ロビーを支える仕組み
■ 役割と構成
- 最大100人のロビーで位置や状態をリアルタイム同期
- Agones（オープンソースのゲームサーバー管理ツール）＋ EKS
- レイテンシ最小化のため、ALBを介さず接続
- Graviton3インスタンスでパフォーマンス最適化
■ スケーリング戦略
- 条件ごとにロビーを個別スケール
- 条件は主に、初心者かどうかや、使用言語、プレイヤーのランク
- CPUやメモリではなく、ユーザー数によるスケーリング
- Karpenter（AWS製スケーラー） でPodの最適配置を行う
■ トラブルと対処
セッション内では、本番環境でのスケールに伴うリソース枯渇というトラブルが発生したことが紹介されました。
-
トラブル内容
Graviton3ベースのC7系インスタンスを使用していたあるリージョンにおいて、プレイヤー同時接続数が約30万POTに達したタイミングで、当該リージョンのインスタンス在庫が枯渇するというトラブル -
対処方法
→ us-east-1リージョンにインスタンスの余剰があったため、そちらでインスタンスを立ち上げ、既存環境と接続する仕組みを構築することでリソースを補完し対処
データベース構成：NoSQL＋NewSQLのハイブリッド運用
| 分類 | 使用サービス | 主な用途 |
|---|---|---|
| NoSQL | Amazon DynamoDB | フレンド・履歴など1人単位の取得 |
| NewSQL | TiDB（Auroraから移行） | 救難信号・サークルの複雑検索 |
■ ハイブリッド構成の工夫
- 検索条件のみTiDBに保存し、詳細はDynamoDBで取得
- ホットスポット回避・スキーマレス対応でパフォーマンス維持
モニタリング・APM・負荷試験
■ モニタリング
- Amazon Managed Prometheus／Grafanaで構築
- メトリクス表示用独自クエリ言語のPromQLの学習に苦戦
- 50GBのメモリ使用など、収集負荷は高め
■ APM：AWS X-Ray
- 分散トレーシングによる障害箇所の特定
- 関数別時間やスタックトレースの可視化で運用負荷低減
■ 負荷試験
- ツール：Locust＋Amazon ECS＋Graviton3＋Spot
- 最大500万同時接続相当までテスト成功
- 救難信号検索はキャッシュ＋DB最適化で対応
サポート体制：AWS Countdown Premiumの活用
このプロジェクトの裏側には、AWSの支援がありました。それは、AWS Countdown Premiumという、ビジネスクリティカルなイベントを成功に導くAWSのプレミアム支援サービスです。
AWS Countdown Premiumの所感
- AWS SAと連携した事前設計レビューと緊急対応体制
- 難しい技術課題への真摯な対応など、人的リソースによる支援
- 講演者の方曰く「安心してGo-Liveできる心強い支援」
成功の鍵と学び
| 成功要因 | 解説 |
|---|---|
| 自社基盤構築による運用自由度の確保 | クロスプレイの実現と高トラフィックへの対応 |
| 柔軟なAWSサービス構成と即応性 | App Mesh終了→VPC Lattice移行など迅速な意思決定 |
| オープンソースとマネージドの併用 | Agones＋KarpenterなどのOSSをAWSリソースで運用 |
| AWS支援の活用 | Countdown PremiumやSAのサポートによる信頼構築 |
最後に：カプコン様のチャレンジが示した未来
MH Wildsの成功は、単なるゲーム開発ではなく、「大規模リアルタイムサービス×クラウド活用」のベストプラクティスとなるものでした。
本セッションを通じて、カプコン様は「技術力」「運用力」「パートナー連携」の重要性を具体的な事例とともに示していたのが印象的でした。
参考リンク
- [モンスターハンターワイルズ公式発表記事]