게임 출시 전 AWS 예상 비용 산출 및 출시 후 비용 최적화 방법

글로벌 게임 사용자를 위한 빠르고 민첩한 게임 서비스 개발을 위해 클라우드 활용은 이제 선택이 아닌 필수가 되었습니다. 세계 최대 게임 회사의 90%가 AWS를 기반으로 게임 서비스를 제공하고 있으며, 국내 게임 매출 상위 15개사에서 모두 AWS를 사용하고 있습니다. 사용자가 많은 만큼 사용하는 방식도 다양하지만, 그 중에서도 많은 경험을 바탕으로 정제되어 만들어지는 모범 사례들이 있습니다. 이러한 모범 사례들을 게임 개발자분들께 주기적으로 공유해 드리고자 합니다. 오늘은 게임사에서 게임 출시 전 예상 비용을 산출하는 방법과 출시 후 비용을 최적화 할 수 있는 방안들에 대해 설명해드리고자 합니다. 게임 출시 이전에 인프라 비용을 정확히 예상하기란 결코 쉬운 일이 아닙니다. 또한, AWS의 수십 가지의 다양한 서비스를 사용하고 계실 경우에는 훨씬 더 많은 변수들을 고려하셔야 하기 때문에 정확한 비용 예상이 더 어려운 경우가 많습니다. 그 모든 내용들을 이번 포스팅을 통해 전달드리기엔 어려운 점이 있어, 오늘은 게임사 인프라 비용의 대부분을 차지하는 3 가지 서비스 – EC2(Elastic Compute Cloud, 가상서버), EBS(Elastic Block Store, 블록 스토리지), DT(Data Transfer, 데이터 전송) – 비용에 초점을 맞춰 설명드리고자 합니다

1. 게임 출시 전 예상 인프라 비용 산출하기

실제 런칭을 준비중이신 게임 고객사분들을 만나 오면서 가장 많이 받은 질문 중 하나는 예상 비용 산출과 관련된 내용입니다. 그 중에서도 준비하시는 게임의 장르와 타깃 동접(동시 접속자)수를 기준으로 예상 AWS 비용을 문의 주시는 경우가 가장 많습니다. 사실 장르와 타깃 동접수를 통해 AWS 비용을 바로 예측하여 답변드릴 수 있으면 정말 좋겠지만, 이는 생각보다 쉬운 일이 아닙니다. 예를 들어, 동접 유저 5,000명을 유지하고 있는 MMORPG 장르의 두 개의 게임이 있다고 가정해보겠습니다.

비록 동접수가 거의 유사하더라도 그 게임의 어플리케이션 개발 로직 및 아키텍처에 따라 그 비용은 무척이나 상이한 경우가 많습니다. 따라서, AWS에서 예상 비용을 산출하기 위해서는 반드시 PoC(Proof of Concept) 테스트 과정이 필요하며, 일반적으로 하기와 같은 프로세스를 걸쳐 최종 예상 비용을 산출해보실 수 있습니다. 해당 PoC 테스트를 진행하기 위한 비용은 AWS KOREA 게임팀에서 지원드리고 있으니, 관련하여 비용 및 기술적인 도움이 필요하신 경우 언제든지 aws-gaming-korea@amazon.com 로 연락주시기 바랍니다.

1) 예상 스펙 우선 선정하기

(1) EC2 (Elastic Compute Cloud, 가상서버)
우선, 테스트를 진행해보기 위해서는 AWS에서 제공하는 가상서버인 Amazon EC2에서 vCPU 및 Memory 사이즈를 기반으로 대략적인 EC2 스펙을 준비해야 합니다. 그 동안 AWS에서는 고객의 워크로드에 따라 다양한 유형의 인스턴스를 추가해오다 보니, 수많은 유형의 EC2 중에서 어느 EC2를 선택해야 할지 가끔 혼란이 오기도 합니다.

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

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

모든 EBS의 경우, 초기에 설정하신 볼륨 용량을 줄이시기 위해서는 스냅샷을 생성하고 새롭게 EBS 볼륨을 만드셔야 하는 번거로운 과정이 따릅니다. 따라서, EBS 볼륨을 처음 생성하시기 전에 반드시 두 가지 사항을 참고하시어 워크로드에 가장 적합한 EBS 타입을 선택하시는 방안을 권장드립니다.

먼저, 범용 SSD(gp2) 및 프로비저닝된 IOPS SSD(io1)의 특징을 고려해보아야합니다. 16,000 IOPS 이하의 디스크 성능이 요구될 때, 해당 성능은 범용 SSD(gp2) 및 프로비저닝된 SSD(io1) 모두를 통해 달성할 수 있지만 비용상 차이는 매우 크게 날 수 있습니다. 예를 들어, 워크로드에 1,000 IOPS가 필요한 경우, 요구사항을 달성할 수 있는 두 볼륨의 비용 차이는 하기와 같이 3배 가까이 비용이 차이가 날 수 있기 때문에 미리 비교를 해보셔야 합니다.

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

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

