Amazon Aurora DSQL 멀티리전 강한 일관성 아키텍처

Amazon Aurora DSQL은 2025년 5월 정식 출시(GA)된 PostgreSQL 호환 서버리스 분산 데이터베이스다. 멀티리전에서 읽기와 쓰기를 함께 처리하면서 강한 일관성을 제공한다. 비동기 복제를 사용하는 Aurora Global Database와 달리, 쓰기 경로에서 일관성을 확보하기 위한 설계가 중심에 있다.

분리된 컴포넌트로 구성한 분산 데이터베이스

Aurora DSQL은 PostgreSQL 위에 분산 레이어를 덧붙인 구조가 아니다. 처음부터 분산 환경을 전제로 비집계(disaggregated) 아키텍처를 택했고, 쿼리 프로세서·어드주디케이터·저널·크로스바를 독립 컴포넌트로 분리했다. 워크로드 변화에 따라 각 구성 요소를 별도로 확장할 수 있다.

단일 리전 구성의 가용성 SLA는 99.99%, 멀티리전 구성은 99.999%다. 멀티리전 클러스터에는 두 활성 리전 엔드포인트와 로그 전용 위트니스(Witness) 리전이 포함된다. 활성 리전은 동등한 피어로서 읽기와 쓰기를 모두 처리하며, 위트니스 리전은 쿼럼 유지에만 참여한다.

⤢✕

쿼리 프로세서(QP)는 SQL 파싱·최적화·실행과 클라이언트 통신을 맡는다. 트랜잭션 안의 쓰기 결과는 로컬에 임시로 보관했다가 커밋 시 어드주디케이터에 전달한다.

어드주디케이터(Adjudicator)는 OCC(낙관적 동시성 제어)를 수행한다. 키 범위를 담당하고 커밋 시점의 충돌을 판별하며, 여러 키 범위를 건드리는 트랜잭션에서는 복수의 어드주디케이터가 함께 처리한다.

저널(Journal)은 모든 트랜잭션을 내구성 있는 로그에 기록하는 분산 WAL(Write-Ahead Log)이며 멀티리전 복제의 진실 공급원(Source of Truth)이다. 크로스바(Crossbar)는 저널의 데이터를 스토리지에 전파하고, 읽기 요청에 최신 상태를 제공한다.

잠금 대신 커밋 시점에 충돌을 판정하는 OCC

전통적 RDBMS의 비관적 잠금(Pessimistic Locking)과 달리 Aurora DSQL은 실행 중 잠금을 잡지 않는다. 충돌이 드물다는 가정 아래, 커밋 요청이 들어왔을 때만 충돌을 검사한다.

트랜잭션은 SQL을 실행하고 쓰기 결과를 로컬에 임시 저장한 뒤, 커밋 단계에서 읽기 집합(Read Set)과 쓰기 집합(Write Set)을 분석한다. 충돌이 없으면 커밋되고, 충돌이 감지되면 롤백 후 애플리케이션이 재시도한다.

잠금 대기(Lock Contention)를 없애 처리량을 높일 수 있지만, 같은 데이터에 쓰기가 집중되는 핫스팟(Hotspot) 워크로드에서는 재시도 비용이 커진다. 이 설계는 충돌 빈도가 낮은 OLTP 워크로드에 맞춰져 있다.

전역 커밋 순서와 멀티리전 지연

멀티리전 강한 일관성에서는 서로 다른 리전에서 발생한 트랜잭션에 전역적으로 일관된 순서를 부여해야 한다. Aurora DSQL은 Amazon Time Sync Service를 이용한다.

Amazon Time Sync Service는 원자시계(Atomic Clock)를 탑재한 위성 네트워크를 통해 모든 AWS 리리에 고정밀 동기화된 시간 기준을 제공한다. 트랜잭션의 전역 커밋 순서는 이 외부 타임스탬프를 기반으로 결정된다. Google Spanner의 TrueTime과 유사한 접근이지만 AWS 인프라 특성에 맞게 최적화된 구현이다.

