Kubernetes と Agones から Amazon GameLift Servers への移行

本記事は 2026 年 8 月 17 日 に公開された「Migrating from Kubernetes and Agones to Amazon GameLift Servers」を翻訳したものです。

Kubernetes 上で動作する Agones は、専用ゲームサーバーをホストするためのオープンソースソリューションとして広く使われています。単一クラスター、単一の AWS リージョンでの構成であれば、専用ゲームサーバーのホスティング基盤として十分に機能します。しかし、グローバルな本番環境の規模になると、Agones の管理は複雑になり、ロケーションごとに複数の補助システムを構築・運用する必要が生じます。具体的には、リージョン間のセキュアな通信、プライベートネットワーク接続、ゲームセッションのアロケーター、マッチメイキング、モニタリング、そして Agones 自体が含まれます。これらはすべて、最初のゲームサーバーをデプロイする前に必要になります。

こうした運用の複雑さとそれに伴うコストから、多くの開発者はフルマネージドなグローバルゲームサーバーホスティングに Amazon GameLift Servers を選んでいます。Amazon GameLift Servers は、グローバルなゲームサーバーオーケストレーションの管理に加えて、リアルタイムの分散型サービス拒否 (DDoS) 保護とマッチメイキングを追加コストなしで組み込みで提供します。さらに、第 6 世代以降のインスタンスでは料金にデータ転送 (アウト) の料金も含まれており、総所有コストを大幅に削減できます。

Amazon GameLift Servers はまた、グローバルなゲームサーバーオーケストレーション全体に対して 99.95% の可用性 SLA を提供します。Agones ベースのソリューションでは、基盤となる Amazon Elastic Kubernetes Service (Amazon EKS) の SLA を超える部分はすべてユーザーの責任になります。

本記事では、この 2 つのホスティングオプションの違いをいくつか取り上げ、Agones ベースの実装から Amazon GameLift Servers へ移行する方法を解説します。

運用面とコスト面の主な違い

本番環境における 2 つのオプションの主な違いは、コストと運用の複雑さにあります。表 1 では、運用面を比較します。

表 1 – 運用機能の比較

本番環境に対応した Agones ベースのデプロイでは、最初のゲームサーバーをデプロイする前の段階で、ホームリージョンに 30〜40 個の Pod、追加ロケーションに 20〜25 個の Pod が必要になります。これらは、モニタリング、運用、パッチ適用、セキュリティ対策、そして支払いをすべて自分で担う必要のあるサービスやツールです。

Amazon GameLift Servers ベースのデプロイでは、ビルドを一度アップロードし、グローバルフリートとその設定を定義するだけです。補助的なツールはサービスによって管理されるため、自分で管理する必要はありません。

図 1 は、グローバルな本番環境に対応した Agones ベースのデプロイと Amazon GameLift Servers のデプロイについて、アーキテクチャの違いを大まかに示したものです。

図 1 – アーキテクチャの比較

ホスティングプロバイダーを選ぶ際には、コストも同様に重要です。表 2 では、コスト要素を比較します。

表 2 – コストの比較

表のとおり、コストはさまざまな要素で構成されます。中でも重要な 2 つの要素は、コンピューティングとデータ転送 (アウト) です。Amazon GameLift Servers ではデータ転送 (アウト) が料金に含まれますが、独自の Agones ソリューションではトラフィックの GB 単位で課金されます。データ転送のコストは、ゲームサーバーホスティングの総コストの最大 40〜50% を占めることもあります。コンピューティングについては、Amazon GameLift Servers では約 20% の追加料金を支払いますが、補助ツールに関する追加コストは一切かかりません。Agones ベースのソリューションでは、こうしたコストがリージョンをまたいで積み上がっていきます。Amazon GameLift Servers には、マッチメイキングと DDoS 保護が組み込まれています。いずれも、そうでなければ大きなコストになりかねない機能です。

データ転送 (アウト) や補助ツール、マッチメイキング、データボリューム、高度な DDoS 機能が料金に含まれることで、Amazon GameLift Servers はほぼすべてのシナリオで最もコスト効率の高いソリューションになります。さらに、これらの機能がマネージドであることで運用の複雑さが軽減されるため、ゲームサーバーの実装と最適化に集中できます。

