주식회사 SEGA, 소규모 팀으로 「Sonic Rumble Party」 글로벌 출시를 위한 Amazon DynamoDB 및 Amazon ElastiCache Serverless for Valkey 활용 사례

이 글은 2026년 8월 19일 AWS Japan 블로그에 게재된 ‘株式会社セガ、グローバル展開タイトル『ソニックランブル パーティ』を少人数チームで支える Amazon DynamoDB / Amazon ElastiCache Serverless for Valkey 活用事例’를 번역한 글입니다.

서론

주식회사 SEGA는 가정용 게임기, PC, 스마트폰용 게임의 기획, 개발, 판매, 운영을 중심으로, 다양한 콘텐츠와 상품을 전 세계에 제공하고 있습니다. SEGA는 비교적 새로운 기술도 적극적으로 도입하는 문화를 바탕으로, 여러 게임에 AWS를 활용해 왔습니다.

이 글에서는 SEGA가 개발/운영하는 『Sonic Rumble Party』 백엔드에 Amazon DynamoDB와 Amazon ElastiCache Serverless for Valkey를 도입하게 된 배경, 기술적 개선사항, 이를 통해 얻은 효과를 개발팀의 의견과 함께 소개합니다.

※본 이미지는 주식회사 SEGA의 허가를 받아 게재했습니다.

『Sonic Rumble Party』는 닥터 에그맨이 만들어 낸 장난감 세계를 배경으로, 「소닉」 시리즈의 인기 캐릭터들이 스릴 넘치는 장애물 코스와 경기 아레나에서 경쟁하는 멀티플레이 파티 게임입니다. 스마트폰과 PC간 크로스 플레이를 지원하며, 2024년 초 일부 지역에서 소프트 론칭을 진행한 뒤, 2025년 11월에 글로벌 론칭을 맞이했습니다.

해결하고자 했던 과제

글로벌하게 서비스되는 Games as a Service(GaaS) 백엔드를 소수 인원의 팀으로 개발하고 운영할 수 있도록 하는 것이 이 타이틀의 핵심 전제였습니다. 따라서 데이터베이스 선정에서도 이것이 최우선 요건이었습니다. 관리형 서비스를 최대한 활용하여 인프라 운영 부담을 가능한 줄인다는 방침 아래, 데이터베이스에는 다음과 같은 요구사항이 있었습니다.

• 글로벌 규모로 원활하게 확장이 가능할것: 수요를 예측하기 어려운 글로벌 서비스 확장에서는 트래픽 증가에 안정적으로 대응할 수 있어야 했습니다. Amazon Aurora에서는 API 서버를 늘릴수록 각 서버가 유지하는 커넥션 풀만큼 DB연결 수(커넥션 풀) 상한이 API서버 확장의 제약이 되기 쉬운 구조였습니다.
• 리소스 사이징 및 관리로부터의 해방: 스토리지 용량과 CPU 성능의 사이징, 사용자 분할(샤딩)에 따른 여러 클러스터를 운영하는 것처럼 리소스를 직접 계속 관리하는 작업 자체를 없애고, 용량 걱정 없이 개발에 집중하고자 하는 요구가 있었습니다.
• 데이터 양이 증가해도 안정적인 레이턴시: 수천만 명 규모의 데이터를 보유하더라도 응답 성능(레이턴시)이 변하지 않아야 했습니다.
• 가동량의 변동과 스파이크에 대한 대응: 출시 시점의 트래픽을 예측하기 어려웠으며, “초기에는 크게 구성하고 나중에 축소할 수 있도록 해두고 싶다”는 게임 업계 특유의 요건에 유연하게 대응할 수 있는 것이 중요했습니다.

DynamoDB / ElastiCache Serverless for Valkey를 선택한 이유

DynamoDB 채택의 결정적 요인

여러 데이터베이스 및 클라우드 서비스를 비교 검토한 결과, DynamoDB를 채택했습니다. 앞서 언급한 과제를 바탕으로, 다음과 같은 사항들이 결정적인 요인이 되었습니다.

• 서버리스 방식으로 운영되며 사실상 무제한의 확장성을 갖춘다는 점
• 유지 관리 기간이나 버전 관리를 신경 쓰지 않고 지속적으로 운영할 수 있다는 점
• 연결 수(커넥션 풀), 스토리지, CPU와 같은 리소스 관리에서 벗어날 수 있다는 점

ElastiCache Serverless for Valkey 채택의 결정적 요인

메인 데이터베이스인 DynamoDB에 대한 읽기 부하를 줄이고, 레이턴시와 비용을 최적화하기 위해, 인메모리 캐시/데이터 스토어로 ElastiCache를 채택했습니다. ElastiCache는 처음에 Redis OSS 엔진의 노드 기반 구성으로 구축을 시작했으며, 이후 Redis OSS 호환 Valkey 엔진을 사용하는 Serverless 구성으로 이전했습니다. Serverless를 선택한 결정적 요인은 다음과 같습니다.

