AWS 기반 게임 개발자를 위한 안내서 – 2부. 게임 출시 전 반드시 챙겨야 할 것들

전 세계에 대규모 게임 사용자를 위한 빠르고 민첩한 게임 서비스 개발을 위해 클라우드 활용은 필수가 되었습니다. 세계 최대 게임 회사의 90%가 AWS 기반 게임 서비스를 제공하고 있으며, 국내 게임 매출 상위 15개사 모두 AWS를 사용하고 있습니다. AWS 기반 게임 개발자들이 경험하는 서비스 제공 이슈를 해결 할 수 있는 모범 사례를 총 4회의 걸쳐 여러분께 공유해 드리고자 합니다.

오늘은 1부. 게임 서비스 분산 서비스 거부 (DDoS) 공격 패턴 및 대응 방법에 이어 게임 출시를 앞두고 AWS에서 체크해봐야 할 주요 내용들을 정리해 보겠습니다.

게임의 장르와 규모에 상관없이, 열심히 달려온 개발의 끝에 출시를 준비하는 것은 항상 흥분되고 설레면서도, 아무리 준비해도 불안할 수 밖에 없는 가장 중요한 이벤트입니다. 열심히 체크리스트를 준비하고 하나씩 완료 표시를 붙여가며 준비를 해도 불안한 마음은 어쩔 수가 없는 것 같습니다. 이 글에서 클라우드 기반 게임 출시에서 무엇을 준비해야 할지 함께 살펴보겠습니다.

1. 리전 선택

제일 먼저 해야 할 일 중의 하나는 수 많은 AWS의 리전 중 어디를 선택할 것인가에 대한 것입니다. AWS는 글로벌 사용자들의 최적의 인프라를 제공하기 위하여 계속하여 리전과 가용영역, 엣지 로케이션들을 추가해 왔으며, 그 숫자는 지금도 계속 증가하고 있습니다. 게임의 장르 및 백엔드 아키텍처 설계에 따라서 어떤 리전을 선택하는가가 플레이어 경험에 큰 영향을 미칠 수 있으며, 리전 별로 비용이 다르기 때문에 다양한 부분을 고려하여 선택해야 합니다.

먼저 개발된 게임이 요구하는 지연시간에 대한 파악이 필요합니다. 당연히 지연시간이 짧을수록 좋겠지만, 전 세계 모든 사용자에게 저지연 서비스를 구현하기 위해서는 백엔드 구조의 복잡성이 증가하는 트레이드 오프가 있을 수 밖에 없습니다. 따라서, 게임이 수용할 수 있는 지연시간과 개발된 게임 형태에 따라 적합한 리전을 선택해야 합니다. 또한 전 세계 모든 리전에서 AWS의 모든 서비스를 사용할 수 있는 것은 아닙니다. 게임에서 반드시 사용해야 하는 AWS 서비스가 있다면 해당 리전에서 그 서비스가 현재 사용 가능한지 리전표를 통해 반드시 점검해봐야 합니다.

1) 게임 장르에 따른 리전 선택

먼저 FPS, 실시간 대전류와 같은 장르의 게임들의 경우, 지연시간에 매우 민감합니다. 사용자와 최대한 근접한 리전으로 백엔드 서비스를 전진 배치하거나, AWS Global Accelerator와 같이 AWS 리전과 플레이어 간 네트워크 경로 최적화를 지원하는 서비스의 도입을 검토할 필요가 있습니다. 사용자와 최대한 근접한 리전으로 백엔드 서비스를 전진 배치할 경우, 게임의 서비스 형태가 글로벌 원빌드인지 다중빌드인지에 따라 서비스 아키텍처의 복잡도의 차이가 크게 나게 됩니다. 원빌드와 다중빌드 서비스에서 점검해야 할 부분은 다음 항목에서 다시 다루도록 하겠습니다. 세션형 게임의 서비스에 특화된 AWS의 관리형 게임 호스팅 서비스인 Amazon GameLift 를 이용하면 지연시간 기반으로 플레이어 간 매치메이킹을 제공할 수 있어 지연시간 감소 및 플레이어 경험 향상에 큰 도움이 됩니다. 또한 WebSocket을 활용하는 게임이라면, CloudFront를 통해 WebSocket의 세션 관리를 엣지 로케이션에서 처리함으로써 지연시간을 줄이는 방법을 시도해볼 수 있습니다.

