Amazon Web Services 한국 블로그

Amazon DynamoDB: 게임 서비스 사용 사례 및 설계 패턴

VR 게임 이미지주요 글로벌 게임 서비스 업체들은 게임 상태, 플레이어 데이터, 세션 기록 및 리더보드 등 게임 플랫폼의 모든 부분에 AWS의 관리형 데이터베이스인 Amazon DynamoDB를 사용합니다. DynamoDB를 통해 얻는 주요 이점은 수백만 명의 동시 사용자 및 요청을 지원할 수 있는 규모로 안정적으로 확대하는 동시에 10밀리 초 미만의 낮은 지연 시간을 지속적으로 보장할 수 있습니다.

뿐만 아니라 DynamoDB는 완전 관리형 서비스이므로 운영 부담이 발생하지 않습니다. 게임 개발자는 데이터베이스 관리에 신경을 쓰지않고 게임 개발에 집중할 수 있습니다. 또한, 게임 제작자들은 단일 AWS 리전에서 여러 리전으로 규모를 확대할 때 DynamoDB 전역 테이블에 의존하여 다중 리전 활성-활성 데이터 복제를 구현할 수 있습니다.

이 게시물에서는 DynamoDB를 사용하는 게임 업체들의 가장 일반적인 사용 사례 및 설계 패턴 중 일부를 설명해 드리고자 합니다. 이 게시물에서는 다음과 같은 데이터 모델링 용어가 사용됩니다.

게임 사용 사례 및 설계 패턴

사용 사례 설계 패턴
게임 상태, 플레이어 데이터 스토어 1:1 모델링, 1:M 모델링
플레이어 세션 기록 데이터 스토어 1:1 모델링, 1:M 모델링
리더보드 N:M 모델링

사례 1. 게임 상태 및 플레이어 데이터 스토어

DynamoDB를 사용하여 플레이어 게임 상태 및 기타 플레이어 데이터를 저장하면 게임업체가 많은 수의 동시 플레이어를 지원하는 동시에 밀리초 수준의 액세스 지연 시간을 유지할 수 있습니다. 전 세계 등록 사용자의 수가 3억 명이 넘는 대형 비디오 게임업체인 Electronic Arts(EA)를 예로 들어 보겠습니다. EA의 경우 높은 동시성이란 초당 100,000회 이상의 요청과 수백만 명의 일일 활성 사용자를 의미할 수 있습니다. DynamoDB로 마이그레이션한 후, EA는 MySQL 클러스터로 구성되었던 이전 데이터베이스에 비해 90%의 비용 절감 효과를 실현합니다. EA는 DynamoDB를 사용하여 여러 테이블에 게임 상태, 사용자 데이터 및 게임 인벤토리를 저장합니다. EA는 사용자 ID를 파티션 키 및 기본 키로 사용합니다(1:1 모델링 패턴).

MMORPG 게임Battle Camp의 제작사인 PennyPop은 DynamoDB를 사용하여 출시 당시 분당 요청 수가 수 회에 불과했던 Battle Camp를 80,000회 이상의 초당 요청 수준으로 확대했습니다. DynamoDB는 완전 관리형 서비스이므로 PennyPop의 소규모 개발 팀은 운영에 신경을 쓰지 않고 게임 개발에 집중할 수 있었습니다. 또한, PennyPop은 DynamoDB을 사용함으로써 MySQL 데이터베이스를 호스팅 및 샤딩할 때와 비교하여 연간 50% 이상의 절감 효과를 얻었습니다. 같은 환경을 온프레이스로 운영할 경우 PennyPop은 운영팀을 기존의 서버 엔지니어 3명의 운영팀을 그 두 배인 6명으로 늘려야 했을 것입니다.

설계 패턴: DynamoDB에 데이터를 저장하기 위해 게임업체들은 플레이어 ID를 사용하여 게임 상태 및 기타 플레이어 데이터를 파티셔닝하고 키-값 액세스 패턴을 사용합니다(1:1 모델링). 보다 세밀한 액세스가 요구되는 경우, 이러하 회사들은 정렬 키를 사용합니다(1:M 모델링). 이렇게 하면 플레이어 데이터 세트의 서로 다른 속성 또는 하위 세트를 개별적으로 액세스 및 업데이트할 수 있습니다. 이 방식을 사용하면 전체 데이터 세트를 검색하지 않아도 됩니다. 이 접근 방식에서는 서로 다른 속성을 저장하는 여러 항목을 DynamoDB 트랜잭션 API를 사용한 트랜잭션 방식으로 업데이트할 수 있습니다. 일부 업체는 비용 절감을 위해 사용자 데이터를 압축합니다. 예를 들어, PennyPop은 gzip을 사용하여 플레이어 데이터를 압축하고 base64 문자열로 저장하여 플레이어 데이터를 원래 크기의 10%로 축소합니다.

