SAABlog
KOEN
데이터베이스중급

RPO와 RTO: 재해복구의 핵심 지표를 이해하는 방법

RPO는 데이터 손실 허용량, RTO는 복구 시간 목표입니다. SAA-C03 시험 필수 개념인 RPO/RTO의 차이와 DR 전략 선택 기준을 정리합니다.

PHILOLAMB••-
RPORTO재해복구DR가용성

관련 시험 도메인

  • Domain 2: Design Resilient Architectures

핵심 요약 (BLUF)

RPO(복구 시점 목표)는 "얼마나 많은 데이터 손실을 허용할 수 있는가"이고, RTO(복구 시간 목표)는 "얼마나 빨리 복구해야 하는가"입니다. RPO는 백업 주기를, RTO는 DR 전략의 복잡성을 결정합니다.

시험 팁

시험 핵심: RPO = 과거 방향 (데이터 손실량), RTO = 미래 방향 (복구까지 시간)

RPO와 RTO 한눈에 비교

지표의미질문방향영향
RPO복구 시점 목표데이터를 얼마나 잃어도 되나?과거 ←백업 주기 결정
RTO복구 시간 목표언제까지 복구해야 하나?미래 →DR 전략 결정
RPO와 RTO 시간선:

         ← RPO →          ← RTO →
              │                │
마지막 백업    │    재해 발생    │    복구 완료
    │         │        │       │        │
────●─────────┼────────●───────┼────────●────→ 시간
    │         │        │       │        │
  10:00     11:00    12:00   13:00    14:00

RPO = 2시간 (마지막 백업 ~ 재해 발생)
  → 10:00~12:00 사이 데이터 손실

RTO = 2시간 (재해 발생 ~ 복구 완료)
  → 12:00~14:00 동안 서비스 중단

RPO (Recovery Point Objective)

RPO란?

RPO는 재해 발생 시 허용 가능한 데이터 손실량을 시간으로 표현한 지표입니다. 마지막 백업 시점부터 재해 발생 시점까지의 데이터가 손실됩니다.

RPO 예시:

RPO = 1시간인 경우:
├── 매시간 백업 필요
├── 최대 1시간 분량의 데이터 손실 허용
└── 예: 12:00 백업 → 12:45 재해 → 45분 데이터 손실

RPO = 24시간인 경우:
├── 하루 1회 백업으로 충분
├── 최대 24시간 분량의 데이터 손실 허용
└── 예: 어제 백업 → 오늘 재해 → 최대 24시간 손실

RPO에 영향을 주는 요소

요소낮은 RPO높은 RPO
백업 주기분 단위일 단위
복제 방식동기식/준동기식비동기식
백업 방법연속 백업, 로그 전송전체 백업
비용높음낮음

RPO를 낮추는 AWS 서비스

RPO별 AWS 솔루션:

RPO ~0 (데이터 손실 거의 없음):
├── DynamoDB 글로벌 테이블
├── Aurora Global Database (1초 미만 복제)
└── S3 Cross-Region Replication

RPO 분 단위:
├── RDS Multi-AZ (동기식)
├── RDS Read Replica (비동기식, 지연 있음)
└── EBS 스냅샷 자동화

RPO 시간 단위:
├── AWS Backup 예약
├── RDS 자동 백업
└── S3 버저닝

RPO 산정 기준

비즈니스 질문으로 RPO 결정:

1. "지난 1시간 데이터를 잃으면 어떻게 되나요?"
   → 치명적: RPO < 1시간

2. "하루치 데이터를 잃으면 복구할 수 있나요?"
   → 수동 재입력 가능: RPO = 24시간

3. "트랜잭션 데이터 손실이 허용되나요?"
   → 금융 시스템: RPO ~0

시험 팁

시험 포인트: RPO는 백업 주기와 데이터 복제 방식을 결정. RPO = 1시간이면 최소 1시간마다 백업 필요

RTO (Recovery Time Objective)

RTO란?

RTO는 재해 발생부터 서비스 복구까지의 목표 시간입니다. 서비스 다운타임의 최대 허용치를 정의합니다.

RTO 예시:

RTO = 4시간인 경우:
├── 재해 발생 후 4시간 내 복구 완료 필요
├── 4시간 이상 다운타임 시 비즈니스 영향
└── Warm Standby 또는 Pilot Light 전략 적합

