#Backend

메시지 전송 트래픽 100배에도 끄떡 없는 User 테이블로 뜯어고치기 (2)

Summary

16억 레코드 마이그레이션을 7일에서 6시간으로 단축시킨 비결

AWS Glue와 DynamoDB Import로 완성한 무중단 대규모 데이터 분리 전략

본 아티클은 채널톡의 1.8TB 규모 User 테이블에서 Badge 기능을 분리하며 겪은 기술적 여정을 담고 있습니다. 단순히 데이터를 옮기는 것을 넘어 AWS 관리형 서비스를 활용해 비용과 성능, 안정성을 모두 잡은 실전 마이그레이션 아키텍처와 상세한 튜닝 포인트를 공유합니다.

01DynamoDB Export/Import를 활용해 프로덕션 RCU/WCU 소모 없이 데이터 이전
02AWS Glue(PySpark)를 이용한 대규모 JSON 데이터 필터링 및 변환 기법
03LWW(Last Writer Wins) 전략을 통한 온라인 마이그레이션 중 데이터 정합성 보장
04Worker 수 최적화와 CloudWatch 메트릭을 활용한 Glue Job 성능 튜닝
05트랜잭션 충돌 및 GSI Back-Pressure 해결을 통한 시스템 안정성 확보

RECOMMENDATION

수억 건 이상의 대규모 테이블 마이그레이션을 준비하는 백엔드 엔지니어에게 추천하며, 특히 읽기 패턴뿐만 아니라 쓰기 패턴에 기반한 테이블 설계의 중요성을 시사합니다.

The Problem

16억 8천만 개의 레코드를 보유한 거대 User 테이블에서 Badge 업데이트 트래픽이 전체 성능을 저하시키는 문제를 해결하기 위해, 서비스 중단 없이 데이터를 분리하는 온라인 마이그레이션이 필요했습니다. 기존 Java 애플리케이션 기반 마이그레이션 방식은 예상 소요 시간이 7일에 달하고 프로덕션 DB에 RCU/WCU 부하를 직접적으로 주는 위험이 있었습니다.

The Solution

DynamoDB PITR을 활용한 Export로 프로덕션 부하를 제거하고, AWS Glue ETL을 통해 데이터를 변환한 뒤 DynamoDB Import 기능을 사용하여 새 테이블을 생성하는 파이프라인을 구축했습니다. 데이터 정합성을 위해 Last Writer Wins(LWW) 전략과 ConditionExpression을 적용한 Dual Write 및 TmpUserBadge를 활용한 3단계 병합 프로세스를 수행했습니다.

The Result

마이그레이션 시간을 7일에서 6시간으로 약 96% 단축했으며, 비용 또한 기존 방식 대비 약 36% 절감하는 성과를 거두었습니다. 기술적으로는 User 테이블과 Badge 업데이트 트래픽을 완전히 격리하여 트랜잭션 충돌을 분당 10,000건에서 80건 수준으로 급감시켰으며 GSI Back-Pressure 문제를 근본적으로 해결했습니다.

Trade-off

AWS Glue ETL 과정에서 Spark의 NULL 처리 방식과 DynamoDB의 데이터 모델 차이로 인해 별도의 커스텀 스크립트 작성이 필요했으며, PK+SK 구조의 테이블일 경우 데이터 정렬 순서에 따른 Rolling Hot Partition 이슈가 발생할 수 있음을 확인했습니다.