DynamoDB 핫 파티션, 이제 안녕! 인덱스 테이블 분리 설계로 서비스 안정성 확보

DynamoDB GSI(Global Secondary Index)의 핫 파티션(Hot Partition)으로 인해 Boot 요청 실패 및 서비스 장애 발생

인덱스 테이블 분리(Index Table Separation)를 통해 GSI 쓰기 병목을 해결하고, Back-Pressure 문제를 근본적으로 차단

DynamoDB Streams(Kinesis), ch-flow-shard, ch-rate-limiter를 활용한 자동 동기화 파이프라인 구축

키 샤딩(Key Sharding) 및 도메인 테이블 분리(Domain Table Separation) 방식의 단점과 인덱스 테이블 분리 방식의 장점 비교 분석

무중단 마이그레이션(Zero-downtime Migration)을 위해 DDB Export, Glue, DDB Import, Kinesis Catch-Up 활용

핫 파티션(Hot Partition) 문제의 근본 원인 분석

본문에서는 DynamoDB의 GSI(Global Secondary Index)에서 발생하는 핫 파티션(Hot Partition) 문제를 심층적으로 분석한다. 특히, managed GSI의 SK(Sort Key) 변경으로 인한 2배의 쓰기 비용 발생과 channelId 기반 PK(Partition Key)로 인해 특정 채널의 쓰기가 한 곳으로 집중되는 현상을 지적한다.

Back-Pressure(백 프레셔) 현상: GSI 파티션의 쓰기 한계 초과 시 메인 테이블 쓰기까지 거부되는 문제 발생

Boot 요청 실패: 핫 파티션으로 인해 Boot 요청이 실패하고, 이는 곧 채널톡 서비스 전체의 장애로 이어진다.

해결의 핵심: 핫 파티션 문제를 해결하기 위해 GSI를 없애고, 별도의 인덱스 테이블을 구축하는 방안 제시

인덱스 테이블 분리 아키텍처(Index Table Separation Architecture) 설계

저자는 핫 파티션 문제를 해결하기 위해 인덱스 테이블 분리(Index Table Separation) 아키텍처를 제안한다. 이는 기존 User 테이블의 변경 사항을 DynamoDB Streams(Kinesis)를 통해 감지하고, ch-flow-shard 마이크로서비스를 통해 별도의 user_managed_index 테이블에 비동기적으로 반영하는 방식이다.

DynamoDB Streams(Kinesis) 활용: User 테이블의 변경 이벤트를 캡처하여 인덱스 테이블에 전파

ch-flow-shard: Kinesis 이벤트를 user_managed_index 테이블에 반영하는 역할 수행

ch-rate-limiter: Redis 기반 Rate Limiter를 통해 핫 파티션 여부를 판단하고, 쓰기 부하를 제어

이러한 설계를 통해 메인 테이블 쓰기와 인덱스 테이블 쓰기를 분리하여 Back-Pressure(백 프레셔) 문제를 해결하고, 핫 파티션 발생 시에도 메인 테이블의 안정성을 확보한다.

키 샤딩(Key Sharding) 및 도메인 테이블 분리(Domain Table Separation) 방식 비교

글에서는 핫 파티션 문제를 해결하기 위한 다른 접근 방식인 키 샤딩(Key Sharding)과 도메인 테이블 분리(Domain Table Separation)의 장단점을 분석하고, 인덱스 테이블 분리 방식과의 비교를 통해 최적의 해결책을 제시한다.

키 샤딩(Key Sharding): GSI 파티션 키를 분산하여 쓰기 부하를 줄이는 방식, 스캐터-게더(Scatter-Gather)로 인한 조회 비용 증가

도메인 테이블 분리(Domain Table Separation): managed 대상 사용자를 별도 테이블로 분리, 쓰기 경로 관리의 어려움

인덱스 테이블 분리(Index Table Separation): 비즈니스 로직 변경 없이 GSI 쓰기 병목을 해결, 자동 동기화 파이프라인 구축

결론적으로, 인덱스 테이블 분리 방식은 기존 시스템에 미치는 영향이 적고, 핫 파티션 문제를 효과적으로 해결할 수 있는 현실적인 대안으로 평가받는다.

무중단 마이그레이션(Zero-downtime Migration) 전략

저자는 기존 데이터를 새로운 인덱스 테이블로 이전하기 위한 무중단 마이그레이션(Zero-downtime Migration) 전략을 상세히 설명한다. 이 전략은 DDB Export, Glue, DDB Import, Kinesis Catch-Up 단계를 포함하며, 임시 테이블과 Dual Write 없이 안전하게 데이터를 이전하는 것을 목표로 한다.

DDB Export + Glue ETL: User 테이블의 스냅샷을 S3로 내보내고, Glue ETL을 통해 데이터를 변환

DDB Import: 변환된 데이터를 user_managed_index 테이블에 적재

Kinesis Catch-Up: Export 시점 이후의 변경 사항을 Kinesis를 통해 인덱스 테이블에 반영

정합성 검사: 마이그레이션 과정에서 GSI와 인덱스 테이블 간의 데이터 정합성을 주기적으로 검사

이러한 과정을 통해 서비스 중단 없이 데이터를 이전하고, 새로운 인덱스 테이블을 안정적으로 운영할 수 있다.

채널톡 GSI 파이프라인의 기술적 세부 사항

글에서는 채널톡의 GSI 파이프라인을 구성하는 기술적 세부 사항을 심도 있게 다룬다. 특히, DynamoDB Streams(Kinesis)를 선택한 이유, ch-flow-shard 및 ch-rate-limiter의 역할, 그리고 파이프라인의 안정성을 확보하기 위한 다양한 기술적 고려 사항을 제시한다.

Kinesis 선택 이유: Native 모드의 한계, Enhanced Fan-Out 지원, 긴 이벤트 보관 기간

ch-flow-shard의 역할: Kinesis 이벤트를 user_managed_index 테이블에 안전하게 반영

ch-rate-limiter의 역할: Redis 기반 Rate Limiter를 통해 핫 파티션 여부를 판단하고, 쓰기 부하를 제어

SQS 버퍼 활용: 핫 파티션 발생 시 쓰기를 격리하고, DynamoDB 쓰로틀링을 방지

이러한 기술적 세부 사항들을 통해 채널톡은 안정적이고 확장 가능한 GSI 파이프라인을 구축하고, 핫 파티션 문제를 효과적으로 해결했다.