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

2021年07月16日 07時00分更新

文●grasys　編集● ASCII

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

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

　DGSはこれまで主にプロプライエタリシステムとして開発されてきましたが、より柔軟でコストメリットの高いクラウド化が進み、オープンソース標準が主流になりつつあります。そこで今回は、Kubernetes上でのDGSの構築・管理を可能にするGoogle Cloudの“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と直接通信し、ゲームができるようになります。