# REL 13 DR(재해 복구)를 어떻게 계획합니까?
DR 전략의 시작은 백업 및 이중화 워크로드 구성 요소를 갖추는 것입니다. [RTO 및 RPO는 워크로드 복원을 위한](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) 목표입니다. 비즈니스 요구 사항에 따라 이러한 목표를 설정합니다. 워크로드 리소스 및 데이터의 위치와 기능을 고려하여 이러한 목표를 충족하는 전략을 구현합니다. 중단 가능성과 복구 비용도 워크로드에 대한 재해 복구 옵션을 갖추는 것이 지니는 비즈니스 가치를 파악하는 데 도움이 되는 주요 요소입니다.
**Topics**
+ [REL13-BP01 가동 중단 시간 및 데이터 손실 시의 복구 목표 정의](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 복구 목표 달성을 위해 정의된 복구 전략 사용](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 재해 복구 구현을 테스트하여 구현 확인](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 DR 사이트 또는 리전에서 구성 드리프트 관리](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 복구 자동화](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 가동 중단 시간 및 데이터 손실 시의 복구 목표 정의
워크로드에는 RTO(복구 시간 목표) 및 RPO(복구 시점 목표)가 있습니다.
*RTO(복구 시간 목표)* 는 서비스 중단 시점과 서비스 복원 시점 간에 허용되는 최대 지연 시간으로, 서비스를 사용할 수 없는 상태로 허용되는 기간을 결정합니다.
*RPO(복구 시점 목표)* 는 마지막 데이터 복구 시점 이후 허용되는 최대 시간으로, 마지막 복구 시점과 서비스 중단 시점 사이에 허용되는 데이터 손실량을 결정합니다.
워크로드에 적절한 재해 복구(DR) 전략을 선택할 때 RTO 및 RPO 값을 고려하는 것이 중요합니다. 이 두 가지 목표는 비즈니스 차원에서 결정하고 기술 팀에서 DR 전략을 선택하여 구현할 때 사용합니다.
**원하는 결과:**
워크로드마다 비즈니스 영향에 따라 정의된 RTO 및 RPO가 할당됩니다. 워크로드는 관련 RTO와 RPO로 서비스 가용성과 용인 가능한 데이터 손실을 정의하는 사전에 정의된 티어에 할당됩니다. 그러한 티어 할당이 불가능하면 나중에 티어를 생성할 의도로 워크로드마다 맞춤형으로 할당될 수 있습니다. RTO 및 RPO는 워크로드의 재해 복구 전략 구현을 선택하기 위한 기본적인 고려 사항 중 하나로 사용됩니다. DR 전략을 선택할 때 추가로 고려해야 할 사항은 비용 제약, 워크로드 종속성, 운영 요구 사항입니다.
RTO의 경우 중단의 기간에 따른 영향을 파악합니다. 영향이 선형적인지, 비선형적인 영향이 있는지(예: 4시간 후에 다음 교대가 시작될 때까지 제조 라인을 중단시킴) 파악해야 합니다.
다음과 같은 재해 복구 매트릭스는 워크로드 중요도가 복구 목표와 어떤 연관이 있는지 파악하는 데 도움이 됩니다. (참고로 X 축과 Y 축의 실제 값은 조직의 요구 사항에 따라 맞춤화해야 합니다.)
![\[재해 복구 매트릭스를 보여주는 차트\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/disaster-recovery-matrix.png)
**일반적인 안티 패턴:**
+ 복구 목표가 정의되지 않음
+ 임의의 복구 목표 선택
+ 너무 관대하고 비즈니스 목표를 충족하지 못하는 복구 목표 선택
+ 가동 중단 시간 및 데이터 손실의 영향을 파악하지 않음
+ 워크로드 구성에서 달성할 수 없는 즉각 복구 또는 데이터 무손실과 같이 비현실적인 복구 목표 선택
+ 실제 비즈니스 목표보다 더 엄격한 복구 목표 선택. 이로 인해 워크로드에 필요한 수준 이상으로 DR 구현의 비용이 높아지고 DR 구현이 복잡해집니다.
+ 종속 워크로드와 호환되지 않는 복구 목표 선택
+ 규제 요구 사항을 고려하지 않은 복구 목표
+ 워크로드에 대한 RTO 및 RPO를 정의했으나 테스트하지 않음
**이 모범 사례 수립의 이점:** 재해 복구를 구현하는 데 기준이 될 시간 및 데이터 손실에 대한 복구 목표가 필요합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
주어진 워크로드에서 가동 중단 시간 및 데이터 손실이 비즈니스에 미치는 영향을 파악해야 합니다. 가동 중단 시간이나 데이터 손실이 커질수록 일반적으로 영향이 커지지만, 영향이 어떻게 커지는지는 워크로드 유형에 따라 다를 수 있습니다. 예를 들어, 영향이 적을 때는 가동 중단 시간을 최대 1시간까지 용인할 수 있지만 그 후에는 영향이 빠르게 증가할 수 있습니다. 비즈니스에 미치는 영향은 비용 손실(수익 손실), 고객 신뢰(평판에 미치는 영향), 운영 문제(급여 누락 또는 생산성 저하), 규제 위험 등 다양한 형태로 나타날 수 있습니다. 다음 단계를 따라 이러한 영향을 이해하고 워크로드에 RTO 및 RPO를 설정하세요.
**구현 단계**
1. 이 워크로드의 비즈니스 이해 관계자를 파악하고 이해 관계자를 관여시켜 이 단계를 구현합니다. 워크로드의 복구 목표는 비즈니스 차원의 의사 결정 사항입니다. 그런 다음 기술 팀에서 비즈니스 이해 관계자와 협력하여 이 목표를 사용해 DR 전략을 선택합니다.
**참고**
2단계와 3단계에서는 다음을 사용합니다. [구현 워크시트](#implementation-worksheet).
1. 아래 질문에 답하여 의사 결정을 내리는 데 필요한 정보를 수집합니다.
1. 조직에 워크로드 영향에 대한 중요도 범주나 티어가 있습니까?
1. 있다면 이 워크로드를 범주에 할당합니다.
1. 없다면 범주를 만듭니다. 5개 이하의 범주를 생성하고 각각의 복구 시간 목표 범위를 구체화합니다. 범주 예시로는 ‘매우 중요’, ‘높음’, ‘보통’, ‘낮음’이 있습니다. 워크로드가 각각의 범주에 어떻게 해당하는지 파악하려면 워크로드가 미션에 필수적인지, 비즈니스 차원에서 중요한지 아니면 비즈니스 추진과 큰 관련이 없는지 고려합니다.
1. 범주에 따라 워크로드 RTO와 RPO를 설정합니다. 언제나 이 단계에 들어설 때 계산한 원래의 값보다 더 엄격하게(더 낮은 RTO 및 RPO) 범주를 선택하세요. 이로 인해 값이 부적절하게 크게 변경된다면 새로운 범주를 만드는 것을 고려하세요.
1. 이 답변에 따라 RTO 및 RPO 값을 워크로드에 할당합니다. 직접 할당하거나 워크로드를 사전에 정의된 서비스 티어에 할당하면 됩니다.
1. 이 워크로드의 재해 복구 계획(DRP)을 문서화합니다. 이는 조직의 [비즈니스 연속성 계획(BCP)에](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)포함되며, 워크로드 팀 및 이해 관계자가 액세스할 수 있는 위치에 저장합니다.
1. RTO 및 RPO와 이러한 값을 결정하는 데 사용된 정보를 기록합니다. 비즈니스에 미치는 워크로드의 영향을 평가하는 데 사용한 전략을 포함합니다.
1. 재해 복구 목표에서 추적하고 있거나 추적하려는 RTO 및 RPO 외의 다른 지표를 기록합니다.
1. 이 계획에 DR 전략 및 런북의 세부 정보를 추가합니다.
1. 그림 15와 같은 매트릭스에서 워크로드 중요도를 찾아보면 조직을 위해 사전 정의된 서비스 티어를 설정할 수 있습니다.
1. 에 따라 DR 전략(또는 DR 전략의 개념 증명)을 구현하고 나면[REL13-BP02 복구 목표 달성을 위해 정의된 복구 전략 사용](rel_planning_for_recovery_disaster_recovery.md)이 전략을 테스트하여 워크로드의 실제 RTC(복구 시간 역량) 및 RPC(복구 시점 역량)를 파악합니다. 이것이 복구 목표에 부합하지 않으면 비즈니스 이해 관계자와 협력하여 목표를 조정하거나 목표에 부합하도록 DR 전략을 변경합니다.
**기본 질문**
1. 비즈니스에 심각한 영향이 미치기 전에 워크로드가 중단되어도 되는 최대 시간은 얼마입니까?
1. 워크로드가 중단되었을 때 분당 비즈니스에 발생하는 금전적 비용(직접적인 금전적 영향)을 파악합니다.
1. 이 영향은 항상 선형적이지 않다는 점을 고려합니다. 처음에는 영향이 제한적이지만 특정 시점을 지나면 영향이 빠르게 증가할 수 있습니다.
1. 비즈니스에 심각한 영향이 미치기 전에 손실되어도 되는 데이터의 최대 양은 얼마입니까?
1. 가장 중요한 데이터 스토어에 대해 이 값을 고려합니다. 다른 데이터 스토어에 대해 각각의 중요도를 파악합니다.
1. 워크로드 데이터가 손실되면 재생성할 수 있습니까? 백업 후 복원하는 것보다 재생성이 운영상 더 용이하면 워크로드 데이터를 재생성하는 데 사용되는 소스 데이터의 중요도에 따라 RPO를 선택합니다.
1. 이것이 의존하는 워크로드(다운스트림) 또는 이것에 의존하는 워크로드(업스트림)의 복구 목표 및 가용성 기대치는 얼마입니까?
1. 이 워크로드가 업스트림 종속성의 요구 사항을 충족하도록 하는 복구 목표를 선택합니다.
1. 다운스트림 종속성의 복구 기능에 따라 달성할 수 있는 복구 목표를 선택합니다. 중요하지 않은 다운스트림 종속성(다른 해결책이 있는 것)은 제외할 수 있습니다. 아니면 중요한 다운스트림 종속성으로 필요하다면 복구 기능을 개선합니다.
**추가 질문**
아래 질문을 고려하고 이 워크로드에 어떻게 적용되는지 생각하세요.
1. 중단의 유형(예: 리전, 가용 영역 등)에 따라 다른 RTO 및 RPO가 있습니까?
1. RTO/RPO가 변경될 수 있는 특정 시기(계절, 세일 이벤트, 제품 출시)가 있습니까? 그렇다면 다른 측정 방식과 시간 경계가 무엇입니까?
1. 워크로드가 중단되면 얼마나 많은 고객이 영향을 받습니까?
1. 워크로드가 중단될 경우 평판에 미치는 영향은 무엇입니까?
1. 워크로드가 중단될 경우 발생할 수 있는 운영상의 다른 영향에는 어떤 것이 있습니까? 예를 들어,이메일 시스템을 사용할 수 없게 되거나 급여 시스템에서 트랜잭션을 제출할 수 없게 되면 직원 생산성에 영향을 미칩니다.
1. 워크로드 RTO 및 RPO가 사업부 및 조직 DR 전략과 어떻게 연계됩니까?
1. 서비스 제공에 내부적으로 계약상의 의무가 있습니까? 그 의무를 이행하지 못하면 불이익이 있습니까?
1. 데이터에 대한 규제 또는 규정상의 제약은 무엇입니까?
## 구현 워크시트
구현의 2 및 3단계에 이 워크시트를 사용하세요. 필요에 따라 질문을 추가하는 등 이 워크시트를 조정할 수 있습니다.
![\[워크시트\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/worksheet.png)
**구현 계획의 작업 수준: **낮음
## 리소스
**관련 모범 사례:**
+ [REL09-BP04 백업 무결성 및 프로세스를 확인하기 위해 데이터의 주기적인 복구 수행](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02 복구 목표 달성을 위해 정의된 복구 전략 사용](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 재해 복구 구현을 테스트하여 구현 확인](rel_planning_for_recovery_dr_tested.md)
**관련 문서:**
+ [AWS 아키텍처 블로그: 재해 복구 시리즈](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS에서 워크로드의 재해 복구: 클라우드에서의 복구(AWS 백서)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [AWS 복원력 허브로 복원력 정책 관리](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [APN 파트너: 재해 복구를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: 재해 복구에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**관련 동영상:**
+ [AWS re:Invent 2018: 다중 리전 액티브-액티브 애플리케이션을 위한 아키텍처 패턴(ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS에서 워크로드의 재해 복구](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 복구 목표 달성을 위해 정의된 복구 전략 사용
워크로드의 복구 목표에 부합하는 재해 복구(DR) 전략을 정의합니다. 백업 및 복원, 대기(활성/비활성), 활성/활성 등의 전략을 선택합니다.
DR 전략은 기본 위치에서 워크로드를 실행할 수 없게 되었을 때 복구 사이트에서 워크로드를 실행하는 능력에 달려 있습니다. 가장 흔한 복구 목표는 다음에서 논의한 RTO 와 RPO입니다 [REL13-BP01 가동 중단 시간 및 데이터 손실 시의 복구 목표 정의](rel_planning_for_recovery_objective_defined_recovery.md).
하나의 AWS 리전 내에서 여러 가용 영역(AZ)에 걸친 DR 전략은 화재, 홍수, 대규모의 정전과 같은 재해 이벤트 시 피해를 완화해 줍니다. 워크로드를 특정 AWS 리전에서 실행할 수 없게 되는 흔치 않은 이벤트에 대한 예방 조치를 구현하는 것이 요구 사항이라면 여러 리전을 사용하는 DR 전략을 사용할 수 있습니다.
여러 리전에 걸쳐 DR 전략을 아키텍팅할 때 다음 전략 중 하나를 사용해야 합니다. 전략은 복잡성과 비용이 증가하고 RTO 및 RPO가 감소하는 순서로 나열되어 있습니다. *복구 리전* 이란 워크로드에 사용한 기본 리전이 아닌 다른 AWS 리전을 말합니다.
![\[DR 전략을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/disaster-recovery-strategies.png)
+ **백업 및 복구** (시간 단위 RPO, 24시간 이하의 RTO): 데이터와 애플리케이션을 복구 리전에 백업합니다. 자동화된 백업 또는 지속적인 백업을 사용하면 특정 시점 복구가 가능하여 경우에 따라서는 RPO를 5분까지 줄일 수 있습니다. 재해 이벤트 시 인프라를 배포(RTO를 단축하기 위해 인프라를 코드로 사용하여)하고, 코드를 배포하고, 백업 데이터를 복원하여 복구 리전에서 재해로부터 복구합니다.
+ **파일럿 라이트** (분 단위 RPO, 10분 단위 RTO): 코어 워크로드의 인프라 복사본을 복구 리전에 프로비저닝합니다. 데이터를 복구 리전에 복제하고 복구 리전에서 백업을 생성합니다. 데이터베이스 및 객체 스토리지 등 데이터 복제 및 백업을 지원하는 데 필요한 리소스가 항상 실행됩니다. 애플리케이션 서버 또는 서버리스 컴퓨팅과 같은 기타 요소는 배포되지 않지만 필요에 따라 필수 구성 및 애플리케이션 코드로 생성될 수 있습니다.
+ **웜 대기** (초 단위 RPO, 분 단위 RTO): 모든 기능을 갖추었지만 축소된 버전의 워크로드를 복구 리전에 항상 실행되는 상태로 유지합니다. 비즈니스 크리티컬 시스템은 완전히 복제되고 항상 실행되지만 플릿은 축소됩니다. 데이터가 복구 리전에 복제되며 실행됩니다. 복구 시기가 되면 시스템은 프로덕션 로드를 처리하기 위해 신속하게 확장됩니다. 웜 대기가 확장될수록 RTO 및 컨트롤 플레인 의존도는 낮아집니다. 완전히 확장되면 이것을 **상시 대기 방식이라고 합니다**.
+ **복수 리전(다중 사이트) 액티브/액티브** (0에 가까운 RPO, 0일 수 있는 RTO): 워크로드가 여러 AWS 리전에 배포되고 능동적으로 트래픽을 처리합니다. 이 전략을 사용하려면 리전 전체에서 데이터를 동기화해야 합니다. 서로 다른 두 개 리전에 있는 복제본에 같은 레코드를 쓸 때 나타날 수 있는 충돌을 피하거나 처리해야 하는데, 그 방법이 복잡할 수 있습니다. 데이터 복제는 데이터 동기화에 유용하며 일부 유형의 재해로부터 보호해 주지만, 솔루션에 특정 시점 복구 옵션이 포함되지 않은 이상 데이터 손상 또는 중단으로부터 보호해 주지는 않습니다.
**참고**
파일럿 라이트와 웜 대기 간의 차이를 이해하기 어려울 수 있습니다. 둘 다 복구 리전에 속한 환경과 기본 리전 자산의 복사본을 포함합니다. 차이점은 파일럿 라이트의 경우 먼저 추가 조치를 취하지 않으면 요청을 처리할 수 없지만 웜 대기는 축소된 용량 수준으로 트래픽을 즉시 처리할 수 있다는 점입니다. 파일럿 라이트를 사용하려면 서버를 켜야 하고 코어 인프라가 아닌 인프라를 추가로 배포해야 할 수 있으며 스케일 업해야 합니다. 반면 웜 대기를 사용하려면 스케일 업만 하면 됩니다. 다른 것은 이미 모두 배포되고 실행되는 상태입니다. RTO 및 RPO 요구 사항에 따라 두 전략 중에서 선택하십시오.
**원하는 결과:**
각 워크로드에 대해 워크로드가 DR 목표를 달성하도록 하는 DR 전략이 정의되고 구현되어 있습니다. 워크로드 간의 DR 전략은 재사용 가능한 패턴(예: 이전에 설명한 전략)을 활용합니다.
**일반적인 안티 패턴:**
+ DR 목표가 유사한 워크로드에 일관적이지 않은 복구 절차를 구현함
+ 재해가 발생했을 때 DR 전략이 필요에 따라 구현되도록 함
+ DR 계획이 없음
+ 복구 시 컨트롤 플레인 작업에 의존함
**이 모범 사례 정립의 이점:**
+ 정의된 복구 전략을 사용하면 공통적인 도구 및 테스트 절차를 사용할 수 있습니다.
+ 복구 전략을 정의해 두면 팀 간에 지식을 더 효율적으로 공유하고, 팀에서 소유한 워크로드에 DR을 더 쉽게 구현할 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
+ DR 전략을 계획, 구현, 테스트하지 않으면 재해 발생 시 복구 목표를 달성하지 못할 가능성이 큽니다.
## 구현 가이드
각각의 단계에서 아래 세부 정보를 확인하세요.
1. 이 워크로드의 복구 요구 사항을 충족하는 DR 전략을 결정합니다.
1. 선택한 DR 전략이 구현될 수 있는 패턴을 검토합니다.
1. 워크로드의 리소스를 평가하고 장애 조치 전에(정상 작동 시) 복구 리전에서 워크로드 리소스의 구성을 평가합니다.
1. 필요할 경우 장애 조치 시(재해 이벤트 시) 복구 리전을 어떻게 준비할지 결정하고 구현합니다.
1. 필요할 경우 장애 조치 시(재해 이벤트 시) 트래픽을 장애 조치로 어떻게 다시 라우팅할지 결정하고 구현합니다.
1. 워크로드의 장애 복구를 위한 계획을 수립합니다.
**구현 단계**
1. **이 워크로드의 복구 요구 사항을 충족하는 DR 전략을 결정합니다.**
DR 전략을 선택할 때는 가동 중단 시간과 데이터 손실을 줄이는 것(RTO 및 RPO)과 전략 구현의 비용과 복잡성을 줄이는 것 사이에서 절충해야 합니다. 필요 이상으로 엄중한 전략을 구현하지 말아야 합니다. 불필요한 비용이 발생하기 때문입니다.
예를 들어, 다음 다이어그램에서 비즈니스는 허용 가능한 최대 RTO와 서비스 복원 전략에 지출할 수 있는 비용의 한계를 결정했습니다. 비즈니스의 목표를 감안할 때 파일럿 라이트 또는 웜 대기 DR 전략이 RTO와 비용 기준을 둘 다 만족시킵니다.
![\[RTO와 비용에 따라 DR 전략을 선택하는 것을 보여주는 그래프\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/choosing-a-dr-strategy.png)
자세한 내용은 다음을 참조하세요. [비즈니스 연속성 계획(BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html).
1. **선택한 DR 전략이 구현될 수 있는 패턴을 검토합니다.**
이 단계는 선택한 전략을 구현하는 방법을 파악하기 위한 것입니다. 전략은 AWS 리전을 기본 사이트 및 복구 사이트로 사용하여 설명되어 있습니다. 그러나 하나의 리전 내에서 DR 전략으로 가용 영역을 선택할 수도 있습니다. 그런 경우 이런 전략 중 여러 개를 활용하게 됩니다.
이어지는 단계에서는 전략을 특정 워크로드에 적용합니다.
**백업 및 복구**
*백업 및 복구* 는 구현하기가 복잡하면서도 워크로드를 복원하는 데 더 많은 시간과 노력이 들어가 RTO와 RPO가 높아지는 전략입니다. 항상 데이터의 백업을 만들어 다른 사이트(예: 다른 AWS 리전)에 복사해 두는 것이 좋습니다.
![\[백업 및 복원 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/backup-restore-architecture.png)
이 전략에 대한 자세한 내용은 [Disaster Recovery (DR) Architecture on AWS, Part II: Backup and Restore with Rapid Recovery(AWS에서의 재해 복구(DR) 아키텍처, 파트 II: 빠른 복구와 백업 및 복원)을 참조하세요](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
**파일럿 라이트**
파일럿 라이트 *접근법을 사용하면* 기본 리전의 데이터를 복구 리전에 복제합니다. 워크로드 인프라에 사용되는 코어 리소스가 복구 리전에 배포되지만 기능하는 스택이 되려면 기타 리소스 및 그 종속성이 여전히 필요합니다. 예를 들어 그림 20에서는 컴퓨팅 인스턴스가 배포되지 않았습니다.
![\[파일럿 라이트 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/pilot-light-architecture.png)
이 전략에 대한 자세한 내용은 [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby(AWS에서의 재해 복구(DR) 아키텍처, 파트 III: 파일럿 라이트 및 웜 대기)를 참조하세요](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**웜 대기**
유효 *웜 대기* 접근법에서는 스케일 다운되었지만 완전히 기능하는 프로덕션 환경의 복사본이 다른 리전에 복사됩니다. 이 접근법은 파일럿 라이트의 개념을 확대하고 복구 시간이 단축됩니다. 워크로드가 다른 리전에서 상시 실행되기 때문입니다. 복구 리전이 완전한 용량으로 배포되면 이것을 *상시 대기 방식이라고 합니다*.
![\[그림 21: 웜 대기 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/warm-standby-architecture.png)
웜 대기 또는 파일럿 라이트를 사용하려면 복구 리전에서 리소스를 스케일 업해야 합니다. 필요할 때 용량을 사용 가능하도록 하려면 [EC2 인스턴스의 용량 예약을](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) 사용하는 것을 고려하세요. AWS Lambda를 사용하는 경우 [프로비저닝된 동시성이](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) 함수의 호출에 즉시 응답하도록 실행 환경을 준비합니다.
이 전략에 대한 자세한 내용은 [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby(AWS에서의 재해 복구(DR) 아키텍처, 파트 III: 파일럿 라이트 및 웜 대기)를 참조하세요](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**복수 사이트 액티브/액티브**
워크로드를 *복수 사이트 액티브/액티브* 전략의 일부로 여러 리전에서 동시에 실행할 수 있습니다. 복수 사이트 액티브/액티브는 배포된 모든 리전에서 트래픽을 받습니다. 고객은 DR과 다른 이유를 이 전략을 선택할 수 있습니다. 이 전략은 가용성을 높이기 위해서 또는 글로벌 오디언스에게 워크로드를 배포하는 경우(사용자에게 엔드포인트를 가까이 가져가거나 해당 리전의 오디언스에게 현지화된 스택을 배포하기 위해) 사용될 수 있습니다. DR 전략으로, 워크로드가 배포된 AWS 리전 중 하나에서 지원되지 않는다면 해당 리전이 철수되며 가용성을 유지하는 데 나머지 리전이 사용됩니다. 복수 사이트 액티브/액티브는 DR 전략 중 운영 측면에서 가장 복잡하며 비즈니스 요구 사항에 따라 필요한 경우에만 선택해야 합니다.
![\[복수 사이트 액티브/액티브 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/multi-site-active-active-architecture.png)
이 전략에 대한 자세한 내용은 [Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active(AWS의 재해 복구(DR) 아키텍처, 파트 IV: 복수 사이트 액티브/액티브)를 참조하세요](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/).
**데이터 보호를 위한 기타 관행**
모든 전략에서 데이터 재해를 완화해야 합니다. 지속적인 데이터 복제는 일부 유형의 재해로부터 보호해 주지만, 전략에 저장된 데이터의 버전 관리 또는 특정 시점 복구 옵션이 포함되지 않은 이상 데이터 손상 또는 중단으로부터 보호해 주지는 않습니다. 복구 사이트에서 복제된 데이터를 백업하여 복제본 외에도 특정 시점 백업을 생성해야 합니다.
**하나의 AWS 리전에서 여러 가용 영역(AZ) 사용**
하나의 리전에서 여러 개의 AZ를 사용하면 DR 구현에서 위 전략 중 여러 요소를 사용하게 됩니다. 먼저, 그림 23에서처럼 여러 개의 AZ를 사용하여 고가용성(HA) 아키텍처를 생성해야 합니다. 이 아키텍처는 [Amazon EC2 인스턴스와 마찬가지로 복수 사이트 액티브/액티브 접근법을 사용합니다.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) 및 [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) 는 여러 AZ에 배포되어 요청을 처리하는 리소스가 있습니다. 이 아키텍처는 상시 대기 방식도 보여주는데, 기본 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) 인스턴스에 장애가 발생하면(또는 AZ 자체에 장애가 발생하면) 대기 인스턴스가 기본으로 승격됩니다.
![\[그림 23: 다중 AZ 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/multi-az-architecture2.png)
이 HA 아키텍처 외에도 워크로드를 실행하는 데 필요한 모든 데이터의 백업을 추가해야 합니다. 이것은 하나의 영역에만 제한된 [Amazon EBS 볼륨](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) 또는 [Amazon Redshift 클러스터와 같은 데이터에 특히 중요합니다](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). AZ에 장애가 발생하면 이 데이터를 다른 AZ에 복원해야 합니다. 가능하다면 추가적인 보호 조치로 데이터 백업을 다른 AWS 리전에 복사해야 합니다.
단일 리전, 다중 AZ DR보다 일반적이지 않은 대안은 [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack(Amazon Route 53 Application Recovery Controller를 사용하여 복원력이 높은 애플리케이션 구축, 파트 1: 단일 리전 스택) 블로그 게시물에 설명되어 있습니다](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/). 여기에 나오는 전략은 리전의 작동 방식처럼 AZ 간에 가능한 한 많은 격리를 유지하기 위한 것입니다. 이 대안을 사용하면 액티브/액티브 또는 액티브/패시브 접근법 중에서 선택할 수 있습니다.
참고: 일부 워크로드에는 상주 요구 사항이 적용됩니다. 현재 하나의 AWS 리전만 있는 근처 워크로드에 상주 요구 사항이 적용되는 경우 복수 리전이 비즈니스 요구 사항에 적합하지 않을 수 있습니다. 다중 AZ 전략은 대부분의 재해로부터 안전하게 보호해 줍니다.
1. **워크로드의 리소스를 평가하고 장애 조치 전에(정상 작동 시) 복구 리전에서 워크로드 리소스의 구성을 평가합니다.**
인프라 및 AWS 리소스의 경우 [AWS CloudFormation](https://aws.amazon.com/cloudformation) 등의 코드형 인프라 또는 Hashicorp Terraform과 같은 서드 파티 도구를 사용하세요. 한 번의 작업으로 여러 개의 계정과 리전에 배포하려면 [AWS CloudFormation StackSets를 사용하면 됩니다](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). 복수 사이트 액티브/액티브 및 상시 대기 방식 전략의 경우 복구 리전에 배포된 인프라의 리소스는 기본 리전의 리소스와 같습니다. 파일럿 라이트 및 웜 대기 전략의 경우 배포된 인프라가 프로덕션으로 사용되려면 추가 조치가 필요합니다. CloudFormation [파라미터](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) 및 [조건부 로직을 사용하면](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html)배포된 스택이 액티브인지 대기인지 하나의 템플릿으로 제어할 수 있습니다. 그러한 CloudFormation 템플릿의 예시는 [이 블로그 게시물에 있습니다](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
모든 DR 전략에서 AWS 리전 내에 데이터 소스가 백업되어야 하며 그러한 백업은 복구 리전에 복사됩니다. [AWS Backup](https://aws.amazon.com/backup/) 은 해당 리소스의 백업을 구성, 예약, 모니터링할 수 있는 중앙 집중화된 보기를 제공합니다. 파일럿 라이트, 웜 대기, 복수 사이트 액티브/액티브의 경우 기본 리전의 데이터를 복구 리전의 [Amazon Relational Database Service(Amazon RDS)](https://aws.amazon.com/rds) DB 인스턴스 또는 [Amazon DynamoDB](https://aws.amazon.com/dynamodb) 테이블 등의 데이터 리소스에 복제해야 합니다. 그래야 이런 데이터 리소스가 복구 리전에서 실행되고 요청을 처리할 준비가 됩니다.
AWS 서비스가 전체 리전에서 작동하는 원리를 자세히 알아보려면 [AWS 서비스로 다중 리전 애플리케이션 생성 블로그 시리즈를 참조하세요](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/).
1. **필요할 경우 장애 조치 시(재해 이벤트 시) 복구 리전을 어떻게 준비할지 결정하고 구현합니다.**
복수 사이트 액티브/액티브의 경우 장애 조치는 한 리전을 철수하고 나머지 액티브 리전에 의존하는 것입니다. 일반적으로 이러한 리전은 트래픽을 받을 준비가 되어 있습니다. 파일럿 라이트 및 웜 대기 전략의 경우 복구 조치로 그림 20의 EC2 인스턴스와 같은 누락된 리소스와 기타 누락된 리소스를 배포해야 합니다.
위에 설명된 모든 전략에서 데이터베이스의 읽기 전용 인스턴스를 기본 읽기/쓰기 인스턴스로 승격해야 합니다.
백업 및 복원의 경우 백업에서 데이터를 복원하면 해당 데이터에 대해 EBS 볼륨, RDS DB 인스턴스, DynamoDB 테이블 등의 리소스가 생성됩니다. 또한 인프라와 배포 코드를 복원해야 합니다. AWS Backup을 사용하여 복구 리전에서 데이터를 복원할 수 있습니다. 참조 [REL09-BP01 백업해야 하는 모든 데이터 확인 및 백업 또는 소스에서 데이터 재현](rel_backing_up_data_identified_backups_data.md) 를 참조하세요. 인프라 재구축에는 필요한 [Amazon Virtual Private Cloud(Amazon VPC)](https://aws.amazon.com/vpc)서브넷 및 보안 그룹 외에도 EC2 인스턴스 등의 리소스를 생성하는 작업이 필요합니다. 이러한 복원 작업의 대부분은 자동화할 수 있습니다. 방법은 [이 블로그 게시물에 있습니다](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
1. **필요할 경우 장애 조치 시(재해 이벤트 시) 트래픽을 장애 조치로 어떻게 다시 라우팅할지 결정하고 구현합니다.**
이 장애 조치 작업은 자동 또는 수동으로 시작할 수 있습니다. 상태 확인 또는 경보를 기반으로 자동으로 시작된 장애 조치는 신중하게 사용해야 합니다. 불필요한 장애 조치(거짓 경보)는 비가용성 및 데이터 손실과 같은 비용을 발생시키기 때문입니다. 따라서 수동으로 시작된 장애 조치를 자주 사용합니다. 이 경우, 버튼을 누르는 것처럼 수동으로 시작할 수 있도록 여전히 장애 조치를 위한 단계는 자동화해야 합니다.
AWS 서비스를 사용할 때는 몇 가지 트래픽 관리 옵션이 있습니다. 옵션 중 하나는 다음을 사용하는 것입니다. [Amazon Route 53](https://aws.amazon.com/route53). Amazon Route 53를 사용하면 하나 또는 그 이상의 AWS 리전에서 여러 개의 IP 엔드포인트를 하나의 Route 53 도메인 이름과 연결할 수 있습니다. 수동으로 시작된 장애 조치를 구현하기 위해서는 트래픽을 복구 리전으로 다시 라우팅하기 위해 가용성이 높은 데이터 영역 API를 제공하는 [Amazon Route 53 Application Recovery Controller를](https://aws.amazon.com/route53/application-recovery-controller/)사용할 수 있습니다. 장애 조치를 구현할 때 데이터 영역 작업을 사용하고 다음에 설명된 대로 컨트롤 플레인 작업은 피하세요 [REL11-BP04 복구 중 컨트롤 플레인이 아닌 데이터 영역 사용](rel_withstand_component_failures_avoid_control_plane.md).
이 옵션 및 다른 옵션에 대한 자세한 내용은 [재해 복구 백서의 이 섹션을 참조하세요](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light).
1. **워크로드의 장애 복구를 위한 계획을 수립합니다.**
장애 복구는 재해 이벤트가 수그러든 후 워크로드 작업을 기본 리전으로 돌려놓는 것입니다. 인프라 및 코드를 기본 리전에 프로비저닝하는 작업은 일반적으로 처음 사용된 것과 같은 단계를 따르며 코드형 인프라 및 코드 배포 파이프라인을 사용합니다. 장애 복구의 어려운 점은 데이터 스토어 복원과 작동하는 복구 리전에서 그 일관성을 확보하는 것입니다.
장애 조치된 상태에서는 복구 리전에서 데이터베이스가 실행되고 복구 리전에 최신 데이터가 있게 됩니다. 이때 목표는 복구 리전에서 기본 리전으로 재동기화하여 최신 상태를 확보하는 것입니다.
일부 AWS 서비스에서는 이 작업이 자동으로 이루어집니다. 만약 [Amazon DynamoDB 글로벌 테이블을](https://aws.amazon.com/dynamodb/global-tables/)사용한다면 기본 리전의 테이블을 사용할 수 없게 되어도 온라인 상태로 돌아오면 DynamoDB가 보류 중인 쓰기 작업의 전파를 재개합니다. 만약 [Amazon Aurora 글로벌 데이터베이스를](https://aws.amazon.com/rds/aurora/global-database/) 사용하고 [관리형 계획 장애 조치를](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover)사용한다면 Aurora 글로벌 데이터베이스의 기존 복제 토폴로지가 유지됩니다. 따라서 기본 리전에 있는 이전의 읽기/쓰기 인스턴스가 복제본이 되고 복구 리전에서 업데이트를 수신합니다.
이 작업이 자동화되지 않는 경우 기본 리전에서 복구 리전의 데이터베이스의 복제본으로 데이터베이스를 다시 구축해야 합니다. 이때 이전의 기본 데이터베이스가 삭제되고 새로운 복제본이 생성되는 경우가 많습니다. 예를 들어, 계획 장애 조치를 사용하는 Amazon Aurora 글로벌 데이터베이스에서 이 작업을 수행하는 방법을 *알아보려면* 다음 실습을 참조하세요. [글로벌 데이터베이스 장애 복구](https://awsauroralabsmy.com/global/failback/).
장애 조치 이후에 계속해서 복구 리전에서 실행이 가능하다면 이 리전을 새로운 기본 리전으로 만드는 것을 고려하세요. 이전의 기본 리전을 복구 리전으로 만들려면 위의 단계를 모두 따르면 됩니다. 일부 조직에서는 예약된 교체를 수행하여 기본 및 복구 리전을 주기적으로(예: 3개월마다) 교체합니다.
장애 조치 및 장애 복구가 필요한 모든 단계는 팀의 모든 멤버가 사용할 수 있는 플레이북에 유지 관리해야 하며 주기적으로 검토해야 합니다.
**구현 계획의 작업 수준:**높음
## 리소스
**관련 모범 사례:**
+ [REL09-BP01 백업해야 하는 모든 데이터 확인 및 백업 또는 소스에서 데이터 재현](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 복구 중 컨트롤 플레인이 아닌 데이터 영역 사용](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 가동 중단 시간 및 데이터 손실 시의 복구 목표 정의](rel_planning_for_recovery_objective_defined_recovery.md)
**관련 문서:**
+ [AWS 아키텍처 블로그: 재해 복구 시리즈](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Disaster Recovery of Workloads on AWS: Recovery in the Cloud(AWS에서 워크로드의 재해 복구: 클라우드에서의 복구)(AWS 백서)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [클라우드에서의 재해 복구 옵션](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [Build a serverless multi-region, active-active backend solution in an hour(한 시간 내에 서버리스 다중 리전, 활성/활성 백엔드 솔루션 구축)](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Multi-region serverless backend — reloaded(다중 리전 서버리스 백엔드 - 다시 로드됨)](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS: 리전 간 읽기 전용 복제본 복제](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53: DNS 장애 조치 구성](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3: 리전 간 복제](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [AWS Backup란 무엇입니까?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Route 53 Application Recovery Controller란 무엇입니까?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform: 시작하기 - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [APN 파트너: 재해 복구를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: 재해 복구에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**관련 동영상:**
+ [AWS에 있는 워크로드의 재해 복구](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications(다중 리전 액티브-액티브 애플리케이션을 위한 아키텍처 패턴)(ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS Elastic Disaster Recovery 시작하기 \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
**관련 예시:**
+ [AWS Well-Architected 실습 - 재해 복구](https://wellarchitectedlabs.com/reliability/disaster-recovery/) - DR 전략을 설명하는 워크숍 시리즈
# REL13-BP03 재해 복구 구현을 테스트하여 구현 확인
복구 사이트로의 장애 조치를 주기적으로 테스트하여 적절한 작업이 수행되고 RTO 및 RPO를 준수하는지 확인합니다.
거의 사용되지 않는 복구 경로를 개발하는 것은 피해야 할 패턴입니다. 읽기 전용 쿼리에 사용되는 보조 데이터 스토어를 예로 들 수 있습니다. 데이터 스토어에 데이터를 쓸 때 기본 스토어에서 장애가 발생하면 보조 데이터 스토어로 장애 조치를 진행할 수 있습니다. 이 장애 조치를 자주 테스트하지 않으면 보조 데이터 스토어의 기능에 대한 가정이 잘못될 수 있습니다. 예를 들어 마지막으로 테스트했을 때는 보조 용량이 충분했지만 이 시나리오에서는 더 이상 로드를 모두 처리하지 못할 수도 있습니다. 경험에 따르면 자주 테스트하는 경로만이 유일하게 작동하는 오류 복구 방법입니다. 이러한 이유로 인해 복구 경로를 적게 갖는 것이 가장 좋습니다. 복구 패턴을 설정하고 정기적으로 테스트할 수 있습니다. 복잡하거나 중요한 복구 경로가 있는 경우 해당 복구 경로의 작동을 확신하기 위해 프로덕션 환경에서 해당 장애를 정기적으로 수행해야 합니다. 앞에서 설명한 예의 경우에는 필요 여부에 관계없이 대기 스토어로 정기 장애 조치를 수행해야 합니다.
**일반적인 안티 패턴:**
+ 프로덕션 환경에서 장애 조치를 수행하지 않음
**이 모범 사례 수립의 이점:** 재해 복구 계획을 정기적으로 테스트하면 필요할 때 제대로 작동하도록 보장하고 팀이 전략 실행 방법을 숙지하고 있는지 확인할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 복구가 가능하도록 워크로드를 설계합니다. 주기적으로 복구 경로를 테스트합니다. 복구 중심 컴퓨팅(ROC)은 복구를 개선하는 시스템의 특성을 식별합니다. 이러한 특성에는 격리 및 중복성, 변경 사항을 롤백하는 시스템 전체 기능, 상태 모니터링 및 확인 기능, 진단 제공 기능, 자동 복구, 모듈식 설계 및 재시작 기능이 포함됩니다. 지정된 시간에 지정한 상태로 복구를 수행할 수 있도록 복구 경로에 대해 실습하십시오. 이 복구 과정에 런북을 사용하여 문제를 문서화하고 다음 테스트 전에 해결 방법을 찾습니다.
+ [The Berkeley/Stanford recovery-oriented computing project(Berkeley/Stanford 복구 중심 컴퓨팅 프로젝트)](http://roc.cs.berkeley.edu/)
+ CloudEndure Disaster Recovery를 사용하여 DR 전략을 구현 및 테스트합니다.
+ [Testing the Disaster Recovery Solution with CloudEndure(CloudEndure를 통해 재해 복구 솔루션 테스트)](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [AWS로의 CloudEndure Disaster Recovery](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
## 리소스
**관련 문서:**
+ [APN 파트너: 재해 복구를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS 아키텍처 블로그: 재해 복구 시리즈](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: 재해 복구에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [Disaster Recovery of Workloads on AWS: Recovery in the Cloud(AWS에서 워크로드의 재해 복구: 클라우드에서의 복구)(AWS 백서)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Testing the Disaster Recovery Solution with CloudEndure(CloudEndure를 통해 재해 복구 솔루션 테스트)](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [The Berkeley/Stanford recovery-oriented computing project(Berkeley/Stanford 복구 중심 컴퓨팅 프로젝트)](http://roc.cs.berkeley.edu/)
+ [AWS Fault Injection Simulator란 무엇입니까?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**관련 동영상:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications(다중 리전 액티브-액티브 애플리케이션을 위한 아키텍처 패턴)(ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS(AWS의 백업 및 복원과 재해 복구 솔루션)(STG208)](https://youtu.be/7gNXfo5HZN8)
**관련 예시:**
+ [AWS Well-Architected 실습 - 복원력 테스트](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL13-BP04 DR 사이트 또는 리전에서 구성 드리프트 관리
DR 사이트 또는 리전에 필요한 인프라, 데이터 및 구성이 갖추어져 있는지 확인합니다. 예를 들어 AMI와 Service Quotas가 최신 상태인지 확인합니다.
AWS Config는 AWS 리소스 구성을 지속적으로 모니터링하고 기록합니다. 이 서비스를 사용하면 드리프트를 감지하고, [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 을 트리거하여 드리프트를 수정한 후, 경보를 생성할 수 있습니다. AWS CloudFormation은 배포된 스택의 드리프트를 추가로 감지할 수 있습니다.
**일반적인 안티 패턴:**
+ 기본 위치에서 구성을 생성하거나 인프라를 변경할 때 복구 위치에서 업데이트에 실패함
+ 기본 및 복구 위치에서 잠재적 제한(예: 서비스의 차이)을 고려하지 않음
**이 모범 사례 수립의 이점:** DR 환경이 기존 환경과 일치하는지 확인하면 완전한 복구를 보장할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 배포 파이프라인이 기본 사이트와 백업 사이트 모두에 제공되는지 확인합니다. 애플리케이션을 프로덕션에 배포하기 위한 배포 파이프라인은 개발 및 테스트 환경을 포함하여 지정된 모든 재해 복구 전략 위치에 배포해야 합니다.
+ AWS Config를 활성화하여 잠재적 드리프트 위치를 추적합니다. AWS Config 규칙을 사용하여 재해 복구 전략을 실행하고 드리프트가 감지되면 알림을 생성하는 시스템을 구축합니다.
+ [AWS Config 규칙에 따른 규정 미준수 AWS 리소스 문제 해결](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ AWS CloudFormation을 사용하여 인프라를 배포합니다. AWS CloudFormation은 CloudFormation 템플릿에 명시된 내용과 실제로 배포된 항목 사이의 드리프트를 감지할 수 있습니다.
+ [AWS CloudFormation: 전체 CloudFormation 스택의 드리프트 감지](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
## 리소스
**관련 문서:**
+ [APN 파트너: 재해 복구를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS 아키텍처 블로그: 재해 복구 시리즈](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS CloudFormation: 전체 CloudFormation 스택의 드리프트 감지](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Marketplace: 재해 복구에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS에서 워크로드의 재해 복구: 클라우드에서의 복구(AWS 백서)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [AWS에서 인프라 구성 관리 솔루션을 구현하려면 어떻게 해야 합니까?](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [AWS Config 규칙에 따른 규정 미준수 AWS 리소스 문제 해결](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**관련 동영상:**
+ [AWS re:Invent 2018: 다중 리전 액티브-액티브 애플리케이션을 위한 아키텍처 패턴(ARC209-R2)](https://youtu.be/2e29I3dA8o4)
# REL13-BP05 복구 자동화
AWS 또는 서드 파티 도구를 사용하여 시스템 복구를 자동화하고 트래픽을 DR 사이트 또는 리전으로 라우팅합니다.
구성된 상태 확인에 따라 Elastic Load Balancing 및 AWS Auto Scaling과 같은 AWS 서비스를 사용하여 정상 상태인 가용 영역에 로드를 분산하고, Amazon Route 53 및 AWS Global Accelerator와 같은 서비스를 사용하여 정상 상태인 AWS 리전으로 로드를 라우팅할 수 있습니다. Amazon Route 53 Application Recovery Controller를 사용하면 준비 상태 확인 및 라우팅 제어 기능을 통해 장애 조치를 관리하고 조정할 수 있습니다. 이러한 기능은 애플리케이션의 장애 복구 성능을 지속적으로 모니터링하므로 이를 통해 여러 AWS 리전, 가용 영역 및 온프레미스에서 애플리케이션 복구를 제어할 수 있습니다.
기존의 물리적 또는 가상 데이터 센터 또는 프라이빗 클라우드의 워크로드의 경우 [AWS Elastic Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)를(AWS Marketplace를 통해 제공) 사용하면 조직에서 AWS에 자동화된 재해 복구 전략을 설정할 수 있습니다. CloudEndure는 AWS에서 교차 리전/교차 AZ 재해 복구도 지원합니다.
**일반적인 안티 패턴:**
+ 자동 장애 조치와 자동 장애 복구를 동일하게 구현하면 장애가 발생할 때 플래핑을 유발할 수 있습니다.
**이 모범 사례 수립의 이점:** 자동 복구는 수작업으로 인한 오류 발생 가능성을 없앰으로써 복구 시간을 단축합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 복구 경로를 자동화합니다. 짧은 복구 시간이 요구되는 고가용성 시나리오에서는 인간의 판단 및 수작업을 사용할 수 없습니다. 모든 상황에서 시스템이 자동으로 복구되어야 합니다.
+ 자동 장애 조치 및 장애 복구를 위해 CloudEndure Disaster Recovery를 사용합니다. CloudEndure Disaster Recovery는 시스템(운영 체제, 시스템 상태 구성, 데이터베이스, 애플리케이션 및 파일 포함)을 대상 AWS 계정과 원하는 리전의 저렴한 스테이징 영역으로 지속적으로 복제합니다. 재해가 발생할 경우 몇 분 만에 수천 대의 시스템을 자동으로 완전히 프로비저닝된 상태로 시작하도록 CloudEndure Disaster Recovery에 지시할 수 있습니다.
+ [Performing a Disaster Recovery Failover and Failback(재해 복구를 위한 조치 및 절차 수행)](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
## 리소스
**관련 문서:**
+ [APN 파트너: 재해 복구를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS 아키텍처 블로그: 재해 복구 시리즈](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: 재해 복구에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS로의 CloudEndure Disaster Recovery](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
+ [Disaster Recovery of Workloads on AWS: Recovery in the Cloud(AWS에서 워크로드의 재해 복구: 클라우드에서의 복구)(AWS 백서)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
**관련 동영상:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications(다중 리전 액티브-액티브 애플리케이션을 위한 아키텍처 패턴)(ARC209-R2)](https://youtu.be/2e29I3dA8o4)