フェスティバトルのインフラアーキテクチャ

コロプラではGKE上にAPIサーバー、バックエンドにCloud Spannerを利用している点が特徴的ではあるものの、構成は一般的なWebサービスと大きな差はありません。
ゲーム特有のアーキテクチャとして特徴的なのは、専用ゲームサーバーのオーケストレーションにAgonesを利用していることです。
Agonesを利用して専用ゲームサーバーを割り当てる際、コロプラでは前段にその割り当て先を決めるAllocator Service（図のAgones Allocatorの部分）を独自で開発しています。
この独自開発したAllocator Serviceのメンテナンスコストを減らす、最終的にはコンポーネント自体をなくすことは、複数のゲームタイトルを同時に開発・運用するコロプラにとって課題の一つです。

この独自のAllocator Serviceを開発している理由の一つに、Agonesでは一度割り当てた専用ゲームサーバーを再割り当てする方法がなかったことが挙げられます。 コロプラでは数人単位でグループを作るゲーム（MO形式）が多いため、コロプラの専用ゲームサーバーではルームと呼ばれるグループにマッチしたユーザー同士を詰め込むことで、ユーザー間の通信ができるようになっています。
ルームは1つの専用ゲームサーバー内に複数作ることができるため、1プロセスでより多くのユーザー通信を処理することができ、効率的にサーバーリソースを利用できるというメリットがあります。
しかしながら、このルームという概念を実現するためにはすでに割り当ての完了している専用ゲームサーバーを再割り当てする必要があります。
今回フェスティバトルではこの専用ゲームサーバーを再割り当てする仕組みをHigh Density GameServerパターンを導入することで実現し、よりAgones標準のAllocator Serviceに近づけることで移行しやすくしています。

現在のアーキテクチャの課題と今後の改善予定

Agonesでは現在、よりコロプラのユースケースに沿った形で専用ゲームサーバーのオーケストレーションを実現できるCountersAndLists機能が開発中です。
CountersAndListsは自分たちで用意した値（例えばルームIDのようなもの）をGameServerリソースに保持することで、専用ゲームサーバーの割り当てにその値を利用したり、オートスケールのしきい値として利用することができる機能です。
今後はこの機能を利用して独自のAllocator ServiceをAgones標準のものへ移行できないか検討していきます。

◆執筆：加藤 悠　
株式会社コロプラ 技術基盤本部 インフラストラクチャ部 第2グループ @katsew

【フェスティバトル公式サイト】
https://festibattle.jp/