백업, 시점 복원, 실수 복구
DSQL의 복구 기능·시간·작업량은 기존 서비스와 어떻게 다른가?
결과 요약
이 실험은 운영자가 데이터를 잘못 바꾼 뒤, 실수 이전 상태의 데이터를 되살려 애플리케이션이 다시 읽을 수 있게 되기까지의 절차와 시간을 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 권한을 새 클러스터로 바꾸는 절차도 준비해야 합니다.
확인할 질문
DSQL의 복구 기능·시간·작업량은 기존 서비스와 어떻게 다른가?
실행 조건
- 리전과 일시: 서울(ap-northeast-2), 2026-09-29 09:24–09:47 UTC.
- 구성: D1 Aurora DSQL 단일 리전, A2 Aurora PostgreSQL 16.15 Serverless v2(writer+reader, 4–32 ACU). 데이터는 E002 규모의 2%(D1 백업 크기 101,940,777 bytes).
- 표식과 실수: 표식 테이블
mvp_marker에 1초 간격으로 30행을 쓰고(09:24:12–09:24:42 UTC), 09:32:54에 모든 행을v = -1로 바꾸고 id 100000인 행을 넣었습니다. - D1 절차: 전용 백업 볼트와 AWS Backup 서비스 역할(
AWSBackupServiceRolePolicyForBackup,...ForRestores)을 만들고, 표식 뒤 온디맨드 백업 → 실수 → 복구 지점에서start-restore-job(삭제 보호 해제) → 새 클러스터 ACTIVE → 러너에 새 클러스터 접속 권한 부여 → 검증 순서로 진행했습니다. 계정에서 AWS Backup의 DSQL 사용 설정은 이미 켜져 있었습니다. - A2 절차: 복원 가능한 최신 시각이 목표 시각을 넘을 때까지 기다린 뒤(0.2초), 마지막 정상 표식과 실수 사이의 중간 시각으로
restore-db-cluster-to-point-in-time→ 클러스터 available →db.serverless인스턴스 생성 → available → 검증. - 검증: 러너에서 복원본에 새로 연결해 표식 수, 덮어쓴 행 수, 실수 뒤 행 수, 표식 합계, 주문 수를 확인했습니다.
- 계획과 달라진 점: 방식·크기별 3회 반복, 7일 보존 정책, 정상 부하 중 복원과 SLO 회복 측정, snapshot 복원 비교, R1·A1은 실행하지 않았습니다.
성능 결과
| 구성 | 복구 방식 | 백업 | 복원(요청→준비) | 첫 연결 | 표식 | 덮어쓴 행 | 실수 뒤 행 |
|---|---|---|---|---|---|---|---|
| D1 | 온디맨드 전체 백업 → 새 클러스터 | 481초 | 129초 | 343 ms | 30/30 | 0 | 0 |
| A2 | 시점 복원 → 새 클러스터 + 인스턴스 | 불필요(연속 백업) | 587초(클러스터 223초) | 291 ms | 30/30 | 0 | 0 |
- 두 복원본의 표식 합계(435)가 원본과 같았습니다. 주문 수는 D1 282,772, A2 282,773으로, 각 원본의 앞선 시험 누적분이 반영된 값입니다.
- D1의 복원 시간에는 백업 시간이 포함되지 않습니다. 실제 사고에서는 백업이 이미 있어야 하므로, 복구 가능한 최신 시점은 마지막 백업 시각입니다.
개발·운영 편의성
- DSQL 백업 준비: AWS Backup 볼트와 서비스 역할이 필요합니다. CLI에서는 기본 볼트가 자동으로 생기지 않습니다. 존재하지 않는 볼트를 조회하면
ResourceNotFound가 아니라AccessDeniedException이 돌아와, 자동화 코드가 이를 “볼트 없음”으로 처리해야 했습니다. - DSQL 복원 결과: 복원은 기본적으로 삭제 보호가 켜진 새 클러스터를 만듭니다. 메타데이터
regionalConfig로 삭제 보호를 끄고 원본 태그를 복사했습니다. 새 클러스터는 식별자와 엔드포인트가 달라 IAM 접속 권한을 다시 주어야 했습니다. - Aurora 시점 복원: 복원 API는 새 관리형 비밀번호 옵션을 받지 않으며 원본의 마스터 비밀번호를 그대로 씁니다. 클러스터 복원 뒤 인스턴스를 따로 만들어야 접속할 수 있습니다.
- 정리: 백업 작업이 끝나기 전에는 볼트를 지울 수 없어, 실행 중인 백업 작업이 끝나기를 기다린 뒤 복구 지점과 볼트를 지웠습니다.
비용
실행 B 전체 비용은 E009 보고서의 비용 절에 정리했습니다. 이 시험에서 추가로 생긴 자원은 AWS Backup 복구 지점 2개(약 102 MB, 수 분 보관), 복원된 D1 클러스터(약 10분), 복원된 A2 클러스터와 인스턴스(약 15분)입니다.
결론과 한계
- 두 서비스 모두 실수 이전 데이터를 정확히 되살렸습니다. DSQL은 복원이 빨랐지만 시점 복원이 없어 복구 시점이 백업 주기에 묶입니다.
- 한계: 1회 실행, 약 100 MB 데이터입니다. 백업·복원 시간은 데이터 크기와 서비스 상태에 따라 달라질 수 있습니다. 부하 중 복원과 애플리케이션 전환까지의 전체 복구 시간은 측정하지 않았습니다.
정리 기록
- 실행 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)의 것입니다.