AWS 기반 게임 개발자를 위한 안내서 – 4부. 게임 런칭 전 부하 테스트 가이드

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

오늘은 1부. 게임 서비스 분산 서비스 거부 (DDoS) 공격 패턴 및 대응 방법와 2부. 게임 출시 전 반드시 챙겨야 할 것, 3부. 게임 개발 및 운영을 위한 유용한 AWS 서비스에 이어 게임 런칭 전 부하 테스트 가이드를 정리해 보겠습니다.

게임을 출시하기 전 정확한 동작과 서비스를 보장하기 위해 작은 로직을 검사하는 유닛 테스트부터 인증, 결제 등 외부 서비스와의 연동 테스트까지 다양한 테스트들이 반드시 필요합니다. AWS 기반 게임 개발자를 위한 안내서 시리즈를 처음 보셨다면 2부. 게임 출시 전 반드시 챙겨야 할 것들을 먼저 읽어 보시길 바랍니다.

참고로, 이 글은 AWS 기반 웹 및 애플리케이션 서버 부하 테스트: A to Z를 기반으로 작성하였습니다. 2016년 글이지만 여전히 유효하고 ,부하 테스트를 위한 전반적인 이야기를 다루는 좋은 글이므로 꼭 한번 읽어 보시길 권장 드립니다.

1. 부하 테스트의 목적

일반적으로 부하 테스트는 서비스 개발 이후, 운영을 하기 직전 수행하는 테스트 중 하나로서, 실제 요구되는 부하를 서비스가 실제 수용할 수 있는지 확인하기 위한 작업 입니다. 사용자 활동을 시뮬레이션 하고 인프라 및 서버의 동작을 모니터링 함으로써, 전부는 아닐지라도, 많은 부분의 병목 현상(Bottleneck)을 제거할 수 있습니다.
부하 테스트의 목적으로는 보통 다음과 같이 세 가지가 있습니다.

현재 서비스 구성의 제한(limit)을 찾기 위함
원하는 부하를 수용할 수 있게끔 구성되었는지 확인하기 위함
병목 지점을 찾고 병목 현상을 제거하기 위함

2. 부하 테스트 전 고려되어야 할 점

실제 성능 테스트 시, 부하 테스트를 비중 있게 여기지 않는 경우가 많으며, ApacheBench 나 JMeter 와 같은 도구를 다운로드 한 뒤, 특정 시나리오를 기반으로 하여 도구를 실행하는 것 만으로 충분하다고 생각하는 경우가 있습니다. 하지만, 실제 워크로드는 다양한 변수와 시나리오를 가지고 있기 때문에, 부하 테스트를 진행 할 때는 과하다 싶을 정도의 경우를 산정하고 부하를 밀어 넣어야 향후 실제 서비스를 안정적으로 운영할 수 있습니다.
그럼 실용적인 부하 테스트를 위해 어떤 부분들을 고려해야 할까요?

충분한 테스트용 인프라 자원 확보: 최대의 트래픽을 생성하여 테스트 하기 위해서는 충분한 인프라 자원이 요구되며, 부족할 경우 적절한 테스트를 진행하기가 쉽지 않습니다.
테스트 시, 블랙박스 혹은 격리된 환경 제어: 부하 테스트는 많은 요청과 패킷을 생성하기 때문에 사내 인프라의 많은 부분을 포화 상태로 만들기 쉽습니다. 이를 방지하기 위해 제한된 자원만 할당된 블랙 박스 혹은 격리된 환경에서 테스트를 수행하는 경우가 많습니다.
글로벌 기반의 부하 생성: 글로벌 서비스의 경우, 전 세계 각 지역에서 부하를 생성하여 테스트를 진행하여야만 실제 사용 패턴에 가까운 시나리오가 될 수 있습니다. 이를 통해 글로벌 커버리지를 확인할 수 있으며, 실제 워크로드에서 얻을 수 있는 유사한 각종 성능 관련 지표도 얻을 수 있습니다.
높은 비용과 불규칙적인 사용성에 대한 주의: 격리된 환경과 더불어 여러 리전을 커버하기 위한 테스트 환경은 때로 높은 비용을 요구합니다.
테스트 환경은 짧은 기간 동안 집중적으로 사용되고, 사용된 후에는 한동안 방치됩니다. 하지만 사용이 완전히 끝난 것은 아니기 때문에 섣불리 없애버리면 추후에 테스트 환경을 재구성하는데 시행착오와 시간을 다시 쓰게 됩니다. 테스트 환경을 남겨두어도 비용이 발생하며, 매번 새롭게 만들어도 여기에 들어가는 엔지니어의 시간 역시 비용입니다. 테스트 환경을 필요할때만 자동으로 생성 할 수 있다면 비용을 많이 아낄 수 있습니다.
높은 아키텍처 복잡성에 대한 주의: 상기 언급된 부분들을 고려하여 부하 테스트 환경을 구성한다면 꽤나 높은 복잡성이 요구 됩니다. 나아가 반복적인 테스트를 위해, 가상의 가짜(Dummy) 데이터 등에 의해 지저분해진 환경을 초기화 시켜 줄 수 있는 방안도 필요 합니다.

