Agones は何であって、何でないか

Googleが Agones というプロジェクトを進めている。 また、Google Cloud Game ServersというGoogle Cloud上でAgonesを管理できるサービスを発表したことで話題になった。

このAgonesというプロジェクトが何をするもので、何をしないものなのか?

公式サイトを開くと

Host, Run and Scale dedicated game servers on Kubernetes

と書いてあり、ゲームサーバーを作るための製品であることがわかる。 しかし、Host, Run and Scaleと言われて具体的にAgonesが何をするライブラリなのかがすぐには想像がつきにくい。

Agonesはマルチプレイ向けゲームエンジンではない

ゲームサーバー用のライブラリと聞くと、Photon EngineモノビットEngineのように多数のプレイヤー間のメッセージのやり取りをするためのものを想像するかもしれないが、Agonesはそうではない。

Agonesはゲームのロジック部分にはほとんど関与せず、ゲームサーバーが動くインフラを管理しやすくするソフトウェアである。 また、インフラといっても特にAgonesはKubernetesで管理されたインフラであることが前提となっている。

Agonesが解決する課題

では、Agonesはゲームサーバーのインフラのどのような課題を解決しているのか。

スケールインからの保護

サーバーの数を負荷に応じて自動で増減するという戦略はよくとられる。 状態をほぼ持たないHTTPサーバーなどであれば大抵はうまくいくのだが、ゲームサーバーとなると少し事情が違ってくる。

ゲームサーバーは複数のプレイヤーがサーバーにつないでいて、プレイ中はずっとつなぎっぱなしの状態を持つ。 たとえある瞬間は通信が何もなくても、1秒後にはまた何らかの通信をするかもしれない。 ゲームプレイ中に自動増減による削減(スケールイン)が実行されてしまうと、ゲームが突然中断されてしまう。

そこでAgonesは、ゲームサーバー専用の状態を取得・設定可能として、「このサーバーは現在使用中かどうか」をKubernetes上で管理できる。 その上にAgones独自のオートスケール機能があり、それを使うと使用中のサーバーはスケールインからは保護される。

プレイヤーの直接接続のサポート

Webアプリなどでは、クライアント(ブラウザやアプリ)からの接続はまずロードバランサーに行き、そこから後ろに控えてるサーバー群のどれかに分散される、という方式が主流だが、ゲームサーバーはまた事情が違ってくる。

たとえば対戦ゲームであれば、同じマップにいるプレイヤーの動きを他のプレイヤーに高速で伝えなければならない。 そうなると、同じゲームに参加するプレイヤーは同じサーバーに接続することになる。

さらに、一度接続したプレイヤーはひとつの試合が終わるまではずっと同じサーバーにつなぎっぱなしになる。 よって、前段にまずロードバランサーを挟んでそこから分散するというやり方は基本的に通用しない。 プレイヤーは直接ゲームサーバーに接続する必要がある。

そこで、Agonesは「今からこのサーバーを使用したい」という要求にあわせて 動的にIPとポート番号を割り当てて外部から直接接続可能にする仕組みが用意されている。

その他いろいろ

他にもサーバーの生存確認や、Prometheus exporterなど便利機能がある。 全部書いてると大変なのでここでは省略。

Agones は Kubernetes の拡張機能である

ここまではKubernetes特有の用語を使わずに解説したが、Agonesは実はKubernetesの拡張機能(CRD)である。

KubernetesにはPodやDeploymentといった要素があるが、それに似せつつも機能を拡張したGameServerやFleetという要素を作り出し、 KubernetesのAPIに則って操作できる

これがAgonesのとても重要なポイントで、Agonesを管理する操作はAgones独自のプロトコルなどではなく、KubernetesのAPIで操作できる。

たとえば現在立っているゲームサーバーを一覧したい場合でも、Kubernetesではおなじみの kubectl コマンドが使える。

$ kubectl get gameserver
NAME               STATE   ADDRESS     PORT   NODE       AGE
simple-udp-6mjqg   Ready   10.0.2.15   7020   minikube   3s

よって、Agonesはこれからインフラ構築のスタンダートとなっていきそうなKubernetesのAPIに乗っかって、ゲームサーバーも同様にいい感じに管理できるようにしたいよね。というテーマで開発されたソフトウェアだということがわかった(多分)。

今後Agonesは流行るのかどうか?

Agonesを使うためにはまずKubernetesを用いたインフラ構成が必須だ。 正直、ゲーム業界ではサーバーをKubernetesで管理するということ自体がまだ目新しく、あまり広まってない印象がある。

よって、まずはKubernetesによるゲームサーバーのインフラ構築が当たり前になっていかないと、Agonesが流行るのはむずかしいだろうなぁと思った。

さらに、Agonesが助けてくれるのはインフラ管理の部分だけである。 ゲームサーバーの実装は結局独自で用意しないといけない(しかも、Kubernetesで動作するようにコンテナ化しないといけない)。

オンラインゲームのサーバー実装というのはWebアプリほど民主化されておらず、 オンラインゲームを作っている企業も頑張って自社でエンジンを作っているか、上で挙げたPhoton Engineのようにインフラまで込みで指定されたものを使っているのが現状である1。 よってAgonesを導入できたとして、ゲームサーバーの実装はどうやって作るんだという話になり、なかなか採用しにくいのではないかと思う。

しかし、このまま消えていくかというわけではなくコンテナ技術でサーバーを運用するという流れ自体は加速していると感じるので、ゲーム業界もじわじわとコンテナが当たり前になっていくのではないかと思っている。Agonesは現時点では”早すぎる”かもしれないが、Agonesが解決する課題を把握して実装を学ぶことはやっておいて損はないだろう。


  1. これはあくまでも自分の観測範囲内での話なので、海外まで目を広げるとオープンなものが広まっているのかもしれない…