성공적인 게임 출시를 위한 Amazon GameLift Servers 사전 제작 단계 가이드 – Part1

멀티플레이어 게임을 개발하고 있다면, 전 세계적으로 게임 서버 플릿을 효율적으로 호스팅하고 확장하며 모니터링하는 방법을 찾고 계실 것입니다. 또한 최고의 플레이어 경험을 위해 플레이어와 가까운 최적의 위치의 게임 서버 플릿에 게임 세션을 효율적으로 배치하는 방법에 대해서도 고민하고 있을 것입니다. 게임 세션을 위해 필요한 인프라를 처음부터 구축하는 것은 부담스러울 수 있습니다.

Amazon GameLift Servers는 글로벌 게임 서버 호스팅을 위한 완전 관리형 서비스입니다. 오케스트레이션, 글로벌 세션 배치, 게임 세션 라이프사이클 관리 기능등을 제공하여 멀티플레이어 게임 출시의 운영 작업과 스트레스를 줄이는 데 도움이 됩니다.

이 블로그 시리즈에서는 성공적인 게임 출시를 준비하기 위한 주요 고려 사항을 다룰 것입니다. 이 첫 번째 블로그는 사전 제작 단계에서 취해야 할 조치에 중점을 두고, 두 번째 부분은 출시 전 준비 사항(출시 2-3개월 전)에 중점을 둡니다. 이러한 권장 사항은 초기 통합부터 게임 출시까지 수백 개의 게임 스튜디오를 지원한 경험을 바탕으로 작성되었습니다.

이 글의 내용을 읽을 때 다음과 같은 사전 지식이 도움이 됩니다.

• Amazon GameLift Servers 기본 사항에 대한 이해
• 게임 엔진 및 게임 개발에 대한 지식
• 멀티플레이어 네트워킹 개념에 대한 이해

그러면 게임 출시를 위한 초기 계획 단계에서의 다음의 네 가지 주요 영역을 살펴보겠습니다:

1. 게임 서버 테스트 및 인스턴스 유형 선택
2. 게임 세션 라이프사이클 관리 구성
3. 세션 배치를 위한 큐 및 큐 이벤트 활용
4. 모니터링, 로깅 및 알람 설정

게임 서버 테스트 및 인스턴스 유형 선택

게임 서버 테스트는 일반적으로 게임 서버를 로컬에서 테스트하는 것으로 시작됩니다. 작동하는 로컬 서버에서 검증이 성공적으로 수행되면, 다음 단계는 이를 Amazon GameLift Servers 플릿에 배포하고 서비스에서 성능을 테스트하는 것입니다.

올바른 인스턴스 유형과 크기를 식별하는 데 도움이 되는 측정해야 할 중요한 메트릭은 다음과 같습니다:

1. 리소스 소비량(CPU 집약적 대비 메모리 집약적)
2. 각 인스턴스에서 실행할 수 있는 게임 서버 컨테이너 또는 프로세스 개수
3. 최대 플레이어 로드에서 인스턴스의 게임 서버 성능

이 단계는 작은 플릿, 심지어 단일 리전의 인스턴스 하나로도 수행할 수 있습니다. 이 시점에서 리소스 격리를 위해 별도의 개발용 Amazon Web Services(AWS) 계정을 생성하는 것이 권장됩니다. 나중에 테스트 및 프로덕션과 같은 다른 환경을 추가할 수 있습니다. 플릿은 매우 선형적으로 확장되므로, 실제 테스터나 봇 클라이언트로 단일 인스턴스에 최대 플레이어 로드를 가하면 게임 서버가 어떻게 수행되는지에 대한 좋은 지표를 얻을 수 있습니다.

권장하는 플릿 유형은 컨테이너 플릿입니다. 컨테이너 플릿을 사용하면 각 게임 서버의 vCPU 및 메모리 요구 사항을 정의할 수 있습니다. Amazon GameLift Servers는 선택한 인스턴스 유형에 대해 가능한 한 많은 세션을 자동으로 배치합니다.

내장된 Amazon CloudWatch 메트릭은 게임 서버 메모리 및 CPU 제약 조건을 식별하는 데 도움이 됩니다. 이러한 테스트 시 사용량 데이터를 기반으로 조정하여 C-패밀리 인스턴스(더 많은 CPU가 필요한 경우), M-패밀리 인스턴스(메모리와 CPU 간의 균형을 위해), R-패밀리 인스턴스(더 많은 메모리가 필요한 경우) 중에서 선택할 수 있습니다. 대부분의 게임은 물리 시뮬레이션이 많은 CPU 리소스를 소비하므로 C-패밀리 또는 M-패밀리 인스턴스를 사용합니다.

