『メルクストーリア – 癒術士と鐘の音色 –』における、リアルタイム通信を支えるKubernetes基盤（前編）
こんにちは、HappyElements 株式会社でインフラを担当しております、K.Hです。
今年7周年を迎えた『メルクストーリア – 癒術士と鐘の音色 –』において、2021年3月にリアルタイム通信技術を用いた新機能をリリースしました！
今回は、この機能を支えているKubernetes基盤及びAgonesについてのご紹介です。
基盤選定のはじまり
メルクストーリアにリアルタイム通信を導入するにあたって、まずは社内の他タイトルの実装を参考にしました。
この頃実は既に、『あんさんぶるスターズ！！』にて、Redis Streamsをバックエンドとしたリアルタイム通信基盤の実装は開始していました。
参考: 僕の考えた最強のリアルタイム通信基盤(検討編)〜みんなでライブの場合〜
参考: 僕の考えた最強のリアルタイム通信基盤(実践編)〜みんなでライブの場合〜
この方法は構成が簡単でスケーラビリティもあり、パフォーマンスもなかなか良い、まさに『僕の考えた最強のリアルタイム通信基盤』なのですが、トレードオフとして以下のような課題も残ります。
- バックエンドとは別にRedisクラスタを起動しておく必要がある
- 単純にコストがかかります。
- Redisクラスタを通す分、パフォーマンスのペナルティがある
- そこまで遅いものではありませんが、当然ゼロではないです。
- 将来的にはリアルタイムレイドの実装が検討されており、フレーム単位でのデータ同期も予想される状況でした。
- Redisクラスタを通じてデータが同期されることを意識したサーバーの実装が必要になる
- リアルタイムレイドを考えた際、ゲームサーバーの複雑さを1つでも排除出来るのであれば排除したい状況でした。
上記のような課題とメルクストーリアの要件を鑑みた結果、今回はステートフルなサーバーによるリアルタイム通信基盤を構築することに決定しました。
ステートフルなサーバーに求められる要件
ステートフルなサーバーに求められる要件としては以下のようなものがありました。
- 狙ったサーバーに接続できること
- ステートフルなので当然ではありますが、同じルームに参加している他のプレイヤーと同じサーバーに狙って接続できる必要があります。
- スケーラブルであること
- 負荷や接続数に応じて、動的にサーバーの台数を変更できる必要があります。
- デプロイや開発が容易であること
- ステートフルであるからといって、簡単にデプロイできることを諦めたくはありませんでした。
これらを鑑みた結果、今回はKubernetes及びAgonesを利用することを決定しました。
なぜAgonesを採用したのか？
Agonesはそもそも、Kubernetes 上でのゲーム サーバー構築をサポートするオープンソース プロジェクトです。
上記のような要件に加え、典型的なゲームサーバーが備えておくべき機能を一通りサポートしてくれています。
参考: Agones ―― Kubernetes 上でのゲーム サーバー構築をサポートするオープンソース プロジェクトが始動
Kubernetes標準のオーケストレーションはHTTPサーバーのようなステートレスなサービスが念頭にありますが、Agonesを利用することでこれらの課題も解決することができます。
Kubernetesを利用するにあたって
Agonesを採用するとなると、次に課題となるのはKubernetesの実行基盤です。
メルクストーリアのサービスはAWS上に構築されており、本システムもAWS上での稼働が当初から想定されていました。
AWSでKubernetesを利用する場合、大きく分けて以下の2つのアプローチが考えられるかと思います。
- EC2上にセルフホスティングする。
- Amazon EKSを利用する。
今回は、迷うことなくAmazon EKSを採用しました。
なぜAmazon EKSを採用したのか？
大まかに、以下の3点が決め手になりました。
- KubernetesのマネージドサービスであるAmazon EKSを利用することで、Kubernetesコントロールプレーンの管理をしなくても良いこと。
- 面倒な構築やバージョンアップがボタンひとつで完了できます。
- 他のAWSサービスとの連携が取りやすいこと。
- KubernetesのServiceAccountとAWSのIAM Roleを紐付け、AWSサービスのAPIを呼び出すようなことが簡単にできます。
- これを利用することで、認証情報等をAWS SecretsManagerからロードしたり、ログをCloudWatch Logsへ転送したりといったワークロードが非常にシームレスに動作します。
- EKS-Optimized AMIが公式から提供されており、ワーカーノードの準備の手間も非常に少ないこと。
- 適切にメンテナンスされたイメージを選ぶだけで、バージョンアップやセキュリティパッチ等も簡単に適用できます。
まとめ
- リアルタイムサーバーを考えるに当たり、ステートレス or ステートフルの選択肢のうち、ステートフルを選びました。
- ○ コスト面で有利。
- ○ 性能面で有利。
- ✗ 複雑さもアップ。
- ステートフルなサーバーを構築するため、Kubernetes + Agonesを採用しました。
- ○ 複雑さの解消。
- ○ 全部入りであることの便利さ。
- ✗ Kubernetesの運用を考える必要が出てくる。
- Kubernetesの実行基盤として、AmazonのEKSを採用しました。
- ○ マネージドサービスを使って効率と品質をアップ。
- ○ Kubernetes自体のバージョンアップのお膳立てはAWSがやってくれる。
Discussion