DSQL 실험 노트
실험 목록으로 돌아가기
E009완료P0

DSQL·기존 서비스의 급증 대응과 유휴 후 재개

DSQL 대 기존 서버리스·고정 용량의 지연·수동 개입·비용은?

이슈 #9 측정 계획 측정일 2026-09-29

결과 요약

이 실험은 요청량이 갑자기 늘거나 오랫동안 요청이 없다가 다시 들어올 때, 사람이 용량을 조정하지 않아도 지연 목표를 지키는지를 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회 실행, 소규모 데이터의 결과입니다.

확인할 질문

DSQL 대 기존 서버리스·고정 용량의 지연·수동 개입·비용은?

실행 조건

  • 리전과 일시: 서울(ap-northeast-2), 2026-09-29. 급증 08:43–08:51 UTC, 유휴 08:51–09:21 UTC.
  • 구성: D1 Aurora DSQL 단일 리전, A2 Aurora PostgreSQL 16.15 Serverless v2(writer+reader, 급증 시험 4–32 ACU). 데이터는 E002 규모의 2%. R1·A1(고정 용량)은 이번 MVP에서 제외했습니다.
  • 급증 부하: E002와 같은 업무 혼합을 고정 도착률로 보냈습니다. 단계마다 새 셀로 실행하며 워밍업은 없습니다. 단계 사이에 셀 준비 시간(D1 약 20–45초, A2 약 10초)이 있어, 계획처럼 끊김 없이 이어지는 부하는 아닙니다.
  • 유휴 시험: 러너의 연결을 모두 닫고 900초 기다린 뒤, 새 연결 → 상품 1건 조회 → 이어서 20건 조회 시간을 쟀습니다. 2회 반복. A2는 이 동안 MinCapacity 0, SecondsUntilAutoPause 300으로 바꿨다가 시험 뒤 4–32 ACU로 되돌렸습니다. 연결 제한 시간은 드라이버 설정 15초입니다.
  • 부하 발생기: D1 c6g.4xlarge, A2 m7g.4xlarge Spot 러너.
  • 계획과 달라진 점: Qref 기준 비율(20%→200%→100%→5%) 대신 1,000 TPS 기준을 썼고, 단계 시간을 줄였으며(10/2/20/10분 → 2/1/2/1분), 3회 반복과 유휴 5회 대신 1회와 2회를 실행했습니다.

성능 결과

급증 부하

주문 생성 p95 / p99(ms). 모든 단계에서 실패율 0(D1 1,000 TPS 단계 0.0008%).

단계 도착률 D1 성공 TPS D1 주문 생성 A2 성공 TPS A2 주문 생성 A2 writer ACU(최대)
20% 200 198 29.2 / 38.6 198 8.5 / 12.2 15
200% 2,000 1,960 30.1 / 51.5 1,960 9.3 / 37.9 19–21
100% 1,000 965 29.2 / 40.2 965 8.2 / 9.9 10.5–19
5% 50 49 36.0 / 67.4 49 12.1 / 14.9 10.5
  • D1의 5% 단계 p99가 커진 것은 요청 수가 적어(1분 약 3,000건) 소수의 느린 요청이 p99를 좌우했기 때문으로 봅니다.

유휴 15분 뒤 첫 요청

구성 회차 첫 연결 첫 조회 이후 20건 p50 결과
D1 1 287 ms 123 ms 2.2 ms 성공
D1 2 112 ms 115 ms 1.9 ms 성공
A2 1 15.2초 후 실패 - - 연결 제한 시간 초과
A2 2 15.1초 후 실패 - - 연결 제한 시간 초과
  • A2 writer의 ACU는 08:57–09:05 UTC와 09:12–09:20 UTC에 0이었고, 첫 연결 시도 뒤 1분 안에 2–6 ACU로 올라왔습니다. 재개에 걸린 정확한 시간은 이번 도구로 측정하지 못했습니다(15초 이상).