Amazon GameLift Servers에서 지원하는 최신 세대 인스턴스는 최고의 가격 대비 성능을 제공합니다. ARM 기반 AWS Graviton 인스턴스를 활용하면 성능을 더욱 향상시킬 수 있습니다.

선택한 인스턴스 유형에 얼마나 많은 컨테이너(컨테이너 플릿의 경우) 또는 게임 서버 프로세스(Amazon Elastic Compute Cloud(Amazon EC2) 플릿의 경우)를 적재할 수 있는지 선택하려면, 실제 로드로 테스트하고 성능을 모니터링해야 합니다. 이는 테스트 그룹을 통한 게임 플레이나 사전 정의된 스크립트로 서버에 연결하여 자동으로 게임을 플레이하는 헤드리스 봇 클라이언트들을 이용하여 수행할 수 있습니다.

서버 상에서 로컬 봇으로 시뮬레이션하여 테스트하는 것은 성능에 대한 포괄적인 그림을 제공하지 않기 때문에, 이 테스트는 클라이언트와 서버 간에 실제 데이터 트래픽이 흐르는 상태에서 수행되어야 합니다. 여러 리전에 봇 클라이언트나 실제 테스터를 두는 것도 지리적 네트워크 트래픽 지연 시간이 성능에 미치는 영향에 대한 보다 현실적인 이해를 얻는 데 유용합니다.

그림 1은 Amazon CloudWatch 메트릭과 로그를 통해 성능을 모니터링하면서 게임 세션에 트래픽을 생성하는 봇 클라이언트를 보여줍니다. 컨테이너 플릿은 게임 서버 로그를 Amazon CloudWatch로 자동 푸시하며, Amazon EC2 플릿에서는 CloudWatch Agent를 사용하여 로그를 CloudWatch로 푸시할 수 있습니다.

게임 세션 라이프사이클 관리설정

게임 서버 프로세스의 라이프사이클에는 여러 핵심 요소가 있으며, 이 모든 것을 고려했는지 확인하는 것이 플릿을 정상 상태를 유지하는 데 필수적입니다. 이제 게임 서버 플릿에서 세션 관리 절차를 자세히 살펴보겠습니다.

시작 시 게임 서버 프로세스는 Amazon GameLift Servers와 통신을 설정하고 게임 세션을 호스팅할 준비가 되었다는 상태를 보고합니다.

게임 서버 프로세스는 다음 GameLift Server SDK를 통해 다음 작업을 순서대로 호출합니다.

1. 게임 서버 초기화
2. 서버 준비 상태 알림
3. 게임 서버 상태 평가
4. 게임 세션 이벤트 처리
5. 게임 세션 종료

1. 게임 서버 초기화

서버는 InitSDK 함수 호출로 시작합니다. 이 함수는 서버 프로세스를 인증하고 서버 프로세스를 Amazon GameLift Servers 오케스트레이션을 위해 준비합니다.

고려사항

• • Amazon GameLift Servers와의 통신을 신속하게 설정하기 위해 서버 프로세스 시작 중 InitSDK를 첫 번째 호출로 만드세요.
  • 실패가 조용히 넘어가는 것을 방지하고 플릿 모니터링을 지원하기 위해 SDK 초기화 오류를 로그에 기록하고 처리하세요.

2. 서버 준비 상태 알림

리소스와 게임 로직이 로드되면 ProcessReady 를 호출하여 프로세스가 게임 세션을 호스팅할 준비가 되었음을 Amazon GameLift Servers에 알립니다. 이 호출은 또한 게임 클라이언트가 게임 세션에 연결하는 데 사용하는 프로세스의 연결 정보를 보고합니다. Amazon GameLift Servers는 게임 서버 프로세스의 상태를 ACTIVE로 업데이트하고 새 게임 세션을 호스팅할 수 있게 됩니다.

고려사항

• • 모든 초기화가 완료된 후에만  ProcessReady 를 호출하고 중복 호출을 피하세요.
  • OnStartGameSession 및 OnHealthCheck 와 같은 모든 필수 콜백을 제공하고 적절한 오류 처리 및 재시도를 구현하세요.
  • EC2 플릿에서 정확한 로그 경로를 제공하여 Amazon GameLift Servers 콘솔이나 API를 통해 세션 로그에 액세스할 수 있는지 확인하세요.

3. 게임 서버 상태 평가

서버 프로세스가 ACTIVE로 설정되면 Amazon GameLift Servers는 주기적으로 OnhealthCheck 콜백을 호출하여 게임 서버 프로세스의 상태 보고를 요청하기 시작합니다. 프로세스가 비정상이라고 보고하거나 상태 확인에 응답하지 않으면, 서비스는 프로세스의 활성 상태를 변경하고 새 프로세스로 교체합니다.