3. AWS 기반 부하 테스트의 장점

AWS 는 부하 테스트를 진행하기 위해 고려할 사항에 대한 적절한 해답을 가지고 있습니다. AWS 에서 부하 테스트 하게 된다면 어떤 특징을 가지고 있을까요?

비용 효율성: Amazon EC2 인스턴스는 사용한 만큼만 비용이 발생하기 때문에, 테스트 조건에 맞는 인스턴스 타입을 선택하여 비용 효율성을 높일 수 있습니다. 인스턴스 사용이 끝나면 즉시 종료할 수 있어 불필요한 비용 발생을 줄일 수 있습니다. 또한, 미사용 EC2 용량을 활용하는 스팟 인스턴스를 사용한다면, 온디맨드 비해 최대 90%까지 저렴한 비용으로 부하 테스트를 진행할 수 있습니다.
충분하고 유연한 컴퓨팅 자원 제공: AWS가 제공하는 컴퓨팅 자원을 활용한다면, 필요한 규모의 부하에 대해 자유롭게 테스트를 수행할 수 있습니다. 또한, 오토스케일링(Auto Scaling)을 통해 부하 테스트 시 자원을 자동으로 증설 혹은 감소 시킬 수 있습니다.
글로벌 리전(Region)으로부터의 부하 생성: AWS가 제공하는 글로벌 인프라를 통해 전 세계 각 리전으로부터 부하 생성을 손쉽게 할 수 있습니다.
쉽고 단순한 아키텍처 구성 및 관리: AWS CloudFormation 을 비롯한 다양한 배포 자동화 서비스 및 기능을 통해 프로덕션과 테스트 용 환경을 동일한 방법으로 손 쉽게 구성할 수 있습니다. 뿐만 아니라 관리형 서비스를 활용하여 운영 측면에서 부담도 줄일 수 있어, 테스트 환경 구축에 관한 복잡성을 줄일 수 있습니다.

4. 웹서비스 부하 테스트

1) 웹 서비스의 단계별 부하 테스트 수행 방법

앞서 언급한 것처럼, 부하 테스트는 전체 스택에 대해서도 수행 가능하지만, 작은 비결합된 컴포넌트나 기능 단위로도 수행 가능합니다. 그리고 작은 단위로 수행될 수록 더 분명하게 병목 지점을 파악하기에 수월 합니다. 그렇기에, 가능한 작은 단위부터 단계별로 진행하는 것이 원하는 결과를 얻어내는데 효율적입니다.
다음은 전형적인 3단계(3-tier) 웹 서비스에 대해 단계별로 부하 테스트를 진행하는 것을 설명하고 있습니다.

최초 ‘WEB’ 을 출력하는 웹 페이지를 대상으로 동시 연결성에 대한 테스트 수행 → 결과 평가→최적화 진행 (Client →Web Server)
웹 서버를 통해 애플리케이션 서버에서 넘겨 받은 ‘APPLICATION’ 을 출력하는 웹 페이지를 대상으로 동시 연결성에 대한 테스트 수행→ 결과 평가 → 최적화 진행 (Client →Web Server → App Server – w/o Logic)
데이터베이스에서 최소한의 쿼리 결과를 전달 받아 출력하는 웹 페이지를 대상으로 동시 연결성에 대한 테스트 수행 →결과 평가 → 최적화 진행 (Client →Web Server → App Server – w/o Logic → Database)
3-tier 스택 전체를 대상으로 애플리케이션 로직이 적용된 페이지에 동시 연결성에 대한 테스트 수행 → 결과 평가 → 최적화 진행 (Client → Web Server → App Server – with Logic →Database)
4번을 기반으로 다양한 시나리오를 지정하여 테스트 수행 → (얻고자 하는 지표 기준에 대해서) 결과 평과 → 최적화 진행

