[AWS SAA] End. 복구 전략

1. 백업 및 복원

대부분의 기존 환경에서는 데이터를 테이프에 백업하여 정기적으로 오프사이트로 전송합니다. 이 방법을 사용할 경우, 가동 중단 발생 시 시스템을 복원하는 데 많은 시간이 걸릴 수 있습니다.

 

S3는 백업에 빠르게 액세스할 수 있는 이상적인 대상 위치입니다. S3와 데이터를 주고받는 과정은 주로 네트워크를 통해 이뤄지므로 어떤 위치에서든 액세스가 가능합니다. 또한 수명 주기 정책을 사용하여 오래된 백업을 더 비용 효율적인 스토리지 클래스로 순차 이동할 수 있습니다.

 

기본적인 작동 방식은 다음과 같습니다.

1. 원격 서버 데이터가 S3의 한 공간(Ex_ /mybucket)에 백업됩니다.
2. 수명 정책에 따라 일정시간 S3에 보관됐다 이동합니다. [ S3 > S3 Standard-IA > S3 Glacier ]
3. 원격 서버에 장애가 발생하면 재해 복구 VPC를 배포해 서비스를 복원합니다.
   • CloudFormation을 사용해 주요 네트워킹 배포 자동화
   • 원격 서버와 일치하는 AMI를 사용해 EC2 인스턴스 생성
   • S3에서 백업을 검색해 시스템 복원
   • DNS 레코드를 AWS 가리키도록 조정

 

2. 파일럿 라이트

파일럿 라이트 접근 방식에서는 환경 간에 데이터를 복제하고 핵심 워크로드 인프라의 복사본을 프로비저닝합니다. 이 예에서는 프로덕션 웹 서버, 앱 서버 및 데이터베이스를 복구 환경에 복제합니다. Route 53은 모든 트래픽을 프로덕션 환경으로 라우팅합니다.

 

데이터 복제 및 백업을 지원하는 데 필요한 리소스(Ex_ DB, 객체 스토리지)는 상시 작동하고 있습니다. 애플리케이션 서버 등의 기타 요소는 애플리케이션 코드와 구성을 통해 로드되지만 꺼져 있으며 재해 복구 장애 조치 호출 시나 테스트 중에만 사용됩니다. 백업 및 복원 방식과는 달리 핵심 인프라는 항상 사용 가능합니다. 애플리케이션 서버를 가동하고 스케일 아웃하여 전체 규모 프로덕션 환경을 빠르게 프로비저닝할 수 있는 옵션이 항상 있습니다.

 

파일럿 라이트 아키텍처는 비교적 저렴하게 구현할 수 있습니다. 재해 복구의 준비 단계에서 데이터 마이그레이션과 영구 스토리지를 지원하는 서비스 및 기능의 사용을 고려한느 것이 중요합니다.

 

재해가 발생하면 복구 환경의 서버가 시작됩니다. 그러면 Route 53이 프로덕션 트래픽을 복구 환경으로 전송하기 시작합니다. 필수적인 인프라에는 DNS, 네트워킹 기능 및 다양한 EC2 기능이 포함됩니다.

 

 

3. 웜 스탠바이

웜 스탠바이 방식에서는 정상 작동하는 축소된 프로덕션 환경 사본을 복구 환경에 생성합니다. 비즈니스 크리티컬한 시스템을 확인한 후 AWS 상에 이러한 시스템을 모두 복제하고 상시 접속되도록 합니다. 따라서 복구 환경의 리소스가 시작될 때까지 기다리지 않아도 되므로 복구 시간이 단축됩니다.

 

 

이 예시에서는 웹 서버와 앱 서버를 Auto Scaling 그룹으로 복구 환경에 복제합니다. Auto Scaling 그룹은 실행 가능한 최소 수의 인스턴스와 가장 작은 EC2 인스턴스 크기를 실행할 수 있습니다. 이 솔루션은 최대 프로덕션 로드를 처리할 정도로 크기가 조정되지 않지만 기능은 온전하게 작동합니다. 이 솔루션은 최대 프로덕션 로드를 처리할 정도로 크기가 조정되진 않지만 기능은 온전하게 작동합니다. 이 솔루션은 테스트, 품질 보장 및 내부 사용 등 프로덕션 이외의 작업에 사용할 수 있습니다. Route 53을 사용해 프로덕션 환경과 복구 환경 간에 요청을 분산합니다. 그런 다음 복구 환경에 데이터베이슬르 복사하고 데이터 복제를 사용하여 해당 데이터 베이스를 최신 상태로 유지합니다.

 

