お問い合わせ

※この記事は2021年5月26日に放送された Google Cloud (GCP) Day:Digital‘２１ のセッション内容をもとに作成しています。

Agones と Game Servers を使ってKubernetes 上でリアルタイム マルチ対戦ゲーム環境（DGS）を構築する方法

世界中で配信され、オンラインで同時プレイされるような、大人数で動きの速いマルチプレイゲームでは、多くの場合ゲームの世界を可能な限りリアルタイムに近い速度でシミュレートするために、プレイヤーが接続する専用ゲームサーバーが必要です。この専用ゲームサーバーを「Dedicated Game Server（以下、DGS）」と呼び、DGS はプレイヤーのステート（状態）を管理する役割を果たします。

DGS はこれまで主にプロプライエタリシステムとして開発されてきましたが、より柔軟でコストメリットの高いクラウド化が進み、オープンソース標準が主流になりつつあります。そこで今回は、Kubernetes 上での DGS の構築・管理を可能にする Google Cloud (GCP) の“ Agones ” と “ Game Servers ” について解説しながら、リアルタイム マルチ対戦ゲーム環境の構築・管理を行う具体的な方法を紹介します。

Kubernetesをゲームサーバー管理に使う理由

今回 DGS に着目したのは、Kubernetes との相性の良さにあります。DGS と Kubernetes では、下記の図で示しているように「ログ、処理結果の保存」、「スケール」、「ライフサイクル」の3つの共通点があります。特に「ライフサイクル」の観点では、DGSはステートフルなアプリケーションでありながらもゲームの計算結果をメモリ上に保持し、データベースなどと異なりライフサイクルが比較的短い性質のものが多いため、短いコンテナライフサイクルに適している Kubernetes と相性がいいと言えます。

オートスケール機能を使う場合の注意点

Kubernetes を利用するにあたり、コストメリットなどからオートスケール機能を使いたいと思う方もいるかもしれません。しかしオートスケールを使うと、スケールインで問題が発生する可能性があるので注意が必要です。ゲームのイベント実施時など、プレイヤーからのアクセスが集中してサーバー負荷が急増する場合に備え、Kubernetes のオートスケール機能を使うことで、あらかじめ設定した定義に基づいて自動でスケールアウトを行い、Pod を増やして負荷を分散することが可能です。その後アクセス集中が落ち着き、サーバー負荷が下がったら、今度は定義に基づいて自動でスケールインを実行し、Pod を動的に減らしていきます。

しかし、ここで削除対象となる Pod にプレイヤーが接続中かどうかを Kubernetes 側で判断することができません。プレイヤーは Pod とのリアルタイム通信によってゲームをプレイできるため、プレイヤーと接続中の Pod がスケールインで意図せず削除されてしまうと、プレイヤーがゲームを継続できなくなってしまいます。このように、Kubernetes のオートスケール機能を使う場合、定義や機能のチューニングはあくまで人的作業となるため、結果として管理の複雑化やボトルネックの発生につながるリスクがあります。こうした問題を解決し、チューニングの効率化・システム化を行うために開発されたソフトウェアが Agones です。

Agones で Kubernetes スケール制御の一部を効率化

Agones は Ubisoft と Google が共同開発しているオープンソースソフトウェアです。マルチプレーヤー専用のゲームサーバーをスケーリング・オーケストレーションするためのプラットフォームを提供しており、Kubernetes を使用して DGS をホスティングすることができます。Agones は、Kubernetes を実行可能な環境であれば、インストールすることでどこでも実行可能です。 Allocator という機能によって Pod にプレイヤーが接続中かどうかを判断し、プレイヤーがゲームを終了した時に削除を実行するなどの設定ができるため、オートスケールを効率的に運用することができます。

Agones には下記のような独自のリソースがあり、Kubernetes のリソースと同様に YAML や json で定義が可能です。

  • GameServer：ゲームサーバーそのもの
  • Fleet：ウォームアップ済みで、実行中のゲームサーバーに割り当てが可能な GameServer の集まり（グループ）のこと
  • GameServer Allocation：Fleet の中の GameServer を実行中のゲームサーバーへ割り当てる機能
  • Fleet Autoscaler：プレイヤーの状態変化にともなう Agones のステート更新に応じて、Fleet のスケールアップ/ダウンを実行する機能 

