『メルクストーリア – 癒術士と鐘の音色 –』における、リアルタイム通信を支えるKubernetes基盤（後編）

こんにちは、HappyElements 株式会社でインフラを担当しております、K.Hです。
前回に引き続き、『メルクストーリア – 癒術士と鐘の音色 –』のリアルタイム機能を支えるKubernetes基盤のご紹介です。

前回の記事にて、Agonesを採用すること、及びその実行基盤としてAmazon EKSを採用する事までをお話ししました。
今回は、Amazon EKSの運用について考慮したポイント等をお話していきます。

Amazon EKSの利用戦略

Amazon EKSによってKubernetes利用の大部分をAWSにおまかせすることができました。
ただし、まだ実際にアプリケーションを運用する上では考えるべきポイントが残っています。
メルクストーリアでは、以下のポイントを考える必要がありました。

• ワーカーノードの種類について。
• Kubernetesバージョンアップ手順について。

それぞれについて解説していきます。

Kubernetesの構成について

EKSのワーカーノードの種類を考えるにあたって、まずはKubernetes自体の構造をおさらいしたいと思います。

Kubernetesは大まかに言えば、以下のような構成のサーバー群で構成されています。
参考: Kubernetesのコンポーネント

左側の枠、ControlPlaneと呼ばれる部分はAmazon EKSを利用する場合はAWSが管理してくれますので、今回の場合は細かく考える必要はありません。
ControlPlaneにはKubernetes自体を管理するための情報を保存するストレージであったり、kubectlコマンドでの操作を受け付けるためのAPIサーバーが起動していたりします。

右側の枠、実際にこちらが利用するアプリケーションが動作するためのサーバーであるWorkerNodeをどのように動かそうか？というのが今回のポイントになります。

ワーカーノードの種類について

Amazon EKSを利用する場合、EC2かFargateのノードを選択することができます。^[1]

それぞれの特徴はざっと以下のようになります。

• EC2
  • ○　Fargateと同数のvCPU/Memoryを利用した場合、Fargateよりも低コストとなります。
  • ○　先にEC2を起動させて、スタンバイさせておくことができます。
  • ○　パブリックサブネット^[2]に配置することができます。
  • ✗　EC2の起動はFargateの起動よりは遅い傾向にあります。
  • ✗　EC2レベルでの運用/保守は引き続き必要になります。
• Fargate
  • ○　本当に必要な分量だけのvCPU/Memoryを要求することができます。
    • EC2に比べて確保するリソース量が下がる場合はより低コストとなる事があります。
  • ○　EC2に比べ、起動は高速である傾向にあります。
  • ○　ホストのメンテナンスについて、全てAWSにおまかせすることができます。
  • ✗　DaemonSetのようなコンテナを配置したり、ホストのファイルシステムへのアクセスは利用できません。
  • ✗　コンテナが起動するより先にFargateインスタンスを起動するような事はできません。
  • ✗　パブリックサブネットへ配置することはできません。^[3]

ワーカーノードの使い分けについて

EC2/Fargateそれぞれにメリットと制限があります。

ステートフルなサーバーを考える場合、狙ったサーバーに確実にリクエストを届ける必要があります。
そのため、パブリックサブネットに配置できるというポイントが非常に魅力的です。
また、ゲームサーバーは大きくリソースを消費することも考えられます。

逆に、Agonesのコントローラーであったり、KubernetesのClusterAutoscalerのような小さなコンテナである場合、
Fargateに対するリソース要求として、0.25 vCPU / 0.5GB Memoryのような下限値の設定であっても十分となります。

上記のような理由からメルクストーリアでは、

• ゲームサーバーアプリケーションはEC2ノードを利用する。
• コントローラーのようなPodはFargateを利用する。

というハイブリッド構成を取りました。
このようなハイブリッド構成を取ることで、EC2レベルでのメンテナンスが発生した際にもコントローラーPodのような自分たちで直接開発していないコンテナへの影響を考えることなくメンテナンス作業を計画することができます。

Kubernetesのバージョンアップについて

Amazon EKSではクラスタのバージョンアップをボタンひとつでトリガーすることもできるのですが、メルクストーリアではクラスタ全体をBlueGreenDeploymentの要領で切り替えることでこれを実現しています。

クラスタ全体の切り替えは、大まかに以下のような流れで実行しています。

• 新しいバージョンのクラスタを、同サイズで準備します。
• ロードバランサーのバックエンドを、旧クラスタから新クラスタに切り替えます。
  • マッチメイキング等、一部のリクエストはロードバランサーを経由しています。
  • ALBのTargetGroup切り替えによって実現しています。
• ロードバランサーを介さない、ゲームサーバーへのリクエストを新クラスタへと誘導するように切り替えます。
  • マッチメイキングのリザルトに接続先が入っており、この向き先が切り替わっているイメージです。
• 旧サーバーの接続を回収し、新サーバーへと誘導します。
  • サーバーから接続を切断し、ゲームクライアントが再び接続を試行することで新サーバーへの誘導を行っています。

クラスタの更新にマネージド機能を利用しない理由

今回、EKSの更新機能の利用を見送った背景としては、大きく以下のポイントがあります。

• ロールバックができないこと。
  • EKSに限らずではありますが、バージョンアップはできてもバージョンダウンができないというのはよくある話だと思います。新バージョンで万が一問題が浮上した際、この方式の場合は接続を切り戻すだけで即座にロールバックが可能です。
  • Kubernetesの本番運用は社内初であったことから、万が一の際にすぐさま切り戻す事ができるのは魅力でした。
• Agonesなどのソフトウェア更新を行いたいこと。
  • Kubernetesのバージョンアップ機能では、Kubernetesそれ自体のバージョンアップは行ってくれますが、当然その上で動作している周辺ソフトウェアの更新まではできません。
  • AgonesやClusterAutoscaler、その他OSSコンポーネント等のバージョンアップも考えた場合、一式組み合わせて動作確認済みのクラスタを事前に準備することができるのは魅力的でした。

まとめ

• EKSのワーカーノードとして、以下の戦略を取りました。
  • ゲームサーバーアプリケーションはEC2タイプを利用。
  • その他のアプリケーションはFargateを利用。
• Kubernetesのバージョンアップ方法はB/G方式での切り替えとしました。
  • ロールバックのしやすさ、アプリケーションの更新のしやすさを優先。

脚注

1. EKS Anywhereについては一旦無視するものとします。

2. https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_Scenario2.html

3. https://aws.amazon.com/jp/blogs/news/amazon-eks-on-aws-fargate-now-generally-available/