클라우드 데이터베이스 기술은 지난 10년간 비약적으로 발전해 왔지만, 엔지니어들은 여전히 인스턴스 크기 산정, 패치 관리, 다중 리전(Multi-region) 구성 시의 복잡한 데이터 동기화 문제로 고민하고 있습니다. Amazon Aurora Distributed SQL (DSQL)은 기존 관리형 DB(DBaaS) 수준을 넘어 '진정한 서버리스(True Serverless)' 구조의 데이터베이스 기술을 제안했습니다.
<aside> 💡
출시 제품명이 Amazon Aurora DSQL 이지만, 기존의 Aurora와 혼동이 있어 이 발표에서는 Amazon DSQL 혹은 그냥 DSQL로 부르겠습니다. 또한 이 발표에서 별 수식 없이 Aurora 라고 하면 기존에 알려진 Aurora MySQL과 Aurora PostgreSQL 을 포함한 Amazon Aurora를 의미합니다.
</aside>
과거의 Aurora MySQL이나 PostgreSQL은 인프라 관리의 상당 부분을 자동화했지만, 여전히 물리적인 인스턴스 개념이 존재했고, 특정 가용 영역(AZ)에 종속된 아키텍처를 가졌습니다. 반면 DSQL은 내부 슬로건인 **"Database system of first resort(가장 먼저 선택하는 데이터베이스)"**가 시사하듯, 개발자가 워크로드 규모나 리전 가용성을 고민하지 않고 즉시 연결해 사용할 수 있는 데이터 시스템을 지향합니다.
이는 단순히 관리의 편의성을 넘어, 초당 1회부터 수백만 QPS(초당 트랜잭션)까지 즉각적으로 확장되는 분산 시스템의 정점을 목표로 하고 있습니다. 'API로서의 데이터베이스'라고 정의한다면, 기존 Aurora보다는 Aurora DSQL이 그 본질에 훨씬 더 가까운 모델이라고 할 수 있습니다.
<aside> ⚠️
오류 주의: DSQL에 대한 제 이해가 개념적이라, 일부 실제와 다른 부분이 있을 수 있습니다. 가능하면 개념적인 부분에서 제가 이해한 것을 설명하는 것으로 이해 부탁드립니다.
</aside>
DSQL은 모든 구성 요소가 완전히 분리된(Disaggregated) 구조를 취하며, 각 계층은 워크로드 특성에 따라 독립적으로 확장됩니다.
이미지 출처: https://www.youtube.com/watch?v=mK2h9VPRgnI
이미지 출처: https://www.youtube.com/watch?v=mK2h9VPRgnI
특히 DSQL은 읽기 전용(Read-only) 트랜잭션의 경우 커밋을 **No-op(무연산)**으로 처리하여 지연 시간을 사실상 제로에 가깝게 유지하는 기술적 정교함을 보여줍니다.
글로벌 스케일 분산 DB의 선구자인 Google Spanner와 DSQL은 지향점이 유사해 보이지만, DSQL은 실제 시장의 요구사항에 맞춰 결정적인 차별점을 두었습니다.
첫째, DSQL은 Serializability 대신 **Snapshot Isolation(스냅샷 격리)**을 선택했습니다. OLTP 워크로드에서는 Write-Write Conflict보다 읽기-쓰기 충돌이 훨씬 빈번하게 발생하는데, Snapshot Isolation은 이를 체크할 필요가 없어 압도적인 성능 우위를 점할 수 있기 때문입니다.
둘째, Spanner가 하드웨어 의존적인 원자 시계(Atomic Clock)에 기반한 TrueTime을 요구하는 것과 달리, DSQL은 표준 **EC2 시간 서비스(Time Service)**를 활용합니다. 이를 통해 특수 장비 없이도 모든 AWS 리전에서 동일한 아키텍처를 구현할 수 있는 운영의 범용성과 이식성을 확보했습니다.