AWS CloudFormation を使用したリソースの管理

AWS CloudFormation を使用して、Amazon GameLift リソースへのアクセスを管理できます。AWS CloudFormation で、各リソースをモデル化するテンプレートを作成し、そのテンプレートを使用してリソースを作成します。リソースを更新するには、テンプレートに変更を加え、AWS CloudFormation を使用して更新を実装します。リソースは、スタックおよびスタックセットと呼ばれる論理グループに編成できます。

AWS CloudFormation を使用して Amazon GameLift ホスティングリソースを維持すると、AWS リソースセットをより効率的に管理できます。バージョン管理を使用して、テンプレートの経時的な変更を追跡し、複数のチームメンバーによる更新を調整できます。テンプレートを再利用することもできます。たとえば、複数のリージョンにゲームをデプロイする場合、同じテンプレートを使用して各リージョンに同一のリソースを作成できます。これらのテンプレートを使用して、同じリソースセットを別のパーティションにデプロイすることもできます。

AWS CloudFormation の詳細については、「AWS CloudFormation ユーザーガイド」を参照してください。Amazon GameLift リソースのテンプレート情報を表示するには、「Amazon GameLift リソースタイプリファレンス」を参照してください。

ベストプラクティス

AWS CloudFormation の使用に関する詳細なガイダンスについてはAWS CloudFormation ユーザーガイドの「AWS CloudFormation のベストプラクティス」を参照してください。さらに、これらのベストプラクティスは Amazon GameLift と特別な関連性があります。

• AWS CloudFormation によりリソースを一貫して管理する。AWS CloudFormation リソース以外のリソースを変更すると、リソースはリソーステンプレートと同期しなくなります。

• AWS CloudFormation スタックおよびスタックセットを使用して、複数のリソースを効率的に管理する。

  • スタックを使用して、接続されたリソースのグループを管理します。例えば、ビルド、ビルドを参照するフリート、フリートを参照するエイリアスを含むスタックがあるとします。テンプレートを更新してビルドを置き換えた場合、AWS CloudFormation はビルドに接続されているフリートを置き換えます。その後、AWS CloudFormation によって、新しいフリートを参照するように既存のエイリアスが更新されます。詳細については、AWS CloudFormation ユーザーガイドの「スタックの操作」を参照してください。

  • 複数のリージョンまたは AWS アカウントに同一のスタックをデプロイする場合は、AWS CloudFormation スタックセットを使用します。詳細については、AWS CloudFormationユーザーガイドの「スタックセットの操作」を参照してください。

• スポットインスタンスを使用する場合は、オンデマンドフリートをバックアップとして含める。リージョンごとに 2 つのフリート (スポットインスタンスを使用するフリートおよびオンデマンドインスタンスを使用するフリート) でテンプレートを設定することをお勧めします。

• 複数のリージョンでリソースを管理している場合は、ロケーション固有のリソースとグローバルリソースを別々のスタックにグループ化します。

• グローバルリソースは、そのリソースを使用するサービスの近くに配置します。キューやマッチメーキング設定などのリソースは、特定のソースから大量のリクエストを受信する傾向があります。リソースをこれらのリクエストのソースの近くに配置することで、リクエストの移動時間を最短に抑え、全体的なパフォーマンスを向上させることができます。

• マッチメーキング設定は、その設定を使用するゲームセッションキューと同じリージョンに配置する。

• スタック内のフリートごとに個別のエイリアスを作成する。

AWS CloudFormation スタックの使用

Amazon GameLift 関連リソースの AWS CloudFormation スタックを設定するときに以下の構造を使用することをお勧めします。最適なスタック構造は、ゲームを 1 つのロケーションにデプロイするか、複数のロケーションにデプロイするかによって異なります。

1 つのロケーションのスタック

1 つのロケーションで Amazon GameLift リソースを管理するには、2 スタック構造をお勧めします。

