기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

클라우드의 재해 복구 옵션

AWS 내에서 사용할 수 있는 재해 복구 전략은 백업을 만드는 데 드는 저렴한 비용과 복잡성부터 여러 활성 리전을 사용하는 보다 복잡한 전략에 이르기까지 크게 네 가지 접근 방식으로 분류할 수 있습니다. 액티브/패시브 전략은 액티브 사이트(예: AWS 리전)를 사용하여 워크로드를 호스팅하고 트래픽을 처리합니다. 패시브 사이트(예: 다른 AWS 리전)가 복구에 사용됩니다. 패시브 사이트는 장애 조치 이벤트가 트리거될 때까지 트래픽을 능동적으로 처리하지 않습니다.

재해 복구 전략이 필요한 경우 이를 호출하는 데 확신을 가질 수 있도록 재해 복구 전략을 정기적으로 평가하고 테스트하는 것이 중요합니다. AWS Resilience Hub를 사용하여 RTO 및 RPO 목표를 충족할 가능성이 있는지 여부를 포함하여 AWS 워크로드의 복원력을 지속적으로 검증하고 추적할 수 있습니다.

그림 6 - 재해 복구 전략

잘 설계된 고가용성 워크로드에 대한 물리적 데이터 센터 하나의 중단 또는 손실로 인한 재해 이벤트의 경우 재해 복구에 대한 백업 및 복원 접근 방식만 필요할 수 있습니다. 재해 정의가 물리적 데이터 센터의 중단 또는 손실을 넘어 리전의 중단 또는 손실을 넘어가거나 이를 요구하는 규제 요구 사항이 적용되는 경우 파일럿 라이트, 웜 스탠바이 또는 다중 사이트 액티브/액티브를 고려해야 합니다.

전략과 이를 구현할 AWS 리소스를 선택할 때 AWS 내에서 일반적으로 서비스를 데이터 영역과 제어 영역으로 나눕니다. 데이터 영역에서는 실시간 서비스를 제공하고, 컨트롤 플레인은 환경을 구성하는 데 사용됩니다. 복원력을 극대화하려면 장애 조치 작업의 일부로 데이터 영역 작업만 사용해야 합니다. 이는 일반적으로 데이터 플레인의 가용성 설계 목표가 컨트롤 플레인보다 높기 때문입니다.

백업 및 복원

