[외부 초청 세션] AWS가 DynamoDB를 만든 방법

안녕하세요. 채널팀 Developer Relations 소마입니다. 👋

채널팀에서는 매주 금요일, 팀원들이 업무에서 얻은 지식과 인사이트를 함께 나누는 엔지니어 세션을 운영하고 있습니다. 사내 엔지니어의 발표가 주를 이루지만, 때로는 외부 엔지니어를 초빙해 더 넓은 시각의 이야기를 듣기도 합니다.

지난 6월 12일에는 AWS의 Sr. Specialist SA이신 이혁님을 모시고 'How AWS built DynamoDB' 세션을 진행했습니다. DynamoDB의 설계 철학을 넘어, Amazon.com이라는 초대형 서비스가 어떻게 이 하나의 데이터베이스로 운영되는지, 그리고 DynamoDB와 ElastiCache를 GenAI 워크로드에 어떻게 접목할 수 있는지까지. 세션을 듣고 현업에서 바로 참고할 수 있는 인사이트들을 공유합니다.

1. DynamoDB의 핵심 테넷 (Tenets)

DynamoDB 서비스팀이 절대적으로 지키는 세 가지 원칙으로, 어떤 기능을 개발하더라도 이를 어기면서는 출시할 수 없습니다.

• 보안 (Security)

• 내구성 (Durability)

• 가용성 (Availability)

모든 구성원이 이 세 테넷을 내재화하고 있기 때문에, 조직 규모가 매우 크더라도 충돌 없이 효율적으로 운영됩니다.

2. Amazon.com의 아키텍처 진화

분산 컴퓨팅 선언문 (Distributed Computing Manifesto)

• 애플리케이션에서 데이터베이스에 직접 접근하는 것을 원칙적으로 금지했습니다.

• 데이터베이스 위에 API 서버를 별도로 두고, 백엔드 서버는 API 서버를 통해서만 데이터베이스에 접근하도록 강제했습니다.

• 특정 백엔드 서버에 장애가 발생해도 다른 서비스는 API 서버를 통해 데이터에 계속 접근할 수 있습니다.

모놀리틱 → SOA → 마이크로서비스

• 모놀리틱 구조에서 개발자 생산성 저하와 데이터베이스 스케일링 문제가 발생했습니다.

• 큰 데이터베이스를 쪼개고, 각 서비스가 자체 데이터 스토어 + API 서버 + 백엔드 서버를 갖는 마이크로서비스 구조로 전환했습니다.

• 마이크로서비스 분리 기준 — 아래 세 가지 요구사항이 동일한 것끼리 묶습니다.

  • 스케일링 요구사항 (Scaling Requirements)

  • 데이터 접근 요구사항 (Data Access Requirements)

  • 보안 요구사항 (Security Requirements)

• 이 기준으로 마이크로서비스를 나눈 지 이미 20년이 넘었습니다.

아키텍처 설계 원칙

• 아키텍처는 한 번 만들고 끝이 아니라 문제가 생기면 계속 진화시켜야 합니다. 진화하지 않는 아키텍처는 결국 죽습니다.

• 서비스를 작은 단위로 쪼개는 것이 신뢰성과 안정성의 핵심입니다.

• 마이크로서비스가 많아질수록 인프라 비용은 급격히 증가합니다. 비용과 안정성 사이의 균형을 선택해야 합니다.

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

• 셀(Cell)은 하나의 마이크로서비스를 여러 개로 샤딩(Sharding)한 독립 단위입니다.

• 빅테크들은 일반적으로 셔플 샤딩 (Shuffle Sharding) 방식을 사용합니다.

  • 장점: 특정 셀에 장애가 발생해도 다른 셀은 영향을 받지 않아 장애 범위(Blast Radius)를 최소화할 수 있습니다.

  • 단점: 데이터 스토어를 여러 벌 복제해야 하므로 인프라 비용이 증가합니다.

Vitess

• MySQL 기반으로 대규모 샤딩 환경을 관리하는 오픈소스 프레임워크입니다.

• 많은 수의 샤드를 사용하는 환경에서 각 샤드의 매핑을 관리해주는 역할을 합니다.

