SAA-C03에서 고가용성과 재해 복구(DR) 전략은 전체 출제 비중의 약 20%를 차지하는 핵심 영역입니다. 시스템 장애는 반드시 일어납니다. 중요한 것은 "장애가 생겼을 때 얼마나 빨리, 얼마나 적은 데이터 손실로 복구할 수 있는가"입니다.
RPO와 RTO — 재해 복구의 두 축
재해 복구 전략을 이해하려면 두 가지 개념을 먼저 잡아야 합니다.
일기장 비유로 생각해 보겠습니다. 여러분이 매일 일기를 씁니다. 그런데 오늘 갑자기 일기장이 불에 탔습니다.
RPO (Recovery Point Objective) — 데이터 손실 허용 범위: 어제 사본을 만들어 두었다면 오늘치 일기만 잃습니다. 1주일 전 사본밖에 없다면 7일치를 잃습니다. RPO는 "최대 얼마치 데이터를 잃어도 괜찮은가?"입니다. RPO가 낮을수록 더 자주 백업해야 합니다.
RTO (Recovery Time Objective) — 복구 시간 목표: 일기장이 탔을 때, 새 일기장을 사러 가는 데 1시간이 걸리면 RTO는 1시간입니다. RTO는 "시스템이 다운된 후 몇 시간 안에 다시 돌아와야 하는가?"입니다. RTO가 낮을수록 항상 켜져 있을 준비가 된 대기 시스템이 필요합니다.
핵심 원칙: RPO와 RTO가 낮을수록 더 많은 인프라가 필요하고 비용이 증가합니다.
4가지 DR 전략 — 보험 정책 비유
4가지 재해 복구 전략을 보험 정책에 비유하면 이해하기 쉽습니다. 보험료(비용)가 올라갈수록 보장 범위(복구 속도)가 넓어집니다.
백업 및 복원 (Backup and Restore) — 기본 화재보험
가장 저렴한 전략입니다. 정기적으로 데이터를 백업해 두고, 장애가 생기면 처음부터 복원합니다.
화재 보험에 비유하면: 집이 불타면 보험금을 받아 새 집을 짓습니다. 비용은 적지만, 새 집이 완성될 때까지 몇 달이 걸릴 수 있습니다.
RPO: 높음 (마지막 백업 이후의 모든 데이터 손실) RTO: 높음 (수 시간 ~ 수십 시간) 비용: 가장 저렴 사용 사례: 비즈니스 크리티컬하지 않은 시스템, 개발/테스트 환경
파일럿 라이트 (Pilot Light) — 항상 켜둔 최소 불씨
핵심 인프라(데이터베이스 등)만 최소 사양으로 항상 가동하고, 나머지(웹 서버, 앱 서버)는 꺼둡니다. 장애 발생 시 나머지를 빠르게 켭니다.
가스레인지 비유: 요리를 시작하려면 점화용 불씨(파일럿 라이트)만 항상 켜 두면 됩니다. 가스를 틀면 순식간에 큰 불이 됩니다.
RPO: 중간 (DB는 실시간 복제 중이므로 데이터 손실 최소) RTO: 중간 (수십 분) 비용: 중저 사용 사례: 중요 DB는 보호하되 전체 인프라 비용은 줄이고 싶을 때
웜 스탠바이 (Warm Standby) — 항상 대기 중인 축소판 팀
전체 시스템의 축소 버전이 항상 가동 중입니다. 장애 발생 시 스케일업하면 됩니다.
보험 비유: 화재가 나면 즉시 입주할 수 있는 작은 임시 거처가 항상 준비된 상태입니다. 가구는 조금 부족하지만 지내는 데는 문제없습니다.
RPO: 낮음 RTO: 낮음 (수 분) 비용: 중고 사용 사례: 중요한 비즈니스 시스템, 어느 정도의 다운타임은 허용
액티브-액티브 (Active-Active) — 완전히 운영되는 두 개의 사무소
두 리전에서 동시에 전체 트래픽을 처리합니다. 하나가 완전히 다운되어도 다른 하나가 즉시 모든 트래픽을 받습니다.
보험 비유: 서울과 부산에 동일한 직원과 장비를 갖춘 두 개의 사무소가 동시에 운영 중입니다. 한 사무소가 문을 닫아도 고객은 차이를 느끼지 못합니다.
RPO: 거의 0 RTO: 거의 0 (수 초) 비용: 가장 비쌈 (동일한 인프라를 두 배로 운영) 사용 사례: 금융, 의료, 전자상거래처럼 단 1분의 다운타임도 허용 안 되는 시스템
!재해 복구 전략 4가지 비교
서비스별 고가용성 패턴
각 AWS 서비스가 어떻게 고가용성을 구현하는지 이해하면, 시험에서 "어떤 서비스를 써야 하는가" 문제를 빠르게 풀 수 있습니다.
EC2 고가용성
여러 가용 영역(AZ)에 인스턴스를 분산시키고, Auto Scaling Group과 Application Load Balancer(ALB)를 결합합니다.
멀티 AZ + Auto Scaling + ALB: EC2 고가용성의 기본 3종 세트 하나의 AZ가 다운되면 트래픽이 자동으로 다른 AZ의 인스턴스로 이동
RDS 멀티 AZ
RDS 멀티 AZ는 주 인스턴스와 동기 복제된 대기 인스턴스를 다른 AZ에 유지합니다.
동기 복제(Synchronous Replication): 모든 쓰기가 즉시 대기 인스턴스에도 반영 자동 페일오버: 주 인스턴스 장애 시 수 분 내에 대기 인스턴스가 자동 승격 읽기 성능 향상이 아닌 고가용성 목적 — 읽기 분산은 Read Replica 사용
Aurora 글로벌 데이터베이스
Aurora는 기본적으로 3개 가용 영역에 6개 데이터 사본을 유지합니다. Aurora Global Database를 사용하면 여러 리전에 걸쳐 복제할 수 있으며, 보조 리전은 1초 미만의 지연 시간으로 복제됩니다.
DynamoDB 글로벌 테이블
여러 리전에서 동시에 읽기와 쓰기가 가능한 완전 관리형 멀티 리전 데이터베이스입니다. 액티브-액티브 패턴의 대표적인 사례입니다.
S3 내구성
S3는 11개의 9(99.999999999%)의 내구성을 제공합니다. 데이터는 자동으로 멀티 AZ에 복제됩니다. 추가로 S3 Cross-Region Replication(CRR)을 설정하면 다른 리전에도 복제됩니다.
Route 53 라우팅 정책 — 트래픽 지능형 분배
Route 53는 단순한 DNS를 넘어 지능적인 트래픽 라우팅을 제공합니다.
| 정책 | 언제 쓰는가 | 시험 키워드 | |------|-----------|-----------| | Failover | 주 서버 장애 시 자동으로 백업으로 전환 | "자동 전환", "DR 라우팅" | | Latency | 가장 지연 시간이 낮은 리전으로 보냄 | "가장 빠른 응답", "지연 최소화" | | Weighted | 트래픽을 비율로 분배 (예: 90/10) | "카나리 배포", "A/B 테스트" | | Geolocation | 사용자 위치 기반으로 라우팅 | "특정 국가 사용자", "지역 규정 준수" | | Geoproximity | 지리적 거리 기반, 편향값 조정 가능 | "특정 리전으로 트래픽 더 많이" |
Failover 라우팅은 Health Check와 결합하여 사용합니다. 주 엔드포인트가 Health Check에 실패하면 Route 53이 자동으로 보조 엔드포인트로 트래픽을 전환합니다.
시험 핵심 정리
"가장 저렴한 DR 전략" -- 백업 및 복원 (Backup and Restore)
"핵심 DB만 최소 가동, 장애 시 나머지를 빠르게 켬" -- 파일럿 라이트 (Pilot Light)