本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 自訂您的遊戲託管解決方案
透過基本遊戲託管解決方案，使用下列主題來自訂和增強它，以改善玩家體驗、最佳化成本並新增進階功能。本節涵蓋由主要影響的元件組織的各種自訂選項。選擇最適合您遊戲需求和玩家基礎的自訂項目。
**主題**
+ [遊戲伺服器建置自訂](customize-game-server-builds.md)
+ [將Amazon GameLift Servers託管遊戲伺服器連接到其他 AWS 資源](gamelift-sdk-server-resources.md)
+ [讓您的遊戲伺服器存取Amazon GameLift Servers機群資料](gamelift-sdk-server-fleetinfo.md)
+ [設定 的 VPC 對等互連 Amazon GameLift Servers](vpc-peering.md)
+ [玩家工作階段和配對自訂](customize-player-sessions-matchmaking.md)
+ [產生玩家 IDs](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 執行個體的佇列](spot-tasks.md)
+ [託管資源自訂](fleets-design.md)
+ [選擇受管機群的運算資源](gamelift-compute.md)
+ [自訂Amazon GameLift Servers容器機群](containers-design-fleet.md)
+ [使用 Spot 機群降低遊戲託管成本](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 角色
在此步驟中，您會建立具有一組許可的 IAM 角色，以控制對 AWS 資源的存取，以及授予使用角色許可Amazon GameLift Servers權限的信任政策。
如需如何設定 IAM 角色的指示，請參閱 [設定 的 IAM 服務角色 Amazon GameLift Servers](setting-up-role.md)。建立許可政策時，請選擇應用程式需要使用的特定服務、資源和動作。最佳實務是盡可能限制許可的範圍。
建立角色之後，請記下角色的 Amazon Resource Name (ARN)。您需要在機群建立期間的角色 ARN。
### 修改應用程式以取得登入資料
在此步驟中，您將應用程式設定為取得 IAM 角色的安全登入資料，並在與 AWS 資源互動時使用它們。請參閱下表，以根據 (1) 應用程式類型，以及 (2) 遊戲用來與 通訊的伺服器 SDK 版本，決定如何修改您的應用程式Amazon GameLift Servers。
| | 遊戲伺服器應用程式 | 其他應用程式 |
| --- | --- | --- |
| **使用伺服器 SDK 5.x 版** | `GetFleetRoleCredentials()` 從遊戲伺服器程式碼呼叫伺服器 SDK 方法。 | 將程式碼新增至應用程式，從機群執行個體上的共用檔案提取登入資料。 |
| **使用伺服器 SDK 第 4 版或更早版本** | `[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)` 使用角色 ARN 呼叫 AWS Security Token Service (AWS STS)。 | `[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)` 使用角色 ARN 呼叫 AWS Security Token Service (AWS STS)。 |
**注意**
對於容器機群，`FleetRoleArn`登入資料會注入每個容器。您的應用程式可以使用預設 AWS 登入資料提供者來存取這些登入資料。您仍然可以呼叫 `GetFleetRoleCredentials()`，這會傳回相同的登入資料。這些機群角色登入資料只能在容器內存取。
對於與伺服器 SDK 5.x 整合的遊戲，此圖說明部署的遊戲組建中的應用程式如何取得 IAM 角色的登入資料。
![\[遊戲可執行檔呼叫 GetFleetRoleCredentials()。其他檔案使用本機儲存的共用登入資料。\]](http://docs.aws.amazon.com/zh_tw/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"
```
**範例：設定 CloudWatch 代理程式以收集Amazon GameLift Servers機群執行個體的指標**
如果您想要使用 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 對等互連，您可以在機群的 VPC 與其他 AWS 資源之間建立直接網路連線。
Amazon GameLift Servers 簡化為遊戲伺服器設定 VPC 對等互連的程序。它會處理對等請求、更新路由表，並視需要設定連線。如需如何為遊戲伺服器設定 VPC 對等互連的說明，請參閱 [設定 的 VPC 對等互連 Amazon GameLift Servers](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"
}
```
# 設定 的 VPC 對等互連 Amazon GameLift Servers
本主題提供如何在您的 Amazon GameLift Servers 託管遊戲伺服器和其他非 Amazon GameLift Servers 資源間設定 VPC 對等互連的指導。使用 Amazon Virtual Private Cloud (VPC) 對等連線，讓您的遊戲伺服器能夠直接和私下與您的其他 AWS 資源通訊，例如 Web 服務或儲存庫。您可以使用在 上執行的任何資源建立 VPC 對等互連， AWS 並由您有權存取 AWS 的帳戶管理。
**注意**
VPC 對等互連是進階功能。若要了解讓遊戲伺服器直接和私下與其他 AWS 資源通訊的偏好選項，請參閱 [將Amazon GameLift Servers託管遊戲伺服器連接到其他 AWS 資源](gamelift-sdk-server-resources.md)。
如果您已經熟悉 Amazon VPCs和 VPC 對等互連，請了解與Amazon GameLift Servers遊戲伺服器的對等互連設定有些不同。您無法存取包含遊戲伺服器的 VPC，其由 Amazon GameLift Servers服務控制，因此您無法直接請求 VPC 對等互連。您會改為先授權 VPC 使用非 Amazon GameLift Servers 資源的權利，以接受來自 Amazon GameLift Servers 服務的對等互連請求。然後觸發 Amazon GameLift Servers 以請求您剛授權的 VPC 對等。Amazon GameLift Servers 會處理建立對等連線、設定路由表以及設定連線的任務。
## 為現有機群設定 VPC 對等互連
1.
**取得 AWS 帳戶 ID (s) 和登入資料。**
您需要下列 AWS 帳戶的 ID 和登入憑證。您可以登入 [AWS 管理主控台](https://console.aws.amazon.com/)並檢視您的帳戶設定來尋找帳戶 AWS IDs。若要取得登入資料，請前往 IAM 主控台。
+ AWS 用來管理Amazon GameLift Servers遊戲伺服器的 帳戶。
+ AWS 用來管理非Amazon GameLift Servers 資源的 帳戶。
如果您為 Amazon GameLift Servers和非Amazon GameLift Servers 資源使用相同的帳戶，則只需要該帳戶的 ID 和登入資料。
1.
**取得每個 VPC 的識別符。**
取得要進行對等互連兩個 VPC 的以下資訊：
+ Amazon GameLift Servers 遊戲伺服器的 VPC – 這是您的Amazon GameLift Servers機群 ID。您的遊戲伺服器會在 EC2 執行個體叢集上的 Amazon GameLift Servers 內部署。叢集會自動置放在其自身擁有的 VPC 內，且該 VPC 是由 Amazon GameLift Servers 服務進行管理。您無法直接存取 VPC，因此會以機群 ID 識別。
+ 非 Amazon GameLift Servers AWS 資源的 VPC – 您可以使用在 上執行的任何資源建立 VPC 對等互連， AWS 並由您有權存取 AWS 的帳戶管理。如果您尚未為這些資源建立 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 的請求，允許其針對非 Amazon GameLift Servers 資源與 VPC 建立與遊戲伺服器之 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。
+ 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 遊戲伺服器的帳戶進行此呼叫。使用下列資訊來識別您要建立對等互連的兩個 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 (s) 和登入資料。**
您需要以下兩個 AWS 帳戶的 ID 和登入憑證。您可以登入 [AWS 管理主控台](https://console.aws.amazon.com/)並檢視您的帳戶設定來尋找帳戶 AWS 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.
**授權 VPC 對等互連使用非 Amazon GameLift Servers 資源的權利。**
當 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 – VPC 與非Amazon GameLift Servers 資源的 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. 遵循[使用 CLI AWS 建立新機群](fleets-creating.md)的指示。包含下列其他參數：
+ *peer-vpc-aws-account-id* – 您用來使用非Amazon GameLift Servers 資源管理 VPC 之帳戶的 ID。
+ *peer-vpc-id* – VPC 與您非Amazon GameLift Servers 帳戶的 ID。
使用 VPC 對等互連參數成功呼叫 [create-fleet](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-fleet.html) 會產生新的叢集及新的 VPC 對等互連請求。會將機群狀態設為**新建**且會起始化機群啟動程序。對等連線請求的狀態是設定為 **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 授權狀態。它可能不存在或可能已過期。
+ 檢查您嘗試建立對等互連的兩個 VPC 區域。如果它們不在同一個區域，則無法建立其對等互連。
+ 兩個 [ VPC 的 CIDR 區塊 （請參閱無效的 VPC 對等互連組態](https://docs.aws.amazon.com/vpc/latest/peering/invalid-peering-configurations.html#overlapping-cidr)) 重疊。 VPCs 指派給對等 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，因此對等連線無法成功。
# 玩家工作階段和配對自訂
玩家工作階段和配對自訂可讓您有機會開發複雜的玩家管理工作流程，包括可協助您提供平衡、吸引多玩家體驗的精細配對系統。
# 產生玩家 IDs
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`。
下列程式碼範例會隨機產生唯一的玩家 IDs：
```
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 ServersRealtime。
FlexMatch 會將配對服務與自訂規則引擎結合在一起。您根據對遊戲有意義的玩家屬性和遊戲模式，設計如何將玩家配對在一起。 FlexMatch管理評估正在尋找遊戲的玩家、與一或多個隊伍組成配對，以及啟動遊戲工作階段來託管配對的螺母和螺絲。
若要使用完整FlexMatch服務，您必須使用佇列設定您的託管資源。 Amazon GameLift Servers使用佇列來尋找跨多個區域和運算類型之遊戲的最佳託管位置。特別是，當遊戲用戶端提供時，Amazon GameLift Servers佇列可以使用延遲資料來放置遊戲工作階段，讓玩家在玩遊戲時體驗到最低的延遲。
如需FlexMatch將配對整合到遊戲中的詳細說明的詳細資訊，請參閱下列[Amazon GameLift ServersFlexMatch開發人員指南](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 執行個體的佇列](spot-tasks.md)
**Topics**
+ [定義佇列的範圍](queues-design-scope.md)
+ [建置多位置佇列](queues-design-multiregion.md)
+ [評估佇列指標](queues-design-metrics.md)
# 定義佇列的範圍
您遊戲的玩家群體可能有一群不應一起玩的玩家。例如，如果您以兩種語言發佈遊戲，則每種語言都應有自己的遊戲伺服器。
若要為您的玩家群體設定遊戲工作階段放置，請為每個玩家客群建立個別的佇列。調整每個佇列的範圍，將玩家放入正確的遊戲伺服器。限制佇列範圍的一些常見方式包括：
+ **依地理位置。**在多個地理區域部署遊戲伺服器時，您可以在每個位置為玩家建立佇列，以減少玩家延遲。
+ **透過建置或指令碼變化。**如果您的遊戲伺服器有多個變化，您可能支援無法在相同遊戲工作階段中玩的玩家群組。例如，遊戲伺服器建置或指令碼可能支援不同的語言或裝置類型。
+ **依事件類型。**您可以建立特殊佇列，為競賽或其他特殊活動的參與者管理遊戲。
## 設計多個佇列
根據您的遊戲和玩家，您可能想要建立多個遊戲工作階段佇列。當您的遊戲用戶端服務請求新的遊戲工作階段時，它會指定要使用的遊戲工作階段佇列。為了協助您決定是否使用多個佇列，請考慮：
+ 遊戲伺服器的變體。您可以為遊戲伺服器的每個變化建立個別佇列。佇列中的所有機群都必須部署相容的遊戲伺服器。這是因為使用佇列加入遊戲的玩家必須能夠在任何佇列的遊戲伺服器上玩遊戲。
+ 不同的玩家群組。您可以自訂 如何根據玩家群組Amazon GameLift Servers放置遊戲工作階段。例如，您可能需要針對特定遊戲模式自訂的佇列，這些模式需要特殊的執行個體類型或執行時間組態。或者，您可能想要特殊佇列來管理賽事或其他活動的置放。
+ 遊戲工作階段佇列指標。您可以根據收集遊戲工作階段置放指標的方式來設定佇列。如需詳細資訊，請參閱[佇列的 Amazon GameLift Servers 指標](monitoring-cloudwatch.md#gamelift-metrics-queue)。
# 建置多位置佇列
我們建議所有佇列採用多位置設計。此設計可以改善置放速度和託管彈性。必須使用多位置設計，才能使用玩家延遲資料，將玩家放入遊戲工作階段，並將延遲降至最低。如果您要建置使用 Spot 執行個體機群的多位置佇列，請遵循 中的指示[使用 Spot 機群降低遊戲託管成本](fleets-spot.md)。
建立多位置佇列的一種方法是將[多位置機群](gamelift-regions.md#gamelift-regions-hosting)新增至佇列。如此一來，佇列就可以將遊戲工作階段放置在任何機群的位置。您也可以新增具有不同組態或主要位置的其他機群以進行備援。如果您使用的是多位置 Spot 執行個體機群，請遵循最佳實務，並包含具有相同位置的隨需執行個體機群。
下列範例概述設計基本多位置佇列的程序。在此範例中，我們使用兩個機群：一個 Spot 執行個體機群和一個隨需執行個體機群。每個機群 AWS 區域 都有下列放置位置：`us-east-1`、`ca-central-1`、 `us-east-2`和 `us-west-2`。
**使用多位置機群建立基本多位置佇列**
1. 選擇要建立佇列的位置。您可以將佇列放置在部署用戶端服務附近的位置，將請求延遲降至最低。在此範例中，我們會在 中建立佇列`us-east-1`。
1. 建立新的佇列，並將多位置機群新增為佇列目的地。目的地順序決定了 Amazon GameLift Servers 放置遊戲工作階段的方式。在此範例中，我們會先列出 Spot 執行個體機群，再列出隨需執行個體機群。
1. 定義佇列的遊戲工作階段置放優先順序。此順序會決定佇列先搜尋可用遊戲伺服器的位置。在此範例中，我們使用預設優先順序。
1. 定義位置順序。如果您未定義位置順序， 會依字母順序Amazon GameLift Servers使用位置。
![\[主控台螢幕擷取畫面，說明範例佇列的位置和目的地順序。\]](http://docs.aws.amazon.com/zh_tw/gameliftservers/latest/developerguide/images/queue-multi-location-1.png)
![\[主控台螢幕擷取畫面，說明範例佇列的置放優先順序和位置順序。\]](http://docs.aws.amazon.com/zh_tw/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`錯誤指標很高，請查看您的 Spot 執行個體機群。當特定執行個體類型的中斷率太高時，Spot 執行個體機群會被視為不可行。若要解決此問題，請將佇列變更為使用具有不同執行個體類型的 Spot 執行個體機群。建議您在每個位置包含具有不同執行個體類型的 Spot 執行個體機群。
# 排定遊戲工作階段放置的優先順序
Amazon GameLift Servers 使用 演算法來判斷佇列目的地的優先順序，並判斷放置新遊戲工作階段的位置。演算法是以一組有序的條件為基礎。您可以使用預設的優先順序，也可以自訂順序。您可以隨時編輯佇列的優先順序。
**預設優先順序**
1. **延遲** – 如果遊戲工作階段置放請求包含玩家的位置特定延遲資料， 會Amazon GameLift Servers計算每個位置的平均玩家延遲，並嘗試將遊戲工作階段放置在平均最低的機群位置。
1. **成本** – 如果請求不包含延遲資料，或多個機群具有相同的延遲，則 會Amazon GameLift Servers評估每個機群的託管成本。機群的託管成本會根據機群類型 (Spot 或隨需）、執行個體類型和位置而有所不同。
1. **目的地** – 如果多個機群具有相同的延遲和成本，則 會根據佇列組態中列出的目的地順序來排定機群的Amazon GameLift Servers優先順序。
1. **位置** – 對於具有多位置機群的佇列，如果所有其他條件相等，則 會根據字母順序排定機群位置的Amazon GameLift Servers優先順序。
## 自訂佇列如何排定遊戲工作階段置放的優先順序
您可以選擇自訂佇列如何排定置放條件的優先順序。佇列會將自訂優先順序套用至其收到的所有遊戲工作階段置放請求。
**注意**
如果您建立自訂優先順序組態，但不包含所有四個條件， 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. 選擇**儲存變更**。
------
#### [ 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`選項來自訂佇列的優先順序。 會Amazon GameLift Servers更新目前預設區域中的佇列 AWS ，或者您可以新增`--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)。
## 依位置排定置放的優先順序
您可以設定佇列，根據地理位置的優先順序清單進行遊戲工作階段置放。Location 是決定佇列如何選擇放置新遊戲工作階段位置的條件之一。根據預設，位置在延遲、成本和目的地之後會排在第四位。
對於遊戲工作階段放置，目的地和位置的含義略有不同：
+ *目的地*是指特定的機群，並包含所有機群的託管資源，無論部署到何處。依目的地排定優先順序時， Amazon GameLift Servers可能會在機群中的任何位置進行置放。多位置受管機群和 Anywhere 機群可以有部署到一或多個位置的託管資源。
+ *位置*是指部署機群託管資源的特定地理位置。機群可以有多個位置，其中可能包括 AWS 區域 Local Zones 或自訂位置 （適用於 Anywhere 機群）。單一位置受管機群有一個位置，且一律為 AWS 區域。多位置受管機群具有主要區域，並且可以有遠端位置。Anywhere 機群有一或多個自訂位置。
依位置排定置放的優先順序時， Amazon GameLift Servers會尋找任何包含優先順序位置的佇列目的地，並搜尋可用的託管資源。如果有多個具有優先順序位置的目的地， Amazon GameLift Servers會移至下一個優先順序條件 （成本、延遲、目的地）。
有多種方式可以影響佇列位置的優先順序
+ 設定佇列如何處理所有遊戲工作階段置放請求：
+ **將優先順序組態新增至佇列。**佇列的優先順序組態包含位置的排序清單。您可以指定一或多個要排定優先順序的位置。此清單不會排除任何位置，只會告訴 先尋找可用託管資源Amazon GameLift Servers的位置。排序位置清單的常見用途是當您想要將大多數流量輸送至一或多個特定地理位置，並使用其他位置做為備份容量時。透過呼叫 [UpdateGameSessionQueue](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_UpdateGameSessionQueue.html) 新增優先順序組態。
+ **將篩選條件組態新增至佇列。**篩選條件組態是佇列的允許清單。它會Amazon GameLift Servers告知 在尋找可用的託管資源時忽略不在清單中的任何位置。篩選條件組態有兩種常見用途。首先，對於具有多個位置的機群，您可以使用篩選條件來排除部分機群的位置。其次，您可能想要暫時不允許在特定位置放置；例如，某個位置可能遇到暫時性問題。由於您可以隨時更新佇列的篩選組態，因此您可以視需要輕鬆新增和移除位置。透過呼叫 [UpdateGameSessionQueue](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_UpdateGameSessionQueue.html) 新增篩選條件組態。
+ 針對個別置放請求使用特殊指示：
+ **在遊戲工作階段置放請求中包含優先順序覆寫清單。**您可以使用任何 [StartGameSessionPlacement](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_StartGameSessionPlacement.html) 請求提供位置的替代優先順序清單。此清單會有效地取代佇列針對僅針對一個請求的位置所設定的優先順序。它不會影響任何其他請求。此覆寫功能有幾個需求：
+ 僅將覆寫清單與具有優先順序組態的佇列搭配使用，並以 `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/zh_tw/gameliftservers/latest/developerguide/images/queue-latency-policy.png)
# 建置 Spot 執行個體的佇列
您可以使用 Spot 機群，大幅節省託管成本。如需 Spot 機群及其使用方式的詳細資訊，請參閱 [隨需執行個體與 Spot 執行個體的比較](gamelift-compute.md#gamelift-compute-spot)。
如果您的遊戲託管解決方案包含 Spot 機群，您必須使用遊戲工作階段置放佇列。 Amazon GameLift Servers會使用佇列跨多個遊戲託管資源進行搜尋，並選取最適合用來託管新遊戲工作階段的佇列。使用 Spot 機群時，佇列對於將託管成本降至最低並避免可能的 Spot 中斷特別重要。本主題可協助您設定彈性佇列，即使發生中斷、減速和中斷，也能繼續為玩家託管遊戲。您可以自訂佇列如何根據多種因素排定可用託管資源的優先順序，包括託管成本。
您是否使用 FlexMatch 進行配對？ 您可以使用具有 Spot 機群的佇列，為您的配對進行遊戲工作階段放置。
## Spot 機群的實作任務
建立或更新遊戲託管解決方案以使用 Spot 機群時，請完成下列任務。如需如何建置佇列以最佳化 Spot 可用性和彈性的詳細指引，請參閱 [使用 Spot 機群降低遊戲託管成本](fleets-spot.md)。
1. **選擇並為您的遊戲工作階段佇列建立一組機群目的地。**
首先，決定要佇列放置遊戲工作階段的位置。佇列可以跨多個機群進行搜尋，以尋找最佳的可能配置。每個機群都有一個執行個體類型，但可以有多個地理位置。具有在位置和執行個體類型中提供多樣性的機群的佇列更有可能成功放置。請參閱這些設計有效且具彈性 Spot 最佳化佇列的最佳實務。
1. **建立 Spot 最佳化遊戲工作階段佇列。**
建立佇列並為您的 Spot 機群進行設定。請參閱 [建立遊戲工作階段佇列](queues-creating.md) 協助建立及設定新佇列。您可以使用 Amazon GameLift Servers主控台或 AWS CLI 來建立或編輯佇列。
+ 從步驟 1 新增機群目的地。
+ 視需要排定目的地順序的優先順序。根據預設， 會依目的地之前的成本排定Amazon GameLift Servers優先順序，因此只有在目的地之間的最低成本相等時，才會使用目的地訂單。
+ 如果您想要在玩家延遲之前排定遊戲託管成本的優先順序，請提供自訂置放優先順序。請參閱 [排定遊戲工作階段放置的優先順序](queues-design-priority.md)。
1. **更新解決方案中的其他元件，以使用新的佇列。**
當您的解決方案使用 Spot 最佳化佇列來啟動新的遊戲工作階段時，佇列會自動避免將遊戲工作階段放置在具有高中斷可能性的機群中。它改為搜尋所有可行的機群，尋找符合您所定義優先順序的資源，包括玩家延遲、託管成本和目的地順序。
+ 如果您不是使用 FlexMatch- 更新您的後端服務，以在遊戲工作階段請求中指定新的 Spot 最佳化佇列。後端服務Amazon GameLift Servers代表您的遊戲用戶端向 發出 API 請求 （使用 `StartGameSessionPlacement()`)，而且每個請求都必須指定佇列名稱。如需協助在遊戲用戶端實作遊戲工作階段配置，請參閱 [建立遊戲工作階段](gamelift-sdk-client-api.md#gamelift-sdk-client-api-create)。
+ 如果您使用的是 FlexMatch- 更新您的配對組態，將遊戲工作階段請求傳送至新的 Spot 最佳化佇列。當配對系統形成玩家配對時，它會向指定的佇列傳送遊戲工作階段置放請求，以啟動配對的新遊戲工作階段。只有FlexMatch模式設為「受管」的配對組態才能指定置放佇列。您可以使用 CLI AWS 或Amazon GameLift Servers主控台更新配對組態 （請參閱[編輯配對組態](https://docs.aws.amazon.com/gameliftservers/latest/flexmatchguide/match-create-configuration-edit.html))。
1. **檢閱 Spot 機群和佇列的效能。**
在Amazon GameLift Servers主控台中或使用 Amazon CloudWatch 檢視Amazon GameLift Servers指標，以檢閱效能。如需 Amazon GameLift Servers 指標的詳細資訊，請參閱[使用 Amazon CloudWatch 監控 Amazon GameLift Servers](monitoring-cloudwatch.md)。關鍵指標包括：
+ 中斷率 – 使用 `InstanceInterruptions`和 `GameSessionInterruptions`指標來追蹤執行個體和遊戲工作階段的 Spot 相關中斷次數和頻率。回收執行個體上的遊戲工作階段狀態為 `TERMINATED`，狀態原因為 `INTERRUPTED`。
+ 佇列有效性 – 追蹤置放成功率、平均等待時間和佇列深度，以確認 Spot 機群不會影響您的佇列效能。
+ 機群用量 – 監控執行個體、遊戲工作階段和玩家工作階段的資料。隨需機群的使用量可能是佇列避免置放至 Spot 機群以避免中斷的指標。
## Spot 機群佇列的最佳實務
為 Spot 執行個體建立機群和佇列時，請使用下列最佳實務。
+ **展開佇列的地理涵蓋範圍。**即使您的玩家叢集在單一 中 AWS 區域，請將相鄰位置新增至 Spot 機群。此方法可改善佇列在區域變慢、中斷和 Spot 中斷期間維持容量的能力。多位置機群適用於 Spot 和隨需執行個體。
+ **分散佇列的執行個體類型涵蓋範圍。** 會根據執行個體類型Amazon GameLift Servers評估 Spot 可行性，因此讓具有各種執行個體類型的 Spot 機群降低多個 Spot 機群同時不可存活的機率。包含至少兩個 Spot 機群，每個位置都有不同的執行個體類型。
**注意**
定價是以您使用的執行個體為基礎，而不是機群數量。執行五個具有 10 個執行個體的機群，與執行一個具有 50 個類似成本執行個體的機群相同。定價因執行個體類型、大小和位置而異。
分組 Spot 執行個體類型的秘訣：
+ 在相同系列中使用執行個體類型，例如 `m6g.medium`、 `m6g.large`和 `m6g.xlarge`。較大的執行個體類型成本較高，但也可以一次託管更多遊戲工作階段。
+ 選取廣泛可用的執行個體類型。一般而言，較舊世代系列 （例如 C5, M5 和 R5) 和常見大小 （例如 .large、.xlarge 和 .2xlarge) 的可用性更佳。
+ 在 Amazon GameLift Servers主控台中檢查 30-90 天的定價歷史記錄。尋找具有一致可用性模式的執行個體類型。
+ 使用 Amazon GameLift Servers主控台、機群建立工具來探索執行個體類型的位置涵蓋範圍。
+ **為備份容量新增隨需機群。**當 Spot 機群無法使用時，遊戲託管可以切換到隨需機群。在每個位置至少放置一個隨需機群，以維持低玩家延遲。將自動擴展新增至備份隨需機群，以便您可以將它們向下擴展，直到需要為止。
+ **將別名指派給所有機群目的地。**為每個佇列的目的地建立別名。別名可讓您在需要取代機群時更輕鬆、更有效率。
+ **套用佇列優先順序策略。**您可以自訂佇列如何排定遊戲工作階段放置位置的優先順序 （如需詳細資訊[排定遊戲工作階段放置的優先順序](queues-design-priority.md)，請參閱 )。對於 Spot 最佳化佇列，成本的優先順序可確保盡可能使用低成本的 Spot 機群。
您也可以指定目的地順序來排定特定機群的優先順序。例如，某些使用者會指定一組主要機群供定期使用，也會指定一組次要機群做為備份。在此案例中，設定佇列的目的地順序，以先列出主要機群。然後，使用目的地設定佇列的優先順序，後面接著成本。
# 託管資源自訂
本節提供進階選項，可讓您設定和管理Amazon GameLift Servers基礎設施，以滿足特定的效能、成本和操作需求。特別是，本節中的主題說明如何自訂Amazon GameLift Servers受管託管資源，以最適合您的遊戲和玩家。
您想要考慮的一些決策：
+ 在何處為您的玩家部署託管資源？ 遊戲延遲是選取機群地理位置的主要因素，但還有其他因位置而異的因素，包括資源類型可用性和成本。
+ 哪些 EC2 執行個體類型最能支援您的遊戲？ 從使用最佳運算架構、記憶體、儲存和聯網容量組合的可用執行個體類型中進行選擇。
+ 您需要多少大小的執行個體類型？ 根據遊戲伺服器軟體的資源需求 （記憶體和 CPU) 和其他因素，選擇執行個體類型大小。
+ 您的機群是否應該使用隨需或 Spot 執行個體？ 考慮您是否可以利用較低的 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)
+ [隨需執行個體與 Spot 執行個體的比較](#gamelift-compute-spot)
+ [Service Quotas](#gamelift-service-limits)
## 地理位置
考慮您計劃部署遊戲伺服器的位置。一般而言，您想要將遊戲伺服器盡可能靠近玩家，以提供最佳的玩家體驗。對於Amazon GameLift Servers受管託管，您可以選擇將遊戲伺服器放在任何支援的 AWS 區域 和 Local Zones。如果您要建置混合式解決方案，請考慮 受管機群部署如何補充自我管理的 Amazon GameLift Servers Anywhere 機群位置。
對於大多數開發和測試案例，部署到單一位置很有意義。當您準備啟動及更高版本時，在多個地理位置之間部署有許多原因。這包括支援廣泛的玩家群組，並改善整體遊戲託管彈性和可靠性。多個位置也可以透過加速遊戲工作階段置放，並在最佳化延遲和成本的置放時啟用更多選擇來提升玩家體驗。
如需 支援的位置清單，Amazon GameLift Servers以及所有機群類型位置的詳細資訊，請參閱 [Amazon GameLift Servers 服務位置](gamelift-regions.md)。
多位置機群
單一受管機群可以將資源部署到多個位置。您可以手動設定多位置機群中每個個別位置的容量。
使用多位置機群的優點：
+ 簡化機群部署和管理 – 您提供遊戲伺服器軟體和機群組態，並將其部署到跨多個位置的機群執行個體 Amazon GameLift Servers （建置一次，隨處部署）。在生產機群中，您可以檢視和管理機群中的所有位置，而不必管理位於不同區域的多個機群。
+ 本地區域可用性 – 如果您想要使用本地區域，您必須建立具有 AWS 區域 主要位置的多位置機群，並將本地區域作為遠端位置。Local Zones 是 的延伸 AWS 區域 ，可為需要的區域和客戶提供更低的延遲。您可以將 Local Zone 新增至任何多位置機群；您不需要包含 Local Zone 的父系 AWS 區域。
+ 遊戲工作階段佇列的相容性 – 您可以使用一或多個多位置機群建置遊戲工作階段置放佇列。此方法在排定優先順序並選擇位置以託管新的遊戲工作階段時，提供佇列彈性。
+ 有效率的資源使用率 – 開啟自動擴展後， 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 可以使用此資料來最佳化低延遲的遊戲工作階段，並防止玩家以無法接受的高延遲加入工作階段。這些特殊端點接受 UDP 訊息，而非傳統的 ICMP ping，因而提供了準確的延遲測量，以協助您選取最佳的機群位置。
## 作業系統
受管機群中的所有執行個體都會部署 Amazon Machine Image (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/)。
## 隨需執行個體與 Spot 執行個體的比較
Amazon EC2 隨需執行個體和 Spot 執行個體提供相同的硬體和效能，但可用性和成本不同。
**隨需執行個體**
您可以在需要時取得隨需執行個體，並隨需保留。隨需執行個體具有固定成本，這表示您只需按使用的時間量付費。沒有長期承諾。
**Spot 執行個體**
Spot 執行個體可以利用未使用的 AWS 運算容量，為隨需執行個體提供經濟實惠的替代方案。Spot 執行個體價格會根據每個位置中每個執行個體類型的供需而波動。每當 Spot 執行個體需要容量回傳時， AWS 可以透過兩分鐘通知來回收 Spot 執行個體，並且在回收的執行個體上主動執行的遊戲工作階段也會中斷。
Amazon GameLift Servers 提供多種工具，協助降低 Spot 中斷遊戲工作階段的可能性。Spot 可行性演算法會追蹤執行個體類型的歷史資料，以預測中斷風險何時達到關鍵點，並避免在該類型的 Spot 執行個體上放置新的遊戲工作階段。如果發生中斷，您的遊戲伺服器可以使用 通知來正常結束玩家的遊戲工作階段。
Spot 機群的遊戲託管必須使用佇列進行遊戲工作階段放置。佇列能夠根據 Spot 機群可行性、成本和其他因素，排定遊戲工作階段置放的優先順序。如需如何為遊戲伺服器託管利用 Spot 的詳細資訊，請參閱這些主題：
+ [使用 Spot 機群降低遊戲託管成本](fleets-spot.md)
+ [建置 Spot 執行個體的佇列](spot-tasks.md)
## Service Quotas
您可以使用 AWS 帳戶 下列工具檢視 的預設服務配額，Amazon GameLift Servers以及 的目前配額狀態：
+ 如需 的一般服務配額資訊Amazon GameLift Servers，請參閱 中的[Amazon GameLift Servers端點和配額](https://docs.aws.amazon.com/general/latest/gr/gamelift.html)*AWS 一般參考*。
+ 如需您帳戶每個位置的可用執行個體類型清單，請開啟 Amazon GameLift Servers主控台的服務[配額](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 使用這些限制來計算如何在機群執行個體上封裝遊戲伺服器容器群組。您也會在為容器機群選擇執行個體類型時使用它們。
計算容器群組所需的總記憶體和 vCPU。考慮下列各項：
+ 容器群組中所有容器執行的所有程序有哪些？ 新增這些程序所需的資源。請記下任何容器特定的限制。
+ 您計劃在每個容器群組中執行多少個並行遊戲伺服器程序？ 您可以在遊戲伺服器容器映像中確定這一點。
根據您對容器群組需求的預估，設定下列`ContainerGroupDefinition`屬性：
+ `TotalMemoryLimitMebibytes` – 設定容器群組的記憶體上限。群組中的所有容器都會共用配置的記憶體。如果您設定個別容器限制，總記憶體限制必須等於或大於最高容器特定記憶體限制。
+ `TotalVcpuLimit` – 設定容器群組的 vCPU 上限。群組中的所有容器都會共用配置的 CPU 資源。如果您設定個別容器限制，CPU 總限制必須等於或大於所有容器特定 CPU 限制的總和。最佳實務是考慮將此值設定為容器 CPU 限制總和的兩倍。
**範例藍本**
假設我們正在定義具有下列三個容器的遊戲伺服器容器群組：
+ 容器 A 是我們的遊戲伺服器容器。我們估計一個遊戲伺服器在 512 MiB 和 1024 CPU 的資源需求。我們計劃讓容器執行 1 個伺服器程序。由於此容器會執行我們最重要的軟體，因此我們不設定記憶體限制或 vCPU 預留限制。
+ 容器 B 是支援容器，其資源需求估計為 1024 MiB 和 1536 CPU。我們設定 2048 MiB 的記憶體限制，以及 1024 CPU 的 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/zh_tw/gameliftservers/latest/developerguide/containers-design-fleet.html)
1. **計算可用的記憶體。**從總執行個體記憶體中減去預留記憶體：
`AvailableMemory = InstanceMemory - round(InstanceMemory × BufferPercentage)`
1. **減去每個執行個體容器群組記憶體。**如果您的機群使用每個執行個體容器群組，`TotalMemoryLimitMebibytes`請從可用的記憶體中減去它。每個機群執行個體都會執行一個每個執行個體容器群組。
`AvailableMemory = AvailableMemory - PerInstanceCGD.TotalMemoryLimitMebibytes`
1. **記錄路由器額外負荷的帳戶。**如果為機群啟用了日誌記錄， 會為日誌路由器Amazon GameLift Servers保留每個遊戲伺服器容器群組額外的 50 MiB。
1. **計算遊戲伺服器容器群組的上限。**每個記憶體適合執行個體的遊戲伺服器容器群組數量上限為：
`MaxGroupsByMemory = floor(AvailableMemory / (GameServerCGD.TotalMemoryLimitMebibytes + LogRouterMemory))`
如果啟用記錄，其中 `LogRouterMemory`為 50 MiB，如果停用記錄，則為 0。
**注意**
記憶體只是決定執行個體上有多少遊戲伺服器容器群組的因素之一。 Amazon GameLift Servers也會考慮 vCPU 容量和可用的連線連接埠，並至少使用這三個計算。
### 記憶體計算範例
考慮使用啟用記錄的`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` – 設定為 `/data` 以參考主機執行個體上的自動掛載 NVMe 磁碟機。
+ `AccessLevel` – 選擇適合您容器需求的存取層級 （例如 READ\$1ONLY 或 READ\$1WRITE)。
+ `ContainerPath` – （選用） 指定將執行個體路徑掛載在容器內的路徑。如果未指定，則會預設為執行個體路徑。
如需掛載點的詳細資訊，請參閱《Amazon GameLift Servers API 參考》中的 [ContainerMountPoint](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_ContainerMountPoint.html)。
## 指定必要容器
對於每個執行個體容器群組，請將每個容器指定為必要或非必要。每個執行個體容器群組必須至少有一個基本支援容器。基本容器會執行容器群組的重要工作。基本容器預期一律在執行中。如果失敗，整個容器群組會重新啟動。
將每個容器的 `ContainerDefinition` 屬性`Essential`設定為 true 或 false。
## 設定網路連線
您可以自訂網路存取，以允許外部流量連接到容器機群中的任何容器。例如，您必須建立與執行遊戲伺服器程序之容器的網路連線，讓遊戲用戶端可以加入並玩遊戲。遊戲用戶端會使用連接埠和 IP 地址連線至遊戲伺服器。
在容器機群中，用戶端和伺服器之間的連線不是直接的。在內部，容器中的程序會接聽*容器連接埠*。在外部，傳入流量會使用*連線連接埠*連線至機群執行個體。 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]`
最佳實務是連接連接埠數量下限的兩倍。
連線連接埠的數量可能會限制每個執行個體的遊戲伺服器容器群組數量。如果機群每個執行個體只有一個遊戲伺服器容器群組的足夠連線連接埠，則 只會Amazon GameLift Servers部署一個遊戲伺服器容器群組，即使執行個體具有適用於多個遊戲伺服器容器群組的足夠運算能力。
**設定傳入許可**
傳入許可透過指定要為傳入流量開啟的連線連接埠，來控制容器機群的外部存取。您可以使用此設定，視需要開啟和關閉機群的網路存取。
根據預設， 會Amazon GameLift Servers計算所有容器群組所需的連接埠數目，並設定連接埠範圍以容納它們。我們強烈建議您使用Amazon GameLift Servers計算值，這些值會在您將更新部署至容器群組定義時更新。如果您需要自訂連線連接埠範圍，請使用下列指引。
當您建立容器機群時，請定義一組傳入許可 （請參閱 [ ContainerFleet：InstanceInboundPermissions](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_ContainerFleet.html))。傳入許可連接埠應與機群的連線連接埠範圍相符。
由於容器連接埠是從 InstanceConnectionPortRange 隨機選取，為了確保可以進行工作階段連線，InstanceConnectionPortRange 中的所有連接埠都應涵蓋在 InstanceInboundPermissions 中的連接埠
**範例藍本**
此範例說明如何設定所有三個網路連線屬性。
+ 我們機群的遊戲伺服器容器群組有 1 個容器，可執行 1 個遊戲伺服器程序。
在遊戲伺服器容器群組定義中，我們會設定此容器的 `PortConfiguration` 參數，如下所示：
```
"PortConfiguration": {
"ContainerPortRanges": [ { "FromPort": 10, "ToPort": 20, "Protocol": "TCP"} ] }
```
+ 我們的機群也具有具有 1 個容器的每個執行個體容器群組。它有 1 個程序需要網路存取。在每個執行個體容器定義中，我們設定此容器的 `PortConfiguration` 參數，如下所示：
```
"PortConfiguration": {
"ContainerPortRanges": [ { "FromPort": 25, "ToPort": 25, "Protocol": "TCP"} ] }
```
+ 我們的機群為每個機群執行個體設定了 20 個遊戲伺服器容器群組。根據此資訊，我們可以使用 公式來計算所需的連線連接埠數量：
+ 下限：**21 個連接埠** 【1 個遊戲伺服器容器連接埠 \$1 每個執行個體 20 個遊戲伺服器容器群組 \$1 每個執行個體容器連接埠 1 個】
+ 最佳實務：**42 個連接埠** 【最小連接埠 \$1 2】
建立容器機群時，我們會設定 `InstanceConnectionPortRange` 參數，如下所示：
```
"InstanceConnectionPortRange": { "FromPort": 1010, "ToPort": 1071 }
```
+ 我們希望允許存取所有可用的連線連接埠。建立容器機群時，我們會設定 `InstanceInboundPermissions` 參數，如下所示：
```
"InstanceInboundPermissions": [
{"FromPort": 1010, "ToPort": 1071, "IpRange": "10.24.34.0/23", "Protocol": "TCP"} ]
```
## 設定容器的運作狀態檢查
如果容器遇到終端故障並停止執行，容器會自動重新啟動。如果容器視為必要，它會提示整個容器群組重新啟動。
所有遊戲伺服器容器都會自動視為必要。支援容器可以指定為必要容器，但他們需要有機制來報告運作狀態。您也可以設定非必要支援容器的運作狀態檢查。
您可以定義其他自訂條件來測量容器運作狀態，並使用運作狀態檢查來測試該條件。若要設定容器運作狀態檢查，您可以在 Docker 容器映像或容器定義中定義它。如果您在容器定義中設定運作狀態檢查，它會覆寫容器映像中的任何設定。
為容器運作狀態檢查設定下列`SupportContainerDefinition`屬性：
+ `Command` — 提供可檢查容器運作狀態某些層面的命令。您可以決定使用哪些條件來測量運作狀態。命令必須導致結束值為 1 （運作狀態不良） 或 0 （運作狀態良好）。
+ `StartPeriod` — 指定運作狀態檢查失敗開始計數之前的初始延遲。此延遲可讓容器有時間引導其程序。
+ `Interval` — 決定執行運作狀態檢查命令的頻率。您想要多快偵測和解決容器故障？
+ `Timeout` — 決定等待成功或失敗的時間，然後再重試運作狀態檢查命令。運作狀態檢查命令需要多長時間才能完成？
+ `Retries` — 在註冊失敗之前，應該重試多少次運作狀態檢查命令？
## 設定容器相依性
在每個容器群組中，您可以根據容器狀態設定容器之間的相依性。相依性會影響相依容器何時可以根據另一個容器的狀態啟動或關閉。
相依性的關鍵使用案例是為容器群組建立啟動和關閉序列。
例如，您可能希望容器 A 先啟動，並在容器 B 和 C 啟動之前成功完成。若要達成此目的，請先建立容器 A 上容器 B 的相依性，條件為容器 A 必須成功完成。然後為容器 A 上具有相同條件的容器 C 建立相依性。啟動序列會以關機的相反順序發生。
## 設定容器機群
當您建立容器機群時，請考慮下列決策點。這些點大多取決於您的容器架構和組態。
**決定您要部署機群的位置**
一般而言，您想要在玩家附近的地理位置部署機群，以將延遲降至最低。您可以將容器機群部署到任何 AWS 區域 Amazon GameLift Servers支援的 。如果您想要將相同的遊戲伺服器部署到其他地理位置，您可以將遠端位置新增至機群，包括 AWS 區域 和 Local Zones。對於多位置機群，您可以在每個機群位置獨立調整容量。如需支援的機群位置的詳細資訊，請參閱 [Amazon GameLift Servers 服務位置](gamelift-regions.md)。
考慮使用 [UDP Ping 指標](reference-udp-ping-beacons.md) 收集不同地理位置的網路延遲資料，以預測玩家裝置和潛在機群位置之間的延遲。這些特殊端點接受 UDP 訊息，而非傳統的 ICMP ping，因而提供了準確的延遲測量，以協助您選取最佳的機群位置。
**為您的機群選擇執行個體類型和大小**
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)。
+ 保護具有作用中玩家的遊戲工作階段，避免在縮減規模事件期間提早終止。
+ 限制一個人可以在有限的時間內在機群上建立的遊戲工作階段數量。
# 使用 Spot 機群降低遊戲託管成本
使用Amazon GameLift Servers受管託管託管多玩家遊戲伺服器時，Spot 執行個體可以為隨需執行個體提供經濟實惠的替代方案。Spot 定價模型提供與隨需相同的硬體和效能，但可能節省大量成本 （高達 70-90%)。不過，它們具有限制：當 AWS 需要恢復容量時，可以透過兩分鐘的中斷通知回收這些執行個體。
Amazon GameLift Servers 可降低遊戲伺服器託管中斷的風險。 可Amazon GameLift Servers預測 Spot 執行個體類型中斷的可能性，並避免在任何有風險的執行個體上放置遊戲工作階段。如果發生罕見的中斷，通知可讓您正常結束玩家的遊戲工作階段。
## Amazon GameLift Servers 如何使用 Spot 機群
當您為遊戲託管設定 Spot 機群時， Amazon GameLift Servers會持續評估 Spot 機群執行個體類型和位置的遊戲託管可行性。
+ Spot 可行性演算法會依位置分析 Spot 執行個體類型的最新可用性模式和歷史中斷率。
+ 根據此分析， Amazon GameLift Servers會識別 Spot 執行個體類型和位置，這些執行個體類型和位置有不可接受的遊戲工作階段中斷可能性。它會採取下列動作：
+ 它將執行個體類型和位置的組合標記為暫時不可存活。
+ 在放置新的遊戲工作階段時，它會移除任何無法存活的 Spot 機群位置。因此，遊戲工作階段只會放置在 Spot 機群位置，這些位置極有可能不間斷地託管遊戲伺服器。
+ 它會耗盡現有執行個體的 Spot 機群位置，即使 AWS 未回收它們，因此您不需要為無法用於遊戲託管的執行個體付費。如果開啟遊戲工作階段保護，執行個體只會在作用中遊戲工作階段完成後關閉。
+ Amazon GameLift Servers 會持續重新評估 Spot 機群執行個體類型和位置，以取得遊戲託管可行性。當先前不可存活的執行個體類型根據更新的歷史資料再次可行時，您可以再次擴展 Spot 機群，然後Amazon GameLift Servers繼續放置遊戲工作階段。
## 設計考量
設計解決方案以使用 Spot 機群時，請考慮下列問題：
+ **評估遊戲工作階段長度** – 遊戲工作階段的平均長度可能會影響 Spot 對您遊戲的運作狀態。遊戲工作階段越短，周轉速度越快，就能根據最新的歷史資料，在可行的執行個體類型上執行遊戲工作階段。較長的遊戲工作階段會繼續在執行個體類型上執行，而不評估最近的可行性資料，隨著時間的推移，中斷風險更高。
+ **評估執行個體類型可用性** – 並非每個機群位置都會將每個執行個體類型提供為 Spot。選擇 Spot 機群的執行個體類型時，請使用Amazon GameLift Servers主控台機群建立工具，協助您在所需的位置尋找 Spot 執行個體類型。使用此工具，您可以選取機群位置，然後檢視這些位置的執行個體類型可用性。
+ **建立多位置 Spot 機群** – 您可以使用多個位置建立 Spot 機群。單一多位置 Spot 機群會將具有相同執行個體類型的執行個體部署至多個 AWS 區域 或 Local Zones。Spot 可行性演算法會根據執行個體類型和位置來評估可行性。如果 Spot 機群位置評估為不可存活，則不會影響機群中的其他位置，這仍然可用於託管遊戲工作階段。
+ **建立具有 Spot 機群多樣性的佇列** – 如果您使用 Spot 機群進行遊戲託管，則需要設定遊戲工作階段置放佇列。對於每個新的遊戲工作階段請求，佇列會尋找可用的遊戲託管資源，並選取最佳的可能選項。使用 Spot 機群時，您想要一個佇列，可以跨位置和執行個體類型不同的多個機群進行搜尋，而且您想要包含至少一個隨需機群做為備份容量。精心設計的多機群佇列提供多樣化的置放選項，可高度彈性地抵禦中斷、減速和中斷。如需為 Spot 設計佇列的其他指導，請參閱 [建置 Spot 執行個體的佇列](spot-tasks.md)。
+ **正常處理中斷** – 設定您的遊戲伺服器，以將發生 Spot 中斷時的玩家影響降至最低。當 AWS 回收 Spot 執行個體時， 會使用伺服器 SDK 回呼函數 ，將終止通知Amazon GameLift Servers傳遞給所有受影響的伺服器程序`onProcessTerminate()`。您的遊戲需要實作此回呼，才能正常結束遊戲工作階段。如需詳細資訊，請參閱[回應伺服器程序關閉通知](gamelift-sdk-server-api.md#gamelift-sdk-server-terminate)。
**注意**
AWS 會盡一切努力在回收執行個體之前提供通知，但有可能在警告到達之前 AWS 回收 Spot 執行個體。您也應該準備遊戲伺服器來處理非預期的中斷。
+ **為您的備份機群設定自動擴展，以在 Spot 中斷期間維護服務。**目標追蹤自動擴展會維護容量緩衝區，並隨需求自動擴展。透過自動擴展，每當備份機群 (Spot 或隨需） 開始接收更多遊戲工作階段請求時，就會開始增加容量。
若要在 Spot 機群變得無法存活時快速取代遺失的容量，自訂擴展機制可以使用可用的佇列和機群指標來啟動快速擴展的備份機群。使用 `FirstChoiceOutOfCapacity`、 和 等指標`FirstChoiceNotViable`偵測 Spot 機群何時變得無法存活`PercentAvailableGameSessions`。透過分析最近的`PlacementsStarted`指標資料來估計替代容量需求。擴展備份機群以處理立即需求之後，正常的自動擴展可以接管。
+ **與 整合 FlexMatch** – 如果您的解決方案使用FlexMatch配對建構器，Spot 機群沒有特殊需求。您可以設定配對建構器使用具有 Spot 機群的佇列。 Amazon GameLift Servers會自動排定 Spot 機群和隨需機群的配對置放優先順序，包括在放置新遊戲工作階段時，以及在現有遊戲工作階段中回填空玩家位置時。
# 最佳化受管 上的遊戲伺服器執行期組態 Amazon GameLift Servers
您可以設定受管 EC2 機群的執行時間組態，以執行每個執行個體的多個遊戲伺服器程序。這會更有效率地使用您的託管資源。
## 機群如何管理多個程序
Amazon GameLift Servers 使用機群的執行時間組態來判斷在每個執行個體上執行的程序類型和數量。執行時間組態包含至少一個代表一個遊戲伺服器可執行檔的伺服器程序組態。您可以定義其他伺服器程序組態，以執行與遊戲相關的其他程序類型。每個伺服器程序組態都會包含以下資訊：
+ 遊戲建置中可執行檔的檔案名稱和路徑。
+ (選用) 啟動時要傳遞至程序的參數。
+ 要同時執行的程序數目。
當機群中的執行個體啟用時，它會啟動執行時間組態中定義的一組伺服器程序。使用多個程序時， Amazon GameLift Servers 會交錯每個程序的啟動。伺服器程序的生命週期有限。隨著程序結束時， 會Amazon GameLift Servers啟動新的程序，以維護執行時間組態中定義的伺服器程序數量和類型。
您可以透過新增、變更或移除伺服器程序組態，隨時變更機群的執行時間組態。每個執行個體都會定期檢查機群執行時間組態的更新，以實作變更。以下是如何Amazon GameLift Servers採用執行時間組態變更的方式：
1. 執行個體會將執行時間組態Amazon GameLift Servers最新版本的請求傳送至 。
1. 執行個體會比較其作用中程序與最新的執行時間組態，然後執行下列動作：
+ 如果更新的執行時間組態移除伺服器程序類型，則此類型的作用中伺服器程序會繼續執行，直到結束為止。執行個體不會取代這些伺服器程序。
+ 如果更新的執行時間組態減少了伺服器程序類型的並行程序數量，則此類型的多餘伺服器程序會繼續執行，直到結束為止。執行個體不會取代這些多餘的伺服器程序。
+ 如果更新的執行時間組態新增了新的伺服器程序類型，或增加現有類型的並行程序，則執行個體會啟動新的伺服器程序，最高可達Amazon GameLift Servers上限。在此情況下，執行個體會在現有程序結束時啟動新的伺服器程序。
## 針對多個程序最佳化機群
若要在機群上使用多個程序，請執行下列動作：
+ [建立包含您要部署至機群之遊戲伺服器可執行檔的組建](gamelift-build-intro.md)，然後將組建上傳至 Amazon GameLift Servers。組建中的所有遊戲伺服器都必須在相同的平台上執行，並使用適用於 的伺服器 SDKAmazon GameLift Servers。
+ 使用一或多個伺服器程序組態建立執行時間組態和多個並行程序。
+ 將遊戲用戶端與 AWS SDK 2016-08-04 版或更新版本整合。
若要最佳化機群效能，建議您執行下列動作：
+ 處理伺服器程序關閉案例，讓 Amazon GameLift Servers可以有效率地回收程序。例如：
+ 將關機程序新增至呼叫伺服器 API 的遊戲伺服器程式碼`ProcessEnding()`。
+ 在遊戲伺服器程式碼`OnProcessTerminate()`中實作回呼函數，以處理來自 的終止請求Amazon GameLift Servers。
+ 請確定 Amazon GameLift Servers 關閉並重新啟動運作狀態不佳的伺服器程序。在遊戲伺服器程式碼中實作回`OnHealthCheck()`呼函數Amazon GameLift Servers，將運作狀態回報給 。 Amazon GameLift Servers會自動關閉連續三個報告回報運作狀態不佳的伺服器程序。如果您不實作 `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 Amazon GameLift Servers版或更新版本的伺服器開發套件整合。
Amazon GameLift Servers 代理程式可在外部用於非受管 EC2 Amazon GameLift Servers機群的機群。（受管 EC2 機群會自動處理代理程式的任務。) 您可以選擇執行機Amazon GameLift Servers群，包括 Anywhere 機群，無論是否有 代理程式。如果沒有 代理程式，您必須提供完成必要任務的替代解決方案。
部署到運算時，應在啟動任何遊戲伺服器程序之前啟動Amazon GameLift Servers代理程式。啟動時，代理程式會完成下列任務：
+ 使用 [RegisterCompute](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_RegisterCompute.html) API 向 Amazon GameLift ServersAnywhere 機群註冊運算。
+ 呼叫 [GetComputeAuthToken](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_GetComputeAuthToken.html) API 來擷取授權字符，並存放它以供在運算上執行的伺服器程序使用。
+ 設定運算的 WebSocket URL 環境變數，並建立與服務的 WebSocket 連線Amazon GameLift Servers。
+ 從 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`：遊戲伺服器程序在 30 秒內`OnProcessTerminate()`傳送後未完全結束。
+ `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，讓您可以順暢地將玩家流量從現有機群切換到新的機群。
+ 如果您想要在遊戲用戶端請求時，執行建立新遊戲工作階段以外的動作。例如，您可能想要將使用out-of-date用戶端的玩家導向升級網站。
別名必須指定路由策略。有兩種類型。*簡單*路由策略會將玩家流量路由到指定的機群 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。此清單包含目前選取之 eith 中的所有機群 AWS 區域。您必須在與機群相同的區域中建立別名。
1. 如果您選擇**終端機**路由策略，請輸入Amazon GameLift Servers要傳回遊戲用戶端的字串值，以回應遊戲工作階段請求。具有終端機別名的請求會擲回內嵌訊息的例外狀況。
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。對於終端機路由策略，請提供訊息字串。
------