기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

GAMEOPS03-BP04 플레이어에게 미치는 영향을 최소화하는 배포 전략 채택

플레이어를 게임에서 차단하는 가동 중지 시간을 최소화하는 게임 소프트웨어 및 인프라에 대한 배포 전략을 통합합니다. 특정 유형의 업데이트에는 게임 클라이언트에 새 업데이트를 설치해야 할 수 있지만 배포 중에 가동 중지 시간이 필요하지 않도록 게임을 설계합니다.

이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준: 높음

구현 지침

게임 배포 전략을 개발할 때 고려해야 할 가장 중요한 단계 중 하나는 게임 인프라를 관리하는 방법을 결정하는 것입니다. Hashicorp의 또는 Terraform과 같은 AWS CloudFormation 코드형 인프라(IaC) 도구를 사용하여 게임 인프라를 관리하여 환경 준비 중에 인적 오류를 줄입니다. 인프라 템플릿은 자동화된 파이프라인에 배포 및 테스트할 수 있으므로 다양한 게임 환경의 구성에서 일관성을 유지할 수 있습니다.

게임에 사용할 수 있는 몇 가지 배포 전략이 있습니다.

롤링 대체

배포를 위한 롤링 대체의 주요 목표는 게임을 종료하지 않고 플레이어에게 영향을 주지 않고 릴리스를 수행하는 것입니다. 수행할 업그레이드 또는 변경 사항은 이전 버전과 호환되며 이전 버전의 시스템과 인접하여 작동하는 것이 중요합니다.

이 배포에서는 서버 인스턴스가 업데이트된 버전을 실행하는 인스턴스로 점진적으로 교체(대체 또는 롤아웃)됩니다. 이 롤링 대체는 몇 가지 방법으로 수행할 수 있습니다. 예를 들어 전용 게임 서버 플릿에 롤링 업데이트를 구현하기 위해 일반적인 접근 방식에는 배포된 새 게임 서버 빌드 버전이 포함된 새 Auto Scaling EC2 인스턴스 그룹을 생성한 다음이 새 서버 플릿에서 호스팅되는 게임 세션으로 플레이어를 점진적으로 라우팅하는 것이 포함됩니다. 새 게임 서버 빌드를 사용하기 위한 사전 조건으로 필요한 연결된 게임 클라이언트 업데이트가 있는 경우이 새 게임 클라이언트 업데이트가 설치된 플레이어만 이러한 게임 세션으로 라우팅되는지 확인하는 검증 검사를 포함해야 합니다.

이전 게임 서버 빌드 버전이 포함된 서버 플릿(예: EC2 Auto Scaling 그룹)은 일반적으로 게임 운영 팀이이 프로세스를 자동화할 수 있도록 개별화된 서버 지표를 설정하여 활성 플레이어 세션이 고갈된 후에만 서비스에서 제거됩니다. 또는 인프라 양과 롤링 배포 수행 시간을 줄이기 위해 기존 프로덕션 인스턴스를 서비스에서 제거하고 새 게임 서버 빌드로 업데이트한 다음 프로덕션 플릿에 다시 배치하는 대체 접근 방식을 수행할 수 있습니다. 이 접근 방식은 필요한 인프라의 양을 줄이지만 서버를 교체함에 따라 플레이어에게 사용 가능한 라이브 게임 서버의 수가 줄어들기 때문에 위험도 증가합니다.

이 모델은 게임 플레이를 호스팅하지 않는 데이터베이스, 캐시 및 애플리케이션 서버와 같은 백엔드 서비스에 대한 롤링 배포를 수행하는 데에도 사용할 수 있습니다. 이러한 서비스가 여러 클러스터링된 인스턴스에서 가용성이 높은 방식으로 배포되는 한, 이러한 서비스에 대한 배포의 복잡성은 전용 게임 서버에 대한 배포보다 작아야 합니다.

블루/그린 배포

게임에서 블루/그린 배포의 주요 목표는 가동 중지 시간을 최소화하는 동시에 문제가 식별되면 이전 배포로 안전하게 롤백할 수 있도록 하는 것입니다. 게임 백엔드의 두 버전이 호환되고 플레이어에게 동시에 서비스를 제공할 수 있는 배포에 적합합니다.

블루/그린 배포 전략에서는 두 개의 동일한 환경(블루 및 그린)이 설정됩니다. 기존 게임 버전에는 파란색 레이블이 지정되고 배포 대상인 새 게임 버전에는 녹색 레이블이 지정됩니다. 그린 환경을 마이그레이션할 준비가 되면 장애 복구가 필요한 경우 이전 환경(블루)을 사용할 수 있도록 유지하면서 트래픽을 그린 환경으로 넘기도록 라우팅 계층을 구성할 수 있습니다. 이 시나리오에서 라우팅 업데이트를 수행하려면 매치메이킹 서비스를 업데이트하여 게임 세션을 새 플릿으로 전송하도록 구성하거나 게임 백엔드 서비스의 경우 서비스에 대해 Amazon Route 53의 DNS 레코드를 업데이트하거나 새 대상 그룹으로 트래픽을 전송하도록 애플리케이션 로드 밸런서 가중치를 이동해야 할 수 있습니다.

블루/그린 배포 전략의 단점 중 하나는 배포를 수행하는 데 필요한 추가 인프라로 인해 대기 환경의 고유한 비용입니다. 이 추가 인프라 비용을 완화하는 옵션은 이미 프로덕션에 배포된 동일한 서버에 새 게임 소프트웨어가 배포되는 블루/그린 배포 변형을 채택하는 것을 고려하는 것입니다. 이 시나리오에서는 기존 블루 서버 프로세스와 함께 새 소프트웨어로 새 그린 서버 프로세스를 시작할 수 있으며, 별도의 물리적 인프라가 아닌 서버 프로세스 간에 전환이 이루어집니다. 또한이 접근 방식은 클라우드에서 새 서버가 시작될 때까지 기다릴 필요 없이 대규모 인프라에서 게임 배포 속도를 높일 수 있습니다. 이 배포 접근 방식에 대한 모범 사례는 블루/그린 배포를 참조하십시오 AWS.

