성공적인 게임 출시를 위한 Amazon GameLift Servers 런칭 단계 가이드 – Part2

게임의 인기가 빠르게 확산될 때 처음부터 성공을 위한 준비가 되어 있는 것이 중요합니다. 이 블로그 글은 Amazon GameLift Servers에서 멀티플레이어 게임을 출시할 때 고려해야 할 중요한 영역들을 다룹니다. 게임 출시 2-3개월 전에 필요한 활동들에 중점을 둘 것입니다. 이는 게임의 완전한 공개 출시일 수도 있지만, 오픈 베타, 얼리 액세스 또는 실제 플레이어가 있는 기타 이벤트들을 의미할 수도 있습니다.

게임 출시를 위한 최종 계획의 다음의 다섯 가지 핵심 영역을 검토하겠습니다.

1. 출시 설문지 작성과 한도 상향 요청
2. 프로덕션 플릿 설정
3. 부하 테스트와 크리티컬 패스 검증
4. API 스로틀링 모니터링
5. 새로운 게임 서버 버전 배포를 위해 프로덕션에서 Blue/Green 배포 사용

1– 출시 설문지 작성과 한도 상향요청

게임 출시를 위한 이벤트 (오픈 베타, 얼리 액세스, 그리고 최종적으로 완전한 게임 출시 등)를 가능하게 하는 핵심 요소 중 하나는 필요에 맞게 서비스 한도를 증가시키는 것입니다. Amazon GameLift Servers의 기본 서비스 한도는 초기 개발 단계에서 실수로 확장되는 것을 방지하기 위해 설정되어 있습니다. 플레이어를 적극적으로 지원할 준비가 되면, 플레이어 부하를 지원하는 데 필요한 인프라를 제공하기 위해 더 높은 한도가 필요할 수 있습니다.

출시 설문지는 Amazon GameLift Servers 콘솔의 왼쪽 메뉴에서 리소스 아래 출시 준비를 선택하면 찾을 수 있습니다. 이는 선택한 인스턴스 유형에 대한 인스턴스 한도와 Amazon GameLift Servers API의 스로틀링 한도를 모두 다룹니다.

설문지를 작성할 때 고려해야 할 주요 사항들

1. 출시 마일스톤 2-3개월 전에 미리 작성하세요.
2. 베타나 비공개 프리뷰도 여전히 출시이므로, 이를 위해서도 한도 증가가 필요합니다. 다음 마일스톤을 위해 언제든지 업데이트 된 출시 설문지를 보낼 수 있습니다.
3. 다중 위치 플릿에는 홈 리전과 추가 위치들이 있습니다. 플릿의 홈 리전을 정의하고 선택된 홈 리전에 대해 각 위치의 한도를 요청하는 것을 기억하세요. 위치별 인스턴스 한도는 각 홈 리전 수준에서 별도로 설정됩니다.
4. 사용하고 있는 정확한 Amazon GameLift API를 검토하고, 예상되는 최대 요청 비율에 맞춰 한도 증가를 요청하세요. 게임 세션 생성 플로우에서 Describe API 사용을 피하세요. 이러한 컨트롤 플레인 API는 일반적으로 모든 플레이어 요청에 대해 자주 호출되도록 설계되지 않았습니다. 이러한 API를 호출해야 하는 경우, Amazon GameLift Servers에서 지속적 월드 게임 호스팅에서 논의된 대로 중앙 집중식으로 수행할 수 있습니다.
5. 필요한 모든 Amazon Web Services (AWS) 계정에 대한 한도를 요청하세요. 여기에는 프로덕션, 테스트 및 부하 테스트 계정이 포함될 수 있습니다.

설문지를 보낼 때, 담당 AWS 어카운트 팀이 있다면 이메일에 추가하여 모든 사람이 같은 정보를 공유하도록 하세요.

그림 1은 Amazon GameLift Servers 콘솔에서 출시 설문지를 찾는 위치를 보여줍니다.

2 – 프로덕션 플릿 설정

Amazon GameLift Servers의 프로덕션 환경의 플릿은 개발 환경의 플릿과 다르게 구성하는 것을 권장합니다.

주요 고려사항

