OPEN HYPER STEP
← 목록으로 (stack-analysis)
STACK-ANALYSIS · 118 / 120
stack-analysis
CHAPTER 118 / 120
읽기 약 2
FUNCTION

멀티 리전 배포와 재해 복구


핵심 개념

multi-region·active-active vs active-passive·DR 절차 — 가용성 99.99%.

본문

가용성 목표

📋 코드 (11줄)
| 가용성 | 다운타임/년 |
|---|---|
| 99% | 3.65일 |
| 99.9% | 8.76시간 |
| 99.99% | 52.6분 |
| 99.999% | 5.26분 |


→ 99.9% 달성: 단일 리전 + 자동 복구
→ 99.99%: 멀티 리전 + 자동 페일오버
→ 99.999%: 멀티 리전 active-active + 다중 클라우드

멀티 리전 패턴

📋 코드 (25줄)
[Active-Passive] (가장 일반적)
- Primary 리전 활성
- Secondary 리전 standby
- 장애 시 페일오버
- RPO: 1~5분, RTO: 5~30분

[Active-Active]
- 두 리전 동시 활성
- 트래픽 분산
- 복잡도 매우 높음
- RPO: 0초, RTO: 0초


[Pilot Light]
- Secondary는 최소 구성만
- 장애 시 수동 확장
- 저렴
- RTO: 1~4시간


[Backup & Restore]
- 백업만
- 장애 시 처음부터
- 가장 저렴
- RTO: 24시간+

데이터 동기화

📋 코드 (15줄)
[비동기 Replication]
- PostgreSQL Streaming Replication
- 1~5초 lag
- 최종 일관성

[동기 Replication]
- 매 트랜잭션 양 리전 commit
- 0초 lag
- 쓰기 latency 큼

[Multi-Region DB]
- AWS Aurora Global Database
- Google Spanner
- CockroachDB
- 자동 동기화

DNS 페일오버

📋 코드 (24줄)
[Route 53 Failover]
- Primary 헬스 체크
- 실패 시 Secondary로 자동 전환
- TTL 60초 (캐시 빠른 만료)

[Cloudflare Load Balancing]
- 글로벌 anycast
- 자동 페일오버
- 지역 라우팅


# Route 53 정책
Primary record:
- Name: api.example.com
- Type: A
- Set ID: primary
- Health Check: ID-1
- Failover: PRIMARY

Secondary record:
- Name: api.example.com
- Type: A
- Set ID: secondary
- Failover: SECONDARY

DR 절차 (Disaster Recovery)

📋 코드 (28줄)
[감지]
1. 모니터링 알림 (Datadog·Sentry)
2. Severity 분류
3. 페이저 호출 (PagerDuty)


[격리]
1. 트래픽 제외 (LB에서 제거)
2. 영향 평가 (사용자·데이터)
3. 통보 (Status Page)


[복구]
1. 옵션 A: 빠른 패치 (10~30분)
2. 옵션 B: 롤백 (5~15분)
3. 옵션 C: 페일오버 (30~60분)


[검증]
1. 핵심 흐름 테스트
2. 모니터링 정상 확인
3. 트래픽 점진 복구


[사후]
1. Post-mortem (24시간 내)
2. 재발 방지
3. Runbook 업데이트

백업 전략

📋 코드 (21줄)
[3-2-1 룰]
- 3 copies (1 primary + 2 backup)
- 2 different media (디스크·테이프·클라우드)
- 1 off-site (다른 지역)


[자동 백업]
- RDS: 매일 자동 + PITR (5분 단위)
- 보존 기간 7~35일

[Cross-Region]
aws rds copy-db-snapshot \
  --source-db-snapshot-identifier arn:aws:rds:ap-northeast-2:... \
  --target-db-snapshot-identifier my-snapshot-tokyo \
  --kms-key-id ...


[정기 복구 테스트]
- 분기 1회 — 새 인스턴스에 복구
- 데이터 무결성 검증
- 시간 측정 (RTO)

Status Page

📋 코드 (22줄)
[목적]
- 사용자에게 투명한 상태 전달
- 지원 부담 감소

[도구]
- Statuspage (Atlassian)
- Better Stack
- Hyperping
- 자체 구축


[자동화]
- Heartbeat 모니터링 → 자동 incident
- Slack 통합
- 이메일·SMS 구독


예: status.example.com
- API: ✅ Operational
- Web: ⚠️ Degraded performance
- Database: ✅ Operational
- 진행 중 incident: "API latency higher than normal" (50% complete)

비용 vs 가용성

📋 코드 (17줄)
99.9% 단일 리전:
- 1 region × 3 AZ
- $200~500/mo (소규모)

99.99% 멀티 리전 active-passive:
- 2 region × 3 AZ
- 1.5x 비용 ($300~750)

99.999% multi-region active-active:
- 3 region
- 3x 비용 ($600~1500)
- + 운영 복잡도


→ 99.9%로 시작 (대부분 충분)
→ 매출·SLA 영향 시 99.99%
→ 99.999%는 금융·핵심 인프라만

다음 챕터

CH.119 "기술 부채 관리: 리팩토링 전략".


AI 프롬프트
🤖 AI에게 잘 물어보는 법 — 모델·전략별 프롬프트
Claude

무료: Sonnet 4.6 / Pro $20/mo: Opus 4.6

내 코드의 멀티 리전 DR 부분을 분석해서
실전 분석 + 개선 우선순위를 알려줘.
ChatGPT

무료: GPT-5.5 / Plus $20/mo: GPT-5.5 Pro

멀티 리전 DR 관련 베스트 프랙티스 5가지를
비교 분석해서 패턴 추출를 알려줘.
Gemini

무료: 2.5 Flash / Pro $19.99/mo: 3.1 Pro

내 프로젝트 전체에서 멀티 리전 DR
최적화 가능 위치를 보고해줘.
Grok

무료: Grok 4.1 / SuperGrok $30/mo

2026년 한국 시장의 멀티 리전 DR
트렌드를 솔직히 알려줘.

⭐ 이것만 기억하세요
멀티 리전 배포와 재해 복구 이 3가지만 확실히 잡으세요
1.99.9% (단일 리전) → 99.99% (멀티 리전 active-passive) → 99.999% (active-active)
2.3-2-1 백업 + 분기 복구 테스트 = 진짜 안전
3.DR Runbook + Status Page = 사고 시 빠른 대응


공유하기
진행도 118 / 120