사례 2. 레이어 세션 기록 데이터 스토어

게임 제작자들은 세션 기록 및 기타 시간 중심의 데이터를 DynamoDB에 저장하여 플레이어, 날짜 및 시간 기준의 빠른 검색을 지원합니다. 예를 들어, 메일 테라바이트 급의 데이터를 생성하는 전 세계 플레이어들을 지원하는 Riot Games는 플레이어 세션 기록을 DynamoDB에 저장합니다. 이렇게 하면 Riot Games의 플레이어 지원 팀이 플레이어의 모든 인게임 구매 및 마지막 로그인 시간 등 특정 플레이어에 대한 모든 정보를 빠르게 검색할 수 있습니다. 이전에는 이 데이터를 Vertica에 저장했었습니다. Vertica는 분석에는 유용하지만 단일 키 검색에는 적합하지 않습니다. 검색에 수 분이 소요되는 경우도 종종 있었습니다. 검색 성능 개선을 위해 Riot Games는 DynamoDB를 사용하기로 결정하고 모든 데이터를 Vertica에서 DynamoDB로 복사하고 모든 사용자 데이터 및 기록에 대한 구체화된 뷰를 DynamoDB에 생성하여 빠른 검색을 제공했습니다. DynamoDB의 사용을 통해 검색 시간은 수 분에서 1초 미만으로 단축되었습니다.

설계 패턴: 플레이어 세션 기록 및 기타 시간 중심의 데이터를 DynamoDB에 저장하기 위해 게임업체들은 일반적으로 플레이어 ID를 파티션 키로 사용하고 마지막 로그인과 같은 날짜 및 시간을 정렬 키로 사용합니다(1:M 모델링). 이러한 회사들은 이 스키마를 통해 플레이어 ID와 날짜 및 시간을 사용함으로써 각 플레이어의 데이터에 효율적으로 액세스할 수 있습니다. 쿼리는 특정 날짜 및 시간에 대한 단일 레코드를 선택하거나 주어진 날짜 및 시간 범위에 대한 레코드 세트를 선택하도록 쉽게 맞춤화될 수 있습니다.

사례3. 리더보드

게임 제작업체들은 DynamoDB를 사용하여 손쉽게 간단한 리더보드를 지원할 수 있습니다. 이러한 사용 사례 중 하나로 게임의 최고 점수를 표시하는 기능을 들 수 있습니다. 게임업체가 이미 플레이어의 최고 점수를 비롯한 플레이어의 게임 상태를 DynamoDB에 저장하고 있는 경우, 글로벌 보조 인덱스를 사용하여 최고 점수를 가져오는 기능을 구현할 수 있습니다.

설계 패턴: 플레이어 ID를 기준으로 파티셔닝된 테이블에 최고 점수를 하나의 속성으로 저장하는 등 플레이어의 게임 상태를 저장하는 경우, 글로벌 보조 인덱스로 리더보드를 구현할 수 있습니다. 인덱스는 게임 ID 또는 이름을 파티션 키로 사용하고 최고 점수 속성을 정렬 키로 사용할 것입니다(N:M 모델링). 이 방식은 DynamoDB 개발자 안내서의 글로벌 보조 인덱스 섹션에 설명되어 있습니다.

요약

이 게시물에서는 게임 업체들의 가장 일반적인 사용 사례 및 설계 패턴 중 일부를 설명해 드렸습니다. 강력한 최종 일관성을 위한 옵션, 다중 항목 ACID 트랜잭션 지원, 원자성 카운터 및 DAX(DynamoDB Accelerator)를 통한 인 메모리 캐싱 기능을 갖춘 DynamoDB는 게임 애플리케이션에서 일반적으로 발생하는 다양한 요구 사항을 충족할 수 있습니다.

AWS 기반의 게임 설계 패턴과 관련한 보다 심층적인 정보는Introduction to Scalable Gaming Patterns on AWS를 살펴 보시거나, AWS 기반의 게임 개발과 관련한 추가 리소스는 Amazon Game Tech를 참고하시기 바랍니다.

(역자 주: 국내 게임 업체들의 최근 활용 사례는 AWS Summit Seoul 게임 트랙 발표 영상을 보시길 권장드립니다. )

Edin 사진Edin Zulich는 AWS의 선임 NoSQL 전문가 솔루션스 아키텍트로서, 다양한 산업에 종사하는 고객이 확장 가능하고 비용 효과적인 솔루션을 설계하여 까다로운 데이터 관리 문제를 해결하도록 지원합니다. Edin은 2005년부터 분산 데이터 기술 관련 작업을 수행해 왔으며 2016년에 AWS에 합류했습니다.

이 블로그 게시물은 새롭게 선보이는 산업 버티컬 게시물 시리즈의 첫 번째 게시물입니다. 두 번째 게시물의 주제는 Amazon DynamoDB: 애드테크 사용 사례 및 설계 패턴입니다.