Disaster Recovery & Multi-region Architecture

1. Overview

재난 복구와 멀티 리전 아키텍처(Disaster Recovery & Multi-region Architecture)는 비행기가 데이터센터에 추락하거나 대지진으로 도시의 전력망이 마비되는 최악의 물리적 대재앙(Black Swan) 앞에서도, 비즈니스 데이터를 단 1바이트도 잃지 않고 서비스를 살려내는 인프라 공학의 최후 방어선입니다.

학습자는 단일 데이터센터 내부의 복제(HA)를 넘어, 수백 킬로미터 떨어진 전혀 다른 전력망과 네트워크 망을 쓰는 지리적 데이터센터 간의 복구 역량인 **RPO(목표 복구 시점)와 RTO(목표 복구 시간)**의 경제학적 트레이드오프를 해부합니다. 나아가 빙하 속에 테이프를 얼려두는 Cold Standby부터, 트래픽을 50<50으로> 나눠 0.1초 만에 살아남는 Active-Active 글로벌 아키텍처까지 재난 복구(DR)의 4단계를 뜯어봅니다. 마지막으로, 빛의 속도 한계 때문에 발생하는 지역 간 데이터 복제 지연(Replication Lag)과 스플릿 브레인 방어 전략을 통해 글로벌 멀티 리전 클라우드를 지배하는 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• RTO & RPO: Recovery Time Objective (시스템 복구까지 걸리는 시간), Recovery Point Objective (데이터 유실 허용 한계선).
• DR Strategies: Cold Standby (백업 테이프), Warm Standby, Hot Standby (Active-Passive), Multi-region (Active-Active).
• Data Synchronization: 동기 복제(Synchronous)의 거리 한계와 비동기 복제(Asynchronous)의 데이터 유실 트레이드오프.
• Failover Mechanisms: GSLB, DNS 라우팅 변경, 데이터베이스 마스터 승격(Promotion).

Out-of-Scope

• 클라우드 벤더 종속적 백업 솔루션 설정: AWS Backup, RDS Snapshot 버튼 클릭 방법 $\rightarrow$ 클라우드 매뉴얼 영역으로 위임 (본 문서는 벤더 중립적 아키텍처 원리에 집중).
• 해킹 및 랜섬웨어 방어: 암호학적 데이터 파괴 방어 $\rightarrow$ 10-01 InfoSec & Cryptography 영역.

Boundaries

• High Availability(HA) vs Disaster Recovery(DR): 랙(Rack) 하나가 고장 나서 옆의 랙에 있는 서버로 0.1초 만에 스위칭되는 것은 HA(고가용성)입니다. 하지만 해당 데이터센터에 화재가 나거나 통신사의 메인 광케이블이 끊어진다면 HA 장비 수천 대가 통째로 증발합니다. DR(재난 복구)은 "이 건물이 지도에서 사라졌을 때" 300km 떨어진 다른 건물(다른 리전)에서 시스템을 어떻게 다시 살려낼 것인가를 다루는, HA와는 차원이 다른 물리적/지리적 생존 철학임을 명확히 경계 짓습니다.

3. Counterexample

• 백업과 DR의 치명적 혼동 (The Backup Fallacy): "우리 회사는 매일 새벽 3시에 AWS S3에 전체 DB 스냅샷을 뜹니다. DR 완벽합니다!"라고 믿습니다. 서울 리전이 붕괴했습니다. 도쿄 리전에 새 서버를 할당받고, OS를 깔고, S3에서 수 테라바이트의 백업 파일을 다운받아 복원하는 데 이틀(48시간)이 걸렸습니다. 회사는 48시간의 서비스 중단으로 입은 신뢰 하락과 금전적 손실로 파산합니다. 백업(데이터 보관)과 DR(시스템 복구)은 완전히 다른 개념이며, RTO(목표 복구 시간) 설계를 간과한 안티 패턴입니다.
• 동기 복제(Sync)의 거리 무시: 재난 복구를 위해 서울 마스터 DB와 도쿄 슬레이브 DB를 동기식(Synchronous)으로 복제 묶었습니다. "도쿄에 데이터가 안전하게 기록(ACK)되기 전까진 서울 유저에게 '저장 완료'를 띄우지 않겠다"는 강한 일관성 결단입니다. 하지만 빛이 해저 케이블을 왕복하는 물리적 시간(약 50ms) 때문에, 평상시 서울 유저들의 모든 API 응답 속도가 50ms씩 무조건 느려지는 퍼포먼스 붕괴가 발생합니다. 빛의 속도라는 물리 법칙을 무시한 아키텍처 설계입니다.