例として、ゲーム開始時の Agones リソースによるステータス管理について説明します。Agones が Kubernetes 上で動作しており、役割を持ったコンテナが複数デプロイされている状態です。マッチングサーバーからゲーム開始の処理を受けた Agones-Controller は、Game Fleet と呼ばれる Game Server をまとめるグループの中から未割り当ての Game Server用Pod を選択し、「ゲーム開始」というステータスとともに割り当てます。

ゲーム終了時には、Agones-Controller が Pod のステータスを「ゲーム終了」と更新し、このプレイヤーが接続していない状態の Pod が削除されます。Pod の削除後、Kubernetes の性質により未割り当ての状態の Pod が再作成されます。ゲームの処理に応じて任意にステータスを持たせることも可能です。

このように、Agones を使うことでゲームのステータスを管理できるようになるため、Kubernetes 側でスケールイン時に Pod とプレイヤーの接続状況がわからなくても、意図しないスケールインを防ぐことが可能です。しかし、Agones はリージョンを跨いだオートスケールには非対応なので、ワールドワイドなゲームサーバー環境を Agones だけで実現するのは困難です。そこで登場するのが “Game Servers” です。

ワールドワイドな環境構築ができるGame Servers

Game Servers は、Google Kubernetes Engine 上で実行される Kubernetes クラスタをサポートするように設計された、ワールドワイドに対応したゲームサーバーのデプロイと管理が容易にできるマネージドゲームサービスです。Game Servers を使用することで、Kubernetes や Game Servers のフリートオーケストレーション、ライフサイクル管理用の Agones を使用したゲームサーバークラスタの管理ができるようになります。また、既存のゲームセッションに干渉せず、Game Servers による管理へのクラスタの接続、切断をいつでも行うことができます。クラスタの切断後、オープンソースの Agones をインストールし、Agones による管理を行うことが可能です。

また、Agones と GameServers によるゲームサーバー環境構築の手順は以下の通りです。

1. Game Server Deployment と Config を定義する

※Game Server Deployment（GSD）：世界中のデプロイ可能なゲームサーバーを管理するリソース。
※Game Server Config（GS Config）：サーバー数やバッファなどを指定する GSD のサブリソース。

2. GSD をデプロイすると、GSD の定義によって各リージョンの Realm にある Game Servers クラスタの DGS Pod が作成される。この際、ひとつの Config を全クラスタに適用することができる。

※Realm（レルム）：ゲームのレイテンシ要件に基づくGSクラスタのユーザー定義グループ。
時間に基づくスケーリング機能について、Realm 内のクラスタで使用できるタイムゾーンが割り当てられる。

※Game Servers クラスタ（GS クラスタ）：Agones がインストールされた Kubernetes クラスタで、
Realm のサブリソースとなる。

例えば、日本のプレイヤーがゲームにアクセスしたとします。まずマッチング成立のため、マッチングサーバーへ接続されます。 マッチングサーバーはゲーム開始準備のために日本のリージョンにある Realm 内の Agones と通信し、割り当て可能な DGS Pod があるかを確認します。この際、ステート管理や割り当ては Agones に任せることができます。 Agones によって DGS Pod が割り当てられると、Pod のエンドポイントの IP とポートがゲームプレイヤーに返されます。 こうして、日本のプレイヤーが日本リージョンの DGS Pod と直接通信し、ゲームができるようになります。

Game Serversを使用する際の注意点

Game Servers のリソースには依存関係があるため、削除時には順番を遵守する必要があります。正しい順番は以下の通りです。

  1. Rollout（default-config,config-overrides）
  2. GS Config
  3. GSD

※Rollout：GSD に基づき、GS config を対象となる Realm にマッピングするリソース

ゲームサーバーを運用する中で、異なるバージョンの専用サーバーをデプロイする場合には、RealmSelector の定義を記述した YAML または json ファイルによってデフォルトの Config をオーバーライドする必要があります。

参考

Agones ―― Kubernetes 上でのゲーム サーバー構築をサポートするオープンソース プロジェクトが始動

Game Servers

Google Cloud (GCP) Game Servers (beta) の紹介 | by Yutty Kawahara | google-cloud-jp