Read Original
#Backend

AWS가 DynamoDB를 만든 방법

AWS가 DynamoDB를 만든 방법
01

Summary

초당 1.5억 건의 트래픽을 견디는 법: AWS가 공개한 DynamoDB 설계의 비밀

아마존의 20년 마이크로서비스 노하우와 무한 스케일링을 가능케 한 셀 기반 아키텍처 Deep Dive

글로벌 최대 규모의 NoSQL 서비스인 DynamoDB의 탄생 배경과 핵심 설계 철학을 다룹니다. Amazon.com이 겪은 아키텍처 진화 과정부터 셀 기반 아키텍처를 통한 장애 격리, 그리고 실제 프라임 데이의 거대 트래픽을 처리하는 내부 구조까지 시니어 엔지니어의 시각에서 요약했습니다.

  • 01보안, 내구성, 가용성이라는 3대 테넷을 기반으로 한 의사결정 체계
  • 02장애 범위를 최소화하는 '셔플 샤딩'과 '셀 기반 아키텍처'의 실무 적용
  • 03데이터베이스 직접 접근을 금지하고 API 서버를 강제하는 분산 컴퓨팅 선언문의 영향
  • 043개의 가용 영역(AZ)에 걸친 데이터 복제 및 9,000 RPS 수준의 배포 전략
  • 05대규모 벌크 트래픽 발생 시 커넥션 유지를 위한 DescribeTable 활용 팁

RECOMMENDATION

대규모 분산 시스템을 설계하거나 데이터베이스 병목으로 고민하는 백엔드 엔지니어에게 추천합니다. 특히 고가용성 서비스 운영을 위한 장애 격리 전략과 비용-안정성 간의 트레이드오프를 이해하는 데 큰 도움이 됩니다.

The Problem

Amazon.com은 과거 모놀리틱 구조에서 개발자 생산성 저하와 데이터베이스 스케일링 문제에 직면했으며, 이를 해결하기 위해 데이터베이스 직접 접근을 금지하는 분산 컴퓨팅 원칙이 필요했습니다.

The Solution

보안, 내구성, 가용성을 핵심 원칙으로 삼아 서비스를 기능 단위 마이크로서비스로 쪼개고, 셀 기반 아키텍처와 셔플 샤딩을 도입하여 장애 범위를 최소화하는 DynamoDB를 설계했습니다.

The Result

아마존 프라임 데이 기준 피크 트래픽 1억 5,100만 RPS를 처리할 수 있는 성능을 확보했으며, 수십 조 건의 API 호출을 견뎌내는 AWS 컨트롤 플레인의 핵심 서비스로 자리 잡았습니다.

Trade-off

장애 격리를 위해 셀 기반 아키텍처를 도입했으나 데이터 스토어를 여러 벌 복제해야 하므로 인프라 비용이 증가하며, 가용성 보장을 위해 상시 50% 이상의 여유 캐퍼시티를 유지해야 하는 비용적 부담이 존재합니다.

03

Key Concepts

Concept · 01

셀 기반 아키텍처 (Cell-Based Architecture)

마이크로서비스를 독립적인 단위인 셀로 샤딩하여 관리하는 구조로, 특정 단위의 장애가 전체로 확산되는 것을 방지합니다.

  • 장애 범위(Blast Radius)를 최소화하기 위해 셔플 샤딩 방식을 채택함
  • 인프라 비용 증가를 감수하더라도 서비스 안정성을 극대화하기 위해 활용됨
Concept · 02

리퀘스트 라우터 (Request Router)

DynamoDB의 입구 역할을 하는 API 서버로 인증, 인가, 메타데이터 조회, 레이트 리밋 등을 처리합니다.

  • 데이터가 위치한 파티션과 스토리지 노드를 확인하는 메타데이터 조회 수행
  • 성능 최적화를 위해 TLS 핸드셰이크를 줄이는 커넥션 풀 관리를 담당함
Concept · 03

셔플 샤딩 (Shuffle Sharding)

사용자나 요청을 여러 샤드 조합에 분산 배치하여, 특정 샤드의 장애가 다른 사용자에게 미치는 영향을 기하급수적으로 줄이는 기법입니다.

  • AWS와 같은 빅테크 기업에서 대규모 트래픽 격리를 위해 표준적으로 사용함
  • 가용 영역(AZ) 기반 구조와 결합하여 높은 가용성을 보장함