다음으로 MMORPG와 같은 장르의 게임들의 경우, 높은 데이터 처리량과 복잡한 게임 로직 및 플레이 시간 동안 계속 연결이 요구되는 장르의 특성이 있습니다. 따라서, 사용자와 게임 백엔드 간의 지연만큼이나 백엔드 서비스 간의 지연 및 안정성이 서비스 품질에 큰 영향을 미칩니다. 이와 같은 경우 플레이어 분포에 따라 대륙별, 국가별로 게임 백엔드를 분리하여 단일 리전에서 서비스하는 경우가 많습니다. 이때, 각 리전은 플레이어 분포에 가장 인접한 리전을 선택하게 됩니다.

마지막으로, 웹 기반 게임 및 방치형 장르의 비동기 게임, 대부분의 아웃게임 요소들은 지연에서 상대적으로 자유롭습니다. 따라서 복수의 리전을 동시에 운영하는 것은 지연시간을 줄일 수 있는 이점은 있지만 백엔드 구조의 복잡성 증가로 인한 개발 및 운영 비용 증가의 문제가 생기게 됩니다. 따라서 보통 한 리전을 선택하여 서비스하면서 CloudFront의 동적 콘텐츠 전송을 최적화하거나 엣지 최적화 API 엔드포인트를 통해 지연시간을 최적화하게 됩니다.

2) 원빌드 vs 다중빌드

글로벌 게임 서비스를 준비하실 경우 백엔드를 원빌드 또는 다중빌드로 구성할지에 대해 출시 전에 충분히 고려해야 합니다. 앞서 게임 장르에 따른 리전 선택 시에서 살펴본 것처럼 비동기적으로 게임 플레이를 처리할 수 있는 게임들의 경우는 원빌드로 서비스하는 것이 백엔드 구성환경을 단순화하고 상대적으로 운영하기에 용이합니다. 물론, 원빌드 전략의 경우에도 지연시간을 최소화하여 플레이어 경험을 개선하기 위해서는 단일 리전 배포가 현실적이지 않을 수 있습니다. 보통 실제 게임 플레이를 저지연으로 처리해야 하는 인게임 서버들은 복수 리전으로 전진 배치하고, 계정 시스템, 상점 시스템, 랭킹 시스템 등 아웃게임 요소들을 처리하는 서버들은 단일 리전에서 운영하는 전략을 사용할 수 있습니다. 이러한 경우, 인게임과 아웃게임 요소들을 잘 분리하여 리전 간 통신이 필요한 요소들에 대해 최소화할 필요가 있습니다. 리전 간 통신은 Mesh 형태로 실패하더라도 재시도가 가능한 방식으로 느슨하게 연결하는 것이 리전 간 네트워크가 순간적으로 단절되는 경우에 서비스 영향을 최소화하는데 도움이 됩니다. 또한 리전 간 데이터 교환을 위하여 리전 간 VPC 피어링이나 AWS Transit Gateway를 사용하여 보안을 높이고 AWS의 리전 간 저지연, 고가용 사설 전용망을 통해 연결되도록 구성할 수 있습니다.

지연시간이나 지역화에 민감한 게임 장르의 경우, 마켓별로 별도의 빌드 및 게임 백엔드를 운영하는 전략을 선택하게 됩니다. 통상적으로 이러한 구성 및 운영을 다중 빌드 운영이라고 합니다. 이때, 각 마켓별 빌드 및 게임 백엔드 간에 데이터 교환이 없는 독립적인 구성이라면, 복수의 원빌드가 지역별로 분포하는 것과 크게 다르지 않습니다. 하지만 마켓별 다중 빌드 및 게임 백엔드 간의 데이터 교환이 필요해질 경우, 데이터 동기화를 어떻게 처리할 것인지에 고민이 깊어집니다. 이런 경우 Amazon DynamoDB의 전역 테이블이 글로벌 데이터 동기화에 대한 해법 중 하나가 될 수 있습니다.

