本記事は 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 では、運用面を比較します。 機能 Amazon EKS 上の Agones Amazon GameLift Servers コンテナのコントロールプレーン EKS のデプロイ、バージョンアップグレード、プラグインを自分で管理 サービスに組み込み済み セッションのライフサイクル管理 各リージョンの Agones コントローラーを自分で運用 サービスに組み込み済み セッションの割り当て Agones アロケーターを自分で運用 サービスに組み込み済み グローバルなゲームサーバーコンピューティング 各リージョンの Amazon EKS クラスターを自分で管理 サービスに組み込み済み マッチメイキング 自分で管理・運用 (Open Match やその他のソリューション) サービスに組み込み済み モニタリング Amazon CloudWatch の Container Insights と、Prometheus や Grafana などのソリューション サービスに組み込み済み ( 組み込みの統合サポート により Prometheus や Grafana を追加することも可能) フリートのオートスケーリング Eviction の管理と Karpenter サービスに組み込み済み リモートロケーションのクラスターと中央バックエンド間の通信 クラスター間の証明書ベースのセキュアな通信を自分で構築 サービスに組み込み済み リージョン間でのコンテナイメージのレプリケーション 自分で管理 サービスに組み込み済み Blue/Green デプロイ 独自の継続的インテグレーション / 継続的デリバリー (CI/CD) ソリューションを自分で構築 シンプル: ゲームのバージョンを透過的に切り替え可能 ゲームセッションの DDoS 保護 各リージョンで独自のグローバルリレーソリューションを自分で管理 (Quilkin など) サービスに組み込み済み Ping エンドポイント Agones インフラの一部としてデプロイし、自分で管理 サービスに組み込み済み ゲームサーバーのコンテナイメージ 自分で管理 自分で管理 表 1 – 運用機能の比較 本番環境に対応した Agones ベースのデプロイでは、最初のゲームサーバーをデプロイする前の段階で、ホームリージョンに 30〜40 個の Pod、追加ロケーションに 20〜25 個の Pod が必要になります。これらは、モニタリング、運用、パッチ適用、セキュリティ対策、そして支払いをすべて自分で担う必要のあるサービスやツールです。 Amazon GameLift Servers ベースのデプロイでは、ビルドを一度アップロードし、グローバルフリートとその設定を定義するだけです。補助的なツールはサービスによって管理されるため、自分で管理する必要はありません。 図 1 は、グローバルな本番環境に対応した Agones ベースのデプロイと Amazon GameLift Servers のデプロイについて、アーキテクチャの違いを大まかに示したものです。 図 1 – アーキテクチャの比較 ホスティングプロバイダーを選ぶ際には、コストも同様に重要です。表 2 では、コスト要素を比較します。 コスト要素 Amazon EKS 上の Agones Amazon GameLift Servers コンテナのコントロールプレーン Amazon EKS コントロールプレーンのコスト 追加費用なし ゲームサーバーコンピューティング Amazon Elastic Compute Cloud (Amazon EC2) のコスト GameLift Servers のコンピューティングコスト (EC2 に対して約 20% の追加料金) ゲームサーバーインスタンスのデータボリューム Amazon EBS のコスト 追加費用なし ゲームサーバーからプレイヤーへのデータ転送 (アウト) データ転送 (アウト) のコスト 追加費用なし 補助サービス (オーケストレーション、割り当て、リージョン間通信、Ping エンドポイント) すべての AWS リージョンにわたるすべてのシステムの Amazon EC2 コンピューティングコスト (リージョンあたり 20 個以上の Pod) 追加費用なし DDoS 保護 各リージョンの各アベイラビリティーゾーンにおける独自のリレーレイヤーのコンピューティングコスト 追加費用なし マッチメイキング コンピューティングコスト (Open Match など) 追加費用なし モニタリング Container Insights とカスタムメトリクスのコスト (Prometheus や Grafana) 追加費用なし (Prometheus や Grafana による追加のモニタリングは追加コストで利用可能) 表 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 に移行する際の手順は、比較的シンプルです。 Agones SDK の呼び出しを GameLift Servers SDK に置き換えるか、SDK Wrapperを使用する ゲームサーバー全体で単一のプライベートポートを使用する コンテナイメージをビルドし、 Amazon Elastic Container Registry (Amazon ECR) にプッシュする コンテナグループ定義を作成する コンテナフリートを作成する アロケーターをゲームセッションキュー (または FlexMatch) に置き換える バックエンドを更新し、接続情報の取得に Agones アロケーター API ではなく GameLift API を呼び出すようにする 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 でローンチを成功させるためのステップ：ローンチフェーズ 著者について Juho Jantunen AWS for Games チームのワールドワイドプリンシパルソリューションアーキテクトで、ゲームバックエンドとゲームサーバーホスティングのソリューションを専門としています。ゲーム業界とクラウドテクノロジーのバックグラウンドを持ち、数百万人のプレイヤーを抱える複数のタイトルについて、AWS 上でゲームバックエンドを構築・運用してきました。 この記事は Kiro が翻訳を担当し、Solutions Architect の西坂がレビューしました。