• 노드 기반 클러스터 모드에서 필요했던 샤드 및 클러스터의 구성/관리로부터 벗어날 수 있어, 소규모 팀에서도 운영할 수 있다는 점
• “서비스 시작 시점에는 큰 규모로 구성하고, 출시 후에는 규모에 맞춰 축소/최적화해 나간다”는 게임 특유의 수요 변동에 용량이 자동으로 대응하므로, 과도한 리소스를 보유하지 않아도 된다는 점
• 이중화 구성을 스스로 설계/관리하지 않아도 고가용성이 기본으로 갖추어져 있다는 점

아키텍처 개요

주요 구성 요소와 역할은 다음과 같습니다.

• Amazon DynamoDB(메인 데이터베이스): 주요 게임 데이터를 저장하는 영구 데이터 스토어 입니다. 사용자 데이터(프로필, 보유 아이템, 진행 상황 등)와 로그 데이터(행동 로그)를 기본적으로 단일 테이블 설계로 관리하고 있습니다.
• Amazon ElastiCache Serverless for Valkey(캐시/리더보드): 사용자 데이터의 캐시, 매치메이킹 처리용 작업 데이터, 리더보드(Sorted Set) 등에 사용합니다. 용도별로 범용 Common과 리더보드 전용 Ranking의 두 구성으로 나누었습니다.
• Amazon ECS on EC2(API 서버): API, 매치메이킹, 행동 로그 집계 및 가공의 각 애플리케이션을 배치하고 있습니다.
• Amazon EKS Auto Mode + Agones: 전용 게임 서버를 관리합니다. 자세한 내용은 별도 글인 「주식회사 SEGA, 글로벌 출시 『Sonic Rumble Party』를 소수 인원 팀으로 지원하는 Amazon EKS Auto Mode × Agones 활용 사례」에서 소개하고 있습니다.

기술적 고려사항

1. 단일 테이블 설계와 키 설계

팀은 지금까지 관계형 데이터베이스(RDB)인 Aurora를 중심으로 사용해 왔으며, DynamoDB에 대한 지식은 거의 없는 상태에서 시작했습니다. DynamoDB는 RDB처럼 join이나 임의 조건을 활용한 유연한 쿼리를 수행 할 수 없습니다. RDB에서도 인덱스를 설계 하지만, DynamoDB에서는 예상되는 액세스 패턴에 맞춰 키와 GSI(Global Secondary Index), 데이터의 비정규를 사전에 설계할 필요가 있으며, 액세스 패턴이 데이터 모델 그 자체를 의미합니다. 본 타이틀은 사용자 데이터, 계정, 친구, 길드(크루), 랭킹 등 엔티티가 많았고, 각 엔티티에는 여러 검색 기준(사용자 ID, 계정 ID, 친구 코드 등)이 필요했습니다.

이에 따라 모든 엔티티를 하나의 테이블에 집약하는 단일 테이블 설계를 채택했습니다. 각 아이템의 키에 “엔티티 이름” 접두사를 붙여 네임스페이스를 분리하고, 검색 기준은 범용 GSI를 엔티티 전반에서 재사용하는 방식으로 설계했습니다.

예를 들어 계정 데이터의 키 설계는 다음과 같습니다.

※「구체적 예」는 실제 값의 예시 이미지입니다.

조회 시에는 동일한 GSI에 엔티티 이름이 포함된 키만 지정하면 됩니다. 예를 들어 GSI1은 계정 검색과 길드(크루)검색에 동일한 하나의 인덱스를 재사용합니다.

예 1: 계정 ID 5555의 계정을 조회

Query(index = Gsi1, P1 = "AccountDataEntity#A5555")

예 2: 동일한 GSI1에서, 이번에는 길드(크루) “Dragons”를 조회

Query(index = Gsi1, P1 = "CrewEntity#Dragons")

이처럼 소수의 범용 GSI를 여러 엔티티에서 재사용함으로써 인덱스의 수를 줄이면서도 다양한 검색 기준에 대응할 수 있습니다. RDB 중심이었던 팀도 예상보다 원활하게 이전을 진행했습니다. 한편, GSI를 능숙하게 사용할 수 있게 되기까지는 몇 개월이 걸렸으며, 부하 테스트 과정에서 GSI의 용량 부족을 알아채기 어렵다는 문제도 있었습니다.

2. 트랜잭션을 사용하지 않는 낙관적 잠금 중심 설계

