Amazon Web Services ブログ

AWS Game-Server CD Pipeline で Game DevOps を容易に



Weaveworks の Anita Buehrle 氏によるゲスト投稿です。

ゲームパブリッシャーにとって最も悩ましいのは、可能な限り迅速にプレイヤーに新機能を提供する能力です。新機能を迅速かつ確実に提供しなければならないだけではなく、その提供は、コストを最適化しつつ、セキュリティを維持する方法で行われる必要があります。GitOps を使用した継続的インテグレーションおよび継続的デプロイ (CI/CD) パイプラインは、ゲームパブリッシャーがゲームを改善し、開発ライフサイクルを通じて新しい機能を提供するための効果的な方法です。この投稿では、GitOps のベストプラクティスと組み合わせた CD パイプラインを使用して、安全かつ費用対効果の高いスケーラブルな方法で、AWS の EKS クラスターにゲームバイナリとそのアセットを自動的に配布する方法を説明します。

CI/CD パイプラインアーキテクチャの概要

以下の図は、CI/CD パイプラインアーキテクチャとそのデータフローを示しています。GitOps を使用して、インフラストラクチャと、git のゲームのアプリケーション設定の両方を、信頼できる唯一のソースとして管理します。すべてが git に保持されているため、開発者は、クラスターに直接ログインすることなく、EKS で実行されているゲームサーバーの運用と更新のデプロイのためのプルリクエストを作成します。GitOps を使用すると、プロダクションクラスターの状態が、ソース管理下にある宣言的な設定と継続的に比較されます。

GitOps は、CI システムが新しくプッシュされたコードをテストして統合したことを前提としています。パイプラインの CI 部分は、Docker イメージを構築して Elastic Container Registry (ECR) にプッシュします。レジストリに新しく構築されたイメージを使用して、Flux CD がそこから引き継ぎます。Flux は、クラスターで実行され、ECR で新しいイメージを監視する GitOps オペレーターです。Flux は、新しいイメージが ECR にプッシュされたことに気付くと、対応するマニフェストファイルをチェックアウトし、それを更新してから再度 git にチェックインします。その後、新しいイメージがクラスターに自動的にデプロイされ、ゲームサーバーが更新され、git に保持されている信頼できるソースに対してその状態が維持されます。

 

ゲーム開発に継続的デプロイ (CD) を使用する理由

ゲームサーバーのデプロイを管理するために GitOps によって有効化された CD は、ゲーム開発者とゲーム運用チームの両方に次のような利点をもたらします。

開発者の生産性の向上 – ゲーム開発プロセスは刺激的です。開発者は、没入型で野心を駆り立てるエクスペリエンスを継続的に構築して、プレーヤーがプレイし続けるようにします。これには、開発者がゲームの更新と機能をより速く提供できるメカニズムが必要です。GitOps を使用すると、開発者は git などの使い慣れたツールを使用して、Kubernetes の内部を知らなくても、更新や新しいゲームの機能を管理できます。デプロイはプルリクエストによって管理されるため、ゲームをホストするプラットフォームの微妙な差異はすべて抽象化されます。たとえば、開発者は、ゲームが EKS と ECS のどちらにデプロイされているかを知る必要はありません。

合理化されたゲーム操作 – 他の種類のソフトウェアと同様に、ゲームプレーヤーは安定性と信頼性を期待しています。Git ワークフローを使用してクラスターを管理することにより、監査証跡が自動的に取得され、クラスターに対して誰がいつ何をしたのかがわかるため、ゲームサーバーホストの安定性が保証されます。GitOps は、一貫していて、かつ、標準化されているワークフローも定義し、ゲームサーバーに関係なく、DevOps チームがすべてのデプロイで使用できるようにします。最後に、ゲームサーバークラスターおよびその他のインフラストラクチャへのアクセスが制限されているため、セキュリティが大幅に向上します。GitOps モデルを使用すると、開発者はステージングシステムに変更をプッシュするために kubectl または AWS マネジメントコンソールを必要としません。代わりに、Git リポジトリの構造を介してデプロイ許可を管理できます。AWS CodeCommit が git プロバイダーとして選択されている場合、アクセス許可は AWS IAM で設定できます。

GitOps はゲームの DevOps にどのように役立ちますか?

バグのある新しいゲーム機能をデプロイしたばかりの新しい DevOps チームメンバーがいるとしましょう。あなたはその日の DevOps 担当者とします。変更が完全にロールアウトされる前に、kubediff は、アラートを起動して問題の原因となった git の変更を示します。

その小さなアドホック設定の変更により、問題が悪化することはありません。代わりに、専用ゲームサーバーのデプロイの一貫性と安定性はより良好で、チームが本番環境に継続的に変更を提供することが容易になります。

動作の詳細

Flux を使用した GitOps での継続的デプロイ (CD) の場合、ゲームサーバーとアセット Docker イメージのマニフェストファイルは、ゲームバイナリ生コードとは別の git リポジトリに保持する必要があります。

