채널톡의 사내 엔지니어 세션에 AWS 인사를 초빙해 진행한 'How AWS built DynamoDB' 세션 정리다. DynamoDB의 설계 철학뿐 아니라 Amazon.com이 어떻게 이 하나의 데이터베이스로 운영되는지, 서비스팀이 지키는 원칙과 셀 기반 아키텍처, 실제 벌크 트래픽 대응 사례까지 다룬다.
핵심 포인트- Amazon은 애플리케이션이 데이터베이스에 직접 접근하는 것을 원칙적으로 금지하고, API 서버를 통해서만 접근하도록 강제했다.
- 마이크로서비스 분리 기준은 요구사항이 같은 것끼리 묶는 것이며, 데이터 접근 요구사항이 그중 하나다. 이 기준으로 나눈 지 20년이 넘었다.
- 아키텍처는 한 번 만들고 끝이 아니라 문제가 생기면 계속 진화시켜야 하며, 진화하지 않는 아키텍처는 결국 죽는다고 정리한다.
- 셀은 하나의 마이크로서비스를 여러 개로 샤딩한 독립 단위로 장애 범위를 최소화하지만, 데이터 스토어를 여러 벌 복제해야 해 인프라 비용이 증가한다.
- AZ는 3개 중 1개가 언제든 죽을 수 있다고 가정하고 나머지 2개가 즉시 50% 추가 트래픽을 받도록 캐퍼시티 플래닝을 명확히 해야 한다.
상세 정리- 세션 배경: 채널팀은 매주 금요일 팀원들이 업무에서 얻은 지식을 나누는 자리를 갖고, 때로는 외부 엔지니어를 초빙해 더 넓은 시각을 듣는다.
- 서비스팀의 원칙: DynamoDB 팀에는 어떤 기능을 개발하더라도 어기면서는 출시할 수 없는 세 가지 원칙이 있고, 모든 구성원이 이를 내재화해 조직 규모가 커도 충돌 없이 운영된다.
- 분산 컴퓨팅 선언문: 데이터베이스 위에 API 서버를 별도로 두면 특정 백엔드 서버에 장애가 나도 다른 서비스는 API 서버를 통해 데이터에 계속 접근할 수 있다.
- 아키텍처 변천: 모놀리틱에서 개발자 생산성 저하와 데이터베이스 스케일링 문제가 생겨 SOA를 거쳐, 각 서비스가 자체 데이터 스토어와 API 서버, 백엔드 서버를 갖는 기능 단위 마이크로서비스로 전환했다.
- 서비스를 작은 단위로 쪼개는 것이 신뢰성과 안정성의 핵심이지만, 마이크로서비스가 많아질수록 인프라 비용이 급격히 증가해 비용과 안정성 사이의 균형을 선택해야 한다고 짚는다.
- 샤딩 관리: 많은 수의 샤드를 쓰는 환경에서 각 샤드의 매핑을 관리해주는 오픈소스 프레임워크가 언급된다.
- 리퀘스트 라우터: DynamoDB에서 API 서버 역할을 하며 데이터가 어느 파티션과 스토리지 노드에 있는지 메타데이터를 조회한다.
- 커넥션 재사용의 중요성: 매번 새 연결을 맺으면 TLS 핸드셰이크와 인증, 메타데이터 조회가 반복되므로 재사용이 성능에 매우 중요하다.
- 복제 구조: 3개 AZ 기반으로 동작하며 각 AZ 안에 여러 로드 밸런서와 플릿이 있고, 스토리지 노드의 데이터는 파티션 단위로 3벌 복제된다.
- 배포 전략: 고객에게 버전이 노출되지 않는 Versionless 서비스를 지향하며, 배포는 하나의 AZ 단위로 진행하고 리퀘스트 라우터와 스토리지 노드를 순차 교체한다.
- SLA는 문서상 6,000 RPS이지만 이 배포 전략을 지키면서 실제로는 9,000 RPS까지 제공 가능하다고 밝힌다.
- 읽기 라우팅: Eventually Consistent Read는 3개 노드 중 아무 곳에서 처리해도 되며, 가능하면 동일 AZ를 먼저 고르고 문제가 생기면 랜덤 라우팅으로 전환한다.
- 조직 관점: 새 기능을 얼마나 빠르게 출시할 수 있는지가 핵심 지표 중 하나이고, 새 기능이 계속 나오지 않으면 서비스가 정체돼 이탈률이 높아진다. 생산성 저하는 개발자 개인이 아니라 시스템의 문제로 접근한다.
- 팀 규모: 피자 두 판으로 먹을 수 있는 약 6~10명을 팀 최대 크기로 제한하는 문화를 소개한다.
- 실제 사례: 컨테이너 약 2,000개가 동시에 대용량 요청을 보내는 벌크 트래픽이 약 20,000 TPS로 일반 트래픽 대비 약 2,000배 수준으로 발생한 상황을 다룬다.
- 대응 판단: 해당 테이블에 평소에도 트래픽이 많다면 벌크와 일반 트래픽을 같은 채널로 처리해도 되고, 낮은 레이턴시가 여전히 필요하면 설정 변경으로 해결할 수 있다.
- 커넥션 유지 팁: 특정 테이블에 트래픽이 적을 때는 DescribeTable 같은 더미 요청을 일부 보내 커넥션을 유지한다.
- DynamoDB는 AWS 서비스 중 가장 기초가 되는 핵심 서비스로 컨트롤 플레인 대부분이 이를 사용한다고 언급한다.
왜 읽나DynamoDB를 쓰면서 내부 동작과 운영 원칙을 알고 싶은 백엔드 엔지니어에게, 복제·배포·라우팅 구조와 벌크 트래픽 대응 판단 기준을 한 번에 훑어준다.
채널톡·
여기어때 (GC컴퍼니)·
Vercel Blog·