또한, 클라우드 서비스의 대중화에 따라, 글로벌 원빌드 서비스가 늘어나면서 플레이어들의 대화나 게시글들의 언어가 자동번역되어야 할 필요성이 증가하고 있습니다. 이 경우 사용하실 수 있는 Amazon Translate는 실시간 번역 서비스를 제공하는 인공신경망 기계 번역 서비스로 현재 54개 언어를 지원하고 있으며 계속하여 지원언어를 늘려가고 있습니다.

2. 게임 출시를 위한 코어 서비스 구성하기

1) Amazon EC2

게임을 운영하기 위해 필요한 다양한 서버들을 AWS 상에서 구동하기 위해서는 AWS에서 제공하는 가상 서버 서비스인 Amazon EC2부터 준비해야 합니다. AWS에서는 고객의 워크로드에 따라 다양한 유형 및 사이즈의 인스턴스를 추가해오다 보니, 수많은 유형의 EC2 중에서 도대체 어느 EC2를 선택해야 할지 혼란이 오기도 합니다.
보통 게임 백엔드로 가장 많이 사용하는 EC2들은 다음의 세 가지 유형으로 좁혀볼 수 있습니다. 높은 동작 클럭을 가진 연산 집약형 워크로드에 적합한 컴퓨팅 최적화 인스턴스( C family ), 다른 유형보다 높은 CPU – 메모리 용량 구성비를 가지고 있어 메모리 사용량이 많은 워크로드에 적합한 메모리 최적화 인스턴스 ( R family ), 좀 더 일반적인 구성으로 일반적인 워크로드에 적합한 범용 인스턴스 ( M family ) 들입니다.

통상적으로, 메인 게임 로직을 처리하는 서버들은 C family, 메모리 사용량이 많은 DB나 Cache 및 세션 서버들은 R family, 비동기 API 서버들은 M family 로 테스트를 시작하는 경우가 많습니다. 하지만 이것은 테스트를 시작하기 위한 지침일 뿐, 애플리케이션마다 부하에 따른 성능 특성은 게임로직에 따라 다를 수 밖에 없습니다. 따라서 실제 애플리케이션으로 부하 테스트를 수행하고 병목 지점을 찾아 더 적합한 인스턴스로 변경하는 작업을 반드시 수행하여야 합니다. 전통적인 데이터센터의 서버구매 절차와 달리, AWS에서는 서버 유형이나 사이즈를 변경하는 것에 별도의 비용이 발생하지 않으므로 성능 예측과 최적의 인스턴스 선정에 너무 많은 시간을 할애하는 것보다 적당한 인스턴스를 선택하고 테스트를 통해 최적의 인스턴스를 찾는 것이 중요합니다. 이 과정에서 AWS Compute Optimizer를 활용하여 수집된 데이터를 토대로 한 적절한 유형과 크기의 인스턴스의 권장 사항을 검토할 수 있습니다.

2) Amazon Elastic Block Store (EBS)

EC2를 서비스하기 위하여 필수적인 것이 블록 스토리지 서비스인 Amazon EBS입니다. AWS에서는 EBS를 요구되는 IO 특성에 따라 4가지 종류로 구분하고 있습니다. 게임에서 가장 많이 쓰이는 EBS는 용량에 따라 IO 성능도 함께 증가하는 범용 SSD (gp2) 타입과 높은 DISK IO에 최적화된 프로비저닝된 IOPS SSD (io1) 타입입니다. 보통 OS가 설치되는 루트 볼륨은 범용 SSD(gp2) 타입이 일반적이며, 데이터베이스와 같이 높은 DISK IO가 필요한 워크로드의 경우 프로비저닝된 IOPS SSD(io1)타입을 사용하게 됩니다.