1. 게임 스케일링 보호 정책을 완전 보호로 설정하세요. 이렇게 하면 플릿이 축소될 때 실행 중인 게임 세션이 보호됩니다.
2. 대상 기반(Target-based) 자동 스케일링 정책을 활성화하고, 출시일에 대비해 충분한 여유분을 확보하세요(최대 30-50%). 트래픽이 안정화되면 나중에 언제든지 이를 줄일 수 있습니다.
3. 각 리전별로 개별 플릿 대신 다중 위치 플릿을 사용하세요. 이는 글로벌 플릿 리소스에 대한 단일 뷰를 제공하고 운영 복잡성을 줄여 운영을 크게 간소화합니다.
4. 지연 시간 목표와 플레이어 인구를 고려하여 그에 따라 위치를 선택하세요. 낮은 지연 시간이 필요한 1인칭 슈터 게임은 일반적으로 각 대륙마다 여러 위치가 필요합니다. 빠른 응답 속도가 필요하지 않는 게임은 간소화된 운영을 위해 더 적은 수의 위치들을 사용하여도 이점을 얻을 수 있습니다. 클라이언트 측에서 지연 시간을 측정하기 위해 Amazon GameLift에서 제공하는 UDP 핑 비콘을 사용할 수 있습니다.
5. 각 위치에 대한 스케일링 구성(최소 및 최대)을 설정하고, 각 위치에 충분한 기준선(최소)과 급격한 수요 증가에 대비한 여유(최대)를 확보하세요.

출시일에는 각 위치의 최소값을 초기 트래픽 피크를 커버할 수 있을 만큼 높은 기준선으로 설정하여 미리 확장하는 것을 권장합니다. 트래픽 패턴이 안정화되면 언제든지 이 값을 더 낮은 숫자로 설정할 수 있지만, 높은 초기 출시 피크에 대비하는 것이 좋습니다.

두개 이상의 인스턴스 유형을 사용하여 예상치 못한 플레이어 부하에 대응하여 게임 서버를 호스팅할 수 있도록 준비하세요. 예를 들어, 선택한 인스턴스 패밀리의 .large 및 .xlarge 변형이거나, 동일한 인스턴스 패밀리 내의 다른 인스턴스 패밀리 또는 세대일 수 있습니다. 대부분의 게임은 여러 플릿을 호스팅할 필요가 없지만, 대규모의 서버플릿이 필요한 경우 다중 플릿 전략을 옵션으로 갖는 것이 필요한 용량을 확보하는 데 도움이 될 수 있습니다.

그림 2는 두 개의 다중 위치 플릿이 동일한 Amazon GameLift Servers 큐에 등록된 구성을 보여줍니다. 한 플릿은 C6i.large 인스턴스 유형을 사용하며 게임 출시를 처리하기 위해 확장되어 있습니다. 두 번째 플릿은 C5.large 인스턴스 유형을 사용하며 아직 확장되지 않았습니다. 두 인스턴스 유형의 한도는 모두 출시 설문지를 통해 프로덕션 트래픽을 처리할 수 있도록 증가되었습니다. 드문 상황이지만 만약 위치 중 하나에서 C6i.large 가용성이 낮은 경우, 백업 플릿을 사용하면 다른 인스턴스 유형으로 확장하여 플레이어에게 계속 서비스를 제공할 수 있습니다. 백업 플릿은 C6i.xlarge와 같은 C6i 패밀리의 다른 인스턴스 크기일 수도 있습니다.

3 – 부하 테스트와 크리티컬 패스 검증

부하 테스트는 인프라의 병목 지점을 찾아내는 데 중요합니다. 출시 준비를 위한 가장 중요한 단계 중 하나입니다.

Amazon GameLift Server의 경우 부하 테스트를 통해 다음을 발견할 수 있습니다.

1. 불충분한 인스턴스 한도
2. 불충분한 API 한도 (각 API별로 개별 적용)
3. 게임 서버가 통신하는 백엔드 시스템과 같은 종속성 단에서의 문제

대규모의 현실적인 트래픽 패턴으로 부하 테스트를 구현하면 이러한 문제들을 발견하는 데 도움이 됩니다. 이는 높은 동시 사용자 수로 들어오는 것처럼 모든 위치에서 세션 배치 요청을 증가시키고, 모든 시스템이 예상대로 작동하는지 확인하는 것을 의미합니다.

5분 만에 동시 사용자 0명에서 50만 명으로 확장 테스트하는 것은 이론적으로는 좋은 테스트처럼 들리지만, 현실적인 트래픽 패턴을 나타내지 않을 수 있습니다. 현실적인 패턴으로 테스트하면 기대치를 과도하게 설정하지 않는 데 도움이 됩니다. 최고점까지의 증가는 일반적으로 더 긴 시간(보통 몇 시간에 걸쳐) 동안 발생하며, 이전 게임의 데이터나 SteamDB와 같은 도구를 사용하여 출시 시 일반적인 트래픽 패턴을 확인할 수 있습니다.

부하 테스트를 수행하는 두 가지 주요 방법이 있습니다.