したがって、CD システムは以下で構成されます。

  • 専用ゲームサーバーをホストする EKS クラスター。
  • Flux CD、ゲームサーバー仕様、監視コンポーネントを含むテンプレート GitOps プロファイル。Flux は、クラスターの状態を維持するためにデプロイを管理する GitOps オペレーターです。監視コンポーネントはログを送信して、CloudWatch または ElasticSearch と同期します。運用上のメトリクスは、ネイティブの Kubernetes ダッシュボードと同様に Prometheus に送信されます。
  • ECR コンテナーレジストリ内のゲームバイナリとアセットを使用したアクセス可能な Docker イメージ。

Flux を使用してクラスターをセットアップし、eksctl を使用してプロファイルをセットアップするには:

最初に、eksctl ツールを使用して EKS クラスターをそれぞれのリージョンにデプロイします。以下に例を示します。

eksctl create cluster -f cluster.yaml

cluster.yaml をクラスター仕様の例として使用します。

次に、GitOps オペレーターが作成されたクラスターで Flux と Helm をセットアップできるようにします。
これは実験的な機能です。有効にするには、環境変数 EKSCTL_EXPERIMENTAL=true を設定します。

eksctl enable repo -r us-west-2
--git-url git@github.com:me/my-gs.git \
--git-branch my-gs-us-west-2 \
--git-email devops@example.com \
--cluster gs-us-west-2 \
--region us-west-2

enable repo コマンドは、—git-url によって設定されたリポジトリを一時ディレクトリに複製します。コマンドの実行には時間がかかるため、出力をスキャンすることをお勧めします。ログには、次のような情報が記録されています。

[ℹ] Flux will only operate properly once it has write-access to the Git repository [ℹ] please configure git@github.com:me/my-gs.git so that the following Flux SSH public key has write access to it ssh-rsa AAAAB3NzaC1yc2

ssh-rsa で始まる行をコピーし、リポジトリへの読み取り/書き込みアクセスを許可します。たとえば、GitHub ではデプロイキーとして追加します。これは、Settings > Deploy keys > Add deploy key で簡単に実行できます。Allow write access もオンにしてください。次回 Fit が Git から同期すると、クラスターの更新とアクティブなデプロイが開始されます。次に git pull を実行すると、Flux が既にそれらを git config リポジトリにコミットしていることがわかります。

3 番目に、オレゴン EKS クラスターでプロファイルを有効にします。
これは実験的な機能です。有効にするには、環境変数 EKSCTL_EXPERIMENTAL=true を設定します。
—get-url 値の me/my-gs.git を EKS クラスターの制御に使用する必要のある git リポジトリに置き換えます。

eksctl enable profile -r us-west-2 \
--git-url git@github.com:me/my-gs.git \
--git-branch my-gs-us-west-2 
--cluster gs-us-west-2 \
git@github.com:aws-samples/amazon-eks-profile-for-gameserver

このコマンドは、amazon-eks-profile-for-gameserver プロファイルを使用してクラスターをセットアップします。本番環境対応クラスターに必要なすべての設定ファイルは、提供した git リポジトリにあり、それらのコンポーネントはクラスターにデプロイされます。設定を変更すると、それらがクラスターに反映されます。

[ℹ] cloning repository "git@github.com:aws-samples/amazon-eks-profile-for-gameserver":master
[ℹ] processing template files in repository
[ℹ] writing new manifests to "/var/folders/n9/53xbvtmd7sjg1q1l55xmpg58n4mgng/T/my-gs/base"

ゲームサーバーを別のリージョンの別のクラスターにデプロイする

ゲームサーバーを別のクラスターまたはまったく新しいクラスターにデプロイする必要がある場合、別々の git ブランチを利用できます。

最初に、eksctl ツールを使用して、それぞれのリージョンにセカンダリ EKS クラスターをデプロイします。以下に例を示します。

eksctl create cluster -f cluster.yaml

次に、以下の eksctl コマンドは同じ git リポジトリを使用しますが、クラスターには異なる git ブランチを指定します。

eksctl enable repo -r eu-west-1 \
--git-url git@github.com:me/my-gs.git \
--git-branch my-gs-eu-west-1 \
--git-email devops@example.com \
--cluster gs-eu-west-1 \

このコマンドは、以前のプロファイルの実行の有効化と同様の結果を生成します。git ブランチが提供する柔軟性を説明します。クラスターはブランチごとに割り当てられ、特別なツールを必要とすることなく、標準の git pull リクエストとマージリクエストを使用して、段階的なクロスリージョンの変更をデプロイするために使用できます。

3 番目に、ダブリン EKS クラスターでプロファイルを有効にします。

eksctl enable profile -r us-west-1 \
--git-url git@github.com:me/my-gs.git \
--git-branch my-gs-eu-west-1 \
--cluster gs-eu-west-1 \
git@github.com:aws-samples/amazon-eks-profile-for-gameserver

これらのコマンドの出力は、オレゴン地域設定の出力に似ています。

ぜひお試しください

4 つの例を示して、Amazon EKS クラスターを構築し、大きなバイナリを含むコンテナ化されたゲームサーバーをデプロイするプロセスを説明しました。