범용 SSD (gp2) 타입의 EBS 성능은 다음 도표와 같이 용량에 따라 결정됩니다. 1 GiB 당 3 IOPS의 IO 성능이 자동으로 할당되고, 5,334GiB일 때 최대 IO 성능인 16,000 IOPS에 도달하게 됩니다. 또한, 1,000 GiB 미만의 범용 SSD (gp2) EBS타입이더라도 유휴 상태일 때 IO Credit을 쌓아 두다가, 필요시 Credit을 소모하여 3,000 IOPS의 성능을 낼 수 있도록 구현되어 있습니다. 따라서 대부분 디스크는 유휴 상태이지만 순간적인 IO 피크가 존재하는 디스크 접근 패턴의 경우에 적합합니다.

프로비저닝된 IOPS SSD(io1) 타입의 EBS의 성능은 생성시 지정한 IOPS 만큼 보장 받습니다. 이 때, 해당 IOPS를 달성하기 위해 필요한 최소용량이 존재하는데, 이 비율이 50:1로 범용 SSD(gp2) 타입보다 훨씬 적은 용량의 EBS 볼륨으로 더 높은 IO 성능을 낼 수 있습니다. 1,280 GiB 의 볼륨으로 최대 64,000 IOPS를 달성할 수 있습니다.

이때, 두 가지 주의해야 할 점이 있습니다. 먼저, 높은 성능의 IO가 보장되는 프로비저닝된 IOPS SSD(io1) 타입의 EBS라도 충분한 크기의 인스턴스와 연결되지 않으면 인스턴스의 대역폭 제한으로 EBS의 성능을 모두 쓰지 못하게 됩니다. 이 경우 높은 비용을 지불하면서도 충분한 IOPS를 달성하지 못하는 문제가 발생합니다. 따라서 사용하고자 하는 각 인스턴스 유형 및 사이즈별로 EBS에 할당된 최대 IOPS를 확인하고 적절한 크기의 인스턴스와 해당 EBS를 연결해야 합니다.

다음으로, 비용의 관점에서 범용 SSD(gp2) 및 프로비저닝된 IOPS SSD(io1)을 고려해보아야 합니다. 16,000 IOPS 이하의 디스크 성능이 요구될 때, 해당 성능은 범용 SSD(gp2) 및 프로비저닝된 SSD(io1) 모두를 통해 달성할 수 있지만 비용상 차이가 크게 날 수 있습니다. 예를 들어, 1,000 IOPS가 필요한 경우, 요구사항을 달성할 수 있는 두 볼륨의 비용 차이는 리전에 따라 두 배 이상 차이가 날 수 있습니다. 따라서, 볼륨 선택시 성능과 함께 비용요소도 반드시 고려되어야 합니다.

• 프로비저닝된 IOPS SSD(io1) : 디스크 볼륨 지정 (333GB) + IOPS 지정 (1,000) → 한 달 기준, $108.9 (서울리전 기준)
• 범용SSD (gp2) : 디스크 볼륨 지정 (333GB) + IOPS 결정 (333 *3 = 999) → 한 달 기준, $37.97(서울리전 기준)

3) Amazon Relational Database Service (RDS)

온라인 게임 서비스에서 데이터베이스는 선택이 아닌 필수입니다. 출시 전에 게임 백엔드가 필요로 하는 성능 요구사항에 맞는 데이터베이스를 구축하고 운영하는 것은 플레이어 경험에 직접적인 영향을 주게 됩니다. AWS에서는 이처럼 중요한 데이터베이스를 운영하는 방식으로 크게 두 가지 옵션을 제공하고 있습니다. EC2에 원하는 데이터베이스 엔진을 설치하여 운영하는 Self-managed 방식과 Amazon RDS 에서 제공하고 있는 데이터베이스 엔진을 사용하는 AWS의 Managed Service를 활용하는 방식으로 구분할 수 있습니다. RDS를 사용하게 되면, 반복적인 데이터베이스의 관리 부담을 상당 부분 경감하고 데이터베이스의 쿼리 최적화 및 게임의 데이터 로직 자체에 집중할 수 있습니다. 더 나아가, 데이터베이스 관리의 자동화를 통하여 이러한 장점들을 더욱 확대할 수 있습니다. Amazon RDS는 여러 인스턴스 유형으로 제공되고 있으며 Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle Database 및 SQL Server를 비롯한 6개의 익숙한 데이터베이스 엔진 중에서 선택하여 사용할 수 있습니다.

