SW BBANG K

DynamoDB 테이블을 설계하다 보면 반드시 마주치는 상황이 있다. 기본 키로는 조회가 잘 되는데, 다른 속성으로도 쿼리해야 하는 요구사항이 생기는 것이다. 이때 LSI(Local Secondary Index)와 GSI(Global Secondary Index) 중 무엇을 써야 하는지 판단하지 못하면, 나중에 테이블을 통째로 재설계해야 하는 상황이 온다. TL;DR: LSI vs GSI 핵심 비교 항목 LSI GSI 파티션 키 기본 테이블과 동일 다른 속성 지정 가능 정렬 키 다른 속성으로 변경 가능 선택적으로 지정 생성 시점 테이블 생성 시에만 가능 언제든지 추가/삭제 가능 일관성 읽기 강력한 일관성 지원 최종적 일관성만 지원 처리량 공유 기본 테이블과 공유 독립적으로 프로비저닝 파티션당 크기 제한 10GB (파티션 키 값 기준) 제한 없음 테이블당 최대 개수 5개 20개 (기본값, 조정 가능) DynamoDB 인덱스가 동작하는 방식 LSI와 GSI를 선택하기 전에, 두 인덱스가 내부적으로 어떻게 다른지 이해해야 한다. 잘못된 선택은 단순히 성능 문제로 끝나지 않는다. LSI는 테이블 생성 후 추가할 수 없기 때문에, 나중에 필요하다는 걸 알았을 때는 이미 늦다. LSI: 같은 파티션 안에서의 다른 정렬 방식 LSI는 기본 테이블과 동일한 파티션 키를 사용한다. 달라지는 것은 정렬 키뿐이다. 물리적으로 ...

DynamoDB 테이블을 처음 생성할 때 가장 먼저 마주치는 질문이 바로 용량 모드 선택이다. 트래픽 패턴이 불분명한 초기 단계에서 Provisioned를 잘못 설정하면 스로틀링으로 요청이 거부되고, On-Demand를 무심코 유지하다 보면 예상치 못한 청구서를 받게 된다. 이 글은 DynamoDB 용량 모드 의 내부 동작 원리부터 실전 전환 판단 기준까지, 운영 경험을 바탕으로 정리한다. TL;DR — 한눈에 보는 선택 기준 상황 권장 모드 핵심 이유 트래픽 패턴 미확인, 초기 서비스 On-Demand 스로틀링 없이 자동 스케일, 용량 예측 불필요 트래픽이 예측 가능하고 일정함 Provisioned + Auto Scaling 단위 비용이 낮고 비용 상한 제어 가능 급격한 스파이크 + 평시 트래픽 낮음 On-Demand 피크 대비 Provisioned 과잉 프로비저닝 방지 높은 베이스라인 + 예측 가능한 피크 Provisioned + Auto Scaling Reserved Capacity와 조합 시 비용 최적화 DynamoDB 용량 모드의 내부 동작 원리 두 모드를 단순히 '자동 vs 수동'으로 이해하면 운영 중 반드시 실수가 생긴다. 각 모드가 내부적으로 어떻게 처리량을 관리하는지 먼저 파악해야 한다. Provisioned 모드 Provisioned 모드에서는 RCU(Read Capacity Unit)와 WCU(Write Capacity Unit)를 명시적으로 설정한다. DynamoDB는 설정된 용량을 파티션 단위로 분배하며, 특정 파티션에 요청이 집중되면 해당 파티션의 할당량이 소진되어 ProvisionedThroughputExceededException 이 발생한다. Auto Scaling을 활성화하면 CloudWatch 지표를 기반으로 목표 사용률에 맞게 RCU/WCU를 자동 ...