강한 일관성을 유지하려면 커밋 시 리전 간 추가 통신이 필요하다. 멀티리전 읽기-쓰기 트랜잭션에는 커밋 시 2 RTT(왕복 시간)의 추가 지연이 발생하며, 물리적 거리에 비례한다. us-east-1과 us-west-2 조합에서는 약 60-80ms 수준이다. 반면 읽기 전용 트랜잭션은 로컬 리전에서 즉시 처리되므로 추가 지연이 없다.

파티션에서 일관성을 우선하는 선택

CAP 정리에서 분산 시스템은 일관성(Consistency), 가용성(Availability), 파티션 허용(Partition Tolerance)을 동시에 완벽히 충족할 수 없다. Aurora DSQL은 파티션 상황에서 일관성을 우선하는 CP 성향을 기본으로 삼는다.

리전 간 네트워크 파티션이 발생하면 쿼럼이 남아 있는 쪽이 서비스를 계속하고, 소수 측은 쓰기를 거부한다. 데이터 무결성을 지키기 위한 선택이다. 위트니스 리전이 쿼럼에 참여하는 구조로 99.999% 가용성 SLA를 달성한다.

액티브-액티브 쓰기에서 애플리케이션이 맡을 일

동일한 데이터에 두 리전이 동시에 쓰기를 시도했을 때, Aurora DSQL의 OCC 처리는 최종 일관성(Eventual Consistency) 시스템의 자동 병합과 다르다. 커밋 타임스탬프를 기준으로 하나의 트랜잭션만 성공하고 나머지는 롤백된다. 충돌 결과를 자동으로 병합하지 않고, 충돌 자체를 커밋 단계에서 막는다.

따라서 애플리케이션에는 트랜잭션 재시도 로직(Retry Logic)이 필요하다. AWS SDK에서는 지수 백오프(Exponential Backoff)와 지터(Jitter)를 포함한 재시도 패턴을 권장한다.

활성 리전 하나가 장애를 겪어도 다른 활성 리전과 위트니스 리전이 쿼럼을 유지하면 서비스는 계속된다. 페일오버는 자동 처리되며, DNS 기반 멀티리전 엔드포인트 라우팅은 클라이언트 재연결 시간을 줄인다. 라우팅 구성에는 레이턴시 기반 라우팅과 장애 시 우선순위 기반 전환 정책을 함께 설계하는 것이 권장된다.

서버리스 용량 운영과 비용 관점

Aurora DSQL은 요청 부하에 맞춰 자동으로 스케일링하는 완전한 서버리스 모델이다. 용량 계획이 필요 없고, 유휴 상태에서는 스토리지 비용만 발생한다.

비용은 읽기·쓰기 요청 단위(Request Units), 스토리지 GB, 멀티리전 구성의 리전 간 복제 트래픽으로 나뉜다. 읽기 전용 쿼리를 로컬 리전 엔드포인트에 집중하면 멀티리전 2 RTT 지연과 복제 비용을 피할 수 있다. 배치성 쓰기를 트랜잭션으로 묶어 요청 수를 줄이는 방법도 비용 최적화 전략에 포함된다.

접속 풀링은 PgBouncer 등 외부 솔루션으로 구현한다. 서버리스 환경에서는 커넥션을 장시간 유지하는 전통적 풀링보다 짧은 수명의 커넥션 패턴이 맞으며, AWS Lambda 등 서버리스 컴퓨팅과의 조합이 권장된다.

Aurora Global Database와 다른 쓰기 경로

항목	Aurora Global Database	Aurora DSQL
복제 방식	비동기(기본)	동기(강한 일관성)
쓰기 가능 리전	1개(Primary)	복수(액티브-액티브)
쓰기 지연	낮음	리전 간 2 RTT 추가
일관성 보장	최종 일관성	강한 일관성
가용성 SLA	99.99%	99.999%
용량 관리	수동 프로비저닝	서버리스 자동화

Aurora DSQL은 멀티리전 강한 일관성과 액티브-액티브 쓰기를 서버리스 방식으로 구현한다. OCC 기반 충돌 제어, 원자시계 기반 외부 타임스탬프 동기화, 비집계 컴포넌트 아키텍처가 이 구조를 뒷받침한다. 커밋 지연 증가와 핫스팟 워크로드의 재시도 비용은 설계 시 고려해야 하며, 강한 일관성이 필수인 글로벌 금융·커머스 서비스에 적합한 선택지다.