ここまで Amazon GameLift Servers の運用のしやすさ、コスト、機能面での利点を説明してきましたが、それでもよりカスタムなデプロイが必要になる状況はあります。たとえば、ゲームサーバーノード間の緊密な連携を必要とする、大規模に分割された MMO ゲームなどのユースケースは、Amazon GameLift Servers での実装が難しい場合があります。単一プロセスで最大数百のゲームセッションをホストする基本的なリレーサーバーも、このサービスにとって最適とは言えないもう 1 つのユースケースです。これは、Amazon GameLift Servers がゲームセッションとゲームサーバープロセスの 1 対 1 のマッピングを前提に設計されているためです。

Agones から Amazon GameLift Servers への移行

既存の Agones ベースのソリューションから Amazon GameLift Servers に移行する際の手順は、比較的シンプルです。

1. Agones SDK の呼び出しを GameLift Servers SDK に置き換えるか、SDK Wrapperを使用する
2. ゲームサーバー全体で単一のプライベートポートを使用する
3. コンテナイメージをビルドし、Amazon Elastic Container Registry (Amazon ECR) にプッシュする
4. コンテナグループ定義を作成する
5. コンテナフリートを作成する
6. アロケーターをゲームセッションキュー (または FlexMatch) に置き換える
7. バックエンドを更新し、接続情報の取得に Agones アロケーター API ではなく GameLift API を呼び出すようにする
8. Agones インフラを廃止する

各手順を詳しく見ていきましょう。

ステップ 1: Agones SDK を GameLift Servers SDK に置き換えるか、SDK Wrapperを使用する

Agones SDK の統合 (SDK.Ready()、SDK.Shutdown()、SDK.Health()) を、Amazon GameLift Servers SDK の対応するものに置き換えます。ここで重要な概念上の変化は、Agones がプル型 (サーバーまたは外部のアロケーターが Allocate() を呼び出す) であるのに対し、Amazon GameLift Servers はプッシュ型 (セッションを配置する際に、サービスが選択したゲームサーバー上の OnStartGameSession コールバックを呼び出す) である点です。WebSocket 接続を確立する InitSDK()、OnStartGameSession と OnProcessTerminate のコールバックハンドラーを備えた ProcessReady()、そしてセッションの完了を通知する ProcessEnding() を実装します。Amazon GameLift Servers SDK は C++、C#、Go で利用でき、Unreal Engine と Unity 向けのプラグインも用意されています。SDK の統合とゲームセッションのライフサイクル管理の仕組みについては、ブログ記事「Amazon GameLift Servers でローンチを成功させるためのステップ：開発フェーズ」で詳しく解説しています。

完全な SDK 統合を行いたくない場合は、Containers Starter Kit がサイドカーソリューションを提供します。これは、サーバービルドを変更することなく、サービスに必要な接続を自動的に実装します。

ステップ 2: ゲームサーバー全体で単一のプライベートポートを使用する

Agones は、パブリックからプライベートへのポートマッピングを行いません。各 Kubernetes ノード上で、設定された範囲 (たとえば 7000〜7029) からホストポートを直接割り当てます。ゲームサーバーはそのポートにバインドし、プレイヤーは同じポート番号でノードの IP に接続します。Amazon GameLift Servers では、コンテナが内部ポートを定義し、EC2 インスタンス上の外部ポートへのマッピングはサービスが管理します。つまり、ゲームサーバーのコードは、外部に公開されるポートを認識したり気にしたりする必要がありません。Agones SDK を使って割り当てられたホストポートを検出して登録する代わりに、内部ポートにバインドし、外部へのマッピングは Amazon GameLift Servers に任せます。そしてセッションが配置されると、サービスがクライアント向けに正しい接続情報を返します。たとえば Unreal Engine で開発されたゲームであれば、すべてのサーバーがデフォルトの 7777 ポートを登録するといった形になります。

ステップ 3: コンテナイメージをビルドして Amazon ECR にプッシュする

Amazon GameLift Servers のコンテナフリートは、Amazon ECR からイメージをプルします。フリートを作成する AWS リージョンと同じリージョンにプライベートな ECR リポジトリを作成し、ゲームサーバーイメージにタグを付けてプッシュします。既存の Docker file は、通常そのまま使えるか、わずかな修正で済みます。コンテナのエントリーポイントは、どちらのシステムでもゲームサーバープロセスです。前述の Containers Starter Kit は、このプロセス全体を自動化します。

ステップ 4: コンテナグループ定義を作成する

