株式会社セガ、グローバル展開タイトル『ソニックランブルパーティ』を少人数チームで支える Amazon EKS Auto Mode × Agones 活用事例

本記事は、株式会社セガとアマゾンウェブサービスジャパンが共同で執筆しています。

はじめに

株式会社セガは、家庭用ゲーム機、PC、スマートフォン向けゲームの企画・開発・販売・運営を軸に、各種コンテンツや商品を全世界へ届けています。同社では、比較的新しい技術も積極的に取り入れる文化のもと、複数タイトルで AWS を活用してきました。

本事例の対象は、同社が開発・運用する『ソニックランブルパーティ』の専用ゲームサーバー基盤です。『ソニックランブルパーティ』は、Dr.エッグマンが作り出したおもちゃの世界で、「ソニック」シリーズの人気キャラクターたちがスリリングな障害物コースや競技アリーナで競い合うマルチプレイパーティーゲームです。スマートフォンとPCのクロスプレイに対応し、2024 年に一部地域でソフトローンチを行い、2025 年 11 月にグローバルローンチを迎えました。

ソニックランブルパーティゲーム画面 1 ソニックランブルパーティゲーム画面 2 ソニックランブルパーティゲーム画面 3

※本画像は株式会社セガの許諾を得て掲載しています

本記事では、この専用ゲームサーバー基盤で、ゲームサーバーのオーケストレーションに Agones を用い、その基盤に Amazon EKS (Elastic Kubernetes Service) Auto Mode を採用した経緯と効果を、お客様の声を交えて紹介します。 EKS Auto Mode の採用により、開発環境では「ゼロインスタンス運用」によるコスト削減を実現、本番環境ではグローバルローンチ以降、インフラ起因の停止はなく安定稼働を続けています。加えてその運用負荷削減効果により、運用が軌道に乗ってからは API サーバーやデータベースも含めた全環境を 1 名のエンジニアで運用できています。

解決したかった課題

グローバルに展開するマルチプレイヤーゲームの専用ゲームサーバー基盤を、少人数のチームで開発・運用することが、本プロジェクトの大きな前提でした。マネージドサービスを活用する観点では Amazon GameLift Servers も選択肢ですが、選定当時はコンテナに未対応だったことに加え、技術のオープン性も重視した背景から、本プロジェクトでは Agones によるセルフホストを選択しました。Agones はオープンソースの専用ゲームサーバーホスティング製品で、Amazon EKS 上で利用でき、専用ゲームサーバーの構成を簡素化できます。しかし Kubernetes 基盤の運用は避けられず、Agones の運用には次のような負荷が存在します。

ノード管理・Amazon Machine Images (AMI) 更新：ノードのプロビジョニング、AMI のバージョン管理とセキュリティパッチ適用のための更新作業
スケーリング設計：需要変化に対してノードを迅速にスケールアウト・スケールインさせる仕組みの構築と運用
各種アドオンのバージョン管理：AWS Load Balancer Controller や kube-proxy 等のバージョンアップ対応

かつ本タイトルでは API サーバーに Amazon Elastic Container Service (ECS) を採用しており、Agones のためだけに Kubernetes の運用負荷を抱えるという課題がありました。

なぜ Agones on EKS Auto Mode を選んだのか

上記の課題の解決のため、Agones の基盤に Amazon EKS Auto Mode を採用しました。Amazon EKS Auto Mode は、2024 年 12 月の AWS re:Invent で一般提供が開始された機能で、Kubernetes クラスタのコンピューティング・ストレージ・ネットワーキングの管理を自動化します。Karpenter をベースとしたノード管理、Bottlerocket による最適化された OS、各種アドオンのマネージド管理により、ノード管理・AMI 更新・スケーリング・アドオンのバージョン管理が AWS の責任範囲となり、専用ゲームサーバー基盤の運用をシンプルにできる点が決め手でした。

アーキテクチャ概要

なお、本タイトルのデータベースに関する事例の詳細については、別記事 “株式会社セガ、グローバル展開タイトル『ソニックランブルパーティ』を少人数チームで支える Amazon DynamoDB / Amazon ElastiCache Serverless for Valkey 活用事例” にて紹介しています。

安定運用を実現するための設計

専用ゲームサーバーという特性上、EKS Auto Mode の採用における最大の検討事項は、EKS Auto Mode によるノードの自動中断と、Agones のゲームサーバーライフサイクル管理の競合でした。
EKS Auto Mode は、コスト最適化のための集約 (Consolidation)、設定変更や AMI 更新への追従 (Drift)、一定期間経過したノードの入れ替え (Expiration) など、様々な理由でノードを自動的に中断します。中断時には対象ノード上の Pod へ終了シグナル (SIGTERM) が発行されるため、対策をしないとプレイ中のゲームサーバーが強制終了されるリスクがありました。専用ゲームサーバーには「プレイ中のゲームセッションを中断させない」という強い制約があるため、この競合の解消が採用の鍵でした。

本プロジェクトでは、AWS の技術支援を受けながら、次の設計パターンを組み合わせてこの課題を解決しました。