1. 플릿 스케일링과 세션 배치 테스트는 StartGameSessionPlacement와 같은 API를 직접 호출하여 수행할 수 있습니다. 상대적으로 적은 수의 실제 클라이언트들과 함께 Python이나 Bash 스크립트를 사용하여 수행할 수 있습니다. 이는 API와 인스턴스 한도, 그리고 스케일링 구성에 대한 훌륭한 스모크 테스트입니다.
2. 게임 서버뿐만 아니라 전체적인 중요 경로(백엔드 포함)를 테스트 하세요. 이 접근 방식에는 실제 계정 생성과 게임 로그인, 그리고 백엔드를 사용한 매치메이킹이나 세션 배치 요청이 포함됩니다. 백엔드의 병목 지점도 테스트하는 더 전체적인 부하 테스트 방식입니다. 이 테스트 수행 시 게임의 헤드리스 봇 클라이언트(예: AWS Fargate 컨테이너에서 실행) 또는 클라이언트와 최대한 유사하게 작동하는 스크립트로 수행하는 것을 권장합니다.

전체적인 테스트를 수행할 때는 클라이언트가 게임 서버에 연결하여 일반 플레이어가 하는 것처럼 이동 및 기타 행동을 전송하며 게임을 플레이하도록 하는 것이 최적입니다. 이는 게임 서버의 성능도 스트레스 테스트할 수 있습니다. 또한 클라이언트가 세션을 플레이하고 로그아웃하여 다음 세션에 연결할 때 현실적인 세션 길이와 게임 세션 로테이션을 테스트하는 데 도움이 됩니다.

이러한 테스트의 성공적인 모니터링을 위해서는 이 블로그 시리즈의 첫 번째 부분인 Amazon GameLift Servers에서 성공적인 출시를 위한 개발 단계 단계의 모니터링, 로깅 및 알람 섹션에서 다룬 접근 방식을 사용하세요. 또한 Amazon GameLift Servers API와 귀하 또는 제3자가 관리하는 기타 서비스 및 구성 요소에서 받는 모든 오류와 스로틀링을 추적해야 합니다. 이에 대해서는 섹션 4 – API 스로틀링 모니터링에서 자세히 다루겠습니다.

Werner Vogels (Amazon CTO)가 “실패는 주어진 것이고 모든 것은 결국 시간이 지나면 실패할 것입니다”라고 말했듯이, 주요 경로에서 모든 종속성(Steam, 콘솔 로그인, 데이터베이스 등)의 실패를 우아하게 처리할 수 있도록 하세요. 또한 내부 실패로부터 복구할 수 있다는 확신을 가져야 합니다. 이는 출시일의 예상치 못한 상황에 대비하는 데 도움이 됩니다.

그림 3은 여러 Amazon Elastic Container Service(Amazon ECS) 작업을 실행하는 서비스로 AWS Fargate에서 부하 테스트 클라이언트를 호스팅하는 예시를 보여주며, 각 작업은 최대 10개의 개별 클라이언트 컨테이너를 호스팅할 수 있습니다. 부하 테스트 클라이언트는 여러 AWS 리전에서 실행되어 지연 시간과 플레이어 위치가 경험에 미치는 영향을 테스트할 수 있습니다. 클라이언트는 실제 게임 클라이언트의 스크립트 기반 헤드리스 버전이거나 게임 클라이언트처럼 작동하는 스크립트일 수 있습니다.

4 – API 스로틀링 모니터링

부하 테스트 도중에 Amazon GameLift Servers API 호출이 기본 프로비저닝된 한도를 초과하여 스로틀링(Throttling) 오류가 발생할 수 있습니다. 스로틀링이 발생한 호출을 식별하고 대응하는 것은 운영 안정성, 가용성 및 원활한 플레이어 경험을 보장하는 데 있어서 중요합니다.

AWS CloudTrail은 Amazon GameLift Servers에 대한 포괄적인 API 이벤트 추적 기능을 제공합니다. 이를 이용하여 모든 API 사용을 모니터링하고 감사할 수 있습니다.

CloudTrail을 효과적으로 사용하여 다음을 수행할 수 있습니다.

• Amazon GameLift Servers API 활동 추적
• 스로틀링 식별
• 사용자 정의 CloudWatch 메트릭에 대한 알람 구성
• 예상되는 최대 요청 비율에 맞는 한도 증가를 요청하도록 운영 팀에 알림

• errorCode가 ThrottlingException
• errorCode가 RequestLimitExceeded
• errorMessage가 RateExceeded

운영 가시성을 위해 CloudTrail에서 새 트레일을 생성하고 CloudWatch 로그를 활성화하세요. CloudWatch 로그에 로그를 작성할 수 있는 올바른 AWS Identity and Access Management (IAM) 권한이 있는지 확인하세요. Amazon GameLift 이벤트를 캡처할 CloudWatch 로그 그룹을 지정하세요. 구성이 완료되면 CloudWatch 로그에서 모든 Amazon GameLift API 호출과 관련된 스로틀링 오류를 확인할 수 있습니다.