• サポートスタック – このスタックには、Amazon GameLift リソースが依存するリソースが含まれます。少なくとも、このスタックには、カスタムゲームサーバーまたは Realtime スクリプトファイルを保存する S3 バケットが含まれる必要があります。また、このスタックには、Amazon GameLift ビルドまたはスクリプトリソースを作成するときに S3 バケットからファイルを取得するためのアクセス許可を Amazon GameLift に付与する、IAM ロールも含まれる必要があります。このスタックには、DynamoDB テーブル、Amazon Redshift クラスター、Lambda 関数など、ゲームで使用される他の AWS リソースも含まれる場合があります。

• Amazon GameLift スタック - このスタックには、すべての Amazon GameLift リソース (ビルドまたはスクリプト、フリートのセット、エイリアス、ゲームセッションキューなど) が含まれます。AWS CloudFormation は、S3 バケットの場所に保存されているファイルを使用してビルドまたはスクリプトリソースを作成し、1 つまたは複数のフリートリソースにデプロイします。フリートごとに対応するエイリアスが必要です。ゲームセッションキューはフリートエイリアスの一部またはすべてを参照します。マッチメーキングに FlexMatch を使用する場合、このスタックにはマッチメーキング設定とルールセットも含まれます。

以下の図では、1 つの AWS リージョンにリソースをデプロイする 2 スタック構造を示しています。

リージョンが複数の場合のスタック

ゲームを複数のリージョンにデプロイする場合、リソースがリージョン間でどのようにやり取りするかに留意してください。Amazon GameLift フリートなどの一部のリソースは同じリージョン内の他のリソースのみをリファレンスできます。Amazon GameLift キューなどの他のリソースはリージョンに依存しません。複数のリージョンで Amazon GameLift リソースを管理するには、以下の構造をお勧めします。

• リージョン別サポートスタック - これらのスタックには、Amazon GameLift リソースが依存するリソースが含まれます。このスタックには、カスタムゲームサーバーまたは Realtime スクリプトファイルを保存する S3 バケットが含まれる必要があります。DynamoDB テーブル、Amazon Redshift クラスター、Lambda 関数など、ゲームで使用される他の AWS リソースも含まれる場合があります。これらのリソースの多くはリージョン固有であるため、リージョンごとに作成する必要があります。Amazon GameLift には、これらのサポートリソースへのアクセスを許可する IAM ロールも必要です。IAM ロールはリージョンに依存しないため、必要なロールリソースは 1 つのみであり、任意のリージョンに配置され、他のすべてのサポートスタックで参照されます。

• リージョン別 Amazon GameLift スタック - このスタックには、ゲームがデプロイされる各リージョンに存在する必要のある Amazon GameLift リソース (ビルドまたはスクリプト、フリートのセット、エイリアスなど) が含まれます。AWS CloudFormation は、S3 バケットの場所に保存されているファイルを使用してビルドまたはスクリプトリソースを作成し、1 つまたは複数のフリートリソースにデプロイします。フリートごとに対応するエイリアスが必要です。ゲームセッションキューはフリートエイリアスの一部またはすべてを参照します。このタイプのスタックを記述する 1 つのテンプレートを維持し、そのテンプレートを使用してリージョンごとに同一のリソースセットを作成できます。

• グローバル Amazon GameLift スタック – このスタックには、ゲームセッションキューとマッチメイキングリソースが含まれます。これらのリソースは任意のリージョンに配置でき、通常は同じリージョンに配置されます。キューは、任意のリージョンにあるフリートまたはエイリアスを参照できます。別のリージョンに追加のキューを配置するには、追加のグローバルスタックを作成します。

以下の図では、複数の AWS リージョンにリソースをデプロイするマルチスタック構造を示しています。最初の図では、1 つのゲームセッションキューを使用した構造を示しています。2 番目の図では、複数のゲームセッションキューを使用した構造を示しています。

ビルドの更新

Amazon GameLift ビルドはイミュータブルです。ビルドとフリートの関係も同様です。その結果、ゲームビルドファイルの新しいセットを使用するようにホスティングリソースを更新する場合、以下の手順を実行する必要があります。

