を使用した Amazon GameLift ホスティングリソースの管理 AWS CloudFormation - Amazon GameLift

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

を使用した Amazon GameLift ホスティングリソースの管理 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 つのロケーションのスタック

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

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

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

次の図は、単一の AWS リージョンにリソースをデプロイするための 2 スタック構造を示しています。

Amazon GameLift リソースとサポート AWS サービスの 2 AWS CloudFormation スタックの図。

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

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

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

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

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

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

リージョン固有の AWS CloudFormation リソースとグローバルリソースを含むリソーススタックの図。
図は、リージョン AWS CloudFormation スタックがキューなどのグローバルリソースを共有する方法を示しています。

ビルドの更新

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 を保持することもできます。詳細については、「 リファレンスRetainResources」の「」を参照してください。 AWS CloudFormation API

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

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

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

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

図は、 AWS CloudFormation スタックを使用してゲームサーバーのビルドを更新する方法を示しています。

ロールバックの仕組み

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

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

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