2) 실제 테스트 진행 하기

앞서 안내드린 내용을 기반으로 대략적인 EC2 및 EBS 스펙을 구성하셨을 것으로 예상됩니다. 이후, ApacheBench 나 JMeter 와 같은 도구를 통해 특정 시나리오를 기반으로 테스트를 하시거나 직접 개발하신 BOT 을 통해 부하 테스트를 진행하시게 됩니다. 이러한 부하 테스트 과정을 진행하시면서 CPU, Memory, Network 수치를 주로 모니터링하여, EC2 및 EBS의 스펙들을 실제 서비스에 맞게 수정하는 과정이 반드시 필요합니다. 좀 더 자세한 테스트 방안에 대해서는 ‘AWS 기반 게임 개발자를 위한 안내서 – 4부. 게임 런칭 전 부하 테스트 가이드’ 를 참고해주시기 바랍니다.

3) 런칭 당일 기준 서버 및 데이터 전송 예상 비용 산출하기

앞서 테스트를 통해 타깃하고 계신 런칭 당일의 피크 동접 유저 수를 기준으로 필요한 서버 스펙들이 결정되었을 것입니다. 해당 내용을 바탕으로 직접 AWS 비용 계산기를 통해 리전별 EC2 및 EBS의 한 달 예상 비용을 산출해보실 수 있습니다. 이를 통해 동접 대비 예상 인프라 사용량 그리고 고려하고 계신 시나리오(ex.타깃 동접 대비 30% 더 유입되었을 때 등)에 따라 더 상세한 예상 비용을 미리 계산해 보실 수도 있습니다.

특히, 데이터 전송량의 경우 런칭전까지는 거의 비용이 발생하지 않는 부분이기 때문에 예상 비용 시나리오에서 간과하시는 경우가 많습니다. 하지만, 런칭 이후에는 반드시 발생하는 필수적인 비용 요소이기 때문에 해당 내용을 반드시 인지하고 미리 계산해 보시는 방안을 권장드립니다. 관련하여 데이터 전송 비용 체계는 하기와 같은 구성되어 있습니다.

a) EC2에서 AWS 타 리전으로 데이터 송신 : 유료
b) EC2에서 AWS 동일 리전으로 데이터 전송 : 무료 또는 유료 (서비스별 가격 정책 상이)
c) 인터넷에서 EC2 로 데이터 수신 : 무료
d) EC2에서 인터넷으로 데이터 송신 : 유료

특히, 게임 내 데이터 전송 비용의 대부분을 차지하는 ‘d) EC2에서 인터넷으로 데이터 송신’의 경우, AWS 리전별로 금액이 상이하며 사용량의 구간별로 비용이 다르게 책정되어 있습니다. 서울 리전의 경우 2020년 7월 기준으로 하기와 같이 그 비용 체계가 구성되어 있습니다.

예를 들어 서울리전을 기준으로, 한 달 200TB의 데이터를 EC2를 통해 외부 인터넷으로 송신하는 경우의 비용은 하기와 같이 계산됩니다. 물론, AWS 비용계산기를 통해 해당 비용을 바로 확인해보실 수 있지만, 정확한 이해를 위해 하기와 같이 계산 로직을 명확히 확인해보시는 방안을 권장드립니다.

※ 한 달 200TB (200 x 1024 GB =204,800GB) 데이터 전송량(EC2에서 인터넷으로 데이터 송신) 예상시,
– 1 GB x 0 USD per GB = 0.00 USD
– 10,239 GB (10TB -1GB) x 0.126 USD per GB = 1290.11 USD
– 40,960 GB (40TB) x 0.122 USD per GB = 4997.12 USD
– 102,400 GB (100TB) x 0.117 USD per GB = 11980.80 USD
– 51,200 GB (50TB) x 0.108 USD per GB = 5529.60 USD
→ 전체 데이터 전송(EC2에서 인터넷으로 데이터 송신) 예상 월 비용 : 23,797.63 USD

2. 게임 출시 후 비용 최적화 하기

지금까지 안내드린 방식을 통해 게임 런칭시 AWS 사용 비용을 시나리오 별로 계산해 보셨을 것이라 생각됩니다. 하지만, 해당 비용은 런칭 스펙을 기준으로 약 한 달 동안의 예상치이며, 그 이후의 비용은 다시 또 달라질 수 밖에 없다는 점을 반드시 기억해주셔야 합니다. 실제 런칭 이후 1년간의 AWS 비용은 게임의 수명에 따라 많은 과정을 거치며 변화하게 됩니다. 특히 게임의 고유한 특성에 따라, 즉, 게임의 흥행 여부에 따라 런칭 이후 AWS 사용 비용이 급증 또는 급감하는 경우가 많으며 모바일 게임의 경우 게임의 수명주기가 더 짧아지면서 런칭 이후의 사용량을 정확히 예상하기가 더 어렵게 되었습니다.

