
AWS 연구진이 오로라 DSQL의 내부 설계와 구현을 설명한 논문을 arXiv에 공개했다. 7월 14일 처음 제출되고 16일 수정된 이 논문은 서버리스 분산 SQL 데이터베이스가 멀티리전 환경에서 강한 일관성과 수평 확장을 함께 다루는 방식을 정리했다. 논문 저자 6명은 모두 Amazon Web Services 소속으로 표기됐다.
오로라 DSQL은 연산, 저장, 트랜잭션 조정, 복제를 독립 서비스로 분리한다. 이용자의 SQL을 처리하는 쿼리 프로세서는 Firecracker 마이크로VM에서 실행되며 로컬 상태를 두지 않는다. 저장 노드는 테이블과 인덱스를 샤드 단위로 맡고, 트랜잭션의 충돌 여부는 어드주디케이터가 판단한다. 커밋된 변경은 AWS가 여러 내부 시스템에서 사용하는 복제 구성요소 저널에 기록된 뒤 크로스바를 거쳐 저장 샤드로 전달된다.
읽기 경로는 조정을 줄이는 데 초점이 맞춰졌다. 쿼리 프로세서는 정밀한 시각 정보를 기준으로 특정 시점의 스냅샷을 요청하고, 저장 노드는 다중 버전 동시성 제어 방식으로 해당 데이터를 반환한다. 읽기 전용 트랜잭션과 읽기·쓰기 트랜잭션의 조회 단계는 이용자와 같은 리전에서 처리한다는 설명이다.
쓰기는 커밋 전까지 쿼리 프로세서에 임시로 모인다. 커밋 시점에는 어드주디케이터가 같은 키를 바꾼 다른 트랜잭션이 있었는지 확인하고, 충돌이 없으면 변경 내용을 저널에 원자적으로 기록한다. 멀티리전 구성에서는 일관성 판단과 복제 내구성 확보에 필요한 통신을 한 차례의 리전 간 왕복에 묶는 구조다. 쿼리 실행 중 매 문장마다 원격 잠금을 조정하는 대신 커밋 단계에 조정을 집중해 지연을 줄이려는 선택이다.
일관성 수준은 강한 스냅샷 격리다. 선형화 가능성을 더한 스냅샷 격리를 기본이자 현재 유일한 격리 수준으로 채택했고, 쓰기 간 충돌이 발생할 때 트랜잭션을 중단한다. 직렬화 격리보다 충돌 중단 가능성을 낮추는 대신 쓰기 왜곡이 생길 수 있어, 스키마 설계나 명시적 잠금으로 업무 규칙을 보완해야 한다. 논문은 이 선택이 PostgreSQL의 REPEATABLE READ와 유사하다고 설명한다.
멀티리전 복제에서 저널은 거래 데이터를 둘 이상의 AWS 리전에 내구성 있게 저장한다. 논문에 제시된 3개 리전 구성에서는 정족수 커밋을 활용해 가장 먼 리전의 응답을 기다리지 않고도 일관성과 내구성을 확보한다. 네트워크가 분리되면 다수 쪽에서 서비스를 이어가되, 일관성과 가용성을 동시에 유지할 수 없는 상황에서는 일관성을 우선한다.
AWS 연구진이 제시한 마이크로벤치마크에서는 버지니아와 오하이오 리전을 묶은 구성에서 기본키 SELECT의 99번째 백분위 지연이 약 2ms, UPDATE는 약 3ms로 측정됐다. 멀티리전 COMMIT은 약 30ms, 단일 리전 COMMIT은 7.4ms였다고 논문은 밝혔다. 이는 특정 구성에서 AWS 연구진이 수행한 측정치로, 독립 기관의 비교 검증 결과는 아니다.
논문은 오로라 DSQL이 트랜잭션 처리량을 초당 수백만 건까지 확장하고, 유휴 상태에서는 0까지 줄이는 것을 목표로 한다고 설명한다. 다만 공개 문서는 시스템의 모든 세부 구현을 다루지 않는다. 디스크 저장 구조와 암호화, 쿼리 최적화는 후속 공개 대상으로 남았고, 현재 논문은 arXiv 사전공개본이어서 동료평가를 거친 최종 학술 논문과는 구분할 필요가 있다.
오로라 DSQL의 설계는 분산 데이터베이스 경쟁이 단순한 저장 분산을 넘어 읽기 경로의 지역성, 커밋 조정 방식, 격리 수준의 선택으로 이동하고 있음을 보여준다. 개발자에게는 PostgreSQL 호환성만큼 트랜잭션 의미와 멀티리전 장애 시 동작을 정확히 이해하는 일이 중요해졌다. 성능 수치의 재현성과 실제 워크로드에서의 제약은 후속 기술자료와 독립 벤치마크를 통해 확인될 전망이다.
출처: AWS 연구진 arXiv 논문 https://arxiv.org/abs/2607.13276
출처: 논문 PDF https://arxiv.org/pdf/2607.13276