RTO = 0 (제로 다운타임):
├── 다운타임 허용 불가
├── Active-Active 또는 자동 장애 조치 필수
└── Multi-AZ, 글로벌 테이블 등 사용

RTO에 영향을 주는 요소

요소짧은 RTO긴 RTO
인프라 상태상시 가동재해 시 생성
자동화 수준자동 장애 조치수동 복구
DR 전략Active-ActiveBackup & Restore
비용높음낮음

RTO를 줄이는 AWS 서비스

RTO별 AWS 솔루션:

RTO ~0 (즉시 복구):
├── Multi-AZ 배포 (자동 장애 조치)
├── Route 53 장애 조치 라우팅
├── Global Accelerator
└── DynamoDB 글로벌 테이블

RTO 분 단위:
├── Aurora 자동 장애 조치 (~30초)
├── RDS Multi-AZ (~60초)
├── Warm Standby DR 전략
└── AWS Elastic Disaster Recovery

RTO 시간 단위:
├── Pilot Light DR 전략
├── EC2 Auto Recovery
└── CloudFormation 자동화

RTO 24시간 이상:
└── Backup & Restore

RTO 산정 기준

비즈니스 질문으로 RTO 결정:

1. "서비스가 1시간 중단되면 매출 손실은?"
   → $100,000/시간: RTO < 1시간

2. "고객이 24시간 기다릴 수 있나요?"
   → 내부 시스템: RTO = 24시간 가능

3. "규제 요구사항이 있나요?"
   → 금융 규제: RTO 명시적 요구사항 확인

시험 팁

시험 포인트: RTO는 DR 전략을 결정. RTO가 짧을수록 비용이 높은 전략(Active-Active, Warm Standby) 필요

RPO와 RTO의 관계

비용과의 트레이드오프

RPO/RTO와 비용 관계:

비용
  ↑
  │                          ●
  │                     ●
  │                ●
  │           ●
  │      ●
  │ ●
  └─────────────────────────────→ 낮은 RPO/RTO
    24h   4h   1h  15m  1m  0

RPO/RTO가 낮을수록:
├── 더 자주 백업/복제 (RPO)
├── 더 많은 인프라 상시 운영 (RTO)
└── 비용 기하급수적 증가

독립적인 목표

RPO와 RTO는 별도로 설정됩니다. 예를 들어:

시나리오RPORTO전략
은행 코어~0~0Active-Active
이커머스5분1시간Warm Standby
백오피스4시간8시간Pilot Light
아카이브24시간72시간Backup & Restore

워크로드별 예시

워크로드별 일반적인 RPO/RTO:

금융 거래 시스템:
├── RPO: ~0 (트랜잭션 손실 불가)
├── RTO: ~0 (즉시 복구)
└── 전략: Active-Active + 동기 복제

전자상거래:
├── RPO: 5분 (최근 주문 보호)
├── RTO: 30분 (매출 손실 최소화)
└── 전략: Warm Standby + 비동기 복제

내부 HR 시스템:
├── RPO: 4시간 (일일 업무)
├── RTO: 24시간 (다음 영업일까지)
└── 전략: Pilot Light + 정기 백업

로그 아카이브:
├── RPO: 24시간 (분석 목적)
├── RTO: 72시간 (긴급하지 않음)
└── 전략: Backup & Restore

AWS 서비스별 RPO/RTO

데이터베이스 서비스

서비스구성RPORTO
RDS Single-AZ자동 백업5분수 시간
RDS Multi-AZ동기 복제~01-2분
Aurora6개 복사본~0~30초
Aurora Global크로스 리전1초1분
DynamoDB글로벌 테이블~0~0

스토리지 서비스

서비스기능RPO비고
S3버저닝~0객체 단위 복구
S3CRR분 단위비동기 복제
EBS스냅샷시간 단위스냅샷 주기에 따름
EFS백업일 단위AWS Backup 연동

컴퓨팅 서비스

서비스기능RTO비고
EC2Auto Recovery분 단위상태 확인 기반
EC2ASG분 단위새 인스턴스 시작
Lambda다중 AZ~0자동 분산
ECS/EKS다중 AZ~0컨테이너 재배포

