[Daily morning study] 클라우드 재해복구(DR) 전략: RTO와 RPO 이해하기
#daily morning study
재해복구(DR)란
Disaster Recovery(DR)는 시스템 장애, 자연재해, 사이버 공격 등으로 서비스가 중단됐을 때 빠르게 복구하기 위한 전략과 절차 전체를 가리킨다. 단순한 백업과는 다르다. 백업은 데이터를 어디에 저장하냐의 문제라면, DR은 “어떤 속도로, 어느 수준까지 복구할 수 있냐”의 문제다.
핵심 지표: RTO와 RPO
DR 전략을 논할 때 항상 따라오는 두 개의 지표가 있다.
| 지표 | 정의 | 예시 |
|---|---|---|
| RTO (Recovery Time Objective) | 장애 발생 후 서비스가 정상 복구되기까지 허용 가능한 최대 시간 | “4시간 안에 복구해야 한다” |
| RPO (Recovery Point Objective) | 장애 발생 시 어느 시점까지의 데이터 손실을 허용할 수 있는가 | “최대 1시간 전 데이터까지 손실 감수” |
- RTO가 낮을수록 → 빠른 복구 → 비용 증가
- RPO가 낮을수록 → 데이터 손실 최소화 → 비용 증가
비즈니스 요구사항에 따라 이 두 값을 적절히 설정하는 게 DR 설계의 시작점이다.
4가지 DR 전략
AWS에서는 DR 전략을 비용과 복구 속도 기준으로 크게 4가지로 분류한다.
낮은 비용 / 느린 복구 높은 비용 / 빠른 복구
| |
Backup & Restore → Pilot Light → Warm Standby → Multi-site Active/Active
1. Backup & Restore
가장 단순하고 저렴한 방법. 주기적으로 데이터를 S3나 Glacier에 백업해두고, 장애 발생 시 새 인프라를 프로비저닝하면서 백업 데이터를 복원한다.
- RTO: 수 시간 ~ 수십 시간
- RPO: 마지막 백업 시점 (백업 주기에 따라 수 시간)
- 비용: 가장 저렴
- 단점: 복구 시간이 길다. 실제로 복구 절차를 주기적으로 테스트하지 않으면 비상 상황에서 실패할 수 있다.
# AWS Backup으로 RDS 스냅샷 주기 설정 예시 (AWS CLI)
aws backup create-backup-plan \
--backup-plan '{
"BackupPlanName": "daily-db-backup",
"Rules": [{
"RuleName": "daily",
"TargetBackupVaultName": "Default",
"ScheduleExpression": "cron(0 3 * * ? *)",
"DeleteAfterDays": 30
}]
}'
2. Pilot Light
핵심 컴포넌트(주로 데이터베이스)만 항상 실행 상태로 유지하고, 나머지 인프라(웹 서버, 앱 서버)는 꺼둔다. 장애 시 꺼져 있던 인프라를 빠르게 켜서 전체 시스템을 복구한다.
- RTO: 수십 분 ~ 수 시간
- RPO: 데이터 복제 지연에 따라 수 분 ~ 수십 분
- 비용: Backup & Restore보다 높지만 Warm Standby보다 낮음
- 핵심: 데이터베이스는 항상 운영 환경과 실시간 동기화(복제)되고 있어야 한다.
파일럿 라이트라는 이름은 보일러의 점화 불꽃(pilot light)에서 유래했다. 작은 불씨를 항상 켜두고 필요할 때 큰 불을 붙인다는 개념이다.
3. Warm Standby
운영 환경의 축소 버전을 항상 실행 상태로 유지한다. 트래픽을 처리할 수 있는 상태이지만, 용량이 작다. 장애 발생 시 스케일 업(인스턴스 크기 조정) 또는 스케일 아웃(인스턴스 수 증가)으로 풀 용량을 확보한다.
- RTO: 수 분 ~ 수십 분
- RPO: 수 초 ~ 수 분
- 비용: 항상 일부 인프라가 실행 중이므로 비용이 높음
- 사용 사례: 가용성이 중요한 SaaS 서비스, 금융 시스템
[운영 리전] [DR 리전]
EC2 x 10 → EC2 x 2 (평소, 최소 용량으로 실행 중)
RDS Primary → RDS Read Replica (실시간 복제)
장애 발생 시 DR 리전에서:
1. RDS Replica를 Primary로 승격
2. EC2를 x10으로 스케일 아웃
3. Route 53에서 트래픽 전환
4. Multi-site Active/Active
운영 환경과 동일한 인프라를 여러 리전에 동시에 배포하고, 두 곳 모두 실제 트래픽을 처리한다. 한 리전이 장애나도 나머지 리전이 즉시 전체 트래픽을 받는다.
- RTO: 거의 0 (초 단위)
- RPO: 거의 0
- 비용: 가장 비쌈 (인프라 비용이 2배 이상)
- 사용 사례: 글로벌 서비스, 금융 결제 시스템, 의료 시스템
AWS에서 DR 구성에 자주 쓰는 서비스
| 구성 요소 | 사용 서비스 |
|---|---|
| 데이터 복제 | RDS Read Replica, Aurora Global Database, DynamoDB Global Tables |
| 스토리지 백업 | S3 Cross-Region Replication, AWS Backup |
| 트래픽 전환 | Route 53 (Failover Routing Policy) |
| 인프라 자동화 | CloudFormation, AWS Elastic Disaster Recovery |
| 모니터링 | CloudWatch Alarms → SNS → Lambda (자동 페일오버 트리거) |
DR 전략 선택 기준
전략 선택은 비용과 RPO/RTO의 트레이드오프다.
비용
^
| Multi-site ●
|
| Warm Standby ●
|
| Pilot Light ●
|
| Backup & Restore ●
+---------------------------------> 복구 속도 (빠를수록 오른쪽)
실무에서는 단일 전략만 쓰지 않는다. 예를 들어 핵심 결제 서비스는 Multi-site로, 분석/리포팅 서비스는 Pilot Light로 운영하는 식으로 서비스 중요도에 따라 차등 적용한다.
DR 계획에서 놓치기 쉬운 것들
복구 절차 문서화와 정기 훈련
아무리 좋은 DR 전략을 세워도 실제로 훈련하지 않으면 비상 상황에서 작동하지 않는다. Netflix의 Chaos Engineering(Chaos Monkey)처럼, 의도적으로 장애를 일으켜 복구 능력을 검증하는 게 권장된다.
데이터 일관성 검증
다중 리전 복제 환경에서는 복제 지연(Replication Lag)이 발생한다. 장애 직전에 쓴 데이터가 DR 사이트에 도달했는지 확인하는 절차가 필요하다.
DNS TTL 설정
Route 53 페일오버를 쓸 때 DNS TTL이 너무 길면 트래픽 전환이 느려진다. TTL을 짧게(60초 이하) 유지하되, 평소 캐싱 비용을 고려해 균형을 맞춰야 한다.
3rd party 의존성
외부 API, SaaS 서비스, CDN 등 제어할 수 없는 의존성이 DR 계획에서 병목이 되는 경우가 많다. 각 외부 의존성의 SLA를 파악하고 대체 방안을 마련해야 한다.
정리
- RTO: 장애 후 허용 복구 시간 / RPO: 허용 데이터 손실 범위
- DR 전략 4단계: Backup & Restore → Pilot Light → Warm Standby → Multi-site
- 복구 속도가 빠를수록 비용이 올라간다
- 서비스 중요도에 따라 DR 전략을 차등 적용하는 것이 현실적
- DR 계획은 문서화와 정기 훈련이 핵심이다
