DynamoDB 핫 파티션, GSI 분리로 해결!

DynamoDB Streams는 테이블 변경 이벤트를 Kinesis Data Stream으로 전송하여 실시간 데이터 복제 및 처리를 가능하게 합니다. 본문에서는 User 테이블의 변경 사항을 NEW_AND_OLD_IMAGES 모드로 캡처하여 이전 및 이후 상태를 모두 기록하고, 이를 Kinesis Data Stream에 저장합니다. 이후 ch-flow-shard 애플리케이션은 Kinesis Stream에서 이벤트를 읽어 user_managed_index 테이블에 반영합니다. 이 과정에서 GSI의 키 변경, 삭제, 늦게 도착한 이벤트 처리 로직을 ch-flow-shard 내에서 직접 구현하여 DynamoDB 내부 GSI 동작을 모방합니다. 특히, 데이터 미저장 정책(Zero-Retention Policy)은 직접적으로 언급되지 않았으나, 변경 전후 이미지를 모두 활용하여 데이터의 완전성을 보장하려는 시도가 엿보입니다.

약 22억 건의 기존 데이터를 새 인덱스 테이블로 이전하기 위해 DynamoDB Export, AWS Glue ETL, DynamoDB Import 파이프라인을 사용했습니다. DynamoDB Export는 PITR(Point-in-Time Recovery) 스냅샷을 S3로 내보내고, AWS Glue ETL은 이 데이터를 읽어 인덱스 테이블 스키마에 맞게 변환합니다. 여기서 핵심은 DynamoDB 테이블의 PK/SK 유니크 제약 조건을 만족시키기 위해 기존 GSI의 `managedKey`와 원본 User의 `userId`를 조합하여 새 SK(`managedKey#userId`)를 설계한 것입니다. 이 과정에서 데이터 격리 아키텍처(Data Isolation Architecture)를 적용하여 기존 User 테이블과 별도로 인덱스 테이블을 관리하게 됩니다.

핫 파티션 문제 해결을 위해 ch-rate-limiter 마이크로서비스를 활용하여 쓰기 속도를 제어했습니다. 초기 Token Bucket 설정의 버스트(Burst) 이슈로 인해 capacity를 낮추자 SQS 메시지 적체가 발생했습니다. 이를 해결하기 위해 5차 배포에서 Leaky Bucket 알고리즘을 도입하여 DynamoDB가 처리 가능한 속도로 꾸준히 트래픽을 흘려보내는 방식을 채택했습니다. 이 과정에서 SQS Consumer의 재시도 로직 변경 및 핫 파티션 마킹 시간 단축 등 여러 최적화가 병행되었습니다. 최종적으로 WriteThrottleEvents를 0회로 줄이는 성과를 달성했습니다.

별도로 분리된 인덱스 테이블이 기존 GSI와 동일한 조회 결과를 내도록 하기 위해, ch-flow-shard 애플리케이션에서 GSI의 내부 동작을 재현해야 했습니다. 여기에는 GSI Item 생성 조건(PK, SK 조합), Key 변경 시 이전 아이템 삭제 및 새 아이템 생성, 삭제 이벤트 처리, 그리고 늦게 도착한 이벤트로 인한 데이터 불일치 방지를 위한 버전 관리(Version Management) 로직이 포함됩니다. 특히, 삭제 이벤트 처리 시에는 하드 삭제(Hard Delete) 대신 조건부 쓰기 및 TTL 적용을 통해 데이터 정합성을 유지했습니다.

인덱스 전파 파이프라인 운영 중 Kinesis Iterator Age, 인덱스 전파 처리 시간, Rate Limiter 429 응답, SQS depth, DLQ 유입량 등 다양한 지표를 Mimir 커스텀 메트릭으로 수집하고 모니터링했습니다. 이를 통해 P95 500ms, P99 950ms 수준의 인덱스 전파 지연 시간(Index Propagation Latency)을 달성했으며, 핫 파티션 문제 해결 후에는 managed GSI의 WriteThrottleEvents가 약 110만 회에서 0회로 감소하는 정량적인 성과를 확인했습니다.