Q. 게임 특징은?
- 높은 처리량이 있는가?
- 실시간 반응이 필요한가?
- 지속적인 연결이 필요한가?
Region 선택
- FPS 또는 실시간 대전
- low latency를 유지해야하기 때문에 유저와 가장 근접한 리전 선택
- AWS Global Accelerator 사용하여 리전간 최적화된 통신
- Amazon GameLift로 지연시간 기반의 플레이어 간 매치메이킹
- MMORPG
- 높은 데이터 처리량, 복잡한 로직, 지속적인 연결 요구하기 때문에 근접한 리전 선택
- 플레이어 분포에 따라 리전 선택
- 리전 별로 백엔드 분리
- 웹 기반, 방치형, 비동기 방식
- 적절히 하나의 리전을 선택
- Edge 최적화 API 엔드포인트를 통해 지연시간 최소화
- CloudFront 사용
1) 게임 장르에 따른 리전 선택
먼저 FPS, 실시간 대전류와 같은 장르의 게임들의 경우, 지연시간에 매우 민감합니다. 사용자와 최대한 근접한 리전으로 백엔드 서비스를 전진 배치하거나, AWS Global Accelerator와 같이 AWS 리전과 플레이어 간 네트워크 경로 최적화를 지원하는 서비스의 도입을 검토할 필요가 있습니다. 사용자와 최대한 근접한 리전으로 백엔드 서비스를 전진 배치할 경우, 게임의 서비스 형태가 글로벌 원빌드인지 다중빌드인지에 따라 서비스 아키텍처의 복잡도의 차이가 크게 나게 됩니다.
Q. 글로벌 게임 서비스 가능?
원 빌드 vs 멀티 빌드
원빌드
- 비동기적으로 플레이가능한 게임 우선 고려
- 인/아웃 게임 요소를 분리 후 리전 간 통신 최소화
- 낮은 시간을 요구할 땐 다중 리전으로 구성
- 아웃 게임 요소는 단일 리전으로 구성
멀티빌드
- 마켓 별 개별 빌드와 백엔드 운영
- 각 빌드와 백엔드 간 데이터 교환 시, 데이터 동기화 필요
- Amazon Dynamo DB 전역 테이블
리전 간 데이터 교환을 위하여 리전 간 VPC 피어링이나 AWS Transit Gateway를 사용하여 보안을 높이고 AWS의 리전 간 저지연, 고가용 사설 전용망을 통해 연결되도록 구성할 수 있습니다.
Amazon DynamoDB의 전역 테이블이 글로벌 데이터 동기화에 대한 해법 중 하나가 될 수 있습니다.
또한, 클라우드 서비스의 대중화에 따라, 글로벌 원빌드 서비스가 늘어나면서 플레이어들의 대화나 게시글들의 언어가 자동번역되어야 할 필요성이 증가하고 있습니다. 이 경우 사용하실 수 있는 Amazon Translate는 실시간 번역 서비스를 제공하는 인공신경망 기계 번역 서비스로 현재 54개 언어를 지원하고 있으며 계속하여 지원언어를 늘려가고 있습니다.
Q. 게임의 성능이 얼마나 되는가?
1) Amazon EC2
보통 게임 백엔드로 가장 많이 사용하는 EC2들은 다음의 세 가지 유형으로 좁혀볼 수 있습니다. 높은 동작 클럭을 가진 연산 집약형 워크로드에 적합한 컴퓨팅 최적화 인스턴스( C family ), 다른 유형보다 높은 CPU – 메모리 용량 구성비를 가지고 있어 메모리 사용량이 많은 워크로드에 적합한 메모리 최적화 인스턴스 ( R family ), 좀 더 일반적인 구성으로 일반적인 워크로드에 적합한 범용 인스턴스 ( M family ) 들입니다.
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를 연결해야 합니다.
3) Amazon Relational Database Service (RDS)
온라인 게임 서비스에서 데이터베이스는 선택이 아닌 필수입니다.
출시 전에 게임 백엔드가 필요로 하는 성능 요구사항에 맞는 데이터베이스를 구축하고 운영하는 것은 플레이어 경험에 직접적인 영향을 주게 됩니다.
AWS에서는 이처럼 중요한 데이터베이스를 운영하는 방식으로 크게 두 가지 옵션을 제공하고 있습니다.
EC2에 원하는 데이터베이스 엔진을 설치하여 운영하는 Self-managed 방식과 Amazon RDS 에서 제공하고 있는 데이터베이스 엔진을 사용하는 AWS의 Managed Service를 활용하는 방식으로 구분할 수 있습니다.
Amazon RDS는 여러 인스턴스 유형으로 제공되고 있으며 Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle Database 및 SQL Server를 비롯한 6개의 익숙한 데이터베이스 엔진 중에서 선택하여 사용할 수 있습니다.
4) Amazon S3, Amazon CloudFront
클라이언트 배포 파일에 대한 오리진 스토리지로 내구성 높고 저렴한 오브젝트 스토리지인 Amazon S3를 사용할 수 있습니다. 또한, 글로벌 배포를 위한 CDN 서비스인 Amazon CloudFront를 사용하여 비용 효율적으로 전 세계 플레이어들에게 손쉽고 빠른 클라이언트 및 업데이트를 배포할 수 있습니다.
클라이언트 배포 외에도, 티저 사이트 및 이벤트 페이지, 점검 및 공지 페이지 그리고 런처에 삽입된 페이지 등 정적 페이지 호스팅으로 대체할 수 있는 부분들을 S3의 정적 페이지 호스팅 기능과 CloudFront 를 함께 사용하여 매우 저렴한 비용으로 별도의 서버 없이도 손쉽게 운영할 수 있습니다.
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)로 구분할 수 있습니다.
참고링크
'클라우드 > AWS' 카테고리의 다른 글
| 프리캐싱, Pre-Caching이란? (0) | 2023.07.09 |
|---|