Amazon Web Services 한국 블로그
트래픽 감소에 따른 AWS 기반 게임 백엔드 최적화 전략
게임 출시와 서비스 규모 확장에 대해서 이전 포스트들 – AWS 기반 게임 개발자를 위한 안내서 – 2부. 게임 출시 전 반드시 챙겨야 할 것들, 서비스 규모 확장에 따른 게임 서비스 아키텍처 개선에서 살펴보았습니다만, 게임 서비스가 영원할 수는 없는 법. 트렌드 변화나 환경 변화, 게임 자체의 생명주기에 따라 트래픽이 감소하기도 합니다.
이러한 트래픽 감소가 지속적이라면 게임 백엔드를 적절히 다운사이징하고 비용을 최적화할 수 있는 요소들을 점검해봐야 할 시기입니다. 꼭 지속적인 트래픽 감소가 예측되는 시점이 아니더라도 최초 예측했던 것보다 실제 사용량이 적거나 지속적인 애플리케이션 최적화로 리소스 사용량이 현저히 줄어들었다면 비용적인 면을 감안하여 클라우드 아키텍처를 최적화해볼 수 있습니다.
1. 비용 모니터링
효과적인 비용 최적화를 위해서는 적절한 비용 모니터링이 필수적입니다. AWS는 사용 비용을 분석하고 절감하기 위한 다양한 도구들을 제공합니다. 비용 탐색기, 예산, Trusted Advisor과 같은 도구들을 활용하여 발생하는 비용을 모니터링하고 절감 요소가 없는지 수시로 점검해보아야 합니다.
비용 탐색기로 계정별, 서비스별 높은 비용을 발생시키는 서비스를 식별하고 규모 조정 권장 사항을 통해 비용 절감 요소를 확인해볼 수 있습니다. 예산으로는 월별 예산을 수립하여 예산을 초과할 것이 예상될 경우 알람을 받아 비용의 낭비 요소를 점검할 수 있으며, Trusted Advisor를 통해 비용 최적화 모범사례 적용 여부를 점검하고 개선이 필요한 영역을 식별 및 조치할 수 있습니다.
비용 탐색기
비용 탐색기의 규모 조정 권장 사항
비용 탐색기 사용 및 비용 모니터링 및 최적화와 관련한 상세한 내용은 AWS 비용을 줄일 수 있는 10가지 기법에서 확인하실 수 있습니다.
2. 적절한 사이징
비용 모니터링을 통하여 비용의 낭비 지점을 찾았다면 적절한 사이징을 통해 실제 비용을 최적화할 차례입니다. AWS의 서비스 중에는 CloudFront, Lambda, S3, DynamoDB, SES, SNS, SQS, Route 53, ELB, EFS, Step Functions들과 같이 사용자가 특별히 신경 쓰지 않아도 태생적으로 높은 확장성, 내결함성, 가용성을 제공하는 서비스들도 있고, 올바른 아키텍처로 구성할 경우 높은 확장성과 내결함성, 가용성을 제공할 수 있는 EC2, EBS, RDS, VPC와 같은 서비스들도 있습니다. 같은 기능을 제공한다면 가급적 태생적으로 높은 확장성을 제공하는 서비스들을 사용하거나 올바른 아키텍처 구성을 통해 높은 확장성을 가지도록 설계하는 것이 트래픽 감소에도 유연하게 대응할 수 있습니다.
위에서 언급한 비용 탐색기의 규모 조정 권장 사항 외에도 기계학습을 통한 EC2 인스턴스의 권장 사항을 분석해볼 수 있습니다. AWS Compute Optimizer를 활용하면, 기계 학습 기술을 사용하여 계정의 리소스 사용 기록을 분석하고 리소스 사용에 맞게 적절히 설명된 실행 가능한 권장 사항을 만듭니다. 이 권장 사항들을 통해 옵션별로 변경 후 리소스 사용량을 예측해보고 EC2 리소스를 비용 효율적으로 사용할 수 있습니다.
수직 축소 Scale-Down
먼저 아키텍처의 변경을 수반하지 않고 고려해볼 수 있는 것은 사용 인스턴스의 사이즈를 줄이는 방식으로 진행하는 Scale-Down입니다. CPU나 메모리의 사용량이 현저히 줄어들었을 때 RDS나 EC2 인스턴스의 유형을 변경하거나 사이즈를 줄이는 방식, 높은 PIOPS로 준비한 io1 EBS의 실제 Disk I/O 사용량이 예상보다 현저히 낮아졌을 때 PIOPS 수치를 낮추거나 gp2 방식의 EBS로 변경하는 방식이 이에 해당합니다. 용량을 늘리거나 IO 요구량을 조정하거나 EBS 타입을 변경하는 작업이 Elastic Volume으로 더욱 손쉬워졌습니다. 볼륨 축소의 경우에는 더 작은 크기의 EBS 볼륨을 만들고 기존 볼륨의 내용을 rsync 등의 애플리케이션 수준 도구를 통해 복제하고 복제된 EBS 볼륨으로 기존의 EBS 볼륨을 대체하는 방식으로 마이그레이션 할 수 있습니다.
수평 축소 Scale-In
이전 글 서비스 규모 확장에 따른 게임 서비스 아키텍처 개선에서 살펴보았던 것처럼 워크로드가 수평적으로 확장할 수 있는 형태라면 할당된 노드를 줄이는 방식으로 수평적인 축소도 용이하게 수행할 수 있으며, AWS Auto Scaling을 통해 수평축소도 자동화할 수 있습니다. 기존의 지표 및 예약설정을 기반으로 동작하는 Auto Scaling뿐 아니라 최근에는 인공 지능 기반의 자동 스케일링 기능도 출시되어 트래픽 증감에 더욱 유연하게 대처할 수 있게 되었습니다. 또한 요즘 인기를 얻고 있는 컨테이너 기반의 서비스들인 Docker 기반의 ECS나 Kubernetes 기반의 EKS와 같은 경우도 ECS 클러스터 AutoScaling 및 클러스터 Autoscaler를 통해 자동 확장 및 축소를 지원하고 있습니다.
Redis용 ElastiCache의 경우, 규모 조정을 통해 적절한 규모로 조정이 가능하고, 클러스터 모드일 경우 다운 타임을 최소화하면서 온라인 규모 조정이 가능하도록 기능이 개선되었습니다. DynamoDB의 경우, Auto Scaling을 통한 자동 확장/축소 및 온디맨드 처리량을 통한 자동 확장/축소를 지원하고 있으며 기존 방식대로 처리 IOPS를 지정하고 수동으로 처리용량 직접 조정을 통한 수동 확장/축소를 수행할 수도 있습니다.
3. 스팟 인스턴스 활용
스팟 인스턴스는 AWS의 EC2 Pool 중 유휴 자원을 활용하여 EC2를 온디맨드 비용 대비 90%까지 저렴한 가격에 제공하는 서비스입니다. 스팟 인스턴스의 가격은 수요와 공급에 따라 동적으로 변경되고, 사용 도중 회수될 수 있기 때문에 배치 프로세싱이나 상태 비 저장형 워크로드에 적합합니다. 애플리케이션 간 상호의존성을 최소화하는 디커플링 및 상태를 애플리케이션 외부에 저장하는 방식을 통하여 스팟 인스턴스를 활용하면 동등한 규모와 성능의 백엔드 서비스를 훨씬 저렴한 비용으로 운영할 수 있으며 EC2 Auto Scaling 및 ECS/EKS도 스팟 인스턴스를 활용하도록 구성할 수 있습니다. 스팟 인스턴스의 다양한 사용사례를 다음 포스트에서 확인하실 수 있으며 실제로 게임을 위한 스팟 인스턴스를 활용해보기 위한 Github sample 코드와 함께 제공하는 스팟 인스턴스 활용기도 참고하실 수 있습니다.
게임 서버 호스팅을 위한 관리형 서비스인 GameLift 역시 스팟 인스턴스를 지원합니다. 특히 GameLift의 일부로 제공되던 FleetIQ는 최근 스팟 인스턴스의 회수로 인한 게임 중단을 최소화할 수 있는 옵션만을 따로 분리하여 고객의 VPC안의 AutoScaling과 함께 사용가능한 서비스로 출시되었습니다.
4. 적절한 서비스와 아키텍처로 변경
같은 방식의 서비스를 제공하는 게임 백엔드라고 하더라도 어떤 AWS 서비스를 이용하여 구현했는지 어떤 아키텍처를 활용했는지에 따라 그 비용이 매우 차이가 날 수 있습니다. 예를 들어 웹서버를 구성했을 때, EC2/EBS 백엔드만을 사용하고 ELB를 활용했을 경우와 정적 콘텐츠를 S3로 분리하고 CloudFront로 캐싱했을 때의 비용의 차이는 무척 큽니다. 또한 RESTful API의 경우에도 EC2를 사용하는 것과 API Gateway와 Lambda를 사용하는 것, 같은 EC2라도 위에서 언급한 스팟 인스턴스를 활용하는 것은 트래픽에 따라 비용 차이가 크게 발생하므로 AWS 비용 계산기로 서비스별 비용 시뮬레이션을 하고 이를 아키텍처 수립 및 백엔드 구현에 반영할 필요가 있습니다.
5. 데이터 수명 주기 관리
모든 데이터에는 수명 주기가 있고 스토리지는 공짜가 아닙니다. 데이터의 수명 주기에 따른 최적화를 통해 비용을 절감하는 것도 함께 검토해야 합니다. S3는 객체 수명 주기 관리 정책을 통해 Standard – Infrequent Access – Glacier로 이어지는 더 저렴한 스토리지 클래스로 객체를 자동으로 전환되도록 설정할 수 있습니다. 또 S3의 지능적 티어를 사용하면 객체에 대한 접근 빈도에 따라 자동으로 가장 효율적인 스토리지 클래스로 객체를 전환하도록 할 수 있습니다. 물론 수동으로 객체의 스토리지 클래스로 전환할 수도 있으며, 이때 S3의 스토리지 클래스 분석기능이 객체별 접근 통계 및 적절한 클래스를 식별하는 데 도움이 됩니다. DynamoDB의 경우 item 별로 TTL을 설정하여 데이터 생명주기를 관리할 수 있습니다.
적절한 TTL 설정 및 업데이트를 통해 적절한 스토리지 사용을 유지할 필요가 있습니다. 서비스 백업 목적으로 생성한 다양한 스냅샷과 백업들도 생명주기가 있습니다. 지나치게 오래된 백업이나 스냅샷들은 정리하여 비용을 절감할 수 있습니다. AWS Backup 서비스를 사용하면 Amazon EBS 볼륨, Amazon EC2 인스턴스, Amazon RDS 데이터베이스, Amazon DynamoDB 테이블, Amazon EFS 파일 시스템 및 AWS Storage Gateway 볼륨과 같은 AWS 리소스의 백업 활동을 중앙관리하고 수명 주기 정책을 구성할 수 있습니다. EBS의 경우 Data Lifecycle Manager를 통하여 스냅샷의 수명 주기에 따른 관리를 자동화할 수 있습니다.
마치며
이것으로 게임의 수명 주기에 따른 고려사항들을 3부작으로 정리해 보았습니다. 짧은 지면에 조금이라도 더 다양한 영역을 간략하게라도 다루려고 하다 보니 지나치게 간략하게 다룬 부분들이 있어 아쉬움이 남지만, 아키텍처 및 시스템의 구성은 고정된 것이 아니라 요구사항에 따라 끊임없이 개선해 나가야 하는 것이라는 점을 다시 한 번 강조하고 싶습니다. 추가로 궁금하신 내용 및 기술 지원이 필요하신 내용이 있다면 언제든지 aws-gaming-korea@amazon.com으로 문의하여 주시기 바랍니다.
– 김병수, AWS 게임 솔루션즈 아키텍트