Amazon DynamoDB

트래픽이 급증하는 키 조회 서비스인데도 관계형 데이터베이스를 샤딩하고 인덱스를 튜닝하는 데 시간을 쓰기 시작하면, 저장 방식보다 운영 복잡도가 더 큰 문제가 됩니다. 요청 패턴이 대부분 키 기반인데도 확장이 수동이면 서비스가 커질수록 발목을 잡습니다.

트래픽이 폭발적으로 늘던 웹 서비스들은 관계형 데이터베이스를 직접 샤딩(sharding, 데이터를 여러 서버에 나눠 저장하는 방식)하며 수평 확장을 시도했습니다. 그런데 샤드 수를 늘릴 때마다 기존 데이터를 새 샤드로 재분배하는 작업이 필요했고, 특정 키에 요청이 몰리는 핫스팟이 생기면 그 샤드만 과부하 상태가 되어 장애로 이어졌습니다. 장애 복구도 각 샤드 서버를 직접 다뤄야 해서 운영팀의 부담이 컸습니다. 이 고통을 서비스 차원에서 흡수하기 위해, 파티션 관리와 데이터 분산을 자동으로 처리하는 완전 관리형 NoSQL 방식인 DynamoDB가 등장했습니다.

DynamoDB에 데이터를 저장할 때는 파티션 키(데이터를 어느 물리 파티션에 저장할지 결정하는 기준 값)를 지정합니다. 파티션 키 값은 해시 함수를 거쳐 특정 파티션으로 매핑되고, 그 파티션에 데이터가 기록됩니다. 조회할 때도 같은 파티션 키를 해시하면 데이터가 있는 파티션으로 바로 라우팅되기 때문에 전체 테이블을 스캔하지 않습니다. 이 구조 덕분에 테이블 크기와 무관하게 단일 자릿수 밀리초 응답을 유지할 수 있습니다. 보조 인덱스(GSI/LSI)는 파티션 키가 아닌 다른 속성으로도 같은 방식의 빠른 조회 경로를 추가로 만들어 줍니다.

DynamoDB와 RDS는 둘 다 애플리케이션 데이터를 저장하지만 접근 방식이 다릅니다. DynamoDB는 키 기반 저지연 조회와 자동 확장에 강하고, RDS는 조인과 복잡한 트랜잭션에 강합니다. 요청 패턴이 미리 정해진 키 조회 중심이면 DynamoDB를 보고, 관계형 질의와 정합성이 핵심이면 RDS를 보면 됩니다.

세션 저장, 장바구니, 프로필, 이벤트 상태, 게임·모바일·IoT 같은 대규모 실시간 조회 데이터처럼 키 중심 액세스가 많은 서비스에 적합합니다. 복잡한 조인이나 트랜잭션 정합성이 필요한 워크로드에는 맞지 않습니다.