こんにちは、セーフィーでエンジニア・PdM・デザイナーの中途採用をしているNむらです。 エンジニアではない私がお邪魔しますという気持ちで今回記事を書いております。 タイトルの通り今回は、非エンジニアの私が採用オペレーションの自動化に挑戦してみたということでエンジニア採用に携わる方にとって、「私もやってみようかな」と思ってもらえるようなことをお伝えしていきたいと思います！ この記事はこんな方におすすめ 何かの作業を楽にしたい 壁打ち相談相手からもうちょっといい感じの生成AIの使い方を知りたい 非エンジニアの採用担当がどの程度使って、どの程度便利になってるのか実例を知りたい 1. 非

Go Conference 2026 に 今年はSilver スポンサーとして協賛いたします！ はじめに この度、株式会社エブリーは、2026 年 9 月 11 日(金)に開催される「Go Conference 2026」に、Silver スポンサーとして今年も協賛することになりました！ Go Conferenceとは？ gocon.jp プログラミング言語 ”Go”ユーザーのためのカンファレンスです。今年はハイブリッド開催で、会場でのセッションやワークショップに加え、セッションのオンライン配信も予定されています！ 今年の開催概要は以下のとおりです。 開催日時 2026年9月11日（金） 開催場所 東京都中野区中野4丁目10番2号 中野セントラルパーク サウス 1F / B1F 開催形態 オフライン / オンライン（セッションのみ配信） コンテンツ ・基調講演 ・セッション ・ワークショップ ・Official Party（懇親会） 昨年は Go 1.24 / 1.25 の新機能や言語内部を深掘りする発表が中心でしたが、今年はすでにGoコミュニティに参加している方、はじめてGoコミュニティに参加する方、みんなの学びや好きがより遠く深く広がるようなカンファレンスになるよう「 Go Far, Go Together 」というテーマが掲げられています。 また、プロポーザルの審査基準にも「自身の経験、知見に基づく、独自性のある内容であるか」とあるように今年の タイムテーブル を見ると独自性に富んだテーマが多く見られます。 例えば、海上で動くGoサーバー、Go におけるコンソールゲーム開発、9年のOSS保守で見た標準ライブラリとtestingの進化などです。 筆者個人としては、convto さんの「標準パッケージに uuid が追加された背景から見る Go らしい意思決定」が気になっています！ イベント当日について エブリーのブースでは、料理に関するクイズや、ノベルティ・キッチングッズなどが当たるくじ引き、アンケートボードを設置しています！ デリッシュキッチン 食クイズ ノベルティは弊社CTO慣習のオリジナルドリップコーヒー「CTO Blend」とステッカーをご用意しています！ ノベルティ 当日は弊社の Go エンジニアも現地に参加しますので、会場でお見かけの際はぜひお気軽にお声がけください！ 非公式アフターイベントのご案内 Go BASH Vol.3 ANDPAD、OPTiM、Resilire、エブリーの4社合同で、非公式アフターイベント Go BASH Vol.3 を開催します！ 今回の会場はエブリー本社です！ Go Conference 2026 の感想戦や各社のセッションなどのコンテンツを用意していますので、みんなで盛り上がりましょう！ 開催日時 2026年9月30日（水） 19:30〜21:00（19:15 開場） 開催場所 東京都港区六本木3-2-1 住友不動産六本木グランドタワー38F 株式会社エブリー本社 開催形態 オフライン コンテンツ ・各社のGoに関するセッション ・Go Conference 2026 感想戦 ・交流会 お申し込みは以下で行っております。みなさんのご参加をお待ちしています！ connpass.com 最後までお読みいただき、ありがとうございました！