백업 및 복원은 데이터 손실 또는 손상을 완화하는 데 적합한 접근 방식입니다. 또한이 접근 방식은 다른 AWS 리전으로 데이터를 복제하여 리전 재해를 완화하거나 단일 가용 영역에 배포된 워크로드의 중복성 부족을 완화하는 데 사용할 수 있습니다. 데이터 외에도 복구 리전에서 인프라, 구성 및 애플리케이션 코드를 재배포해야 합니다. 인프라가 오류 없이 빠르게 재배포되도록 하려면 항상 AWS CloudFormation 또는와 같은 서비스를 사용하여 코드형 인프라(IaC)를 사용하여 배포해야 합니다AWS Cloud Development Kit (AWS CDK). IaC가 없으면 복구 리전에서 워크로드를 복원하는 것이 복잡하여 복구 시간이 늘어나고 RTO를 초과할 수 있습니다. 사용자 데이터 외에도 Amazon EC2 인스턴스를 생성하는 데 사용하는 Amazon Machine Image(AMIs 포함하여 코드와 구성도 백업해야 합니다. Amazon EC2 AWS CodePipeline를 사용하여 애플리케이션 코드 및 구성의 재배포를 자동화할 수 있습니다.

그림 7 - 백업 및 복원 아키텍처

서비스

워크로드 데이터에는 주기적으로 실행되거나 지속적인 백업 전략이 필요합니다. 백업을 실행하는 빈도에 따라 달성 가능한 복구 시점(RPO에 맞게 조정되어야 함)이 결정됩니다. 또한 백업은 백업이 수행된 시점으로 복원할 수 있는 방법을 제공해야 합니다. point-in-time으로 복구를 통한 백업은 다음 서비스 및 리소스를 통해 사용할 수 있습니다.

Amazon Simple Storage Service(Amazon S3)의 경우 복원 지점을 선택할 수 있도록 Amazon Amazon S3 교차 리전 복제(CRR)를 사용하여 객체를 지속적으로 DR 리전의 S3 버킷에 비동기식으로 복사하는 동시에 저장된 객체에 대한 버전 관리를 제공할 수 있습니다. 데이터의 지속적 복제는 데이터를 백업하는 데 가장 짧은 시간(0에 가까움)이라는 이점이 있지만 데이터 손상 또는 악의적인 공격(예: 무단 데이터 삭제)과 point-in-time 백업과 같은 재해 이벤트로부터 보호하지 못할 수 있습니다. 지속적 복제는 AWS Services for Pilot Light 섹션에서 다룹니다.

AWS Backup는 다음 서비스 및 리소스에 대한 AWS 백업 기능을 구성, 예약 및 모니터링할 수 있는 중앙 위치를 제공합니다.

AWS Backup 는 재해 복구 리전과 같은 리전 간에 백업 복사를 지원합니다.

Amazon S3 데이터에 대한 추가 재해 복구 전략으로 S3 객체 버전 관리를 활성화합니다. 객체 버전 관리는 작업 전에 원래 버전을 유지하여 삭제 또는 수정 작업의 결과로부터 S3의 데이터를 보호합니다. 객체 버전 관리는 인적 오류 유형 재해를 완화하는 데 유용할 수 있습니다. S3 복제를 사용하여 데이터를 DR 리전에 백업하는 경우 기본적으로 소스 버킷에서 객체가 삭제되면 Amazon S3는 소스 버킷에만 삭제 마커를 추가합니다. 이 접근 방식은 DR 리전의 데이터를 소스 리전의 악의적인 삭제로부터 보호합니다.

데이터 외에도 워크로드를 재배포하고 복구 시간 목표(RTO)를 충족하는 데 필요한 구성과 인프라도 백업해야 합니다. AWS CloudFormation는 코드형 인프라(IaC)를 제공하며 워크로드의 모든 AWS 리소스를 정의할 수 있으므로 여러 AWS 계정 및 AWS 리전에 안정적으로 배포하고 재배포할 수 있습니다. 워크로드에서 사용하는 Amazon EC2 인스턴스를 Amazon Machine Image(AMIs. AMI는 인스턴스의 루트 볼륨 및 인스턴스에 연결된 다른 EBS 볼륨의 스냅샷에서 생성됩니다. 이 AMI를 사용하여 복원된 버전의 EC2 인스턴스를 시작할 수 있습니다. AMI는 리전 내 또는 리전 간에 복사할 수 있습니다. 또는 AWS Backup를 사용하여 계정 간 및 다른 AWS 리전으로 백업을 복사할 수 있습니다. 교차 계정 백업 기능은 내부자 위협 또는 계정 침해를 포함하는 재해 이벤트로부터 보호하는 데 도움이 됩니다. AWS Backup 또한는 인스턴스의 개별 EBS 볼륨 외에도 EC2 백업을 위한 추가 기능을 추가하며 인스턴스 유형, 구성된 Virtual Private Cloud(VPC), 보안 그룹, IAM 역할, 모니터링 구성 및 태그와 같은 메타데이터 AWS Backup 를 저장하고 추적합니다. 그러나이 추가 메타데이터는 EC2 백업을 동일한 AWS 리전으로 복원할 때만 사용됩니다.

백업으로 재해 복구 리전에 저장된 모든 데이터는 failover. AWS Backup offers 복원 기능 시 복원해야 하지만 현재 예약된 복원 또는 자동 복원을 활성화하지 않습니다. AWS SDK를 사용하여 API를 호출APIs AWS Backup. 백업이 완료될 때마다 이를 정기적으로 반복되는 작업 또는 트리거 복원으로 설정할 수 있습니다. 다음 그림은 Amazon Simple Notification Service(Amazon SNS) 및를 사용한 자동 복원의 예를 보여줍니다AWS Lambda. 예약된 주기적 데이터 복원을 구현하는 것이 좋습니다. 백업의 데이터 복원은 컨트롤 플레인 작업이기 때문입니다. 재해 발생 시이 작업을 사용할 수 없는 경우에도 최근 백업에서 작업 가능한 데이터 스토어가 생성됩니다.

그림 8 - 백업 복원 및 테스트

파일럿 라이트

파일럿 라이트 접근 방식을 사용하면 한 리전에서 다른 리전으로 데이터를 복제하고 코어 워크로드 인프라의 사본을 프로비저닝할 수 있습니다. 데이터베이스 및 객체 스토리지 등 데이터 복제 및 백업을 지원하는 데 필요한 리소스가 항상 실행됩니다. 애플리케이션 서버와 같은 다른 요소는 애플리케이션 코드 및 구성으로 로드되지만 "끄기"되며 테스트 중에 또는 재해 복구 장애 조치가 호출될 때만 사용됩니다. 클라우드에서는 리소스가 필요하지 않을 때 리소스를 프로비저닝 해제하고 프로비저닝할 때 리소스를 프로비저닝할 수 있는 유연성이 있습니다. “끄기”의 모범 사례는 리소스를 배포하지 않고 필요한 경우 리소스를 배포하는 구성 및 기능을 생성하는 것입니다(“켜기”). 백업 및 복원 접근 방식과 달리 코어 인프라는 항상 사용할 수 있으며 애플리케이션 서버를 켜고 확장하여 전체 규모의 프로덕션 환경을 신속하게 프로비저닝할 수 있습니다.

그림 9 - 파일럿 조명 아키텍처

파일럿 라이트 접근 방식은 활성 리소스를 최소화하여 지속적인 재해 복구 비용을 최소화하고 코어 인프라 요구 사항이 모두 적용되므로 재해 발생 시 복구를 간소화합니다. 이 복구 옵션을 사용하려면 배포 접근 방식을 변경해야 합니다. 각 리전에 코어 인프라를 변경하고 워크로드(구성, 코드) 변경 사항을 각 리전에 동시에 배포해야 합니다. 이 단계는 배포를 자동화하고 코드형 인프라(IaC)를 사용하여 여러 계정 및 리전에 인프라를 배포하여 간소화할 수 있습니다(기본 리전으로의 전체 인프라 배포 및 DR 리전으로의 축소/전환된 인프라 배포). 리전별로 다른 계정을 사용하여 가장 높은 수준의 리소스 및 보안 격리를 제공하는 것이 좋습니다(피해된 보안 인증 정보도 재해 복구 계획의 일부인 경우).

이 접근 방식을 사용하면 데이터 재해도 완화해야 합니다. 지속적인 데이터 복제는 일부 유형의 재해로부터 보호해 주지만, 전략에 저장된 데이터의 버전 관리 또는 특정 시점 복구 옵션이 포함되지 않은 이상 데이터 손상 또는 중단으로부터 보호해 주지는 않습니다. 재해 리전에서 복제된 데이터를 백업하여 동일한 리전에서 point-in-time 백업을 생성할 수 있습니다.

서비스

백업 및 복원 섹션에서 다루는 AWS 서비스를 사용하여 point-in-time 백업을 생성하는 것 외에도 파일럿 조명 전략에 대해 다음 서비스도 고려하세요.

파일럿 조명의 경우 DR 리전의 라이브 데이터베이스 및 데이터 스토어에 대한 지속적인 데이터 복제는 낮은 RPO(앞서 설명한 point-in-time 백업 외에 추가로 사용하는 경우)에 가장 적합한 접근 방식입니다. AWS는 다음 서비스 및 리소스를 사용하여 데이터에 대해 지속적인 리전 간 비동기 데이터 복제를 제공합니다.

지속적 복제를 사용하면 DR 리전에서 거의 즉시 데이터 버전을 사용할 수 있습니다. 실제 복제 시간은 S3 객체용 S3 복제 시간 제어(S3 RTC)와 같은 서비스 기능과 Amazon Aurora 글로벌 데이터베이스의 관리 기능을 사용하여 모니터링할 수 있습니다. S3

재해 복구 리전에서 읽기/쓰기 워크로드를 실행하지 않으려면 RDS 읽기 전용 복제본을 기본 인스턴스로 승격해야 합니다. Aurora 이외의 DB 인스턴스의 경우 프로세스를 완료하는 데 몇 분 정도 걸리며 재부팅이 프로세스의 일부입니다. RDS를 사용한 교차 리전 복제(CRR) 및 장애 조치의 경우 Amazon Aurora 글로벌 데이터베이스를 사용하면 몇 가지 이점이 있습니다. 글로벌 데이터베이스는 데이터베이스를 완전히 사용할 수 있도록 하는 전용 인프라를 사용하며, 일반적인 지연 시간이 1초 미만(및 AWS 리전 내에서는 100밀리초 미만)인 보조 리전으로 복제할 수 있습니다. Amazon Aurora 글로벌 데이터베이스를 사용하면 기본 리전에서 성능 저하 또는 중단이 발생하는 경우, 리전이 완전히 중단되더라도 1분 이내에 읽기/쓰기 책임을 맡도록 보조 리전 중 하나를 승격할 수 있습니다. 또한 모든 보조 클러스터의 RPO 지연 시간을 모니터링하여 하나 이상의 보조 클러스터가 대상 RPO 기간 내에 유지되도록 Aurora를 구성할 수 있습니다.

리소스가 적거나 작은 코어 워크로드 인프라의 축소된 버전을 DR 리전에 배포해야 합니다. AWS CloudFormation를 사용하면 인프라를 정의하고 AWS 계정 및 AWS 리전 전체에 일관되게 배포할 수 있습니다.는 사전 정의된 의사 파라미터를 AWS CloudFormation 사용하여 배포되는 AWS 계정 및 AWS 리전을 식별합니다. 따라서 CloudFormation 템플릿에서 조건 로직을 구현하여 DR 리전에 인프라의 축소 버전만 배포할 수 있습니다. EC2 인스턴스 배포의 경우 Amazon Machine Image(AMI)는 하드웨어 구성 및 설치된 소프트웨어와 같은 정보를 제공합니다. 필요한 AMIs를 생성하는 Image Builder 파이프라인을 구현하고 이를 기본 리전과 백업 리전 모두에 복사할 수 있습니다. 이렇게 하면 재해 발생 시 이러한 골든 AMIs가 새 리전에서 워크로드를 재배포하거나 스케일 아웃하는 데 필요한 모든 것을 확보할 수 있습니다. Amazon EC2 인스턴스는 축소된 구성(기본 리전의 인스턴스보다 적음)으로 배포됩니다. 프로덕션 트래픽을 지원하기 위해 인프라를 확장하려면 웜 스탠바이 섹션의 Amazon EC2 Auto Scaling을 참조하세요.

파일럿 조명과 같은 액티브/패시브 구성의 경우, 모든 트래픽은 처음에 기본 리전으로 이동하고 기본 리전을 더 이상 사용할 수 없는 경우 재해 복구 리전으로 전환됩니다. 이 장애 조치 작업은 자동 또는 수동으로 시작할 수 있습니다. 상태 확인 또는 경보에 따라 자동으로 시작된 장애 조치는 신중하게 사용해야 합니다. 여기에 설명된 모범 사례를 사용하더라도 복구 시간과 복구 시점은 0보다 커져 가용성과 데이터가 약간 손실됩니다. 필요하지 않을 때 장애 조치하면(거짓 경보) 이러한 손실이 발생합니다. 따라서 수동으로 시작된 장애 조치를 자주 사용합니다. 이 경우에도 여전히 장애 조치 단계는 자동화하여 수동 시작은 버튼을 누르는 것 정도가 되도록 해야 합니다.

AWS 서비스를 사용할 때 고려해야 할 몇 가지 트래픽 관리 옵션이 있습니다.

한 가지 옵션은 Amazon Route 53을 사용하는 것입니다. Amazon Route 53을 사용하면 하나 이상의 AWS 리전에 있는 여러 IP 엔드포인트를 Route 53 도메인 이름과 연결할 수 있습니다. 그런 다음 트래픽을 해당 도메인 이름으로 적절한 엔드포인트로 라우팅할 수 있습니다. 장애 조치 시 트래픽을 복구 엔드포인트로 전환하고 기본 엔드포인트에서 멀어져야 합니다. Amazon Route 53 상태 확인은 이러한 엔드포인트를 모니터링합니다. 이러한 상태 확인을 사용하면 자동으로 시작된 DNS 장애 조치를 구성하여 트래픽이 데이터 영역에서 수행되는 신뢰성 높은 작업인 정상 엔드포인트로만 전송되도록 할 수 있습니다. 수동으로 시작된 장애 조치를 사용하여 이를 구현하려면 Amazon Application Recovery Controller(ARC)를 사용할 수 있습니다. ARC를 사용하면 실제로 상태를 확인하지 않고, 대신 전체 제어 권한이 있는 켜기/끄기 스위치 역할을 하는 Route 53 상태 확인을 생성할 수 있습니다. AWS CLI 또는 AWS SDK를 사용하면 가용성이 높은이 데이터 영역 API를 사용하여 장애 조치를 스크립트로 작성할 수 있습니다. 스크립트는 이러한 전환(Route 53 상태 확인)을 전환하여 Route 53에 기본 리전 대신 복구 리전으로 트래픽을 전송하도록 지시합니다. 일부에서 사용한 수동 시작 장애 조치를 위한 또 다른 옵션은 가중치가 적용된 라우팅 정책을 사용하고 모든 트래픽이 복구 리전으로 이동하도록 기본 및 복구 리전의 가중치를 변경하는 것입니다. 그러나이 작업은 컨트롤 플레인 작업이므로 Amazon Application Recovery Controller(ARC)를 사용하는 데이터 플레인 접근 방식만큼 복원력이 뛰어나지 않습니다.

또 다른 옵션은를 사용하는 것입니다AWS Global Accelerator. AnyCast IP를 사용하면 하나 이상의 AWS 리전에 있는 여러 엔드포인트를 동일한 정적 퍼블릭 IP 주소 또는 주소와 연결할 수 있습니다. AWS Global Accelerator 그런 다음는 트래픽을 해당 주소와 연결된 적절한 엔드포인트로 라우팅합니다. Global Accelerator 상태 확인은 엔드포인트를 모니터링합니다. 이러한 상태 확인을 사용하여는 애플리케이션의 상태를 AWS Global Accelerator 확인하고 사용자 트래픽을 정상 애플리케이션 엔드포인트로 자동으로 라우팅합니다. 수동으로 시작된 장애 조치의 경우 트래픽 다이얼을 사용하여 트래픽을 수신하는 엔드포인트를 조정할 수 있지만, 이는 컨트롤 플레인 작업입니다. Global Accelerator는 광범위한 AWS 엣지 네트워크를 사용하여 가능한 한 빨리 AWS 네트워크 백본에 트래픽을 배치하므로 애플리케이션 엔드포인트에 대한 지연 시간을 줄입니다. 또한 Global Accelerator는 DNS 시스템(예: Route 53)에서 발생할 수 있는 캐싱 문제를 방지합니다.

Amazon CloudFront는 오리진 장애 조치를 제공합니다. 여기서 기본 엔드포인트에 대한 지정된 요청이 실패하면 CloudFront는 요청을 보조 엔드포인트로 라우팅합니다. 앞서 설명한 장애 조치 작업과 달리 모든 후속 요청은 여전히 기본 엔드포인트로 이동하며 각 요청마다 장애 조치가 수행됩니다.

AWS 탄력적 재해 복구

AWS Elastic Disaster Recovery(DRS)는 기본 서버의 블록 수준 복제를 AWS 사용하여 모든 소스에서 로 서버 호스팅 애플리케이션 및 서버 호스팅 데이터베이스를 지속적으로 복제합니다. Elastic Disaster Recovery를 사용하면의 리전을 온프레미스 또는 다른 클라우드 공급자 및 해당 환경에서 호스팅되는 워크로드의 AWS 클라우드 재해 복구 대상으로 사용할 수 있습니다. 또한 EC2에서 AWS 호스팅되는 애플리케이션 및 데이터베이스(즉, RDS 아님)로만 구성된 호스팅 워크로드의 재해 복구에도 사용할 수 있습니다. Elastic Disaster Recovery는 파일럿 라이트 전략을 사용하여 스테이징 영역으로 사용되는 Amazon Virtual Private Cloud(Amazon VPC)에서 데이터 사본과 “스위치 오프” 리소스를 유지합니다. 장애 조치 이벤트가 트리거되면 스테이징된 리소스가 복구 위치로 사용되는 대상 Amazon VPC에서 전체 용량 배포를 자동으로 생성하는 데 사용됩니다.

그림 10 - AWS Elastic Disaster Recovery 아키텍처

웜 대기

웜 대기 접근 방식에는 스케일 다운되었지만 완전히 기능하는 프로덕션 환경의 복사본이 다른 리전에 복사됩니다. 이 접근법은 파일럿 라이트의 개념을 확대하고 복구 시간을 단축합니다. 워크로드가 다른 리전에서 상시 실행되기 때문입니다. 또한이 접근 방식을 사용하면 테스트를 더 쉽게 수행하거나 지속적인 테스트를 구현하여 재해 복구 능력에 대한 신뢰도를 높일 수 있습니다.

그림 11 - 웜 스탠바이 아키텍처

참고: 파일럿 라이트와 웜 스탠바이의 차이점을 이해하기 어려운 경우가 있습니다. 둘 다 기본 리전 자산의 복사본이 있는 DR 리전의 환경을 포함합니다. 파일럿 라이트는 먼저 추가 조치를 취하지 않고 요청을 처리할 수 없는 반면, 웜 스탠바이는 트래픽(감소된 용량 수준에서)을 즉시 처리할 수 있다는 점이 구별됩니다. 파일럿 라이트 접근 방식을 사용하려면 서버를 '켜고', 추가(코어가 아닌) 인프라를 배포하고 스케일 업해야 하는 반면, 웜 스탠바이를 사용하려면 스케일 업만 하면 됩니다(모든 것이 이미 배포되어 실행 중임). RTO 및 RPO 요구 사항을 사용하여 이러한 접근 방식 중에서 선택할 수 있습니다.

서비스

백업 및 복원과 파일럿 조명이 적용되는 모든 AWS 서비스는 데이터 백업, 데이터 복제, 액티브/패시브 트래픽 라우팅, EC2 인스턴스를 포함한 인프라 배포를 위한 웜 스탠바이에도 사용됩니다.

Amazon EC2 Auto Scaling은 AWS 리전 내의 Amazon EC2 인스턴스, Amazon ECS 작업, Amazon DynamoDB 처리량 및 Amazon Aurora 복제본을 포함한 리소스를 확장하는 데 사용됩니다. Amazon EC2 Auto Scaling은 AWS 리전 내의 가용 영역 간에 EC2 인스턴스 배포를 확장하여 해당 리전 내에서 복원력을 제공합니다. Auto Scaling을 사용하여 파일럿 라이트 또는 웜 스탠바이 전략의 일환으로 DR 리전을 전체 프로덕션 기능으로 확장할 수 있습니다. 예를 들어 EC2의 경우 Auto Scaling 그룹에서 원하는 용량 설정을 늘립니다. 를 통해 AWS Management Console, AWS SDK를 통해 자동으로 또는 원하는 새 용량 값을 사용하여 AWS CloudFormation 템플릿을 재배포하여이 설정을 수동으로 조정할 수 있습니다. AWS CloudFormation 파라미터를 사용하여 CloudFormation 템플릿을 더 쉽게 재배포할 수 있습니다. 프로덕션 용량으로 확장하는 것을 제한하지 않도록 DR 리전의 서비스 할당량이 충분히 높게 설정되어 있는지 확인합니다.

Auto Scaling은 컨트롤 플레인 활동이므로 이에 의존하면 전체 복구 전략의 복원력이 저하됩니다. 이는 절충입니다. 복구 리전이 배포된 전체 프로덕션 로드를 처리할 수 있도록 충분한 용량을 프로비저닝하도록 선택할 수 있습니다. 이 정적 안정성 구성을 상시 대기라고 합니다(다음 섹션 참조). 또는 더 적은 비용으로 더 적은 리소스를 프로비저닝하도록 선택할 수 있지만 Auto Scaling에 의존할 수 있습니다. 일부 DR 구현에서는 초기 트래픽을 처리하기에 충분한 리소스를 배포하여 RTO를 낮춘 다음 Auto Scaling을 사용하여 후속 트래픽을 증가시킵니다.

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

다중 사이트 액티브/액티브 또는 핫 스탠바이 액티브/패시브 전략의 일환으로 여러 리전에서 워크로드를 동시에 실행할 수 있습니다. 다중 사이트 액티브/액티브는 배포된 모든 리전의 트래픽을 제공하는 반면, 핫 스탠바이는 단일 리전의 트래픽만 제공하고 다른 리전(들)은 재해 복구에만 사용됩니다. 다중 사이트 액티브/액티브 접근 방식을 사용하면 사용자는 워크로드가 배포된 모든 리전의 워크로드에 액세스할 수 있습니다. 이 접근 방식은 재해 복구에 대한 가장 복잡하고 비용이 많이 드는 접근 방식이지만 올바른 기술 선택 및 구현을 통해 대부분의 재해에 대해 복구 시간을 거의 0으로 줄일 수 있습니다(그러나 데이터 손상은 백업에 의존해야 할 수 있으며, 이는 일반적으로 0이 아닌 복구 시점을 초래합니다). 핫 스탠바이는 사용자가 단일 리전으로만 이동하고 DR 리전이 트래픽을 받지 않는 액티브/패시브 구성을 사용합니다. 대부분의 고객은 두 번째 리전에서 전체 환경을 유지할 경우 활성/활성으로 사용하는 것이 좋습니다. 또는 두 리전을 모두 사용하여 사용자 트래픽을 처리하지 않으려면 Warm Standby는 보다 경제적이고 운영상 덜 복잡한 접근 방식을 제공합니다.

그림 12 - 다중 사이트 액티브/액티브 아키텍처(핫 스탠바이를 위해 하나의 액티브 경로를 비활성으로 변경)

다중 사이트 액티브/액티브에서는 워크로드가 둘 이상의 리전에서 실행되므로이 시나리오에서는 장애 조치와 같은 것이 없습니다. 이 경우 재해 복구 테스트는 워크로드가 리전 손실에 반응하는 방식에 초점을 맞춥니다. 트래픽이 실패한 리전에서 멀리 라우팅되나요? 다른 리전(들)이 모든 트래픽을 처리할 수 있습니까? 데이터 재해에 대한 테스트도 필요합니다. 백업 및 복구는 여전히 필요하며 정기적으로 테스트해야 합니다. 또한 데이터 손상, 삭제 또는 난독화와 관련된 데이터 재해의 복구 시간은 항상 0보다 크고 복구 시점은 항상 재해가 발견되기 전의 특정 시점입니다. 복구 시간을 거의 0으로 유지하기 위해 다중 사이트 액티브/액티브(또는 핫 스탠바이) 접근 방식의 추가 복잡성과 비용이 필요한 경우 보안을 유지하고 인적 재해를 완화하기 위해 인적 오류를 방지하기 위해 추가 노력을 기울여야 합니다.

서비스

백업 및 복원, 파일럿 조명 및 웜 스탠바이에 적용되는 모든 AWS 서비스는 특정 point-in-time 데이터 백업, 데이터 복제, 액티브/액티브 트래픽 라우팅, EC2 인스턴스를 포함한 인프라 배포 및 규모 조정에도 사용됩니다.

앞에서 설명한 액티브/패시브 시나리오(파일럿 라이트 및 웜 스탠바이)의 경우, Amazon Route 53 및 모두 네트워크 트래픽을 액티브 리전으로 라우팅하는 데 사용할 AWS Global Accelerator 수 있습니다. 여기서 활성/활성 전략의 경우 이러한 두 서비스 모두 어떤 사용자가 어떤 활성 리전 엔드포인트로 이동할지 결정하는 정책의 정의도 활성화합니다. 를 AWS Global Accelerator 사용하여 각 애플리케이션 엔드포인트로 전달되는 트래픽의 비율을 제어하도록 트래픽 다이얼을 설정합니다. Amazon Route 53는이 백분율 접근 방식과 지리 근접성 및 지연 시간 기반 정책을 포함하여 사용 가능한 다른 여러 정책을 지원합니다. Global Accelerator는 AWS 엣지 서버의 광범위한 네트워크를 자동으로 활용하여 가능한 한 빨리 AWS 네트워크 백본에 트래픽을 온보딩하므로 요청 지연 시간이 줄어듭니다.

이 전략을 사용한 비동기 데이터 복제를 통해 거의 0에 가까운 RPO를 사용할 수 있습니다. Amazon Aurora 글로벌 데이터베이스와 같은 AWS 서비스는 전용 인프라를 사용하여 데이터베이스를 애플리케이션에 제공할 수 있게 하며, 일반적인 지연 시간이 1초 미만인 최대 5개의 보조 리전으로 복제할 수 있습니다. 액티브/패시브 전략을 사용하면 쓰기가 기본 리전에만 발생합니다. 액티브/액티브의 차이점은 각 액티브 리전에 대한 쓰기와의 데이터 일관성이 처리되는 방식을 설계하는 것입니다. 로컬 읽기라고 하는 가장 가까운 리전에서 제공할 사용자 읽기를 설계하는 것이 일반적입니다. 쓰기에는 다음과 같은 몇 가지 옵션이 있습니다.

AWS CloudFormation 는 여러 AWS 리전의 AWS 계정 간에 일관되게 배포된 인프라를 적용하는 강력한 도구입니다. AWS CloudFormation StackSets는 단일 작업으로 여러 계정 및 리전에서 CloudFormation 스택을 생성, 업데이트 또는 삭제할 수 있도록 하여이 기능을 확장합니다. AWS CloudFormation 는 YAML 또는 JSON을 사용하여 인프라를 코드로 정의하지만를 AWS Cloud Development Kit (AWS CDK) 사용하면 익숙한 프로그래밍 언어를 사용하여 인프라를 코드로 정의할 수 있습니다. 코드가 CloudFormation으로 변환되고 AWS에 리소스를 배포하는 데 사용됩니다.