따라서, 런칭 이후의 사용량을 정확히 예상해보는데 많은 시간을 할애하기 보다는, 런칭 이후 게임 수명주기에 맞춰 인프라를 어떻게 최적화하여 비용 효율적으로 AWS를 사용할지에 대해 준비하시는 과정이 더 중요하다고 말씀드리고 싶습니다.
특히, AWS에서는 과거 온프렘 환경과 달리 서버 스펙을 계속 조정할 수 있기 때문에 지속적으로 정기적인 모니터링을 해주어야 합니다. 이를 통해 실제 사용하는 것보다 큰 규모의 인프라를 사용하여 원래 지불해야할 비용 보다 더 많은 금액을 지출하는 경우를 피할 수 있습니다. 따라서 게임 런칭 이후의 향후 예상 비용은 주어지는게 아니라 직접 만들어 나가는 과정으로 이해해주셔야 합니다. 이를 위해 반드시 알고 계셔야 할 게임 수명 주기에 맞춰 비용을 최적화하실 수 있는 두 가지 방안을 안내 드리고자 합니다.

1) 비용 체계 관점에서

비용 체계 관점에서 AWS EC2 를 사용하시는 방법에는 온디맨드(On-Demand), 예약 인스턴스 (Reserved Instance), 세이빙스 플랜(Savings Plan), 스팟 인스턴스 (Spot Instance) 가 있습니다.

(1) 온디맨드
가장 기본이 되는 비용 체계이며, 실행되는 인스턴스에 따라 시간당(Windows) 또는 초당(Linux) 비용을 지불합니다. 장기 약정이나 선결제 금액이 필요하지 않으며, 어플리케이션 수요에 따라 인스턴스를 언제든지 늘리거나 줄이실 수 있습니다.

(2) 예약 인스턴스
1년 또는 3년 기간 동안 해당 인스턴스의 종류와 대수(ex. M5.large / Linux / 2대)를 약정하여 EC2 비용을 최대 72% 할인받을 수 있는 비용 쳬계입니다. 할인 금액은 인스턴스 타입별/기간별/지불방식별로 모두 상이하기 때문에 구매전 반드시 확인해보셔야 합니다.

(3) 세이빙스 플랜
1년 또는 3년 기간의 일정 사용량 약정(시간당 USD 단위)을 조건으로 EC2, Lambda 및 Fargate 사용량에 대해 할인을 제공하는 비용 체계입니다. 예를들어 해당 컴퓨터 사용량을 시간당 15 USD을 납부하여 사용중에 있고, 이중 10 USD의 컴퓨팅 사용량을 세이빙스 플랜으로 약정하면, 10 USD에 해당하는 사용량까지 세이빙스 플랜 요금을 적용받고, 약정을 초과하는 5 USD 사용량에 대해서는 온디맨드 요율을 적용받습니다.

(4) 스팟 인스턴스
스팟 인스턴스는 온디맨드 가격 대비 최대 90%를 절약할 수 있는 여분의 EC2 용량으로서 2분 전에 공지하고 인스턴스가 종료될 수 있습니다. 언제든지 중단될 수 있다는 특징때문에 실제 게임 운영과 관련된 워크로드 보다는 테스트/개발 워크로드 및 빅 데이터 분석 등에 쓰시는 방안을 권장드립니다.

보통 온디맨드를 통해 게임을 런칭하시고 3-6개월 정도의 모니터링을 통해 향후 1년 또는 3년 동안의 최소 사용량에 대해서만 세이빙스 플랜 및 예약 인스턴스를 구매하시는 방안을 권장드립니다. 즉, 3-6개월 간의 모니터링을 통해 향후 1년 간 최소로 사용할 것으로 예상되는 만큼(ex. 현재 사용량의 30%)만 세이빙스 플랜 및 예약 인스턴스를 구매하시고, 게임이 안정화 되면서 그 비율을 높여가는 방식으로 구매하시는 방안을 권장드립니다. 또는 게임서버가 아닌 향후 1년 또는 3년간 꾸준히 사용할 것으로 예상되는 워크로드(ex.플랫폼 서비스)가 있다면 온디맨드가 아닌 세이빙스 플랜 및 예약 인스턴스를 50%이상 구매하시어 비용을 절약하실 수 있습니다. 또한 분석 워크로드 등을 위해 대용량의 컴퓨팅 파워가 필요하신 경우에는 스팟 인스턴스를 적극 활용하시어 온디맨드 대비 최대 90% 할인된 금액으로 EC2를 사용하실 수 있습니다.