고려사항

• • 서버 SDK 연동 시 견고한 OnHealthCheck 콜백을 구현하여, true로 응답하기 전에 서버가 정상인지 적절히 검증하세요.

4. 게임 세션 이벤트 처리

플레이어가 게임 참여를 요청하면 게임 클라이언트는 백엔드 서비스에 요청을 보내고, 백엔드 서비스는 새 세션을 시작하기 위해 StartGameSessionPlacement 또는 CreateGameSession을 호출할 수 있습니다. 서비스는 사용 가능한 서버 프로세스를 찾기 위해 플릿을 검색합니다. 찾으면 게임 세션을 생성하고 OnStartGameSession 콜백을 호출합니다. 그러면 서버는 준비가 되면 ActivateGameSession을 호출하고, Amazon GameLift는 세션을 PENDING에서 ACTIVE로 업데이트하여 배치를 완료합니다.

고려사항

• • OnStartGameSesion을 받은 후에만 플레이어가 연결하도록 하세요. Amazon GameLift Servers는 서버 프로세스가 새 게임 세션 호스팅을 시작하기를 원할 때 이 콜백을 호출합니다. 이렇게 하면 실제 게임 로드 이전에 서버에 대한 탐지 연결 문제를 줄일 수 있습니다.
  • 게임 맵, 기타 구성을 적절히 설정하고 세션을 호스팅할 완전한 준비가 된 후에만 OnStartGameSession 콜백에서 ActivateGameSession을 호출하세요. ActivateGameSession을 호출하면 서버가 새 게임 세션을 호스팅하기 위한 초기화를 완료했으며 이제 플레이어 연결을 설정하기 위한 수신 트래픽을 받을 준비가 되었음을 Amazon GameLift 서비스에 알립니다.
  • 프로세스가 몇일 동안 세션 배치를 기다리고 있을 때, Health Check 시 모든 시스템이 여전히 올바르게 작동하는지 확인하세요. 이는 미리 플릿을 설정했지만 나중에 프로덕션 트래픽을 받는 경우와 하루 중 시간에 따라 플레이어 트래픽이 변경되는 경우에 적용됩니다. 일부 위치(GameLift Location)는 세션 배치를 받지 않는 시간이 있을 수 있습니다.

5. 게임 세션 종료

게임 세션이 끝나면 서버 프로세스는 Amazon GameLift Servers에 게임 세션 상태를 알립니다. 게임 서버 프로세스는 서버 SDK의 ProcessEnding 함수를 호출하여 종료를 시작합니다. 게임 세션 종료의 일부로 Amazon GameLift Servers는 게임 세션과 서버 프로세스 상태를 TERMINATED로 변경합니다.

고려사항

• • OnStartGameSession이 호출되어 게임 세션이 서버에 배치되었지만 플레이어가 연결하지 않거나 연결이 끊어진 경우를 위한 백업 프로세스 종료 메커니즘을 구현하세요. 이러한 상황에서 프로세스가 올바르게 종료되고 새로운 게임 서버로 교체되도록 해야 합니다.
  • 여러 세션에 대해 서버 프로세스를 재사용하지 마세요. 세션이 끝나면 ProcessEnding 을 호출하고 종료하세요. 이렇게 하면 즉시 새 프로세스의 생성과 등록이 트리거됩니다.
  • 서버가 종료될 수 있는 모든 경로에서 Amazon GameLift Servers SDK의 ProcessEnding을 호출하세요. 이렇게 하면 기존 게임 세션이 적절히 정리되고 즉시 새 세션으로 교체됩니다.

그림 2는 게임 서버 프로세스의 라이프사이클과 모든 게임 서버 구현에서 고려해야 할 주요 단계를 보여줍니다.

세션 배치를 위한 큐 및 큐 이벤트 활용

Amazon GameLift Servers 큐를 이용하면 플릿에 대해 직접 세션을 생성하는 것보다 여러 이점을 제공합니다.

큐는 다음의 기능들을 제공합니다

1. 첫 번째 플릿을 사용할 수 없는 경우 다음 순위의 플릿 위치로 장애 조치 가능
2. 여러 플릿에 걸쳐 세션 배치 가능
3. 백엔드에서 수신하여 처리할 수 있는 세션 배치 이벤트 제공
4. 지연 시간과 비용을 기반으로 배치 대상 우선순위 지정

큐를 사용할 때 StartGameSessionPlacement 호출이 사용해야 하는 유일한 API이며, 나머지는 큐 이벤트를 통해 관리됩니다.

