【参加レポート】 AWS Summit Japan 2025 Day2

こんにちは！マネージドサービス部の加藤（貴）です。

先日、AWS Summitに初めて参加してきたので、その際に聴講したセッションの内容をブログにまとめていきたいと思います！本ブログでは、二日目のセッション内容をご紹介します。

一日目のブログはこちらになります。【参加レポート】 AWS Summit Japan 2025 Day1 - サーバーワークスエンジニアブログ

スペシャルセッションビルダーのための AWS テクノロジー：その深化と進化
モンスターハンターワイルズ 100万以上のユーザー同時接続を支えたネットワークアーキテクチャ (株式会社カプコン)
まとめ

スペシャルセッションビルダーのための AWS テクノロジー：その深化と進化

二日目も朝一のセッションから聴講しました。

本セッションで個人的に特に興味深かったのが、株式会社NTTドコモ様の「データドリブンなモバイルネットワーク運用」です。

まず驚いたのが、ネットワーク機器の監視台数が約120万台に及ぶという点でした。

その数もさることながら、膨大なデータを集約してリアルタイムに処理しているのは、さすがだと感じました。

取り組みの3つの柱として「Observability」「Automation」「AI, Digital Twin」を挙げられていました。

「Observability」ではAmazon Timestream、「AI, Digital Twin」ではAmazon Neptuneを活用した事例が紹介されました。

「Observability」のデータベースは、元々RDSを利用していたものの、クエリの複雑さや実行時間の長さに課題があったそうです。そこでAmazon Timestreamに移行したことで、大量の時系列データを扱ってもレスポンスが高速になったとのことでした。

用途に応じたサービス選択の重要さを改めて実感しました。

続いて「AI, Digital Twin」での実装内容です。

グラフのプロパティとしてアラーム情報や利用量の情報を持たせ、大量のアラームデータ受信を契機に被疑箇所を分析。運用担当者に通知が届くまで、わずか約15秒という速度には非常に驚きました。

このグラフデータ化には、とても地道で泥臭いデータ整合作業が必要だったとのことです。

運用業務の効率化に繋がる仕組みを作れるように、自身も精進しようとモチベーションがアップしたセッションでした！

モンスターハンターワイルズ 100万以上のユーザー同時接続を支えたネットワークアーキテクチャ (株式会社カプコン)

本セッションでは、私もプレイしたことのある名作ゲームのネットワークアーキテクチャが紹介されました！

世界的に大ヒットしているゲームシリーズの最新作を支える技術ということで、会場も満員で立ち見の方も多く、非常に注目度の高いセッションでした。

マイクロサービスアーキテクチャの採用

まず、100万以上の同時接続という大規模なトラフィックを捌くアーキテクチャとして「マイクロサービス」を採用したというお話がありました。アプリケーションやサーバーが巨大になることを見据え、開発速度の向上と柔軟性の確保を狙ったとのことです。サーバーアプリケーションを12のサービスに分割したそうですが、そこにはやはりメリットとデメリットがあったと語られていました。

良かった点

各サービス担当者がコンフリクトを気にせず開発できる
サービス単位で課題（エラーやレイテンシ）の切り分けがしやすく、チューニングが容易
運用中に特定サービスのみをアップデートできる

難しかった点

サービスが十数個にも及ぶため、CI/CDの構築や管理が複雑になる
複数のサービスをまたぐデータ操作時のトランザクション管理に気を配る必要がある

複雑な検索を実現するDB戦略

セッションの中で特に興味深かったのが、データベースに関するお話です。「モンスターハンター」ではお馴染みの「救難信号」や、コミュニティ機能である「サークル」など、プレイヤーが仲間を探すための検索機能は条件が多岐にわたり、DB設計の大きな課題になったそうです。

そこで採用されたのが、NewSQL (TiDB) と NoSQL (Amazon DynamoDB) を組み合わせたハイブリッド構成でした。元々はAmazon Aurora Serverless v2を利用していたそうですが、性能や水平分散の複雑さを考慮し、TiDBへ変更したとのことです。さらに、検索に必要な情報のみをTiDBに、詳細なプレイヤー情報などはDynamoDBに格納することで、TiDBへの負荷を下げてパフォーマンスを確保しているとのことでした。

安定運用の要となるモニタリング

最後に、システムの安定運用に不可欠なモニタリングについても触れられました。モニタリングには Amazon Managed Service for Prometheus と Amazon Managed Grafana を、APM（アプリケーションパフォーマンス管理）には AWS X-Ray を採用されていました。収集用サーバーのメモリ管理や、独自クエリ言語「PromQL」の学習コストの高さといった、現場ならではの苦労話も聞くことができました。