읽기 확장과 최신 데이터 가시성
DSQL은 reader 분산 대비 성능·최신성·라우팅 작업이 어떻게 다른가?
결과 요약
이 실험은 쓰기가 커밋된 직후 다른 연결에서 그 값을 바로 읽을 수 있는지, 즉 최신 데이터 가시성을 DSQL과 Aurora Serverless v2(A2)에서 비교했습니다. 계획의 전체 범위 대신 최소 범위(MVP)로 줄여, 한 연결에서 행을 넣고 커밋 응답을 받은 즉시 다른 연결이 10 ms 간격으로 그 행을 조회하는 시험을 200회 반복했습니다.
DSQL(D1)은 200회 모두 첫 조회에서 새 행이 보였습니다. 두 번째 연결이 행을 확인하기까지 걸린 시간은 p50 2.1 ms, p99 5.5 ms로, 조회 한 번의 왕복 시간 수준이었습니다. DSQL은 접속 지점이 하나뿐이고 커밋이 끝난 데이터는 어느 연결에서나 바로 읽혔으므로, 애플리케이션이 쓰기 직후 읽기를 writer로 보내는 라우팅 규칙을 따로 둘 필요가 없었습니다.
A2는 writer 엔드포인트의 다른 연결에서는 200회 모두 바로 보였지만(p99 0.5 ms), reader 엔드포인트로 조회하면 200회 중 199회가 첫 조회에서 행을 찾지 못했습니다. 새 행이 reader에서 보이기까지 p50 21.8 ms, p95 22.1 ms, p99 32.6 ms, 최대 65.5 ms가 걸렸습니다. reader로 읽기를 분산하는 구성에서는 “쓰기 직후 자기 쓰기 읽기”가 필요한 요청을 writer로 보내거나 수십 ms의 지연을 허용해야 합니다. 이번에는 읽기 처리량 확장과 reader 수에 따른 성능은 측정하지 않았습니다.
프로덕션 사용 관점
최신성 측면에서 DSQL은 유리했습니다. 커밋 직후 다른 연결에서도 200회 모두 새 값을 읽었으므로, 기존 Aurora처럼 reader 복제 지연(이번 측정 p99 약 33 ms)을 피하려고 쓰기 직후 읽기를 writer로 보내는 라우팅 코드를 둘 필요가 없습니다. 주문 직후 주문 내역을 보여 주는 화면처럼 자기 쓰기를 바로 읽어야 하는 업무에서 구현이 단순해집니다. 다만 읽기 처리량을 얼마나 늘릴 수 있는지는 이번에 측정하지 않았고, E002에서 본 것처럼 DSQL의 읽기 지연 자체는 Aurora writer보다 약 4배 길었습니다. 읽기 비중이 매우 큰 서비스는 E002 용량 결과와 함께 판단해야 합니다.
확인할 질문
DSQL은 reader 분산 대비 성능·최신성·라우팅 작업이 어떻게 다른가? 이번 MVP는 이 가운데 최신성과 그에 따른 라우팅 필요성만 답합니다.
실행 조건
- 리전과 일시: 서울(ap-northeast-2), 2026-09-29 08:38–08:40 UTC.
- 구성:
- D1: Aurora DSQL 단일 리전 클러스터.
- A2: Aurora PostgreSQL 16.15 Serverless v2, writer 1 + 다른 AZ reader 1(승격 순위 1), 각 4–32 ACU, Aurora Standard.
- 데이터: E002 데이터 규모의 2%(고객 2만, 주문 22만 행, 약 100 MB). 가시성 시험용 테이블
mvp_visibility를 따로 만들고 시험 뒤 지웠습니다. - 방법: 쓰기 연결이
INSERT를 자동 커밋으로 실행하고 응답을 받은 시각부터, 관측 연결이 새 트랜잭션으로 10 ms마다 그 행을 조회했습니다. 5초 안에 보이지 않으면 검열(censored)로 셌습니다. 시험마다 200회입니다. - 관측 연결: D1은 같은 엔드포인트의 다른 연결. A2는 writer 엔드포인트의 다른 연결과 reader 엔드포인트(
pg_is_in_recovery() = true로 복제본임을 확인) 두 가지. - 부하 발생기: 구성마다 Spot 러너 1대(D1
c6g.4xlarge, A2m7g.4xlarge). 가시성 시험은 연결 두 개만 쓰므로 러너 사양 차이는 결과에 영향을 주지 않습니다. - 계획과 달라진 점: 읽기 중심 부하의 처리량·p99 비교, reader 수 변경, R2 구성, 엔진 복제 지표 수집은 실행하지 않았습니다.
성능 결과
| 구성 | 관측 경로 | 첫 조회에서 옛 값 | 5초 초과 | 보일 때까지 p50 | p95 | p99 | 최대 |
|---|---|---|---|---|---|---|---|
| D1 | 같은 엔드포인트, 다른 연결 | 0/200 | 0 | 2.1 ms | 2.8 ms | 5.5 ms | 41.8 ms |
| A2 | writer 엔드포인트, 다른 연결 | 0/200 | 0 | 0.2 ms | 0.3 ms | 0.5 ms | 4.1 ms |
| A2 | reader 엔드포인트 | 199/200 | 0 | 21.8 ms | 22.1 ms | 32.6 ms | 65.5 ms |
- 보일 때까지의 시간에는 관측 조회 자체의 왕복 시간이 포함됩니다. D1의 값이 A2 writer보다 큰 것은 복제 지연이 아니라 DSQL 조회 한 번의 지연(E002에서 읽기 약 2–10 ms) 때문입니다.
- A2 reader의 지연은 조회 간격 10 ms 단위로 측정되므로 약 ±10 ms의 오차가 있습니다.
개발·운영 편의성
- DSQL은 접속 지점이 하나라서 읽기·쓰기 라우팅 설정이 필요 없었습니다. A2는 reader 엔드포인트가 클러스터 엔드포인트와 별도로 있고(
.cluster-ro-), 쓰기 직후 읽기를 어느 쪽으로 보낼지 애플리케이션이 결정해야 합니다. - DSQL에서 시험 테이블을 만들고 지우는 DDL은 문제없이 실행되었습니다.
비용
이 시험은 E005·E006·E007·E009를 함께 실행한 실행 B(e002-20260929t082035z-afbe)의 일부이며, 가시성 시험 자체는 약 2분이었습니다. 실행 B 전체 비용은 E009 보고서의 비용 절에 정리했습니다.
결론과 한계
- DSQL은 커밋 직후 다른 연결에서도 새 값을 읽었고, A2 reader는 거의 매번 수십 ms 늦게 보였습니다. 이 차이는 쓰기 직후 읽기 라우팅이 필요한지를 가릅니다.
- 한계: 각 시험 200회, 1회 실행입니다. 소규모 데이터와 부하 없는 상태의 측정이라, 부하가 큰 상황의 복제 지연은 더 클 수 있습니다. 읽기 처리량 확장은 측정하지 않았습니다.
정리 기록
- 실행 B 생성 자원: BATCH(VPC, 서브넷 2개, IGW, 보안 그룹 2개, DB 서브넷 그룹, 러너 IAM 역할·인스턴스 프로파일), D1 DSQL 클러스터, A2 클러스터와 writer·reader, RDS 관리 시크릿, Spot 러너 2대(D1
c6g.4xlarge, A2m7g.4xlarge). E007에서 AWS Backup 볼트, 백업 서비스 역할, 복구 지점 2개, 복원된 DSQL 클러스터 1개, 시점 복원한 A2 클러스터와 인스턴스를 추가로 만들었습니다. - 삭제: 백업 볼트와 복구 지점 2개는 09:35 UTC, 복원된 DSQL 클러스터와 A2 복원본은 09:48 UTC부터 약 10:05 UTC까지 소유 태그를 확인한 뒤 삭제했습니다. 나머지는
e002.py batch-down으로 10:04–10:20 UTC에 삭제했습니다. 삭제에 실패한 자원은 없습니다. - 검증 (10:20:27 UTC):
e002.py verify의remaining_count=0입니다. 수동 교차 확인으로 AWS Backup 볼트 0개, 이 실행 접두어의 RDS 클러스터·IAM 역할 0개, 열린 Spot 요청 0개를 확인했습니다. 이 시각에 남아 있던 DSQL 클러스터 1개는 동시에 실행 중이던 실행 A(E002·E003·E008·E012)의 것입니다.