4. Prerequisites

• GSLB 및 트래픽 라우팅 (Basic): DNS를 이용한 트래픽 우회. (07-03-03 Load Balancing)
• 데이터베이스 복제 (Basic): 마스터-슬레이브 데이터 복사 개념. (07-03-02 Replication)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 재난 복구의 경제학, RPO와 RTO (RPO & RTO Economics)

• Why to Learn: 무조건 "데이터 유실 0, 복구 시간 0"을 고집하는 것이 회사의 인프라 예산을 파산시키는 비현실적 목표임을 증명하고, 비즈니스 가치에 맞는 복구 스펙을 협상하기 위함입니다.
• What to Learn:
  • Concepts: RPO (Recovery Point Objective - 데이터 유실 허용 시점), RTO (Recovery Time Objective - 시스템 복구 소요 시간).
  • Skills: 비즈니스 도메인(예: 금융 vs 커뮤니티 게시판)별 RPO/RTO 임계치 설계.
• How to Learn:
  • 1단계: RPO (시간을 되돌리다): 새벽 3시에 백업했는데 오후 1시에 지진이 났습니다. 복구하면 10시간 치 데이터가 허공에 증발합니다. 회사가 "10시간 치 유실은 감당 못 해! 10분 치만 유실(RPO 10분)되어야 해"라고 한다면 10분마다 트랜잭션 로그를 원격지로 쏴야 하는 인프라 비용 폭발을 해부합니다.
  • 2단계: RTO (시간을 당기다): 지진 직후 시스템을 다시 살리는데 24시간이 걸립니다(RTO 24시간). 회사가 "1분 안에 살아나야 해(RTO 1분)!"라고 요구한다면, 평상시에도 똑같은 데이터센터를 원격지에 100% 켜두고 비용을 두 배로 내야 하는 무자비한 경제학을 뜯어봅니다.
• Implement: RPO/RTO 비용 계산기. 입력: RTO(1시간 vs 1일), RPO(0초 vs 1시간). 공식에 따라 인프라 예산(백업 스토리지, 상시 가동 대기 서버, 전용선)이 $y = 1/x$ 곡선을 그리며 기하급수적으로 폭등하는 콘솔 차트 출력.

Recommended

Core Topic 02: 복구의 4단계 스펙트럼 (The 4 Tiers of DR)

• Why to Learn: 스타트업부터 초거대 엔터프라이즈까지 자신들의 예산과 RTO에 맞춰 냉동 보관(Cold)부터 초가열 상태(Hot)까지 인프라 체급을 결정하기 위함입니다.
• What to Learn:
  • Concepts: Backup & Restore (Cold), Pilot Light (가스레인지 불씨), Warm Standby (준비된 백업), Multi-site Hot Standby (Active-Passive).
  • Skills: 예산 제약 내에서 가장 효율적인 DR Tier 아키텍처링.
