기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 게임 호스팅 솔루션에 맞게 사용자 지정
기본 게임 호스팅 솔루션을 마련한 상태에서 다음 주제를 사용하여 플레이어 경험을 개선하고, 비용을 최적화하며, 고급 기능을 추가하도록 사용자 지정하고 개선합니다. 이 섹션에서는 주로 영향을 미치는 구성 요소에 따라 구성된 다양한 사용자 지정 옵션을 다룹니다. 게임의 요구 사항과 플레이어 기반에 가장 적합한 사용자 지정을 선택합니다.
**주제**
+ [게임 서버 빌드 사용자 지정](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)
+ [Amazon GameLift Servers에 FlexMatch 매치메이킹 추가](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(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 버전을 기반으로 애플리케이션을 수정하는 방법을 결정합니다.
| | 게임 서버 애플리케이션 | 기타 애플리케이션 |
| --- | --- | --- |
| **Server SDK 버전 5.x 사용** | 게임 서버 코드에서 Server SDK 메서드 `GetFleetRoleCredentials()`를 호출합니다. | 코드를 애플리케이션에 추가하여 플릿 인스턴스의 공유 파일에서 자격 증명을 가져옵니다. |
| **Server SDK 버전 4 또는 이전 버전 사용** | 역할 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()`하는를 계속 호출할 수 있습니다. 이러한 플릿 역할 자격 증명은 컨테이너 내에서만 액세스할 수 있습니다.
Server SDK 5.x와 통합된 게임의 경우 이 다이어그램은 배포된 게임 빌드의 애플리케이션이 IAM 역할에 대한 자격 증명을 획득하는 방법을 보여줍니다.
![\[게임 실행 파일이 GetFleetRoleCredentials()를 호출합니다. 다른 파일은 로컬에 저장된 공유 자격 증명을 사용합니다.\]](http://docs.aws.amazon.com/ko_kr/gameliftservers/latest/developerguide/images/instance-role-creds_vsd.png)
#### `GetFleetRoleCredentials()` 호출(Server 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`를 다시 호출하여 자격 증명을 새로 고칠 수 있습니다.
#### 공유 자격 증명 사용(Server SDK 5.x)
Server 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()` 사용(Server SDK 4)
애플리케이션에 코드를 추가하여 IAM 역할을 수임하고 AWS 리소스와 상호 작용하기 위한 자격 증명을 가져옵니다. Sever 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(VPC) 피어링을 사용하여 Amazon GameLift Servers 인스턴스에서 실행되는 애플리케이션과 다른 AWS 리소스 간에 통신할 수 있습니다. VPC는를 통해 관리되는 리소스 세트를 포함하는 사용자가 정의하는 가상 프라이빗 네트워크입니다 AWS 계정. 각 Amazon GameLift Servers 플릿에는 고유의 VPC가 있습니다. 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 게임 서버와의 피어링 설정은 약간 다릅니다. 게임 서버(Amazon GameLift Servers 서비스로 제어됨)를 포함하는 VPC에 액세스할 권한이 없으므로 VPC 피어링을 직접 요청할 수 없습니다. 그 대신 비 Amazon GameLift Servers 리소스를 포함하는 VPC를 사전 승인하여 Amazon GameLift Servers 서비스의 피어링 요청을 수락합니다. 그런 다음 방금 승인한 VPC 피어링을 요청하도록 Amazon GameLift Servers를 트리거합니다. Amazon GameLift Servers는 피어링 연결 생성, 라우팅 테이블 설정 및 연결 구성 작업을 처리합니다.
## 기존 플릿용 VPC 피어링을 설정하려면
1.
**AWS 계정 ID(들) 및 자격 증명을 가져옵니다.**
다음 AWS 계정에 대한 ID 및 로그인 자격 증명이 필요합니다. 에 로그인[AWS Management Console](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에 대한 ID를 가져옵니다.**
피어링할 두 VPC에 대해 다음 정보를 가져옵니다.
+ Amazon GameLift Servers 게임 서버용 VPC이며, 이는 Amazon GameLift Servers 플릿 ID입니다. EC2 인스턴스 플릿의 Amazon GameLift Servers에 게임 서버가 배포됩니다. 플릿은 해당 VPC에 자동으로 배치되며 Amazon GameLift Servers 서비스에 의해 관리됩니다. 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 Management Console](https://console.aws.amazon.com/)에 로그인한 후 VPC를 확인하여 VPC ID를 찾을 수 있습니다.
**참고**
피어링을 설정할 때는 두 VPC가 동일한 리전에 있어야 합니다. Amazon GameLift Servers 플릿 게임 서버용 VPC는 플릿과 동일한 리전에 있습니다.
1.
**VPC 피어링을 승인합니다.**
이 단계에서는 비 Amazon GameLift Servers 리소스에 대해 VPC가 있는 게임 서버와 함께 VPC를 피어링하기 위해 Amazon GameLift Servers에서 향후 요청을 사전 승인합니다. 이 작업은 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(들) 및 자격 증명을 가져옵니다.**
다음 두 AWS 계정에 대한 ID와 로그인 자격 증명이 필요합니다. 에 로그인[AWS Management Console](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.
**비 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 피어링 연결이 실패할 경우 새 플릿의 상태가 **Activating**에서 **Active**로 전환되지 않습니다.
**참고**
새로운 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) 참조)이 중첩되어 있습니다. 피어링된 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\$160초)으로 요청 상태를 폴링합니다. 취소된 요청은 `Cancelled due to duplicate player` 이유인 `CANCELLED` 상태로 표시됩니다.
다음 코드 샘플은 고유한 플레이어 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) 섹션을 참조하세요.
# Amazon GameLift Servers에 FlexMatch 매치메이킹 추가
Amazon GameLift Servers FlexMatch를 사용하여 Amazon GameLift Servers 호스팅하는 게임에 플레이어 매치메이킹 기능을 추가합니다. FlexMatch를 사용자 지정 게임 서버 또는 Amazon GameLift Servers Realtime과 함께 사용할 수 있습니다.
FlexMatch는 매치메이킹 서비스를 사용자 지정 가능한 규칙 엔진과 연결합니다. 게임에 적합한 플레이어 속성과 게임 모드를 기반으로 플레이어를 함께 매칭하는 방법을 설계합니다. FlexMatch는 게임을 찾고 있는 플레이어를 평가하고, 하나 이상의 팀과 매치를 구성하며, 매치를 호스팅하기 위해 게임 세션을 시작하는 기본 사항을 관리합니다.
전체 FlexMatch 서비스를 사용하려면 호스팅 리소스를 대기열로 설정해야 합니다. Amazon GameLift Servers는 대기열을 사용하여 여러 리전 및 컴퓨팅 유형에 걸쳐 게임에 가장 적합한 호스팅 위치를 찾습니다. 특히 Amazon GameLift Servers 대기열은 게임 클라이언트가 제공하는 지연 시간 데이터를 사용하여 게임 세션을 배치하므로, 플레이어가 게임을 플레이할 때 최대한 낮은 지연 시간을 경험하게 됩니다.
게임에 매치메이킹을 통합하는 자세한 지원이 있는 FlexMatch에 대한 자세한 내용은 [Amazon GameLift Servers FlexMatch 개발자 가이드](https://docs.aws.amazon.com/gamelift/latest/flexmatchguide/)의 다음 주제를 참조하세요.
+ [Amazon GameLift Servers FlexMatch 작동 방식](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)
# 대기열의 범위 정의
게임의 플레이어 모집단에는 함께 플레이해서는 안 되는 플레이어 그룹이 있을 수 있습니다. 예를 들어 게임을 두 언어로 게시하는 경우 각 언어에는 고유한 게임 서버가 있어야 합니다.
플레이어 인구를 대상으로 게임 세션 배치를 설정하려면 각 플레이어 세그먼트에 대해 별도의 대기열을 생성합니다. 각 대기열의 범위를 지정하여 플레이어를 올바른 게임 서버에 배치합니다. 대기열의 범위를 지정하는 몇 가지 일반적인 방법은 다음과 같습니다.
+ **지리적 위치별.** 여러 지역에 게임 서버를 배포할 때는 각 위치에 플레이어를 위한 대기열을 만들어 플레이어 지연 시간을 줄일 수 있습니다.
+ **빌드 또는 스크립트 변형별.** 게임 서버의 변형이 두 개 이상이면 동일한 게임 세션에서 플레이할 수 없는 플레이어 그룹을 지원하는 것일 수 있습니다. 예를 들어 게임 서버 빌드나 스크립트는 다양한 언어 또는 디바이스 유형을 지원할 수 있습니다.
+ **이벤트 유형별.** 토너먼트 또는 기타 특별 이벤트 참가자의 게임을 관리하기 위해 특별 대기열을 만들 수 있습니다.
## 여러 대기열 설계
게임과 플레이어에 따라 게임 세션 대기열을 두 개 이상 만들어야 할 수도 있습니다. 게임 클라이언트 서비스가 새로운 게임 세션을 요청하면 어떤 게임 세션 대기열을 사용하는지 지정합니다. 대기열을 여러 개 사용할지 여부를 결정하는 데 도움이 되려면 다음을 고려합니다.
+ 게임 서버의 변형. 게임 서버의 각 변형에 대해 별도의 대기열을 만들 수 있습니다. 대기열에 있는 모든 플릿은 호환 가능한 게임 서버를 배포해야 합니다. 대기열을 사용하여 게임에 참가하는 플레이어는 해당 대기열의 모든 게임 서버에서 플레이할 수 있어야 하기 때문입니다.
+ 다양한 플레이어 그룹. Amazon GameLift Servers가 플레이어 그룹을 기반으로 게임 세션을 배치하는 방법을 사용자 지정할 수 있습니다. 예를 들어 특별한 인스턴스 유형이나 런타임 구성이 필요한 특정 게임 모드에 맞게 사용자 지정된 대기열이 필요할 수 있습니다. 또는 토너먼트나 기타 이벤트의 배치를 관리하기 위한 특수 대기열을 원할 수도 있습니다.
+ 게임 세션 대기열 지표. 게임 세션 배치 지표를 수집하려는 방식에 따라 대기열을 설정할 수 있습니다. 자세한 내용은 [대기열에 대한 Amazon GameLift Servers 지표](monitoring-cloudwatch.md#gamelift-metrics-queue) 단원을 참조하십시오.
# 다중 위치 대기열 빌드
모든 대기열에 다중 위치 설계를 사용하는 것이 좋습니다. 이 설계를 통해 배치 속도와 호스팅 복원성을 개선할 수 있습니다. 플레이어 지연 시간 데이터를 사용하여 플레이어를 지연 시간을 최소화하면서 게임 세션에 참여시키려면 다중 위치 설계가 필요합니다. 스팟 인스턴스 플릿을 사용하는 다중 위치 대기열을 구축하는 경우 [스팟 플릿으로 게임 호스팅 비용 절감](fleets-spot.md)의 지침을 따릅니다.
다중 위치 대기열을 생성하는 한 가지 방법은 대기열에 [다중 위치 플릿](gamelift-regions.md#gamelift-regions-hosting)을 추가하는 것입니다. 이렇게 하면 대기열에서 플릿의 어느 위치에나 게임 세션을 배치할 수 있습니다. 중복성을 위해 구성이나 홈 위치가 다른 플릿을 추가할 수도 있습니다. 다중 위치 스팟 인스턴스 플릿을 사용하는 경우 모범 사례를 따르고 동일한 위치의 온디맨드 인스턴스 플릿을 포함합니다.
다음 예는 기본 다중 위치 대기열을 설계하는 프로세스에 대해 간략하게 설명합니다. 이 예에서는 스팟 인스턴스 플릿 하나와 온디맨드 인스턴스 플릿 하나, 이렇게 두 플릿을 사용합니다. 각 플릿에는 배치 위치에 AWS 리전 대한 `us-east-1`, `us-east-2`, 및 `ca-central-1`가 있습니다`us-west-2`.
**다중 위치 플릿이 포함된 기본 다중 위치 대기열을 생성하려면**
1. 대기열을 생성할 위치를 선택합니다. 클라이언트 서비스를 배포한 위치 근처에 대기열을 배치하여 요청 지연 시간을 최소화할 수 있습니다. 이 예제에서는 `us-east-1`에서 대기열을 만듭니다.
1. 새 대기열을 생성하고 대기열 대상으로 다중 위치 플릿을 추가합니다. 대상 순서에 따라 Amazon GameLift Servers가 게임 세션을 배치하는 방식이 결정됩니다. 이 예에서는 스팟 인스턴스 플릿을 먼저 나열하고 온디맨드 인스턴스 플릿을 두 번째로 나열합니다.
1. 대기열의 게임 세션 배치 우선 순위를 정의합니다. 이 순서는 대기열이 사용 가능한 게임 서버를 가장 먼저 검색하는 위치를 결정합니다. 이 예제에서는 기본 우선 순위 순서를 사용합니다.
1. 위치 순서를 정의합니다. 위치 순서를 정의하지 않는 경우 Amazon GameLift Servers는 위치를 알파벳 순서대로 사용합니다.
![\[예제 대기열의 위치와 대상 순서를 보여주는 콘솔 스크린샷\]](http://docs.aws.amazon.com/ko_kr/gameliftservers/latest/developerguide/images/queue-multi-location-1.png)
![\[대기열의 배치 우선 순위 및 위치 순서를 보여주는 콘솔 스크린샷\]](http://docs.aws.amazon.com/ko_kr/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는 알파벳 순서에 따라 플릿의 위치의 우선 순위를 지정합니다.
## 대기열이 게임 세션 배치의 우선 순위를 지정하는 방법에 대한 사용자 지정
대기열이 배치 기준의 우선 순위를 지정하는 방법을 사용자 지정하도록 선택할 수 있습니다. 대기열은 수신하는 모든 게임 세션 배치 요청에 사용자 지정 우선 순위를 적용합니다.
**참고**
사용자 지정 우선 순위 구성을 생성할 때 네 가지 기준을 모두 포함하지 않는 경우 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` 옵션과 함께 사용하여 대기열의 우선 순위 순서를 사용자 지정합니다.는 현재 기본 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 핑 비콘을 사용합니다. 이러한 엔드포인트를 사용하면 플레이어 디바이스와 각 잠재적 호스팅 위치 간의 실제 UDP 네트워크 지연 시간을 측정할 수 있으므로 ICMP Ping을 사용하는 것보다 더 정확한 배치 결정을 내릴 수 있습니다. UDP 핑 비콘을 사용하여 지연 시간을 측정하는 방법에 대한 자세한 내용은 [UDP 핑 비콘](reference-udp-ping-beacons.md) 섹션을 참조하세요.
## 위치별 배치 우선순위 지정
우선순위가 지정된 지리적 위치 목록을 기반으로 게임 세션을 배치하도록 대기열을 구성할 수 있습니다. 위치는 대기열이 새 게임 세션을 배치할 위치를 선택하는 방법을 결정하는 기준 중 하나입니다. 기본적으로 위치는 지연 시간, 비용, 대상 이후 네 번째로 우선순위가 지정됩니다.
게임 세션 배치의 경우 대상과 위치의 의미는 약간 다릅니다.
+ *대상*은 특정 플릿을 가리키며 배포된 모든 플릿의 호스팅 리소스를 포함합니다. 대상에 따라 우선순위를 지정할 때 Amazon GameLift Servers는 플릿의 모든 위치에 배치할 수 있습니다. 다중 위치 관리형 플릿 및 Anywhere 플릿에는 하나 이상의 위치에 배포되는 호스팅 리소스가 있을 수 있습니다.
+ *위치*는 플릿의 호스팅 리소스가 배포되는 특정 지리적 위치를 나타냅니다. 플릿에는 AWS 리전로컬 영역 또는 사용자 지정 위치( 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. 모든 플레이어 지연 시간이 50밀리초 미만인 위치를 검색하는 데 120초를 소요합니다.
1. 모든 플레이어 지연 시간이 100밀리초 미만인 위치를 검색하는 데 120초를 소요합니다.
1. 모든 플레이어 지연 시간이 200밀리초 미만인 위치를 검색하는 데 남은 대기열 제한 시간을 소요합니다.
![\[점진적으로 완화되는 지연 시간 정책의 예를 보여주는 콘솔 스크린샷.\]](http://docs.aws.amazon.com/ko_kr/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 모드가 ‘관리형’으로 설정된 매치메이킹 구성만 배치 대기열을 지정할 수 있습니다. AWS CLI 또는 Amazon GameLift Servers 콘솔을 사용하여 매치메이킹 구성을 업데이트할 수 있습니다([매치메이킹 구성 편집](https://docs.aws.amazon.com/gameliftservers/latest/flexmatchguide/match-create-configuration-edit.html) 참조).
1. **스팟 플릿 및 대기열의 성능을 검토합니다.**
Amazon GameLift Servers 콘솔 또는 Amazon CloudWatch를 사용하여 Amazon GameLift Servers 지표를 보고 성능을 검토할 수 있습니다. Amazon GameLift Servers 지표에 대한 자세한 정보는 [Amazon CloudWatch를 사용하여 Amazon GameLift Servers 모니터링](monitoring-cloudwatch.md) 단원을 참조하십시오. 주요 지표는 다음과 같습니다.
+ 중단율 - `InstanceInterruptions` 및 `GameSessionInterruptions` 지표를 사용하여 인스턴스 및 게임 세션에 대한 스팟 관련 중단의 횟수와 빈도를 추적합니다. `TERMINATED`에서 회수된 게임 세션은 상태이고 상태 이유는 `INTERRUPTED`입니다.
+ 대기열 효율성 - 배치 성공률, 평균 대기 시간 및 대기열 깊이를 추적하여 스팟 플릿 사용이 대기열 성능에 영향을 미치지 않는지 확인합니다.
+ 플릿 사용 - 인스턴스, 게임 세션, 플레이어 세션에 대한 데이터를 모니터링합니다. 온디맨드 플릿의 사용량은 중단 상황이 발생하지 않도록 대기열이 스팟 플릿에 배치되는 것을 피하고 있다는 지표가 될 수 있습니다.
## 스팟 플릿의 대기열에 대한 모범 사례
스팟 인스턴스에 대한 플릿 및 대기열을 생성할 때 다음 모범 사례를 사용합니다.
+ **대기열의 지리적 범위를 확장합니다.** 플레이어가 단일에 클러스터링되어 있더라도 스팟 플릿에 인접 위치를 AWS 리전추가합니다. 이 접근 방식을 통해 리전 속도 저하, 중단, 스팟 중단 중에 용량을 유지하는 대기열의 기능을 개선합니다. 다중 위치 플릿은 스팟 인스턴스와 온디맨드 인스턴스 모두에서 작동합니다.
+ **대기열의 인스턴스 유형 범위를 다양화합니다.** Amazon GameLift Servers는 인스턴스 유형을 기반으로 스팟 실행 가능성을 평가하므로 다양한 인스턴스 유형의 스팟 플릿을 사용하면 여러 스팟 플릿을 동시에 사용할 수 없을 가능성이 줄일 수 있습니다. 각 위치마다 인스턴스 유형이 다른 스팟 플릿을 두 개 이상 포함합니다.
**참고**
요금은 플릿 수가 아닌 사용하는 인스턴스를 기준으로 합니다. 10개의 인스턴스를 가진 5개의 플릿을 실행하는 것은 유사한 비용의 인스턴스 50개를 가진 하나의 플릿을 실행하는 것과 같습니다. 요금은 인스턴스 유형, 크기, 위치에 따라 다릅니다.
스팟 인스턴스 유형 그룹화에 대한 팁:
+ `m6g.medium`, `m6g.large`, `m6g.xlarge`와 같은 동일한 패밀리의 인스턴스 유형을 사용합니다. 인스턴스 유형이 클수록 비용이 많이 들지만 한 번에 더 많은 게임 세션을 호스팅할 수도 있습니다.
+ 널리 사용 가능한 인스턴스 유형을 선택합니다. 일반적으로 이전 세대 패밀리(예: C5, M5, R5)와 일반적인 크기(예: .large, .xlarge, .2xlarge)의 가용성이 향상됩니다.
+ Amazon GameLift Servers 콘솔에서 30\$190일 요금 내역을 확인합니다. 일관된 가용성 패턴을 가진 인스턴스 유형을 찾습니다.
+ 플릿 생성 도구인 Amazon GameLift Servers 콘솔을 사용하여 인스턴스 유형의 위치 범위를 탐색합니다.
+ **백업 용량을 위한 온디맨드 플릿을 추가합니다.** 게임 호스팅은 스팟 플릿을 사용할 수 없을 때마다 온디맨드 플릿으로 전환할 수 있습니다. 플레이어 지연 시간을 낮게 유지하려면 각 위치에 온디맨드 플릿을 하나 이상 배치합니다. 백업 온디맨드 플릿에 오토 스케일링을 추가하여 필요할 때까지 스케일 다운 상태를 유지할 수 있습니다.
+ **모든 플릿 대상에 별칭을 할당합니다.** 각 대기열의 대상에 대해 별칭을 생성합니다. 별칭을 사용하면 플릿을 교체해야 할 때마다 더 쉽고 효율적으로 사용할 수 있습니다.
+ **대기열 우선순위 지정 전략을 적용합니다.** 대기열이 게임 세션을 배치할 위치의 우선순위를 지정하는 방법을 사용자 지정할 수 있습니다(자세한 내용은 [게임 세션 배치 우선순위](queues-design-priority.md) 참조). 스팟 최적화 대기열의 경우, 비용을 우선순위로 지정하면 가능할 때마다 언제든지 저렴한 비용의 스팟 플릿이 사용되도록 보장합니다.
대상 순서를 지정하여 특정 플릿의 우선순위를 지정할 수도 있습니다. 예를 들어 일부 사용자는 정기적으로 사용할 기본 플릿 세트와 보조 플릿 세트를 백업으로 지정합니다. 이 시나리오에서는 기본 플릿을 먼저 나열하도록 대기열의 대상 순서를 설정합니다. 그런 다음 대상과 비용 순으로 대기열의 우선순위 순서를 구성합니다.
# 리소스 사용자 지정 호스팅
이 섹션에서는 특정 성능, 비용, 운영 요구 사항을 충족하도록 Amazon GameLift Servers 인프라를 구성하고 관리하기 위한 고급 옵션을 제공합니다. 특히 이 섹션의 주제에서는 게임과 플레이어에 가장 적합하도록 Amazon GameLift Servers 관리형 호스팅 리소스를 사용자 지정하는 방법을 설명합니다.
고려해야 할 몇 가지 결정 사항은 다음과 같습니다.
+ 플레이어용 호스팅 리소스는 어디에서 배포하나요? 게임 플레이 지연 시간은 플릿의 지리적 위치를 선택하는 주요 요인이지만 위치에 따라 리소스 유형 가용성 및 비용을 포함한 다른 요인들에 의해 달라집니다.
+ 게임을 가장 잘 지원할 수 있는 EC2 인스턴스 유형은 무엇인가요? 사용할 수 있는 인스턴스 유형 중에서 선택하여 컴퓨팅 아키텍처, 메모리, 스토리지 및 네트워킹 용량의 최상의 조합을 사용해야 합니다.
+ 필요한 인스턴스 유형의 크기: 게임 서버 소프트웨어의 리소스 요구 사항(메모리 및 CPU) 및 기타 요인에 따라 인스턴스 유형 크기를 선택해야 합니다.
+ 플릿에서 사용할 인스턴스 유형(온디맨드 또는 스팟): 더 낮은 스팟 요금을 활용할 수 있는지, Amazon GameLift Servers가 게임 세션에 대한 스팟 중단 가능성을 충분히 완화하는지 고려합니다.
+ 각 플릿 인스턴스에서 게임 서버 소프트웨어가 실행되는 방법: 런타임 구성으로 Amazon GameLift Servers가 실행할 서버 소프트웨어와 방법을 지정할 수 있습니다.
+ 컨테이너 플릿의 경우 기본 구성이 게임에 적합하나요? Amazon GameLift Servers는 컨테이너 플릿 구성을 최적화하도록 많은 작업을 수행하지만 대부분의 구성 설정은 사용자 지정할 수 있습니다.
# 관리형 플릿의 컴퓨팅 리소스 선택
관리형 EC2 및 관리형 컨테이너를 포함한 AWS 클라우드관리형 호스팅의 경우 서비스는 게임 서버를 Amazon GameLift Servers의 컴퓨팅 리소스 플릿에 배포합니다. 관리형 플릿을 생성할 때 게임에 가장 적합하도록 호스팅 리소스를 구성하고자 합니다. 이 주제에서는 게임 호스팅 플릿을 선택하고 구성할 때의 주요 결정 사항에 대해 설명합니다.
**참고**
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) 섹션을 참조하세요.
다중 위치 플릿
단일 관리형 플릿은 여러 위치에 리소스를 배포할 수 있습니다. 다중 위치 플릿에서 각 개별 위치의 용량을 수동으로 설정할 수 있습니다.
다중 위치 플릿 사용의 이점:
+ 간소화된 플릿 배포 및 관리 - 게임 서버 소프트웨어 및 플릿 구성을 제공하고 Amazon GameLift Servers가 여러 위치(한 번 빌드, 어디에나 배포)의 플릿 인스턴스에 배포합니다. 프로덕션 플릿에서는 각각 다른 리전에 있는 여러 플릿을 관리할 필요 없이 플릿의 모든 위치를 보고 관리할 수 있습니다.
+ 로컬 영역 가용성 - 로컬 영역을 사용하려면 AWS 리전 홈 위치와 로컬 영역을 원격 위치로 사용하여 다중 위치 플릿을 생성해야 합니다. 로컬 영역은 필요한 영역과 고객에게 훨씬 더 짧은 지연 시간을 제공할 AWS 리전 수 있는의 확장입니다. 다중 위치 플릿에 로컬 영역을 추가할 수 있으며, 로컬 영역의 상위 AWS 리전을 포함할 필요는 없습니다.
+ 게임 세션 대기열과의 호환성 - 하나 이상의 다중 위치 플릿을 사용하여 게임 세션 배치 대기열을 구축할 수 있습니다. 이 접근 방식은 새 게임 세션을 호스팅할 위치의 우선순위를 지정하고 선택할 때 대기열에 유연성을 제공합니다.
+ 효율적인 리소스 사용률 - Auto Scaling이 켜져 있으면 Amazon GameLift Servers는 플릿의 모든 위치에서 용량 조정을 더 잘 최적화할 수 있습니다.
다중 위치 플릿 사용에 대한 팁:
+ AWS 리전 또는 플릿당 위치 수에 대한 할당량을 확인합니다. [Amazon GameLift Servers 서비스 할당량](https://docs.aws.amazon.com/general/latest/gr/gamelift.html#limits_gamelift)을 참조하세요.
+ 모든 위치에서 모든 인스턴스 유형을 사용할 수 있는 것은 아닙니다. 선택한 위치에 따라 인스턴스 유형 옵션이 제한될 수 있습니다. Amazon GameLift Servers 콘솔은 위치와 인스턴스 유형의 적절한 균형을 찾는 데 도움이 되는 유용한 도구를 제공합니다.
+ [UDP 핑 비콘](reference-udp-ping-beacons.md)를 사용하여 모든 플릿 위치에 대한 플레이어 지연 시간 데이터를 수집하는 것이 좋습니다. Amazon GameLift Servers는이 데이터를 사용하여 짧은 지연 시간으로 게임 세션을 최적화하고 플레이어가 허용할 수 없을 정도의 높은 지연 시간으로 세션에 참여하지 못하도록 할 수 있습니다. 이러한 특수 엔드포인트는 기존 ICMP 핑 대신 UDP 메시지를 수락하여 정확한 지연 시간 측정값을 제공하므로 최적의 플릿 위치를 선택하는 데 도움이 됩니다.
## 운영 체제
관리형 플릿의 모든 인스턴스는 게임 서버 소프트웨어를 위한 완전한 런타임 환경을 제공하는 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에는 Server SDK 5.1.1 이상이 필요합니다. Go에는 Server SDK 5.0 이상이 필요합니다. 이러한 인스턴스는 Amazon Linux 2023(AL2023) 또는 Amazon Linux 2(AL2)에서 모노 설치에 대한 기본 지원을 제공하지 않습니다.
+ 게임 서버 빌드의 컴퓨팅, 메모리 및 스토리지 요구 사항입니다.
+ 인스턴스 유형의 크기입니다. 게임 서버 소프트웨어 실행 파일의 요구 사항을 충족하는 것 외에도 인스턴스 유형 크기가 클수록 각 인스턴스에서 여러 게임 서버 프로세스 및/또는 컨테이너를 실행할 수 있습니다. 고려해야 할 요소에는 비용이 포함됩니다(몇 개의 큰 인스턴스 또는 여러 개의 작은 인스턴스를 실행하는 것이 더 저렴함). 또한 플릿 조정 이벤트 중에 또는 비정상 인스턴스를 종료할 때 인스턴스를 추가하거나 제거하여 게임 세션 용량에 어떤 영향을 미칠 수 있는지 고려합니다. 각 인스턴스가 여러 게임 서버 프로세스를 동시에 실행하는 경우 인스턴스를 추가하거나 제거하면 게임 호스팅 용량에 상당한 영향을 미칠 수 있습니다.
인스턴스 유형에 대한 자세한 내용은 [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 단위는 vCPU 1개에 해당합니다.)
**컨테이너 그룹에 대한 총 리소스 제한 설정**
개별 컨테이너에 대한 제한을 설정하는 경우 컨테이너 그룹에 필요한 메모리 및 vCPU 리소스의 양을 수정해야 할 수 있습니다. 목표는 게임 서버 성능을 최적화하기 위해 충분한 리소스를 할당하는 것입니다. Amazon GameLift Servers는 이러한 제한을 사용하여 플릿 인스턴스에 게임 서버 컨테이너 그룹을 패키징하는 방법을 계산합니다. 컨테이너 플릿의 인스턴스 유형을 선택할 때 사용할 수도 있습니다.
컨테이너 그룹에 필요한 총 메모리 및 vCPU를 계산합니다. 다음을 고려하세요.
+ 컨테이너 그룹의 모든 컨테이너에서 실행되는 모든 프로세스는 무엇인가요? 이러한 프로세스에 필요한 리소스를 추가합니다. 컨테이너별 제한을 기록해 둡니다.
+ 각 컨테이너 그룹에서 실행할 동시 게임 서버 프로세스는 몇 개인가요? 게임 서버 컨테이너 이미지에서 이를 결정합니다.
컨테이너 그룹 요구 사항 추정치에 따라 다음 `ContainerGroupDefinition` 속성을 설정합니다.
+ `TotalMemoryLimitMebibytes` - 컨테이너 그룹의 최대 메모리 제한을 설정합니다. 그룹의 모든 컨테이너는 할당된 메모리를 공유합니다. 개별 컨테이너 제한을 설정하는 경우 총 메모리 제한은 가장 높은 컨테이너별 메모리 제한보다 크거나 같아야 합니다.
+ `TotalVcpuLimit` - 컨테이너 그룹의 최대 vCPU 제한을 설정합니다. 그룹의 모든 컨테이너는 할당된 CPU 리소스를 공유합니다. 개별 컨테이너 제한을 설정하는 경우 총 CPU 제한은 모든 컨테이너별 CPU 제한 합계보다 크거나 같아야 합니다. 컨테이너 CPU 제한 합계의 두 배로 이 값을 설정하는 것이 가장 좋습니다.
**예제 시나리오**
다음 세 개의 컨테이너로 게임 서버 컨테이너 그룹을 정의한다고 가정해 보겠습니다.
+ 컨테이너 A는 게임 서버 컨테이너입니다. 하나의 게임 서버에 대한 리소스 요구 사항은 512MiB 및 1024CPU로 추정됩니다. 컨테이너가 1개의 서버 프로세스를 실행하도록 할 계획입니다. 이 컨테이너는 가장 중요한 소프트웨어를 실행하므로 메모리 제한이나 vCPU 예약 제한을 설정하지 않습니다.
+ 컨테이너 B는 1024MiB 및 1536CPU로 예상되는 리소스 요구 사항이 있는 지원 컨테이너입니다. 메모리 제한을 2048MiB로 설정하고 CPU 예약 제한을 1024CPU로 설정합니다.
+ 컨테이너 C는 다른 지원 컨테이너입니다. 메모리 제한을 512MiB로 설정하고 CPU 예약 제한을 512CPU로 설정합니다.
이 정보를 사용하여 컨테이너 그룹에 대해 다음과 같은 총 제한을 설정합니다.
+ 총 메모리 제한: 7680MiB. 이 값은 가장 높은 메모리 제한(1024MiB)을 초과합니다.
+ 총 CPU 한도: 13312CPU. 이 값은 CPU 제한(1024\$1512CPU)의 합계를 초과합니다.
## 컨테이너 플릿 메모리 할당 이해
가 플릿 인스턴스에 컨테이너 그룹을 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/ko_kr/gameliftservers/latest/developerguide/containers-design-fleet.html)
1. **사용 가능한 메모리를 계산합니다.** 총 인스턴스 메모리에서 예약된 메모리를 뺍니다.
`AvailableMemory = InstanceMemory - round(InstanceMemory × BufferPercentage)`
1. **인스턴스당 컨테이너 그룹 메모리를 뺍니다.** 플릿이 인스턴스당 컨테이너 그룹을 사용하는 경우 사용 가능한 메모리`TotalMemoryLimitMebibytes`에서 해당 그룹을 뺍니다. 인스턴스당 하나의 컨테이너 그룹이 각 플릿 인스턴스에서 실행됩니다.
`AvailableMemory = AvailableMemory - PerInstanceCGD.TotalMemoryLimitMebibytes`
1. **로그 라우터 오버헤드에 대한 계정입니다.** 플릿에 로깅이 활성화된 경우는 로그 라우터에 대해 게임 서버 컨테이너 그룹당 50MiB를 추가로 Amazon GameLift Servers 예약합니다.
1. **최대 게임 서버 컨테이너 그룹을 계산합니다.** 메모리별로 인스턴스에 맞는 게임 서버 컨테이너 그룹의 최대 수는 다음과 같습니다.
`MaxGroupsByMemory = floor(AvailableMemory / (GameServerCGD.TotalMemoryLimitMebibytes + LogRouterMemory))`
여기서 `LogRouterMemory`는 로깅이 활성화된 경우 50MiB이고 로깅이 비활성화된 경우 0입니다.
**참고**
메모리는 인스턴스에 맞는 게임 서버 컨테이너 그룹 수를 결정하는 한 가지 요소일 뿐입니다.는 vCPU 용량과 사용 가능한 연결 포트Amazon GameLift Servers도 고려하고 세 가지 계산 모두의 최소값을 사용합니다.
### 메모리 계산 예
로깅이 활성화된 `c5.xlarge` 인스턴스(총 메모리 8,192MiB)를 사용하는 플릿을 생각해 보십시오.
1. 인스턴스 메모리는 8,192MiB이며 5,000\$19,999 티어(6% 버퍼)에 속합니다.
1. 예약 메모리 = round(8,192 × 0.06) = 492MiB
1. 사용 가능한 메모리 = 8,192\$1492 = 7,700MiB
1. `TotalMemoryLimitMebibytes` 512의 인스턴스당 컨테이너 그룹을 사용하는 경우: 사용 가능한 메모리 = 7,700\$1512 = 7,188MiB
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 스토리지에 액세스할 수 있도록 하려면 `MountPoints`다음 `ContainerGroupDefinition` 속성을 설정합니다.
+ `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)를 참조하세요.
## 필수 컨테이너 지정
인스턴스당 컨테이너 그룹의 경우 각 컨테이너를 필수 또는 비필수로 지정합니다. 인스턴스당 컨테이너 그룹에는 하나 이상의 필수 지원 컨테이너가 있어야 합니다. 필수 컨테이너는 컨테이너 그룹의 중요한 작업을 수행합니다. 필수 컨테이너는 항상 실행 중일 것으로 예상됩니다. 실패하면 전체 컨테이너 그룹이 다시 시작됩니다.
각 컨테이너에 대해 `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` - 실패를 등록하기 전에 상태 확인 명령을 몇 번 재시도해야 하나요?
## 컨테이너 종속성 설정
각 컨테이너 그룹 내에서 컨테이너 상태에 따라 컨테이너 간에 종속성을 설정할 수 있습니다. 종속성은 종속 컨테이너가 다른 컨테이너의 상태에 따라 시작하거나 종료할 수 있는 경우에 영향을 줍니다.
종속성의 주요 사용 사례는 컨테이너 그룹에 대한 시작 및 종료 시퀀스를 생성하는 것입니다.
예를 들어 컨테이너 B와 C가 시작되기 전에 컨테이너 A를 먼저 시작하고 성공적으로 완료하도록 할 수 있습니다. 이렇게 하려면 먼저 컨테이너 A가 성공적으로 완료되어야 하는 조건으로 컨테이너 A에서 컨테이너 B에 대한 종속성을 생성합니다. 그런 다음 동일한 조건으로 컨테이너 A에서 컨테이너 C에 대한 종속성을 생성합니다. 시작 시퀀스는 종료의 역순으로 실행됩니다.
## 컨테이너 플릿 구성
컨테이너 플릿을 생성할 때 다음 결정 사항을 고려하세요. 대부분의 이러한 지점은 컨테이너 아키텍처 및 구성에 따라 달라집니다.
**플릿을 배포할 위치 결정**
일반적으로 플레이어 근처에 지리적으로 플릿을 배포하여 지연 시간을 최소화하려고 합니다. 가 Amazon GameLift Servers 지원하는에 컨테이너 플릿 AWS 리전 을 배포할 수 있습니다. 동일한 게임 서버를 추가 지리적 위치에 배포하려는 경우 AWS 리전 및 로컬 영역을 포함한 원격 위치를 플릿에 추가할 수 있습니다. 다중 위치 플릿의 경우 각 플릿 위치에서 독립적으로 용량을 조정할 수 있습니다. 지원되는 플릿 위치에 대한 자세한 내용은 [Amazon GameLift Servers 서비스 위치](gamelift-regions.md) 섹션을 참조하세요.
[UDP 핑 비콘](reference-udp-ping-beacons.md)을 사용하여 다양한 지리적 위치에서 네트워크 지연 시간 데이터를 수집하여 플레이어 디바이스와 잠재적 플릿 위치 간의 지연 시간을 예측할 수 있습니다. 이러한 특수 엔드포인트는 기존 ICMP 핑 대신 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)을(를) 참조하세요.
+ 스케일 다운 이벤트 중에 활성 플레이어가 있는 게임 세션이 조기에 종료되지 않도록 보호합니다.
+ 제한된 시간 내에 한 개인이 플릿에서 생성할 수 있는 게임 세션 수를 제한합니다.
# 스팟 플릿으로 게임 호스팅 비용 절감
Amazon GameLift Servers 관리형 호스팅을 사용하여 멀티플레이어 게임 서버를 호스팅할 때 스팟 인스턴스는 온디맨드 인스턴스에 대한 비용 효율적인 대안을 제공할 수 있습니다. 스팟 요금 모델은 온디맨드와 동일한 하드웨어 및 성능을 제공하지만 잠재적으로 상당한 비용 절감(최대 70\$190%)을 제공합니다. 그러나 제한 사항이 있습니다.에 용량이 다시 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 리전 또는 로컬 영역에 배포합니다. 스팟 실행 가능성 알고리즘은 인스턴스 유형과 위치 모두를 기반으로 실행 가능성을 평가합니다. 스팟 플릿 위치가 실행 불가능한 것으로 평가되는 경우 플릿의 다른 위치에 영향을 주지 않으며 게임 세션을 호스팅하는 데에도 여전히 사용할 수 있습니다.
+ **스팟 플릿 다양성을 사용하여 대기열 생성** - 게임 호스팅에 스팟 플릿을 사용하는 경우 게임 세션 배치 대기열을 설정해야 합니다. 각 새 게임 세션 요청에 대해 대기열은 사용 가능한 게임 호스팅 리소스를 찾고 가능한 최상의 옵션을 선택합니다. 스팟 플릿을 사용할 때에는 위치 및 인스턴스 유형 모두에서 서로 다른 여러 플릿을 검색할 수 있는 대기열이 필요하며, 적어도 하나 이상의 온디맨드 플릿을 백업 용량으로 포함해야 합니다. 다양한 배치 옵션을 제공하는 잘 설계된 다중 플릿 대기열은 중단, 속도 저하 및 장애에 대한 복원력이 뛰어납니다. 스팟용 대기열 설계에 대한 추가 지침은 [스팟 인스턴스를 위한 대기열 빌드](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는 플릿의 런타임 구성을 사용하여 각 인스턴스에서 실행할 프로세스의 유형과 수를 결정합니다. 런타임 구성에는 게임 서버 실행 파일 하나를 나타내는 서버 프로세스 구성이 하나 이상 포함되어 있습니다. 게임과 관련된 다른 유형의 프로세스를 실행하기 위해 추가 서버 프로세스 구성을 정의할 수 있습니다. 각 서버 프로세스 구성에는 다음 정보가 포함됩니다.
+ 게임 빌드에서 실행 파일의 파일 이름 및 경로
+ (선택 사항) 시작 시 프로세스에 전달할 파라미터
+ 동시에 실행할 프로세스 수
플릿의 인스턴스가 활성화되면 런타임 구성에 정의된 서버 프로세스의 집합이 시작됩니다. 여러 프로세스를 사용하는 경우 Amazon GameLift Servers는 각 프로세스의 시작을 시차를 두고 진행합니다. 서버 프로세스의 수명은 제한되어 있습니다. 작업이 끝나면 Amazon GameLift Servers는 런타임 구성에 정의된 서버 프로세스의 수와 유형을 유지하기 위해 새로운 프로세스를 시작합니다.
언제든 서버 프로세스 구성을 추가, 변경 또는 삭제하여 런타임 구성을 변경할 수 있습니다. 각 인스턴스는 플릿의 런타임 구성에 대한 업데이트를 정기적으로 확인하여 변경 사항을 구현합니다. Amazon GameLift Servers가 런타임 구성 변경을 채택하는 방식은 다음과 같습니다.
1. 인스턴스는 Amazon GameLift Servers에 최신 버전의 런타임 구성을 위한 요청을 전송합니다.
1. 인스턴스는 활성 프로세스를 최신 런타임 구성과 비교한 후, 다음을 수행합니다.
+ 업데이트된 런타임 구성에서 서버 프로세스 유형을 제거하면, 이 유형의 활성 서버 프로세스는 종료될 때까지 계속 실행됩니다. 인스턴스는 이러한 서버 프로세스를 대체하지 않습니다.
+ 업데이트된 런타임 구성에서 서버 프로세스 유형에 대한 동시 프로세스 수를 줄이면, 이 유형의 초과 서버 프로세스는 종료될 때까지 계속 실행됩니다. 인스턴스는 이러한 초과 서버 프로세스를 대체하지 않습니다.
+ 업데이트된 런타임 구성에서 새 서버 프로세스 유형을 추가하거나 기존 유형에 대한 동시 프로세스를 증가시키면, 인스턴스는 최대 Amazon GameLift Servers를 기준으로 새 서버 프로세스를 시작합니다. 이 경우 기존 프로세스가 종료되면 인스턴스가 새 서버 프로세스를 시작합니다.
## 여러 프로세스에 대한 플릿 최적화
플릿에서 여러 프로세스를 사용하려면 다음을 수행합니다.
+ 플릿에 배포하려는 게임 서버 실행 파일이 포함된 [빌드를 생성](gamelift-build-intro.md)한 다음 Amazon GameLift Servers에 빌드를 업로드합니다. 빌드의 모든 게임 서버는 동일한 플랫폼에서 실행되어야 하며 Amazon GameLift Servers용 서버 SDK를 사용해야 합니다.
+ 하나 이상의 서버 프로세스 구성과 여러 개의 동시 프로세스로 이루어진 런타임 구성을 생성합니다.
+ 게임 클라이언트를 AWS SDK 버전 2016-08-04 이상과 통합합니다.
플릿 성능을 최적화하려면 다음을 수행하는 것이 좋습니다.
+ Amazon GameLift Servers가 프로세스를 효율적으로 재활용할 수 있도록 서버 프로세스 종료 시나리오를 처리합니다. 예제:
+ 서버 API `ProcessEnding()`을 호출하는 게임 서버 코드에 종료 절차를 추가합니다.
+ 게임 서버 코드에 콜백 함수 `OnProcessTerminate()`를 구현하여 Amazon GameLift Servers의 종료 요청을 처리합니다.
+ 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 플릿에서 게임 서버 프로세스의 실행을 감독합니다. 에이전트는 플릿의 각 컴퓨팅에 배포되며 컴퓨팅에 대한 자동화된 프로세스 관리, 호스팅 관리 및 로깅을 제공합니다. 에이전트를 사용하려면 게임 서버 빌드가 Amazon GameLift Servers용 서버 SDK 버전 5.x 이상과 통합되어야 합니다.
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를 추상화하면 기존 플릿에서 새 플릿으로 플레이어 트래픽을 원활하게 전환할 수 있습니다.
+ 게임 클라이언트가 요청할 때 새 게임 세션을 생성하는 것 이외의 다른 작업을 수행하려는 경우, 예를 들어, 오래된 클라이언트를 이용하는 플레이어를 웹사이트 업그레이드로 연결해야할 수 있습니다.
별칭은 라우팅 전략을 지정해야 하며 두 가지의 유형이 있습니다. *단순* 라우팅 전략은 플레이어 트래픽을 지정된 플릿 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. (선택 사항) 별칭 리소스에 **태그**를 추가합니다. 각 태그는 사용자가 정의하는 키와 선택적 값으로 구성됩니다. 용도, 소유자, 환경 등의 기준에 따라 태그를 지정해 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 리전에서 별칭 리소스를 생성합니다(또는 다른 AWS 리전에 리전 태그 추가 지정 가능).
최소한 별칭 이름과 라우팅 전략을 포함해야 합니다. 단순 라우팅 전략의 경우 별칭과 동일한 리전에 있는 플릿의 ID를 지정합니다. 터미널 라우팅 전략의 경우 메시지 문자열을 제공합니다.
------