翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ゲームホスティングソリューションをカスタマイズする
基本的なゲームホスティングソリューションを導入したら、次のトピックを使用してカスタマイズおよび強化し、プレイヤーエクスペリエンスの向上、コストの最適化、高度な機能の追加を行います。このセクションでは、主に影響を受けるコンポーネント別に整理されたさまざまなカスタマイズオプションについて説明します。ゲームの要件とプレイヤーベースに最適なカスタマイズを選択します。
**トピック**
+ [ゲームサーバー構築のカスタマイズ](customize-game-server-builds.md)
+ [Amazon GameLift Servers ホストされたゲームサーバーを他の AWS リソースに接続する](gamelift-sdk-server-resources.md)
+ [ゲームサーバーが Amazon GameLift Servers フリートデータにアクセスできるようにする](gamelift-sdk-server-fleetinfo.md)
+ [Amazon GameLift Servers に対する VPC ピアリングのセットアップ](vpc-peering.md)
+ [プレイヤーセッションとマッチメーキングのカスタマイズ](customize-player-sessions-matchmaking.md)
+ [プレイヤー ID を生成する](player-sessions-player-identifiers.md)
+ [FlexMatch マッチメーキングを Amazon GameLift Servers に追加する](gamelift-match-intro.md)
+ [ゲームセッション配置のカスタマイズ](customize-game-session-placement.md)
+ [ゲームセッションキューをカスタマイズする](queues-design.md)
+ [ゲームセッション配置に優先順位を付ける](queues-design-priority.md)
+ [スポットインスタンスのキューの設計](spot-tasks.md)
+ [ホスティングリソースのカスタマイズ](fleets-design.md)
+ [マネージドフリートのコンピューティングリソースを選択する](gamelift-compute.md)
+ [Amazon GameLift Servers コンテナフリートをカスタマイズする](containers-design-fleet.md)
+ [スポットフリートによるゲームホスティングコストの削減](fleets-spot.md)
+ [マネージド Amazon GameLift Servers でのゲームサーバーランタイム設定の最適化](fleets-multiprocess.md)
+ [Amazon GameLift Servers エージェントの操作](integration-dev-iteration-agent.md)
+ [エイリアスを使用して Amazon GameLift Servers フリートの指定を抽象化する](aliases-intro.md)
# ゲームサーバー構築のカスタマイズ
ゲームサーバービルドのカスタマイズは、他の AWS サービスを活用するなど、ゲームサーバーの機能を強化する機会を提供します。これらのカスタマイズにより、ゲームサーバー機能が基本的なホスティングを超えて拡張され、高度な機能と統合がサポートされます。
# Amazon GameLift Servers ホストされたゲームサーバーを他の AWS リソースに接続する
Amazon GameLift Servers フリートにデプロイするゲームサーバービルドを作成する場合、ゲームビルド内のアプリケーションが、所有する他の AWS リソースと直接かつセキュアに通信できるようにしたい場合があります。Amazon GameLift Servers はゲームホスティングフリートを管理するため、Amazon GameLift Servers にこれらのリソースとサービスへの制限付きアクセスを許可する必要があります。
シナリオの例には次のようなものがあります。
+ Amazon CloudWatch エージェントを使用し、マネージド EC2 フリートおよび Anywhere フリートからメトリックス、ログ、トレースを収集します。
+ Amazon CloudWatch Logs にインスタンス ログデータを送信します。
+ データファイルを格納する Amazon Simple Storage Service (Amazon S3) バケットを取得します。
+ Amazon DynamoDB データベースや他のデータストレージサービスに保存されているゲームデータ (ゲームモードやインベントリなど) を動的に読み取りおよび書き込みします。
+ Amazon Simple Queue Service (Amazon SQS) を使用し、シグナルをインスタンスに直接送信します。
+ Amazon Elastic Compute Cloud (Amazon EC2) にデプロイされ、実行しているカスタムリソースにアクセスします。
Amazon GameLift Servers は、アクセスを確立するための方法として以下をサポートしています。
+ [IAM ロールを使用して AWS リソースにアクセスする](#gamelift-sdk-server-resources-roles)
+ [VPC ピアリングを使用して AWS リソースにアクセスする](#gamelift-sdk-server-resources-vpc)
## IAM ロールを使用して AWS リソースにアクセスする
IAM ロールを使用してリソースにアクセスできるユーザーを指定し、そのアクセスに制限を設定します。信頼できる関係者はロールを「引き受ける」ことで、リソースとのやりとりを認可する一時的なセキュリティ認証情報を取得できます。関係者がリソースに関連する API リクエストを行う場合は、認証情報を含める必要があります。
IAM ロールで制御されるアクセスを設定するには、以下のタスクを実行します。
1. [IAM ロールを作成する](#gamelift-sdk-server-resources-roles-create)
1. [認証情報を取得するようにアプリケーションを変更する](#gamelift-sdk-server-resources-roles-apps)
1. [IAM ロールをフリートに関連付ける。](#gamelift-sdk-server-resources-roles-fleet)
### IAM ロールを作成する
このステップでは、 AWS リソースへのアクセスを制御する一連のアクセス許可と、ロールのアクセス許可を使用するAmazon GameLift Servers権限を付与する信頼ポリシーを持つ IAM ロールを作成します。
IAM ロールのセットアップ方法については「[Amazon GameLift Servers 用に IAM サービスロールをセットアップする](setting-up-role.md)」を参照してください。アクセス許可かポリシーを作成するときは、アプリケーションが連携する必要のある特定のサービス、リソース、アクションを選択します。ベストプラクティスとして、アクセス許可の範囲をできる限り制限してください。
ロールを作成した後、ロールの Amazon リソースネーム (ARN) をメモします。フリート作成時にはロール ARN が必要です。
### 認証情報を取得するようにアプリケーションを変更する
このステップでは、IAM ロールのセキュリティ認証情報を取得し、 AWS リソース を操作するときにそれらを使用するようにアプリケーションを設定します。以下の表を参照して、(1) アプリケーションのタイプ、(2) ゲームが Amazon GameLift Servers との通信に使用するサーバー SDK バージョンに基づいてアプリケーションを変更する方法を決定してください。
| | ゲームサーバーアプリケーション | その他のアプリケーション |
| --- | --- | --- |
| **サーバー SDK バージョン 5.x の使用** | ゲームサーバーコードからサーバー SDK メソッド `GetFleetRoleCredentials()` を呼び出します。 | アプリケーションにフリートインスタンス上の共有ファイルから認証情報を取得するコードを追加します。 |
| **バージョン 4 以前のサーバー SDK の使用** | ロール ARN `[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)`を使用して AWS Security Token Service (AWS STS) を呼び出します。 | ロール ARN `[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)`を使用して AWS Security Token Service (AWS STS) を呼び出します。 |
**注記**
コンテナフリートの場合、`FleetRoleArn`認証情報は各コンテナに挿入されます。アプリケーションは、デフォルトの AWS 認証情報プロバイダーを使用してこれらの認証情報にアクセスできます。を呼び出しても`GetFleetRoleCredentials()`、同じ認証情報が返されます。これらのフリートロールの認証情報は、コンテナ内でのみアクセスできます。
サーバー SDK 5.x と統合されたゲームの場合、この図は、デプロイされたゲームビルドのアプリケーションが IAM ロールの認証情報を取得する方法を示しています。
![\[ゲーム実行可能ファイルは GetFleetRoleCredentials() を呼び出します。他のファイルは、ローカルに保存された共有認証情報を使用します。\]](http://docs.aws.amazon.com/ja_jp/gameliftservers/latest/developerguide/images/instance-role-creds_vsd.png)
#### `GetFleetRoleCredentials()` (サーバー SDK 5.x) を呼び出す
Amazon GameLift Servers サーバー SDK 5.x とすでに統合されているゲームサーバーコードで、`GetFleetRoleCredentials` ([C\$1\$1](integration-server-sdk5-cpp-actions.md#integration-server-sdk5-cpp-getfleetrolecredentials)) ([C\$1](integration-server-sdk5-csharp-actions.md#integration-server-sdk5-csharp-getfleetrolecredentials)) ([Unreal](integration-server-sdk5-unreal-actions.md#integration-server-sdk5-unreal-getfleetrolecredentials)) ([Go](integration-server-sdk-go-actions.md#integration-server-sdk-go-getfleetrolecredentials)) を呼び出し、一時的な認証情報のセットを取得します。認証情報の有効期限が切れたら、`GetFleetRoleCredentials` をもう一度呼び出して認証情報を更新できます。
#### 共有の認証情報 (サーバー SDK 5.x) を使用する
サーバー SDK 5.x を使用するゲームサーバービルドでデプロイされる非サーバーアプリケーションの場合は、共有ファイルに保存されている認証情報を取得して使用するコードを追加します。Amazon GameLift Servers は各フリートインスタンスごとに認証情報プロファイルを生成します。認証情報は、インスタンス上のすべてのアプリケーションで使用できます。Amazon GameLift Servers は、一時的な認証情報を継続的に更新します。
フリート作成時に共有の認証情報ファイルを生成するようにフリートを設定する必要があります。
共有の認証情報ファイルを使用する必要がある各アプリケーションで、次のようにファイルの場所とプロファイル名を指定します。
Windows:
```
[credentials]
shared_credential_profile= "FleetRoleCredentials"
shared_credential_file= "C:\\Credentials\\credentials"
```
Linux:
```
[credentials]
shared_credential_profile= "FleetRoleCredentials"
shared_credential_file= "/local/credentials/credentials"
```
**例: Amazon GameLift Servers フリートインスタンスのメトリクスを収集するように CloudWatch エージェントをセットアップする**
Amazon CloudWatch エージェントを使用して Amazon GameLift Servers フリートからメトリクス、ログ、トレースを収集する場合は、このメソッドを使用して、エージェントがアカウントにデータを送信することを許可します。このシナリオでは、以下のステップを行います。
1. CloudWatch エージェント `config.json` ファイルを取得または書き込みます。
1. 前述のように、エージェント用の `common-config.toml` ファイルを更新して、認証情報ファイル名とプロファイル名を特定します。
1. ゲームサーバーのビルドインストールスクリプトを設定して、CloudWatch エージェントをインストールして開始します。
#### `AssumeRole()` (サーバー SDK 4) を使用する
アプリケーションにコードを追加して IAM ロールを引き受け、 AWS リソースを操作するための認証情報を取得します。サーバー SDK 4 以前の Amazon GameLift Servers フリートインスタンスで実行されるすべてのアプリケーションで IAM ロールを引き受けることができます。
アプリケーションコードでは、 AWS リソースにアクセスする前に、アプリケーションは AWS Security Token Service (AWS STS) `[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)` API オペレーションを呼び出し、ロール ARN を指定する必要があります。このオペレーションは、アプリケーションが AWS リソースにアクセスすることを許可する一時的な認証情報のセットを返します。詳細については、*IAM* [ユーザーガイドの「 AWS リソースでの一時的な認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html)の使用」を参照してください。
### IAM ロールをフリートに関連付ける。
IAM ロールを作成し、ゲームサーバービルドのアプリケーションを更新してアクセス認証情報を取得して使用したら、フリートをデプロイできます。新しいフリートを設定するときは、次のパラメータを設定します。
コンテナフリートの場合:
+ [FleetRoleArn](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_CreateContainerFleet.html#gameliftservers-CreateContainerFleet-request-FleetRoleArn) – このパラメータを IAM ロールの ARN に設定します。
他のフリートタイプの場合:
+ [InstanceRoleArn](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_FleetAttributes.html#gamelift-Type-FleetAttributes-InstanceRoleArn) – このパラメータを IAM ロールの ARN に設定します。
+ [InstanceRoleCredentialsProvider](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_FleetAttributes.html#gamelift-Type-FleetAttributes-InstanceRoleCredentialsProvider) – Amazon GameLift Servers に各フリートインスタンスの共有の認証情報ファイルを生成するように求めるには、このパラメータを `SHARED_CREDENTIAL_FILE` に設定します。
これらの値は、フリートを作成するときに設定する必要があります。これらは後で更新できません。
## VPC ピアリングを使用して AWS リソースにアクセスする
Amazon Virtual Private Cloud (Amazon VPC) ピアリングを使用して、Amazon GameLift Serversインスタンスで実行されているアプリケーションと別の AWS リソース間で通信できます。VPC は、 を通じて管理される一連のリソースを含む、ユーザーが定義する仮想プライベートネットワークです AWS アカウント。Amazon GameLift Servers フリートごとに専用の VPC があります。VPC ピアリングを使用すると、フリートと他の AWS リソースの VPC 間の直接ネットワーク接続を確立できます。
Amazon GameLift Servers は、ゲームサーバー用の VPC ピアリング接続を設定するプロセスを合理化します。ピアリングリクエストを処理し、ルートテーブルを更新し、必要に応じて接続を設定します。ゲームサーバーの VPC ピア接続を設定する方法の手順については、「[Amazon GameLift Servers に対する VPC ピアリングのセットアップ](vpc-peering.md)」を参照してください。
**注記**
VPC ピアリングはコンテナフリートではサポートされていません。
# ゲームサーバーが Amazon GameLift Servers フリートデータにアクセスできるようにする
カスタムゲームビルドまたは Amazon GameLift Servers Realtime スクリプトが、Amazon GameLift Servers フリートに関する情報を必要とする場合があります。例えば、ゲーム構築またはスクリプトに次のコードが含まれる場合があります。
+ フリートデータに基づいてアクティビティをモニタリングします。
+ メトリクスをロールアップして、フリートデータでアクティビティを追跡します。(多くのゲームでは、このデータを LiveOps アクティビティに使っています。)
+ マッチメーキング、追加のキャパシティスケーリング、テストなど、カスタムゲームサービスに関連するデータを提供します。
フリート情報は、次の場所の各インスタンスで JSON ファイルとして利用できます。
+ Windows: `C:\GameMetadata\gamelift-metadata.json`
+ Linux: `/local/gamemetadata/gamelift-metadata.json`
`gamelift-metadata.json` ファイルには、フリー[Amazon GameLift Serversトリソースの属性](https://docs.aws.amazon.com/gamelift/latest/apireference/API_FleetAttributes.html)が含まれます。
JSON ファイルの例:
```
{
"buildArn":"arn:aws:gamelift:us-west-2:123456789012:build/build-1111aaaa-22bb-33cc-44dd-5555eeee66ff",
"buildId":"build-1111aaaa-22bb-33cc-44dd-5555eeee66ff",
"fleetArn":"arn:aws:gamelift:us-west-2:123456789012:fleet/fleet-2222bbbb-33cc-44dd-55ee-6666ffff77aa",
"fleetDescription":"Test fleet for Really Fun Game v0.8",
"fleetId":"fleet-2222bbbb-33cc-44dd-55ee-6666ffff77aa",
"name":"ReallyFunGameTestFleet08",
"fleetType":"ON_DEMAND",
"instanceRoleArn":"arn:aws:iam::123456789012:role/S3AccessForGameLift",
"instanceType":"c5.large",
"serverLaunchPath":"/local/game/reallyfungame.exe"
}
```
# Amazon GameLift Servers に対する VPC ピアリングのセットアップ
このトピックでは、Amazon GameLift Servers ホストゲームサーバーと他の Amazon GameLift Servers 以外のリソースとの VPC ピアリング接続を設定する方法に関するガイダンスを提供します。Amazon Virtual Private Cloud (VPC) ピアリング接続を使用して、ゲームサーバーがウェブサービスやリポジトリなどの他の AWS リソースと直接およびプライベートに通信できるようにします。で実行 AWS され、アクセスできる AWS アカウントによって管理されている任意のリソースと VPC ピア接続を確立できます。
**注記**
VPC ピアリング接続は高度な機能です。ゲームサーバーが他の AWS リソースと直接およびプライベートに通信できるようにする推奨オプションについては、「」を参照してください[Amazon GameLift Servers ホストされたゲームサーバーを他の AWS リソースに接続する](gamelift-sdk-server-resources.md)。
Amazon VPC と VPC ピアリングにすでに精通している場合は、Amazon GameLift Servers ゲームサーバーとのピア接続の設定は多少異なっているのがわかります。ゲームサーバーを含む VPC にアクセスすることはできません (これは Amazon GameLift Servers サービスによってコントロールされます)。そのため、VPC ピアリングを直接リクエストすることはできません。代わりに、最初に Amazon GameLift Servers サービスへのピア接続リクエストを受け入れるために、Amazon GameLift Servers 以外のリソースで VPC を事前承認します。次に、Amazon GameLift Servers をトリガーして、先ほど認可した VPC ピアリング接続をリクエストします。Amazon GameLift Servers はピア接続の作成、ルートテーブルの設定、接続の設定のタスクを処理します。
## 既存のフリート用に VPC ピアリング接続を設定するには
1.
**AWS アカウント ID (複数可) と認証情報を取得します。**
次の AWS アカウントの ID とサインイン認証情報が必要です。 AWS にサインイン[AWS マネジメントコンソール](https://console.aws.amazon.com/)してアカウント設定を表示することで、アカウント IDs を見つけることができます。認証情報を取得するには、IAM コンソールに移動します。
+ AWS Amazon GameLift Servers ゲームサーバーの管理に使用する アカウント。
+ AWS 以外のAmazon GameLift Servers リソースの管理に使用する アカウント。
同じアカウントを Amazon GameLift Servers リソースと Amazon GameLift Servers 以外のリソースに使用している場合は、そのアカウントのみの ID と認証情報が必要です。
1.
**各 VPC の識別子を取得します。**
ピア接続される 2 つの VPC について以下の情報を取得します。
+ Amazon GameLift Servers ゲームサーバー用の VPC - ユーザーの Amazon GameLift Servers フリート ID。ゲームサーバーは、EC2 インスタンスのフリート上の Amazon GameLift Servers にデプロイされます。フリートは、Amazon GameLift Servers サービスによって管理される専用の VPC に自動的に配置されます。VPC への直接アクセスは許可されないため、VPC はフリート ID によって識別されます。
+ Amazon GameLift Servers AWS リソース以外の VPC – で実行 AWS され、アクセスできる AWS アカウントによって管理されている任意のリソースと VPC ピア接続を確立できます。これらのリソース用の VPC をまだ作成していない場合は、「[Amazon VPC の開始方法](https://docs.aws.amazon.com/vpc/latest/userguide/getting-started-ipv4.html)」を参照してください。VPC を作成したら、Amazon VPC の [AWS マネジメントコンソール](https://console.aws.amazon.com/) にサインインして VPC を一覧表示することで VPC ID を確認できます。
**注記**
ピア接続を設定するときは、両方の VPC が同じリージョンに存在する必要があります。Amazon GameLift Servers フリートゲームサーバー用の VPC はフリートと同じリージョンにあります。
1.
**VPC ピアリング接続を認可します。**
このステップでは、Amazon GameLift Servers への今後のリクエストを事前認可して、ゲームサーバーを含む VPC を、Amazon GameLift Servers 以外のリソース用の VPC にピア接続します。このアクションにより、VPC のセキュリティグループが更新されます。
VPC ピア接続を承認するには、サービス API [ CreateVpcPeeringAuthorization()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_CreateVpcPeeringAuthorization.html) を呼び出すか AWS 、CLI コマンド を使用します`create-vpc-peering-authorization`。Amazon GameLift Servers 以外のリソースを管理するアカウントを使用してこの呼び出しを行います。以下の情報を識別します。
+ ピア VPC ID - Amazon GameLift Servers 以外のリソース用の VPC の ID。
+ Amazon GameLift Servers AWS アカウント ID – Amazon GameLift Serversフリートの管理に使用するアカウントです。
VPC ピアリング接続を承認した後は、取り消されない限り、24 時間有効です。以下の操作を使用して､VPC ピアリング接続承認を管理できます。
+ [DescribeVpcPeeringAuthorizations()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeVpcPeeringAuthorizations.html) (AWS CLI `describe-vpc-peering-authorizations`)。
+ [DeleteVpcPeeringAuthorization()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DeleteVpcPeeringAuthorization.html) (AWS CLI `delete-vpc-peering-authorization`)。
1.
**ピア接続をリクエストします。**
有効な認可があれば、Amazon GameLift Servers にピア接続の確立をリクエストできます。
VPC ピア接続をリクエストするには、サービス API [CreateVpcPeeringConnection()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_CreateVpcPeeringConnection.html) AWS を呼び出すか、CLI コマンド を使用します`create-vpc-peering-connection`。Amazon GameLift Servers ゲームサーバーを管理するアカウントを使用してこの呼び出しを行います。以下の情報を使用して、ピア接続する 2 つの VPC を指定します。
+ ピア VPC ID と AWS アカウント ID – これは、 Amazon GameLift Servers以外のリソースの VPC と、それらの管理に使用するアカウントです。VPC ID は有効なピア接続認可の ID と一致する必要があります。
+ フリート ID - Amazon GameLift Servers ゲームサーバー用の VPC を識別します。
1.
**ピア接続のステータスを追跡します。**
VPC ピアリング接続のリクエストは、非同期操作です。ピア接続リクエストのステータスを追跡し、成功または失敗のケースを処理するには、次のいずれかのオプションを使用します。
+ `DescribeVpcPeeringConnections()` を使用して継続的にポーリングします。この操作では、リクエストのステータスを含む VPC ピアリング接続レコードが取得されます。ピア接続が正常に作成された場合、接続レコードには、VPC に割り当てられたプライベート IP アドレスの CIDR ブロックも含まれます。
+ 成功イベントと失敗イベントを含む [DescribeFleetEvents()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeFleetEvents.html) の VPC ピアリング接続に関連付けられたフリートイベントを処理します。
ピア接続が確立されると、以下のオペレーションを使用してその接続を管理できます。
+ [DescribeVpcPeeringConnections()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeVpcPeeringConnections.html) (AWS CLI `describe-vpc-peering-connections`)。
+ [DeleteVpcPeeringConnection()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DeleteVpcPeeringConnection.html) (AWS CLI `delete-vpc-peering-connection`)。
## 新しいフリートとの VPC ピアリング接続を設定するには
新しい Amazon GameLift Servers フリートを作成し、VPC ピアリング接続を同時にリクエストできます。
1.
**AWS アカウント ID (複数可) と認証情報を取得します。**
次の 2 つの AWS アカウントの ID とサインイン認証情報が必要です。 AWS にサインイン[AWS マネジメントコンソール](https://console.aws.amazon.com/)し、アカウント設定を表示することで、アカウント IDs を見つけることができます。認証情報を取得するには、IAM コンソールに移動します。
+ AWS Amazon GameLift Servers ゲームサーバーの管理に使用する アカウント。
+ AWS 以外のAmazon GameLift Servers リソースの管理に使用する アカウント。
同じアカウントを Amazon GameLift Servers リソースと Amazon GameLift Servers 以外のリソースに使用している場合は、そのアカウントのみの ID と認証情報が必要です。
1.
**Amazon GameLift Servers AWS リソース以外の VPC ID を取得します。**
これらのリソースの VPC をまだ作成していない場合は、ここで作成してください (「[Amazon VPC の開始方法](https://docs.aws.amazon.com/vpc/latest/userguide/getting-started-ipv4.html)」を参照)。新しいフリートを作成する予定の同じリージョンに新しい VPC を作成してください。以外のAmazon GameLift Serversリソースが で使用するものとは異なる AWS アカウントまたはユーザー/ユーザーグループで管理されている場合はAmazon GameLift Servers、次のステップで認可をリクエストするときに、これらのアカウント認証情報を使用する必要があります。
VPC を作成したら、VPC を表示して Amazon VPC コンソールで VPC ID を見つけることができます。
1.
**Amazon GameLift Servers 以外のリソースとの VPC ピアリング接続を承認します。**
Amazon GameLift Servers によって新しいフリートおよび対応する VPC が作成されるとき、Amazon GameLift Servers 以外のリソース用の VPC にピア接続するためのリクエストも送信されます。そのリクエストを事前承認する必要があります。このステップにより、VPC のセキュリティグループが更新されます。
以外のAmazon GameLift Serversリソースを管理するアカウント認証情報を使用して、サービス API [ CreateVpcPeeringAuthorization()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_CreateVpcPeeringAuthorization.html) AWS を呼び出すか、CLI コマンド を使用します`create-vpc-peering-authorization`。以下の情報を識別します。
+ ピア VPC ID - Amazon GameLift Servers 以外のリソース用の VPC の ID。
+ Amazon GameLift Servers AWS アカウント ID – Amazon GameLift Serversフリートの管理に使用するアカウントの ID。
VPC ピアリング接続を承認した後は、取り消されない限り、24 時間有効です。以下の操作を使用して､VPC ピアリング接続承認を管理できます。
+ [DescribeVpcPeeringAuthorizations()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeVpcPeeringAuthorizations.html) (AWS CLI `describe-vpc-peering-authorizations`)。
+ [DeleteVpcPeeringAuthorization()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DeleteVpcPeeringAuthorization.html) (AWS CLI `delete-vpc-peering-authorization`)。
1. [AWS CLI を使用して新しいフリートを作成する手順に従います](fleets-creating.md)。以下の追加のパラメータを含めます。
+ *peer-vpc-aws-account-id* - Amazon GameLift Servers 以外のリソース用の VPC を管理するために使用するアカウントの ID。
+ *peer-vpc-id* – Amazon GameLift Servers 以外のアカウント用の VPC のID。
VPC ピアリング接続パラメータを設定した [create-fleet](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-fleet.html) の呼び出しが成功すると、新しいフリートと新しい VPC ピアリング接続リクエストの両方が生成されます。フリートのステータスは **New** に設定され、フリートのアクティブ化プロセスが開始されます。ピア接続リクエストのステータスは **initiating-request** に設定されます。[describe-vpc-peering-connections](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-vpc-peering-connections.html) を呼び出して、ピアリングリクエストの成否を追跡できます。
新しいフリートと VPC ピアリング接続の両方をリクエストすると、両方のアクションが成功するか失敗します。フリートの作成プロセス中にエラーが発生すると、VPC ピアリング接続は確立されません。同様に、VPC ピアリング接続が何らかの理由で失敗した場合も、新しいフリートのステータスは [**アクティブ化中**] から [**アクティブ**] に移行しません。
**注記**
新しい VPC ピアリング接続は、フリートがアクティブになる準備が整うまで完了しません。これは、その接続が利用可能になっておらず、ゲームサーバービルドのインストールプロセス中に使用できないことを意味します。
以下の例では、新しいフリートと、事前に確立された VPC と新しいフリートの VPC 間のピア接続の両方を作成します。事前に確立された VPC は、非Amazon GameLift Servers AWS アカウント ID と VPC ID の組み合わせによって一意に識別されます。
```
$ AWS gamelift create-fleet
--name "My_Fleet_1"
--description "The sample test fleet"
--ec2-instance-type "c5.large"
--fleet-type "ON_DEMAND"
--build-id "build-1111aaaa-22bb-33cc-44dd-5555eeee66ff"
--runtime-configuration "GameSessionActivationTimeoutSeconds=300,
MaxConcurrentGameSessionActivations=2,
ServerProcesses=[{LaunchPath=C:\game\Bin64.dedicated\MultiplayerSampleProjectLauncher_Server.exe,
Parameters=+sv_port 33435 +start_lobby,
ConcurrentExecutions=10}]"
--new-game-session-protection-policy "FullProtection"
--resource-creation-limit-policy "NewGameSessionsPerCreator=3,
PolicyPeriodInMinutes=15"
--ec2-inbound-permissions "FromPort=33435,ToPort=33435,IpRange=0.0.0.0/0,Protocol=UDP"
"FromPort=33235,ToPort=33235,IpRange=0.0.0.0/0,Protocol=UDP"
--metric-groups "EMEAfleets"
--peer-vpc-aws-account-id "111122223333"
--peer-vpc-id "vpc-a11a11a"
```
*コピー可能バージョン:*
```
AWS gamelift create-fleet --name "My_Fleet_1" --description "The sample test fleet" --fleet-type "ON_DEMAND" --metric-groups "EMEAfleets" --build-id "build-1111aaaa-22bb-33cc-44dd-5555eeee66ff" --ec2-instance-type "c5.large" --runtime-configuration "GameSessionActivationTimeoutSeconds=300,MaxConcurrentGameSessionActivations=2,ServerProcesses=[{LaunchPath=C:\game\Bin64.dedicated\MultiplayerSampleProjectLauncher_Server.exe,Parameters=+sv_port 33435 +start_lobby,ConcurrentExecutions=10}]" --new-game-session-protection-policy "FullProtection" --resource-creation-limit-policy "NewGameSessionsPerCreator=3,PolicyPeriodInMinutes=15" --ec2-inbound-permissions "FromPort=33435,ToPort=33435,IpRange=0.0.0.0/0,Protocol=UDP" "FromPort=33235,ToPort=33235,IpRange=0.0.0.0/0,Protocol=UDP" --peer-vpc-aws-account-id "111122223333" --peer-vpc-id "vpc-a11a11a"
```
## VPC ピアリング接続に関する問題のトラブルシューティング
Amazon GameLift Servers ゲームサーバーの VPC ピアリング接続の確立に問題がある場合は、以下の一般的な根本原因を検討してください。
+ リクエストされた接続の認可が見つからなかった。
+ Amazon GameLift Servers 以外の VPC の VPC 認可のステータスを確認します。存在しないか、有効期限が切れている可能性があります。
+ ピア接続しようとしている 2 つの VPC のリージョンを確認します。それらが同じリージョンにない場合は、ピア接続できません。
+ 2 つの VPC の CIDR ブロック (「[無効な VPC ピアリング接続設定](https://docs.aws.amazon.com/vpc/latest/peering/invalid-peering-configurations.html#overlapping-cidr)」を参照) が重複している。ピア接続された VPC に割り当てられた IPv4 CIDR ブロックは､重複することはできません。Amazon GameLift Servers フリートの VPC の CIDR ブロックは自動的に割り当てられ、変更できません。そのため、Amazon GameLift Servers 以外のリソース用の VPC の CIDR ブロックを変更する必要があります。この問題を解決するには。
+ `DescribeVpcPeeringConnections()` を呼び出して、Amazon GameLift Servers フリートのこの CIDR ブロックを検索します。
+ Amazon VPC コンソールに移動し、Amazon GameLift Servers 以外のリソース用の VPC を見つけて、それらが重複しないように CIDR ブロックを変更します。
+ 新しいフリートがアクティブにならなかった (新しいフリートとの VPC ピアリング接続のリクエスト時)。新しいフリートが **[アクティブ]** ステータスに移行しなかった場合、ピア接続する VPC がないため、ピア接続は成功しません。
# プレイヤーセッションとマッチメーキングのカスタマイズ
プレイヤーセッションとマッチメーキングのカスタマイズにより、バランスの取れた魅力的なマルチプレイヤーエクスペリエンスを提供するのに役立つ微妙なマッチメーキングシステムなど、高度なプレイヤー管理ワークフローを開発できます。
# プレイヤー ID を生成する
Amazon GameLift Servers はプレイヤーセッションを使用して、ゲームセッションに接続されたプレイヤーを表します。Amazon GameLift Servers は、プレイヤーが Amazon GameLift Servers と統合されたゲームクライアントを使用してゲームセッションに接続するたびにプレイヤーセッションを作成します。プレイヤーがゲームを終了すると、プレイヤーセッションは終了します。Amazon GameLift Servers はプレイヤーセッションを再利用しません。
**重要**
FlexMatch マッチメーキングを使用する場合、既存のアクティブなマッチメーキングリクエストにすでに含まれているプレイヤー ID を含む新しいマッチメーキングリクエストを作成した場合、既存のリクエストは自動的にキャンセルされます。ただし、キャンセルされたリクエストには `MatchmakingCancelled` イベントは送信されません。既存のマッチメーキングリクエストのステータスをモニタリングするには、[DescribeMatchmaking](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeMatchmaking.html) を使用して、頻度の低い間隔 (30～60 秒) でリクエストステータスをポーリングします。キャンセルされたリクエストには、`CANCELLED` のステータスと理由「`Cancelled due to duplicate player`」が表示されます。
以下のサンプルコードでは、一意のプレイヤー ID をランダムに生成します。
```
bool includeBrackets = false;
bool includeDashes = true;
string playerId = AZ::Uuid::CreateRandom().ToString(includeBrackets, includeDashes);
```
プレイヤーセッションの詳細については、「[Amazon GameLift Servers コンソールでのゲームセッションとプレイヤーセッション](gamelift-console-game-player-sessions-metrics.md)」を参照してください。
# FlexMatch マッチメーキングを Amazon GameLift Servers に追加する
Amazon GameLift Servers FlexMatch を使用して、Amazon GameLift Servers でホストされているゲームにプレイヤーマッチメーキング機能を追加します。FlexMatch は、カスタムゲームサーバーまたは Amazon GameLift Servers Realtime のいずれでも使用できます。
FlexMatch では、マッチメーキングサービスとカスタマイズ可能なルールエンジンをペアリングします。ゲームに適したプレイヤー属性とゲームモードに基づいてプレイヤーを一緒にマッチングする方法を設計します。FlexMatch は、ゲームを探しているプレイヤーを評価し、1 つ以上のチームとマッチングを行い、マッチングをホストするゲームセッションを開始するための作業を管理します。
フル FlexMatch サービスを使用するには、ホスティングリソースをキューで設定する必要があります。Amazon GameLift Servers はキューを使用して、複数のリージョンとコンピューティングタイプのゲームに最適なホスティング場所を見つけます。特に、Amazon GameLift Servers キューはゲームクライアントから提供されるレイテンシーデータを利用して、プレイヤーがプレイ時に可能な限り低いレイテンシーで済むように、ゲームセッションの配置場所を決定します。
FlexMatch に関する詳細、特にマッチメーキングをゲームに統合するための詳細なヘルプについては、「[Amazon GameLift Servers FlexMatch デベロッパーガイド](https://docs.aws.amazon.com/gamelift/latest/flexmatchguide/)」の各トピックを参照してください。
+ [Amazon GameLift ServersFlexMatchの仕組み](https://docs.aws.amazon.com/gamelift/latest/flexmatchguide/match-intro.html)
+ [FlexMatch 統合ステップ](https://docs.aws.amazon.com/gamelift/latest/flexmatchguide/match-tasks.html)
# ゲームセッション配置のカスタマイズ
ゲームセッション配置のカスタマイズにより、配置システムをファインチューニングして、プレイヤーベースに可能な限り最高のゲームプレイエクスペリエンスを提供することができます。プレイヤーの互換性と設定、コスト効率、地理的分散、サービスの中断に対する耐障害性などの運用上の考慮事項に合わせて配置を最適化できます。
# ゲームセッションキューをカスタマイズする
このトピックでは、ゲームセッションキューをカスタマイズして、ゲームセッションの配置に関する最善の決定を行う方法について説明します。ゲームセッションキューとその仕組みの詳細については、「[ゲームセッションの配置を設定する](queues-intro.md)」を参照してください。
以下の Amazon GameLift Servers 機能にはキューが必要です:
+ [FlexMatch でのマッチメーキング](https://docs.aws.amazon.com/gameliftservers/latest/flexmatchguide/match-tasks.html)
+ [スポットインスタンスのキューの設計](spot-tasks.md)
**Topics**
+ [キューのスコープを定義する](queues-design-scope.md)
+ [マルチロケーションキューを構築する](queues-design-multiregion.md)
+ [キューメトリクスの評価](queues-design-metrics.md)
# キューのスコープを定義する
ゲームのプレイヤー集団には、一緒にプレイしてはいけないプレイヤーグループが存在する可能性があります。たとえば、ゲームを 2 つの言語で公開する場合、各言語には独自のゲームサーバーが必要です。
プレイヤー集団のゲームセッション配置を設定するには、プレイヤーセグメントごとに個別のキューを作成します。各キューをスコープ設定して、プレイヤーを正しいゲームサーバーに配置します。キューのスコープ設定の一般的な方法には、次のようなものがあります。
+ **地理的なロケーション別。**複数の地理的エリアにゲームサーバーをデプロイする場合、プレイヤーのレイテンシーを削減するために、ロケーション別にプレイヤー用のキューを構築できます。
+ **ビルド/スクリプトのバリエーション別。**ゲームサーバーのバリエーションが複数ある場合は、同じゲームセッションでプレイできないプレイヤーグループをサポートしている可能性があります。例えば、ゲームサーバーのビルドまたはスクリプトは、異なる言語やデバイスタイプなどをサポートすることがあります。
+ **イベントタイプ別。**特別なキューを作成して、トーナメントやその他の特別なイベント参加者のゲームを管理できます。
## 複数のキューを設計する
ゲームとプレイヤーによっては、複数のゲームセッションキューを作成する必要がある場合があります。ゲームクライアントサービスが新規のゲームセッションをリクエストする際に、どのゲームセッションキューを使用するか指定されます。複数のキューを使用するかどうかを判断するには、以下を検討してください。
+ ゲームサーバーのバリエーション。ゲームサーバーのバリエーションごとに個別のキューを作成することができます。キュー内のすべてのフリートは、互換性のあるゲームサーバーをデプロイする必要があります。これは、キューを使用してゲームに参加するプレイヤーが、キュー内の任意のゲームサーバーでプレイできる必要があるためです。
+ 異なるプレイヤーグループ。Amazon GameLift Servers がプレイヤーグループに基づいてゲームセッションを配置する方法をカスタマイズできます。たとえば、特別なインスタンスタイプまたはランタイム設定を必要とする特定のゲームモードに合わせてキューをカスタマイズする必要がある場合があります。または、トーナメントやその他のイベントのプレースメントを管理するために特別なキューが必要な場合があります。
+ ゲームセッションのキューメトリクス。ゲームセッションの配置メトリクスの収集方法に基づいて、キューを設定できます。詳細については、「[キューの Amazon GameLift Servers メトリクス](monitoring-cloudwatch.md#gamelift-metrics-queue)」を参照してください。
# マルチロケーションキューを構築する
すべてのキューにマルチロケーション設計を推奨します。この設計により、プレイスメント速度とホスティングの耐障害性が向上します。プレイヤーレイテンシーデータを使用して、最小のレイテンシーでプレイヤーをゲームに参加させるには、マルチロケーション設計が必要です。スポットインスタンスフリートを使用するマルチロケーションキューを構築する場合は、「[スポットフリートによるゲームホスティングコストの削減](fleets-spot.md)」の手順に従ってください。
マルチロケーションキューを作成する 1 つの方法は、[マルチロケーションフリート](gamelift-regions.md#gamelift-regions-hosting)をキューに追加することです。こうすることで、キューは、任意のフリートのロケーションにゲームセッションを配置できます。冗長性を保つため、設定やホームロケーションが異なる他のフリートを追加することもできます。マルチロケーションのスポットインスタンスのフリートを使用している場合は、ベストプラクティスに従って、同じロケーションを含むオンデマンドインスタンスのフリートを含めてください。
次の例では、基本的なマルチロケーションキューの設計プロセスについて説明します。この例では、2 つのフリートを使用します。1 つはスポットインスタンスフリートで、もう 1 つはオンデマンドインスタンスフリートです。各フリートには、配置場所 AWS リージョン として `us-east-1`、、`us-east-2``ca-central-1`、および があります`us-west-2`。
**マルチロケーションフリートを含む基本的なマルチロケーションキューを作成するには**
1. キューを作成するロケーションを選択します。クライアントサービスをデプロイした場所の近くのロケーションにキューを配置することで、リクエストの待ち時間を最小限に抑えることができます。この例では、キューを `us-east-1` に構築します。
1. 新しいキューを作成し、キューの送信先としてマルチロケーションフリートを追加します。送信先の順序によって、Amazon GameLift Servers がゲームセッションを配置する方法が決まります。この例では、最初にスポットインスタンスフリートをリストし、オンデマンドインスタンスフリートを 2 番目にリストしています。
1. キューのゲームセッションのプレイスメント優先順位を定義します。この順序により、キューが利用可能なゲームサーバーを最初に検索するロケーションが決まります。この例では、デフォルトの優先順序を使用します。
1. ロケーションの順序を定義します。ロケーションの順序を定義しない場合、Amazon GameLift Servers はロケーションをアルファベット順に使用します。
![\[サンプルキューの場所と送信先順序を示すコンソールのスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/gameliftservers/latest/developerguide/images/queue-multi-location-1.png)
![\[サンプルキューの配置優先度とロケーションの順序を示すコンソールのスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/gameliftservers/latest/developerguide/images/queue-multi-location-2.png)
# キューメトリクスの評価
キューのパフォーマンスを評価するには、メトリクスを使用します。キューに関係するメトリクスは、[Amazon GameLift Servers コンソール](https://console.aws.amazon.com/gamelift) または Amazon CloudWatch で表示できます。キューメトリクスのリストと説明については、「[キューの Amazon GameLift Servers メトリクス](monitoring-cloudwatch.md#gamelift-metrics-queue)」を参照してください。
キューメトリクスは、以下に関する分析情報を提供します。
+ **キュー全体のパフォーマンス** – キューメトリックは、キューがプレイスメントリクエストにどの程度正常に応答したかを示します。これらのメトリクスは、プレイスメントが失敗するタイミングと理由を特定するのにも役立ちます。フリートを手動でスケールしたキューの場合、`AverageWaitTime` および `QueueDepth` メトリクスはキューの容量をいつ調整する必要があるか示す場合があります。
+ **FleetIQ アルゴリズムのパフォーマンス** - FleetIQ アルゴリズムを使用する配置リクエストの場合、メトリクスはアルゴリズムが理想的なゲームセッションの配置を見つける頻度を示します。プレイスメントでは、プレイヤーのレイテンシーが最も低いリソースや、コストが最も低いリソースを優先的に使用することができます。Amazon GameLift Servers が理想的なプレイスメントを発見できない一般的な理由を特定するエラーメトリクスもあります。メトリクスの詳細については、「[Amazon CloudWatch で Amazon GameLift Servers を監視する](monitoring-cloudwatch.md)」を参照してください。
+ **[ロケーション固有のプレイスメント]** – マルチロケーションキューの場合、メトリクスはロケーション別の正常なプレイスメントを示します。FleetIQ アルゴリズムを使用するキューの場合、このデータはプレイヤーのアクティビティの発生箇所に関する有益な分析情報を提供します。
FleetIQ アルゴリズムのパフォーマンスメトリクスを評価する場合は、以下のヒントを参考にしてください。
+ キューの理想的なプレイスメントを発見する比率を追跡するには、`PlacementsSucceeded` メトリクスと最小レイテンシーおよび最低料金に関する FleetIQ のメトリクスを併用します。
+ キューが理想的なプレイスメントを見つける比率を上げるには、以下のエラーメトリクスを確認してください。
+ `FirstChoiceOutOfCapacity` が高い場合は、キューのフリートに合わせて容量スケーリングを調整してください。
+ `FirstChoiceNotViable` エラーメトリクスが高い場合は、スポットインスタンスフリートを確認してください。特定のスポットインスタンスタイプの中断率が高すぎる場合、スポットフリートは「有効でない」とみなされます。この問題を解決するには、キューを変更して異なるインスタンスタイプのスポットインスタンスのフリートを使用します。ロケーションごとに異なるインスタンスタイプのスポットインスタンスフリートを含めることをお勧めします。
# ゲームセッション配置に優先順位を付ける
Amazon GameLift Servers はアルゴリズムを使用して、キューの送信先に優先順位を付ける方法と、新しいゲームセッションを配置する場所を決定します。アルゴリズムは、順序付けられた一連の基準に基づいています。デフォルトの優先順位を使用することも、順序をカスタマイズすることもできます。キューの優先順位はいつでも編集できます。
**デフォルトの優先順序**
1. **レイテンシー** – ゲームセッション配置リクエストにプレイヤーのロケーション固有のレイテンシーデータが含まれている場合、Amazon GameLift Servers は各ロケーションの平均プレイヤーレイテンシーを計算し、平均が最も低いフリートロケーションにゲームセッションを配置しようとします。
1. **コスト** – リクエストにレイテンシーデータが含まれていない場合、または複数のフリートのレイテンシーが等しい場合、Amazon GameLift Servers は各フリートのホスティングコストを評価します。フリートのホスティングコストは、フリートタイプ (スポットまたはオンデマンド)、インスタンスタイプ、ロケーションによって異なります。
1. **送信先** - 複数のフリートのレイテンシーとコストが等しい場合、Amazon GameLift Servers は、キュー設定にリストされている送信順序に基づいてフリートに優先順位を付けます。
1. **場所** – マルチロケーションフリートを持つキューの場合、他のすべての条件が等しい場合、Amazon GameLift Servers はアルファベット順に基づいてフリートの場所の優先順位を付けます。
## キューがゲームセッション配置の優先順位を付ける方法をカスタマイズする
キューが配置条件の優先順位を付ける方法をカスタマイズできます。キューは、受信するすべてのゲームセッション配置リクエストにカスタム優先順位を適用します。
**注記**
カスタム優先度設定を作成し、4 つの条件をすべて含めない場合、Amazon GameLift Servers は欠落している条件をデフォルトの順序で自動的に追加します。
**キューの優先度設定をカスタマイズする方法**
[Amazon GameLift Servers コンソール](https://console.aws.amazon.com/gamelift/)または AWS Command Line Interface (AWS CLI) を使用して、カスタム優先度設定を作成します。
------
#### [ Console ]
[Amazon GameLift Servers コンソール](https://console.aws.amazon.com/gamelift/)では、新しいキューの作成時または既存のキューの更新時に、キューの優先順位をカスタマイズできます。作業する AWS リージョンを選択します。
コンソールの左側のナビゲーションバーを開き、**[キュー]** を選択します。[キュー] ページで、既存のキューを選択し、**[編集]** を選択します。
1. **[ゲームセッション配置の優先度]** セクションに移動します。各優先条件をドラッグアンドドロップして、必要な順序を作成します。
1. **[ロケーションの順序]** セクションに移動します。優先する場所を追加します。このリストは、キューに複数のロケーションを持つフリートがある場合に便利です。少なくとも 1 つの場所を指定する必要があります。ここで指定した場所が最初に優先され、次にキューの送信先の他のすべての場所が優先されます。
1. **[Save changes]** (変更の保存) をクリックします。
------
#### [ AWS CLI ]
コマンド[https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/update-game-session-queue.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/update-game-session-queue.html)と `--priority-configuration`オプションを使用して、キューの優先順位をカスタマイズします。 は現在のデフォルト AWS リージョンのキューAmazon GameLift Serversを更新するか、`--region`タグを追加して別の AWS リージョンを指定できます。
次のリクエスト例では、指定されたキューの優先度設定を追加または更新します。
```
aws gamelift update-game-session-queue \
--name "example-queue-with-priority"
--priority-configuration PriorityOrder="COST','LOCATION","DESTINATION",LocationOrder="us-east-1","us-east-2","ca-central-1","us-west-2" \
```
------
## プレイヤーのレイテンシー別に配置を優先する
プレイヤーに可能な限り最高のプレイヤーエクスペリエンスを提供し、レイテンシーを最小限に抑えるには、ゲームセッション配置システムを設定するときに次の手順を実行します。
+ ゲームセッションを配置する場所を選択するときにレイテンシーを優先するようにキューを設定します。デフォルトでは、レイテンシーは優先度リストの最上位にあります。キューの優先度設定をカスタマイズし、レイテンシーを優先度順に配置する場所を選択することもできます。
+ キューのプレイヤーレイテンシーポリシーを設定します。レイテンシーポリシーを使用すると、ゲームセッション配置で許容するレイテンシーの量にハードリミットを設定できます。Amazon GameLift Servers が制限を超えることなくゲームセッションを配置できない場合、プレイスメントリクエストはタイムアウトして失敗します。単一のレイテンシーポリシーを設定することも、時間の経過とともにレイテンシー制限を徐々に緩和する一連のポリシーを作成することもできます。一連のポリシーを使用すると、初期レイテンシーの制限を非常に低く指定でき、短い遅延後にレイテンシーが高いプレイヤーに対応できます。レイテンシーポリシーの作成の詳細については、「[プレイヤーレイテンシーポリシーを作成する](queues-design-latency.md)」を参照してください。
+ ゲームセッションの配置リクエストを行うときは ([「StartGameSessionPlacement」](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_StartGameSessionPlacement.html)を参照)、各プレイヤーのレイテンシーデータを含めます。プレイヤーレイテンシーデータには、ゲームセッションを配置できるすべての場所の値が含まれます。たとえば、 AWS リージョン us-east-2 と ca-central-1 にゲームセッションを配置するキューの場合、レイテンシーデータは次のようになります。
```
"PlayerLatencies": [
{ "LatencyInMilliseconds": 100, "PlayerId": "player1", "RegionIdentifier": "us-east-2" },
{ "LatencyInMilliseconds": 100, "PlayerId": "player1", "RegionIdentifier": "ca-central-1" },
{ "LatencyInMilliseconds": 150, "PlayerId": "player2", "RegionIdentifier": "us-east-2" },
{ "LatencyInMilliseconds": 150, "PlayerId": "player2", "RegionIdentifier": "ca-central-1" }
]
```
正確なレイテンシー測定値を取得するには、Amazon GameLift Servers の UDP ping ビーコンを使用します。これらのエンドポイントを使用すると、プレイヤーデバイスと潜在的な各ホスティングロケーション間の実際の UDP ネットワークレイテンシーを測定できるため、ICMP ping を使用するよりも正確な配置決定を行うことができます。UDP ping ビーコンを使用してレイテンシーを測定する方法の詳細については、「[UDP ping ビーコン](reference-udp-ping-beacons.md)」を参照してください。
## 場所による配置の優先順位付け
優先順位付けされた地理的位置のリストに基づいてゲームセッションを配置するようにキューを設定できます。場所は、キューが新しいゲームセッションを配置する場所を選択する方法を決定する基準の 1 つです。デフォルトでは、場所はレイテンシー、コスト、送信先の後、4 番目に優先されます。
ゲームセッションの配置では、送信先と場所の意味が多少異なります。
+ *送信先*とは、特定のフリートを指し、デプロイされているすべてのフリートのホスティングリソースが含まれます。送信先で優先順位を付けると、Amazon GameLift Servers はフリート内の任意の場所に配置できます。マルチロケーションマネージドフリートと Anywhere フリートは、1 つ以上の場所にデプロイされるホスティングリソースを持つことができます。
+ *ロケーション*とは、フリートのホスティングリソースがデプロイされる特定の地理的位置を指します。フリートには、Local Zones AWS リージョンやカスタムロケーション (Anywhere フリートの場合) など、複数のロケーションを含めることができます。単一ロケーションのマネージドフリートには 1 つのロケーションがあり、常に AWS リージョンです。マルチロケーションマネージドフリートは、ホームリージョンに加え、リモートロケーションを持つことができます。Anywhere フリートには 1 つ以上のカスタムロケーションがあります。
ロケーションごとにプレイスメントを優先順位付けする場合、Amazon GameLift Servers は優先ロケーションを含むキューの送信先を検索し、使用可能なホスティングリソースを検索します。優先ロケーションを持つ送信先が複数ある場合、Amazon GameLift Servers は次の優先度基準 (コスト、レイテンシー、送信先) に進みます。
キューのロケーションの優先順位付け方法に影響を与えるには、いくつかの方法があります。
+ キューがすべてのゲームセッションの配置リクエストを処理する方法を設定します。
+ **キューに優先度設定を追加します。**キューの優先度設定には、順序付けられたロケーションのリストが含まれます。優先順位を付けるロケーションを 1 つ以上指定できます。このリストはロケーションを除外するものではなく、利用可能なホスティングリソースを最初に探す場所を Amazon GameLift Servers に指定するだけです。順序付けられたロケーションリストの一般的な用途は、ほとんどのトラフィックを 1 つ以上の特定の地理的場所にファネルし、バックアップ容量として追加の場所を使用する場合です。[UpdateGameSessionQueue](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_UpdateGameSessionQueue.html) を呼び出して優先度設定を追加します。
+ **フィルター設定をキューに追加します。**フィルター設定は、キューの許可リストです。使用可能なホスティングリソースを検索するときに、リストにない場所を無視するように Amazon GameLift Servers に指示します。フィルター設定には 2 つの一般的な用途があります。まず、複数のロケーションを持つフリートの場合、フィルターを使用してフリートのロケーションの一部を除外できます。次に、特定のロケーションでの配置を一時的に禁止する場合があります。たとえば、ロケーションで一時的な問題が発生している可能性があります。キューのフィルター設定はいつでも更新できるため、必要に応じてロケーションを簡単に追加および削除できます。[UpdateGameSessionQueue](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_UpdateGameSessionQueue.html) を呼び出してフィルター設定を追加します。
+ 個々のプレイスメントリクエストには特別な手順を使用します。
+ **ゲームセッションの配置リクエストに優先度のオーバーライドリストを含めます。**[StartGameSessionPlacement](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_StartGameSessionPlacement.html) リクエストを使用して、ロケーションの代替優先度リストを指定できます。このリストは、その 1 つのリクエストのみのロケーションに対してキューが設定した優先順位を効果的に置き換えます。他のリクエストには影響しません。このオーバーライド機能にはいくつかの要件があります。
+ オーバーライドリストは、優先度設定が `LOCATION` であるキューを最優先としてのみ使用します。
+ 同じプレイスメントリクエストにプレイヤーレイテンシーデータを含めないでください。Amazon GameLift Servers が解決できないロケーションを優先する場合、レイテンシーデータを含めると競合が発生します。
+ 優先度のオーバーライドリストで使用可能なリソースが見つからない場合の Amazon GameLift Servers の処理方法を決定します。キューの他のロケーションにフォールバックするか、オーバーライドリストへの配置を制限するかを選択します。デフォルトでは、Amazon GameLift Servers はキューの他のロケーションへの配置を試みるためにフォールバックします。
+ オーバーライドリストにロケーションを追加するなど、必要に応じてキューのフィルター設定を更新します。オーバーライドリストはフィルターリストを無効にしません。
# プレイヤーレイテンシーポリシーを作成する
プレイスメントリクエストにプレイヤーレイテンシーデータが含まれている場合、Amazon GameLift Servers は、すべてのプレイヤーに対して、平均レイテンシーが最小のロケーションのゲームセッションを検出します。平均プレイヤーレイテンシーに基づいてゲームセッションを配置することで、Amazon GameLift Servers は多くのプレイヤーを高いレイテンシーのゲームに配置することを防ぎます。ただし、Amazon GameLift Servers はそれでもプレイヤーを非常に高いレイテンシーで配置します。このようなプレイヤーに対応するため、プレイヤーレイテンシーポリシーを作成します。
プレイヤーレイテンシーポリシーは、Amazon GameLift Servers がリクエストされたゲームセッションを、リクエスト内のプレイヤーが最大値を超えるレイテンシーを経験するロケーションに配置するのを防止します。また、プレイヤーレイテンシーポリシーは、Amazon GameLift Servers がゲームセッションリクエストをレイテンシーの高いプレイヤーとマッチングしないようにすることもできます。
**ヒント**
グループ内のすべてのプレイヤーで同様のレイテンシーを必要とするなど、プレイヤーのレイテンシーのルールを具体的に管理したい場合は、[Amazon GameLift Servers FlexMatch](https://docs.aws.amazon.com/gameliftservers/latest/flexmatchguide/match-intro.html) を使用して、レイテンシーベースのマッチメーキングルールを作成します。
たとえば、タイムアウトが 5 分間で、次のプレイヤーレイテンシーポリシーのあるキューについて検討してみましょう。
1. 120 秒かけて、すべてのプレイヤーのレイテンシーが 50 ミリ秒未満のロケーションを検索します。
1. 120 秒かけて、すべてのプレイヤーのレイテンシーが 100 ミリ秒未満のロケーションを検索します。
1. 次に、キューのタイムアウトまでの残り時間を使って、すべてのプレイヤーレイテンシーが 200 ミリ秒未満のロケーションを検索します。
![\[徐々に緩和されるレイテンシーポリシーの例を示すコンソールのスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/gameliftservers/latest/developerguide/images/queue-latency-policy.png)
# スポットインスタンスのキューの設計
スポットフリートを使用すると、ホスティングコストを大幅に削減できます。スポットフリートとその使用方法の詳細については、「[オンデマンドインスタンスとスポットインスタンスの比較](gamelift-compute.md#gamelift-compute-spot)」を参照してください。
ゲームホスティングソリューションにスポットフリートが含まれている場合は、ゲームセッションプレイスメントキューを使用する必要があります。Amazon GameLift Servers はキューを使用して複数のゲームホスティングリソースを検索し、新しいゲームセッションをホストするために利用可能な最適なリソースを選択します。スポットフリートでは、キューはホスティングコストを最小限に抑え、スポットの中断を回避するために特に重要です。このトピックは、中断、スローダウン、停止が発生した場合でもプレイヤーのゲームをホストし続けることができる回復力のあるキューを設定するのに役立ちます。キューが利用可能なホスティングリソースに優先順位を付ける方法は、ホスティングコストなどのいくつかの要因に基づいてカスタマイズできます。
マッチメーキングに FlexMatch を使用していますか? マッチメイキングを配置する既存のゲームセッションキューにスポットフリートを追加できます。
## スポットフリートの実装タスク
スポットフリートを使用するようにゲームホスティングソリューションを作成または更新する場合は、次のタスクを完了します。スポットの可用性と回復性を最適化するキューを構築する方法の詳細については、「[スポットフリートによるゲームホスティングコストの削減](fleets-spot.md)」を参照してください。
1. **ゲームセッションキューのフリート送信先のセットを選択して作成します。**
まず、キューでゲームセッションを配置する場所を決定します。キューは複数のフリートを検索して、最適な配置を見つけることができます。各フリートは、複数の地理的な場所にデプロイされたインスタンスを持つことができます。ロケーションタイプとインスタンスタイプの両方で異なるフリートを持つキューは、プレイスメントを成功させる可能性が高くなります。効果的で回復力のあるスポット最適化キューを設計するためのベストプラクティスを参照してください。
1. **スポット最適化ゲームセッションキューを作成します。**
キューを作成し、スポットフリート用に設定します。新しいキューの作成および設定のヘルプについては、「[ゲームセッションキューを作成する](queues-creating.md)」を参照してください。Amazon GameLift Servers コンソールまたは AWS CLI を使用して、キューを作成または編集できます。
+ ステップ 1 からフリートの送信先を追加します。
+ 必要に応じて送信先の順序に優先順位を付けます。デフォルトでは、Amazon GameLift Servers は送信先のコストで優先順位を付けるため、送信先間のコストが最も低い場合にのみ送信先の順序が使用されます。
+ プレイヤーのレイテンシーの前にゲームホスティングコストを優先する場合は、カスタムプレイスメントの優先順位を指定します。「[ゲームセッション配置に優先順位を付ける](queues-design-priority.md)」を参照してください。
1. **ソリューション内の他のコンポーネントを更新して、新しいキューを使用します。**
ソリューションがスポット最適化キューを使用して新しいゲームセッションを開始すると、キューは中断の可能性の高いフリートでゲームセッションを配置することを自動的に回避します。代わりに、プレイヤーのレイテンシー、ホスティングコスト、送信先の順序など、定義された優先順位に一致するリソースについて、実行可能なすべてのフリートを検索します。
+ FlexMatch を使用していない場合 – バックエンドサービスを更新して、ゲームセッションリクエストで新しいスポット最適化キューを指定します。バックエンドサービスは、ゲームクライアントに代わって (`StartGameSessionPlacement()` を使用して) Amazon GameLift Servers に API リクエストを行い、各リクエストはキュー名を指定する必要があります。ゲームクライアントにゲームセッション配置を実装する方法については、「[ゲームセッションを作成する](gamelift-sdk-client-api.md#gamelift-sdk-client-api-create)」を参照してください。
+ FlexMatch を使用している場合 – マッチメーキング設定を更新して、新しいスポット最適化キューにゲームセッションリクエストを送信します。マッチメーキングシステムがプレイヤーマッチを形成すると、指定されたキューにゲームセッション配置リクエストを送信して、マッチの新しいゲームセッションを開始します。FlexMatch モードが「マネージド」に設定されているマッチメーキング設定のみがプレイスメントキューを指定できます。CLI または AWS コンソールを使用してマッチメーキング設定を更新できます Amazon GameLift Servers ([「マッチメーキング設定の編集](https://docs.aws.amazon.com/gameliftservers/latest/flexmatchguide/match-create-configuration-edit.html)」を参照）。
1. **スポットフリートとキューのパフォーマンスを評価します。**
Amazon GameLift Servers コンソールの Amazon GameLift Servers メトリクス、または Amazon CloudWatch を表示してパフォーマンスを確認できます。Amazon GameLift Servers メトリクスの詳細については、「[Amazon CloudWatch で Amazon GameLift Servers を監視する](monitoring-cloudwatch.md)」を参照してください。主なメトリクスには次のものがあります。
+ 中断率 – スポットフリートのインスタンスとゲームセッションについてスポットに関連した中断の回数と頻度を追跡する `InstanceInterruptions` および `GameSessionInterruptions` メトリクスを使用します。再要求されたインスタンスのゲームセッションのステータスは `TERMINATED`、ステータス理由は `INTERRUPTED` です。
+ キューの有効性 – プレイスメントの成功率、平均待機時間、キューの深度などのキューメトリクスを追跡し、スポットフリートによってキューのパフォーマンスに影響が出ないことを確認します。
+ フリート使用率 – インスタンス、ゲームセッションおよびプレイヤーセッションをモニタリングします。オンデマンドフリートの使用率は、中断を避けるためにキューがスポットフリートへのプレイスメントを避けている指標になります。
## スポットフリートを使用したキューのベストプラクティス
スポットインスタンスのフリートとキューを作成するときは、次のベストプラクティスを使用します。
+ **キューの地理的カバレッジを拡張します。**プレイヤーが 1 つの にクラスター化されていても AWS リージョン、スポットフリートに隣接する場所を追加します。このアプローチにより、リージョンの速度低下、停止、スポットの中断時にキャパシティを維持するキューの機能が向上します。マルチロケーションフリートは、スポットインスタンスとオンデマンドインスタンスの両方で動作します。
+ **キューのインスタンスタイプのカバレッジを多様化します。** はインスタンスタイプに基づいてスポットの実行可能性Amazon GameLift Serversを評価するため、さまざまなインスタンスタイプのスポットフリートがあると、複数のスポットフリートが同時に実行できなくなる可能性が低くなります。各ロケーションに異なるインスタンスタイプを持つ少なくとも 2 つのスポットフリートを含めます。
**注記**
料金は、フリートの数ではなく、使用するインスタンスに基づいています。それぞれ 10 個のインスタンスで 5 つのフリートを実行することは、同様のコストで 50 個のインスタンスで 1 つのフリートを実行することと同じです。料金はインスタンスタイプ、サイズ、場所によって異なります。
スポットインスタンスタイプをグループ化するためのヒント:
+ `m6g.medium`、`m6g.large`、`m6g.xlarge` など、同じファミリーでインスタンスタイプを使用します。インスタンスタイプが大きいほどコストは高くなりますが、一度により多くのゲームセッションをホストすることもできます。
+ 広く利用可能なインスタンスタイプを選択します。通常、旧世代のファミリー (C5, M5、R5 など) と一般的なサイズ (.large、.xlarge、.2xlarge など) は可用性が高くなります。
+ Amazon GameLift Servers コンソールで 30～90 日間の料金履歴を確認します。一貫した可用性パターンを持つインスタンスタイプを探します。
+ Amazon GameLift Servers コンソール、フリート作成ツールを使用して、インスタンスタイプのロケーションカバレッジを調べます。
+ **バックアップ容量のオンデマンドフリートを追加します。**ゲームホスティングは、スポットフリートが利用できないときはいつでもオンデマンドフリートに切り替えることができます。各ロケーションに少なくとも 1 つのオンデマンドフリートを配置して、プレイヤーのレイテンシーを低く保ちます。バックアップオンデマンドフリートに自動スケーリングを追加すると、必要なまでスケールダウンしたままにできます。
+ **すべてのフリート送信先にエイリアスを割り当てます。**キューの送信先ごとにエイリアスを作成します。エイリアスを使用すると、フリートを置き換える必要がある場合に簡単かつ効率的になります。
+ **キューの優先順位付け戦略を適用します。**キューがゲームセッションの配置先を優先する方法をカスタマイズできます (詳細については、「[ゲームセッション配置に優先順位を付ける](queues-design-priority.md)」を参照)。スポット最適化キューの場合、コストで優先順位を付けると、可能な限り低コストのスポットフリートが使用されます。
送信先順序を指定して、特定のフリートに優先順位を付けることもできます。たとえば、一部のユーザーは、定期的に使用するプライマリフリートのセットと、バックアップとしてセカンダリフリートのセットを指定します。このシナリオでは、キューの送信先順序を設定して、プライマリフリートを最初に一覧表示します。次に、キューの優先順位を宛先とそれに続くコストで設定します。
# ホスティングリソースのカスタマイズ
このセクションでは、特定のパフォーマンス、コスト、運用要件を満たすように Amazon GameLift Servers インフラストラクチャを設定および管理するための高度なオプションを提供します。特に、このセクションのトピックでは、ゲームとプレイヤーに最適な Amazon GameLift Servers マネージドホスティングリソースをカスタマイズする方法について説明します。
考慮すべき決定事項には、次のようなものがあります。
+ プレイヤーのホスティングリソースをデプロイする場所とは ゲームプレイのレイテンシーはフリートの地理的場所を選択する上で重要な要素ですが、リソースタイプの可用性やコストなど、場所によって異なるその他の要因があります。
+ ゲームに最適な EC2 インスタンスタイプはどれか。利用可能なインスタンスタイプの中から、コンピューティングアーキテクチャ、メモリ、ストレージ、ネットワーク容量の最適な組み合わせを使用するものを選択します。
+ 必要なインスタンスタイプのサイズはどのくらいか。ゲームサーバーソフトウェアのリソース要件 (メモリと CPU) などの要因に基づいて、インスタンスタイプのサイズを選択します。
+ フリートはオンデマンドインスタンスまたはスポットインスタンスを使用する必要があるか。低い Spot 料金を活用できるかどうか、また Amazon GameLift Servers がゲームセッションに対する Spot の中断リスクを十分に軽減できるかどうかを検討してください。
+ ゲームサーバーソフトウェアを各フリートインスタンスでどのように実行するか。ランタイム設定は、実行するサーバーソフトウェアとその方法を Amazon GameLift Servers に指示します。
+ コンテナフリートの場合、デフォルト設定がゲームで機能するかどうか。Amazon GameLift Servers はコンテナフリート設定を最適化するための作業の多くを代行しますが、ほとんどの設定はカスタマイズできます。
# マネージドフリートのコンピューティングリソースを選択する
Amazon GameLift Servers マネージド EC2 やマネージドコンテナを含むマネージドホスティングの場合、サービスはゲームサーバーを AWS クラウドのコンピューティングリソースのフリートにデプロイします。マネージドフリートを作成する場合は、ゲームに最適なホスティングリソースを設定する必要があります。このトピックでは、ゲームホスティングフリートを選択および設定する際の重要な決定ポイントについて説明します。
**注記**
Anywhere フリートと Amazon GameLift Servers マネージドフリートの両方を使用してハイブリッドソリューションを構築する場合は、これらのトピックを参照して、セルフマネージドリソースを補完するための マネージドフリートを設計してください。「[Amazon GameLift Servers のホスティングフリートをデプロイする](fleets-intro.md)」を参照してください。
**Topics**
+ [地理的場所](#gamelift-compute-location)
+ [オペレーティングシステム](#gamelift-compute-os)
+ [インスタンスのタイプ](#gamelift-compute-instance)
+ [オンデマンドインスタンスとスポットインスタンスの比較](#gamelift-compute-spot)
+ [Service Quotas](#gamelift-service-limits)
## 地理的場所
ゲームサーバーをデプロイする予定の場所を検討してください。一般的に、可能な限り最高のプレイヤーエクスペリエンスを提供するために、ゲームサーバーをプレイヤーにできるだけ近づけたいと考えています。Amazon GameLift Servers マネージドホスティングでは、サポートされている任意の AWS リージョン およびローカルゾーンにゲームサーバーを配置することを選択できます。ハイブリッドソリューションを構築する場合は、マネージドフリートのデプロイがセルフマネージド Amazon GameLift Servers Anywhere フリートの場所を補完する方法を検討してください。
ほとんどの開発およびテストシナリオでは、単一の場所にデプロイするのが理にかなっています。起動以降に備えると、複数の地理的な場所にデプロイする理由は多数あります。これには、幅広いプレイヤーグループをサポートし、ゲームホスティングの全体的な耐障害性と信頼性を向上させることが含まれます。複数のロケーションでは、ゲームセッションの配置を高速化し、レイテンシーとコストに合わせて配置を最適化するときにより多くの選択を可能にすることで、プレイヤーのエクスペリエンスを向上させることもできます。
Amazon GameLift Servers でサポートされているロケーションのリストと、すべてのフリートタイプのロケーションの詳細については、「[Amazon GameLift Servers サービスロケーション](gamelift-regions.md)」を参照してください。
マルチロケーションフリート
1 つのマネージドフリートで、複数の場所にリソースをデプロイできます。マルチロケーションフリート内の個々のロケーションに容量を手動で設定できます。
マルチロケーションフリートを使用する利点:
+ フリートのデプロイと管理の簡素化 - ゲームサーバーソフトウェアとフリート設定を提供し、Amazon GameLift Servers が複数のロケーション (一度構築、任意の場所にデプロイ) のフリートインスタンスにデプロイします。本番フリートでは、各ロケーションが異なるリージョンにある複数のフリートを個別に管理する必要はなく、フリート内のすべてのロケーションを一覧表示して管理できます。
+ ローカルゾーンの可用性 – ローカルゾーンを使用する場合は、 AWS リージョン ホームロケーションとローカルゾーンをリモートロケーションとするマルチロケーションフリートを作成する必要があります。Local Zones は、それを必要とするエリアや顧客にレイテンシーをさらに短縮 AWS リージョン できる の拡張機能です。ローカルゾーンは任意のマルチロケーションフリートに追加できます。ローカルゾーンの親 AWS リージョンを含める必要はありません。
+ ゲームセッションキューとの互換性 - 1 つ以上のマルチロケーションフリートを使用してゲームセッションプレイスメントキューを構築できます。このアプローチにより、新しいゲームセッションをホストする場所を優先して選択する際のキューの柔軟性が得られます。
+ 効率的なリソース使用率 - 自動スケーリングを有効にすると、Amazon GameLift Servers はフリート内のすべてのロケーションで容量スケーリングをより適切に最適化できます。
マルチロケーションフリートを使用するためのヒント:
+ AWS リージョン または フリートあたりのロケーション数のクォータを確認します。「[Amazon GameLift Servers サービスのクオータ](https://docs.aws.amazon.com/general/latest/gr/gamelift.html#limits_gamelift)」を参照してください。
+ ロケーションによっては使用できないインスタンスタイプがあります。選択した場所によっては、インスタンスタイプのオプションが限られている場合があります。Amazon GameLift Servers コンソールには、場所とインスタンスタイプの適切なバランスを見つけるのに役立つ便利なツールが用意されています。
+ [UDP ping ビーコン](reference-udp-ping-beacons.md) を使用してすべてのフリートロケーションのプレイヤーレイテンシーデータを収集することを検討してください。Amazon GameLift Servers はこのデータを使用して、低レイテンシーのゲームセッションを最適化し、許容できないほど高いレイテンシーでプレイヤーがセッションに参加できないようにします。これらの特別なエンドポイントは、従来の ICMP ping の代わりに UDP メッセージを受け入れるため、正確なレイテンシー測定が可能になり、最適なフリートロケーションの選択に役立ちます。
## オペレーティングシステム
マネージドフリート内のすべてのインスタンスは、ゲームサーバーソフトウェアの完全なランタイム環境を提供する Amazon マシンイメージ (AMI) でデプロイされます。マネージド EC2 フリートの場合、ビルドを Amazon GameLift Servers にアップロードするときにゲームサーバービルドのオペレーティングシステムを指定します。マネージドコンテナフリートの場合は、コンテナグループ定義でオペレーティングシステムを指定します。AMI のバージョンの詳細については、[Amazon GameLift Servers AMI バージョン](reference-ec2-ami-version-history.md) を参照してください。
AMI バージョンは定期的に更新されます。新しいフリートを作成すると、Amazon GameLift Servers はゲームビルド用に選択した AMI の最新バージョンを割り当てます。そのフリートにデプロイされているすべてのインスタンスは、同じバージョンを使用します。AMI バージョンを最新のセキュリティおよびソフトウェア更新で最新の状態に保つには、フリートを定期的に置き換える必要があります。ベストプラクティスとして、マネージドフリートのランタイム環境を最新に保つため、30日ごとにフリートを更新することをお勧めします。ガイダンスについては、「[Amazon GameLift Servers のセキュリティに関するベストプラクティス](security-best-practices.md)」を参照してください。
## インスタンスのタイプ
マネージドフリートのインスタンスタイプは、すべてのフリートインスタンスにデプロイされるハードウェアの種類を決定し、インスタンスタイプは一般的にさまざまなサイズで利用できます。すべての Amazon GameLift Servers マネージドフリートは Amazon EC2 インスタンスを使用し、コンピューティング能力、メモリ、ストレージ、ネットワーク機能のさまざまな組み合わせを提供する幅広いインスタンスタイプをサポートします。インスタンスタイプの利用可否は、選択するロケーションによって異なります。
Amazon GameLift Servers コンソールには、ゲームビルドおよびデプロイ場所に適したインスタンスタイプを選択するのに役立つ便利なツールが用意されています。マネージドコンテナフリートの場合、コンソールはゲームの CPU 電源とメモリの要件に関するガイダンスも提供します。
ゲームに対して使用可能なインスタンスタイプから選択するときは、次の要素を考慮してください。
+ ゲームサーバーのコンピューティングアーキテクチャ: x64 または Arm (AWS Graviton)。
**注記**
Graviton Arm インスタンスには、Linux AMI 用のサーバービルドが必要です。C\$1\$1 および C\$1 には、サーバー SDK 5.1.1 以降が必要です。Go にはサーバー SDK 5.0 以降が必要です。これらのインスタンスでは、Amazon Linux 2023 (AL2023) および Amazon Linux 2 (AL2)での Mono インストールは標準ではサポートされません。
+ ゲームサーバービルドのコンピューティング、メモリ、およびストレージ要件。
+ インスタンスタイプのサイズ。ゲームサーバーソフトウェア実行可能ファイルの要件を満たすだけでなく、より大きなインスタンスタイプでは、各インスタンスで複数のゲームサーバープロセスやコンテナを実行できます。検討すべき要素にはコストが含まれます (大きなインスタンスを少数実行する方が安いのか、小さなインスタンスを多数実行する方が安いのか) 。フリートスケーリングイベントの間や異常のあるインスタンスをシャットダウンする際に、インスタンスを追加または削除すると、全体のゲームホスティング容量に大きく影響する可能性があります。各インスタンスが多数のゲームサーバープロセスを同時に実行する場合、インスタンスを追加または削除すると、同じホスティング容量に大きな影響を与える可能性があります。
インスタンスタイプの詳細については、「[Amazon EC2 インスタンスタイプ](https://aws.amazon.com/ec2/instance-types/)」を参照してください。
## オンデマンドインスタンスとスポットインスタンスの比較
Amazon EC2 オンデマンドインスタンスとスポットインスタンスは同じハードウェアとパフォーマンスを提供しますが、可用性とコストは異なります。
**オンデマンドインスタンス**
オンデマンドインスタンスは必要なときに取得し、必要な期間維持しておくことができます。オンデマンドインスタンスは従量課金制で、使用した時間分だけ料金が発生します。長期契約の必要はありません。
**スポットインスタンス**
スポットインスタンスは、未使用の AWS コンピューティング容量を利用することで、オンデマンドインスタンスに代わるコスト効率の高い方法を提供できます。スポットインスタンスの料金は、各ロケーションの各インスタンスタイプの需要と供給に応じて変動します。 は、容量を戻す必要があるたびに 2 分間の通知でスポットインスタンスを再利用 AWS でき、再利用されたインスタンスでアクティブに実行されているゲームセッションは中断されます。
Amazon GameLift Servers には、ゲームセッションのスポット中断の可能性を軽減するのに役立つツールがいくつか用意されています。スポットバイアビリティアルゴリズムは、インスタンスタイプの履歴データを追跡して、中断のリスクが重要なポイントに達するタイミングを予測し、そのタイプのスポットインスタンスに新しいゲームセッションを配置しないようにします。中断が発生した場合、ゲームサーバーは通知を使用してプレイヤーのゲームセッションを適切に終了できます。
スポットフリートによるゲームホスティングでは、ゲームセッションの配置にキューを使用する必要があります。キューは、スポットフリートの実行可能性、コスト、その他の要因に基づいてゲームセッション配置に優先順位を付けることができます。ゲームサーバーホスティングでスポットを利用する方法の詳細については、以下のトピックを参照してください。
+ [スポットフリートによるゲームホスティングコストの削減](fleets-spot.md)
+ [スポットインスタンスのキューの設計](spot-tasks.md)
## Service Quotas
次のツールを使用して、Amazon GameLift Servers のデフォルトのサービスクォータと、 AWS アカウント の現在のクォータステータスを確認できます。
+ Amazon GameLift Servers に関する一般的なサービスクォータ情報については、*AWS 全般のリファレンス* の「[Amazon GameLift Servers エンドポイントおよびクォータ](https://docs.aws.amazon.com/general/latest/gr/gamelift.html)」を参照してください。
+ アカウントのロケーションごとに利用可能なインスタンスタイプのリストについては、Amazon GameLift Servers コンソールの [[Service Quotas]](https://console.aws.amazon.com/gamelift/service-quotas) ページを開いてください。このページには、各ロケーションの各インスタンスタイプに関するアカウントの現在の使用状況も表示されます。
+ リージョンごとのインスタンスタイプのアカウントの現在のクォータのリストについては、 AWS Command Line Interface (AWS CLI) コマンド を実行します[https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/describe-ec2-instance-limits.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/describe-ec2-instance-limits.html)。このコマンドは、デフォルトリージョン (または指定した別のリージョン) にあるアクティブなインスタンスの数を返します。
ゲームを起動する準備ができたら、 [Amazon GameLift Serversコンソール](https://console.aws.amazon.com/gamelift/)で起動アンケートに入力します。Amazon GameLift Servers チームはローンチアンケートを使用して、ゲームの正しいクォータと制限を決定します。
# Amazon GameLift Servers コンテナフリートをカスタマイズする
このセクションのトピックでは、Amazon GameLift Servers マネージドコンテナのオプション機能の一部を説明します。これらの機能は、必要に応じて、いずれか単独でも、複数組み合わせても 使用できます。
**Topics**
+ [リソース制限の設定](#containers-design-fleet-limits)
+ [コンテナフリートのメモリ割り当てを理解する](#containers-design-fleet-memory-allocation)
+ [NVMe ドライブアクセスの設定](#containers-design-fleet-nvme)
+ [必須コンテナの指定](#containers-design-fleet-essential)
+ [ネットワーク接続を構成する](#containers-custom-network)
+ [コンテナのヘルスチェックを設定する](#containers-design-fleet-health)
+ [コンテナの依存関係の設定](#containers-design-fleet-dependencies)
+ [コンテナフリートを設定する](#containers-design-fleet-config)
## リソース制限の設定
各コンテナグループについて、その コンテナグループがソフトウェアを実行するために必要なメモリおよびコンピューティング能力を設定できます。Amazon GameLift Servers はこの情報を使用してグループ全体のリソースを管理します。さらに、この情報を使って、フリートイメージが保持できるゲームサーバーコンテナグループの数を算出します。個々のコンテナに対して制限を設定することもできます。
コンテナグループのメモリおよびコンピューティング能力の上限を設定できます。デフォルトでは、これらのリソースはグループ内のすべてのコンテナで共有されます。個々のコンテナに制限を設定することで、リソース管理をさらに細かく調整できます。
**個々のコンテナにオプションの制限を設定**
コンテナごとにリソース制限を設定すると、個々のコンテナがグループのリソースをどのように使用するかをより細かく管理できます。コンテナ固有の制限を設定しない場合、グループ内のコンテナはすべて グループのリソースを共有します。共有することで、必要なリソースを柔軟に使用しやすくなります。一方で、プロセス同士がリソースを奪い合い、結果的にコンテナが障害を起こす可能性も高まります。
任意のコンテナに対して、以下のいずれかの `ContainerDefinition` プロパティを設定できます。
+ `MemoryHardLimitMebibytes` – コンテナの最大メモリ制限を設定します。コンテナがこの制限を超えると、再起動されます。
+ `Vcpu` 制限 – コンテナが専有して使用するための最小 vCPU リソースを予約します。コンテナには、この予約済みリソースが常に利用可能です。追加のリソースが利用可能な場合、この最小値を上回ることも可能です。(1024 CPU ユニットは 1 vCPU に相当します)。
**コンテナグループの総合リソース制限を設定します。**
個々のコンテナに制限を設定する場合、コンテナグループに必要なメモリや vCPU リソース量を調整する必要が生じる場合があります。目的は、ゲームサーバーのパフォーマンスを最適化するために十分なリソースを割り当てることです。Amazon GameLift Servers は、この制限情報を使用して、1 つのフリートインスタンスにどれだけのゲームコンテナサーバーグループを配置できるかを計算します。また、この情報はコンテナフリートのインスタンスタイプを選択する際にも使用します。
コンテナグループに必要な合計メモリと vCPU を計算します。以下の点を考慮してください。
+ コンテナグループ内のすべてのコンテナで実行されるすべてのプロセスは何ですか。これらのプロセスに必要なリソースを加算します。コンテナ固有の制限に注意してください。
+ 各コンテナグループで実行する予定の同時ゲームサーバープロセス数はいくつですか。これはゲームサーバーコンテナイメージで決定します。
コンテナグループ要件の見積もりに基づいて、次の `ContainerGroupDefinition` プロパティを設定します。
+ `TotalMemoryLimitMebibytes` – コンテナグループの最大メモリ制限を設定します。グループ内のすべてのコンテナは、割り当てられたメモリを共有します。個々のコンテナ 制限を設定する場合、合計メモリはそのコンテナ固有の最大メモリ 制限以上である必要があります。
+ `TotalVcpuLimit` – コンテナグループの最大 vCPU 制限を設定します。グループ内のすべてのコンテナは、割り当てられた CPU リソースを共有します。個々のコンテナ制限を設定する場合、合計 CPU 制限は、すべてのコンテナ固有の CPU 制限の合計以上である必要があります。ベストプラクティスとして、この値をコンテナ CPU 制限の合計の 2 倍に設定することを検討してください。
**シナリオの例**
次の 3 つのコンテナを使用して、ゲームサーバーコンテナグループを定義するとします。
+ コンテナ A は ゲームサーバーコンテナ です。1 つのゲームサーバーのリソース要件は、512 MiB と 1024 CPU で見積もられます。コンテナで 1 つのサーバープロセスを実行する予定です。このコンテナは最も重要なソフトウェアを実行するため、桃利制限と vCPU リザーブ制限は設定しません。
+ コンテナ B は、リソース要件が 1024 MiB および 1536 CPU と推定されるサポートコンテナです。メモリ上限は2048 MiB、CPUリザーブの上限は1024 CPUユニットに設定されています。
+ コンテナ C は別の サポート コンテナ です。メモリのハードリミットは512 MiB、CPUリザーブの上限は512 CPUユニットに設定されています。
この情報を使用して、コンテナグループに対して次の合計制限を設定します。
+ 合計メモリ制限: 7680 MiB。この値は、メモリの上限 (1024 MiB) を超えています。
+ 合計 CPU 制限: 13312 CPU。この値は CPU 制限 (1024\$1512 CPU) の合計を超えています。
## コンテナフリートのメモリ割り当てを理解する
がフリートインスタンスにコンテナグループをAmazon GameLift Serversデプロイする場合、インスタンスのすべてのメモリがコンテナで使用できるわけではありません。 は、オペレーティングシステム、Amazon ECS エージェント、およびその他のサポートサービスのインスタンスメモリの一部Amazon GameLift Serversを予約します。予約メモリの量は、インスタンスタイプの合計メモリによって異なります。このオーバーヘッドを理解することで、使用可能なリソースを最大限に活用するようにコンテナグループ定義を設定できます。
### メモリオーバーヘッド数式
Amazon GameLift Servers は、次の手順を使用してコンテナグループで使用できるメモリを計算します。
1. **メモリバッファの割合を決定します。** は、次の階層に基づいてインスタンスの合計メモリの割合Amazon GameLift Serversを予約します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/gameliftservers/latest/developerguide/containers-design-fleet.html)
1. **使用可能なメモリを計算します。**インスタンスメモリの合計からリザーブドメモリを減算します。
`AvailableMemory = InstanceMemory - round(InstanceMemory × BufferPercentage)`
1. **インスタンスごとのコンテナグループメモリを減算します。**フリートがインスタンスごとのコンテナグループを使用している場合は、使用可能なメモリ`TotalMemoryLimitMebibytes`からそのコンテナグループを減算します。インスタンスごとに 1 つのコンテナグループがフリートインスタンスごとに実行されます。
`AvailableMemory = AvailableMemory - PerInstanceCGD.TotalMemoryLimitMebibytes`
1. **ログルーターのオーバーヘッドを考慮します。**フリートのログ記録が有効になっている場合、 はログルーターのゲームサーバーコンテナグループごとにさらに 50 MiB Amazon GameLift Serversを予約します。
1. **ゲームサーバーコンテナグループの最大数を計算します。**メモリによってインスタンスに収まるゲームサーバーコンテナグループの最大数は、次のとおりです。
`MaxGroupsByMemory = floor(AvailableMemory / (GameServerCGD.TotalMemoryLimitMebibytes + LogRouterMemory))`
ここで、 `LogRouterMemory`はログ記録が有効になっている場合は 50 MiB、ログ記録が無効になっている場合は 0 です。
**注記**
メモリは、インスタンスに収まるゲームサーバーコンテナグループの数を決定する 1 つの要素にすぎません。 は vCPU 容量と使用可能な接続ポートAmazon GameLift Serversも考慮し、3 つの計算の最小値を使用します。
### メモリ計算の例
ログ記録が有効になっている`c5.xlarge`インスタンス (合計メモリ 8,192 MiB) を使用するフリートを考えてみましょう。
1. インスタンスメモリは 8,192 MiB で、5,000～9,999 層 (6% バッファ) に相当します。
1. 予約メモリ = round(8,192 × 0.06) = 492 MiB
1. 使用可能なメモリ = 8,192～492 = 7,700 MiB
1. 512 `TotalMemoryLimitMebibytes`のインスタンスごとのコンテナグループを使用する場合: 使用可能なメモリ = 7,700～512 = 7,188 MiB
1. 各ゲームサーバーコンテナグループの `TotalMemoryLimitMebibytes`が 1,024 の場合: MaxGroupsByMemory = floor(7,188 / (1,024 \$1 50)) = floor(7,188 / 1,074) = 6
### インスタンスタイプ別の使用可能なメモリ
次の表は、一般的に使用されるインスタンスタイプの合計メモリと使用可能なメモリ (Amazon GameLift Serversバッファの後) を示しています。コンテナグループ定義を設定するときは、これらの値を出発点として使用します。*使用可能なメモリ*列には、インスタンス上のすべてのコンテナグループで使用できるメモリが表示されてから、インスタンスごとのコンテナグループまたはログルーターのオーバーヘッドが減算されます。
| インスタンスタイプ | 合計メモリ (MiB) | バッファの割合 | 使用可能なメモリ (MiB) |
| --- | --- | --- | --- |
| c5.large | 4,096 | 8% | 3,768 |
| c5.xlarge | 8,192 | 6% | 7,700 |
| c5.2xlarge | 16,384 | 5% | 15,565 |
| c5.4xlarge | 32,768 | 5% | 31,130 |
| c5.9xlarge | 73,728 | 5% | 70,042 |
| c5.12xlarge | 98,304 | 4% | 94,372 |
| c5.18xlarge | 147,456 | 4% | 141,558 |
| c5.24xlarge | 196,608 | 4% | 188,744 |
| m5.large | 8,192 | 6% | 7,700 |
| m5.xlarge | 16,384 | 5% | 15,565 |
| m5.2xlarge | 32,768 | 5% | 31,130 |
| m5.4xlarge | 65,536 | 5% | 62,259 |
| m5.8xlarge | 131,072 | 4% | 125,829 |
| m5.12xlarge | 196,608 | 4% | 188,744 |
| r5.large | 16,384 | 5% | 15,565 |
| r5.xlarge | 32,768 | 5% | 31,130 |
| r5.2xlarge | 65,536 | 5% | 62,259 |
| r5.4xlarge | 131,072 | 4% | 125,829 |
| c6i.large | 4,096 | 8% | 3,768 |
| c6i.xlarge | 8,192 | 6% | 7,700 |
| c6i.2xlarge | 16,384 | 5% | 15,565 |
| c6i.4xlarge | 32,768 | 5% | 31,130 |
| c6i.8xlarge | 65,536 | 5% | 62,259 |
| c7i.large | 4,096 | 8% | 3,768 |
| c7i.xlarge | 8,192 | 6% | 7,700 |
| c7i.2xlarge | 16,384 | 5% | 15,565 |
| c7i.4xlarge | 32,768 | 5% | 31,130 |
| c7i.8xlarge | 65,536 | 5% | 62,259 |
| m7i.large | 8,192 | 6% | 7,700 |
| m7i.xlarge | 16,384 | 5% | 15,565 |
| m7i.2xlarge | 32,768 | 5% | 31,130 |
| m7i.4xlarge | 65,536 | 5% | 62,259 |
| m7i.8xlarge | 131,072 | 4% | 125,829 |
| m7i.12xlarge | 196,608 | 4% | 188,744 |
| r7i.large | 16,384 | 5% | 15,565 |
| r7i.xlarge | 32,768 | 5% | 31,130 |
| r7i.2xlarge | 65,536 | 5% | 62,259 |
| r7i.4xlarge | 131,072 | 4% | 125,829 |
ここにリストされていないインスタンスタイプの場合、上記の式を使用して使用可能なメモリを計算できます。選択した[インスタンスタイプの合計メモリについては、Amazon EC2 インスタンスタイプのドキュメント](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-instance-type-specifications.html)を参照してください。
## NVMe ドライブアクセスの設定
d タイプのインスタンスでは、ホストの起動時に NVMe ドライブが `/data` ディレクトリに自動的にマウントされます。コンテナが SSD ストレージにアクセスできるようにするには、次の`ContainerGroupDefinition`プロパティ を設定します`MountPoints`。
+ `InstancePath` – ホストインスタンスの自動マウント NVMe ドライブを参照`/data`するには、 に設定します。
+ `AccessLevel` – コンテナのニーズに適したアクセスレベルを選択します (例: READ\$1ONLY または READ\$1WRITE)。
+ `ContainerPath` – (オプション) インスタンスパスをコンテナ内にマウントするパスを指定します。指定しない場合、デフォルトでインスタンスパスになります。
マウントポイントの詳細については、「Amazon GameLift Servers API リファレンス」の[ContainerMountPoint](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_ContainerMountPoint.html)」を参照してください。
## 必須コンテナの指定
各インスタンスのコンテナグループごとに、各コンテナをEssential (必須) または Non-essential (非必須) として指定します。インスタンス単位のコンテナグループには、少なくとも 1 つの必須コンテナが必要です。必須コンテナは、コンテナグループの重要な処理を担当します。必須コンテナは、常に稼働していることが期待されます。失敗すると、コンテナグループ全体が再起動します。
`ContainerDefinition`プロパティ`Essential`を各コンテナの true または false に設定します。
## ネットワーク接続を構成する
外部トラフィックがコンテナフリート内の任意のコンテナに接続できるように、ネットワークアクセスをカスタマイズできます。例えば、ゲームクライアントがゲームに参加できるようにするには、ゲームサーバープロセスを実行するコンテナに対してネットワーク接続を構成する必要があります。ゲームクライアントは、ポートと IP アドレスを使用してgameサーバーに接続します。
コンテナフリートでは、クライアントとサーバー間の接続は直接には行われません。内部的には、コンテナ内のプロセスは*コンテナポート*で待ち受けます。外部からのトラフィックは、*接続ポート*を使用してフリート内のインスタンスに接続されます。Amazon GameLift Servers は、内部コンテナポートと外部公開ポートのマッピングを管理し、トラフィックがインスタンス上の正しいプロセスにルーティングされるようにします。
Amazon GameLift Servers は、ネットワーク接続に対する追加の制御レイヤーを提供します。各コンテナフリートには*受信許可*設定があり、外部公開ポートごとのアクセス制御が可能です。例えば、すべての接続ポートの許可を無効にして、フリート内のコンテナへのアクセスを完全に遮断することも可能です。
フリートの受信許可、接続ポート、およびコンテナポートを更新できます。
**警告**
カスタムの InstanceConnectionPortRange または InstanceInboundPermissions を指定した場合、Amazon GameLift Servers はフリートでこれらの値を管理しなくなります。意図しない動作を避けるために、両方のフィールドを設定する必要があります。
**コンテナポート範囲の設定**
各コンテナ定義の一部として、コンテナポート範囲を設定します。これは、コンテナグループ定義に必要なパラメータです。外部アクセスが必要なすべての同時実行プロセスに対応できるよう、十分な数のポートを設定する必要があります。一部のコンテナにはポートが不要な場合もあります。
ゲームサーバーコンテナには、同時に実行される各ゲームサーバープロセスに対して、それぞれポートが必要です。ゲームサーバープロセスは、割り当てられたポートをリッスンし、その情報を Amazon GameLift Servers に報告します。
**接続ポート範囲の設定**
接続ポートのセットを使用して コンテナフリート を構成します。接続ポートは、コンテナを実行しているフリートインスタンスへの外部アクセスを提供します。Amazon GameLift Servers は接続ポートを割り当て、必要に応じてコンテナポートにマッピングします。
デフォルトでは、Amazon GameLift Servers がすべてのコンテナグループに必要なポート数を計算し、それに応じたポート範囲を設定します。コンテナ グループ定義に更新をデプロイすると更新される、Amazon GameLift Servers によって計算された値を使用することを強く推奨します。接続ポート範囲をカスタマイズする必要がある場合は、次のガイダンスを使用します。
コンテナフリートを作成する際は、接続ポート範囲を定義します ([ContainerFleet:InstanceConnectionPortRange ](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_ContainerFleet.html)を参照)。フリート内のすべてのコンテナグループに含まれるコンテナポートにマッピングできるよう、ポート範囲に十分な数のポートが含まれていることを確認します。必要な最小接続ポートを計算するには、次の式を使用します。
`[Total number of container ports defined for containers in the game server container group] * [Number of game server container groups per instance] + [Total number of container ports defined for containers in the per-instance container group]`
ベストプラクティスとして、接続ポートの最小数を 2 倍にします。
接続ポート数は、インスタンスあたりのゲームサーバーコンテナグループの数を制限する可能性があります。フリートに、インスタンスごとに1つのゲームサーバーコンテナグループしか対応できないだけの接続ポートしかない場合、たとえインスタンスに複数のゲームサーバーコンテナグループを実行できる十分な計算リソースがあっても、Amazon GameLift Servers は 1 つのゲームサーバーコンテナグループしかデプロイしません。
**受信許可を設定する**
受信許可は、受信トラフィックに対して開放する接続ポートを指定することで、コンテナフリートへの外部アクセスを制御します。この設定を使用して、必要に応じてフリートのネットワークアクセスをオンまたはオフにできます。
デフォルトでは、Amazon GameLift Servers がすべてのコンテナグループに必要なポート数を計算し、それに応じたポート範囲を設定します。コンテナ グループ定義に更新をデプロイすると更新される、Amazon GameLift Servers によって計算された値を使用することを強く推奨します。接続ポート範囲をカスタマイズする必要がある場合は、次のガイダンスを使用します。
コンテナフリートを作成するときは、一連のインバウンド権限を定義します（[ContainerFleet::InstanceInboundPermissions を参照）。](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_ContainerFleet.html)受信許可ポートは、フリートの接続ポート範囲と一致している必要があります。
コンテナポートは InstanceConnectionPortRange からランダムに選ばれるため、セッション接続を確実に行うには、InstanceConnectionPortRange に含まれるすべてのポートがInstanceInboundPermissions によって許可されている必要があります。
**シナリオの例**
この例では、3 つのネットワーク接続プロパティをどのように設定するかを示します。
+ フリートのゲームサーバーコンテナグループには、1つのコンテナがあり、1 つのゲームサーバープロセスを実行しています。
ゲームサーバーコンテナグループ定義では、このコンテナの `PortConfiguration` パラメータを次のように設定します。
```
"PortConfiguration": {
"ContainerPortRanges": [ { "FromPort": 10, "ToPort": 20, "Protocol": "TCP"} ] }
```
+ フリートには、1 つのコンテナを持つインスタンス単位のコンテナグループもあります。このグループには、ネットワークアクセスを必要とするプロセスが1つ含まれています。インスタンス単位のコンテナ定義では、このコンテナ の `PortConfiguration` パラメータを次のように設定します。
```
"PortConfiguration": {
"ContainerPortRanges": [ { "FromPort": 25, "ToPort": 25, "Protocol": "TCP"} ] }
```
+ フリートでは、1 インスタンスあたり20個のゲームサーバーコンテナグループが構成されています。この情報に基づいて、必要な接続ポート数を次の計算式で求めることができます。
+ 最小: **21 ポート** 〔1 ゲームサーバーコンテナ port × インスタンスあたり 20 ゲームサーバーコンテナ groups ＋ 1 per-instance コンテナ ポート〕
+ ベストプラクティス: **42 ポート** [最小ポート数 x 2]
コンテナフリートを作成するときは、`InstanceConnectionPortRange` パラメータを次のように設定します。
```
"InstanceConnectionPortRange": { "FromPort": 1010, "ToPort": 1071 }
```
+ 使用可能なすべての接続ポートへのアクセスを許可したいと考えています。コンテナフリートを作成するときは、`InstanceInboundPermissions` パラメータを次のように設定します。
```
"InstanceInboundPermissions": [
{"FromPort": 1010, "ToPort": 1071, "IpRange": "10.24.34.0/23", "Protocol": "TCP"} ]
```
## コンテナのヘルスチェックを設定する
コンテナは、ターミナル障害が発生して実行が停止すると、自動的に再起動します。コンテナが必須 (Essential) と見なされている場合、そのコンテナが停止するとコンテナグループ全体が再起動されます。
すべてのゲームサーバーコンテナは、自動的に必須コンテナとして扱われます。サポートコンテナも必須に設定できますが、その場合は正常性を報告する仕組みが必要です。必須でないサポートコンテナにも、ヘルスチェックを設定できます。
コンテナの正常性を評価するための、独自のカスタム基準を定義し、その基準を検証するためにヘルスチェックを使用できます。コンテナのヘルスチェックは、Docker コンテナイメージまたはコンテナ定義内に記述できます。コンテナ定義にヘルスチェックを設定すると、コンテナイメージ内の設定は上書きされます。
コンテナ ヘルスチェックには、次の `SupportContainerDefinition` プロパティを設定します。
+ `Command` — コンテナの状態の一部を確認するコマンドを指定します。正常性の基準は、任意に定義できます。コマンドの終了コードは、次のいずれかである必要があります: 1 (異常) または 0 (正常)。
+ `StartPeriod` — ヘルスチェックの失敗カウントを開始するまでの遅延時間を指定します。この遅延により、コンテナはプロセスをブートストラップするための時間を確保できます。
+ `Interval` — ヘルスチェックコマンドを実行する頻度を指定します。コンテナ障害をどのくらい早く検出して解決しますか?
+ `Timeout` — ヘルスチェックコマンドを再試行するまでの成功・失敗の待機時間を設定します。ヘルスチェックコマンドの完了に必要な時間はどれくらいですか？
+ `Retries` — 失敗を登録する前にヘルスチェックコマンドを何回再試行する必要がありますか?
## コンテナの依存関係の設定
各 コンテナグループ内では、コンテナのステータスに基づいて、コンテナ間の依存関係を設定できます。依存関係を設定することで、他のコンテナの状態に応じて、依存先コンテナの起動やシャットダウンのタイミングを制御できます。
依存関係の主なユースケースの 1 つは、コンテナグループのスタートアップおよびシャットダウンの順序を構成することです。
たとえば、コンテナ A を最初に起動し、B や C が起動する前に正常終了させたい場合があります。これを実現するには、まずコンテナBに対してコンテナAへの依存関係を設定します。条件として、コンテナAが正常に完了することを指定します。続けて、同じ条件でコンテナ C にもコンテナ A への依存関係を設定します。スタートアップシーケンスは、シャットダウン時に逆順で実行されます。
## コンテナフリートを設定する
コンテナフリートを作成する際は、以下の設計上の判断項目を考慮してください。これらの判断項目の多くは、コンテナのアーキテクチャと設定内容に依存します。
**フリートをどこにデプロイするかを決定します。**
一般的には、レイテンシーを最小限に抑えるため、プレイヤーに近い地域にデプロイするのが理想です。コンテナフリートは、 がAmazon GameLift Serversサポート AWS リージョン する任意の にデプロイできます。同じゲームサーバーを追加の地理的場所にデプロイする場合は、 AWS リージョン および Local Zones を含むリモートロケーションをフリートに追加できます。マルチロケーションフリートを持つフリートでは、各ロケーションで個別に容量を調整できます。サポートされているフリートのロケーションの詳細については、「[Amazon GameLift Servers サービスロケーション](gamelift-regions.md)」を参照してください。
ネットワークのレイテンシーデータを収集するには、[UDP ping ビーコン](reference-udp-ping-beacons.md) を使用して、各地域のレイテンシーを測定し、プレイヤーデバイスとフリート候補ロケーション間の遅延を予測することを検討してください。これらの特別なエンドポイントは、従来の ICMP ping の代わりに UDP メッセージを受け入れるため、正確なレイテンシー測定が可能になり、最適なフリートロケーションの選択に役立ちます。
**フリートで使用するインスタンスタイプとサイズを選択する**
Amazon GameLift Servers は、幅広い Amazon EC2 インスタンスタイプをサポートしており、これらはすべてコンテナフリートで利用できます。利用可能なインスタンスタイプと料金は、ロケーションによって異なります。サポートされているインスタンスタイプのリストは、Amazon GameLift Servers コンソールの「**リソース、インスタンス、およびサービスのクォータ**」内で、ロケーション別にフィルタリングして確認できます。
インスタンスタイプを選択するときは、まずインスタンスファミリーを検討してください。インスタンスファミリでは、CPU、メモリ、ストレージ、ネットワーキング機能をさまざまな組み合わせで提供しています。[EC2 インスタンスファミリ](https://aws.amazon.com/ec2/instance-types/)の詳細情報を取得します。各ファミリー内では、さまざまなインスタンスサイズを選択できます。インスタンスサイズを選択するときは、次の点を考慮してください。
+ ワークロードをサポートできる最小インスタンスサイズを教えてください。この情報を活用して、小さすぎるインスタンスタイプを除外しましょう。
+ コンテナアーキテクチャに適したインスタンスタイプサイズは何ですか？ 理想的には、ゲームサーバーコンテナグループの複数のコピーを無駄なスペースを最小限に抑えて収容できるサイズを選択します。
+ ゲームに適したスケーリングの粒度 (細かさ) はどれくらいですか？ フリートの容量スケーリングにはインスタンスの追加や削除が伴い、各インスタンスは特定の数のゲームセッションをホストする能力を持ちます。インスタンスごとに、どれだけの容量を追加・削除したいかを検討しましょう。プレイヤーの需要が分単位で数千規模に変動する場合は、数百から数千のゲームセッションをホストできる大規模インスタンスの利用が有効です。一方で、小さなインスタンスタイプを用いることで、より細かくスケーリング制御ができる場合もあります。
+ インスタンスサイズによって、コスト削減の可能性はありますか？ 一部のインスタンスタイプでは、利用可能性によりロケーションごとにコストが異なることがあります。
**その他のフリート設定を構成する**
コンテナフリートを設定するときは、次のオプション機能を使用できます。
+ 他の AWS リソースにアクセスするようにゲームサーバーを設定します。「[Amazon GameLift Servers ホストされたゲームサーバーを他の AWS リソースに接続する](gamelift-sdk-server-resources.md)」を参照してください。
+ スケールダウン時に、アクティブなプレイヤーが参加しているゲームセッションが途中終了しないように保護します。
+ 一定期間内に 1 人のユーザーがフリート上で作成できるゲームセッション数を制限します。
# スポットフリートによるゲームホスティングコストの削減
Amazon GameLift Servers マネージドホスティングを使用してマルチプレイヤーゲームサーバーをホストする場合、スポットインスタンスはオンデマンドインスタンスの代わりにコスト効率の高い方法を提供できます。スポット料金モデルは、オンデマンドと同じハードウェアとパフォーマンスを提供しますが、コストを大幅に削減できる可能性があります (最大 70～90%)。ただし、 が容量を戻す AWS 必要がある場合、2 分間の中断通知でこれらのインスタンスを再利用できます。
Amazon GameLift Servers は、ゲームサーバーホスティングの中断リスクを軽減します。Amazon GameLift Servers は、スポットインスタンスタイプの中断の可能性を予測し、すべてのインスタンスにゲームセッションを危険にさらすことを回避します。まれな中断が発生した場合、通知によりプレイヤーのゲームセッションを正常に終了できます。
## Amazon GameLift Servers がスポットフリートと連携する方法
ゲームホスティング用にスポットフリートを設定すると、Amazon GameLift Servers はゲームホスティングの実行可能性についてスポットフリートのインスタンスタイプと場所を継続的に評価します。
+ スポット実行可能性アルゴリズムは、スポットインスタンスタイプの最近の可用性パターンと過去の中断率をロケーション別に分析します。
+ この分析に基づいて、Amazon GameLift Servers は、ゲームセッションの中断の可能性が許容できないスポットインスタンスタイプと場所を特定します。以下のアクションを実行します。
+ インスタンスタイプと場所の組み合わせを一時的に無効としてマークします。
+ 新しいゲームセッションを配置するときに、実行不可能なスポットフリートの場所が考慮から除外されます。その結果、ゲームセッションは、ゲームサーバーのホスティングが中断されない可能性が高いスポットフリートのロケーションにのみ配置されます。
+ AWS が既存のインスタンスのスポットフリートの場所を再利用しない場合でもドレインするため、ゲームホスティングに使用できないインスタンスには料金が発生しません。ゲームセッション保護が有効になっている場合、インスタンスはアクティブなゲームセッションが完了した後にのみシャットダウンされます。
+ Amazon GameLift Servers は、ゲームホスティングの実行可能性についてスポットフリートのインスタンスタイプと場所を継続的に再評価します。更新された履歴データに基づいて、以前は実行できなかったインスタンスタイプが再び有効になると、スポットフリートを再度スケールアップでき、Amazon GameLift Servers はそれを使用してゲームセッションの配置を再開します。
## 設計上の考慮事項
スポットフリートを使用するソリューションを設計するときは、次の問題を考慮してください。
+ **ゲームセッションの長さを評価する** - ゲームセッションの平均長は、スポットがゲームに対してどの程度うまく機能するかに影響を与える可能性があります。ゲームセッションが短いほど、切り替えが速くなり、最新の履歴データに基づいて実行可能なインスタンスタイプでゲームセッションが実行されます。長いゲームセッションは、最新の実行可能性データを評価しないまま同じインスタンスタイプで実行され続けるため、時間の経過とともに中断するリスクが高まります。
+ **インスタンスタイプの可用性を評価する** - すべてのフリートロケーションがすべてのインスタンスタイプをスポットとして提供するわけではありません。スポットフリートのインスタンスタイプを選択するときは、Amazon GameLift Servers コンソールフリート作成ツールを使用して、必要な場所にスポットインスタンスタイプを見つけることができます。このツールを使用すると、フリートロケーションを選択し、それらのロケーションでのインスタンスタイプの可用性を表示できます。
+ **マルチロケーションスポットフリートの作成** - 複数のロケーションでスポットフリートを作成できます。単一のマルチロケーションスポットフリートは、同じインスタンスタイプのインスタンスを複数の AWS リージョン またはローカルゾーンにデプロイします。スポット実行可能性アルゴリズムは、インスタンスタイプと場所の両方に基づいて実行可能性を評価します。スポットフリートの場所が実行不可能と評価された場合、フリート内の他の場所には影響しません。この場所はゲームセッションのホストに使用できます。
+ **スポットフリートの多様性を持つキューを作成する** - ゲームホスティングにスポットフリートを使用している場合は、ゲームセッションプレイスメントキューを設定する必要があります。新しいゲームセッションリクエストごとに、キューは利用可能なゲームホスティングリソースを検索し、最適なオプションを選択します。スポットフリートでは、ロケーションやインスタンスタイプが異なる複数のフリートを検索できるキューが必要です。また、バックアップ容量として少なくとも 1 つのオンデマンドフリートを含める必要があります。さまざまな配置オプションを提供する適切に設計されたマルチフリートキューは、中断、速度低下、停止に対して高い耐障害性を備えます。スポットのキューの設計に関するその他のガイダンスについては、[スポットインスタンスのキューの設計](spot-tasks.md) を参照してください。
+ **中断を適切に処理する** - スポットの中断時にプレイヤーへの影響を最小限に抑えるようにゲームサーバーを設定します。がスポットインスタンス AWS を再利用すると、 はサーバー SDK コールバック関数 を使用して、影響を受けるすべてのサーバープロセスに終了通知をAmazon GameLift Servers渡します`onProcessTerminate()`。ゲームセッションを適切に終了するためには、ゲームにこのコールバックを実装する必要があります。詳細については、「[サーバープロセスのシャットダウン通知に応答する](gamelift-sdk-server-api.md#gamelift-sdk-server-terminate)」を参照してください。
**注記**
AWS は、インスタンスを再利用する前に通知を提供するよう努めますが、警告が到着する前に がスポットインスタンスを AWS 再利用する可能性があります。ゲームサーバーが予期しない中断を適切に処理できるように準備しておきます。
+ **バックアップフリートの自動スケーリングを設定して、スポットの中断中にサービスを維持します。**ターゲット追跡の自動スケーリングは容量バッファを維持し、需要に応じて自動的にスケーリングします。自動スケーリングでは、バックアップフリート (スポットまたはオンデマンド) は、より多くのゲームセッションリクエストの受信を開始するたびに容量の増加を開始します。
スポットフリートが実行不能になったときに失われた容量をすばやく置き換えるために、カスタムスケーリングメカニズムは使用可能なキューとフリートのメトリクスを使用してバックアップフリートの迅速なスケールアウトを開始できます。スポットフリートが `FirstChoiceOutOfCapacity`、`FirstChoiceNotViable`、`PercentAvailableGameSessions` などのメトリクスで実行不能になったときを検出します。最近の `PlacementsStarted` メトリクスデータを分析して、代替容量のニーズを見積もります。即時の需要に対応するためにバックアップフリートをスケーリングすると、通常の自動スケーリングが引き継がれます。
+ **FlexMatch との統合** - ソリューションが FlexMatch マッチメーカーを使用している場合、スポットフリートに特別な要件はありません。スポットフリートでキューを使用するようにマッチメーカーを設定できます。Amazon GameLift Servers は、新しいゲームセッションを配置する場合や既存のゲームセッションで空のプレイヤースロットをバックフィルする場合など、スポットフリートとオンデマンドフリート間でマッチプレイスメントを自動的に優先します。
# マネージド Amazon GameLift Servers でのゲームサーバーランタイム設定の最適化
インスタンスごとに複数のゲームサーバープロセスを実行するようにマネージド EC2 フリートのランタイム設定を定義できます。これにより、ホスティングリソースがより効率的に使用されます。
## フリートが複数のプロセスを管理する方法
Amazon GameLift Servers はフリートのランタイム設定を使用して、各インスタンスで実行するプロセスのタイプと数を決定します。1 つのランタイム設定には、少なくとも 1 個のゲームサーバー実行可能ファイルを表す 1 つのサーバープロセス設定が含まれます。追加のサーバープロセス設定を定義して、ゲームに関連する他のタイプのプロセスを実行することができます。各サーバープロセス設定には、以下の情報が含まれています。
+ ゲームビルドの実行可能ファイルのファイル名とパス。
+ (オプション) 起動時にサーバープロセスに渡すパラメータ。
+ 同時に実行するプロセスの数。
フリートのインスタンスがアクティベートされると、ランタイム設定で定義された一連のサーバープロセスが起動します。複数のプロセスで、Amazon GameLift Servers は各プロセスの起動をずらします。サーバープロセスの存続時間は限られています。プロセスが終了すると、Amazon GameLift Servers は新しいプロセスを起動して、ランタイム設定で定義されているサーバープロセスの数とタイプを維持します。
ランタイム設定は、サーバープロセス設定を追加、変更、削除することでいつでも変更できます。各インスタンスは定期的にフリートのランタイム設定の更新をチェックし、変更を実装します。Amazon GameLift Servers がランタイム設定の変更を適用する方法は以下のとおりです。
1. インスタンスは Amazon GameLift Servers に最新バージョンのランタイム設定についてリクエストを送信します。
1. インスタンスはアクティブなプロセスを最新のランタイム設定と比較し、次の操作を行います。
+ 更新されたランタイム設定によりサーバープロセスタイプが削除された場合、このタイプのアクティブなサーバープロセスは、終了するまで実行され続けます。インスタンスはこれらのサーバープロセスを置き換えるものではありません。
+ 更新されたランタイム設定によりサーバープロセスタイプの同時プロセス数が減る場合、このタイプの過剰なサーバープロセスは、終了するまで実行され続けます。インスタンスがこれらのサーバープロセスを置き換えることはありません。
+ 更新されたランタイム設定により新しいタイプのサーバープロセスが追加されるか、既存のタイプの同時プロセスが増える場合、インスタンスは新しいサーバープロセスを Amazon GameLift Servers の最大数まで開始します。この場合、インスタンスは、既存のプロセスが終了したときに新しいサーバープロセスを起動します。
## フリートを複数のプロセスに合わせて最適化する
フリートで複数のプロセスを使用するには、次の操作を実行します。
+ フリートにデプロイしようとするゲームサーバー実行可能ファイルを含む[ビルドを作成](gamelift-build-intro.md)し、Amazon GameLift Servers にそのビルドをアップロードします。ビルド内のすべてのゲームサーバーは同じプラットフォーム上で実行され、サーバー SDK for Amazon GameLift Servers を使用する必要があります。
+ ひとつ以上のサーバープロセス設定と複数の同時プロセスのあるランタイム設定を作成します。
+ ゲームクライアントを AWS SDK バージョン 2016-08-04 以降と統合します。
フリートのパフォーマンスを最適化するには、次の操作を実行することをお勧めします。
+ Amazon GameLift Servers がプロセスを効率よくリサイクルできるよう、サーバープロセスのシャットダウンシナリオに適切に対応します。例えば、次のようになります。
+ サーバー API `ProcessEnding()` を呼び出すシャットダウン手順をゲームサーバーコードに追加する。
+ Amazon GameLift Servers からの終了リクエストを適切に処理するために、`OnProcessTerminate()` コールバック関数をゲームサーバーコードに実装する。
+ Amazon GameLift Servers が異常なサーバープロセスをシャットダウンし、再起動することを確認します。ゲームサーバーコードに `OnHealthCheck()` コールバック関数を実装し、サーバーのヘルスステータスを Amazon GameLift Servers に報告します。Amazon GameLift Servers は、3 回連続で異常と報告されたサーバープロセスを自動的にシャットダウンします。`OnHealthCheck()` を実装しない場合、Amazon GameLift Servers は、プロセスが通信への応答に失敗しない限り、サーバープロセスが正常であるとみなします。
## インスタンスごとのプロセスの数を選択する
インスタンスで実行する同時プロセスの数を決定するときは、以下に注意してください。
+ Amazon GameLift Servers は各インスタンスの[同時プロセスの最大数](https://docs.aws.amazon.com/general/latest/gr/gamelift.html#limits_gamelift)を制限します。フリートのサーバープロセス設定のすべての同時プロセスの合計数がこのクォータを超えることはできません。
+ 許容可能なパフォーマンスレベルを維持するため、Amazon EC2 インスタンスタイプによっては、同時に実行できるプロセスの数が制限される場合があります。ゲームでさまざまな設定を試して、選択したインスタンスタイプにとって適切なプロセス数を見つけます。
+ Amazon GameLift Servers は、設定した合計数を超える同時プロセスを実行しません。つまり、以前のランタイム設定から新しい設定への移行は段階的に行われる可能性があります。
# Amazon GameLift Servers エージェントの操作
Amazon GameLift Servers エージェントは、Amazon GameLift Servers フリートでのゲームサーバープロセスの実行を監督します。エージェントはフリート内の各コンピューティングにデプロイされ、コンピューティングの自動プロセス管理、ホスティング管理、ログ記録を提供します。エージェントを使用するには、ゲームサーバービルドをバージョン 5.x 以降用のサーバー SDK for Amazon GameLift Servers と統合する必要があります。
Amazon GameLift Servers エージェントは、マネージド EC2 フリートではない Amazon GameLift Servers フリートで外部使用できます。(マネージド EC2 フリートは、エージェントのタスクを自動的に処理します。) エージェントの有無にかかわらず、Anywhere フリートを含む Amazon GameLift Servers フリートを実行できます。エージェントがない場合、必要なタスクを完了するための代替ソリューションを提供する必要があります。
コンピューティングにデプロイする場合は、ゲームサーバープロセスを開始する前に Amazon GameLift Servers エージェントを起動する必要があります。起動時に、エージェントは次のタスクを完了します。
+ [RegisterCompute](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_RegisterCompute.html) API を使用して、コンピューティングを Amazon GameLift Servers Anywhere フリートに登録します。
+ [GetComputeAuthToken](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_GetComputeAuthToken.html) API を呼び出して認証トークンを取得し、コンピューティングで実行されているサーバープロセスで使用できるように保存します。
+ コンピューティングの WebSocket URL 環境変数を設定し、Amazon GameLift Servers サービスへの WebSocket 接続を確立します。
+ Amazon GameLift Servers サービスからフリートのランタイム設定の最新バージョンを要求します。
+ ランタイム設定手順に従って、サーバープロセスを開始および停止します。
Amazon GameLift Servers エージェントのソースコードおよびビルドの手順は、[Amazon GameLift Servers エージェント](https://github.com/aws/amazon-gamelift-agent) GitHub で入手できます。
## エージェントについて
Amazon GameLift Servers エージェントは、フリートに対して次のタスクを処理するように設計されています。
**プロセス管理**
+ ランタイム手順で定義されているように、新しいサーバープロセスを開始します。エージェントは、エージェントにデプロイされたカスタムランタイム設定を使用する場合があります。また、`RuntimeConfiguration` をフリート定義の一環として指定することもできます。このアプローチの利点として、いつでもフリートのランタイム設定を変更できることが挙げられます。エージェントは、定期的に Amazon GameLift Servers サービスから更新されたランタイム設定を要求します。
+ サーバープロセスのアクティベーションを監視し、時間内にアクティブ化されない場合はプロセスを終了します。
+ ハートビートを Amazon GameLift Servers に送信します。エージェントがハートビートを送信できない場合、コンピューティングは「古い」としてマークされる場合があります。
+ サーバープロセスが終了したら、Amazon GameLift Servers に報告します。Amazon GameLift Servers はこの情報を使用して、ゲームセッション配置のゲームサーバーの可用性をモニタリングします。
+ 以下を含むサーバープロセスのフリートイベントを出力します。
+ `SERVER_PROCESS_INVALID_PATH`: ゲームサーバープロセスの起動パラメータが正しく設定されていません。
+ `SERVER_PROCESS_TERMINATED_UNHEALTHY`: ゲームサーバープロセスが、アクティブ化されてから 3 分以内に有効なヘルスチェックを報告しなかったため、終了しました。
+ `SERVER_PROCESS_FORCE_TERMINATED`: `OnProcessTerminate()` が 30 秒以内に送信された後、ゲームサーバープロセスが正常に終了しませんでした。
+ `SERVER_PROCESS_CRASHED`: 何らかの理由でゲームサーバープロセスがクラッシュしました。
**コンピューティング管理**
+ Amazon GameLift Servers サービスからメッセージを受信して、コンピューティングをシャットダウンします。
+ Amazon GameLift Servers によって終了されることをコンピューティングにプロンプトします。
**ログ記録**
+ AWS アカウントの Amazon S3 バケットにログをアップロードします。
# エイリアスを使用して Amazon GameLift Servers フリートの指定を抽象化する
Amazon GameLift Servers *エイリアス*は、ホスティング先を抽象化するために使用されます。ホスティング先は、Amazon GameLift Servers に、プレイヤー用に新しいゲームセッションをホスティングするために利用できるリソースを検索する場所を伝えます。エイリアスは、次のシナリオで有用です。
+ ゲームセッション配置にマルチフリートキューを使用しない場合、Amazon GameLift Serversフリート ID を指定して新しいゲームセッションをリクエストします。ゲームの開始から停止まで、サーバービルドの更新やホスティングハードウェアとオペレーティングシステムの更新、パフォーマンスの問題の解決のために何度もフリートを入れ替えることになります。エイリアスを使用してフリート ID を抽象化することで、プレイヤートラフィックを既存のフリートから新しいフリートにシームレスに切り替えることができます。
+ ゲームクライアントが新しいゲームセッションをリクエストした際に、セッションを作成する以外のことを行う場合。例えば、古いクライアントを使用しているプレイヤーをアップデートウェブサイトに誘導する場合などです。
エイリアスはルーティング戦略を指定する必要があります。ルーティング戦略には 2 種類あります。*シンプル*ルーティング戦略は、プレイヤートラフィックを指定されたフリート ID にルーティングします。このフリート ID を更新することでトラフィックをリダイレクトできます。*ターミナル*ルーティング戦略は、新しいゲームセッションを作成する代わりに、メッセージをクライアントに渡します。エイリアスのルーティング戦略はいつでも変更できます。
ゲームセッション配置にキューを使用する場合、フリートを入れ替える際にトラフィックをリダイレクトするためのエイリアスは必要ありません。キューを使用すれば、新しいフリートを追加し、古いフリートを削除するだけで済みます。新しいゲームセッションリクエストは新しいフリートを使用して自動的に実行されるため、このアクションはプレイヤーからは見えません。既存のゲームセッションにも影響しません。キューの宛先は、フリート ID またはエイリアスを使用して識別できます。
**Topics**
+ [Amazon GameLift Servers エイリアスの作成](aliases-creating.md)
# Amazon GameLift Servers エイリアスの作成
このトピックでは、ゲームセッションの配置で使用する Amazon GameLift Servers エイリアスの作成方法を説明します。
**エイリアスを作成するには**
エイリアスは、Amazon GameLift Servers コンソールまたは AWS Command Line Interface (AWS CLI) を使用して作成できます。
------
#### [ Console ]
[[Amazon GameLift Servers コンソール]](https://console.aws.amazon.com/gamelift/) のナビゲーションペインを使用して、**[エイリアス]** ページを開きます。
1. **[エイリアスを作成]** を選択します。
1. エイリアスの **[名前]** を入力します。エイリアスの一覧を確認する際にわかりやすいように、エイリアス名には意味のある特徴を持たせることをお勧めします。
1. 必要に応じてエイリアスの **[説明]** を入力します。
1. エイリアスの **[ルーティング戦略]** を選択します。
1. **[シンプル]** ルーティング戦略を選択した場合は、このエイリアスに関連付けるフリート ID をリストから選択します。リストには、現在選択されている AWS リージョンのすべてのフリートが含まれます。エイリアスはフリートと同じリージョンに作成する必要があります。
1. **[ターミナル]** ルーティング戦略を選択した場合は、ゲームセッションリクエストに応じて Amazon GameLift Servers がゲームクライアントに返す文字列値を入力します。ターミナルエイリアスを持つリクエストは、メッセージが埋め込まれた例外をスローします。
1. (オプション) エイリアスリソースに **[タグ]** を追加します。タグはそれぞれ、1 つのキーとオプションの 1 つの値で設定されており、どちらもお客様側が定義します。タグを割り当てることで、AWS リソースを目的、所有者、環境など有用な方法で分類することができます。追加するタグごとに **[新しいタグを追加]** を選択します。
1. 新しいフリートをデプロイする準備ができたら、**[作成]** を選択します。
------
#### [ AWS CLI ]
[https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-alias.html](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-alias.html) コマンドを使用してエイリアスを作成します。Amazon GameLift Servers は現在のデフォルト AWS リージョン にエイリアスリソースを作成します (または、--region タグを追加して別の AWS リージョン を指定することもできます)。
少なくとも、エイリアス名とルーティング戦略を含めます。シンプルルーティング戦略では、エイリアスと同じリージョンにあるフリートの ID を指定します。ターミナルルーティング戦略には、メッセージ文字列を指定します。
------