2) 웹서비스 부하 테스트 시, 각 레이어별 고려하여야 할 사항

부하 테스트를 수행한 뒤 각 레이어별로 발생할 수 있는 상황과 고려하여야 할 부분에 대해서 알아보도록 하겠습니다.

(1) 네트워크 용량 확인: 테스트 환경이 구성된 인프라와 관련하여 여러가지 지표를 확인할 수 있지만, 대표적으로 아웃바운드 연결이 예상되는 최대의 부하를 처리할 수 있는지 확인할 필요가 있습니다. Amazon EC2 의 경우 인스턴스 타입 마다 서로 다른 네트워킹 성능을 제공하고 있기에, 부하에 따른 적절한 인스턴스 타입 선택이 중요 합니다. 또 사내 인프라와 프라이빗하게 연결되어 있다면, V PN 관련 네트워킹 성능에 대해서도 확인을 하여야 합니다.
(2) 부하 생성 클라이언트: 앞서 설명하였듯이 부하 테스트의 요구 사항 중 하나로, 필요한 만큼의 부하를 생성할 수 있는 충분한 인스턴스 확보가 요구됩니다. 하지만, 설정 및 구현 방식에 의해 하나의 부하 생성 클라이언트가 처리할 수 있는 동시성에 큰 제한이 있다면, 필요 이상으로 복수개의 인스턴스가 요구되어 비용이 증가할 수 있습니다. 이럴 땐 Thread 기반의 툴 보다는 높은 동시성을 제공하는 Async IO 기반의 툴을 사용하여 테스트를 진행하는게 좋습니다.
(3) 로드 밸런싱: ELB(Elastic Load Balancing)는 서비스 전체 부하를 백엔드에 등록된 복수의 인스턴스로 분산하는 기능을 제공합니다. 부하 테스트를 수행할 때 다양한 이유로 기대치 보다 낮은 결과나 5xx 에러가 발생하는 것을 볼 수 있습니다. 이 때, ELB 가 제공하는 다양한 모니터링 지표들을 확인하면, 어느 곳에서 병목 현상이나 에러가 발생되는지 확인하는데 도움이 됩니다. ELB 가 제공하는 지표들은 여기에서 확인할 수 있습니다.
추가로 ELB 도 발생하는 부하에 따라 Auto Scaling 을 통해 규모가 변화되도록 설계 되어 있습니다. 만약, 매우 급격한 트래픽 증가가 일어날 때 ELB 가 확장되는 속도가 증가하는 트래픽을 수용하지 못한다면 5xx 에러가 발생할 수 있습니다. 이를 방지 하기 위해, 미리 점차적으로 증가하는 부하 테스트를 통해 어느정도 ELB 를 확장 시켜 둘 수 있습니다. 또한, ELB 에 등록된 백엔드 인스턴스에서 Keep-Alive 기능을 활성화 시켜, ELB 와 백엔드 인스턴스간에 불필요한 연결 수립이 일어나는 것을 방지한다면 더 높은 성능을 기대할 수 있습니다.
(4) 서버 인스턴스: 서버 인스턴스의 설정 값에 따라 웹/애플리케이션 서버의 자원 사용 효율성이 달라 집니다. 대표적으로 Linux 서버의 open files 숫자를 늘려 두지 않으면, 동시 접속이 기본값인 1024 개로 제한되어 서버 인스턴스를 효과적으로 사용할 수 없습니다.
(5) 애플리케이션 서버: 애플리케이션 서버의 종류마다 다르지만, 일반적으로 Tomcat 등의 Thread 기반의 애플리케이션 서버일 경우, Thread Pool 의 크기가 너무 작다면 처리 되어야 할 요청들이 기다리는(waiting) 상태가 길어져 전체 부하 테스트의 효율성을 떨어뜨릴 수 있습니다. 최근에는 Thread 기반의 애플리케이션 서버가 가지고 있는 제약으로 인해, Event 기반의 비동기 형태의 애플리케이션 서버가 자주 사용되어 집니다.
(6) 애플리케이션: 애플리케이션 코드와 프레임워크 둘로 나누어 생각해 볼 수 있습니다. 애플리케이션 코드 내에서 잘못된 방식으로 프레임워크나 API 를 사용할 수 있으며, blocking 코드가 포함되어 있다거나, 불필요한 연산을 진행하거나, 테스트 코드를 삭제하지 않는 등의 문제가 있을 수 있습니다. 이 때에는 적절한 Unit Test 와 Lint 등을 통해 문제를 조기에 발견할 수 있어야 합니다. 사용하는 웹 프레임워크나 ORM(Object-relational mapping)과 같은 라이브러리가 가지고 있는 버그로 인하여 문제가 발생할 수도 있습니다. 애플리케이션 관련 다양한 문제를 해결하기 위해 APM(Application Performance Monitoring) 을 활용하여 성능을 모니터링 하는 것도 한가지 방법 입니다.
(7) 데이터베이스: CPU 사용률과 응답 시간(response time) 등을 확인할 필요가 있습니다. 특히 데이터베이스를 설정한 방법에 따라 더 요구되는 자원을 눈 여겨 볼 필요가 있습니다. 최근에는 성능을 향상 시키기 위해 메모리를 적극 활용하게끔 설정을 하는 경우가 많으며, 이때에는 메모리 사용률이 특정 수치 이상으로 넘어갈 경우, 알람을 발생 하도록 설정하여 병목 지점 확인이 가능 하겠습니다.