큐 사용 시 모범 사례

1. 적절한 용량을 찾을 수 없는 경우 배치가 실패로 간주되는 시점을 정의하는 큐 타임아웃을 설정하세요.
2. 큐에 플레이어 지연 시간을 제공하는 경우 플레이어 지연 시간 정책을 설정하세요. 여기서 설정하는 제한이 현실적인지 확인하여, 대부분의 매치에서 게임의 일부 플레이어가 해당 지역 조건을 충족될 수 없어 오랜 시간을 기다리지 않도록 하세요. 플레이어 지연 시간 정책이 없어도 큐에 지연 시간 데이터를 제공할 때마다 이 정보를 기반으로 세션이 배치됩니다. 기본 동작은 평균을 기준으로 작동하여 플레이어 지연 시간 정책은 어떤 플레이어도 최대 지연 시간 제한을 초과하지 않도록 보장합니다.
3. 게임 세션 배치 우선순위를 정의하세요. 대부분의 요구사항에 대해서는 등록된 모든 플릿에서 지연 시간을 우선시한 다음 비용을 우선시하는 기본 동작을 권장합니다. 그러나 지연 시간 품질에 관계없이 Amazon GameLift Anywhere 플릿 리소스를 먼저 활용하려는 경우에는 해당 대상(Destination)을 첫 번째 우선순위로 설정하세요.

큐 이벤트 사용 모범 사례

1. 게임 세션 배치 이벤트 알림을 받기 위해 Amazon Simple Notification Service(Amazon SNS) 토픽을 등록하거나 Amazon EventBridge를 사용하세요.
2. 이벤트에 AWS Lambda 함수를 등록하고 Amazon DynamoDB와 같은 데이터베이스에 이벤트 데이터를 저장하거나 WebSocket을 통해 플레이어에게 직접 업데이트를 보낼 수 있습니다. 이벤트 사용은 Describe API 사용과 달리 확장성이 매우 뛰어납니다.

그림 3은 게임 세션 배치를 위한 Amazon GameLift Servers 큐 활용과 Amazon SNS 토픽 구독을 통한 이벤트 처리를 위한 표준 아키텍처를 보여줍니다.

지연 시간 정책을 사용하지 않고 정확한 위치 기본 설정으로 세션을 배치해야 하는 경우, StartGameSessionPlacement 요청에서 Priority Configuration Override를 정의할 수 있습니다. 이는 게임 디자인에서 플레이어에게 특정 위치를 선택하거나 우선순위 위치 목록에서 선택할 수 있는 기능을 제공하는 경우 유용합니다. 또한 매치메이커가 각 위치의 지연 시간을 개별적으로 제공하는 대신 우선순위 목록을 제공하는 경우에도 유용합니다.

매치메이커로 Amazon GameLift Servers FlexMatch를 사용하는 경우, 정의한 큐와 기본적으로 통합됩니다. 그러면 세션 배치 프로세스를 추적하기 위해 큐 이벤트 대신 FlexMatch 이벤트를 사용할 수 있습니다.

메트릭, 로깅 및 알람 설정

관찰 가능성은 환경에서 무슨 일이 일어나고 있는지 이해하는 데 핵심입니다. Amazon GameLift Servers는 이를 도와주는 여러 기본 기능들을 제공합니다. 세 가지 주요 측면인 로그, 모니터링 및 알람을 다루겠습니다.

로그

컨테이너 플릿에서는 추가 도구나 서비스 없이 게임 서버 출력을 Amazon CloudWatch 또는 Amazon Simple Storage Service(Amazon S3)로 전송하도록 구성할 수 있습니다. 디버깅 시 올바른 로그 파일을 검색할 수 있도록 게임 서버의 출력에 게임 세션 ID를 작성해야 합니다. EC2 플릿에서는 게임 세션이 종료된 후 14일 이내에 로그 파일을 다운로드할 수 있습니다. EC2 플릿에서도 Amazon CloudWatch로 로그를 푸시하려면, Amazon CloudWatch Agent 설정을 위해 AWS Game Backend Framework 가이던스의 Amazon GameLift Servers 통합을 참고하시기 바랍니다.

게임 서버 프로세스에서 로그 출력을 생성할 때, 로깅 시스템에서 로깅의 세부 수준을 정의할 수 있는 것이 좋습니다. 개발에서는 더 자세한 로깅을 사용하고 프로덕션에서는 수집되는 데이터 양을 줄일 수 있습니다. JSON 형식과 같은 구조화된 로그 출력은 CloudWatch 쿼리 기능을 활용하는 데 도움이 될 수 있습니다.

