翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# を使用してAmazon GameLift Serversホスティングリソースを管理する CloudFormation
CloudFormation を使用して Amazon GameLift Serversリソースを管理できます。では CloudFormation、各リソースをモデル化するテンプレートを作成し、テンプレートを使用してリソースを作成します。リソースを更新するには、テンプレートを変更し、 CloudFormation を使用して更新を実装します。リソースは、スタックおよびスタックセットと呼ばれる論理グループに編成できます。
CloudFormation を使用してAmazon GameLift Serversホスティングリソースを維持すると、 AWS リソースのセットをより効率的に管理できます。バージョニングを使用して、テンプレートの経時的な変更を追跡し、複数のチームメンバーによる更新を調整できます。テンプレートを再利用することもできます。たとえば、複数のリージョンにゲームをデプロイする場合、同じテンプレートを使用して各リージョンに同一のリソースを作成できます。これらのテンプレートを使用して、同じリソースセットを別のパーティションにデプロイすることもできます。
詳細については CloudFormation、[AWS CloudFormation 「 ユーザーガイド](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/)」を参照してください。Amazon GameLift Servers リソースのテンプレート情報を表示するには、[Amazon GameLift Servers リソースタイプリファレンス](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_GameLift.html)を参照してください。
## ベストプラクティス
の使用に関する詳細なガイダンスについては CloudFormation、 *AWS CloudFormation ユーザーガイド*の[CloudFormation ベストプラクティス](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html)を参照してください。さらに、これらのベストプラクティスは Amazon GameLift Servers と特別な関連性があります。
+ ** CloudFormationによりリソースを一貫して管理する。**リソースの外部でリソースを変更する CloudFormation と、リソーステンプレートと同期しなくなります。
+ ** CloudFormation スタックとスタックセットを使用して、複数のリソースを効率的に管理します。**
+ スタックを使用して、接続されたリソースのグループを管理します。例えば、ビルド、ビルドを参照するフリート、フリートを参照するエイリアスを含むスタックがあるとします。テンプレートを更新してビルドを置き換える場合、 はビルドに接続されているフリートを CloudFormation 置き換えます。 CloudFormation その後、 は既存のエイリアスを更新して新しいフリートを参照します。詳細については、「*AWS CloudFormation ユーザーガイド*」の「[スタックの操作](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacks.html)」を参照してください。
+ 複数のリージョンまたは AWS アカウントに同一の CloudFormation スタックをデプロイする場合は、スタックセットを使用します。詳細については、「*AWS CloudFormation ユーザーガイド*」の「[スタックセットの操作](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)」を参照してください。
+ **スポットインスタンスを使用する場合は、オンデマンドフリートをバックアップとして含める。**リージョンごとに 2 つのフリート (スポットインスタンスを使用するフリートおよびオンデマンドインスタンスを使用するフリート) でテンプレートを設定することをお勧めします。
+ **複数のリージョンでリソースを管理している場合は、ロケーション固有のリソースとグローバルリソースを別々のスタックにグループ化します。**
+ **グローバルリソースは、そのリソースを使用するサービスの近くに配置します。**キューやマッチメーキング設定などのリソースは、特定のソースから大量のリクエストを受信する傾向があります。リソースをこれらのリクエストのソースの近くに配置することで、リクエストの移動時間を最短に抑え、全体的なパフォーマンスを向上させることができます。
+ **マッチメーキング設定は、その設定を使用するゲームセッションキューと同じリージョンに配置します。**
+ **スタック内のフリートごとに個別のエイリアスを作成します。**
## CloudFormation スタックの使用
Amazon GameLift Servers リソースの CloudFormation スタックを設定するときは、次の構造を使用することをお勧めします。最適なスタック構造は、ゲームを 1 つのロケーションにデプロイするか、複数のロケーションにデプロイするかによって異なります。
### 1 つのロケーションのスタック
1 つのロケーションで Amazon GameLift Servers リソースを管理するには、2 スタック構造をお勧めします。
+ **サポートスタック** - このスタックには、Amazon GameLift Servers リソースが依存するリソースが含まれます。少なくとも、このスタックには、カスタムゲームサーバーまたは Realtime スクリプトファイルを保存する S3 バケットが含まれる必要があります。スタックには、Amazon GameLift Serversビルドまたはスクリプトリソースの作成時に S3 バケットからファイルを取得するAmazon GameLift Serversアクセス許可を付与する IAM ロールも含める必要があります。このスタックには、DynamoDB テーブル、Amazon Redshift クラスター、Lambda 関数など、ゲームで使用される他の AWS リソースが含まれている場合もあります。
+ **Amazon GameLift Servers スタック **– このスタックには、ビルドまたはスクリプト、フリートのセット、エイリアス、ゲームセッションキューを含むすべてのAmazon GameLift Serversリソースが含まれます。 は、S3 バケットの場所に保存されたファイルを含むビルドまたはスクリプトリソース CloudFormation を作成し、ビルドまたはスクリプトを 1 つ以上のフリートリソースにデプロイします。フリートごとに対応するエイリアスが必要です。ゲームセッションキューはフリートエイリアスの一部またはすべてを参照します。マッチメーキングに FlexMatch を使用する場合、このスタックにはマッチメーキング設定とルールセットも含まれます。
次の図は、単一の AWS リージョンにリソースをデプロイするための 2 スタック構造を示しています。
![\[\]](http://docs.aws.amazon.com/ja_jp/gameliftservers/latest/developerguide/images/resources-cf_single_vsd.png)
### リージョンが複数の場合のスタック
ゲームを複数のリージョンにデプロイする場合、リソースがリージョン間でどのようにやり取りするかに留意してください。Amazon GameLift Servers フリートなどの一部のリソースは同じリージョン内の他のリソースのみを参照できます。Amazon GameLift Servers キューなどの他のリソースは、リージョンに依存しません。複数のリージョンで Amazon GameLift Servers リソースを管理するには、以下の構造をお勧めします。
+ **リージョン別サポートスタック** - これらのスタックには、Amazon GameLift Servers リソースが依存するリソースが含まれます。このスタックには、カスタムゲームサーバーまたは Realtime スクリプトファイルを保存する S3 バケットが含まれる必要があります。また、DynamoDB テーブル、Amazon Redshift クラスター、Lambda 関数など、ゲームの他の AWS リソースが含まれている場合もあります。これらのリソースの多くはリージョン固有であるため、リージョンごとに作成する必要があります。Amazon GameLift Servers には、これらのサポートリソースへのアクセスを許可する IAM ロールも必要です。IAM ロールはリージョンに依存しないため、必要なロールリソースは 1 つのみであり、任意のリージョンに配置され、他のすべてのサポートスタックで参照されます。
+ **リージョンAmazon GameLift Serversスタック** – このスタックには、ビルドまたはスクリプト、フリートのセット、エイリアスなど、ゲームがデプロイされている各リージョンに存在する必要があるAmazon GameLift Serversリソースが含まれています。 は、S3 バケットの場所にファイルを含むビルドまたはスクリプトリソース CloudFormation を作成し、ビルドまたはスクリプトを 1 つ以上のフリートリソースにデプロイします。フリートごとに対応するエイリアスが必要です。ゲームセッションキューはフリートエイリアスの一部またはすべてを参照します。このタイプのスタックを記述する 1 つのテンプレートを維持し、そのテンプレートを使用してリージョンごとに同一のリソースセットを作成できます。
+ **グローバル Amazon GameLift Servers スタック** - このスタックには、ゲームセッションキューとマッチメーキングリソースが含まれます。これらのリソースは任意のリージョンに配置でき、通常は同じリージョンに配置されます。キューは、任意のリージョンにあるフリートまたはエイリアスを参照できます。別のリージョンに追加のキューを配置するには、追加のグローバルスタックを作成します。
以下の図は、複数の AWS リージョンにリソースをデプロイするためのマルチスタック構造を示しています。最初の図では、1 つのゲームセッションキューを使用した構造を示しています。2 番目の図では、複数のゲームセッションキューを使用した構造を示しています。
![\[\]](http://docs.aws.amazon.com/ja_jp/gameliftservers/latest/developerguide/images/resources-cf_multi_vsd.png)
![\[\]](http://docs.aws.amazon.com/ja_jp/gameliftservers/latest/developerguide/images/resources-cf_multiqueue_vsd.png)
## ビルドの更新
Amazon GameLift Servers ビルドは不変です。ビルドとフリートの関係も同様です。その結果、ゲームビルドファイルの新しいセットを使用するようにホスティングリソースを更新する場合、以下の手順を実行する必要があります。
+ 新しいファイルのセットを使用して新しいビルドを作成する (置き換え)。
+ 新しいゲームビルドをデプロイするための新しいフリートのセットを作成する (置き換え)。
+ 新しいフリートを参照するようにエイリアスをリダイレクトする (中断することなく更新)。
詳細については、「*AWS CloudFormation ユーザーガイド*」の「[スタックリソースの更新動作](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-update-behaviors.html)」を参照してください。
### ビルドの更新を自動的にデプロイする
関連するビルド、フリート、エイリアスリソースを含むスタックを更新する場合、デフォルトの CloudFormation 動作では、これらのステップを順番に自動的に実行します。この更新をトリガーするには、まず新しいビルドファイルを新しい S3 の場所にアップロードします。次に、新しい S3 の場所を指すように CloudFormation ビルドテンプレートを変更します。新しい S3 の場所でスタックを更新すると、以下の CloudFormation シーケンスがトリガーされます。
1. S3 から新しいファイルを取得し、それらのファイルを検証して、新しい Amazon GameLift Servers ビルドを作成します。
1. フリートテンプレートでビルドの参照を更新すると、新しいフリートの作成がトリガーされます。
1. 新しいフリートがアクティブになったら、エイリアス内のフリートの参照を更新します。これにより、エイリアスの更新がトリガーされて、新しいフリートがターゲットになります。
1. 古いフリートを削除します。
1. 古いビルドを削除します。
ゲームセッションキューがフリートエイリアスを使用している場合、エイリアスが更新されるとすぐに、プレイヤーのトラフィックは新しいフリートに自動的に切り替えられます。ゲームセッションが終了すると、古いフリートは段階的にプレイヤーからドレインされます。自動スケーリングは、プレイヤーのトラフィックの変動に応じ、フリートの各セットに対してインスタンスを追加および削除するタスクを処理します。または、切り替え用にすばやく増やせることを前提に、最初に必要になるインスタンスの数を指定し、後で自動スケーリングを有効にすることもできます。
リソースを削除する代わりに で CloudFormation 保持することもできます。詳細については、*AWS CloudFormation API リファレンス*の「[RetainResources](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_DeleteStack.html)」を参照してください。
### ビルドの更新を手動でデプロイする
プレイヤーが新しいフリートをいつ稼働させるかをさらに細かく制御する場合は、いくつかのオプションがあります。Amazon GameLift Servers コンソールまたは CLI を使用して、エイリアスを手動で管理することを選択できます。または、ビルドテンプレートを更新してビルドとフリートを置き換える代わりに、2 番目のビルドとフリートのセットの定義をテンプレートに追加することを選択できます。テンプレートを更新すると、 は 2 番目のビルドリソースと対応するフリート CloudFormation を作成します。既存のリソースは置き換えられないため、それらのリソースは削除されず、エイリアスは元のフリートを参照したままになります。
このアプローチの主な利点は、柔軟性が得られることです。ビルドの新しいバージョン用に個別のリソースを作成し、新しいリソースをテストして、新しいフリートをプレイヤーに公開するタイミングを制御できます。考えられる欠点は、短期間にリージョンごとに 2 倍のリソースが必要になることです。
次の図は、このプロセスを示したものです。
![\[\]](http://docs.aws.amazon.com/ja_jp/gameliftservers/latest/developerguide/images/resources-cf_updating_vsd.png)
### ロールバックの仕組み
リソースの更新を実行するときに、いずれかのステップが正常に完了しない場合、 CloudFormation によってロールバックが自動的に開始されます。このプロセスでは、各ステップを順番に反転させて、新しく作成されたリソースを削除します。
ロールバックを手動でトリガーする必要がある場合は、ビルドテンプレートの S3 の場所キーを元の場所に戻し、スタックを更新します。Amazon GameLift Servers の新しいビルドとフリートが作成され、フリートがアクティブになると、エイリアスが新しいフリートに切り替わります。エイリアスを個別に管理している場合は、新しいフリートを参照するようにエイリアスを切り替える必要があります。
失敗またはスタックしたロールバックの処理方法の詳細については、「*AWS CloudFormation ユーザーガイド*」の「[更新のロールバックを続ける](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-continueupdaterollback.html)」を参照してください。