실무 적용

RPO/RTO 산정 프로세스

1단계: 비즈니스 영향 분석 (BIA)
├── 시스템별 중요도 분류
├── 다운타임 비용 산정
└── 데이터 손실 영향 평가

2단계: 목표 설정
├── RPO: 허용 가능한 데이터 손실
├── RTO: 허용 가능한 다운타임
└── 예산 확인

3단계: DR 전략 선택
├── RPO/RTO 요구사항 충족
├── 비용 내 구현 가능
└── 테스트/유지보수 가능

4단계: 구현 및 테스트
├── AWS 서비스 구성
├── 자동화 스크립트 작성
└── 정기 DR 훈련 실시

다운타임 비용 계산

다운타임 비용 예시:

전자상거래 사이트:
├── 시간당 매출: $10,000
├── 평판 손실: $5,000/시간
├── 총 다운타임 비용: $15,000/시간
└── RTO 1시간 초과 시 $15,000+ 손실

계산 공식:
다운타임 비용 = 매출 손실 + 생산성 손실 + 복구 비용 + 평판 손실

SAA-C03 시험 출제 포인트

  1. ✅ RPO 정의: 허용 가능한 데이터 손실량 (시간 단위)
  2. ✅ RTO 정의: 복구 완료까지 목표 시간
  3. ✅ 방향: RPO는 과거(백업 시점), RTO는 미래(복구 완료)
  4. ✅ 영향: RPO → 백업 주기, RTO → DR 전략
  5. ✅ 비용: RPO/RTO가 낮을수록 비용 증가
  6. ✅ AWS 서비스: Multi-AZ(낮은 RTO), 동기 복제(낮은 RPO)

시험 팁

시험 문제 예시: "회사는 RPO 5분, RTO 1시간의 요구사항이 있습니다. RDS 데이터베이스에 적합한 구성은?" → 정답: Multi-AZ 배포 + 자동 백업 활성화 (Multi-AZ: RTO 1-2분, 자동 백업: RPO 5분)

자주 묻는 질문 (FAQ)

Q: RPO와 RTO 중 무엇이 더 중요한가요?

워크로드 특성에 따라 다릅니다. 금융 거래 시스템은 RPO(데이터 손실 불가)가 중요하고, 전자상거래는 RTO(빠른 복구로 매출 보호)가 중요할 수 있습니다. 일반적으로 둘 다 비즈니스 요구사항에 맞게 설정합니다.

Q: RPO 0을 달성하려면 어떻게 해야 하나요?

동기식 복제가 필요합니다. RDS Multi-AZ(동기 복제), Aurora(6개 복사본), DynamoDB 글로벌 테이블 등을 사용하면 데이터 손실 없이 복구할 수 있습니다. 단, 동기 복제는 지연시간이 증가할 수 있습니다.

Q: RTO와 MTTR의 차이점은?

RTO는 목표, MTTR은 실제 측정값입니다. RTO(Recovery Time Objective)는 "목표"이고, MTTR(Mean Time To Recovery)는 "평균 복구 시간"입니다. MTTR이 RTO보다 짧아야 목표를 달성한 것입니다.

Q: RPO/RTO를 어떻게 테스트하나요?

정기적인 DR 훈련(Drill)을 실시합니다. 실제 장애를 시뮬레이션하고 복구까지 걸린 시간(RTO)과 데이터 손실량(RPO)을 측정합니다. 최소 연 1회 이상 테스트를 권장합니다.

Q: 모든 시스템에 같은 RPO/RTO를 적용해야 하나요?

아니요, 시스템 중요도에 따라 다르게 설정합니다. Tier 1(핵심)은 낮은 RPO/RTO, Tier 3(비핵심)은 높은 RPO/RTO로 설정하여 비용을 최적화합니다. 이를 "계층화된 DR"이라고 합니다.

Q: AWS에서 RPO/RTO를 모니터링하는 방법은?

AWS Resilience Hub를 사용할 수 있습니다. 애플리케이션의 복원력을 평가하고 RPO/RTO 요구사항 충족 여부를 확인합니다. CloudWatch로 백업 성공/실패, 복제 지연 등도 모니터링합니다.

관련 글

참고 자료