목차
데이터베이스는 지금까지 여러 DR이나 인프라 부담을 줄이기 위한 다양한 노력이 꾸준히 이어져 왔다. 예를 들어 AWS만 보더라도, 기본적으로 RDS는 SSD 용량이 차면 자동으로 한계 용량까지 점진적으로 증가시켜주는 기능이 내장되어 있고, 다중 Read 부하를 분산시키기 위해 Read Replica를 만들거나 DR을 대비해 Multi-AZ 배포를 수행하는 등, 안정성을 높이기 위한 다양한 기능이 추가되어 왔다. 그만큼 데이터베이스는 정말 중요하다. 아무리 애플리케이션을 잘 만들어도 데이터베이스가 무너지면 모든 게 무너진다. (물론 반대도 마찬가지겠지만…?)
AWS 자체 개발 DB 엔진인 Aurora를 생각해보자. 자동으로 3개 AZ에 6개의 인스턴스를 분산 배포하여 DR을 보장하고, Write와 Read 엔드포인트를 나누어 트래픽을 분산시키며, Read에 대해서는 자동으로 읽기 용량을 확장해주는 등, DB 관리에 들이는 수고를 줄여주는 기능들이 정말 잘 설계되어 있다.
그런데, 지금까지의 구조를 보면 항상 Write가 가능한 인스턴스는 단 하나였다. Aurora Global Database에서 Write Forward 기능이 있긴 하지만, 마찬가지이다. 지금까지 RDB의 구조는 결국 내부적으로 하나의 Writable&Readable Master와 여러 Readable Slave가 있는 구조이고, Master에서 들어온 입력이 여러 Slave로 커밋 프로토콜을 통해 전파되는 방식이다.
그런데 DSQL은 여러 Write 엔드포인트를 가진다. 즉, 다중 Write가 가능하다는 얘기다. 빠른 속도와 ACID를 보장해야 하는 RDB에서 다중 Write가 가능하다니, 말만 들어도 정말 쉽지 않은 일이다. 그런데 심지어 DSQL은 서버리스다. 서버리스. 사용자가 인프라를 전혀 신경 쓰지 않아도 알아서 자동으로 대응해주는, 극단적인 수준까지 인프라를 추상화한 형태라고 생각한다. 이걸 NoSQL도 아니고 SQL 기반 RDB에 적용했다는 사실이 정말 놀라웠다. (이게 된다고?)
당시 내부 구조가 너무 궁금해서 DSQL 관련 논문을 찾아보려고 했는데 아직 찾을 수 없는 것 같다.
그래서 궁금했다. 도대체 내부 구조가 어떻게 되어 있길래 이게 가능한 걸까? 그 궁금증 때문에 이 강연을 선택하게 되었다.
<aside> 💡
요약
본 문서는 Amazon의 차세대 서버리스 분산 SQL 데이터베이스인 Aurora DSQL의 아키텍처 및 주요 특징을 분석합니다. 2025 AWS Summit에서 들었던 내용을 정리한 것이며, 최대한 원본 그대로 전달하고자 하였습니다.
주요 핵심 내용은 다음과 같습니다.
작년 2024 AWS re:Invent를 통해 공개된 Amazon Aurora DSQL은 서버리스 분산 SQL 데이터베이스의 새로운 지평을 열 것으로 주목받고 있습니다. Aurora DSQL은 특히 온라인 트랜잭션 처리(OLTP) 워크로드에 최적화된 관계형 데이터베이스로서, 기존 데이터베이스 운영의 복잡성을 해소하고 개발 생산성을 극대화하는 데 초점을 맞추고 있습니다.
Aurora DSQL은 데이터 분석이나 리포팅보다는 트랜잭션 중심의 애플리케이션, 예를 들어 금융 시스템의 입출금 처리와 같은 고성능 OLTP 환경에 적합하도록 설계되었습니다.
Aurora DSQL의 핵심 특징은 다음과 같습니다.