4) Amazon S3, Amazon CloudFront

게임의 품질과 디바이스의 성능이 높아짐에 따라 모바일 게임의 클라이언트 용량도 점점 증가하고 있습니다. 이러한 상황에서 글로벌 서비스 환경에서의 게임 클라이언트 및 업데이트 배포도 반드시 신경을 써야 하는 중요한 부분입니다. 클라이언트 배포 파일에 대한 오리진 스토리지로 내구성 높고 저렴한 오브젝트 스토리지인 Amazon S3를 사용할 수 있습니다. 또한, 글로벌 배포를 위한 CDN 서비스인 Amazon CloudFront를 사용하여 비용 효율적으로 전 세계 플레이어들에게 손쉽고 빠른 클라이언트 및 업데이트를 배포할 수 있습니다.

클라이언트 배포 외에도, 티저 사이트 및 이벤트 페이지, 점검 및 공지 페이지 그리고 런처에 삽입된 페이지 등 정적 페이지 호스팅으로 대체할 수 있는 부분들을 S3의 정적 페이지 호스팅 기능과 CloudFront 를 함께 사용하여 매우 저렴한 비용으로 별도의 서버 없이도 손쉽게 운영할 수 있습니다.

이 서비스 구성의 비용구조는 약정을 따로 필요로 하지 않으며 지역에 따른 GB당 단가로 구성됩니다. 다만, Amazon CloudFront를 통해 대량의 트래픽을 전송하시는 많은 게임사에서는 AWS 공식 파트너사를 통해 큰 폭의 할인율이 제공된 금액으로 사용하고 있습니다. 자세한 내용에 대해서는 aws-gaming-korea@amazon.com으로 문의하시길 바랍니다.

5) Elastic Load Balancing (ELB)

게임의 장르와 백엔드 서비스의 구조에 따라 다르지만, 대부분의 경우 로드밸런서 기능이 필요합니다. AWS에서 로드밸런서 역할을 하는 ELB는 트래픽의 종류에 따라 HTTP/HTTPS를 처리하는 L7 로드밸런서인 Application Load Balancer(ALB), TCP/UDP/TLS를 처리하는 Network Load Balancer(NLB), 이전 세대의 Classic Load Balancer(CLB)로 구분할 수 있습니다.
각 로드밸런서가 지원하는 기능에 대한 세부사항을 비교해보고 해당 요구사항에 맞게 적절한 로드밸런서를 선택하게 됩니다. 이때, NLB를 제외한 ALB와 CLB의 경우 출시 및 대용량의 마케팅 이벤트를 통해 매우 짧은 시간에 급격한 트래픽 증가가 예상되는 경우 미리 Pre-Warming을 신청해주시는 방향을 권장드리고 있습니다. Pre-Warming은 따로 비용이 발생하지 않으며, 신청 방법에 대해서는 다음 3. 게임 출시 전 필요한 조치 사항 숙지하기 부분을 참고해주시기 바랍니다.

3. 게임 출시 전 필요한 조치 사항 숙지하기

게임을 서비스할 리전과 사용할 AWS 코어 서비스들도 제대로 구성했다면, 이제 출시 전 필요한 조치사항들을 최종 점검할 차례입니다.

1) 서비스 할당량 – 제한 점검 및 증가 요청

