한 리전 전체가 장애를 겪으면 그 안의 가용영역을 아무리 여러 개 써도 서비스는 멈춥니다. 진짜 재해복구(DR)는 다른 리전에 데이터와 실행 환경의 복제본을 두는 것에서 시작합니다. 핵심은 "복제했다"가 아니라 "얼마나 데이터를 잃고(RPO), 얼마나 빨리 복구하느냐(RTO)"를 비용과 맞바꿔 설계하는 일입니다.
두 개의 지표 — RPO와 RTO
| 지표 | 의미 | 질문 |
|---|---|---|
| RPO | 허용 가능한 데이터 손실 시간 | "얼마 전 데이터까지 복구되면 되나?" |
| RTO | 허용 가능한 복구 소요 시간 | "몇 분/시간 안에 다시 떠야 하나?" |
RPO를 0에 가깝게 가져가려면 동기 복제가 필요한데, 리전 간 거리(수십 ms 지연) 때문에 쓰기 지연이 커집니다. 그래서 대부분의 리전 간 복제는 비동기이고, RPO는 수초~수분으로 잡습니다.
DR 전략 4단계
비용이 낮은 순서이며, 아래로 갈수록 RTO가 짧아집니다.
| 전략 | 평상시 비용 | RTO | 설명 |
|---|---|---|---|
| Backup & Restore | 최저 | 수시간 | 백업만 타 리전에 보관, 장애 시 복원 |
| Pilot Light | 낮음 | 수십 분 | DB만 복제 유지, 앱은 꺼둠 |
| Warm Standby | 중간 | 분 단위 | 축소판 환경 상시 가동 |
| Active-Active | 높음 | 수초 | 양 리전이 동시에 트래픽 처리 |
서비스 등급에 맞춰 고릅니다. 사내 도구라면 Backup & Restore로 충분하고, 결제 같은 핵심 경로는 Warm Standby 이상이 필요합니다.
실무 구성과 검증
- 데이터 계층 복제 — 관리형 DB의 크로스 리전 리드 레플리카를 둡니다. 예:
aws rds create-db-instance-read-replica --source-region ap-northeast-2처럼 다른 리전에 레플리카를 만들고 장애 시 승격(promote)합니다. - 객체 스토리지 복제 — S3 Cross-Region Replication을 켭니다.
JSON
{
"Role": "arn:aws:iam::111122223333:role/s3-crr-role",
"Rules": [{
"Status": "Enabled",
"Filter": { "Prefix": "" },
"Destination": { "Bucket": "arn:aws:s3:::backup-bucket-tokyo" }
}]
}
- 트래픽 전환 준비 — Route 53 health check + failover 라우팅으로 DNS를 대기 리전으로 자동 전환되게 둡니다.
- 정기 DR 훈련 — 가장 중요한 단계입니다. 분기마다 페일오버를 실제로 해보고 RTO가 목표 안에 드는지 측정합니다. "복제는 되는데 막상 승격이 안 되더라"가 실전에서 가장 흔한 사고입니다.
복제 지연(replica lag)은 항상 모니터링합니다. lag이 RPO 목표를 넘으면 그 순간 DR은 무력화된 것입니다.
요점 정리
- DR 설계의 출발점은 기술이 아니라 RPO/RTO 합의입니다.
- 리전 간은 보통 비동기 복제이고, RPO
0은 비용·지연 부담이 큽니다. - 전략은 Backup&Restore → Pilot Light → Warm Standby → Active-Active 순으로 비용·속도가 올라갑니다.
- 복제 설정만큼 정기 페일오버 훈련이 중요합니다.
리전·가용영역·라우팅을 직접 구성하며 DR을 설계해보려면 클라우드 트랙에서 회원가입 없이 무료로 시작할 수 있습니다.