#Backend

메시지 트래픽 100배에도 끄떡 없게 고객 테이블 뜯어고치기 (1)

Summary

1.8TB 데이터의 대수술, 16억 개 고객 테이블에서 '뱃지'를 도려낸 이유

DynamoDB 쓰로틀링과 GSI 백프레셔를 잡기 위한 채널톡의 대규모 아키텍처 현대화 전략

폭발적인 메시지 트래픽 속에서 시스템 안정성을 확보하기 위해 거대해진 User 테이블을 분리한 엔지니어링 기록입니다. 단순한 기능 분리를 넘어, DynamoDB의 내부 동작 원리와 핫 파티션 문제를 해결하며 16억 건의 데이터를 안전하게 옮기기 위한 고군분투를 담고 있습니다.

011.68B 레코드 규모의 DynamoDB 테이블 운영 중 발생한 성능 병목 분석
02GSI 핫 파티션이 메인 테이블 쓰기까지 막는 백프레셔 현상의 실체 확인
03아이템 분리 대신 테이블 분리를 선택한 4가지 기술적/비용적 근거
047일이 소요되는 수동 마이그레이션 대신 AWS Glue를 선택한 배경
05데이터 유실을 방지하는 동기식 Dual-Write 및 임시 버퍼 테이블 전략

RECOMMENDATION

DynamoDB를 사용하며 급격한 트래픽 스파이크로 인한 쓰로틀링을 겪고 있거나, 대규모 NoSQL 데이터 마이그레이션을 고민하는 백엔드 엔지니어에게 적극 추천합니다.

The Problem

16억 8천만 건의 레코드를 보유한 DynamoDB User 테이블에서 스파이크성 뱃지 업데이트 트래픽(1500 TPS 이상)이 발생하여 서비스 핵심 기능인 '부트'가 마비되는 현상이 발생했습니다. 원인은 업데이트 시 아이템 전체 크기 기준의 WCU 소모와 GSI 핫 파티션으로 인한 백프레셔(Back-Pressure)로 분석되었습니다.

The Solution

성격과 쓰기 패턴이 다른 뱃지 데이터를 별도의 UserBadge 테이블로 물리적으로 분리하는 결정을 내렸습니다. 대규모 데이터를 안전하게 이전하기 위해 Java 스크립트 기반 방식 대신 RCU/WCU 소모가 없는 DynamoDB Export/Import와 AWS Glue를 조합한 무중단 마이그레이션 파이프라인을 설계했습니다.