CloudWatch 로그에서 CloudTrail이 로그를 작성하는 데 사용하는 로그 그룹을 선택하고 스로틀링 패턴을 식별하기 위한 사용자 정의 메트릭 필터를 생성하세요. 네임스페이스를 할당하고 스로틀링이 발생할 때마다 증가하는 사용자 정의 메트릭을 생성해야 합니다.

다음은 필터 패턴의 예시입니다.

{ ($.eventSource = "gamelift.amazonaws.com") && ($.errorCode = "ThrottlingException") }

사용자 정의 메트릭이 설정되었으면 이제 스로틀링 임계값을 모니터링하기 위한 CloudWatch 알람을 구성하세요. 예를 들어, 5분 기간 내에 10개 이상의 스로틀된 요청이 발생하면 알람을 트리거하세요. 생성된 알람을 운영 팀에 이메일, 단문 메시지 서비스(SMS) 또는 채팅 알림을 보내는 Amazon Simple Notification Service(Amazon SNS) 주제에 연결하세요. 그러면 운영 팀이 API 사용량을 검토해서 그에 따라 조치를 취할 수 있습니다.

한도 증가를 요청하기 전에 스로틀링을 최소화하려면

• Amazon GameLift Servers API 호출에 지수 백오프 (exponential backoff) 구현
• Amazon GameLift Servers API에서 대용량 데이터셋을 검색할 때 페이지네이션(pagination)과 필터링 사용
• 반복적인 API 호출을 피하기 위해 플릿 정보와 같이 자주 액세스하는 데이터를 캐싱
• API 호출 빈도를 줄이기 위해 가능한 배치 작업으로 수행

5 – 새 게임 서버 버전의 프로덕션 배포 시 블루/그린 배포 활용

프로덕션에 성공적으로 게임을 런칭하면, 처음에는 게임 서버를 상대적으로 자주 패치해야 하고, 지속적으로 게임에 기능과 개선 사항을 추가하면서 패치해야 합니다. Amazon GameLift Servers에서 업데이트를 수행하는 권장 방법은 Blue/Green 배포입니다.

이 접근 방식에서는 새로운 게임 서버 빌드 또는 컨테이너 이미지로 완전히 새로운 프로덕션 플릿을 설정합니다. 새 플릿이 준비되고 모니터링을 통해 문제가 없으면, 몇 개의 게임 세션으로 스모크 테스트를 수행하는 추가 단계를 가질 수 있습니다. 이후 Amazon GameLift Servers 큐 설정에서 세션 배치를 기존 플릿 대신 새 플릿으로 전환하여 라우팅하는 인플라이트(inflight) 업데이트를 수행합니다. 신규 세션은 새 버전의 플릿에서 생성되기 시작하지만, 기존 플릿에서 실행 중인 세션은 중단 없이 계속 실행될 수 있습니다.

모든 것이 정상적으로 보이면 세션이 모두 소진된 후 기존 플릿을 종료할 수 있습니다. 이전 버전으로 롤백해야 하는 경우, 큐 설정에서 대상을 전환하여 기존 버전으로 다시 전환할 수 있습니다. 이는 Blue/Green 배포의 주요 이점 중 하나입니다.

세션 배치에 큐를 사용하지 않는 경우, 별칭(Alias) 리소스를 유사한 방식으로 사용할 수 있습니다. Amazon GameLift Servers 툴킷에는 이 접근 방식을 구현하는 방법을 보여주는 Python 스크립트가 제공됩니다.

그림 4는 큐 뒤단의 플릿이 새 플릿으로 교체되고, 이전 플릿에서 기존 세션이 소진되는 Blue/Green 배포를 보여줍니다.

본 블로그에서는 Amazon GameLift Servers에서 성공적인 프로덕션 출시를 위해 서비스 한도를 확장하는 방법을 다뤘습니다. 그 다음 프로덕션 플릿 설정을 위한 주요 고려사항들을 논의하였습니다. 또한 부하 테스트가 출시 준비에 어떻게 도움이 되는지, 그리고 부하 테스트를 수행하는 일반적인 방법들에 대해서도 다뤘습니다. 마지막으로 Blue/Green 배포가 프로덕션에서 인플라이트 서버 버전 업데이트를 관리하는 데 어떻게 도움이 되는지 논의하였습니다.

이 시리즈는 Amazon GameLift Servers에서 성공적인 게임 출시를 위해 운영측면에서 그리고 아키텍처 측면에서 준비하는 다양한 영역들을 다루었습니다. 멀티플레이어 게임 서버 호스팅을 위해 오늘 Amazon GameLift Servers로 시작하세요. 비즈니스 가속화에 어떻게 도움을 드릴 수 있는지 알아보려면 AWS 담당자에게 문의하세요.

• 게임 출시 준비
• Amazon GameLift가 게임당 1억 명의 동시 연결 사용자 달성
• Amazon GameLift Servers에서 지속적 월드 게임 호스팅