DynamoDB 핫 파티션을 해결하는 3가지 방법 (1): 인덱스 테이블로 GSI 떼어내기 설계편
4
AI 요약

이 글은 AI가 원문을 분석하여 핵심 내용을 요약한 것입니다.

이 게시물은 DynamoDB managed GSI의 쓰기 쏠림으로 Back-Pressure가 발생해 메인 테이블 쓰기와 Boot 요청까지 연쇄 거부되는 장애 구조를 분석합니다. managed GSI는 SK(lastSeenAt) 변경 시 기존 아이템을 삭제 후 재기록하고, 특정 channelId의 쓰기가 한 파티션으로 집중되면서 핫 파티션을 만들며, 이 상태에서 GSI가 먼저 쓰기 한도에 도달하면 메인 테이블 쓰기까지 막히는 동작을 설명합니다. 해결책으로 managed GSI를 없애고 DynamoDB Streams(Kinesis) 기반의 별도 인덱스 테이블(user_managed_index)을 만들어 비즈니스 로직 변경 없이 쓰기 전파를 파이프라인으로 분리합니다. 파이프라인은 인덱스 테이블 쓰기 전 Redis Rate Limiter(ch-rate-limiter)로 해당 파티션의 핫 여부를 검사하고, 핫 파티션이면 SQS 버퍼에 격리해 천천히 재처리하여 Back-Pressure 전파를 차단합니다. 기존 데이터는 DDB Export + Glue로 스냅샷을 변환해 DDB Import로 적재한 뒤, Export 시점 이후 변경분은 스트림 재생(Kinesis Catch-Up)으로 맞춰 무중단 마이그레이션을 구성합니다. 정합성은 일정 주기로 GSI와 인덱스 테이블 간 샘플링 비교로 점검하며, 조회 전환 전 안전 장치로 활용합니다.

연관 게시글