コンテナグループ定義を作成して、コンテナのアーキテクチャを定義します。これは Agones の Fleet スペックと Pod テンプレートに代わるものです。ECR イメージ URI と、コンテナグループの vCPU およびメモリの上限を指定します。ロギングやモニタリング用のサポートコンテナ (サイドカー) を追加することもできます。Amazon GameLift Servers は、指定したリソース上限とインスタンスタイプに基づいて、各 EC2 インスタンスに収まるコンテナグループのレプリカ数を自動的に計算します。これは、Agones がリソースリクエストに基づいて Pod をノードに配置する方法に似ています。この手順でも、Containers Starter Kit に要件を満たすための自動化が含まれています。

ステップ 5: コンテナフリートを作成する

コンテナグループ定義、EC2 インスタンスタイプ、地理的なロケーションを指定して、マネージドコンテナフリートを作成します。この単一のリソースが、EKS クラスター、ノードプール、Agones のインストール、Helm チャート、cert-manager、そしてマルチクラスターの割り当て設定に取って代わります。Amazon GameLift Servers は、インスタンスのプロビジョニング、基盤となる OS、コンテナのデプロイ、ヘルスチェック、オートスケーリングを処理します。単一のフリートに複数のロケーションを追加すれば、複数リージョンでの展開が可能です。VPC ピアリングやクラスター間の TLS 通信は必要ありません。ホームリージョンからリモートロケーションへの通信は、サービスによって完全に管理されます。

ステップ 6: アロケーターをゲームセッションキュー (または FlexMatch) に置き換える

フリートを指すゲームセッションキューを作成します。これは、独自の Director、マルチクラスターの Agones アロケーター、そしてリージョン間の TLS/VPC ピアリング接続に代わるものです。キューは、レイテンシーベースまたはロケーション優先度ベースのルーティングにより、ロケーション間での配置を処理します。組み込みのマッチメイキングが必要な場合は、チームサイズ、スキルレンジ、レイテンシー許容範囲を定義したルールセットを使って FlexMatch を設定します。それ以外の場合は、バックエンドから直接 StartGameSessionPlacement() をプレイヤーのレイテンシーデータとともに呼び出し、最適なロケーションをキューに見つけさせます。

ステップ 7: バックエンドを更新し、接続情報の取得に Agones アロケーター API ではなく GameLift API を呼び出すようにする

現在、バックエンドサービスは、ゲームサーバーの接続情報 (GameServer.Status の IP とポート) を Agones アロケーター API に問い合わせています。これを、キューイベントの処理に置き換えます。配置が完了すると、Amazon Simple Notification Service (Amazon SNS) の通知を受け取ります。マッチメイキングに FlexMatch を使用している場合は、FlexMatch イベントを使用することもできます。これらのイベントには、クライアントがサーバーへの接続を認証するために使用する、ゲームセッションの IP アドレス、ポート、プレイヤーセッション ID が含まれます。Amazon GameLift Servers は、オプションのプレイヤーセッション管理も提供します。これを採用することも、既存のソリューションを引き続き使用することもできます。Event-based session placement のガイダンスには、キューを効果的に使用するためのアーキテクチャとサンプルコードが含まれています。

ステップ 8: Agones インフラを廃止する

トラフィックが完全に Amazon GameLift Servers に移行され、検証が完了したら、Agones スタックを廃止します。これには、EKS クラスター (全リージョン)、VPC ピアリング接続、Open Match のデプロイ、cert-manager、Amazon ECR のレプリケーションルール、および関連するノードグループが含まれます。これにより、プラットフォームを稼働させるためだけに動いていた、ホームリージョンの 30〜40 個、各リモートリージョンの 20〜25 個のシステム Pod がなくなります。

まとめ

本記事では、Agones ベースのソリューションと Amazon GameLift Servers の主な違いを、運用とコストの観点から説明しました。運用面では、Amazon GameLift Servers に比べて Agones の方がはるかに多くの責任を負うことがわかりました。コスト面では、無料のデータ転送 (アウト)、料金に含まれる補助ツール、そして追加機能により、Amazon GameLift Servers が多くの場合によりコスト効率の高いソリューションになります。

また、Agones から Amazon GameLift Servers への移行手順も紹介しました。ほとんどのゲームでは、ゲームサーバーとゲームバックエンドのロジックに必要な変更はわずかで、シンプルかつ手間のかからないプロセスになるはずです。

マルチプレイヤーゲームサーバーのホスティングに、今すぐ Amazon GameLift Servers を使い始めましょう。ビジネスの加速をどのように支援できるかについては、AWS 担当者にお問い合わせください。

参考資料

• Amazon GameLift Servers Developer Guide
• Free Network Bandwidth for Amazon GameLift Servers is Here
• Amazon GameLift Servers でローンチを成功させるためのステップ：ローンチフェーズ

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の西坂がレビューしました。