• 新しいファイルのセットを使用して新しいビルドを作成する (置き換え)。

• 新しいゲームビルドをデプロイするための新しいフリートのセットを作成する (置き換え)。

• 新しいフリートを参照するようにエイリアスをリダイレクトする (中断することなく更新)。

詳細については、AWS CloudFormation ユーザーガイドの「スタックリソースの更新動作」を参照してください。

ビルドの更新を自動的にデプロイする

関連するビルド、フリート、エイリアスリソースを含むスタックを更新すると、デフォルトの AWS CloudFormation の動作では、以下のステップが順番に自動的に実行されます。この更新をトリガーするには、まず新しいビルドファイルを新しい S3 の場所にアップロードします。次に、新しい S3 の場所を参照するように AWS CloudFormation ビルドテンプレートを変更します。新しい S3 の場所でスタックを更新すると、以下の AWS CloudFormation シーケンスがトリガーされます。

1. S3 から新しいファイルを取得し、それらのファイルを検証して、新しい Amazon GameLift ビルドを作成します。

2. フリートテンプレートでビルドの参照を更新すると、新しいフリートの作成がトリガーされます。

3. 新しいフリートがアクティブになったら、エイリアス内のフリートの参照を更新します。これにより、エイリアスの更新がトリガーされて、新しいフリートがターゲットになります。

4. 古いフリートを削除します。

5. 古いビルドを削除します。

ゲームセッションキューがフリートエイリアスを使用している場合、エイリアスが更新されるとすぐに、プレイヤーのトラフィックは新しいフリートに自動的に切り替えられます。ゲームセッションが終了すると、古いフリートは段階的にプレイヤーからドレインされます。Auto Scaling は、プレイヤーのトラフィックの変動に応じてフリートの各セットに対してインスタンスを追加および削除するタスクを処理します。または、切り替え用にすばやく増やせることを前提に、最初に必要になるインスタンスの数を指定し、後で Auto Scaling を有効にすることもできます。

AWS CloudFormation で、リソースを削除する代わりに保持することもできます。詳細については、AWS CloudFormationAPI リファレンスの「RetainResources」を参照してください。

ビルドの更新を手動でデプロイする

プレイヤーが新しいフリートをいつ稼働させるかをさらに細かく制御する場合は、いくつかのオプションがあります。Amazon GameLift コンソールまたは CLI を使用して、エイリアスを手動で管理することを選択できます。または、ビルドテンプレートを更新してビルドとフリートを置き換える代わりに、2 番目のビルドとフリートのセットの定義をテンプレートに追加することを選択できます。テンプレートを更新すると、AWS CloudFormation によって 2 番目のビルドリソースと対応するフリートが作成されます。既存のリソースは置き換えられないため、それらのリソースは削除されず、エイリアスは元のフリートを参照したままになります。

このアプローチの主な利点は、柔軟性が得られることです。ビルドの新しいバージョン用に個別のリソースを作成し、新しいリソースをテストして、新しいフリートをプレイヤーに公開するタイミングを制御できます。考えられる欠点は、短期間にリージョンごとに 2 倍のリソースが必要になることです。

次の図は、このプロセスを示したものです。

ロールバックの仕組み

リソースの更新を実行するときに、いずれかのステップが正常に完了しない場合、AWS CloudFormation によってロールバックが自動的に開始されます。このプロセスでは、各ステップを順番に反転させて、新しく作成されたリソースを削除します。

ロールバックを手動でトリガーする必要がある場合は、ビルドテンプレートの S3 の場所キーを元の場所に戻し、スタックを更新します。Amazon GameLift の新しいビルドとフリートが作成され、フリートがアクティブになると、エイリアスが新しいフリートに切り替わります。エイリアスを個別に管理している場合は、新しいフリートを参照するようにエイリアスを切り替える必要があります。

失敗またはスタックしたロールバックの処理方法の詳細については、AWS CloudFormation ユーザーガイドの「更新のロールバックを続ける」を参照してください。