재해 복구 & 비즈니스 연속성

재해 복구 설계는 목표 복구 시간(RTO)과 허용 데이터 손실량(RPO)을 비용과 함께 맞추는 작업이다. 예를 들어 RTO 1시간, RPO 15분이라는 요구만으로 특정 전략을 확정할 수는 없다. 데이터 복제 방식과 대기 환경의 용량, 장애 조치 절차를 확인해야 실제 목표를 검증할 수 있다. 아래 시간 표기는 전략 간 상대적인 차이를 설명하는 예시이지 서비스가 보장하는 값은 아니다. 실제 RTO·RPO는 복구 절차를 정기적으로 시험해 측정한다.

1. 핵심 개념: RTO와 RPO

RTO (Recovery Time Objective)

목표 복구 시간 — 장애 발생 후 서비스가 복구되기까지 허용되는 최대 시간

장애 발생 ──────────────────────→ 서비스 복구
          ←────── RTO ────────→
          (이 시간 안에 복구해야 함)

• RTO 4시간: 장애 후 최대 4시간 내 서비스 재개
• RTO가 짧을수록 → 더 많은 인프라 비용 필요

RPO (Recovery Point Objective)

목표 복구 시점 — 장애 발생 시 어느 시점의 데이터까지 손실을 허용하는가

마지막 백업 ──────────→ 장애 발생
           ←── RPO ──→
           (이 구간의 데이터는 손실 허용)

• RPO 1시간: 최근 1시간 이내 데이터는 손실될 수 있음
• RPO가 짧을수록 → 더 자주 백업·복제 필요

RTO vs RPO 판단 기준

비용
 ↑  Multi-Site Active-Active  ← 가장 짧은 목표를 설계할 수 있으나 0을 보장하지 않음
 │  Warm Standby              ← RTO 분, RPO 분
 │  Pilot Light               ← RTO 시간, RPO 분~시간
 ↓  Backup & Restore          ← RTO 시간~일, RPO 시간
    ────────────────────────────────────────────────→
                    복구 속도 (빠름)

2. 4가지 DR 전략

전략 1: Backup & Restore

가장 단순하고 저렴한 전략. 정기 백업 → 장애 시 복원.

[평상시]
온프레미스 / 프라이머리 AWS
  → 주기적 백업 → S3 / Glacier

[장애 시]
S3 / Glacier에서 복원
  → EC2 재생성, RDS 스냅샷 복원, 설정 재적용

특성

• 비용: 가장 낮음 (백업 스토리지 비용만)
• RTO: 시간 ~ 일 (복원 시간에 따라)
• RPO: 백업 주기 (1일 백업이면 최대 24시간 손실)
• 복잡도: 낮음

주요 AWS 도구

• AWS Backup: 중앙에서 여러 서비스 백업 정책 관리
• S3 크로스 리전 복제: 백업 파일 다른 리전에 보존
• EBS 스냅샷 → AMI 생성: EC2 복원용

전략 2: Pilot Light

핵심 시스템만 DR 리전에서 최소 규모로 유지. 장애 시 확장.

[평상시]
프라이머리 리전: 전체 스택 운영
DR 리전: 핵심 DB만 복제 (EC2, 앱 서버는 없음)

[장애 시]
DR 리전:
  1. EC2·앱 서버 신규 생성 (AMI에서)
  2. DB는 이미 복제되어 있어 즉시 사용
  3. DNS 전환 (Route 53)

특성

• 비용: 낮음 (DB 인스턴스 + 소량 리소스만 상시 유지)
• RTO: 수십 분 ~ 수 시간 (EC2 생성 시간 포함)
• RPO: 분 단위 (DB 복제 주기에 따라)
• 복잡도: 중간

구현 패턴

프라이머리 리전 RDS
  → RDS 크로스 리전 읽기 복제본 (DR 리전)

프라이머리 리전 AMI
  → 크로스 리전 AMI 복사 (DR 리전에 준비)

장애 시:
  읽기 복제본 → 프라이머리 승격 (수 분)
  AMI → EC2 생성 (수 분)
  Route 53 → DR 엔드포인트로 전환

