AWS DynamoDB, Amazon.com의 심장을 움직이는 비밀

DynamoDB는 보안(Security), 내구성(Durability), 가용성(Availability)이라는 세 가지 핵심 테넷을 절대적으로 준수하며 설계되었습니다. 이는 기능 개발 시 반드시 지켜야 하는 원칙으로, 대규모 조직에서도 충돌 없이 효율적인 운영을 가능하게 합니다. 아키텍처는 고정된 것이 아니라 지속적인 진화가 필수적이며, 서비스의 신뢰성과 안정성 확보를 위해 작은 단위로 쪼개는 것이 중요합니다. 다만, 마이크로서비스가 많아질수록 인프라 비용 증가라는 현실적인 문제와 안정성 사이의 균형점을 찾아야 합니다.

DynamoDB는 셀 기반 아키텍처(Cell-Based Architecture)를 채택하여 특정 장애가 전체 시스템에 미치는 영향을 최소화합니다. 이는 셔플 샤딩(Shuffle Sharding) 방식을 통해 구현되며, 데이터를 여러 독립적인 셀로 분할하여 관리합니다. 특정 셀에 장애가 발생하더라도 장애 범위(Blast Radius)를 최소화할 수 있다는 장점이 있습니다. 하지만 이 방식은 데이터 스토어를 여러 벌 복제해야 하므로 인프라 비용이 증가하는 단점이 존재합니다. Vitess와 같은 오픈소스 프레임워크는 MySQL 기반의 대규모 샤딩 환경 관리를 지원합니다.

DynamoDB는 3개의 가용 영역(AZ)을 기반으로 동작하며, 각 AZ 내에는 로드 밸런서와 플릿(Fleet)이 존재합니다. 스토리지 노드의 데이터는 파티션 단위로 3벌 복제되어 저장되며, 이는 높은 내구성과 가용성을 보장합니다. 운영 원칙상 3개 AZ 중 1개가 언제든 장애를 일으킬 수 있다고 가정하며, 나머지 2개 AZ가 추가 트래픽을 50% 수용할 수 있도록 캐퍼시티 플래닝이 명확해야 합니다. AZ 개수가 많을수록 가용성은 높아지지만, 운영 복잡도 또한 증가합니다.

DynamoDB는 고객에게 버전 노출 없이 서비스를 제공하는 버전리스(Versionless) 배포 전략을 사용합니다. 배포는 하나의 AZ 단위로 순차적으로 진행되며, 리퀘스트 라우터와 스토리지 노드를 교체합니다. 문서상 SLA는 6,000 RPS이지만, 실제 배포 전략을 통해 9,000 RPS까지 제공 가능합니다. Consistent Read는 3개 노드 중 어느 곳에서든 처리가 가능하며, 라우팅 시에는 동일 AZ를 우선 선택하고 문제가 발생하면 랜덤 라우팅으로 전환하는 전략을 사용합니다.

Amazon Prime Day 기준, Amazon Aurora는 5000억 건의 트랜잭션 처리량과 4PB의 저장 데이터를 기록했습니다. 반면, DynamoDB는 수십 조 건의 API 호출을 처리하며 피크 트래픽 1억 5,100만 RPS를 기록했습니다. 이는 DynamoDB가 AWS 서비스 중 가장 기초가 되는 핵심 서비스이며, AWS 컨트롤 플레인의 대부분이 DynamoDB를 사용하고 있음을 시사합니다. 이러한 방대한 규모는 DynamoDB의 뛰어난 확장성과 성능을 증명합니다.

새로운 기능(Feature)의 빠른 출시는 서비스 정체와 사용자 이탈을 막는 핵심 지표입니다. 개발자 생산성 저하를 시스템 문제로 접근하며, AWS는 피자 두 판으로 먹을 수 있는 규모(약 6~10명)를 팀 최대 크기로 제한하는 투 피자 팀(Two-Pizza Team) 문화를 통해 이를 관리합니다. 이는 팀원 간의 긴밀한 소통과 빠른 의사결정을 촉진하여 개발 속도를 높이는 데 기여합니다.