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

GAMEOPS05-BP01 목표에 맞는 적절한 단계, 아키텍처 및 로드 테스트 프레임워크 선택

게임 로드 테스트에 대한 접근 방식은 게임이 수행되는 개발 프로세스의 단계, 로드 생성 시스템 자체의 아키텍처, 로드 테스트 프레임워크 선택 등 여러 요인에 따라 크게 달라질 수 있습니다. 초기 단계이든, 반복 스프린트 중이든, 프로덕션 배포 전이든, 배포 후이든 상관없이 수행되는 시기는 테스트 노력의 목표와 초점을 형성합니다. 로드 생성 인프라의 다양한 설계에는 고유한 장단점이 있으며, 로드 테스트 프레임워크를 선택하면 테스트 프로세스에 사용할 수 있는 기능, 사용 편의성 및 통합에 큰 영향을 미칩니다.  개발 팀은 이러한 요소를 신중하게 조정하여 로드 테스트 접근 방식을 게임의 고유한 특성에 맞게 조정하고, 가장 중요한 성능 인사이트를 추출하고, 플레이어에게 원활한 경험을 제공할 수 있습니다.

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

구현 지침

다양한 개발 단계에서 로드 테스트 

개발 단계 초기에 탐색 로드 테스트를 수행하면 기본 시스템 아키텍처를 검증할 수 있습니다. 이를 통해 개발자는 광범위한 구현 작업이 완료되기 전에 게임의 인프라, 데이터베이스 설계 및 네트워크 토폴로지에 대해 정보에 입각한 결정을 내릴 수 있습니다. 로드 테스트는 위험을 식별하고 성능 기준을 생성하여 개발 수명 주기 후반에 비용이 많이 드는 재작업 및 기술 부채의 필요성을 최소화할 수 있습니다. 또한 팀 간의 게임 성능 요구 사항에 대한 공동 이해를 촉진하여 협업과 의사 결정을 개선할 수 있습니다. 궁극적으로 초기 단계의 로드 테스트는 성능, 확장성 및 복원력이 뛰어난 게임을 위한 강력한 기반을 구축하여 전반적인 플레이어 경험을 개선하는 데 도움이 됩니다.

각 스프린트 또는 반복이 끝나면 로드 테스트는 최신 주기에 도입된 새로운 기능, 버그 수정 및 기타 변경 사항의 성능 영향을 평가할 수 있습니다. 이 목표 접근 방식을 통해 개발 팀은 최신 업데이트로 인한 회귀 또는 성능 저하를 신속하게 식별할 수 있으므로 파이프라인으로 더 전파되기 전에 이러한 문제를 해결하고 일관된 수준의 품질과 성능을 유지할 수 있습니다.

프로덕션에 배포하기 전에 강력한 로드 테스트를 통해 팀은 예상되는 실제 트래픽 및 로드 조건을 처리할 수 있는 시스템의 능력을 검증할 수 있습니다. 프로덕션 인프라 내에서 확장성 병목 현상 또는 리소스 제약을 발견하고 게임 성능을 최적화하여 첫날부터 원활하고 응답성이 뛰어난 사용자 환경을 만들 수 있는 기회를 제공할 수 있습니다. 출시 전 로드 테스트에서 얻은 인사이트는 출시일 위험을 완화하고 지속적인 용량 계획에 정보를 제공할 수 있으며, 이는 게임의 장기 지속 가능성 및 확장성의 토대를 마련합니다.

이미 프로덕션 환경에 있는 게임을 로드 테스트하면 팀이 게임의 성능을 모니터링하고 시간 경과에 따라 발생할 수 있는 성능 저하 또는 성능 저하를 식별할 수 있습니다. 이를 통해 플레이어 경험에 영향을 미치고 사용자 보존에 부정적인 영향을 미치기 전에 문제를 사전에 해결할 수 있습니다. 또한 프로덕션에서의 로드 테스트는 구현된 성능 최적화 작업 또는 인프라 규모 조정의 효과를 검증합니다. 이 프로세스는 게임이 발전하고 성숙해지더라도 플레이어에게 응답성이 뛰어나고 확장 가능한 고품질 게임 환경을 제공합니다.

로드 생성 아키텍처