전략 3: Warm Standby

DR 리전에 축소된 전체 스택을 항상 실행. 장애 시 스케일 아웃.

[평상시]
프라이머리: 프로덕션 규모 (EC2 × 10, RDS Multi-AZ)
DR 리전:   최소 규모 (EC2 × 1, RDS 읽기 복제본)

[장애 시]
DR 리전:
  1. EC2 Auto Scaling → 프로덕션 규모로 확장
  2. RDS 읽기 복제본 → 프라이머리 승격
  3. Route 53 → DR 리전으로 DNS 전환

특성

• 비용: 중간 (항상 최소 인프라 운영)
• RTO: 분 단위 (스케일 아웃 시간)
• RPO: 분 ~ 초 단위 (DB 복제 지연)
• 복잡도: 중상

Pilot Light vs Warm Standby 차이

전략 4: Multi-Site Active-Active

두 리전이 동시에 트래픽을 처리. 한 리전 장애 시 나머지가 즉시 처리.

[평상시]
리전 A: 프로덕션 (50% 트래픽)
리전 B: 프로덕션 (50% 트래픽)
  → Route 53 가중치 기반 라우팅

[장애 시]
리전 A 장애
  → Route 53 Health Check 감지
    → 100% 트래픽을 리전 B로 자동 전환
      → 다운타임: 장애 탐지·라우팅·애플리케이션 상태에 따라 달라짐

특성

• 비용: 가장 높음 (두 리전 모두 프로덕션 규모)
• RTO: 매우 짧게 설계할 수 있으나 실제 장애 조치 시간으로 검증
• RPO: 복제 모델과 충돌 처리 방식에 따라 달라짐
• 복잡도: 높음 (데이터 동기화, 글로벌 일관성 문제)

데이터 동기화 과제

RDS: Aurora Global Database (리전 간 비동기 복제, 실제 지연 확인)
DynamoDB: 글로벌 테이블 (멀티 리전 액티브-액티브)
S3: 크로스 리전 복제 (CRR)
ElastiCache: 글로벌 데이터스토어 (Redis)

3. 서비스별 DR 구성

EC2

AMI를 크로스 리전 복사 → DR 리전에서 즉시 EC2 생성 가능
Auto Scaling 시작 구성 준비 → 장애 시 빠른 확장

RDS

SAP 핵심: 리전 수준 DR = Aurora Global Database / AZ 수준 = Multi-AZ

Aurora Global Database

프라이머리 리전 (읽기/쓰기)
  → 리전 간 비동기 복제, 실제 지연은 워크로드와 리전 상태에서 확인
    → 보조 리전 (읽기 전용, 최대 5개)

장애 시:
  보조 리전 → 프라이머리 승격 (절차·구성에 따른 복구 시간 측정)
  → 애플리케이션 엔드포인트 변경

DynamoDB 글로벌 테이블

리전 A (읽기/쓰기) ←→ 리전 B (읽기/쓰기)
  → 양방향 자동 복제 (수 초 이내)
  → 충돌 해결: 마지막 쓰기 승리 (Last Write Wins)

S3

크로스 리전 복제 (CRR):
  소스 버킷 (리전 A) → 자동 복제 → 대상 버킷 (리전 B)
  - 새 오브젝트 자동 복제
  - 삭제 마커 복제 옵션
  - 복제 시간 제어 (RTC): 99.99% 오브젝트를 15분 내 복제 보장

S3 버전 관리: 실수로 삭제·덮어쓴 데이터 복구

Route 53 장애 조치

프라이머리 레코드 (가중치 100)
  → Health Check 실패 감지 (10~30초)
    → 보조 레코드로 자동 전환

장애 조치 유형:
  Active-Passive: 프라이머리 → 보조 전환
  Active-Active:  가중치 기반 분산 + 장애 감지 시 제거

4. AWS Backup

핵심 개념

AWS Backup은 여러 서비스의 백업을 중앙에서 정책으로 관리한다.

백업 정책 (Backup Plan)
  → 백업 규칙: 매일 오전 2시, 30일 보존
  → 대상: EC2, EBS, RDS, Aurora, DynamoDB, EFS, FSx, S3, VMware