5. 게임에서 부하 테스트

위에서 우리는 웹서비스에서 부하테스트를 알아봤습니다. 웹 서비스는 단순하면서 범용적으로 사용하는 스택으로 테스트 목적을 이해하고 각 단계를 이해하는데 도움이 됩니다. 더불어, 게임에서도 플랫폼 서비스나 캐주얼게임의 경우 웹기반 백엔드를 주로 사용하기 때문에 위의 방식과 같이 테스트를 진행 할 수 있습니다.

그렇다면 MMORPG 장르나 세션 베이스 장르(데디케이티트 서버를 가지는 게임 장르) 경우에는 어떻게 해야 할까요?

1) MMORPG 장르에서 각 레이어

(1) 게임서버: MMORPG는 최대한 많은 사용자들과 최대한 낮은 레이턴시를 유지해야 유저들이 쾌적하게 플레이 하기 때문에 모든 데이터를 메모리에 올려두고 장비의 성능을 최대한 뽑아내도록 개발합니다. 또한 네트워크 레이턴시를 최대한 줄이기 위해, 게임 서버 구성에 많은 레이어를 두지 않습니다. 여러 서버로 하나의 월드를 구성하는 경우에도, 하나의 지역을 여러 서버가 담당하는 게 아니라 지역을 쪼개서 서버들이 겹치지 않게 합니다. 이러한 이유로 유저는 늘 특정 서버에 접속해 있어야 하며, 이것을 스테이트풀(Stateful) 어플리케이션이라고 합니다. 보통, 이러한 스테이트풀 어플리케이션 앞에는 로드 밸런싱을 두지 않습니다.

게임 서버 테스트 시 주요 모니터링 속성은 CPU, 메모리 누수, 네트워크 입니다.

쓰레드(Thread) 개수는 CPU 코어 개수와 비슷한 것이 이상적이지만, 복잡한 서버 개발을 하다보면 쓰레드가 늘어나곤 합니다. 보통 인스턴스의 CPU 코어 개수가 늘어나면 쓰레드 개수도 비례하여 늘리게 되는데, 어느순간 임계값을 넘어가면 컨텍스트 스위칭(Context Switching)과 락(Lock)에서 필요 이상의 CPU를 쓰거나, 하나의 락을 기다리는 쓰레드들이 모든 코어에 올라와 CPU 자원이 남게 됩니다. 모니터링 시, 트래픽양과 비례하여 CPU가 올라가는지, 콜스택 통계에 락에 관련된 시스템콜에서 시간을 많이 쓰지는 않는지 살펴봐야 합니다.

메모리 사용량은 큰 문제가 되지 않지만 메모리 누수는 살펴봐야 합니다. 테스트 전 힙 메모리 덤프를 뜨고, 부하테스트가 끝난 후 힙 메모리 덤프를 다시 떠서 두개를 비교하여 누수 여부를 확인 할 수 있습니다.