카나리아 배포

카나리아 배포는 게임의 초기 알파 또는 베타 빌드를 릴리스하거나 제한된 플레이어 또는 소규모 플레이어 프로덕션에 새로운 게임 모드, 맵 또는 챌린지와 같은 게임 기능을 릴리스하는 데 전략을 적용할 수 있으므로 게임 개발자에게 유용합니다. 이러한 배포를 카나리아라고 합니다. 릴리스에는 추가 추적 및 보고 기능이 있을 수 있으므로 실제 플레이어가 해당 게임 또는 기능을 플레이하면 게임 플레이 원격 측정이 수집되어 이상 및 문제가 있는지 분석됩니다.

새로운 기능의 경우 플레이어에게 이에 대해 지속적으로 알리지 않으며 게임 원격 측정은 플레이어에게 문제가 발생하고 릴리스를 롤백해야 하는지 여부를 결정하는 데 사용되는 기본 소스입니다. 동시에 중요한 문제가 식별되지 않으면 추가 데이터를 위해 더 많은 플레이어에게 기능을 추가로 배포할 수 있습니다. 플레이어에게 알림이 전송되면 자신의 경험에 대한 정기적인 피드백을 제공하도록 요청할 수 있습니다. 이러한 테스트 활동은 라이브 운영 팀에서 조정하는 것이 이상적입니다.

전략으로 canary 배포를 표준 릴리스에 사용하여 플레이어가 새로운 기능을 점진적으로 사용할 수 있도록 할 수도 있습니다. 표준 블루/그린 환경보다 잠재적인 이점은 전체 규모의 두 번째 환경이 필요하지 않다는 것입니다. 새로운 축소 환경의 용량은 새로운 기능에 온보딩할 플레이어 수를 결정합니다. 플레이어를 더 추가하기 전에 용량을 적절하게 조정해야 합니다. 이 사용자 지정 블루/그린 기술은 표준 블루/그린보다 비용이 비교적 적게 들 것으로 예상되지만 canary 배포의 롤링 대체 기술보다 비용이 더 많이 들 수 있습니다.

프로덕션 환경에서 단일 canary만 실행하고 데이터와 피드백에 집중합니다. 여러 canary가 배포되면 문제 해결 및 프로덕션 문제 격리가 복잡해지고 수집 중인 데이터 세트 및 피드백의 품질이 저하됩니다.

카나리아의 변형은 하나 이상의 실험(일반적으로 UI 테스트)이 대상 배포를 통해 실행되는 경우입니다. 여기서 게임 백엔드 서버 세트 하나는 한 버전의 기능을 제공하고 동일한 크기의 다른 세트는 다른 버전의 동일한 기능을 제공합니다. 이를 위한 추가 또는 특수 인프라는 생성되지 않으며, 선택한 백엔드 서버 주머니만 이러한 업데이트를 수신합니다. 실험의 결과는 플레이어가 동일한 기능의 각 버전에 어떻게 반응하는지 관찰하고, 전반적으로 좋아요 또는 싫어요에 대한 합의가 있는지 확인하고, 사용성 또는 기능과 관련하여 식별된 문제가 있는지 관찰하는 것입니다. 이러한 전략적 실험을 A/B 테스트라고도 하며, 전체 프로세스를 A/B 테스트라고 합니다. 이러한 실험이 완료되면 테스트에 사용되는 서버에서 게임 백엔드 시스템의 현재 버전으로 되돌리기 전에 필요한 테스트 데이터가 수집됩니다.

레거시 기존 배포

기존 배포 방식에서는 예약된 유지 관리 기간 동안 게임 백엔드 내의 서버 인스턴스가 최신 코드 빌드로 업데이트되기 전에 게임이 종료되고 연결된 플레이어가 삭제되거나 드레이닝됩니다. 이 배포는 수행될 때마다 플레이어에게 영향을 미치므로 플레이어에게 일정에 앞서 알림을 보내야 합니다. 따라서이 모델은 플레이어에게 가장 큰 영향을 미치므로 가능하면 피해야 합니다.

게임 업데이트가 배포된 후에는 게임이 다시 열릴 때까지 기다리는 플레이어에게 게임을 열기 전에 게임을 연기 테스트할 수 있습니다. 이로 인해 플레이어가 짧은 시간 내에 로그인하고 플레이하려고 할 때 트래픽이 급증할 수 있습니다. 따라서 게임이 이러한 트래픽 급증을 처리하도록 설계되지 않은 경우 플레이어가 게임에 배치로 다시 참여하도록 점진적으로 허용할 수 있습니다.

또는 인프라 오버프로비저닝을 선택하여 트래픽의 급증을 지속하고 게임 트래픽이 안정화되면 리소스를 축소할 수 있습니다. 필요한 경우 플레이어 수가 가장 적은 사용량이 적은 시간에 이러한 유형의 배포를 수행합니다. 유지 관리가 자주 예약되고 유지 관리가 연장되면 기본적으로 플레이어 이탈 및 잠재적 수익 손실 위험이 있습니다. 또한 플레이어는 새 릴리스 이후 변경 사항을 예상하며 가동 중지 시간이 지난 후 게임에 대한 신뢰를 잃을 수 있습니다.

구현 단계