주요 기능

• 백업 볼트(Vault): 백업 저장소, 볼트 잠금으로 삭제 방지
• 크로스 리전 복사: 자동으로 다른 리전에 백업 복사
• 크로스 계정 복사: 다른 AWS 계정에 백업 보관 (랜섬웨어 대비)
• AWS Organizations 연동: 조직 전체 백업 정책 중앙 관리

Organizations 정책
  → 모든 계정 EBS, RDS 매일 자동 백업
  → 백업 완료 후 DR 계정으로 자동 복사

5. 재해 복구 설계 패턴

패턴 1: 비용 최적화 DR (Pilot Light)

프라이머리 리전 (서울)
  ├── EC2 Auto Scaling (앱 서버)
  ├── RDS Multi-AZ (MySQL)
  └── ALB

DR 리전 (도쿄) — 평상시 최소 비용
  ├── RDS 크로스 리전 읽기 복제본 (항상 동기화)
  └── AMI 복사본 (EC2 생성 준비)

장애 시:
  1. RDS 읽기 복제본 → 프라이머리 승격
  2. AMI → Auto Scaling 그룹 생성
  3. Route 53 → 도쿄 ALB로 전환
  → RTO: 30~60분 / RPO: 분 단위

패턴 2: 금융/의료급 DR (Active-Active)

리전 A (서울)                리전 B (도쿄)
  EC2 × 10                    EC2 × 10
  Aurora (프라이머리) ←→ Aurora Global DB (보조)
  DynamoDB 글로벌 테이블 ←→ DynamoDB 글로벌 테이블

Route 53 가중치 라우팅 (50:50)
  + Health Check → 장애 리전 자동 제외

  → 목표 RTO/RPO는 실제 장애 전환 훈련으로 검증

패턴 3: 백업 계층화

EBS 스냅샷 (매시간)   → 24시간 보존 (빠른 복원)
RDS 자동 백업 (매일)  → 35일 보존
S3 크로스 리전 복제   → 영구 보존 (Glacier)
AWS Backup 크로스 계정 → 격리된 DR 계정 보관

패턴 4: 데이터베이스 계층 DR

Aurora Global Database
  프라이머리 (서울): 읽기/쓰기
  보조 (도쿄):      읽기 전용

정상: 전체 트래픽 → 서울
장애: 도쿄 승격 (< 1분) → 앱 엔드포인트 재설정
      또는 관리형 페일오버 (자동)

6. 비즈니스 연속성을 위한 HA 설계

다중 AZ 고가용성

리전 내 AZ 장애 → Multi-AZ로 자동 복구

EC2: Auto Scaling 다중 AZ 배포
RDS: Multi-AZ (자동 장애 조치, 복구 결과와 데이터 손실 목표 시험)
ALB: 다중 AZ 자동 분산
ElastiCache: 클러스터 모드 + 다중 AZ

리전 간 재해 복구

리전 전체 장애 → DR 리전으로 복구

전략 선택:
  RPO/RTO 엄격 → Active-Active (비용 높음)
  RPO 분 / RTO 시간 → Pilot Light (비용 낮음)
  RPO 시간 / RTO 일 → Backup & Restore (최저 비용)

7. 핵심 암기 포인트

핵심 내용을 다시 정리하면

• RTO: 장애 후 복구까지 허용 시간 / RPO: 허용 가능한 데이터 손실 시점
• Backup & Restore: 저비용, 긴 RTO → 백업 스토리지만 유지
• Pilot Light: DB만 복제, 장애 시 앱 생성 → RTO 시간, RPO 분
• Warm Standby: 최소 규모 전체 스택 실행 → RTO 분, RPO 분
• Multi-Site: 두 리전 동시 운영, 목표 RTO·RPO는 복제 방식과 전환 훈련으로 확인
• Aurora Global DB: 리전 간 비동기 복제, 실제 복제 지연과 페일오버 시간 검증
• AWS Backup: 중앙 백업 정책, 크로스 계정으로 랜섬웨어 대비

이어 읽기: 16. 워크로드별 AWS 비용 최적화