AWS 재해 복구 전략
더 많은 작업
- AWS 재해 복구 전략; AWS 재해 복구; AWS Disaster Recovery
- AWS에서 워크로드를 리전 단위 장애나 데이터 손상에서 되살리기 위한 네 가지 대표 전략(백업 및 복원, 파일럿 라이트, 웜 스탠바이, 다중 사이트 액티브-액티브)과 이를 구현하는 AWS 서비스
재해 복구(DR)는 장애가 났을 때 얼마나 오래 멈춰도 되는가(RTO, 복구 시간 목표)와 데이터를 얼마나 잃어도 되는가(RPO, 복구 시점 목표)를 먼저 정하고, 그 목표를 가장 싼 비용으로 맞추는 설계다. AWS 백서 "Disaster Recovery of Workloads on AWS"와 Well-Architected 프레임워크 안정성 원칙은 전략을 네 가지로 나누며, 오른쪽으로 갈수록 RPO·RTO는 짧아지고 비용과 복잡도는 커진다. SAA 시험 가이드는 이 네 전략을 "백업 및 복원, 파일럿 라이트, 예열 대기 방식, 활성/활성 장애 조치"라고 적고 있다. 예열 대기 방식이 웜 스탠바이, 활성/활성 장애 조치가 다중 사이트 액티브-액티브다.
| 구분 | 고가용성(HA) | 재해 복구(DR) |
|---|---|---|
| 대상 | 워크로드의 구성 요소 장애(인스턴스, 가용 영역) | 워크로드 전체 사본을 잃는 큰 사건(리전 장애, 데이터 손상·삭제) |
| 대표 구현 | 다중 AZ 배포, ELB, Auto Scaling, RDS 다중 AZ | 다른 리전으로 백업·복제, 복구 리전 인프라 |
| 데이터 관점 | 동기·연속 복제로 다른 위치에 즉시 반영 | 연속 복제에 더해 특정 시점 백업 필요. 삭제나 손상도 복제되기 때문 |
다중 AZ는 가용 영역 하나의 장애를 견디는 고가용성 장치이고, 리전 전체 장애나 규제상 원격지 복구 요구는 다중 리전 DR로 대응한다. 백서도 데이터 센터 하나의 손실만 대비하면 되는, 잘 설계된 고가용성 워크로드라면 백업 및 복원만으로 충분할 수 있다고 설명한다.
RPO·RTO 수준은 AWS Well-Architected 안정성 원칙(REL13-BP02)의 기준이다.
| 구분 | 백업 및 복원 | 파일럿 라이트 | 웜 스탠바이 | 다중 사이트 액티브-액티브 |
|---|---|---|---|---|
| RPO | 시간 단위 | 분 단위 | 초 단위 | 거의 0 |
| RTO | 24시간 이하 | 수십 분 | 분 단위 | 0에 가까울 수 있음 |
| 복구 리전 상태 | 백업만 있음, 인프라는 복구 시 생성 | 데이터 저장소는 항상 켜져 있고 복제 중, 애플리케이션 서버는 꺼져 있거나 배포 안 됨 | 축소된 규모로 전체 스택이 항상 실행 | 모든 리전이 전체 규모로 실제 트래픽 처리 |
| 장애 시 할 일 | 인프라 배포 → 데이터 복원 → 트래픽 전환 | 서버 켜기·배포 → 확장 → 트래픽 전환 | 확장 → 트래픽 전환 | 장애 리전에서 트래픽만 빼면 됨 |
| 비용 | 가장 낮음 | 낮음 | 중간 | 가장 높음 |
| 대표 AWS 구현 | AWS Backup(교차 리전 복사), EBS·RDS 스냅샷, AMI 복사, CloudFormation | Aurora 글로벌 데이터베이스, RDS 교차 리전 읽기 전용 복제본, S3 교차 리전 복제, DynamoDB 글로벌 테이블 | 파일럿 라이트 구성 + 최소 규모 EC2 Auto Scaling 그룹, Route 53 장애 조치 | DynamoDB 글로벌 테이블, Aurora 글로벌 데이터베이스(쓰기 전달), Route 53·Global Accelerator 트래픽 분산 |
- 데이터를 정기적으로 또는 연속으로 백업하고 다른 리전·계정으로 복사해 둔다. AWS Backup은 EBS, EC2, RDS·Aurora, DynamoDB, EFS, FSx, Storage Gateway 볼륨 백업을 한곳에서 일정·보존 관리하고 교차 리전·교차 계정 복사를 지원한다.
- 데이터만으로는 복구가 안 된다. 인프라와 설정도 AWS CloudFormation 같은 코드형 인프라로 정의하고 AMI를 복구 리전에 복사해 둬야 RTO를 지킬 수 있다.
- S3는 버전 관리를 켜 두면 실수로 지우거나 덮어쓴 객체를 되살릴 수 있다. 교차 리전 복제(CRR)는 연속 복제라 백업 시점이 거의 0에 가깝지만, 손상·악의적 삭제까지 막아 주지는 않으므로 시점 백업과 함께 쓴다.
- 백업은 반드시 복원 테스트를 한다.
- 데이터베이스와 객체 저장소처럼 데이터를 담는 핵심 부분만 복구 리전에서 항상 켜 두고 복제를 유지한다. 애플리케이션 서버는 꺼 두거나 아예 배포하지 않고, 필요할 때 켤 수 있도록 템플릿과 AMI만 준비한다.
- 데이터 연속 복제 수단: S3 복제, RDS 교차 리전 읽기 전용 복제본, Aurora 글로벌 데이터베이스, DynamoDB 글로벌 테이블, DocumentDB 글로벌 클러스터, ElastiCache 글로벌 데이터 스토어.
- Aurora 글로벌 데이터베이스는 보통 1초 미만의 지연으로 보조 리전에 복제하고, 리전 전체 장애 시에도 보조 리전을 1분 안에 읽기·쓰기 클러스터로 승격할 수 있다. RDS 읽기 전용 복제본(Aurora 외) 승격은 재부팅을 포함해 몇 분이 걸린다.
- 장애 시 서버를 켜고 Auto Scaling으로 운영 규모까지 늘린 뒤 트래픽을 넘긴다. 복구 리전의 서비스 할당량(Service Quotas)이 운영 규모를 감당하도록 미리 올려 두어야 한다.
- 복구 리전에 축소된 규모지만 완전히 동작하는 운영 환경 사본을 항상 실행한다. 파일럿 라이트와의 차이는 추가 조치 없이도 바로 요청을 처리할 수 있느냐다. 파일럿 라이트는 서버를 켜야 하고, 웜 스탠바이는 확장만 하면 된다.
- 항상 동작하므로 지속적인 테스트가 쉽다.
- 복구 리전에 운영 규모 전체를 미리 띄워 두고 트래픽만 보내지 않는 방식은 핫 스탠바이라고 하며, Auto Scaling(제어 영역 작업)에 기대지 않아 더 안정적이지만 비용이 크다.
- 여러 리전이 동시에 실제 트래픽을 처리한다. 장애 조치라는 개념이 거의 없고, 장애 리전으로 가는 트래픽을 빼면 된다.
- 읽기는 가까운 리전에서 처리하고(read local), 쓰기는 설계에 따라 나눈다.
- 쓰기 전역(write global): 쓰기를 한 리전으로 모은다. Aurora 글로벌 데이터베이스와 쓰기 전달이 맞다.
- 쓰기 로컬(write local): 가까운 리전에 쓴다. DynamoDB 글로벌 테이블이 맞으며 동시 수정은 마지막 쓰기 우선으로 정리된다.
- 쓰기 분할(write partitioned): 사용자 ID 같은 키로 쓰기 리전을 정해 충돌을 피한다.
- 데이터 손상이나 삭제는 모든 리전에 복제되므로, 이 전략에서도 시점 백업이 필요하다.
| 서비스 | 방식 |
|---|---|
| 아마존 Route 53 | 상태 확인과 장애 조치 라우팅으로 정상 엔드포인트에만 DNS 응답. 가중치·지연 시간·지리 근접성 정책으로 액티브-액티브 분산 |
| 아마존 Application Recovery Controller(ARC) | 수동 전환을 데이터 영역 스위치로 안정적으로 실행 |
| AWS Global Accelerator | 고정 애니캐스트 IP 뒤의 여러 리전 엔드포인트를 상태 확인으로 전환. DNS 캐시 문제가 없고 트래픽 다이얼로 비율 조절 |
| 아마존 CloudFront | 오리진 장애 조치(요청 단위로 보조 오리진 사용) |
장애 조치에는 가능한 한 제어 영역(리소스 생성·설정 변경)보다 가용성 목표가 높은 데이터 영역 작업을 쓰라는 것이 백서의 권고다.
AWS Elastic Disaster Recovery(AWS DRS)는 온프레미스, 다른 클라우드, AWS의 서버를 블록 수준으로 계속 복제해 복구 리전의 스테이징 영역 서브넷에 저렴한 저장소와 최소한의 컴퓨팅으로 유지한다. 장애나 훈련 시 복구 인스턴스를 몇 분 안에 띄우며, 최신 상태나 이전 시점을 골라 복구할 수 있다. Well-Architected 안정성 원칙은 DRS가 파일럿 라이트 수준의 비용으로 웜 스탠바이에 가까운 목표(초 단위 RPO, 분 단위 RTO)를 낼 수 있다고 설명한다. EC2에서 실행하는 애플리케이션과 DB가 대상이며, RDS 같은 관리형 DB는 각 서비스의 복제 기능을 쓴다. 복구 후에는 원래 위치로 되돌리는 페일백도 지원한다.
- 요구 RPO·RTO와 "가장 비용 효율적"이라는 단서를 함께 보고 네 전략 중 목표를 만족하는 가장 싼 것을 고른다. 몇 시간의 다운타임을 허용하면 백업 및 복원, 수십 분이면 파일럿 라이트, 몇 분이면 웜 스탠바이, 0에 가까우면 액티브-액티브다.
- 파일럿 라이트와 웜 스탠바이 구분: 복구 리전에서 애플리케이션이 이미 돌아가며 요청을 처리할 수 있으면 웜 스탠바이다.
- "온프레미스 서버를 AWS로 DR, 비용 최소, 몇 분 내 복구"는 AWS Elastic Disaster Recovery다.
- "글로벌 사용자, 여러 리전에서 읽기·쓰기"는 DynamoDB 글로벌 테이블, "관계형 DB의 리전 간 DR, 1분 내 승격"은 Aurora 글로벌 데이터베이스다.
- 다중 AZ는 HA이지 리전 DR이 아니다. 리전 장애 대비 문제에서 다중 AZ만 고르는 보기는 오답이다.
- 연속 복제만으로는 랜섬웨어·실수 삭제를 막지 못하므로 시점 백업(AWS Backup, 버전 관리)을 함께 쓴다.