• How to Learn:
  • 1단계: Pilot Light vs Warm Standby: 가스레인지 불씨(Pilot Light) 전략은 DB(불씨)만 원격지에 살려두고 웹 서버는 죽여둡니다. 재난이 터지면 그제야 웹 서버를 프로비저닝(점화)하여 RTO가 수십 분 걸립니다. 반면 Warm Standby는 웹 서버도 작게(스펙 축소) 켜두어 트래픽이 터지면 사이즈만 키우는(Scale-up) 방식으로 RTO를 수 분으로 단축시킵니다.
  • 2단계: Hot Standby (Active-Passive): 아예 메인 센터(Active)와 100% 똑같은 스펙의 센터(Passive)를 원격지에 켜둡니다. 트래픽은 0이지만 매달 수억 원의 서버비가 나갑니다. 하지만 재난 시 GSLB 스위치 하나만 누르면 단 5초 만에 복구(RTO $\approx$ 0)되는 금융권 최후 방어선을 뜯어봅니다.
• Implement: DR 전략별 장애 대응(Failover) 시뮬레이션 대시보드. 재난 버튼 클릭 시 1) Cold: 스크립트가 리눅스 패키지 설치부터 시작 (sleep 10초). 2) Hot: 이미 메모리에 대기 중인 인스턴스로 라우팅만 변경 (sleep 0.1초). RTO 시간 차이 체감 렌더링.

Practical

Core Topic 03: 궁극의 생존력, 글로벌 Active-Active (Multi-region Active-Active)

• Why to Learn: 절반의 인프라를 놀리는 Active-Passive의 엄청난 돈 낭비를 해결하고, 평상시에도 전 세계 유저에게 가장 빠른 응답 속도를 제공하는 넷플릭스급 최상위 아키텍처를 세우기 위함입니다.
• What to Learn:
  • Concepts: Active-Active Multi-region, GSLB Geo-routing, Split-brain 방어, 양방향(Bi-directional) 데이터 동기화 충돌.
  • Skills: 대륙별 트래픽 분산 라우팅 및 특정 리전 폭파 시 트래픽 재분배(Failover) 설계.
• How to Learn:
  • 1단계: 돈 낭비 멈춰!: 서울 센터(Active)와 도쿄 센터(Passive)가 있습니다. 도쿄의 1,000대 서버는 재난 전까지 그냥 놉니다. 이를 Active-Active로 바꿔 평상시 서울 유저는 서울 센터로, 일본 유저는 도쿄 센터로 라우팅(Geo-DNS)하여 속도와 자원 효율을 극대화하는 설계를 해부합니다.
  • 2단계: 지옥의 양방향 동기화: Active-Active의 끔찍한 단점. 서울에서 A 유저 정보가 수정되고, 동시에 도쿄에서 A 유저 정보가 수정되었습니다. 양쪽 DB 마스터가 서로 데이터를 교환하다가 "누구 데이터가 진짜야?" 하며 충돌(Conflict)이 나는 현상과, 이를 벡터 시계나 LWW로 타협하는 병합 지옥을 뜯어봅니다.
• Implement: Geo-Routing 및 Active-Active 장애 전가 스크립트. 정상 상태: KR 요청 $\rightarrow$ 서울(용량 100/100), JP 요청 $\rightarrow$ 도쿄(용량 100/100). 서울 파괴 시: GSLB가 KR 요청을 도쿄로 돌림. 도쿄 노드 부하가 200/100으로 폭발(Cascading Failure 위기)할 때 서버 오토스케일링이 작동해야 살아남는 아키텍처 로직 구현.

Advanced

Core Topic 04: 빛의 속도와 타협, 대륙 간 복제 역학 (The Speed of Light: Sync vs Async)

• Why to Learn: 대륙 간 데이터센터를 묶을 때 물리적 거리로 인해 발생하는 네트워크 지연(Latency)이 데이터 정합성(RPO 0)과 어플리케이션 성능 중 하나를 강제로 파괴하는 우주적 물리법칙을 장악하기 위함입니다.
• What to Learn:
  • Concepts: Synchronous Replication (동기 복제 - RPO 0), Asynchronous Replication (비동기 복제 - Performance 극대화), 빛의 속도 한계(Speed of light limit), Replication Lag.
  • Skills: 물리적 거리에 따른 왕복 시간(RTT) 계산 및 허용 가능한 RPO 베이스라인 타협.