猶予期間の設計：ノードが強制削除されるまでの猶予 (terminationGracePeriod) と、Pod が終了しきるまでの猶予 (terminationGracePeriodSeconds) を、ゲームの最大持続時間より長く設定します。ノード中断が発生してもプレイ中のゲームが終わるまで待ってから安全に停止できます。
シグナルハンドリングの実装：ゲームサーバーアプリが終了シグナルを受け取ったとき、進行中のゲームは終了を待ってから停止し、待機中のサーバーは新規割り当てをブロックして速やかに退去します。
ノード自動最適化の有効化 (spec.eviction.safe: Always)：Agones のデフォルト設定はノードの退去をすべてブロックし、EKS Auto Mode のコスト最適化やセキュリティパッチ適用を妨げます。この設定を変更することで、上記の猶予期間とシグナルハンドリングでプレイ中のゲームを守りつつ、EKS Auto Mode の自動最適化を活かします。
NodePool の分離：特性の異なる Agones のコントローラ系とゲームサーバー本体を別々のノードグループ (NodePool) に配置し、それぞれに適した猶予期間等を設定します。
可用性の確保：ゲームサーバーの割り当てを担うコンポーネント (agones-allocator 等) に PodDisruptionBudget (PDB) を設定し、ノード中断時にも機能を維持します。

これらの設計により、EKS Auto Mode の運用自動化のメリットを享受しながら、プレイ中のゲームを守る安定運用を実現しています。各設定の具体的な内容は、別記事 “Amazon EKS Auto Mode 上で Agones を安定稼働させる設計のポイント“で実装例を交えて解説しています。

導入して得られた効果

コスト：「ゼロインスタンス運用」により開発環境コストを大幅に削減

長期間の開発、目的別に多数の環境を維持する必要性、といった背景から、開発環境のコストは無視できません。本タイトルでは、EKS Auto Mode への移行により実現された Karpenter の高速スケーリングを活かし、開発者がいない時間帯はゲームサーバーが起動するノードを 0 台にし、マッチメイキング中に起動する「ゼロインスタンス運用」を実現しました。これにより、常時起動が必要ない開発環境の EKS ノードのコストを大幅に削減しました。

運用：日常的な運用作業からの解放

EKS Auto Mode への移行で、ノード管理や AMI 管理といった作業の大部分を任せることができ、EKS の運用設計における考慮事項を大きく減らせたとともに、運用工数も削減できました。例えばセキュリティパッチ適用のための AMI 更新作業では、通常は担当者のアサイン、スケジュール調整、影響確認、適用計画の作成、適用実施と、多くの場合に一週間以上かける作業が、本タイトルではほぼ対応不要と判断できています。またノードプールを yaml で定義・管理できるため、kubectl を中心とした kubernetes 標準の運用フローに統一できました。ノードプールの追加・変更もコードベースで管理できるため、設定変更や構成管理が容易になり、運用性・保守性の向上につながったと感じでいます。グローバルローンチ後は、一定期間 3 名体制で運用整備し、その後はAPI サーバーやデータベースも含めた全環境を 1 名のエンジニアで運用できています。

パフォーマンス：迅速なスケールイン・アウトでリソース利用効率向上

EKS Auto Mode はノードのスケールアウト・スケールインともに応答性が高く、Pod 需要の変化に対してクラスタが迅速に追従できました。その結果、ゲームサーバーがリソース不足で待機する時間を短縮できただけでなく、需要減少時には不要なノードも速やかに解放されるため、リソース利用効率も向上しました。また、本タイトルで独自に実装した Pod AutoScaler とも高い親和性を示し、Pod の需要変化に応じたスケーリング戦略をインフラ側へ迅速に反映でき、ピーク時の応答性と平常時の効率性を高いレベルで両立できています。

可用性：本番環境でもスムーズに移行、グローバルローンチ後も無停止で安定稼働

本タイトルでは、2024 年 12 月の一般提供開始と同時に EKS Auto Mode の検証を開始し、2025 年 1 月に開発環境へ、同年 3 月にはソフトローンチ済みの本番環境への導入が完了と、わずか 4 ヶ月でスムーズな移行を実現できました。2025 年 11 月のグローバルローンチ以降、専用ゲームサーバー基盤は安定稼働しており、インフラ起因のサービス影響のある障害は発生していません。

AWS による支援について

EKS Auto Mode と Agones の共存における安定運用のための設計にあたっては、AWS の SA (ソリューションアーキテクト) が支援しました。株式会社セガの担当者は、「EKS Auto Mode 導入時は既に一部地域でソフトローンチ済みで、運用中の環境に手を入れるリスクもありましたが、AWS 社員と直接密にやり取りできる形で随時技術支援をいただきながら進めることができ、対応も早く、安心して進めることができました」と語っています。

今後の展望

EKS Auto Mode と Agones を組み合わせた設計・本番運用は世界的にも先進的な取り組み事例となりました。本アーキテクチャは今後、部門のスタンダードアーキテクチャとして後続タイトルでも主要な選択肢となる見込みです。

まとめ

株式会社セガは『ソニックランブルパーティ』の専用ゲームサーバー基盤で利用する Agones を動作させる基盤として Amazon EKS Auto Mode を採用しました。Agones の柔軟性を活かしつつ EKS Auto Mode で運用管理をシンプルにすることで、グローバル規模のタイトルの少人数チームでの安定運用とコスト最適化を両立しました。

株式会社セガ第 4 オンライン研究開発プログラム部の穂園氏・松崎氏は、次のように振り返っています。

「以前はノードや AMI の管理、スケーリング設定に常に気を配っていましたが、EKS Auto Mode への移行後は日々の運用からほぼ解放されました。インフラを気にせず開発に向き合えるようになったことが、何よりの変化です。」