4. DynamoDB 내부 구조

리퀘스트 라우터 (Request Router)

DynamoDB의 리퀘스트 라우터는 API 서버 역할을 합니다. 처리하는 주요 업무는 다음과 같습니다.

• 인증(Authentication) 및 인가(Authorization)

• 메타데이터 조회: 데이터가 어느 파티션, 어느 스토리지 노드에 있는지 확인

• 레이트 리밋(Rate Limit) 검사

• KMS를 통한 암호화 키 조회

• 커넥션 풀(Connection Pool) 관리

매번 새로운 연결을 맺으면 TLS 핸드셰이크, 인증, 메타데이터 조회 등이 반복됩니다. 커넥션을 재사용하는 것이 성능에 매우 중요합니다.

가용 영역(AZ) 기반 구조

• DynamoDB는 3개의 가용 영역(AZ)을 기반으로 동작합니다.

• 각 AZ 안에는 여러 로드 밸런서와 이에 연결된 플릿(Fleet)들이 존재합니다.

• 스토리지 노드의 데이터는 파티션(Partition) 단위로 3벌 복제되어 저장됩니다.

• AZ 운영 원칙: 3개 중 1개가 언제든 죽을 수 있다고 가정하고, 나머지 2개가 즉시 50% 추가 트래픽을 수용할 수 있는 캐퍼시티 플래닝이 명확해야 합니다.

• AZ 개수는 많을수록 가용성이 높아집니다.

배포 전략

• DynamoDB는 고객에게 버전이 노출되지 않는 Versionless 서비스를 지향합니다.

• 배포는 하나의 AZ 단위로 진행되며, 리퀘스트 라우터와 스토리지 노드를 순차적으로 교체합니다.

• SLA 기준: 문서상 6,000 RPS이나, 배포 전략을 지키면서 실제로는 9,000 RPS까지 제공 가능합니다.

• Consistent Read: 3개 노드 중 아무 노드에서 처리해도 무방합니다.

• 라우팅 전략: 가능하면 동일한 AZ를 먼저 선택하고, 문제가 생기면 랜덤 라우팅으로 전환합니다.

5. DynamoDB 규모 및 성능 (Amazon Prime Day 기준)

DynamoDB는 AWS 서비스 중 가장 기초가 되는 핵심 서비스입니다. AWS 컨트롤 플레인(Control Plane)의 대부분이 DynamoDB를 사용합니다.

6. 개발자 생산성 관리

• 새로운 기능(Feature)을 얼마나 빠르게 출시할 수 있는가가 핵심 지표 중 하나입니다. 새 기능이 계속 나오지 않으면 서비스가 정체되고 사용자 이탈률이 높아집니다.

• 생산성 저하의 원인은 개발자 개인의 문제가 아니라 시스템(아키텍처)의 문제로 접근합니다.

• 투 피자 팀 (Two-Pizza Team): AWS 개발팀의 문화로, 피자 두 판으로 먹을 수 있는 규모(약 6~10명)를 팀 최대 크기로 제한합니다.

7. 트래픽 최적화 사례

문제 상황: 컨테이너 약 2,000개가 동시에 대용량 요청을 보내는 벌크(Bulk) 트래픽이 발생했습니다. 벌크 트래픽 규모는 약 20,000 TPS로 일반 트래픽 대비 약 2,000배 수준이었습니다.

해결 방법:

• 해당 테이블에 평소에도 트래픽이 많다면, 벌크 트래픽과 일반 트래픽을 같은 채널로 처리해도 됩니다.

• 낮은 레이턴시(예: 2.1ms)가 여전히 필요하다면, 설정(Configuration)을 변경해 해결할 수 있습니다.

• 특정 테이블에 트래픽이 적을 때는 DescribeTable 같은 더미 요청을 일부 보내 커넥션을 유지합니다.

이번 세션 덕분에 DynamoDB를 한층 더 깊이 이해할 수 있는 시간이었습니다. 바쁜 일정에도 흔쾌히 자리해 주신 이혁님께 다시 한번 감사드립니다! 

채널팀 엔지니어 세션은 앞으로도 계속됩니다!