#Backend

DynamoDB 핫 파티션을 해결하는 3가지 방법 (4): 쓰기 샤딩

Summary

20억 건 대용량 테이블의 트래픽 한계를 16배 확장한 채널톡의 DynamoDB 쓰기 샤딩 기술 개척기

물리 파티션 한계인 1,000 WCU의 벽을 깨고, 단 1회의 쿼리로 조회가 가능한 결정적 샤딩 프레임워크를 구축하다

본 아티클은 채널톡이 DynamoDB 인프라에서 급증하는 대규모 프로모션 트래픽(Boot 요청)을 안정적으로 수용하기 위해 '쓰기 샤딩(Write Sharding)' 기법을 도입한 생생한 여정을 담고 있습니다. 물리적 한계를 극복하기 위해 설계한 공통 샤딩 프레임워크부터, 20억 건의 데이터를 백필하는 도중에 발생한 예기치 못한 '롤링 핫 파티션' 쓰로틀링 에러를 셔플 기법으로 해결해 나간 구체적인 아키텍처적 도전과 솔루션을 전달합니다.

01단건 조회의 O(1) 성능을 완벽히 유지하기 위해 입력값(memberId)에 기반해 Suffix 위치를 재현하는 '결정적 샤딩(Deterministic Sharding)' 기법 적용
02저장, 조회, 마이그레이션 도구에 이르기까지 일관된 해시 연산 규칙을 준수하고 타입 안전성을 확보하기 위한 공통 인터페이스 및 프레임워크 자체 설계
03DynamoDB Export와 AWS Glue(Spark) 배치를 연동하여 운영망에 주는 부담을 최소화하며 20억 건의 레코드를 라이브 상태로 전수 백필 성공
04데이터 이관 과정에서 파티션별로 쓰기가 편향되어 이동하며 장애를 유발하는 '롤링 핫 파티션(Rolling Hot Partition)' 문제를 순서 셔플링을 통해 무력화
05특정 대형 고객사의 트래픽 폭증 시에도 병목 없이 초당 최대 16,000 WCU까지 유연하게 확장 가능하도록 구조 개선

RECOMMENDATION

NoSQL(DynamoDB 등) 환경에서 특정 키에 부하가 쏠리는 '핫 파티션' 현상으로 시스템 아키텍처 교체를 고민 중이거나, 대량의 데이터(수십억 건 단위)를 중단 없이 고성능으로 마이그레이션하려는 백엔드 및 DevOps 개발자들에게 실전 문제해결서로 적극 권장합니다.

The Problem

채널톡의 member GSI가 channelId를 파티션 키로 사용하면서 특정 채널에 대규모 부트(Boot) 트래픽이 집중될 때 DynamoDB의 물리 파티션당 처리 한계인 초당 1,000 WCU를 초과하여 쓰로틀링이 발생했습니다. 이 쓰로틀링이 백프레셔로 작용하여 메인 User 테이블의 쓰기 작업까지 거부시켰고, 결과적으로 서비스 무중단 운영에 심각한 장애 위협이 되었습니다.

The Solution

memberId를 Murmur3 해시 함수로 연산하여 16개의 Suffix(접미사) 중 하나를 도출하고, 이를 기존 channelId와 결합해 파티션 키를 분산하는 결정적 쓰기 샤딩(Deterministic Write Sharding) 기법을 도입했습니다. 이를 안정적으로 운영하기 위해 특정 데이터베이스에 의존하지 않는 공통 쓰기 샤딩 프레임워크를 직접 설계했으며, DynamoDB Export 및 AWS Glue를 활용해 약 20억 건의 기존 데이터를 무중단 상태에서 업데이트했습니다.

The Result

특정 고객사 채널에 집중되는 부트 트래픽 수용 한계를 초당 기존 약 1,000건에서 최대 16,000건으로 약 16배 대폭 늘려 안정성을 확보했습니다. 또한 저장과 조회의 키 계산 규칙을 완벽히 일치시킴으로써 단건 조회 시 분산된 16개 샤드 상태에서도 단 1회의 Query 요청으로 조회할 수 있게 만들었으며, 20억 건의 방대한 기존 데이터를 완벽하게 마이그레이션했습니다.

Trade-off

결정적 샤딩 기법을 통해 단건 조회의 오버헤드는 제거했으나, 만약 한 그룹 전체의 사용자 목록을 조회해야 하는 패턴(Scatter-Gather)이 생길 경우 분산된 16개의 샤드를 전체 스캔한 뒤 머지 및 재정렬해야 하므로 읽기 비용이 커집니다. 또한 백필 단계에서 물리적 정렬 순서대로 가해지는 대량 쓰기가 특정 파티션에 차례대로 부하를 주는 롤링 핫 파티션 현상을 초래하여 데이터의 처리 순서를 섞는 셔플 과정을 따로 구현해야 했습니다.