• How to Learn:
  • 1단계: 빛의 한계(RTT): 서울과 뉴욕의 물리적 거리는 약 11,000km. 빛의 속도로 편도 36ms, 해저 광케이블 왕복(RTT) 실측은 약 150ms입니다. 아무리 천재 해커가 와도 서울에서 뉴욕 DB로 데이터를 동기 복제(ACK 대기)하는 데 최소 150ms가 걸리는 우주적 한계를 해부합니다.
  • 2단계: Performance vs Data Loss: 모든 글쓰기 API가 150ms 지연되는 끔찍한 UX(동기)를 감수하고 재난 시 데이터 유실률(RPO) 0을 가져갈 것인가? 아니면 0.1초 만에 응답(비동기)하고, 재난 시 날아가던 중이던 150ms 구간의 데이터 수천 건이 증발(RPO > 0)하는 것을 묵인할 것인가? 인프라 아키텍트의 최후의 결단을 뜯어봅니다.
• Implement: 대륙 간 복제 물리적 한계 모사. 입력: 두 리전 간의 거리(km). 출력: 빛의 속도($300,000\text{km/s}$)를 기반으로 최소 왕복 시간(RTT) 계산. 동기 복제 시 어플리케이션 Latency가 강제로 $+RTT$ 만큼 늦어짐을 경고하고, 비동기 선택 시 그 RTT 구간 안에서 발생할 수 있는 데이터 손실량(TPS $\times$ RTT)을 산출하는 치명적 룰 엔진 렌더링.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - System Reliability and Disaster Recovery
• [P5] SFIA - IT Management (ITMG) - Business Continuity Planning (BCP)

Secondary

• [Web Operations: Keeping the Data On Time] John Allspaw - Disaster Recovery and Backup
• [The Practice of Cloud System Administration] Thomas A. Limoncelli - Designing for Multi-Region

Industry

• [AWS Architecture Blog] - Disaster Recovery (DR) Architecture on AWS (Pilot Light, Warm Standby)
• [Netflix TechBlog] - Active-Active for Multi-Regional Resiliency

9. Final Checklist

Primary

• 목표 복구 시간(RTO)과 복구 시점(RPO)을 0(Zero)으로 설정하려 할 때, 왜 클라우드 인프라 유지 비용이 비선형적(기하급수적)으로 폭발하는지 경제학적 관점으로 증명할 수 있는가?
• 데이터센터 재난 시 인프라를 복구하는 전략 4단계 (Cold Backup $\rightarrow$ Pilot Light $\rightarrow$ Warm Standby $\rightarrow$ Hot Standby)의 체급별 속도 차이와 리소스 낭비율을 비교할 수 있는가?

Secondary

• 서울 리전과 미국 버지니아 리전을 묶어 글로벌 데이터베이스 동기(Synchronous) 복제를 걸었을 때, 빛의 속도 한계(Speed of light limit)로 인해 전체 API 응답 속도가 박살 나는 물리적 이유를 해부할 수 있는가?
• 비동기(Asynchronous) 복제를 채택하여 성능을 확보했을 때, 메인 데이터센터가 폭파된 순간 '복제 지연(Replication Lag)' 구간에 있던 수 초 분량의 데이터가 영구 유실(Data Loss)되는 역학을 논증할 수 있는가?

Industry

• 수백억의 인프라 비용 낭비를 막기 위해 Active-Passive 대신 양쪽 데이터센터를 모두 살리는 Active-Active 멀티 리전을 도입할 때, 양쪽에서 동시 쓰기가 발생해 빚어지는 DB 충돌(Conflict)을 어떻게 병합(Merge)할지 설계할 수 있는가?
• 대륙 간 GSLB 라우팅을 셋업한 상태에서 서울 데이터센터가 붕괴했을 때, DNS 캐시(TTL) 문제로 인해 일부 유저 트래픽이 최대 수 분 동안 계속 불타는 서울 서버로 꽂히는 DNS 맹점(Blackhole)을 아키텍처 관점으로 방어할 수 있는가?