또한 사이드카 컨테이너를 실행하거나 EC2 플릿의 경우 인스턴스에서 백그라운드 에이전트를 실행하여 로그 출력을 모든 타사 로그 관리 도구로 전송할 수 있습니다.

메트릭

Amazon GameLift Servers는 광범위한 CloudWatch 메트릭을 제공합니다. 여기에는 플릿의 인스턴스 및 게임 세션에 대한 정보, 큐의 배치 시간, 리소스 활용 메트릭 등이 포함됩니다. 이러한 메트릭은 Amazon GameLift Servers 콘솔과 CloudWatch에서 직접 사용할 수 있습니다.

모니터링할 주요 메트릭

1. 리소스 활용률: CPUutilization,  MemoryUtilization (컨테이너 플릿용), 그리고 NetworkIn/NetworkOut.  . 이러한 메트릭은 게임 서버 프로세스의 성능과 리소스 활용량에 대한 개요를 제공합니다.
2. 세션 가용성: PercentAvailableGameSessions, AvailableGameSessions. 이러한 메트릭은 플릿의 상태와 새 세션을 배치할 수 있는 용량을 나타냅니다.
3. 잠재적 문제: UnhealthyInstanceReplaced , ServerProcessAbnormalTerminations. 이러한 메트릭은 인스턴스가 계속 작동할 리소스가 부족하거나 프로세스가 올바르게 종료되지 않는 문제를 나타냅니다.
4. 큐 메트릭: AverageWaitTime, PlacementsFailed , PlacementsTimeOut. 이러한 메트릭은 큐의 상태에 대한 지표를 제공합니다. 플레이어가 매치에 얼마나 빨리 배치되는지, 배치가 얼마나 자주 실패하는지를 보여줍니다.

로그와 마찬가지로 사이드카 컨테이너를 사용하거나 EC2 플릿의 에이전트를 사용하여 다른 시스템에 대한 고객 메트릭을 수집할 수 있습니다. 예를 들어 OpenTelemetry 에이전트와 같은 도구나 서비스를 사용하여 Prometheus 인스턴스에서 메트릭을 수집하여 Grafana로 시각화할 수 있습니다.

알람

알람은 게임 백엔드에 문제가 있음을 운영 팀에 알리는 메커니즘입니다. 가능한 문제를 나타내는 메트릭에 대해 적절한 알람을 생성해야 합니다. 여기에는 PercentAvailableGameSessions (낮거나 0인 경우), ServerProcessAbnormalTerminations, UnhealthyInstancesReplaced, PlacementsFailed 및 필요에 따른 기타 메트릭이 포함됩니다. 또한 CloudWatch Logs에서 메트릭을 추출하고 추출된 메트릭을 기반으로 알람을 생성할 수 있습니다. 로그에서 메트릭을 빠르게 추출하려면 JSON 형식이 권장됩니다.

그림 4는 CloudWatch의 메트릭과 로그를 활용하여 알람을 생성하고 문제에 대해 대기 중인 팀에 알리는 방법의 예를 보여줍니다. Prometheus로 메트릭을 수집하고 Grafana로 시각화하는 경우에도 유사한 접근 방식을 사용할 수 있습니다.

본 블로그에서는 게임 서버 호스팅을 위해 Amazon GameLift Servers를 사용하여 성공적인 게임 출시를 위한 운영 준비의 출발점을 다뤘습니다. 올바른 인스턴스 유형과 서버 프로세스 또는 컨테이너 패킹을 선택하는 것이 어떻게 성능이 우수하고 비용 최적화된 구성을 보장할 수 있는지 논의했습니다. 또한 모든 아키텍처가 잘 제어되고 이벤트 기반 세션 배치를 위해 큐를 활용해야 하는 방법도 고려했습니다. 마지막으로 로그, 모니터링 및 알람 설정이 문제를 식별하고 게임 서버의 성능에 대한 정보를 수집하는 데 어떻게 도움이 되는지 논의했습니다.

시리즈의 두 번째 블로그인 ‘Amazon GameLift Servers에서 성공적인 출시를 위한 출시 단계 단계’에서는 게임 출시 준비에 대해 더 자세히 살펴보겠습니다.

멀티플레이어 게임 서버 호스팅을 위한 Amazon GameLift Servers로 오늘 시작하세요. 비즈니스 가속화를 위한 지원 방법에 대해 알아보려면 AWS 담당자에게 문의하세요.

• 게임 출시 준비
• Amazon GameLift, 게임당 1억 명의 동시 연결 사용자 달성
• AWS Graviton EC2 인스턴스용 Unreal Engine 5 전용 서버 컴파일