「AWS Summit Japan 2025」レポート

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

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

　

「ロビー」サーバーは超高負荷、リージョンのインスタンスが“売り切れ”に…！

　続いては、リアルタイムサーバーの舞台裏だ。

　リアルタイムサーバーの役割は、最大100人まで同時参加できる、「ロビー」というオンライン空間（他のプレイヤーとマルチプレイや交流を行う“待合所”）を提供することだ。レイテンシを抑えるために、主要各国のリージョンに分散配置し、さらにロードバランサーなども通さずに接続している。

　最大100人分のパケットをリレーするサーバーのため、“超高負荷”なのが特徴だ。アプリケーションをチューニングする余地も少ないため、解決策として、AWSの第3世代カスタムArｍプロセッサー「AWS Graviton3」を採用した。「Gravitonの“うたい文句”どおりに、実際にパフォーマンスが向上したのには驚いた」と筑紫氏。

　クラスターあたりのpod数も数万を超えている。そのため、EKSクラスターの負荷対策として、クラスター自体を増やしており、リージョン内でも複数クラスター（多いリージョンでは5つ）を立てている。

リアルタイムサーバーの特徴

　リアルタイムサーバーは、「条件」ごとに動的にスケールする戦略をとっている。「条件」とは、各ロビーに設定された特徴（そこに集まるプレイヤーのプレイ傾向、使用言語、強さの目安など）を指す。例えば“初心者向け”ロビーが満員になったら、その条件だけスケールアウトするといったイメージだ。単純にCPUやメモリの消費量で制御するのではなく、人数によって制御しているのは、「消費リソースがユーザーの動きや接続数で大きく変わる」ためだという。

　スケーラーサービスには、AWSが開発するOSSの「Karpenter」を利用。また、スケールアウトの仕組みは、ミドルウェアの「Agones」で実現した。

ロビーごとの条件

　インスタンスに関しては、「Graviton3ベースのC7gインスタンスで運用していたが、リージョンのインスタンスを使い切ってしまったことがあった。一時期、本番環境では30万podほどを使っていた」という、驚異的なエピソードもある。これはAWSにも相談し、インスタンスの“売り切れ”を検知した場合は、リソースが豊富なリージョンにインスタンスを立てて、そこに接続する仕組みをつくった。

インスタンスにまつわる小話