네트워크는 레이턴시와 대역폭 모두 확인해야 합니다. MMORPG, 액션, FPS는 레이턴시에 민감한 장르 입니다. 게임 기획 및 개발시 예상한 하한 레이턴시를 충족하는지 모니터링 해야합니다. 대역폭도 중요합니다. 게임 서버 입장에서는 10ms내에 응답 했어도 대역폭에 막혀 실제 유저가 느끼는 레이턴시는 매우 높을 수 있습니다. 유저 수에 따라 어느정도 대역폭을 사용하는지 파악하고 프로덕트 환경에서 이 값을 바탕으로 적정 사이즈의 인스턴스를 선택해야 합니다. 따라서 테스트 환경에서는 높은 대역폭을 제공하는 인스턴스에서 테스트 하는것이 좋습니다. 또한 Amazon EC2에는 향상된 네트워킹 기능이 있으니 필히 활용하시길 바랍니다.

(2) 데이터베이스: MMORPG에는 어떤 아이템이 생성 됐는지, 이 아이템을 누가 소유 했는지 굉장히 중요합니다. 많은 MMORPG에서 이러한 중요 객체의 Atomic Operation을 처리하는데 DB의 트랜잭션을 활용합니다. 그리고 쿼리의 관리와 성능 향상을 위해 스토어드 프로시저를 사용합니다. 이 말은 DB에서 트랜잭션 처리를 하는데 성능이 들쭉날쭉하면 이것이 그대로 유저의 게임 플레이에 영향을 준다는 뜻입니다. 부하 테스트시에는 CPU를 살펴보며 DB의 인스턴스 사이즈가 너무 작지는 않은지 살펴보고, 주요 트랜잭션들의 수행시간이 짧으면서 안정(jitter)적인지 봐야 합니다. 또한 캐시 히트율은 높게 유지 되는지, 디스크에서 병목이 발생 하지 않는지 확인하여 필요 IOPS를 산정 해야 합니다.

(3) 캐시 서버: 많은 MMORPG 게임의 아키텍쳐에서 데이터베이스가 굉장히 중요하므로 불필요한 부하를 최대한 줄여주기 위해 캐시 서버를 둡니다. 캐시 서버를 사용할때는 캐시 서버를 순수 캐시용으로 쓸것인지, 메모리가 가득 찼을 때 어느 데이터부터 뺄것인지 정책이 중요합니다. 따라서 캐시용도의 데이터는 분명하게 TTL을 주어 쓸모 없는 데이터가 메모리를 갉아먹지 않도록 하고, 메모리가 가득 찼을 때도 어느 데이터를 내릴 수 있는지 힌트로 사용할 수 있도록 합니다.
또한 캐시 서비스들은 해시 알고리즘을 기반으로 만들어졌기 때문에 전체 데이터를 대상으로 순회하거나 조회하는 기능은 제한적 입니다. 개발시에는 작은 데이터에서 순회에 걸리는 시간이 티가 나지 않지만 부하테스트에서는 이것이 실제로 얼마나 큰 영향을 주는지 확인해 볼 수 있습니다.
부하 테스트시에는 CPU 사용율, 메모리 사용율, 초당 요청 수, 응답시간을 모니터링 합니다. 그리고 캐시 히트율을 보면서 기대대로 동작하는지 확인합니다. 좀 더 심도 있는 테스트를 한다면, 위에서 설명한 시나리오를 만들어서 메모리가 가득 찼을 때 관리 정책에 맞춰 캐시를 유지하는지 확인하면 좋습니다.

(4) 부하 생성 클라이언트: MMORPG는 패킷을 최대한 간결하게 만들기 위해 바이너리 프로토콜을 사용합니다. 따라서 시중의 범용 부하 테스트 툴을 사용하는데 제약이 있을 수 있습니다. 또한 로직이 매우 복잡하므로, 봇을 직접 만들어서 테스트하는 것이 가장 좋습니다. 만약 봇을 만들기 어렵다면, 커스텀 프로토콜을 만들고 분기나 반복 수행 등 로직을 넣을 수 있는 테스트 툴이 필요합니다. JMeter 는 프로토콜 및 테스트 로직을 Java로 직접 구현할 수 있고 Nagle알고리즘 사용 여부 지정처럼 TCP 옵션도 조절 할 수 있는 좋은 후보입니다.

2) MMORPG에서 단계별 테스트 수행 방법