AWS의 서비스들은 예상치 못한 오남용을 방지하기 위해 대부분 서비스 할당량 혹은 서비스 제한이라는 항목으로 AWS 계정당 최대 리소스의 수를 제한하고 있습니다. 설정된 기본 서비스 할당량 및 제한이 게임 개발 단계에서 문제가 되지는 않지만, 출시 및 게임 서비스의 확장에 따라 해당 제한의 영향을 받을 수 있습니다. 따라서 출시 전 사용하고 있는 서비스별 할당량 제한에 문제가 없을지 점검하고 미리 할당량 증가를 요청해둬야 합니다. AWS 서비스 센터 및 Service Quotas를 이용하여 이러한 할당량 증가 및 한도 해제를 요청할 수 있습니다.

2) 대규모 트래픽 대비 – Pre-Warming 신청

코어 서비스에서 살펴본 ELB 내용에서 ALB 및 CLB의 경우, 매우 짧은 시간에 급격한 트래픽의 증가가 예상될 상황에서 로드밸런서에 대한 Pre-Warming이 필요하다고 설명해 드렸습니다. 급격한 트래픽이 증가할 이벤트 당일 최소 10일 전에는 Pre-Warming을 신청하시는 방향을 권장해 드리고 있습니다. 해당 방법은 콘솔 내 케이스 오픈을 통해 신청할 수 있으며, 자세한 내용에 대해서는 aws-gaming-korea@amazon.com으로 문의하시길 바랍니다.

3) 문제 발생 시 처리 절차 수립 – 서포트 플랜 검토

아무리 모든 것을 미리 테스트해보고 점검했다 하더라도, 항상 출시 시기에는 (마가 끼었는지) 꼭 크고 작은 이슈들이 발생합니다. 이러한 경우들을 대비하여 문제 발생 시의 처리 절차를 미리 수립해 놓을 필요가 있습니다. 이 처리 절차는 내부의 운영 담당자 및 개발자 뿐 아니라 AWS 장애 조치를 위한 지원 요청 및 확인 절차를 포함해야 하고, 장애 조치를 위한 적절한 수준의 지원을 받을 수 있는 AWS 서포트 플랜을 검토하고 적용해두어야 합니다. 최소한 Business 등급이상의 서포트 플랜을 갖추어야 게임의 상용 서비스에 적절한 수준의 지원을 AWS 서포트 센터를 통해 제공 받을 수 있습니다.
AWS 서포트센터를 통해 케이스를 오픈할 때에는 최대한 상세한 내용 – 문제가 발생한 정확한 시간, 리전, 가용영역, 인스턴스 ID, ARN, 상세한 문제 기술 및 스크린샷이나 로그들을 모두 함께 제출해 주셔야 더욱더 빠르고 효과적인 지원이 가능합니다. 게임 출시 시기나 대규모 업데이트, 인프라 대규모 마이그레이션과 같은 대규모 이벤트에 대한 실시간 지원을 원하신다면 인프라 이벤트 관리를 요청할 수 있습니다. 인프라 이벤트 관리를 사용하면 이벤트 전부터 전략적 계획 지원을 받을 수 있을 뿐만 아니라 비즈니스에 가장 중요한 순간에 실시간 지원을 받을 수 있습니다. 이 경우 추가 비용이 발생하게 되며, Enterprise 등급의 서포트 플랜을 사용하고 계실 경우에는 무료로 제공됩니다.

4. 마치며

오랜 개발의 결실을 보는 게임 출시를 고객분들과 함께 준비하면서 겪었던, 자주 질문 받거나 미리 챙겼더라면 더 좋았을 부분들을 정리해 보았습니다. 이 안내서가 게임 출시에 필요한 모든 부분을 다루고 있지는 않더라도, 성공적인 게임의 안정적인 출시에 도움이 되었으면 합니다. 추가로 궁금하신 내용 및 기술 지원이 필요하신 내용이 있다면, 언제든지 aws-gaming-korea@amazon.com으로 문의하여 주시기 바랍니다.

– 김병수, AWS 게임 솔루션즈 아키텍트