Amazon DynamoDB: 게임 서비스 사용 사례 및 설계 패턴
뿐만 아니라 DynamoDB는 완전 관리형 서비스이므로 운영 부담이 발생하지 않습니다. 게임 개발자는 데이터베이스 관리에 신경을 쓰지않고 게임 개발에 집중할 수 있습니다. 또한, 게임 제작자들은 단일 AWS 리전에서 여러 리전으로 규모를 확대할 때 DynamoDB 전역 테이블에 의존하여 다중 리전 활성-활성 데이터 복제를 구현할 수 있습니다.
이 게시물에서는 DynamoDB를 사용하는 게임 업체들의 가장 일반적인 사용 사례 및 설계 패턴 중 일부를 설명해 드리고자 합니다. 이 게시물에서는 다음과 같은 데이터 모델링 용어가 사용됩니다.
- 1:1 모델링: 파티션 키를 기본 키로 사용하는 일대일 관계 모델링입니다.
- 1:M 모델링: 파티션 키와 정렬 키를 기본 키로 사용하는 일대다 관계 모델링입니다.
- N:M 모델링: 파티션 키와 정렬 키를 기본 키로 사용하고 테이블 및 글로벌 보조 인덱스를 포함하는 다대다 관계 모델링입니다.
게임 사용 사례 및 설계 패턴
| 사용 사례 | 설계 패턴 |
| 게임 상태, 플레이어 데이터 스토어 | 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 게임 트랙 발표 영상을 보시길 권장드립니다. )
이 블로그 게시물은 새롭게 선보이는 산업 버티컬 게시물 시리즈의 첫 번째 게시물입니다. 두 번째 게시물의 주제는 Amazon DynamoDB: 애드테크 사용 사례 및 설계 패턴입니다.
Source: Amazon DynamoDB: 게임 서비스 사용 사례 및 설계 패턴