개발·운영 편의성

  • 급증 시험 동안 두 서비스 모두 사람의 개입이 필요 없었습니다. A2는 ACU 범위(최소·최대)를 미리 정해야 하고, DSQL은 설정할 용량 값이 없습니다.
  • A2의 자동 일시 정지를 쓰려면 최소 용량을 0으로 바꾸고, 애플리케이션의 연결 제한 시간과 재시도를 재개 시간보다 길게 잡아야 합니다. DSQL은 유휴 뒤 첫 연결에 IAM 토큰 서명과 TLS 연결이 필요했지만 0.3초 안에 끝났습니다.

비용

E005·E006·E007·E009는 같은 실행 B(e002-20260929t082035z-afbe, 2026-09-29 08:20–10:20 UTC)에서 자원을 공유했으므로 비용을 실행 단위로 적습니다. 추정 비용은 CloudWatch 사용량에 서울 리전 On-Demand 단가를 곱한 값이고, 실제 청구액은 2026-09-30에 Cost Explorer(2026-09-29 UTC, 사용 유형별)로 확인한 값입니다. 같은 날 실행한 E002 2차 측정과 DSQL DPU·Spot 러너가 같은 줄로 청구되어, DPU는 클러스터별 CloudWatch 값으로, Spot 러너는 인스턴스 타입별 가동 시간 비율로 나눴습니다. 실험 전날에도 나오던 계정 상시 요금은 제외했습니다.

항목 사용량 추정 비용 실제 청구액
A2 컴퓨팅 추정 19.05 ACU-시간(writer 8.53, reader 9.26, E007 복원본 1.26), 청구 18.77 ACU-시간 × $0.20 약 $3.81 $3.75
A2 I/O 청구 119만 8천 I/O 약 $0.29 $0.29
D1 DPU 34,055 DPU + E007 복원본 33 DPU 약 $0.23 $0.34
E007 DSQL 복원 복원 데이터 0.095 GB - $0.002
Spot 러너 2대 c6g.4xlarge 약 1.8시간, m7g.4xlarge 약 1.8시간 약 $0.8 $0.68
합계   약 $5.1 $5.07
  • 두 실행이 함께 쓴 AZ 간 전송·EBS·공인 IPv4 약 $0.65는 어느 한쪽에 나누지 않았습니다.

  • D1 DPU 추정이 실제보다 낮았던 것은 하네스가 마지막으로 측정한 뒤의 사용량이 빠졌기 때문입니다.

  • 하네스의 비용 가드는 측정되지 않은 A2 구간을 최대 32 ACU로 계산해 약 $9.5로 보았고, 이 때문에 E006 재측정 전에 가드 한도를 $14에서 $16으로 올렸습니다.
  • A2의 비용 대부분은 요청이 거의 없는 동안에도 최소 4 ACU씩 켜져 있던 writer와 reader에서 나왔습니다. DSQL은 같은 시간 동안 요청을 처리한 만큼의 DPU($0.34)만 청구되었습니다.

결론과 한계

  • 이번 급증 폭에서는 두 서비스 모두 개입 없이 실패 0건이었고, DSQL의 지연은 부하와 무관하게 일정했습니다.
  • 유휴 뒤 첫 요청은 DSQL이 즉시 응답한 반면, 0 ACU로 멈춘 A2는 재개가 15초 연결 제한 시간을 넘겼습니다.
  • 한계: 1회 실행, 소규모 데이터, 단계 사이 끊김이 있는 급증 부하입니다. 급증 폭이 용량 한계보다 작았고, 고정 용량 대조군(R1·A1)과 유휴 구간 비용 비교는 하지 않았습니다.

정리 기록

  • 실행 B 생성 자원: BATCH(VPC, 서브넷 2개, IGW, 보안 그룹 2개, DB 서브넷 그룹, 러너 IAM 역할·인스턴스 프로파일), D1 DSQL 클러스터, A2 클러스터와 writer·reader, RDS 관리 시크릿, Spot 러너 2대(D1 c6g.4xlarge, A2 m7g.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)의 것입니다.