05/10 — 가용성·전환·재해 복구
이 구간은 장애 범위, 검증된 전환, 복구 목표를 하나의 아키텍처로 연결한다.
1. 단순 정의
- 장애 도메인: 함께 영향을 받을 수 있는 범위다. 인스턴스, 가용 영역(AZ), 리전 순으로 범위가 커진다.
- 고가용성(HA): 구성 요소나 AZ 장애에도 서비스를 계속하도록 중복 배치와 상태 확인·우회·교체를 연결한 구조다.
- Cutover: 검증된 대상 환경으로 쓰기, 데이터 흐름, 사용자 트래픽을 넘기는 시점이다.
- RPO / RTO: RPO는 허용 데이터 손실 시간, RTO는 허용 서비스 복구 시간이다. 복구 목표 정의
- 복제 / 백업: 복제는 최신 사본을 준비하고, 백업은 과거 복구 지점을 보존한다. 각각 다른 복구 경계를 맡는다.
- DR 전략: Backup and Restore, Pilot Light, Warm Standby, Multi-site active-active는 평시 준비도·비용과 복구 속도를 조절하는 네 단계다. AWS DR 전략
2. 결정 축과 관계
첫 번째 축은 장애 범위다. 인스턴스 장애는 상태 확인·교체, AZ 장애는 여러 AZ의 용량·데이터 장애조치로 흡수한다. ALB 뒤의 stateless ASG를 여러 AZ에 두고 남은 AZ가 부하를 감당하게 하며, 상태는 관리형 저장소로 분리한다. 다중 AZ Auto Scaling DR 범위는 업무가 견뎌야 할 재해로 정하며, 리전 장애까지면 보조 리전을 준비한다.
RDS의 Multi-AZ DB instance는 기본 인스턴스와 동기식 대기 인스턴스로 자동 장애조치를 제공한다. Multi-AZ DB cluster는 writer와 두 개의 읽기 가능한 standby를 3개 AZ에 둔다. 읽기 확장이 중심이면 비동기 read replica가 맞고, 승격은 별도 전환 절차로 다룬다. RDS Multi-AZ
두 번째 축은 데이터 준비도와 복구 목표다. 짧은 RPO는 지속 복제나 더 촘촘한 복구 지점을, 짧은 RTO는 미리 가동된 컴퓨팅과 자동화된 승격·라우팅을 요구한다. 복제는 최신 사본의 가용성을 높이고, versioning·PITR·교차 리전 백업은 삭제나 손상 이전의 시점으로 돌아갈 경로를 만든다.
세 번째 축은 검증 가능한 전환이다. 대상 환경 준비 → 데이터 동기화 → 기능·데이터 검증 → 쓰기 정지와 변경분 추격 → 엔드포인트·트래픽 전환 → 관찰 → 복귀 창 뒤 원본 제거로 경계를 나눈다. 애플리케이션은 blue/green과 weighted routing으로 일부 트래픽부터 확인하고, 데이터베이스는 DMS full load와 CDC로 기존 데이터와 변경분을 옮긴 뒤 validation과 replication lag를 확인한다. DNS 가중치는 캐시의 영향을 받으므로 정확한 요청 비율보다는 점진적 전환 수단으로 이해한다. 가중치 라우팅, DMS CDC
네 번째 축은 평시 준비도다. Backup and Restore는 백업과 IaC를 준비해 사고 후 복원한다. Pilot Light는 핵심 데이터와 최소 기반을 계속 가동한다. Warm Standby는 축소된 완전 기능 환경을 가동하다가 확장한다. Multi-site active-active는 둘 이상의 리전이 평소에도 트래픽을 처리하며 가장 높은 비용과 데이터 일관성 설계를 동반한다.
마지막으로 복구 가능성은 연습으로 측정한다. 정기 restore·failover에서 데이터 사용 가능성, 기능, 실제 RPO와 RTO를 확인해야 백업과 절차가 복구 체계가 된다. 주기적 복원 테스트
3. 아키텍처 적용
사례 A — 리전 내 웹 서비스 HA
Route 53 → 여러 AZ의 ALB → stateless ASG로 구성하고, 상태는 RDS Multi-AZ와 공유 저장소에 둔다. ALB 상태 확인이 정상 대상으로만 보내고 ASG가 비정상 인스턴스를 교체한다. 백업과 PITR은 별도 복구 시점을 보존한다.
사례 B — 짧은 중단의 앱·DB 전환
IaC로 green 환경을 만들고 DMS full load+CDC와 validation을 수행한다. 짧게 쓰기를 멈춰 변경분을 따라잡은 뒤 엔드포인트를 전환하고, weighted routing으로 앱 트래픽을 늘린다. 관찰·복귀 창이 끝난 뒤 기존 환경을 제거한다.
사례 C — Warm Standby 리전 DR
주 리전은 Multi-AZ로 운영하고 복구 리전에는 축소된 완전 기능 환경과 복제된 데이터를 유지한다. 장애 선언 후 데이터 승격, 용량 확장, Route 53 failover, 기능 검증을 실행한다. 정기 훈련 결과로 실제 RPO·RTO를 확인한다.
4. 정답 구조
- 인스턴스·AZ 장애 중 서비스 지속 → 여러 AZ의 ALB + stateless ASG → 정상 대상 우회와 자동 교체
- RDS의 AZ 장애 자동 전환 → RDS Multi-AZ → 다중 AZ 배치와 관리형 failover
- 읽기 처리량 확장과 승격 가능한 사본 → read replica → 비동기 복제와 별도 승격 절차
- 낮은 평시 비용과 긴 복구 여유 → Backup and Restore + IaC → 사고 후 환경 재구축
- 핵심 상태만 상시 준비 → Pilot Light → 사고 후 나머지 계층 배포·확장
- 축소된 전체 환경 상시 운영 → Warm Standby → 용량 확장과 라우팅 전환
- 여러 리전이 평시 트래픽 처리 → Multi-site active-active → 가장 높은 준비도
- 새 환경을 소량부터 검증 → blue/green + weighted routing → 점진적 트래픽 전환
- DB를 짧은 중단으로 이전 → DMS full load + CDC + validation → 초기 적재와 변경분 동기화
- 복구 목표 달성 여부 확인 → 정기 restore·failover 훈련 → 실제 RPO·RTO 측정
5. 긍정형 암기표
| 요구사항의 중심 | 올바른 연결 |
|---|---|
| 인스턴스·AZ 장애 흡수 | 다중 AZ ALB + ASG |
| RDS 자동 장애조치 | Multi-AZ |
| 읽기 확장·별도 승격 | Read replica |
| 최신 상태의 다른 사본 | 지속 복제 |
| 과거 복구 지점 보존 | Backup·PITR·Versioning |
| 평시 비용 최소화 | Backup and Restore |
| 핵심 상태만 상시 가동 | Pilot Light |
| 축소된 완전 기능 환경 | Warm Standby |
| 두 리전이 평시 처리 | Multi-site active-active |
| 점진적 검증 후 전환 | Blue/green + weighted routing |
다음: 06/10 — 스토리지 선택과 수명 주기. 접근 모델, 공유 범위, 장애 범위, 성능·용량과 수명 주기를 연결한다.