위 다이어그램에서 프로덕션 환경과 복구 환경에서 실행중인 저용량 시스템이 있습니다. 복구 환경을 웜 스탠바이 상태로 유지하려면 모든 필수 구성 요소가 프로덕션 트래픽에 맞게 크기가 조정되지 않은 상태로 계속 실행돼야 합니다. 따라서 모범 사례에 따라 DR 사이트로 전송되는 프로덕션 트래픽의 하위 세트를 사용하여 지속적으로 테스트를 진행해야 합니다.

 

• 프로덕션 환경을 사용할 수 없으면 Route 53은 복구 환경으로 전환합니다. 프라이머리 시스템에서 장애가 발생하면 복구 환경은 자동으로 용량을 확장합니다. 
• 중요한 로드의 경우, 장애 발생 시 대기 영역의 워크로드를 중지하고, 주요 영역의 워크로드를 대기 영역으로 복제한 후 다시 시작합니다. 따라서 RTO는 장애 조치 소요 시간만큼만 소요됩니다.
• 나머지 로드의 경우, 장애 발생 시 대기 영역의 워크로드를 운영 수준으로 스케일 업합니다. 따라서 RTO는 스케일 업하는 데 걸리는 시간만큼 소요됩니다.
• 복제 유형은 데이터를 대기 영역으로 복제하는 방법을 의미합니다. 즉시 복제, 주기적 복제, 변경 사항만 복제 등의 방법이 있습니다. RPO는 복제 유형에 따라 달라지므로, 중요한 로드의 경우 즉시 복제, 나머지 로드의 경우 주기적 복제 또는 변경 사항만 복제하는 방법을 사용하는 것이 일반적입니다.

 

 

다중 사이트 액티브-액티브

액티브-액티브 구성에서는 다중 사이트 솔루션이 2개 환경에서 실행됩니다. 

위 예에서는 프로덕션 A 및 프로덕션 B 환경에서 웹 서버, 앱 서버, DB를 실행하여 프로덕션 트래픽을 처리합니다. Route 53은 두 환경 간에 트래픽을 라우팅합니다.

 

이 아키텍처는 잠재적으로 가동 중단 시간이 가장 짧습니다. 하지만 더 많은 환경이 실행되므로 비용도 더 많이 듭니다. Route 53과 같은 가중치 기반 라우팅을 지원하는 DNS 서비스를 사용하면 프로덕션 트래픽을 동일한 애플리케이션이나 서비스를 제공하는 다른 사이트로 라우팅할 수 있습니다.

 

A 환경에서 재해가 발생할 경우 DNS 가중치를 조정하여 B 환경으로 모든 트래픽을 전송할 수 있습니다. 또한, 최대 프로덕션 로드를 처리할 수 있도록 AWS 서비스 용량을 신속하게 증가시킬 수 있습니다. EC2 Auto Scaling을 사용하면 이 프로세스를 자동으로 실행할 수 있습니다. 프라이머리 DB 서비스의 장애를 감지하고 AWS에서 실행되는 병렬 DB 서비스로 이관되기 위해 몇 가지 애플리케이션 로직이 필요할 수 있습니다.

 

이 패턴은 잠재적으로 가동 중단 시간이 가장 짧습니다. 하지만 더 많은 시스템이 실행되므로 비용도 더 많이 듭니다. 이 시나리오의 비용은 정상 운영 중 AWS가 처리하는 프로덕션 트래픽의 양에 따라 결정됩니다. 복구 단계에서는 전체 재해 복구 환경이 필요한 기간 동안 트래픽을 실제로 사용한 만큼만 비용을 지불하면 됩니다. 비용을 더욱 줄이려면 상시 작동해야 하는 AWS 서버에 대해 EC2 예약 인스턴스를 구입하면 됩니다.

 

 

AWS에서 흔히 사용되는 DR 사례 비교

심각한 재해가 발생하더라도 비즈니스 연속성을 통해 중요한 비즈니스 기능이 계속 빠르게 작동하거나 복구됩니다. 애플리케이션은 복잡성의 스펙트럼에 배치할 수 있습니다.

 

위 그림은 재해 복구 이벤트가 발생한 후 얼마나 빨리 사용자에게 시스템을 사용 가능한 상태로 다시 제공할 수 있는지에 따라 4가지 시나리오로 분류한 스펙트럼입니다. 이 예시는 접근 방식 중 하나일 뿐으로 여러 다른 변형 및 조합도 가능합니다.

 

재해의 경우 파일럿 라이트와 웜 스탠바이 모두 데이터 손실을 제한하는 기능(RPO)을 제공합니다. 둘 다 가동 중단 시간을 제한할 수 있는 충분한 RTO 성능을 제공합니다. 두 전략 중에서 RTO 또는 비용 측면에서 최적화하는 선택을 하면 됩니다.