비용과 성능을 고려하여 트랜잭션은 채택하지 않고, 낙관적 잠금 중심의 설계로 구성했습니다. 구현에는 AWS SDK의 객체 영속성 모델이 제공하는 버전 속성에 의한 낙관적 잠금을 사용했습니다. 또한 필요한 경우 SkipVersionCheck(버전 체크 비활성화)를 구분해서 사용할 수 있도록 데이터 접근 계층을 설계했습니다.

한편, 길드(크루) 기능처럼 여러 사용자가 동일한 데이터를 동시에 업데이트하는 기능에서는 정합성 보장이 중요합니다. 따라서 이러한 부분에서는 Valkey를 통한 잠금을 사용하여 경합을 방지하고 있습니다.

3. 리더보드의 핫 키 대응

랭킹은 ElastiCache(Sorted Set)에서 실시간으로 집계, 제공하는 한편, 점수는 사용자 데이터로 DynamoDB에도 영구 저장하고 있습니다. 이 DynamoDB 측의 랭킹용 GSI에서는 동일한 랭킹(단일 파티션 키)에 다수 플레이어의 쓰기 작업이 집중되어, 특정 파티션이 핫 파티션이 되기 쉬운 문제가 있었습니다.

이에 따라 랭킹용 GSI의 파티션 키에 사용자 ID의 마지막 4자리로 샤드를 분할 하는 방식(P1 = …#Shard{사용자ID 마지막4자리})을 도입해, 쓰기 작업을 여러 파티션으로 분산했습니다. 전체 랭킹을 조회할 때는 집계 태스크가 각 샤드를 통합하는 구성입니다.

한편, 캐시 측 ElastiCache Serverless에도 같은 종류의 고려가 필요했습니다. ElastiCache Serverless는 항상 클러스터 모드로 동작하기 때문에, 동일 슬롯 제약을 고려해 멀티 키 작업에서는 관련 키를 동일 해시 슬롯에 배치하는, 즉 해시 태그를 사용하는 키 설계가 필요합니다. 그만큼 특정 키에 부하가 쏠려 핫 슬롯이 될 위험도 있으므로, 이러한 트레이드오프를 고려해야합니다. 본 게임 사례를 통해서도 설계 초기에 이 점을 염두에 둘 필요가 있다는 인사이트를 얻었습니다.

4. 글로벌 출시의 급격한 트래픽에 대한 대책

2025년 11월의 글로벌 출시는 트래픽을 예측하기 어려운 가장 큰 고비였습니다. 사전 워밍업을 위해 다음과 같이 대응했습니다.

• DynamoDB: Warm Throughput을 사용해 관리 콘솔에서 필요한 처리량을 높이는 것만으로 워밍업을 완료했습니다. 수동으로 프로비저닝된 처리량을 조정한 뒤, 상향 조정 후 온디맨드 모드로 되돌리는 방식과 비교해 운영 수고를 크게 줄일 수 있었습니다.
• ElastiCache Serverless: 출시 전에 최소 ECPU를 설정하는 것만으로 사전 워밍업을 수행할 수 있었습니다. 출시 후에는 일반 운영으로 되돌리기만 하면 되었고, 용량 조정에 드는 수고를 최소화할 수 있었습니다.

결과적으로 예측하기 어려운 급격한 트래픽 스파이크에도 문제없이 대응할 수 있었습니다.

AWS의 기술 지원

이 게임의 설계와 구현 과정에서는 AWS의 기술 지원 프로그램인 DynamoDB Immersion Day와 DynamoDB DCAD(Database Clinic in A Day)를 통해, 며칠에 걸쳐 DynamoDB 학습 세션과 핸즈온을 진행했습니다. 이와 함께 Solutions Architect의 설계 상담, 아키텍처 리뷰, 키 설계 리뷰도 진행했습니다.

특히 다음과 같은 부분에서 큰 효과를 얻었습니다.

• 사내의 여러 부서가 학습 세션에 참가하면서 「단일 테이블 설계」를 여러 관점에서 비교, 논의할 수 있어 설계의 방향성을 검증할 수 있었습니다.
• 「TTL은 설정 시각에 반드시 삭제되는 것은 아니다」와 같은 실제 운영상의 유의사항을 사전에 파악하여, 잘못된 설계나 운영 방식으로 서비스 시작하는 일을 피할 수 있었습니다.
• 실제 운영에서 스케일링이 이루어지는 방식을 들음으로써, 운영 방식에 대한 구체적인 이미지를 가질 수 있었습니다.

개발/운영 측면에서 얻은 효과

개발/운영 부담 경감 및 소규모 운영 실현

현재 데이터베이스를 포함한 백엔드를 사실상 1명이 개발, 운영, 유지 보수할 수 있게 되었습니다. 용량 설계가 필요하지 않기 때문에, 소수 인원이라도 애플리케이션 개발에 집중할 수 있습니다.

또한 파티셔닝과 샤딩을 투명하게 처리되므로, 개발 환경과 운영 환경의 구성을 변경하지 않고 운영할 수 있다는(dev/prod parity) 점도 큰 장점이었습니다. 과거 프로젝트에서 Aurora를 사용했을 때는 쓰기 부하를 하나의 클러스터만으로 감당할 수 없어, 사용자 단위로 여러 클러스터에 샤딩을 했습니다. 어느 클러스터에 액세스할지는 애플리케이션 측의 분배(디스패치) 처리로 제어했습니다. 그러나 개발 환경에서는 비용 문제로 운영 환경과 동일한 클러스터 구성을 재현할 수 없었기 때문에, 이 분배 로직을 개발 환경과 운영 환경에 맞게 각각 구현해야 했습니다. 반면 DynamoDB의 파티셔닝과 ElastiCache의 샤딩은 투명하게 수행되며, 용량이나 샤드 수 관리도 불필요합니다. 따라서 애플리케이션은 클러스터 분배나 분할을 전혀 의식할 필요가 없으며, 동일한 코드, 동일한 테이블 설계, 동일한 캐시 구성이 개발 환경부터 운영 환경까지 그대로 동작합니다. 서버리스 환경이므로 개발 환경을 비용 때문에 축소할 필요도 없고, 운영 환경과의 구성 차이가 발생하지 않으므로 개발 환경에서 검증한 내용이 운영 환경에서도 그대로 적용되는 상태를 구현할 수 있었습니다.

DynamoDB로 이전한 뒤에는 알림이 발생할 때를 제외하면 모니터링 화면을 거의 확인할 필요가 없어졌고, 데이터베이스 관련 일상적인 운영 업무도 거의 없어졌습니다. Aurora 사용 시 신경 썼던 대규모 테이블의 파티션 운영, 데이터 증가에 따른 성능 저하 대응, API 서버 확장 시의 연결 수(커넥션 풀)와 같은 문제에서도 벗어날 수 있었습니다.

성능 측면의 효과

DynamoDB의 레이턴시는 모든 DynamoDB API의 평균에서 10밀리초 이하(CloudWatch의 DynamoDB 레이턴시 기준)로 안정적으로 유지되고 있습니다. 데이터 양이 증가해도 응답 성능이 변하지 않기 때문에, 일관되게 낮은 레이턴시를 유지할 수 있습니다. 복잡한 쿼리를 작성하지 않는, 다시 말해 작성할 필요가 없는 설계라는 점도 쿼리 부하가 커지기 어려운 요인 중 하나입니다.

ElastiCache for Valkey는 기존에 사용하던 Redis와 비교해도 손색없는 성능을 유지하고 있습니다. 자주 조회되는 사용자 데이터와 랭킹을 ElastiCache에서 캐싱함으로써, 낮은 레이턴시로 응답하면서도 DynamoDB에 대한 읽기 요청도 줄일 수 있습니다. 활성 사용자나 상위 사용자일수록 조회 빈도가 높기 때문에, 제한된 캐시 용량으로도 높은 캐시 적중률을 얻을 수 있어, 효율적으로 읽기 부하를 줄이고 있습니다.

비용 측면의 효과

가장 크게 체감한 효과는 운영과 관리까지 포함한 전체 비용 측면의 이점입니다. DynamoDB는 클러스터를 분할한 Aurora구성의 추정치와 비교하여, 개발, 스테이징, QA 환경을 합쳐 95%, 운영 환경에서 40~50%의 비용을 절감했습니다. 인프라의 사용료뿐 아니라 기존 데이터베이스 운영, 관리에 투입하던 비용까지 포함해 부담이 크게 줄었습니다.

ElastiCache Serverless는 개발 환경에서 노드 구성과 비교하여 훨씬 낮은 비용으로 운영할 수 있습니다. 운영 환경에서도 트래픽 스파이크에 대비한 과도한 프로비저닝이나 예약 노드의 사전 구매가 필요 없어졌으며, 부하를 예측하기 어려운 상황에서 용량을 미리 추산해 확보할 필요도 없어졌습니다.

가용성 및 내결함성

최초 출시 이후 중단 없이 안정적으로 운영되고 있으며, 서비스에 영향을 미칠 만한 장애는 발생하지 않았습니다.

마치며

「Sonic Rumble Party」에서 얻은 이러한 성과를 바탕으로, DynamoDB와 Valkey는 앞으로 부서의 표준 아키텍처로서 후속 게임에서도 채택할 예정입니다. ElastiCache for Valkey를 Serverless와 노드 기반 중 어느 것으로 구성할지는 예약 노드의 활용 가능 여부를 고려하여 각 프로젝트에서 선택할 수 있도록 하고 있습니다.