게임 로드 테스트를 위한 로드 생성 아키텍처의 설계는 다양한 형태를 취할 수 있으며, 각 아키텍처에는 고유한 장점과 고려 사항이 있습니다. 

가장 기본적인 수준에서 자체 관리형 Amazon EC2 인스턴스를 프로비저닝하고 로드 생성기 역할을 하도록 구성할 수 있습니다. 제어 노드 및 작업자 노드 접근 방식을 사용하면 여러 로드 생성 인스턴스를 설정할 수 있습니다. 각 인스턴스는 자체 테스트 스크립트를 실행하고 전체는 단일 제어 인스턴스에서 관리합니다. 아키텍처는 추가 작업자 노드를 가동하여 복잡성을 높이지 않고 확장하고 더 많은 로드를 생성할 수 있지만,이 실습 접근 방식을 사용하려면 팀이 기본 인프라의 프로비저닝, 구성 및 관리를 처리해야 합니다.

보다 확장 가능하고 오케스트레이션된 접근 방식을 위해 Amazon EKS Kubernetes 클러스터를 사용하여 컨테이너 기반 로드 에이전트 플릿에 로드 테스트 워크로드를 관리하고 배포할 수 있습니다. Kubernetes 자동 조정 기능을 사용하여 로드 생성 포드의 규모 조정을 처리할 수 있으며 팀 자체는 포드를 호스팅하는 클러스터의 기본 EC2 인스턴스를 구성하고 관리합니다. 

또는의 서버리스 특성은 필요한 확장성과 유연성을 제공하면서 인프라 관리를 추상화하여 로드 테스트 설정을 가속화하고 단순화할 AWS Fargate 수 있습니다. 온프레미스, 로드 생성 Kubernetes 클러스터가 이미 있지만 추가 용량이 필요할 수 있는 하이브리드 솔루션의 경우 EKS Anywhere는 두 클러스터를에서 하나로 관리할 수 있습니다 AWS Management Console.

요구 사항 및 목표에 따라 AWS Lambda 함수를 사용할 수도 있습니다. Lambda 함수는 추가 리소스를 프로비저닝하고 관리할 필요 없이 비교적 간단하게 설정하고 확장할 수 있습니다. 또한 다른 AWS 서비스와의 심층 통합으로 인해 더 복잡하고 동적인 테스트 시나리오를 생성할 수 있습니다. 그러나 Lambda 함수에는 동시 함수 및 런타임(15분)에 대한 제한이 있으므로 달성할 수 있는 로드 테스트의 규모와 길이가 제한될 수 있습니다. 콜드 스타트 지연 시간은 결과의 정확도에도 영향을 미칠 수 있으며, Lambda의 리소스 제한은 매우 까다로운 로드 테스트 워크로드에 적합하지 않을 수 있습니다.

사전 구축된 솔루션을 사용하려는 스튜디오는 에서 분산 로드 테스트를 AWS 사용할 수 있습니다. 이 솔루션은의 Amazon ECS AWS Fargate 를 사용하여 수만 명의 연결된 사용자로 구성된 시뮬레이션을 실행할 수 있는 컨테이너를 배포합니다. 이를 사용하여를 사용하여 IAC 방식으로 로드 테스트 인프라를 빠르게 시작할 수 있습니다 AWS CloudFormation.

로드 테스트 프레임워크

두 로드 테스트 프레임워크가 동일하게 빌드되지 않습니다. 테스트 생성을 위한 직관적인 그래픽 인터페이스가 있는 것도 있고, 명령줄을 기반으로 하는 것도 있습니다. 한 도구는 유연하고 성능이 뛰어나지만 구성 및 관리에 시간과 노력이 필요할 수 있으며, 다른 도구는 서버리스이지만 생성 및 실행할 수 있는 테스트에 제한이 있을 수 있습니다. 일부는 현장에서 입증되지 않은 상태에서 대규모 커뮤니티와 많은 자습서를 이용하며, 프로덕션 환경에서 전투 테스트를 거쳤지만 커뮤니티 지원이나 문서가 부족한 다른 사람들과는 명확하게 대조됩니다. 자신과 팀에 적합한 균형을 이루는 프레임워크를 선택합니다. 몇 가지 인기 옵션은 다음과 같습니다.

구현 단계