SQL 호환성과 실행 가능성
35개 SQL 검사 중 DSQL은 17개 통과, 16개 미지원(0A000). 대조군 3종은 DSQL 전용 CREATE INDEX ASYNC를 제외한 34개 통과. 주문 트랜잭션(FK 포함)은 DSQL에서 수정 없이 통과했다.
측정일 2026-09-24실험 진행 현황
- 계획
- 0
- 진행 중
- 0
- 완료
- 12
공개 결과
측정·검토를 마친 기록OLTP 처리량과 지연의 한계
DSQL 단독 재측정(2026-09-29)에서 DSQL은 연결 256개 고정 동시성으로 24,541 TPS를 처리하며 SLO(쓰기 p99 35.7 ms)를 지켰다. 같은 조건의 대조군이 SLO를 지킨 최고 처리량은 RDS Multi-AZ 5,839, Aurora Provisioned 3,375, Aurora Serverless v2 11,559 TPS였다. DSQL의 지연은 부하와 거의 무관했지만 절대값은 쓰기 p95 약 28–41 ms로 Serverless v2(7–9 ms)보다 길었다. 부하 발생기가 포화 근처라 DSQL 값은 하한이며, 본 측정·반복은 하지 않았다.
측정일 2026-09-29연결 수, 연결 폭증, 풀링
MVP(DSQL 단독). IAM 토큰 서명은 p50 0.2 ms로 부담이 작았고, 새 연결(TLS·인증·첫 조회)은 순차 실행에서 p50 15.5 ms, p99 120 ms였다. 연결 500개와 1,000개를 한꺼번에 요청해도 거절 없이 모두 성공했다. 반면 요청마다 새 연결을 맺으면 16개 작업자의 조회 처리량이 121 TPS로, 연결을 유지할 때(8,370 TPS)의 약 1/70이었다. 연결 풀 사용이 사실상 필수이며, 대조군 비교와 RDS Proxy는 측정하지 않았다.
측정일 2026-09-29트랜잭션 경합과 데이터 정합성
66개 부하 셀과 격리 수준 시나리오 전부에서 업무 불변식 위반은 0건이었다. 집중(hot) 경합에서 DSQL은 대기 없이 커밋 시점 충돌(40001)로 실패해 p99를 110ms 이하로 유지했지만 원시 충돌률이 동시성 256에서 67–71%까지 올랐다. 대조군(소형 구성)은 잠금 대기가 2초 마감을 넘겨 처리량이 수십 TPS로 떨어졌다. 반복 1회·25초 셀·소형 대조군의 결과이며 용량 비교 근거가 아니다.
측정일 2026-09-26읽기 확장과 최신 데이터 가시성
MVP. 커밋 확인 직후 다른 연결에서 같은 행을 읽는 시험 200회에서 DSQL은 첫 읽기부터 200회 모두 새 값을 보았다(보일 때까지 p99 5.5 ms). Aurora Serverless v2의 reader 엔드포인트는 200회 중 199회가 첫 읽기에서 옛 값을 보였고, 새 값이 보이기까지 p50 21.8 ms, p99 32.6 ms가 걸렸다. writer 엔드포인트의 다른 연결은 바로 보였다. 읽기 처리량 확장은 측정하지 않았다.
측정일 2026-09-29연결 장애·서비스별 복구와 성공 커밋의 보존
MVP. 초당 300건의 주문 부하 중 부하 발생기에서 DB로 가는 패킷을 30초 동안 버리는 클라이언트 쪽 네트워크 장애를 만들었다. DSQL과 Aurora Serverless v2 모두 차단 구간의 요청이 연결 오류로 실패해 셀 전체 실패율이 약 20.6%였지만, 차단을 푼 뒤 0.02–0.07초 만에 새 연결이 성공했고 업무 영수증으로 대조한 커밋 유실·중복 효과는 두 서비스 모두 0건이었다. DB 쪽 장애 조치(failover)와 DSQL 내부 장애는 시험하지 않았다.
측정일 2026-09-29백업, 시점 복원, 실수 복구
MVP. 약 100 MB 데이터에 초 단위 표식 30개를 쓴 뒤 모든 표식을 덮어쓰는 실수를 만들고 복구했다. DSQL은 시점 복원이 없어 실수 전에 받아 둔 AWS Backup 전체 백업(481초)에서 새 클러스터로 복원했고 복원은 129초였다. Aurora Serverless v2는 실수 직전 시각으로 시점 복원했고 클러스터 준비 223초, 인스턴스까지 587초였다. 두 복원본 모두 정상 표식 30개가 그대로였고 덮어쓴 행과 실수 뒤 행은 0개였다.
측정일 2026-09-29데이터 증가와 운영 작업의 영향
MVP(DSQL 단독). 초당 1,000건 주문 부하 중 주문 1,100만 행에 비동기 인덱스를 만들었다. 명령은 0.1초에 돌아왔고 인덱스가 실제로 쓸 수 있게 되기까지 736초가 걸렸다. 빌드 동안 주문 생성 p95가 27.5 ms에서 52.0 ms로, p99가 30.7 ms에서 79.8 ms로 늘었지만 SLO 안이었고 실패는 0건이었다. 열 추가·삭제와 인덱스 삭제는 0.1초 안에 끝났다. 5,000행을 바꾸는 트랜잭션과 310초 동안 열린 트랜잭션은 각각 행 수 한도와 300초 한도로 거절되었다.
측정일 2026-09-29DSQL·기존 서비스의 급증 대응과 유휴 후 재개
MVP. 초당 200→2,000→1,000→50건으로 바뀌는 급증 부하에서 DSQL과 Aurora Serverless v2 모두 수동 개입 없이 실패 0건으로 처리했다. DSQL의 쓰기 p95는 29–36 ms로 부하와 무관하게 일정했고 A2는 8–12 ms였다. 15분 동안 연결이 전혀 없던 뒤 첫 요청은 DSQL이 연결 112–287 ms, 첫 조회 115–123 ms로 응답했지만, 0 ACU까지 자동 일시 정지한 A2는 재개가 늦어 첫 연결이 두 번 모두 15초 제한 시간을 넘겨 실패했다.
측정일 2026-09-29같은 업무의 비용과 선택 기준
MVP(추가 AWS 실행 없음). E002·E009 측정값으로 같은 주문 업무의 시간당 비용을 계산했다. DSQL은 요청 수에 비례해 요청 백만 건당 약 USD 0.31(요청당 0.029–0.032 DPU)이 들고, RDS Multi-AZ는 부하와 관계없이 시간당 약 USD 1.22였다. 평균 부하가 약 1,100 TPS보다 낮거나 유휴 시간이 길면 DSQL이 싸고, 그보다 높은 부하가 계속되면 고정 인스턴스가 싸다. 읽기 복제본을 둔 Aurora Serverless v2는 측정한 모든 부하에서 DSQL보다 비싸거나 비슷했다.
측정일 2026-09-29DSQL의 개발·운영 편의성과 도입 부담
MVP(추가 AWS 실행 없음). E001–E012에서 네 서비스를 실제로 만들고 쓰고 지우며 겪은 작업을 모았다. DSQL은 생성 32초·삭제 약 2분으로 Aurora Serverless v2(생성 약 11분, 삭제 약 15분)보다 빨랐고, 용량 선택·비밀번호 관리·vacuum·reader 라우팅이 필요 없었다. 반면 업무 SQL 35개 중 16개를 고쳐야 했고, 충돌 재시도, 3,000행·300초 트랜잭션 분할, 비동기 인덱스 완료 확인, 외래 키 쪽 인덱스 수동 생성, 1시간 연결 교체, IAM 토큰 서명, 시점 복원 부재에 대응하는 코드와 절차가 추가로 필요했다. 작업 시간은 측정하지 않았다.
측정일 2026-09-29DSQL의 대용량 조회·집계와 OLTP 간섭
MVP(DSQL 단독, S 데이터). 고객별 최근 주문 JOIN은 p50 4.4 ms였고, 주문 10%(110만 행)의 일별 매출 집계는 2.4–2.6초, 주문 품목 약 27만 행의 상품 순위는 0.7초, 주문 1,100만 행 전체 집계는 약 36초였다. 전체 집계 한 번에 약 1,700 DPU(약 USD 0.017)가 들었다. 초당 1,000건의 주문 부하 중 10% 집계를 쉬지 않고 반복해도 OLTP는 실패 0건으로 SLO를 지켰고, 주문 생성 p99는 30.7 ms에서 41.8 ms로 늘었다. 대조군 비교와 L 규모 데이터는 측정하지 않았다.
측정일 2026-09-29실험 목록
전체 계획 읽기OLTP → 급증·유휴 → 대용량 조회 순으로 진행합니다. 편의성과 비용은 첫 생성부터 삭제까지 기록합니다. 실험 번호는 실행 순서가 아닌 식별자입니다.
SQL 호환성과 실행 가능성
DSQL에서 같은 업무를 구현하려면 무엇을 바꿔야 하는가?
결과 DSQL 17/35 무수정 통과, 16개 미지원(0A000). 대조군 3종 34/35 통과
요약과 프로덕션 사용 관점 보기
이 실험은 기존 PostgreSQL 업무를 Aurora DSQL로 옮길 때 SQL을 얼마나 고쳐야 하는지 확인했습니다. 업무 SQL 35개 항목을 DSQL(D1)과 대조군 세 서비스(RDS PostgreSQL, Aurora Provisioned, Aurora Serverless v2)에서 그대로 실행했습니다. DSQL은 17개 항목을 수정 없이 통과했고, 16개 항목은 “지원하지 않는 기능”(SQLSTATE 0A000)으로 거부했습니다. 대조군 세 서비스는 DSQL 전용 문법인 CREATE INDEX ASYNC를 제외한 34개 항목을 모두 통과했습니다.
DSQL에서 수정이 필요했던 영역은 sequence·identity 선언, serial 타입, 인덱스 생성 방식, 임시 테이블과 파티션, PL/pgSQL 함수와 트리거, 격리 수준 지정, statement_timeout, 서버 측 문장 취소입니다. 반면 PK·UNIQUE·CHECK·외래키 같은 제약, JOIN·CTE·window 함수, JSONB, 그리고 핵심 업무인 주문 트랜잭션은 원본 그대로 동작했습니다. SELECT FOR UPDATE는 문법은 통과했지만 동작이 달랐습니다. 대조군은 다른 쓰기를 대기시켰고, DSQL은 대기시키지 않고 커밋 시점에 충돌(40001)로 한쪽을 실패시켰습니다. 따라서 DSQL로 옮기는 애플리케이션에는 실패한 트랜잭션을 다시 시도하는 로직이 필요합니다.
이 결과는 소형 구성과 로컬 클라이언트로 SQL 기능만 검사한 것이며, 각 구성을 한 번씩 실행했습니다. 성능, 지연, 고가용성은 평가하지 않았고, DSQL의 지원 범위는 계속 바뀌므로 2026-09-24 시점의 관측으로 읽어야 합니다.
프로덕션 사용 관점
DSQL은 제약·외래키·JOIN·JSONB와 주문 트랜잭션 같은 핵심 OLTP SQL을 수정 없이 실행했으므로, 처음부터 DSQL 제약에 맞춰 설계하는 새 서비스라면 SQL 측면의 도입 장벽은 낮습니다. 반면 기존 PostgreSQL 서비스를 옮기려면 sequence·serial 선언, 인덱스 생성 방식, PL/pgSQL·트리거, 임시 테이블·파티션을 바꿔야 합니다. 또 격리 수준이 REPEATABLE READ뿐이고 statement_timeout과 서버 측 취소가 동작하지 않으므로, 충돌 재시도와 요청 기한을 애플리케이션에서 구현해야 합니다. 저장 프로시저와 트리거에 로직이 많은 시스템일수록 이관 비용이 커집니다. 이 실험은 기능 검사일 뿐이며, 성능·가용성은 E002 이후 실험으로 판단합니다.
완료P0이슈 #1
OLTP 처리량과 지연의 한계
DSQL의 SLO 용량·지연은 각 대조군의 몇 배인가?
결과 연결 256 기준 SLO 통과 최고 처리량: DSQL 24,541 TPS 이상(하한), A2 11,559, R1 5,839, A1 3,375 TPS. DSQL 쓰기 p95 약 28–41 ms, A2 약 7–9 ms
요약과 프로덕션 사용 관점 보기
이 실험은 같은 주문 업무를 같은 지연 목표(SLO)로 실행할 때 DSQL이 대조군보다 얼마나 많은 요청을 처리하고 지연이 어떻게 다른지 확인했습니다. 업무는 상품 조회 40%, 주문 이력 조회 30%, 주문 생성 20%, 주문 취소 10%로 섞었고, SLO는 읽기 p95 50 ms·p99 100 ms, 쓰기 p95 100 ms·p99 200 ms, 기술적 실패율 0.1% 이하입니다. 실험은 두 번에 나눠 실행했습니다. 2026-09-28에는 네 서비스를 함께 띄워 파일럿과 동시성 탐색을 했지만 DSQL 탐색이 초기화 지연과 예산으로 멈췄고, 2026-09-29에 DSQL만 새로 띄워 셀마다 데이터를 지우지 않는 방식으로 다시 측정했습니다.
연결 수를 고정하고 쉬지 않고 요청을 보내는 방식(closed-loop)에서 DSQL은 연결 64개로 6,680 TPS, 연결 256개로 24,541 TPS를 처리하며 모두 SLO를 지켰습니다. 연결 256개에서도 주문 생성 p99는 35.7 ms로 연결 64개(30.4 ms)와 거의 같았습니다. 같은 방식의 대조군 측정(2026-09-28)에서는 연결 256개에서 세 대조군 모두 쓰기 지연이 SLO를 넘었고, SLO를 지킨 최고 처리량은 RDS Multi-AZ(R1) 5,839 TPS, Aurora Provisioned(A1) 3,375 TPS, Aurora Serverless v2(A2) 11,559 TPS였습니다. 연결 256개 조건에서 DSQL은 A2의 약 2.1배, R1의 약 4.2배, A1의 약 7.3배를 처리했습니다. 이때 부하 발생기 CPU가 80.8%로 포화 기준(85%)에 가까워, DSQL 값은 서비스 한계가 아니라 이번 측정의 하한입니다.
지연의 절대값은 DSQL이 길었습니다. 같은 1,600 TPS에서 DSQL의 주문 생성 p95는 41.0 ms(2026-09-28), A2는 6.8 ms였고, 2026-09-29 측정에서 DSQL 쓰기 p95는 약 28–30 ms였습니다. 요청을 정해진 도착률로 보내는 방식(open-loop)에서는 DSQL이 6,750 TPS까지 SLO를 지켰고 8,100 TPS에서 p99가 200 ms를 넘었습니다. 다만 이 실패는 DSQL의 처리 지연(p95 약 28 ms로 변화 없음)이 아니라 부하 발생기가 프로세스마다 나눠 쓰는 연결을 기다린 시간(대기 p99 약 190 ms) 때문이어서, open-loop 한계는 측정 도구의 연결 풀 한계로 해석합니다. 모든 셀에서 업무 불변식 위반은 0건이었습니다. 계획한 공통 도착률 본 측정과 반복은 하지 못했으므로 서비스 간 차이는 1회 측정 값입니다.
프로덕션 사용 관점
처리량 측면에서 DSQL은 이번 실험에서 가장 크게 확장되었습니다. 연결 256개에서 초당 2만 4천 건 이상의 주문 혼합 업무를 지연 증가 없이 처리했고, 같은 조건에서 기존 서비스는 모두 지연 목표를 넘었습니다. 용량 계획 없이 부하가 커져도 버틴다는 점은 트래픽 변동이 큰 서비스에 유리합니다. 대신 요청 하나의 지연은 Aurora보다 3–6배 길어(쓰기 p95 약 30–40 ms), 요청마다 여러 쿼리를 순서대로 실행하는 화면은 응답 시간이 늘어납니다. 같은 처리량을 내려면 연결과 동시성을 더 많이 써야 하고, 높은 처리량을 계속 유지하면 DPU 요금이 커집니다(E010).
완료P0이슈 #2
연결 수, 연결 폭증, 풀링
DSQL의 인증·연결 갱신·급증 대응에 어떤 부담이 있는가?
결과 MVP: 새 연결 p50 15.5 ms, 동시 연결 1,000개 거절 0건. 요청마다 새 연결 시 처리량 121 TPS vs 연결 유지 8,370 TPS(약 1/70)
요약과 프로덕션 사용 관점 보기
이 실험은 애플리케이션이 DSQL에 연결할 때 IAM 인증과 연결 수립이 얼마나 부담이 되는지, 그리고 연결이 한꺼번에 몰릴 때 거절이나 지연이 생기는지를 확인했습니다. 최소 범위(MVP)로, E002 규모 데이터가 들어 있는 DSQL 클러스터 하나에 대해 부하 발생기 한 대에서 토큰 서명, 순차 연결, 연결 유지와 요청마다 새 연결의 비교, 연결 500개·1,000개 동시 요청을 측정했습니다. 대조군은 이번에 측정하지 않았습니다.
DSQL은 비밀번호 대신 IAM으로 서명한 토큰으로 인증합니다. 토큰 서명은 네트워크 호출 없이 러너 안에서 이루어져 p50 0.2 ms였고, 첫 호출만 클라이언트 초기화로 131 ms가 걸렸습니다. 새 연결을 맺고 첫 조회를 끝내기까지는 순차 실행 100회에서 p50 15.5 ms, p95 109 ms, p99 120 ms였습니다.
연결을 유지한 16개 작업자는 상품 조회를 초당 8,370건(p50 1.9 ms) 처리했지만, 요청마다 새 연결을 맺으면 초당 121건(p50 131 ms)으로 약 70분의 1이 되었습니다. 연결 500개와 1,000개를 한꺼번에 요청했을 때는 모두 거절 없이 성공했지만, 전부 맺어지기까지 각각 3.7초와 8.2초가 걸렸습니다. 이 속도(초당 약 120–135개)는 요청마다 새 연결을 맺을 때의 처리량과 비슷해, DSQL의 연결 수립 속도 제한인지 러너의 단일 Python 프로세스가 TLS 연결을 처리하는 한계인지 이번 측정으로는 구분하지 못했습니다. 폭증 직후 새 연결은 p50 16.2 ms로 평소와 같았습니다.
프로덕션 사용 관점
DSQL의 IAM 토큰 인증 자체는 부담이 작았습니다. 서명은 0.2 ms였고, 토큰을 몇 분씩 재사용하면 연결마다 서명할 필요도 없습니다. 연결 1,000개를 한꺼번에 요청해도 거절되지 않았습니다. 그러나 새 연결 한 번에 15–120 ms가 걸려, 요청마다 연결을 새로 맺는 구조(예: 연결 풀 없이 동작하는 짧은 함수)는 처리량이 연결을 유지할 때의 약 1/70로 떨어졌습니다. 연결 풀을 쓰고, DSQL이 1시간이 지난 연결을 끊으므로 풀이 연결을 주기적으로 교체하게 설정해야 합니다. 대조군과 RDS Proxy 비교는 하지 않았습니다.
완료P0이슈 #3
트랜잭션 경합과 데이터 정합성
DSQL의 경합·재시도는 정합성·지연·구현량에 어떤 영향을 주는가?
결과 불변식 위반 0/66셀. 집중 경합에서 DSQL은 대기 없이 40001로 실패(동시성 256 충돌률 67–71%, 성공 요청 p99 110 ms 이하), 소형 대조군은 잠금 대기로 처리량 급감
요약과 프로덕션 사용 관점 보기
이 실험은 같은 행을 여러 요청이 동시에 갱신할 때 DSQL과 대조군이 정합성을 지키는지, 그리고 충돌과 재시도가 지연과 실패율에 어떤 영향을 주는지 확인했습니다. 주문 생성과 계좌 이체 업무를 동시성 16/64/256, 균등 접근과 인기 키 집중 접근으로 나눠 실행하고, 부하 셀마다 재고·잔액·중복 처리 불변식을 검사했습니다. 66개 부하 셀 전부에서 불변식 위반은 0건이었습니다. 네 서비스 모두 조건부 갱신, 업무 ID 영수증, 재시도, 커밋 여부 확인을 구현하면 이중 처리나 커밋 유실 없이 동작했습니다.
경합을 처리하는 방식은 크게 달랐습니다. DSQL은 잠금 대기 없이 커밋 시점에 충돌(40001)을 알립니다. 그래서 상위 1% 키에 요청의 80%가 몰리는 집중 경합에서 커밋에 성공한 요청의 p99는 110 ms 이하로 짧았지만, 동시성 256의 충돌률은 67–71%였고 최대 3회 재시도 뒤에도 39%가 최종 실패했습니다. 대조군은 행 잠금으로 요청을 줄 세웠고, 동시성 64와 256의 집중 경합에서는 대기가 2초 마감을 넘겨 성공 처리량이 24–512 TPS로 떨어지고 최종 실패율이 18–63%가 되었습니다. DSQL은 READ COMMITTED를 지원하지 않으므로 재시도 구현이 필수이며, 인기 상품처럼 경합이 몰리는 업무는 재시도 예산과 경합을 분산하는 스키마 설계를 함께 검토해야 합니다.
비용 상한(당시 USD 5, 이후 50으로 상향) 때문에 대조군을 버스터블 소형 인스턴스로 줄였고, 셀은 25초씩 한 번만 실행했습니다. 따라서 처리량 차이는 서비스 비교 근거로 쓰지 않으며, 고정 동시성 방식이라 요청이 밀리는 동안의 지연이 빠질 수 있습니다. 계획 규모의 용량과 지연 비교는 E002에서 요청률을 고정하는 방식으로 다시 측정합니다. 사용량으로 계산한 추정 비용은 약 USD 3.4였고, Cost Explorer로 확인한 실제 청구액은 약 USD 2.07입니다(DSQL 월 무료 사용량 차감이 주된 차이).
프로덕션 사용 관점
재시도와 업무 ID 영수증(멱등 처리)을 구현하면 DSQL도 경합 상황에서 이중 처리나 커밋 유실 없이 정합성을 지켰으므로, 정합성 자체는 프로덕션 도입의 걸림돌이 아니었습니다. 경합이 분산된 업무에서는 충돌률이 기존 서비스와 비슷했고 재시도로 대부분 해소되었습니다. 그러나 인기 상품 재고처럼 소수 행에 쓰기가 몰리면 재시도 뒤에도 실패가 크게 남으므로(동시성 256에서 39%), 이런 업무는 재고 행 분할 같은 스키마 재설계 없이는 그대로 옮기기 어렵습니다. 트랜잭션당 3,000행 한도 때문에 대량 삭제·정리 작업을 나눠야 했고, 서버 오류도 한 번 관측되어 재시도가 필수입니다. 소형 대조군·1회 반복의 결과라 용량 판단은 E002에서 합니다.
완료P0이슈 #4
읽기 확장과 최신 데이터 가시성
DSQL은 reader 분산 대비 성능·최신성·라우팅 작업이 어떻게 다른가?
결과 MVP: 쓰기 직후 다른 연결 읽기에서 DSQL 옛 값 0/200, A2 reader 옛 값 199/200(보일 때까지 p99 32.6 ms)
요약과 프로덕션 사용 관점 보기
이 실험은 쓰기가 커밋된 직후 다른 연결에서 그 값을 바로 읽을 수 있는지, 즉 최신 데이터 가시성을 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 용량 결과와 함께 판단해야 합니다.
완료P1이슈 #5
연결 장애·서비스별 복구와 성공 커밋의 보존
같은 연결 장애 뒤 업무 복구·커밋 보존·재연결 부담은?
결과 MVP: 30초 연결 차단 뒤 DSQL·A2 모두 커밋 유실·중복 0건, 차단 해제 후 재연결 0.02–0.07초(DB 장애 조치는 미측정)
요약과 프로덕션 사용 관점 보기
이 실험은 애플리케이션과 DB 사이의 연결이 잠시 끊겼을 때, 연결이 돌아온 뒤 정상 처리로 복귀하는지와 이미 성공한 커밋이 사라지거나 두 번 반영되지 않는지를 확인했습니다. 최소 범위(MVP)로, 초당 300건의 주문 업무를 보내는 도중 부하 발생기에서 DB로 가는 패킷을 30초 동안 버리도록 경로를 막았습니다(블랙홀 라우트). 이것은 클라이언트 쪽 네트워크 장애이며, DB 자체의 장애나 장애 조치(failover)가 아닙니다.
DSQL(D1)과 Aurora Serverless v2(A2) 모두 차단된 30초 동안의 요청이 연결 오류와 시간 초과로 실패해, 150초 측정 구간 전체의 기술적 실패율이 D1 20.6%, A2 20.7%였습니다. 차단 시간이 측정 구간의 20%이므로 차단 구간 요청은 대부분 실패하고 나머지 구간은 정상 처리된 것으로 해석합니다. 차단을 푼 뒤 새 연결로 첫 조회가 성공하기까지 D1은 0.02초, A2는 0.07초였습니다.
가장 중요한 결과는 정합성입니다. 커밋 응답을 받지 못해 성공 여부가 불명확한 요청은 업무 ID 영수증으로 확인한 뒤 재시도하도록 구현했고, 셀이 끝난 뒤 영수증·주문·원장·재고를 대조했습니다. 두 서비스 모두 커밋 유실, 이중 반영, 재고 불일치가 0건이었습니다. DSQL도 대조군과 같은 방식(업무 ID 영수증과 커밋 여부 확인)을 구현하면 연결이 끊긴 상황에서 정합성을 지킬 수 있었습니다.
프로덕션 사용 관점
이번 시험 범위에서 DSQL은 연결이 30초 끊겨도 성공한 커밋을 잃거나 두 번 반영하지 않았고, 연결이 돌아오면 바로 다시 연결했습니다. 다만 이것은 애플리케이션이 업무 ID 영수증과 “커밋 여부 불명확 시 확인 후 재시도”를 구현했기 때문이며, 이 구현은 DSQL과 기존 서비스 모두에 필요합니다. 차단 동안의 요청은 두 서비스 모두 실패했으므로 복구 시간은 네트워크가 돌아오는 시간에 좌우됩니다. DSQL 내부 장애나 AZ 장애에서 어떻게 동작하는지는 공개된 장애 주입 수단이 없어 이번에 확인하지 못했고, Aurora의 장애 조치 시간도 측정하지 않았습니다.
완료P0이슈 #6
백업, 시점 복원, 실수 복구
DSQL의 복구 기능·시간·작업량은 기존 서비스와 어떻게 다른가?
결과 MVP: DSQL은 PITR 없음, 백업 481초+복원 129초로 실수 전 상태 회복. A2 PITR 587초. 두 복원본 표식 30/30 정상
요약과 프로덕션 사용 관점 보기
이 실험은 운영자가 데이터를 잘못 바꾼 뒤, 실수 이전 상태의 데이터를 되살려 애플리케이션이 다시 읽을 수 있게 되기까지의 절차와 시간을 DSQL과 Aurora Serverless v2(A2)에서 비교했습니다. 최소 범위(MVP)로, 약 100 MB 데이터 위에 1초 간격 표식 30개를 쓰고, 이후 모든 표식을 -1로 덮어쓰고 새 행 하나를 넣는 “실수”를 만든 뒤 각 서비스의 방법으로 복구했습니다.
DSQL은 원하는 시각으로 되돌리는 시점 복원(PITR)을 지원하지 않고, AWS Backup의 전체 백업에서 새 클러스터로 복원하는 방법만 있습니다. 그래서 표식을 쓴 뒤, 실수 전에 온디맨드 백업을 받았습니다. 백업(약 102 MB)에 481초가 걸렸고, 이 백업에서 새 클러스터를 만드는 복원 작업은 129초였습니다. A2는 실수 직전 시각을 지정해 시점 복원했고, 복원된 클러스터가 준비되기까지 223초, 인스턴스를 붙여 접속할 수 있게 되기까지 587초가 걸렸습니다.
두 복원본 모두 정상 표식 30개와 합계가 원본과 같았고, 덮어쓴 행과 실수 뒤에 넣은 행은 0개였습니다. 복원본에 처음 연결하는 데 D1 343 ms, A2 291 ms가 걸렸습니다. DSQL의 복원은 빨랐지만, 되살릴 수 있는 시점이 “마지막 백업을 받은 시각”으로 제한되므로 백업 주기 사이에 생긴 변경은 잃습니다.
프로덕션 사용 관점
DSQL로 실수를 복구할 수는 있지만, 기존 Aurora처럼 “실수 1초 전”으로 되돌리는 시점 복원이 없다는 점이 가장 큰 차이입니다. 복구할 수 있는 최신 상태는 마지막 AWS Backup 복구 지점이므로, 허용 가능한 데이터 손실 시간(RPO)에 맞춰 백업 주기를 정하고 비용을 감수해야 합니다. 이번 소규모 데이터에서 백업은 8분, 복원은 2분이었지만, 백업은 매번 전체 백업이라 데이터가 커지면 시간과 비용이 늘 수 있습니다. 복원은 항상 새 클러스터로 이루어지므로 애플리케이션의 접속 주소와 IAM 권한을 새 클러스터로 바꾸는 절차도 준비해야 합니다.
완료P1이슈 #7
데이터 증가와 운영 작업의 영향
DSQL의 DDL·진단·성장 대응은 얼마나 간편하며 제약은 무엇인가?
결과 MVP: 부하 중 1,100만 행 비동기 인덱스 736초, 빌드 중 쓰기 p99 30.7→79.8 ms(SLO 안, 실패 0). 5,000행 트랜잭션·310초 트랜잭션은 한도로 거절
요약과 프로덕션 사용 관점 보기
이 실험은 서비스가 운영 중일 때 스키마를 바꾸거나 인덱스를 만드는 작업이 DSQL에서 얼마나 쉽고 업무에 어떤 영향을 주는지, 그리고 DSQL의 트랜잭션 제약이 실제로 어떻게 드러나는지를 확인했습니다. 최소 범위(MVP)로, E002 규모 데이터가 있는 DSQL 클러스터에 초당 1,000건의 주문 업무를 보내면서 인덱스 생성과 열 추가·삭제를 실행하고, 같은 부하만 보낸 셀과 비교했습니다. 대조군은 이번에 측정하지 않았습니다.
주문 1,100만 행의 status 열에 CREATE INDEX ASYNC로 인덱스를 만들자, 명령은 0.1초 만에 돌아왔고 인덱스가 실제로 쓸 수 있는 상태(indisvalid)가 되기까지 736초(약 12분)가 걸렸습니다. 빌드가 진행된 5분 측정 구간에서 주문 생성 p95는 27.5 ms에서 52.0 ms로, p99는 30.7 ms에서 79.8 ms로 늘었고, 주문 이력 조회 p99도 9.8 ms에서 45.7 ms로 늘었습니다. 그래도 모든 업무가 SLO 안에 있었고 실패는 0건, 업무 불변식 위반도 0건이었습니다. 이어서 실행한 열 추가·열 삭제·인덱스 삭제는 각각 0.1초 안에 끝났습니다.
DSQL의 제약은 분명하게 드러났습니다. 5,000행을 한 트랜잭션에서 바꾸려 하자 “transaction row limit exceeded”(54000)로 거절되었고, 트랜잭션을 310초 동안 열어 두자 “transaction age limit of 300s exceeded”로 거절되었습니다. 대량 변경은 3,000행 이하로 나누고, 5분을 넘는 작업은 트랜잭션을 나눠야 합니다. E002에서도 이 제약 때문에 적재·정리 코드를 나눠 쓰고, 대량 삭제가 느려 측정 방식을 바꿔야 했습니다.
프로덕션 사용 관점
운영 중 인덱스 추가와 열 변경은 DSQL에서 서비스를 멈추지 않고 할 수 있었습니다. 1,100만 행 인덱스 빌드 중 쓰기 지연이 2–3배 늘었지만 목표 안이었고 실패도 없었습니다. 다만 인덱스는 명령이 끝난 뒤에도 약 12분 동안 쓸 수 없으므로, 배포 절차가 indisvalid를 확인하고 나서 새 인덱스에 의존하는 코드를 켜야 합니다. 3,000행과 300초 트랜잭션 한도는 대량 수정·삭제, 긴 배치 작업을 여러 트랜잭션으로 나누도록 강제하므로, 기존 배치나 데이터 이관 스크립트는 다시 작성해야 합니다. vacuum 같은 유지보수는 사용자가 할 일이 없지만, 대조군과의 운영 부담 비교는 하지 않았습니다.
완료P1이슈 #8
DSQL·기존 서비스의 급증 대응과 유휴 후 재개
DSQL 대 기존 서버리스·고정 용량의 지연·수동 개입·비용은?
결과 MVP: 급증(최대 2,000 TPS) 실패 DSQL·A2 0건. 15분 유휴 후 첫 연결 DSQL 112–287 ms, auto-pause A2는 15초 연결 제한 초과 2/2
요약과 프로덕션 사용 관점 보기
이 실험은 요청량이 갑자기 늘거나 오랫동안 요청이 없다가 다시 들어올 때, 사람이 용량을 조정하지 않아도 지연 목표를 지키는지를 DSQL과 Aurora Serverless v2(A2)에서 비교했습니다. 최소 범위(MVP)로, 기준 1,000 TPS의 20%(2분) → 200%(1분) → 100%(2분) → 5%(1분)로 도착률을 바꾸는 급증 부하를 한 번 보내고, 그 뒤 연결을 모두 닫은 채 15분 기다렸다가 첫 요청을 보내는 유휴 시험을 두 번 했습니다.
급증 부하에서는 두 서비스 모두 수동 개입 없이 모든 단계를 실패 0건으로 처리했습니다. DSQL의 주문 생성 p95는 29.2–36.0 ms로 도착률이 10배 늘어도 거의 변하지 않았고, 2,000 TPS 단계의 p99는 51.5 ms였습니다. A2는 4–32 ACU 범위에서 writer가 10.5 ACU에서 최대 21 ACU까지 늘었고, 주문 생성 p95는 8.2–12.1 ms, 2,000 TPS 단계 p99는 37.9 ms였습니다. 이 급증 폭(최대 2,000 TPS)은 E002에서 측정한 두 서비스의 용량보다 작아서, 용량 한계에서의 급증 대응은 이번 결과로 판단할 수 없습니다.
유휴 뒤 첫 요청에서는 차이가 컸습니다. DSQL은 15분 동안 연결이 없었던 뒤에도 첫 연결 112–287 ms, 첫 조회 115–123 ms로 응답했고, 그 뒤 조회는 약 2 ms로 돌아왔습니다. A2는 이 시험 동안 최소 용량을 0 ACU로, 자동 일시 정지를 300초로 설정했고, CloudWatch에서 실제로 0 ACU까지 멈춘 것을 확인했습니다. 이 상태에서 첫 연결은 두 번 모두 드라이버 연결 제한 시간 15초 안에 끝나지 않아 실패했고, 그 연결 시도가 재개를 일으켜 약 1분 안에 용량이 다시 올라왔습니다.
프로덕션 사용 관점
요청이 드문드문 들어오거나 밤새 멈추는 서비스에서는 DSQL이 뚜렷하게 유리했습니다. DSQL은 15분 유휴 뒤에도 첫 요청을 0.3초 안에 처리했고, 유휴 동안 컴퓨팅 요금이 나가지 않습니다. Aurora Serverless v2도 0 ACU 자동 일시 정지로 유휴 비용을 없앨 수 있지만, 재개하는 동안 첫 연결이 15초를 넘겨 실패했으므로 연결 제한 시간과 재시도를 길게 잡아야 합니다. 이번 급증 폭에서는 두 서비스 모두 수동 개입 없이 처리했으므로, 용량 한계 근처의 급증 대응은 E002 용량 결과와 함께 판단해야 합니다. 1회 실행, 소규모 데이터의 결과입니다.
완료P0이슈 #9
같은 업무의 비용과 선택 기준
DSQL의 성능·편의성 이점은 어떤 비용·제약을 수반하는가?
결과 MVP: DSQL 요청 백만 건당 약 USD 0.31. RDS Multi-AZ(시간당 약 USD 1.22)와의 손익분기 평균 약 1,100 TPS. 8시간 활동+16시간 유휴 하루 비용 DSQL 약 USD 9 vs RDS 약 USD 29
요약과 프로덕션 사용 관점 보기
이 실험은 같은 업무와 같은 지연 목표를 지킬 때 DSQL과 기존 서비스의 비용이 부하 모양에 따라 어떻게 달라지는지 계산했습니다. 최소 범위(MVP)로, 새로 AWS 자원을 띄우지 않고 E002(처리량·DPU·ACU)와 E009(유휴 동작)에서 측정한 값에 서울 리전 On-Demand 단가를 곱했습니다. 업무는 E002의 주문 혼합(상품 조회 40%, 주문 이력 30%, 주문 생성 20%, 취소 10%)입니다.
DSQL은 처리한 양만큼 DPU로 과금되며, 이 업무에서 요청 한 번에 0.029–0.032 DPU를 썼습니다. 서울 단가(백만 DPU당 $10)로 요청 백만 건당 약 $0.31이고, 1,000 TPS를 한 시간 유지하면 약 $1.12입니다. 반면 RDS Multi-AZ(db.r6g.xlarge, gp3 400 GiB)는 부하와 관계없이 시간당 약 $1.22이고 SLO 안에서 5,839 TPS까지 처리했습니다. 따라서 평균 부하가 약 1,100 TPS보다 낮으면 DSQL이 싸고, 그보다 높은 부하가 계속되면 고정 인스턴스가 쌉니다. Aurora Provisioned(writer+reader, 시간당 약 $1.25 + I/O)도 비슷한 손익분기를 보입니다.
부하 모양에 따라 차이가 커집니다. 1,000 TPS로 24시간 일정한 부하에서는 하루 비용이 DSQL 약 $27, RDS Multi-AZ 약 $29로 비슷했습니다. 8시간만 1,000 TPS로 일하고 16시간 쉬는 서비스는 DSQL 약 $9, RDS 약 $29로 DSQL이 약 3분의 1이었습니다. 읽기 복제본을 둔 Aurora Serverless v2(A2)는 writer와 reader가 함께 커져 1,000 TPS에서 시간당 약 $3.4였고, 최소 용량 때문에 유휴 시간에도 과금되어 하루 약 $53이었습니다. 0 ACU 자동 일시 정지를 쓰면 약 $27로 줄지만, E009에서 첫 연결이 15초를 넘겨 실패했습니다.
프로덕션 사용 관점
비용만 보면 DSQL은 “요청이 적거나 들쭉날쭉한 서비스”에 유리하고, “높은 부하가 하루 종일 이어지는 서비스”에는 불리합니다. 이번 업무에서 손익분기는 평균 약 1,100 TPS였습니다. 그보다 낮은 부하에서는 고정 인스턴스를 계속 켜 두는 비용이 사라지고 고가용성도 기본 포함이라 DSQL이 쌉니다. 반대로 수천 TPS를 계속 처리하면 요청 수에 비례하는 DPU 요금이 고정 인스턴스보다 커집니다. 큰 집계도 처리량만큼 과금되므로(E012), 분석 업무가 많은 서비스는 따로 비용을 계산해야 합니다. 이 계산은 한 업무 혼합, On-Demand 단가, 1회 측정값에 기반한 추정입니다.
완료P0이슈 #10
DSQL의 개발·운영 편의성과 도입 부담
DSQL은 초기 도입·반복 운영의 작업 시간과 수정량을 얼마나 줄이거나 늘리는가?
결과 MVP: 인프라 작업은 줄었지만(생성 32초, 용량·비밀번호·vacuum·라우팅 불필요) 앱 쪽 부담이 늘었다(SQL 16/35 수정, 재시도·트랜잭션 분할·비동기 인덱스·연결 교체·PITR 부재 대응)
요약과 프로덕션 사용 관점 보기
이 실험은 DSQL을 도입할 때 인프라 운영 작업이 얼마나 줄고, 그 대신 애플리케이션과 운영 절차에 어떤 부담이 더해지는지를 정리했습니다. 최소 범위(MVP)로, 새 AWS 실행 없이 E001부터 E012까지 네 서비스(DSQL, RDS Multi-AZ, Aurora Provisioned, Aurora Serverless v2)를 실제로 만들고, 적재하고, 부하를 주고, 복구하고, 지우며 겪은 작업을 모았습니다. 계획의 작업별 시간 측정과 3회 재실행은 하지 않았으므로, 작업 시간 절감률은 계산하지 않았습니다.
인프라 쪽 작업은 DSQL이 뚜렷하게 적었습니다. DSQL 클러스터는 생성 요청 뒤 32초 만에 쓸 수 있었고 삭제는 약 2분이었습니다. Aurora Serverless v2(writer+reader)는 생성에 약 11분, 삭제에 약 15분이 걸렸습니다. DSQL에는 인스턴스 크기나 최소·최대 용량을 고르는 단계, 저장할 비밀번호, vacuum 같은 유지보수 설정, 읽기·쓰기 라우팅이 없었고, 2만 4천 TPS까지 부하가 늘어도 용량을 조정할 필요가 없었습니다.
반면 애플리케이션 쪽 부담은 DSQL에서 늘었습니다. 업무 SQL 35개 가운데 16개를 고쳐야 했고(E001), 커밋 시점 충돌을 다시 시도하는 코드가 필수였습니다(E004). 트랜잭션은 3,000행과 300초를 넘을 수 없어 적재·삭제·배치 코드를 나눠야 했고(E002, E008), 비동기 인덱스는 완료를 따로 확인해야 했으며, 외래 키 쪽 인덱스를 직접 만들어야 했습니다. 연결은 1시간마다 교체하고 IAM 토큰을 서명해야 했고(E003), 시점 복원이 없어 실수 복구는 백업 주기에 묶였습니다(E007).
프로덕션 사용 관점
DSQL은 “DB 서버를 운영하는 일”을 크게 줄여 줍니다. 용량 계획, 인스턴스 교체, 비밀번호 교체, vacuum, reader 라우팅을 신경 쓸 필요가 없었고, 클러스터 생성도 30초 남짓이었습니다. 대신 그 부담의 상당 부분이 애플리케이션으로 옮겨 갑니다. 기존 PostgreSQL 코드는 SQL 수정, 재시도, 트랜잭션 분할, 연결 교체를 다시 설계해야 하고, 시점 복원이 없는 만큼 백업 주기와 복구 절차를 따로 정해야 합니다. 새로 만드는 서비스가 처음부터 이 제약에 맞춰 설계한다면 이점이 크고, 저장 프로시저·대량 배치가 많은 기존 서비스를 옮기면 부담이 큽니다. 작업 시간은 측정하지 않았습니다.
완료P0이슈 #11
DSQL의 대용량 조회·집계와 OLTP 간섭
DSQL의 큰 쿼리 성능·OLTP 간섭·튜닝 부담은?
결과 MVP: 1,100만 행 전체 집계 약 36초(약 1,700 DPU), 110만 행 집계 2.4–2.6초. 집계 반복 중 OLTP 실패 0, 주문 생성 p99 30.7→41.8 ms
요약과 프로덕션 사용 관점 보기
이 실험은 DSQL에서 큰 JOIN·집계 쿼리가 얼마나 걸리고 비용이 얼마인지, 그리고 이런 쿼리를 주문 업무(OLTP)와 동시에 실행하면 OLTP가 얼마나 느려지는지를 확인했습니다. 최소 범위(MVP)로, 계획의 L 규모 대신 E002의 S 규모 데이터(주문 1,100만, 주문 품목 2,750만 행)에서 선택도가 다른 네 쿼리를 실행했고, 초당 1,000건의 OLTP 부하 중 집계를 반복하는 간섭 시험을 했습니다. 대조군은 이번에 측정하지 않았습니다.
인덱스를 쓰는 고객별 최근 주문 20건 JOIN은 30회 실행에서 p50 4.4 ms, p95 32.9 ms였습니다. 주문 10%(약 110만 행)를 날짜별로 집계하는 쿼리는 2.4–2.6초, 주문 1% 범위의 주문 품목(약 27만 행)으로 상품 순위를 매기는 window 쿼리는 0.7초, 주문 1,100만 행 전체를 상태별로 집계하는 쿼리는 약 36초가 걸렸습니다. 같은 쿼리를 두 번 실행한 결과 행 수와 결과 해시가 같았고, 두 번째 실행도 첫 번째와 거의 같은 시간이 걸려 반복 실행으로 빨라지는 효과는 보이지 않았습니다.
DSQL은 쿼리가 처리한 양만큼 DPU로 과금합니다. 분 단위 사용량으로 추정하면 전체 집계 한 번에 약 1,700 DPU(약 $0.017), 10% 집계 한 번에 약 100–150 DPU가 들었습니다. 초당 1,000건의 OLTP 부하를 보내면서 10% 집계를 쉬지 않고 반복(5분 동안 124회, p50 2.4초)하자, OLTP는 실패 0건으로 SLO를 지켰고 주문 생성 p95가 27.5 ms에서 32.0 ms로, p99가 30.7 ms에서 41.8 ms로, 상품 조회 p99가 6.9 ms에서 16.4 ms로 늘었습니다.
프로덕션 사용 관점
DSQL에서 인덱스를 타는 조회는 빠르지만, 수백만 행 이상을 훑는 집계는 초 단위에서 수십 초가 걸렸고(1,100만 행 약 36초), 트랜잭션 300초 한도 때문에 더 큰 집계는 나눠 실행해야 합니다. 서버 쪽 statement_timeout과 문장 취소가 동작하지 않으므로(E001), 오래 걸리는 쿼리를 중간에 멈출 수단도 제한됩니다. 집계를 반복해도 OLTP는 목표 안에서 처리되어 간섭은 작았습니다. 다만 집계는 처리한 데이터만큼 DPU 요금이 나오므로, 정기 리포트나 대시보드처럼 큰 집계가 잦은 업무는 분석용 저장소로 분리하는 편이 비용 면에서 안전합니다. 대조군과의 속도 비교는 하지 않았습니다.
완료P1이슈 #12
무엇을, 어떻게 비교하나요?
DSQL의 우위를 전제하지 않습니다. 같은 업무·정합성·SLO를 만족한 결과로 판단합니다.
- 성능
- 기한 내 성공 처리량과 p95/p99 지연. 연결·재시도 시간을 포함하고 반복 측정의 편차를 공개합니다.
- 편의성
- 첫 연결·이관·확장·진단·복구의 실제 작업 시간, 수동 개입과 수정량. 초기 학습과 반복 운영을 구분합니다.
- 비용과 제약
- 동일 요구를 충족하는 성공 업무당 비용. 미지원 기능·미측정 항목을 밝히고 종료 후 모든 실험용 리소스를 삭제합니다.