DB가 필요없는 동작에 대해서 부하 테스트를 진행합니다. 예를 들면 브로드캐스트를 시험합니다. MMORPG는 유저의 좌표에 대한 브로드캐스팅이 매우 많습니다. 유저가 많이 모여서 동시에 움직이면 N^2의 브로드캐스트 패킷이 발생하게 됩니다. 보통 성능 때문에 커스텀 바이너리 프로토콜을 사용하는데, 패킷에 유저별 검증코드를 심었다면, 브로드캐스트에서 수많은 직렬화/역직렬화를 하느라 많은 CPU시간을 소비하게 됩니다.
캐시 서버를 통하는 부하 테스트를 진행합니다. MMORPG에는 수 많은 오브젝트가 있고, 이를 DB가 아니라 캐시 서버에 저장하고 있다가 빠르게 가져올 수 있습니다. 이를테면 투기장에서 상위 랭커의 점수와 장비를 보여준다면, 이를 캐시서버에 저장해두고 필요 시 가져다 쓸 수 있습니다. 이렇게 하면 로그아웃중인 랭커의 외형을 쉽고 빠르게 불러 올 수 있습니다. 또한, 채팅의 경우 Pub/Sub 모델을 사용하면 만들기 쉬운데, Redis는 이를 내장하고 있습니다. Redis Pub/Sub을 이용해 채팅을 만들었다면, 수많은 채팅을 발생시켜 Redis의 부하테스트를 해 볼 수 있습니다.
모든 시나리오를 적용해서 테스트 합니다. 특히나 아이템 생성, 아이템 교환, 아이템 강화와 같이 DB를 반드시 거쳐야 하는 매우 중요한 로직을 수행 시킵니다.

3) 세션베이스 장르에서 부하 테스트

데디케이티드 서버는 정해진 유저만을 받으며 특정한 라이프타임이 있다는 특징이 있지만, 기본적으로 MMORPG서버처럼 스테이트풀 어플리케이션입니다. 따라서 부하테스트는 MMORPG서버와 비슷하게 진행될 수 있습니다. 다만 게임 서버가 필요로 하는 최대 리소스 지점을 확실하게 파악할 필요가 있습니다. 데디케이티트 서버를 운영하는데는 Amazon GameLift같은 관리형 서비스를 사용할 수 있으며, 컨테이너 오케스트레이션을 사용하거나, 이 모든것을 직접 만들어 사용할 수도 있습니다. 방식은 다양하지만 공통적으로 이들 모두 하나의 인스턴스에 여러개의 데디 서버를 띄우는 방식으로 비용 및 운용 효율성을 높이게 됩니다. 따라서 어느 인스턴스에서 데디 서버가 몇개가 들어갈 수 있는지 정확히 알아야 하며, 부하테스트에서 이를 찾을 수 있습니다.

6. 마치며

프로젝트가 시작할때는 언제나 오픈 전에 부하 테스트를 계획하지만 막상 오픈이 다가오면 할일은 산더미처럼 쌓이게 됩니다. 그러면서 시간이 많이 걸릴 수 있는 부하테스트를 위해 시나리오를 짜고 환경을 만드는걸 포기하는 경우가 많습니다. 하지만 우리가 예상한 부분은 기대처럼 돌아가지 않고 생각지도 못한 유스케이스가 발생하면서 전체 서비스를 망가뜨리는 경우가 발생하기도 합니다.

급하더라도 테스트를 하면서 문제를 찾아 해결해 나가는것이 전체적인 시간을 줄여주고 서비스의 품질을 높이는 방법입니다. 위의 설명들이 각 컴포넌트들에게 기대하는 바와 어떤 부분을 검사해 나갈지에 대해 많은 도움이 되었으면 합니다. 또한, 부하테스트를 진행하시는 과정에서 발생되는 비용들을 지원드리고 있습니다. 관련 PoC(Proof of Concept) 지원 프로그램과 추가 궁금하신 내용 및 기술 지원이 필요하신 내용에 대해서는 언제든지 aws-gaming-korea@amazon.com으로 문의해주시기 바랍니다.

마지막으로 게임 솔루션즈 아키텍트들이 진행하는 AWS Game Master 웨비나를 소개합니다. 앞으로 6월 17일 (수)/ 6월 30일 (화)/ 7월 14일 (화)/ 7월 28일 (화) 네 번에 걸쳐 트위치(Twitch)에서 라이브로 방송합니다.

이 시간에는 저희가 블로그로 다뤘던 이야기와 국내 유명 게임 고객사 성공 사례도 준비될 예정이니 많은 관심 바랍니다.

– 유재석, AWS 게임 솔루션즈 아키텍트
– 박진성, AWS 게임 솔루션즈 아키텍트

Amazon Web Services 한국 블로그