이러한 의사결정을 하시기 위해 필요하신 모든 데이터들은 AWS Cost Explorer 을 통해 하기와 같이 확인해보실 수 있으며, 현재 AWS 파트너사를 통해 AWS를 사용 중이신 경우에는, 해당 파트너에 데이터를 요청하시어 관련 자료를 받아보실 수 있습니다. 또한, 사용량 분석에 대한 AWS 파트너사의 전문적인 리포팅 및 컨설팅을 통해 좀 더 정확한 예상 사용량을 기반으로 다양한 비용 체계를 활용하실 수 있습니다.

(AWS 비용 최적화 – 리디북스의 예약 인스턴스 활용 사례 : 비용탐색기 – RI Coverage 리포트)

2) 게임의 수명 주기 관점에서

모바일 게임의 경우 게임의 수명 주기가 점점 더 짧아지고 있습니다. 따라서 AWS 비용 관리 관점에서는 하루 하루 다르게 변화하는 트래픽에 맞춰 서버 사용량을 점검하고 서버 스펙을 최적화하여 AWS 인프라 운영 비용을 줄여 나가야 합니다. 예를 들어 A 라는 모바일 게임의 경우 런칭이 진행되었던 첫 번째 달의 동접 유저 트래픽을 100%라고 가정해볼때, 3개월이 지난 후 동접 유저 트래픽이 80%, 9개월이 지난 후 동접 유저트래픽이 50% 로 감소하면서 최종 1년 후에는 서버 통합이 있었다고 가정 해보겠습니다.

이러한 경우, Amazon CloudWatch 및 AWS Cost Explorer 를 통해 지속으로 CPU/Memory/Network 수치를 모니터링함으로써 서버 스펙을 낮춰나갈 수 있습니다. 또한 감소한 유저 트래픽에 따른 서버 타입 및 스펙을 AWS Compute Optimizer를 통해 자동으로 추천받으실 수도 있습니다. 특히 AWS Compute Optimizer를 사용하면 인스턴스 제품군 내에서 인스턴스 유형 권장 사항을 살펴볼 수 있으며, 인스턴스 제품군 내 또는 전체에 걸쳐 다운 사이징 권장 사항, 성능 병목 현상을 제거하기 위한 업 사이징 권장 사항 및 Auto Scaling 그룹의 일부인 EC2 인스턴스에 대한 권장 사항을 제공받으실 수 있습니다. (AWS Compute Optimizer에 대한 자세한 소개는 동영상를 참고해주시기 바랍니다.)

더불어 트래픽이 줄어드는 시기, 또는 간헐적인 트래픽이 발생되는 시기라고 판단하실 경우에는 T 타입과 같은 성능 순간 확장 가능 인스턴스 타입을 적극 고려해보시는 방안을 권장드립니다. 기존 Amazon EC2 인스턴스 유형은 고정된 CPU 사용률을 제공하는 반면, 성능 순간 확장 가능 인스턴스인 T3, T3a 및 T2 인스턴스는 기본 수준의 CPU 성능과 함께 워크로드에서 필요한 만큼 성능을 높이는 버스트 기능을 제공하도록 설계되었습니다. 예를 들어 평소 사용하던 c5.large 타입의 CPU 사용률이 20% 이하이고 크게 튀는 spike 트래픽이 없는 경우에는 유사한 스펙(2vCPU / 4Memory)를 가진 t3.medium으로 변경하시어 기존대비 46% 할인된 금액으로 서비스를 운영하실 수 있습니다. 실제 많은 게임사에서 T타입의 인스턴스를 적극 사용하고 있지만, 기준 사용률과 버스트 기능은 T 타입의 CPU 크레딧이라는 개념에 의해 좌우되기 때문에 실제 게임 서버에 도입하시기 전에는 반드시 여러 관점에서 검증 및 테스트 해보시는 방안을 권장드립니다.

마치며

이 글에서는 과거 온프렘/IDC 환경과 달리 AWS를 사용하여 게임 출시를 준비하실 경우의 비용 계산과 출시 이후의 비용을 관리해나갈 수 있는 방안들에 대해 정리해보았습니다. 이 안내서가 여러분의 AWS 여정에 작은 도움이 되길 바래봅니다. 또한 본 글에서 다 담지 못한 다양한 비용 최적화 방안에 대해 잘 정리되어 있는 블로그 자료(AWS 비용을 줄일 수 있는 10가지 기법)를 전달드리오니 참고 부탁드리겠습니다. 추가로 궁금하신 내용 및 기술 지원이 필요하신 내용이 있다면 언제든지 aws-gaming-korea@amazon.com으로 문의하여 주시기 바랍니다.

– 김진우, AWS 게임 어카운트 매니저

더 자세한 것은 최근 AWS 기반 게임 개발을 안내서 시리즈나 게임 개발 카테고리를 참고해주시기 바랍니다.

Amazon Web Services 한국 블로그