# 안정성
**Topics**
+ [기반](a-foundations.md)
+ [워크로드 아키텍처](a-workload-architecture.md)
+ [변경 사항 관리](a-change-management.md)
+ [장애 관리](a-failure-management.md)
# 기반
**Topics**
+ [REL 1 서비스 할당량과 제약 조건은 어떻게 관리합니까?](w2aac19b9b5b5.md)
+ [REL 2 네트워크 토폴로지는 어떻게 계획합니까?](w2aac19b9b5b7.md)
# REL 1 서비스 할당량과 제약 조건은 어떻게 관리합니까?
클라우드 기반 워크로드 아키텍처에는 서비스 할당량(서비스 한도라고도 함)이라는 것이 있습니다. 이러한 할당량은 실수로 필요한 것보다 많은 리소스를 프로비저닝하는 것을 방지하고 API 작업에 대한 요청 속도를 제한하여 서비스를 침해로부터 보호하기 위해 존재합니다. 광섬유 케이블을 통해 비트를 전송할 수 있는 속도나 물리적 디스크의 스토리지 양과 같은 리소스 제약 조건도 있습니다.
**Topics**
+ [REL01-BP01 Service Quotas 및 제약 조건 인식](rel_manage_service_limits_aware_quotas_and_constraints.md)
+ [REL01-BP02 계정 및 리전 전체에서 서비스 할당량 관리](rel_manage_service_limits_limits_considered.md)
+ [REL01-BP03 아키텍처를 통해 고정된 서비스 할당량 및 제약 조건 수용](rel_manage_service_limits_aware_fixed_limits.md)
+ [REL01-BP04 할당량 모니터링 및 관리](rel_manage_service_limits_monitor_manage_limits.md)
+ [REL01-BP05 할당량 관리 자동화](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL01-BP06 현재의 할당량과 최대 사용량 간에 장애 조치를 수용할 만큼 여유가 충분히 있는지 확인](rel_manage_service_limits_suff_buffer_limits.md)
# REL01-BP01 Service Quotas 및 제약 조건 인식
워크로드 아키텍처에 대한 기본 할당량이 있으며 할당량 증가를 요청할 수 있습니다. 또한 디스크 또는 네트워크와 같은 리소스 제약 조건은 잠재적인 영향을 미칠 수 있습니다.
Service Quotas는 100개 이상의 AWS 서비스에 대한 할당량을 단일 위치에서 관리할 수 있는 AWS 서비스입니다. 할당량 값을 조회하는 것에 더해 Service Quotas 콘솔 또는 AWS SDK를 통해 할당량 증가를 요청하고 추적할 수 있습니다. AWS Trusted Advisor는 일부 서비스의 특정 측면에 대한 사용량 및 할당량을 표시하는 서비스 할당량 확인 기능을 제공합니다. 각 서비스의 기본 서비스 할당량은 해당하는 서비스의 AWS 설명서에도 문서화되어 있습니다. 예를 들어 [Amazon VPC 할당량을 참조하십시오.](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html). 조절된 API에 대한 속도 제한은 API Gateway 자체에서 사용량 계획을 구성하는 방법으로 설정됩니다. 해당하는 서비스에서 구성으로 설정되는 기타 제한으로는 프로비저닝된 IOPS, 할당된 RDS 스토리지 및 EBS 볼륨 할당이 있습니다. Amazon Elastic Compute Cloud(Amazon EC2)에는 인스턴스, Amazon Elastic Block Store(Amazon EBS) 및 탄력적 IP 주소 제한을 관리하는 데 도움이 되는 자체 서비스 한도 대시보드가 있습니다. 서비스 할당량이 애플리케이션 성능에 영향을 미치고 요구 사항에 맞춰 조정할 수 없는 사용 사례가 있는 경우 AWS Support에 문의하여 완화 방법이 있는지 확인하십시오.
**일반적인 안티 패턴:**
+ 사용된 AWS 서비스의 서비스 할당량을 고려하지 않고 워크로드 배포
+ AWS 서비스의 설계 제약 조건을 조사 및 반영하지 않고 워크로드 설계
+ 필요한 할당량을 구성하거나 사전에 AWS Support에 문의하지 않은 채로 알려진 기존 워크로드를 대체하는 사용량이 많은 워크로드 배포
+ 워크로드로 트래픽을 유도하는 이벤트를 계획하면서 필요한 할당량을 구성하거나 사전에 AWS Support에 문의하지 않음
**이 모범 사례 정립의 이점:** 서비스 할당량, API 조절 한도 및 설계 제약 조건을 숙지하면 워크로드를 설계, 구현, 운영하는 데 이러한 제한 사항을 고려할 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 게시된 설명서와 Service Quotas의 AWS 서비스 할당량 섹션 검토
+ [AWS Service Quotas(이전의 ‘한도’)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ 배치 코드를 확인하여 워크로드에 필요한 모든 서비스를 결정합니다.
+ AWS Config를 사용하여 AWS 계정에서 사용되는 모든 AWS 리소스를 찾습니다.
+ [AWS Config 지원 AWS 리소스 유형 및 리소스 관계](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)
+ AWS CloudFormation을 사용하여 사용되는 AWS 리소스를 파악할 수도 있습니다. AWS Management Console에서 또는 list-stack-resources CLI 명령을 통해 생성된 리소스를 확인합니다. 템플릿 자체에 배포하도록 구성된 리소스를 볼 수도 있습니다.
+ [AWS Management Console에서 AWS CloudFormation 스택 데이터 및 리소스 보기](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html)
+ [AWS CLI for CloudFormation: list-stack-resources](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html)
+ 적용되는 서비스 할당량을 확인합니다. Trusted Advisor 및 Service Quotas를 통해 프로그래밍 방식으로 액세스되는 정보를 활용합니다.
## 리소스
**관련 문서:**
+ [AWS Marketplace: 한도 추적에 유용한 구성 관리 데이터베이스(CMDB) 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas(이전의 ‘서비스 한도’)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor 모범 사례 점검 항목(‘서비스 한도’ 섹션 참조)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS Answers의 AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 서비스 한도](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Service Quotas란 무엇입니까?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**관련 동영상:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP02 계정 및 리전 전체에서 서비스 할당량 관리
여러 AWS 계정 또는 AWS 리전을 사용하는 경우 프로덕션 워크로드가 실행되는 모든 환경에서 적절한 할당량을 요청해야 합니다.
서비스 할당량은 계정별로 추적됩니다. 다른 언급이 없는 한, 각 할당량은 AWS 리전별로 다릅니다. 프로덕션 환경에 더해 적용 가능한 모든 비 프로덕션 환경에서도 할당량을 관리하여 테스트 및 개발에 방해가 되지 않도록 합니다.
**일반적인 안티 패턴:**
+ 다른 격리 영역에서 용량을 유지하는 메커니즘 없이 격리 영역의 리소스 사용률을 확장하도록 허용
+ 격리 영역에서 모든 할당량을 독립적으로 수동으로 설정
+ 배포가 손실된 경우 다른 리전에서 증가하는 트래픽을 수용할 수 있도록 리전별로 격리된 배포의 크기를 설정하지 않음
**이 모범 사례 수립의 이점:** 격리 영역을 사용할 수 없는 경우에도 현재 로드를 처리할 수 있도록 하면, 장애 조치 중에 발생하는 오류 수를 줄여 고객에게 서비스 거부를 초래하지 않도록 할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 서비스 요구 사항, 지연 시간, 규정, 재해 복구(DR) 요구 사항을 기준으로 관련 계정 및 리전을 선택합니다.
+ 모든 관련 계정, 리전 및 가용 영역의 서비스 할당량을 확인합니다. 한도는 계정 및 리전별로 관리됩니다.
+ [Service Quotas란 무엇입니까?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
## 리소스
**관련 문서:**
+ [AWS Marketplace: 한도 추적에 유용한 CMDB 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas(이전의 ‘서비스 한도’)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor 모범 사례 점검 항목(‘서비스 한도’ 섹션 참조)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS Answers의 AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 서비스 한도](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Service Quotas란 무엇입니까?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**관련 동영상:**
+ [AWS 라이브 re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP03 아키텍처를 통해 고정된 서비스 할당량 및 제약 조건 수용
변경할 수 없는 서비스 할당량과 물리적 리소스를 인지하고 안정성에 영향을 미치지 않도록 설계합니다.
예를 들어 네트워크 대역폭, AWS Lambda 페이로드 크기, API Gateway의 버스트 속도 조절, Amazon Redshift 클러스터에 대한 동시 사용자 연결 등이 여기에 포함됩니다.
**일반적인 안티 패턴:**
+ 벤치마킹을 너무 짧은 시간 동안만 수행하고, 버스트 제한을 활용한 다음 서비스가 일정 기간 동안 해당 용량에서 정상적인 성능을 보일 것으로 예상
+ 확장 시 해당 설계에서 장애를 유발하는 설계 제약 조건이 있다는 사실을 인지하지 못한 채 사용자 또는 고객당 하나의 서비스 리소스를 사용하는 설계 방식 선택
**이 모범 사례 수립의 이점:** 연결 제약 조건, IP 주소 제약 조건, 타사 서비스의 제약 조건 등, 워크로드의 다른 부분에 적용되는 AWS 서비스의 고정된 할당량과 제약 조건을 추적하면 할당량에 근접하는 추세를 보이는 경우 이를 감지하고 할당량을 초과하기 전에 할당량을 조절할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 고정된 서비스 할당량 숙지 고정된 서비스 할당량과 제약 조건을 숙지하고 이를 중심으로 설계합니다.
+ [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
## 리소스
**관련 문서:**
+ [AWS Marketplace: 한도 추적에 유용한 구성 관리 데이터베이스(CMDB) 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas(이전의 ‘서비스 한도’)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor 모범 사례 점검 항목(‘서비스 한도’ 섹션 참조)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS Answers의 AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 서비스 한도](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Service Quotas란 무엇입니까?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**관련 동영상:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP04 할당량 모니터링 및 관리
잠재적 사용량을 평가하고 할당량을 적절히 늘려 사용량 증가를 계획합니다.
지원되는 서비스의 경우 사용량을 모니터링하고 할당량에 근접할 때 알림을 받도록 CloudWatch 경보를 구성하여 할당량을 관리할 수 있습니다. 이러한 경보는 Service Quotas 또는 Trusted Advisor에서 트리거될 수 있습니다. CloudWatch Logs의 지표 필터를 사용하여 로그의 패턴을 검색하고 추출하여 사용량이 할당량 임계값에 근접하는지 여부를 확인할 수도 있습니다.
**일반적인 안티 패턴:**
+ Service Quotas에 근접할 경우 알리는 경보를 구성하지만, 알림에 응답하는 프로세스를 갖추지 않음
+ Service Quotas에서 지원하는 서비스에 대해서만 경보를 구성하고 다른 서비스는 모니터링하지 않음
**이 모범 사례 수립의 이점:** AWS 서비스 할당량을 자동으로 추적하고 이러한 할당량을 기준으로 사용량을 모니터링하면 할당량 한도에 근접할 경우 이를 알 수 있습니다. 또한 이 모니터링 데이터를 통해, 할당량을 줄여 비용을 절감할 수 있는지 평가할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 할당량 모니터링 및 관리 AWS에서 잠재 사용량을 확인하고, 리전별 서비스 할당량을 적절히 늘린 후 계획에 따른 사용량 증가분이 반영되도록 합니다.
+ 현재 리소스 사용 내역(예: 버킷, 인스턴스)을 파악합니다. 현재 리소스 사용 내역을 모두 보려면 Amazon EC2 DescribeInstances API와 같은 서비스 API 작업을 사용합니다.
+ 현재 할당량 포착 AWS Service Quotas, AWS Trusted Advisor, AWS 설명서를 사용합니다.
+ 100개 이상의 AWS 서비스에 대한 할당량을 단일 위치에서 관리할 수 있는 AWS 서비스인 AWS Service Quotas를 사용합니다.
+ Trusted Advisor 서비스 한도를 이용해 현재 서비스 한도를 파악합니다.
+ 서비스 API 작업을 사용하여 현재 적용되는 서비스 할당량을 파악합니다.
+ 할당량 증가 요청 내역과 처리 현황을 기록합니다. 할당량 증가가 승인되고 나면 변경된 할당량을 반영하도록 레코드를 업데이트해야 합니다.
## 리소스
**관련 문서:**
+ [AWS Marketplace: 한도 추적에 유용한 구성 관리 데이터베이스(CMDB) 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas(이전의 ‘서비스 한도’)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [서비스 한도에 대한 AWS Trusted Advisor 모범 사례 점검 항목](https://docs.aws.amazon.com/awssupport/latest/user/service-limits.html)
+ [AWS Answers의 AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 서비스 한도](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Service Quotas란 무엇입니까?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [Amazon CloudWatch 경보를 사용하여 Service Quotas 모니터링](https://docs.aws.amazon.com/servicequotas/latest/userguide/configure-cloudwatch.html)
**관련 동영상:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP05 할당량 관리 자동화
임계값에 근접했을 때 알림을 받을 수 있는 도구를 구현합니다. AWS Service Quotas API를 사용하여 할당량 증가 요청을 자동화할 수 있습니다.
CMDB(구성 관리 데이터베이스) 또는 티켓팅 시스템을 Service Quotas와 통합하면 할당량 증가 요청 및 현재 할당량 추적을 자동화할 수 있습니다. Service Quotas는 AWS SDK 외에도 AWS Command Line Interface(AWS CLI)를 사용한 자동화를 제공합니다.
**일반적인 안티 패턴:**
+ 스프레드시트에서 할당량 및 사용량 추적
+ 일별, 주별 또는 월별 사용량에 대한 보고서를 실행한 다음 사용량을 할당량과 비교
**이 모범 사례 정립의 이점:** AWS 서비스 할당량을 자동으로 추적하고 해당 할당량을 기준으로 사용량을 모니터링하면 할당량에 근접할 경우 이를 알 수 있습니다. 자동화를 설정하여 필요할 때 할당량 증가를 요청할 수 있습니다. 사용량이 반대로 감소 추세를 보일 경우 할당량을 일부 낮추면 위험 감소(자격 증명이 침해당한 경우) 및 비용 절감의 이점을 실현할 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 자동화된 모니터링 설정 SDK를 사용하여 임계값에 근접할 때 알림을 제공하는 도구를 구현합니다.
+ Service Quotas를 사용하고 AWS Limit Monitor 또는 AWS Marketplace에서 제공하는 것과 같은 자동 할당량 모니터링 솔루션으로 이 서비스를 보강합니다.
+ [Service Quotas란 무엇입니까?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [AWS에서의 할당량 모니터링 - AWS 솔루션](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ Amazon SNS 및 AWS Service Quotas API를 사용하여 할당량 임계값을 기준으로 트리거되는 응답을 설정합니다.
+ 테스트를 자동화합니다.
+ 한도 임계값을 구성합니다.
+ AWS Config, 배포 파이프라인, Amazon EventBridge 또는 타사의 변경 이벤트와 통합합니다.
+ 응답을 테스트하기 위해 인위적으로 할당량 임계값을 설정합니다.
+ 알림 발생 시에 적절한 조치를 취하고 필요한 경우 AWS Support에 연락하도록 트리거를 설정합니다.
+ 변경 이벤트를 수동으로 트리거합니다.
+ 게임 데이를 실행하여 할당량 증가 변경 프로세스를 테스트합니다.
## 리소스
**관련 문서:**
+ [APN 파트너: 구성 관리를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Configuration+Management)
+ [AWS Marketplace: 한도 추적에 유용한 구성 관리 데이터베이스(CMDB) 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas(이전의 ‘서비스 한도’)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor 모범 사례 점검 항목(‘서비스 한도’ 섹션 참조)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS에서의 할당량 모니터링 - AWS 솔루션](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 서비스 한도](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Service Quotas란 무엇입니까?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**관련 동영상:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP06 현재의 할당량과 최대 사용량 간에 장애 조치를 수용할 만큼 여유가 충분히 있는지 확인
리소스는 장애가 발생하더라도 정상적으로 종료할 때까지는 할당량 계산에 계속 포함될 수 있습니다. 그러므로 할당량에는 장애 발생 리소스가 종료되기 전까지 장애가 발생한 모든 리소스와 교체 리소스의 중복이 포함되어야 합니다. 이 차이를 계산할 때는 가용 영역 장애를 고려해야 합니다.
**일반적인 안티 패턴:**
+ 장애 조치 시나리오를 고려하지 않고 현재의 수요를 기준으로 서비스 할당량 설정
**이 모범 사례 수립의 이점:** 이벤트가 가용성에 영향을 미칠 가능성이 있을 때 클라우드를 사용하면 해당 이벤트의 영향을 완화하거나 이벤트로부터 복구하는 전략을 구현할 수 있습니다. 그러한 전략에는 장애가 발생한 리소스를 대체할 추가 리소스를 생성하는 작업이 포함되는 경우가 많습니다. 할당량 전략에는 이러한 추가 리소스를 감안해야 합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 서비스 할당량과 최대 사용량 간에 장애 조치를 수용할 만큼 여유가 충분히 있는지 확인합니다.
+ 배포 패턴, 가용성 요청 사항, 서비스 사용량 증가를 고려해 서비스 할당량을 결정합니다.
+ 필요한 경우 할당량 증가를 요청합니다. 할당량 증가 요청이 반영될 시간을 고려합니다.
+ 신뢰성 요구 사항(‘9의 개수’라고도 함)을 결정합니다.
+ 장애 시나리오(예: 구성 요소, 가용 영역 또는 리전 손실)를 설정합니다.
+ 배포 방법(Canary, 블루/그린, 레드/블랙 또는 롤링 등)을 설정합니다.
+ 현재 한도에 적절한 버퍼(예: 15%)가 포함되어야 합니다.
+ 사용량 증가 계획(사용 추세 모니터링 등)을 수립합니다.
## 리소스
**관련 문서:**
+ [AWS Marketplace: 한도 추적에 유용한 구성 관리 데이터베이스(CMDB) 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas(이전의 ‘서비스 한도’)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor 모범 사례 점검 항목(‘서비스 한도’ 섹션 참조)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [Amazon EC2 서비스 한도](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Service Quotas란 무엇입니까?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**관련 동영상:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL 2 네트워크 토폴로지는 어떻게 계획합니까?
워크로드는 여러 환경에 존재할 수 있습니다. 여기에는 다중 클라우드 환경(퍼블릭 액세스 및 프라이빗)과 기존 데이터 센터 인프라가 포함됩니다. 따라서 시스템 내부 및 시스템 간 연결, 퍼블릭 IP 주소 관리, 프라이빗 IP 주소 관리 및 도메인 이름 확인과 같은 네트워크 고려 사항을 계획에 포함해야 합니다.
**Topics**
+ [REL02-BP01 워크로드 퍼블릭 엔드포인트에 고가용성 네트워크 연결 사용](rel_planning_network_topology_ha_conn_users.md)
+ [REL02-BP02 클라우드와 온프레미스 환경의 프라이빗 네트워크 간에 이중화된 연결 프로비저닝](rel_planning_network_topology_ha_conn_private_networks.md)
+ [REL02-BP03 확장 및 가용성을 위한 IP 서브넷 할당 계정 확인](rel_planning_network_topology_ip_subnet_allocation.md)
+ [REL02-BP04 다대다 메시보다 허브 앤드 스포크 토폴로지 선호](rel_planning_network_topology_prefer_hub_and_spoke.md)
+ [REL02-BP05 연결된 모든 프라이빗 주소 공간에서 겹치지 않는 프라이빗 IP 주소 범위 적용](rel_planning_network_topology_non_overlap_ip.md)
# REL02-BP01 워크로드 퍼블릭 엔드포인트에 고가용성 네트워크 연결 사용
이러한 엔드포인트와 엔드포인트로의 라우팅은 고가용성으로 구현해야 합니다. 이러한 고가용성을 달성하려면 고가용성 DNS, CDN(콘텐츠 전송 네트워크), API Gateway, 로드 밸런싱 또는 리버스 프록시를 사용합니다.
Amazon Route 53, AWS Global Accelerator, Amazon CloudFront, Amazon API Gateway, Elastic Load Balancing(ELB)은 모두 가용성이 매우 높은 퍼블릭 엔드포인트를 제공합니다. AWS Marketplace 소프트웨어 어플라이언스를 평가하여 로드 밸런싱 및 프록시에 사용할 어플라이언스를 선택할 수도 있습니다.
워크로드가 제공하는 서비스의 소비자는 최종 사용자든 다른 서비스든 이러한 서비스 엔드포인트로 요청을 보냅니다. 여러 AWS 리소스를 사용하여 고가용성 엔드포인트를 제공할 수 있습니다.
Elastic Load Balancing은 가용 영역에 걸쳐 로드 밸런싱을 제공하고, 계층 4(TCP) 또는 계층 7(http/https) 라우팅을 수행하고, AWS WAF와 통합되며, AWS Auto Scaling 통합을 통해 자가 복구 인프라를 생성하고 트래픽 증가를 흡수하는 동시에 트래픽이 감소할 때는 리소스를 해제합니다.
Amazon Route 53은 확장 가능한 고가용성 도메인 이름 시스템(DNS) 서비스로, 사용자 요청을 Amazon EC2 인스턴스, Elastic Load Balancing 로드 밸런서 또는 Amazon S3 버킷처럼 AWS에서 실행되는 인프라에 효과적으로 연결하며, 사용자를 AWS 외부의 인프라로 라우팅하는 데에도 사용할 수 있습니다.
AWS Global Accelerator는 AWS 글로벌 네트워크를 통해 트래픽을 최적의 엔드포인트로 보내는 데 사용할 수 있는 네트워크 계층 서비스입니다.
DDoS(분산 서비스 거부) 공격은 합법적인 트래픽을 차단하고 사용자의 가용성을 낮출 위험이 있습니다. AWS Shield는 워크로드의 AWS 서비스 엔드포인트에 이러한 공격에 대한 자동 보호를 추가 비용 없이 제공합니다. APN 파트너 및 AWS Marketplace에서 제공하는 가상 어플라이언스를 사용하여 요구에 맞게 이러한 기능을 보강할 수 있습니다.
**일반적인 안티 패턴:**
+ 인스턴스 또는 컨테이너에서 퍼블릭 인터넷 주소를 사용하고 DNS를 통해 이러한 주소에 대한 연결을 관리합니다.
+ 서비스를 찾는 데 도메인 이름 대신 인터넷 프로토콜 주소를 사용합니다.
+ 콘텐츠 전송 네트워크를 사용하지 않고 대규모 지리적 영역에 콘텐츠(웹 페이지, 정적 자산, 미디어 파일) 제공
**이 모범 사례 수립의 이점:** 워크로드에 고가용성 서비스를 구현하면 워크로드가 사용자에게 워크로드의 가용성을 보장할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
워크로드 사용자를 위해 고가용성 연결을 제공하는지 확인합니다. Amazon Route 53, AWS Global Accelerator, Amazon CloudFront, Amazon API Gateway, Elastic Load Balancing(ELB)은 모두 매우 가용성이 높은 퍼블릭 엔드포인트를 제공합니다. AWS Marketplace 소프트웨어 어플라이언스를 평가하여 로드 밸런싱 및 프록시에 사용할 어플라이언스를 선택할 수도 있습니다.
+ 사용자에 대한 연결 가용성이 높은지 확인합니다.
+ 고가용성 DNS를 사용하여 애플리케이션 엔드포인트의 도메인 이름을 관리하고 있는지 확인합니다.
+ 사용자가 인터넷을 통해 애플리케이션에 액세스하는 경우 서비스 API 작업을 이용하여 인터넷 게이트웨이가 올바르게 사용되는지 확인합니다. 또한 애플리케이션 엔드포인트를 호스팅하는 서브넷에 대한 라우팅 테이블 항목이 올바른지 확인합니다.
+ [DescribeInternetGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInternetGateways.html)
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
+ 애플리케이션에 고가용성 역방향 프록시 또는 로드 밸런서를 사용하고 있는지 확인합니다.
+ 사용자가 온프레미스 환경을 통해 애플리케이션에 액세스하는 경우 AWS와 온프레미스 환경 간의 연결성이 높은지 확인합니다.
+ Route 53을 사용하여 도메인 이름을 관리합니다.
+ [Amazon Route 53란 무엇입니까?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ 요구 사항을 충족하는 서드 파티 DNS 공급자를 사용합니다.
+ Elastic Load Balancing을 사용합니다.
+ [Elastic Load Balancing이란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ 요구 사항을 충족하는 AWS Marketplace 어플라이언스를 사용합니다.
## 리소스
**관련 문서:**
+ [APN 파트너: 네트워킹 계획을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Direct Connect 복원력 권장 사항](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [네트워크 인프라에 대한 AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011)
+ [Amazon Virtual Private Cloud 연결 옵션 백서](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [여러 데이터 센터 고가용 네트워크 연결](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Using the Direct Connect Resiliency Toolkit to get started(Direct Connect 복원 도구 키트를 사용하여 시작)](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ [VPC 엔드포인트 및 VPC 엔드포인트 서비스(AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [AWS Global Accelerator란 무엇입니까?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [Amazon VPC란 무엇입니까?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [Transit Gateway란 무엇일까요?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Amazon CloudFront란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ [Amazon Route 53란 무엇입니까?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [Elastic Load Balancing이란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [Working with Direct Connect Gateways(Direct Connect 게이트웨이 작업)](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html)
**관련 동영상:**
+ [AWS re:Invent 2018: Amazon VPC의 고급 VPC 설계 및 새로운 기능(NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: 여러 VPC를 위한 AWS Transit Gateway 참조 아키텍처(NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP02 클라우드와 온프레미스 환경의 프라이빗 네트워크 간에 이중화된 연결 프로비저닝
별도로 배포된 프라이빗 네트워크 간에 여러 AWS Direct Connect 연결 또는 VPN 터널을 사용합니다. 고가용성을 위해 여러 Direct Connect 위치를 사용합니다. 여러 AWS 리전을 사용하는 경우 2개 이상의 AWS 리전에 이중화되도록 해야 합니다. VPN을 종료하는 AWS Marketplace 어플라이언스를 평가해야 할 수 있습니다. AWS Marketplace 어플라이언스를 사용하는 경우 다른 가용 영역에서 고가용성을 위해 중복 인스턴스를 배포합니다.
AWS Direct Connect는 온프레미스 환경에서 AWS로의 전용 네트워크 연결을 쉽게 설정할 수 있게 지원하는 클라우드 서비스입니다. Direct Connect Gateway를 사용하면 온프레미스 데이터 센터를 여러 AWS 리전에 분산된 다수의 AWS VPC에 연결할 수 있습니다.
이러한 중복성은 연결 복원력에 영향을 주는 잠재적 장애를 해결합니다.
+ 토폴로지에서 장애가 발생하는 경우 복원할 방법
+ 특정 항목을 잘못 구성하여 연결을 제거하는 경우의 결과
+ 예기치 않은 트래픽 또는 서비스 사용량 증가 처리 가능 여부
+ DDoS(분산 서비스 거부) 공격 시도에서 정상 상태 유지 가능 여부
VPN을 통해 온프레미스 데이터 센터에 VPC를 연결하는 경우 어플라이언스를 실행해야 하는 인스턴스 크기 및 공급업체를 선택할 때 필요한 복원력 및 대역폭 요구 사항을 고려해야 합니다. 해당 구현에서 복원되지 않는 VPN 어플라이언스를 사용하는 경우에는 두 번째 어플라이언스를 통한 중복 연결을 설정해야 합니다. 이러한 모든 시나리오에서는 허용되는 복구 시간을 정의하고 테스트를 진행하여 해당 요구 사항을 충족할 수 있는지를 확인해야 합니다.
Direct Connect 연결을 사용하여 VPC를 데이터 센터에 연결하기로 선택한 경우 이 연결이 고가용성이어야 한다면 각 데이터 센터에서 중복 Direct Connect 연결을 사용하세요. 중복 연결에는 첫 번째 연결과 다른 위치의 두 번째 Direct Connect 연결이 사용되어야 합니다. 데이터 센터가 다수인 경우 연결이 각기 다른 위치에서 종료되는지 확인합니다. 연결은 [Direct Connect 복원 도구 키트](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) 를 사용하여 설정할 수 있습니다.
Site-to-Site VPN을 사용하여 인터넷을 통해 VPN으로 장애 조치하려는 경우, VPN 터널당 최대 1.25Gbps의 처리량이 지원되기는 하지만 여러 AWS 관리형 VPN 터널이 같은 VGW에서 종료되는 경우에는 아웃바운드 트래픽용 ECMP(Equal Cost Multi Path)가 지원되지 않는다는 점을 알아야 합니다. 장애 조치 중 1Gbps 미만의 속도가 허용되는 경우가 아니라면 AWS 관리형 VPN을 Direct Connect 연결의 백업으로 사용하지 않는 것이 좋습니다.
또한 VPC 엔드포인트를 사용하여 퍼블릭 인터넷을 통하지 않고 비공개로 VPC를 지원되는 AWS 서비스와 AWS PrivateLink 기반 VPC 엔드포인트 서비스에 연결할 수 있습니다. 엔드포인트는 가상 디바이스입니다. 수평적으로 확장되고 이중화된 고가용성의 VPC 구성 요소입니다. 엔드포인트를 사용하면 네트워크 트래픽에 미치는 가용성 위험이나 대역폭 제약 없이 VPC의 인스턴스와 서비스 간에 통신할 수 있습니다.
**일반적인 안티 패턴:**
+ 온사이트 네트워크와 AWS 간에 연결 공급자를 하나만 구성
+ AWS Direct Connect 연결의 연결 기능을 사용하지만 연결을 하나만 구성
+ VPN 연결을 위한 경로를 하나만 구성
**이 모범 사례 수립의 이점:** 클라우드 환경과 기업 또는 온프레미스 환경 간에 이중화된 연결을 구현하면 두 환경 간의 종속 서비스가 서로 안정적으로 통신할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ AWS와 온프레미스 환경 간 고가용성 연결을 구현해야 합니다. 별도로 배포된 프라이빗 네트워크 간에 여러 AWS Direct Connect 연결 또는 VPN 터널을 사용합니다. 고가용성을 위해 여러 Direct Connect 위치를 사용합니다. 여러 AWS 리전을 사용하는 경우 2개 이상의 AWS 리전에 이중화되도록 해야 합니다. VPN을 종료하는 AWS Marketplace 어플라이언스를 평가해야 할 수 있습니다. AWS Marketplace 어플라이언스를 사용하는 경우 다른 가용 영역에서 고가용성을 위해 중복 인스턴스를 배포합니다.
+ 온프레미스 환경에 중복 연결된 상태인지 확인합니다. 가용성 요구 사항을 충족하기 위해서는 여러 AWS 리전에 중복 연결이 필요할 수 있습니다.
+ [AWS Direct Connect 복원력 권장 사항](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [이중화 Site-to-Site VPN 연결을 사용하여 장애 조치 제공](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html)
+ 서비스 API 작업을 사용하여 Direct Connect 회선이 올바르게 사용되고 있는지 확인합니다.
+ [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html)
+ [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html)
+ [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html)
+ [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll)
+ [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html)
+ [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html)
+ [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html)
+ Direct Connect 연결이 하나만 있거나 하나도 없는 경우 가상 프라이빗 게이트웨이에 이중화 VPN 터널을 설정합니다.
+ [AWS Site-to-Site VPN이란 무엇입니까?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html)
+ 현재 연결(예: Direct Connect, 가상 프라이빗 게이트웨이, AWS Marketplace 어플라이언스)을 파악합니다.
+ 서비스 API 작업을 사용하여 Direct Connect 연결의 구성을 쿼리합니다.
+ [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html)
+ [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html)
+ [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html)
+ [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll)
+ [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html)
+ [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html)
+ [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html)
+ 서비스 API 작업을 사용하여 라우팅 테이블에서 사용하는 가상 프라이빗 게이트웨이를 수집합니다.
+ [DescribeVpnGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpnGateways.html)
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
+ 서비스 API 작업을 사용하여 라우팅 테이블에서 사용하는 AWS Marketplace 애플리케이션을 수집합니다.
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
## 리소스
**관련 문서:**
+ [APN 파트너: 네트워킹 계획을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Direct Connect 복원력 권장 사항](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [네트워크 인프라에 대한 AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011)
+ [Amazon Virtual Private Cloud 연결 옵션 백서](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [여러 데이터 센터 고가용 네트워크 연결](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [이중화 Site-to-Site VPN 연결을 사용하여 장애 조치 제공](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html)
+ [Using the Direct Connect Resiliency Toolkit to get started(Direct Connect 복원 도구 키트를 사용하여 시작)](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ [VPC 엔드포인트 및 VPC 엔드포인트 서비스(AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [Amazon VPC란 무엇입니까?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [Transit Gateway란 무엇일까요?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [AWS Site-to-Site VPN이란 무엇입니까?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html)
+ [Working with Direct Connect Gateways(Direct Connect 게이트웨이 작업)](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html)
**관련 동영상:**
+ [AWS re:Invent 2018: Amazon VPC의 고급 VPC 설계 및 새로운 기능(NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: 여러 VPC를 위한 AWS Transit Gateway 참조 아키텍처(NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP03 확장 및 가용성을 위한 IP 서브넷 할당 계정 확인
Amazon VPC IP 주소 범위는 가용 영역의 서브넷에 IP 주소를 할당하고 추후 확장을 고려하는 등 워크로드의 요구 사항을 수용할 수 있도록 충분히 커야 합니다. 여기에는 로드 밸런서, EC2 인스턴스 및 컨테이너 기반 애플리케이션이 포함됩니다.
네트워크 토폴로지를 계획할 때는 첫 단계로 IP 주소 공간 자체를 정의합니다. 각 VPC에는 RFC 1918 지침에 따라 프라이빗 IP 주소 범위를 할당해야 합니다. 이 프로세스의 일부로 다음 요구 사항을 준수하십시오.
+ 리전당 두 개 이상의 VPC에 대한 IP 주소 공간을 허용합니다.
+ VPC 내에서 여러 가용 영역에 걸쳐 있는 여러 서브넷에 공간을 허용합니다.
+ 사용되지 않은 CIDR 블록 공간은 향후 확장을 위해 항상 VPC 내에 남겨둡니다.
+ 기계 학습용 스팟 플릿, Amazon EMR 클러스터 또는 Amazon Redshift 클러스터 등 사용할 수 있는 임시 EC2 인스턴스 플릿의 요구 사항을 충족할 IP 주소 공간이 있는지 확인합니다.
+ 참고로 각 서브넷 CIDR 블록에서 처음 4개의 IP 주소와 마지막 IP 주소는 예약되므로 사용할 수 없습니다.
+ 대규모 VPC CIDR 블록 배포를 계획해야 합니다. VPC에 할당된 초기 VPC CIDR 블록은 변경 또는 삭제가 불가능하지만 중첩되지 않은 추가 CIDR 블록을 VPC에 추가할 수 있습니다. 서브넷 IPv4 CIDR은 변경할 수 없지만 IPv6 CIDR은 변경할 수 있습니다. 가능한 최대 규모(/16)의 VPC를 배포하면 IP 주소 수가 65,000개를 초과하게 됩니다. 기본 10.x.x.x IP 주소 공간에만 255개의 VPC를 프로비저닝할 수 있습니다. 따라서 규모를 너무 작게 하는 것보다 지나치다 싶을 만큼 큰 규모로 배포해야 VPC를 더 쉽게 관리할 수 있습니다.
**일반적인 안티 패턴:**
+ 크기가 작은 VPC 생성
+ 작은 서브넷을 생성한 다음, 확장 시에 서브넷을 구성에 추가
+ Elastic Load Balancer가 사용할 수 있는 IP 주소 수를 잘못 추정
+ 트래픽이 많은 여러 로드 밸런서를 동일한 서브넷에 배포
**이 모범 사례 정립의 이점:** 이렇게 하면 워크로드의 증가를 수용하고 확장 시 가용성을 계속 제공할 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 성장, 규정 준수 및 다른 제품과 통합을 수용할 수 있도록 네트워크 계획을 수립합니다. 성장은 과소 평가될 수 있고 규정 준수는 변경될 수 있으며 적절한 계획 없이는 프라이빗 네트워크 연결을 구현하기가 어려울 수 있습니다.
+ 서비스 요구 사항, 지연 시간, 규정, DR(재해 복구) 요구 사항을 기준으로 관련 AWS 계정 및 리전을 선택합니다.
+ 지역 VPC 배포에 대한 요구 사항을 파악합니다.
+ VPC 규모를 파악합니다.
+ 다중 VPC 연결을 배포할 것인지 여부를 결정합니다.
+ [Transit Gateway란 무엇일까요?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [단일 리전 다중 VPC 연결](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ 규정 요구 사항에 따라 분리된 네트워킹이 필요한지 결정합니다.
+ VPC를 최대한 큰 규모로 만듭니다. VPC에 할당된 초기 VPC CIDR 블록은 변경 또는 삭제가 불가능하지만 중첩되지 않은 추가 CIDR 블록을 VPC에 추가할 수 있습니다. 그러나 이 경우 주소 범위를 분할될 수 있습니다.
+ VPC를 최대한 큰 규모로 만듭니다. VPC에 할당된 초기 VPC CIDR 블록은 변경 또는 삭제가 불가능하지만 중첩되지 않은 추가 CIDR 블록을 VPC에 추가할 수 있습니다. 그러나 이 경우 주소 범위를 분할될 수 있습니다.
## 리소스
**관련 문서:**
+ [APN 파트너: 네트워킹 계획을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [네트워크 인프라에 대한 AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011)
+ [Amazon Virtual Private Cloud 연결 옵션 백서](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [여러 데이터 센터 고가용 네트워크 연결](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [단일 리전 다중 VPC 연결](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ [Amazon VPC란 무엇입니까?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
**관련 동영상:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC(Amazon VPC에 대한 VPC 설계 및 새로운 기능)(NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs(여러 VPC를 위한 AWS Transit Gateway 참조 아키텍처)(NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP04 다대다 메시보다 허브 앤드 스포크 토폴로지 선호
셋 이상의 네트워크 주소 공간(예: VPC와 온프레미스 네트워크)이 VPC 피어링, AWS Direct Connect 또는 VPN을 통해 연결되는 경우 AWS Transit Gateway가 제공하는 것과 같은 허브 앤드 스포크 모델을 사용합니다.
이러한 네트워크가 두 개 뿐인 경우에는 서로 연결하면 되지만 네트워크 수가 증가하면 이 메쉬 기반 연결의 복잡성이 크게 증가합니다. AWS Transit Gateway는 유지 관리가 간편한 허브 앤드 스포크 모델을 제공하므로 여러 네트워크에 걸쳐 트래픽을 라우팅할 수 있습니다.
![\[AWS Transit Gateway를 사용하지 않는 경우를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/without-transit-gateway.png)
![\[AWS Transit Gateway를 사용하는 경우를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/with-transit-gateway.png)
**일반적인 안티 패턴:**
+ VPC 피어링을 사용하여 2개 이상의 VPC 연결
+ 각 VPC마다 여러 BGP 세션을 설정하여 여러 AWS 리전에 분산된 Virtual Private Cloud(VPC)에 걸쳐 있는 연결 설정
**이 모범 사례 정립의 이점:** 네트워크 수가 증가하면 이러한 메시 기반 연결의 복잡성이 크게 증가합니다. AWS Transit Gateway는 유지 관리가 간편한 허브 앤드 스포크 모델을 제공하므로 여러 네트워크에 트래픽을 라우팅할 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 다대다 메시보다 허브 앤드 스포크 토폴로지를 선호합니다. 셋 이상의 네트워크 주소 공간(VPC, 온프레미스 네트워크)이 VPC 피어링, AWS Direct Connect 또는 VPN을 통해 연결되는 경우 AWS Transit Gateway가 제공하는 것과 같은 허브 앤드 스포크 모델을 사용합니다.
+ 이러한 네트워크가 두 개뿐인 경우에는 서로 연결하면 되지만 네트워크 수가 증가하면 이 메시 기반 연결의 복잡성이 크게 증가합니다. AWS Transit Gateway는 유지 관리가 간편한 허브 앤드 스포크 모델을 제공하므로 여러 네트워크에 걸쳐 트래픽을 라우팅할 수 있습니다.
+ [Transit Gateway란 무엇일까요?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
## 리소스
**관련 문서:**
+ [APN 파트너: 네트워킹 계획을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [네트워크 인프라에 대한 AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011)
+ [여러 데이터 센터 고가용 네트워크 연결](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [VPC 엔드포인트 및 VPC 엔드포인트 서비스(AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [Amazon VPC란 무엇입니까?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [Transit Gateway란 무엇일까요?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
**관련 동영상:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC(Amazon VPC에 대한 VPC 설계 및 새로운 기능)(NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs(여러 VPC를 위한 AWS Transit Gateway 참조 아키텍처)(NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP05 연결된 모든 프라이빗 주소 공간에서 겹치지 않는 프라이빗 IP 주소 범위 적용
VPN을 통해 피어링되거나 연결된 경우 각 VPC의 IP 주소 범위가 겹치지 않아야 합니다. 마찬가지로, VPC와 온프레미스 환경 간의 IP 주소 충돌 또는 사용하는 다른 클라우드 공급자와의 IP 주소 충돌을 방지해야 합니다. 필요한 경우 프라이빗 IP 주소 범위를 할당할 수 있어야 합니다.
IPAM(IP 주소 관리) 시스템을 사용하는 것이 도움이 될 수 있습니다. AWS Marketplace에서 여러 IPAM을 사용할 수 있습니다.
**일반적인 안티 패턴:**
+ VPC에서 온프레미스 또는 회사 네트워크와 동일한 IP 범위 사용
+ 워크로드를 배포하는 데 사용되는 VPC의 IP 범위를 추적하지 않음
**이 모범 사례 수립의 이점:** 네트워크를 능동적으로 계획하면 상호 연결된 네트워크에서 동일한 IP 주소가 여러 번 사용되는 것을 방지할 수 있습니다. 이렇게 하면 다른 애플리케이션을 사용하는 워크로드의 일부에서 라우팅 문제가 발생하는 것을 방지할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ CIDR 사용을 모니터링 및 관리합니다. AWS에서 잠재적인 사용량을 평가하고, 기존 VPC에 CIDR 범위를 추가하고, VPC를 생성하여 사용량을 계획적으로 늘릴 수 있습니다.
+ 현재 CIDR 사용량을 파악합니다(예: VPC, 서브넷).
+ 서비스 API 작업을 사용하여 현재 CIDR 사용량을 파악합니다.
+ 현재 서브넷 사용량을 파악합니다.
+ 서비스 API 작업을 사용하여 각 리전의 VPC당 서브넷 정보를 수집합니다.
+ [DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html)
+ 현재 사용량을 기록합니다.
+ 중첩되지 않는 IP 범위를 생성했는지 판단합니다.
+ 여유 용량을 계산합니다.
+ 중첩된 IP 범위를 파악합니다. 중첩되는 범위를 연결해야 하는 경우 새 주소 범위로 마이그레이션하거나 AWS Marketplace에서 제공하는 Network and Port Translation(NAT) 어플라이언스를 사용할 수 있습니다.
## 리소스
**관련 문서:**
+ [APN 파트너: 네트워킹 계획을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [네트워크 인프라에 대한 AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011)
+ [Amazon Virtual Private Cloud 연결 옵션 백서](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [여러 데이터 센터 고가용 네트워크 연결](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Amazon VPC란 무엇입니까?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [IPAM이란?](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html)
**관련 동영상:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC(Amazon VPC에 대한 고급 VPC 설계 및 새로운 기능)(NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs(여러 VPC를 위한 AWS Transit Gateway 참조 아키텍처)(NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# 워크로드 아키텍처
**Topics**
+ [REL 3 워크로드 서비스 아키텍처는 어떻게 설계합니까?](w2aac19b9b7b5.md)
+ [REL 4 분산 시스템에서 장애 방지를 위한 상호 작용은 어떻게 설계합니까?](w2aac19b9b7b7.md)
+ [REL 5 분산 시스템에서 장애 완화 또는 극복을 위한 상호 작용은 어떻게 설계합니까?](w2aac19b9b7b9.md)
# REL 3 워크로드 서비스 아키텍처는 어떻게 설계합니까?
SOA(서비스 지향 아키텍처) 또는 마이크로서비스 아키텍처를 사용하여 확장성과 안정성이 뛰어난 워크로드를 구축합니다. SOA(서비스 지향 아키텍처)는 서비스 인터페이스를 통해 소프트웨어 구성 요소를 재사용 가능하게 만드는 방식입니다. 마이크로서비스 아키텍처는 구성 요소를 더 작고 간단하게 만듭니다.
**Topics**
+ [REL03-BP01 워크로드를 세그먼트화하는 방법 선택](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 특정 비즈니스 도메인 및 기능을 중심으로 서비스 구축](rel_service_architecture_business_domains.md)
+ [REL03-BP03 API별로 서비스 계약 제공](rel_service_architecture_api_contracts.md)
# REL03-BP01 워크로드를 세그먼트화하는 방법 선택
워크로드 세그먼트화는 애플리케이션의 복원력 요구 사항을 결정할 때 중요합니다. 되도록 모놀리식 아키텍처는 피해야 합니다. 대신 어떤 애플리케이션 구성 요소를 마이크로 서비스로 나눌 수 있을지 신중하게 고려합니다. 가능한 경우 애플리케이션 요구 사항에 따라 서비스 지향 아키텍처(SOA)와 마이크로 서비스의 결합으로 마무리될 수도 있습니다. 상태 비저장일 수 있는 워크로드는 마이크로 서비스로 배포할 수 있습니다.
**원하는 결과:** 워크로드는 지원 가능하고 확장 가능하며 가능한 한 느슨하게 결합되어 있어야 합니다.
워크로드를 세그먼트화하는 방법을 선택할 때 복잡성 대비 이점의 균형을 고려합니다. 신제품의 첫 출시에 필요한 것과 처음부터 워크로드를 확장할 때 필요한 것은 다릅니다. 기존 모놀리식을 리팩터링할 때 애플리케이션이 상태 비저장을 향한 해체를 얼마나 잘 지원하는지 고려해야 합니다. 서비스를 더 작은 부분으로 나누면 잘 정의된 소규모 팀에서 이러한 부분을 개발하고 관리할 수 있습니다. 그러나 크기가 작은 서비스는 복잡성을 불러올 수 있고 여기에는 지연 시간 증가, 디버깅 복잡성, 운영 부담 증가가 포함됩니다.
**일반적인 안티 패턴:**
+ [마이크로서비스 *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) 는 원자성 구성 요소의 상호 의존성이 커져 한 구성 요소의 장애가 훨씬 더 큰 장애로 이어져 구성 요소가 모놀리식처럼 경직되고 취약해질 수 있습니다.
**이 모범 사례 정립의 이점:**
+ 보다 구체적인 세그먼트를 사용하면 민첩성, 조직의 유연성 및 확장성이 향상됩니다.
+ 서비스 중단의 영향이 감소합니다.
+ 애플리케이션 구성 요소가 원자성이 더 큰 세그먼트화로 지원할 수 있는 여러 가능성 요구 사항을 가질 수 있습니다.
+ 워크로드를 지원하는 팀의 책임이 잘 정의됩니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 가이드
워크로드를 분할하는 방법에 따라 아키텍처 유형 선택 SOA 또는 마이크로서비스 아키텍처(또는 드문 경우 모놀리식 아키텍처)를 선택합니다. 처음에 모놀리식 아키텍처를 선택하더라도, 사용자 채택에 따라 제품을 확장할 때 SOA 또는 마이크로서비스로 변경할 수 있는 모듈식 아키텍처인지 확인해야 합니다. SOA와 마이크로서비스는 더 작게 분할할 수 있기 때문에 현대의 확장 가능하고 안정적인 아키텍처로 선호되지만 특히 마이크로서비스 아키텍처를 배포하는 경우 절충을 고려해야 합니다.
한 가지 주요 절충은 분산 컴퓨팅 아키텍처가 구축되므로 사용자 지연 시간 요구 사항을 충족하기가 더 어려워지며, 사용자 상호 작용을 디버그하고 추적하는 과정이 더 복잡해진다는 것입니다. AWS X-Ray을(를) 사용하면 이 문제를 해결할 수 있습니다. 관리 중인 애플리케이션의 수가 증가함에 따라 운영 복잡성이 증가하므로 다수의 독립 구성 요소를 배포해야 한다는 점도 고려해야 합니다.
![\[모놀리식, 서비스 지향, 마이크로서비스 아키텍처 간 비교 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## 구현 단계
+ 애플리케이션을 리팩터링 또는 구축하기에 적절한 아키텍처를 결정합니다. SOA 및 마이크로서비스는 상태적으로 더 세분화된 조각화를 제공하며, 이는 확장 가능하고 안정적인 최신 아키텍처로서 선호됩니다. SOA는 마이크로서비스의 복잡성을 어느 정도 피하면서 더 세분화된 조각화를 실현하기에 좋은 절충안이 될 수 있습니다. 자세한 내용은 [Microservice Trade-Offs를 참조하세요](https://martinfowler.com/articles/microservice-trade-offs.html).
+ 이를 워크로드에 적용할 수 있고 조직에서 지원할 수 있는 경우, 마이크로서비스 아키텍처를 사용하여 최고의 민첩성과 안정성을 실현해야 합니다. 자세한 내용은 [AWS에서 마이크로서비스 구현을 참조하세요.](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ 모놀리식을 더 작은 구성 요소로 리팩터링하려면 [*스트랭글러 피그* 패턴](https://martinfowler.com/bliki/StranglerFigApplication.html) 을 따라 고려하세요. 여기에는 특정 애플리케이션을 새 애플리케이션 및 서비스로 점차적으로 교체하는 작업이 포함됩니다. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) 은(는) 점진적 리팩터링을 위한 시작점 역할을 합니다. 자세한 내용은 [스트랭글러 패턴을 사용하여 원활하게 온프레미스 레거시 워크로드 마이그레이션을 참조하세요](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ 마이크로 서비스를 구현하려면 분산된 서비스가 서로 통신하기 위한 서비스 검색 메커니즘이 필요할 수 있습니다. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) 을(를) 서비스 지향 아키텍처와 함께 사용하여 안정적인 서비스 검색 및 액세스를 제공할 수 있습니다. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) 은(는) 동적 DNS 기반 서비스 검색에도 사용할 수 있습니다.
+ 모놀리식에서 SOA로 마이그레이션하는 경우 [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) 은(는) 클라우드에서 레거시 애플리케이션을 다시 설계하는 경우 서비스 버스로 격차를 해소하는 데 도움이 될 수 있습니다.
+ 공유 데이터베이스 하나를 사용하는 기존 모놀리식의 경우 데이터를 더 작은 세그먼트로 재구성하는 방법을 선택합니다. 사업부, 액세스 패턴 또는 데이터 구조별로 선택할 수 있습니다. 리팩터링 프로세스 중 이 지점에서 데이터베이스의 관계형 또는 비관계형(NoSQL) 유형을 사용하여 진행할지 선택해야 합니다. 자세한 내용은 [SQL에서 NoSQL로를 참조하세요](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**구현 계획의 작업 수준:** 높음
## 리소스
**관련 모범 사례:**
+ [REL03-BP02 특정 비즈니스 도메인 및 기능을 중심으로 서비스 구축](rel_service_architecture_business_domains.md)
**관련 문서:**
+ [Amazon API Gateway: OpenAPI를 사용하여 REST API 구성](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [서비스 지향 아키텍처란 무엇인가요?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [경계 컨텍스트(도메인 주도 설계의 주요 패턴)](https://martinfowler.com/bliki/BoundedContext.html)
+ [AWS에서 마이크로서비스 구현](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Microservice Trade-Offs](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices - a definition of this new architectural term](https://www.martinfowler.com/articles/microservices.html)
+ [AWS 마이크로서비스](https://aws.amazon.com/microservices/)
+ [AWS App Mesh란 무엇인가요?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**관련 예시:**
+ [반복적 앱 데이터베이스 현대화 워크숍](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**관련 동영상:**
+ [Delivering Excellence with Microservices on AWS(AWS에서 마이크로서비스를 사용하여 우수성 제공)](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 특정 비즈니스 도메인 및 기능을 중심으로 서비스 구축
서비스 지향 아키텍처(SOA)는 비즈니스 요구 사항에 따라 명확하게 정의된 기능으로 서비스를 구축합니다. 마이크로서비스는 도메인 모델과 경계 컨텍스트를 사용하여 이를 추가로 제한함으로써 각 서비스가 한 가지 작업을 수행하도록 합니다. 특정 기능에 집중하면 다양한 서비스의 안정성 요구 사항을 구분하고 보다 구체적으로 투자의 대상을 지정할 수 있습니다. 또한 비즈니스 문제가 간단해지고 각 서비스에 소규모 팀이 연결되므로 조직의 확장이 수월해집니다.
마이크로서비스 아키텍처를 설계할 때는 DDD(Domain-Driven Design)에서 엔터티를 사용하여 비즈니스 문제를 모델링하는 것이 도움이 됩니다. 예를 들어 Amazon.com 웹 사이트에서 엔터티에는 패키지, 배송, 일정, 가격, 할인 및 통화가 포함될 수 있습니다. 이 모델은 [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html)를 사용하여 유사한 기능 및 속성을 공유하는 엔터티를 그룹화하는 더 작은 모델로 구분됩니다. 따라서 Amazon.com 예시 패키지에서 배송 및 일정은 배송 컨텍스트에 포함되지만 가격, 할인 및 통화는 요금 컨텍스트에 포함됩니다. 모델을 컨텍스트로 나누면 마이크로서비스의 경계를 지정하는 방법에 대한 템플릿을 사용할 수 있게 됩니다.
![\[마이크로서비스의 경계 지정 방법을 위한 모델 템플릿\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/building-services.png)
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 비즈니스 도메인과 해당 기능을 기준으로 워크로드를 설계합니다. 특정 기능에 집중하면 다양한 서비스의 안정성 요구 사항을 구분하고 보다 구체적으로 투자의 대상을 지정할 수 있습니다. 또한 비즈니스 문제가 간단해지고 각 서비스에 소규모 팀이 연결되므로 조직의 확장이 수월해집니다.
+ 도메인 분석을 수행하여 워크로드에 대한 DDD(도메인 중심 설계)를 매핑합니다. 그러면 워크로드의 요구 사항에 맞는 아키텍처 유형을 선택할 수 있습니다.
+ [모놀리식 유형을 마이크로서비스로 분할하는 방법](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [레거시 시스템으로 둘러싸여 있을 때 DDD 시작](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans ‘Domain-Driven Design: Tackling Complexity in the Heart of Software’](https://www.amazon.com/gp/product/0321125215)
+ [AWS에서 마이크로서비스 구현](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ 가능한 한 가장 작은 구성 요소로 서비스를 분해합니다. 마이크로서비스 아키텍처를 사용하면 워크로드를 최소 기능 단위의 구성 요소로 분리하여 조직을 확장하고 민첩성을 실현할 수 있습니다.
+ 워크로드 및 설계 목표, 한도 및 사용에 대한 기타 고려 사항과 관련하여 API를 정의합니다.
+ API 정의.
+ API 정의는 확장 및 추가 파라미터를 허용해야 합니다.
+ 설계된 가용성 정의.
+ API는 다양한 기능에 대해 여러 설계 목표를 가질 수 있습니다.
+ 한도 수립
+ 테스트를 사용하여 워크로드 기능의 한도를 정의합니다.
## 리소스
**관련 문서:**
+ [Amazon API Gateway: OpenAPI를 사용하여 REST API 구성](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [경계 컨텍스트(도메인 주도 설계의 주요 패턴)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans ‘Domain-Driven Design: Tackling Complexity in the Heart of Software’](https://www.amazon.com/gp/product/0321125215)
+ [레거시 시스템으로 둘러싸여 있을 때 DDD 시작](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [모놀리식 유형을 마이크로서비스로 분할하는 방법](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [AWS에서 마이크로서비스 구현](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Microservice Trade-Offs](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices - a definition of this new architectural term](https://www.martinfowler.com/articles/microservices.html)
+ [AWS 마이크로서비스](https://aws.amazon.com/microservices/)
# REL03-BP03 API별로 서비스 계약 제공
서비스 계약은 서비스 통합에 대한 팀 간의 문서화된 계약으로, 머신 판독 가능한 API 정의, 속도 제한 및 성능 기대치를 포함합니다. 버전 관리 전략을 사용하면 클라이언트에서 기존 API를 계속 사용하면서 준비가 될 때 애플리케이션을 최신 API로 마이그레이션할 수 있습니다. 계약을 위반하지 않는 한 언제든지 배포가 가능합니다. 서비스 공급자 팀은 원하는 기술 스택을 사용하여 API 계약을 충족할 수 있습니다. 마찬가지로 서비스 소비자는 자체 기술을 사용할 수 있습니다.
마이크로서비스는 서비스 지향 아키텍처(SOA) 개념을 적용하여 최소한의 기능 세트만 포함된 서비스를 생성합니다. 각 서비스는 API 및 설계 목표, 한도 및 서비스 사용을 위한 기타 고려 사항을 게시합니다. 이렇게 하면 호출 애플리케이션과의 *계약이* 성립됩니다. 이러한 방식에서 제공되는 세 가지 주요 이점은 다음과 같습니다.
+ 서비스에서 간단한 업무상의 문제만 처리하면 되며, 소규모 팀이 업무상의 문제를 소유할 수 있습니다. 그러므로 조직 크기를 더 효율적으로 조정할 수 있습니다.
+ 팀은 API 및 ‘계약’ 요구 사항을 충족하는 경우에 한해 언제든지 서비스를 배포할 수 있습니다.
+ 팀은 API 및 ‘계약’ 요구 사항을 충족하는 경우에 한해 원하는 모든 기술 스택을 사용할 수 있습니다.
Amazon API Gateway는 어떤 규모에서든 개발자가 API를 손쉽게 생성, 게시, 유지 관리, 모니터링 및 보안할 수 있게 해주는 완전관리형 서비스입니다. 트래픽 관리, 권한 부여 및 접근 제어, 모니터링 및 API 버전 관리를 비롯하여 최대 수십만 건의 동시 API 호출을 수락하고 처리하는 데 관련된 모든 작업을 처리합니다. 이전의 Swagger Specification인 OpenAPI Specification(OAS)을 사용하여 API 계약을 정의한 다음 이 정의를 API Gateway로 가져올 수 있습니다. 그런 다음 API Gateway를 사용하여 API를 버전 관리하고 배포할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ API당 서비스 계약 제공: 서비스 계약은 서비스 통합에 대한 팀 간의 문서화된 계약으로, 머신 판독 가능한 API 정의, 속도 제한 및 성능 기대치를 포함합니다.
+ [Amazon API Gateway: OpenAPI를 사용하여 REST API 구성](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ 버전 관리 전략을 사용하면 클라이언트에서 기존 API를 계속 사용하면서 준비가 될 때 애플리케이션을 최신 API로 마이그레이션할 수 있습니다.
+ Amazon API Gateway는 어떤 규모에서든 개발자가 API를 손쉽게 생성할 수 있게 해주는 완전관리형 서비스입니다. 이전의 Swagger Specification인 OpenAPI Specification(OAS)을 사용하여 API 계약을 정의한 다음 이 정의를 API Gateway로 가져올 수 있습니다. 그런 다음 API Gateway를 사용하여 API를 버전 관리하고 배포할 수 있습니다.
## 리소스
**관련 문서:**
+ [Amazon API Gateway: OpenAPI를 사용하여 REST API 구성](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [경계 컨텍스트(도메인 주도 설계의 주요 패턴)](https://martinfowler.com/bliki/BoundedContext.html)
+ [AWS에서 마이크로서비스 구현](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Microservice Trade-Offs](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices - a definition of this new architectural term](https://www.martinfowler.com/articles/microservices.html)
+ [AWS 마이크로서비스](https://aws.amazon.com/microservices/)
# REL 4 분산 시스템에서 장애 방지를 위한 상호 작용은 어떻게 설계합니까?
분산 시스템에서 구성 요소(예: 서버 또는 서비스)는 통신 네트워크를 사용하여 상호 연결됩니다. 워크로드는 이러한 네트워크에서 데이터 손실 또는 지연 시간이 발생하더라도 안정적으로 작동해야 합니다. 분산 시스템의 구성 요소는 다른 구성 요소나 워크로드에 부정적인 영향을 미치지 않는 방식으로 작동해야 합니다. 여기에 나온 모범 사례는 장애를 방지하고 MTBF(평균 장애 간격)를 개선합니다.
**Topics**
+ [REL04-BP01 필요한 분산 시스템의 종류 식별](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 느슨하게 결합된 종속성 구현](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 일정한 작업 수행](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 모든 응답의 멱등성 유지](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 필요한 분산 시스템의 종류 식별
하드 실시간 분산 시스템에서는 응답을 동기식으로 신속하게 제공해야 하지만, 소프트 실시간 시스템에서는 응답하기 위한 몇 분 이상의 여유가 주어집니다. 오프라인 시스템은 배치 또는 비동기식 처리를 통해 응답을 처리합니다. 하드 실시간 분산 시스템은 안정성 요구 사항이 가장 엄격합니다.
요청/응답 서비스로 알려진 높은 수준의 실시간 분산 시스템과 관련된 문제가 [분산 시스템의 가장 어려운 문제라고](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 할 수 있습니다. 이 문제가 어려운 이유는 언제 도착할지 예상할 수 없는 요청에 대해 신속하게 응답을 제공해야 하기 때문입니다(예: 응답이 올 때까지 앞에서 대기하는 고객). 예를 들어 프런트엔드 웹 서버, 주문 파이프라인, 신용 카드 거래, 모든 AWS API 및 전화 통신이 여기에 포함됩니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 필요한 분산 시스템의 종류를 식별합니다. 분산 시스템에는 지연 시간, 확장 및 축소, 네트워킹 API에 대한 이해, 데이터 마샬링 및 마샬링 취소와 알고리즘(예: Paxos)의 복잡성과 같은 당면 과제가 있었습니다. 시스템이 커지고 분산화가 확대되자, 이론적으로는 극단적 사례에 해당했던 문제들이 주기적으로 발생하기 시작했습니다.
+ [Amazon Builders' Library: 분산 시스템의 도전 과제](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ 하드 실시간 분산 시스템에서는 응답이 동기식으로 신속하게 제공되어야 합니다.
+ 소프트 실시간 시스템은 상대적으로 응답 시간의 여유가 있어 분 단위 이상의 응답 시간이 허용됩니다.
+ 오프라인 시스템은 배치 또는 비동기식 처리를 통해 응답을 처리합니다.
+ 하드 실시간 분산 시스템은 안정성 요구 사항이 가장 엄격합니다.
## 리소스
**관련 문서:**
+ [Amazon EC2: Ensuring Idempotency(멱등성 보장)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library: 분산 시스템의 도전 과제](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: (안정성, 지속적인 작업 및 맛 좋은 한 잔의 커피)](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon Simple Queue Service란 무엇입니까?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**관련 동영상:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures(이벤트 중심 아카텍처 및 Amazon EventBridge 소개) 및 Amazon EventBridge(MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small(루프 닫기 및 마음 열기: 규모에 상관없이 시스템을 제어하는 방법) ARC337(느슨한 결합, 일정한 작업, 정적 안정성 포함)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures(이벤트 중심 아키텍처로 전환)(SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP02 느슨하게 결합된 종속성 구현
대기열 처리 시스템, 스트리밍 시스템, 워크플로 및 로드 밸런서와 같은 종속성은 약결합됩니다. 느슨한 결합은 한 구성 요소의 동작을 다른 종속 구성 요소에서 분리하여 복원력 및 민첩성을 높이는 데 도움이 됩니다.
한 구성 요소에 대한 변경이 다른 종속 구성 요소의 변경을 강제하는 경우 이러한 구성 요소는 *강하게* 결합된 것입니다. *느슨한* 결합에서는 이 종속성이 분리되므로 종속 구성 요소에서는 버전이 지정되고 게시된 인터페이스만 알면 됩니다. 종속성 간에 느스한 결합을 구현하면 한 구성 요소의 장애가 다른 구성 요소에 영향을 미치지 않도록 분리됩니다.
느슨한 결합을 사용하면 종속 구성 요소에 미치는 위험을 최소화하면서 추가 코드 또는 기능을 추가할 수 있습니다. 또한 종속성의 기본 구현을 스케일 아웃하거나 변경할 수 있으므로 확장성이 개선됩니다.
느슨한 결합을 통해 복원력을 추가로 개선하려면 가능한 경우 구성 요소가 비동기식으로 상호 작용하도록 합니다. 이 모델은 즉각적인 응답이 필요하지 않고 요청이 등록되었다는 확인으로 충분한 상호 작용에 적합합니다. 이러한 상호 작용에는 이벤트를 생성하는 구성 요소와 이벤트를 사용하는 구성 요소가 포함됩니다. 두 구성 요소는 직접적인 지점 간 상호 작용을 통해 통합되지 않으며 일반적으로 내구성이 있는 중간 스토리지 계층(예: SQS 대기열 또는 Amazon Kinesis 또는 AWS Step Functions와 같은 스트리밍 데이터 플랫폼)을 통해 통합됩니다.
![\[대기열 처리 시스템 및 로드 밸런서와 같은 종속성이 느슨하게 결합된 것을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/loosely-coupled-dependencies.png)
Amazon SQS 대기열과 Elastic Load Balancer는 느슨한 결합을 위한 중간 계층을 추가할 수 있는 두 가지 방법의 예입니다. AWS 클라우드에서는 Amazon EventBridge를 사용하여 이벤트 기반 아키텍처를 구축할 수도 있습니다. Amazon EventBridge는 클라이언트(이벤트 소비자)가 사용하는 서비스에서 클라이언트(이벤트 생산자)를 추상화할 수 있습니다. Amazon Simple Notification Service(Amazon SNS)는 높은 처리량의 푸시 기반 다대다 메시징이 필요할 때 효과적인 솔루션입니다. Amazon SNS 주제를 사용하면 게시자 시스템에서 다수의 구독자 엔드포인트로 메시지를 팬아웃하여 병렬 처리를 수행할 수 있습니다.
대기열은 다수의 장점을 제공하지만 대부분의 강성 실시간 시스템에서 임계 시간(주로 초 단위)을 초과한 요청은 무효한 요청(클라이언트가 포기하여 더 이상 응답을 기다리지 않는 요청)으로 간주되어 처리되지 않습니다. 이렇게 하면 오래된 요청 대신 여전히 유효한 요청일 가능성이 큰 최근 요청을 처리할 수 있습니다.
**일반적인 안티 패턴:**
+ 워크로드의 일부로 싱글톤 배포
+ 장애 조치 또는 비동기식 요청 처리 기능 없이 워크로드 티어 간에 API를 직접 호출
**이 모범 사례 수립의 이점:** 느슨한 결합은 한 구성 요소의 동작을 다른 종속 구성 요소에서 분리하여 복원력 및 민첩성을 높이는 데 도움이 됩니다. 한 구성 요소에서 발생한 장애는 다른 구성 요소로부터 격리됩니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 느슨하게 결합된 종속성을 구현합니다. 대기열 처리 시스템, 스트리밍 시스템, 워크플로 및 로드 밸런서와 같은 종속성은 약결합됩니다. 느슨한 결합은 한 구성 요소의 동작을 다른 종속 구성 요소에서 분리하여 복원력 및 민첩성을 높이는 데 도움이 됩니다.
+ [AWS re:Invent 2019: Moving to event-driven architectures(이벤트 중심 아키텍처로 전환)(SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon Simple Queue Service란 무엇입니까?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ Amazon EventBridge를 사용하면 느슨하게 결합되고 분산된 이벤트 중심의 아키텍처를 구축할 수 있습니다.
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge(이벤트 중심 아카텍처 및 Amazon EventBridge 소개)(MAD205)](https://youtu.be/tvELVa9D9qU)
+ 한 구성 요소에 대한 변경이 다른 종속 구성 요소의 변경을 강제하는 경우 이러한 구성 요소는 강하게 결합된 것입니다. 느슨한 결합에서는 이 종속성이 분리되므로 종속 구성 요소에서는 버전이 지정되고 게시된 인터페이스만 알면 됩니다.
+ 가능한 경우 구성 요소 상호 작용을 비동기식으로 만듭니다. 이 모델은 즉각적인 응답이 필요하지 않고 요청이 등록되었다는 확인으로 충분한 상호 작용에 적합합니다.
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda(Amazon SQS 및 Lambda를 사용하는 확장 가능한 서버리스 이벤트 중심 애플리케이션)(API304)](https://youtu.be/2rikdPIFc_Q)
## 리소스
**관련 문서:**
+ [AWS re:Invent 2019: Moving to event-driven architectures(이벤트 중심 아키텍처로 전환)(SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon EC2: Ensuring Idempotency(멱등성 보장)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library: 분산 시스템의 도전 과제](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: Reliability, constant work, and a good cup of coffee(안정성, 지속적인 작업 및 맛 좋은 한 잔의 커피)](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon Simple Queue Service란 무엇입니까?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**관련 동영상:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge(이벤트 중심 아카텍처 및 Amazon EventBridge 소개)(MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small(루프 닫기 및 마음 열기: 규모에 상관없이 시스템을 제어하는 방법) ARC337(느슨한 결합, 일정한 작업, 정적 안정성 포함)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures(이벤트 중심 아키텍처로 전환)(SVS308)](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda(Amazon SQS 및 Lambda를 사용하는 확장 가능한 서버리스 이벤트 중심 애플리케이션)(API304)](https://youtu.be/2rikdPIFc_Q)
# REL04-BP03 일정한 작업 수행
대규모 로드가 급속도로 변경되면 시스템에서 장애가 발생할 수 있습니다. 예를 들어 서버 수천 대의 상태를 모니터링하는 상태 확인을 수행하는 워크로드의 경우 매번 동일한 크기의 페이로드(현재 상태의 전체 스냅샷)를 전송해야 합니다. 장애가 전혀 발생하지 않는 경우나, 또는 모든 서버에서 발생하는 경우와 무관하게 상태 확인 시스템은 대규모의 급속한 변경 없이 일정한 작업을 처리합니다.
예를 들어 상태 확인 시스템이 100,000개의 서버를 모니터링하는 경우 서버 장애율이 정상적으로 낮을 때는 서버에 가해지는 로드가 작습니다. 그러나 중대한 이벤트로 인해 이러한 서버의 절반이 비정상 상태가 될 때 상태 확인 시스템에서 알림 시스템을 업데이트하고 클라이언트로 상태를 전달하려면 상태 확인 시스템이 과부하가 될 수 있습니다. 그렇기 때문에 상태 확인 시스템에서는 매번 현재 상태의 전체 스냅샷을 전송하는 것이 낫습니다. 100,000개의 서버 상태(각각 비트로 표시됨)는 12.5KB 페이로드에 불과합니다. 장애가 발생한 서버가 없든 모든 서버에서 장애가 발생하든 상태 확인 시스템은 일정한 작업을 처리하므로 대규모의 급속한 변경이 시스템 안정성에 위협이 되지 않습니다. 이 방법으로 Amazon Route 53이 엔드포인트(예: IP 주소)에 대한 상태 확인을 수행하여 최종 사용자가 어떻게 엔드포인트에 라우팅되는지 판단합니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 로드에 대규모의 급격한 변화가 있을 때 시스템에서 장애가 발생하지 않도록 일정하게 작업을 수행합니다.
+ 느슨한 결합 종속성을 구현합니다. 대기열 처리 시스템, 스트리밍 시스템, 워크플로 및 로드 밸런서와 같은 종속성은 약결합됩니다. 느슨한 결합은 한 구성 요소의 동작을 다른 종속 구성 요소에서 분리하여 복원력 및 민첩성을 높이는 데 도움이 됩니다.
+ [Amazon Builders' Library: (안정성, 지속적인 작업 및 맛 좋은 한 잔의 커피)](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small(루프 닫기 및 마음 열기: 규모에 상관없이 시스템을 제어하는 방법) ARC337(일정한 작업 포함) ](https://youtu.be/O8xLxNje30M?t=2482)
+ 10만 개의 서버를 모니터링하는 상태 확인 시스템의 예에서 성공 또는 실패 횟수와 관계없이 페이로드 크기가 일정하게 유지되도록 워크로드를 엔지니어링합니다.
## 리소스
**관련 문서:**
+ [Amazon EC2: Ensuring Idempotency(멱등성 보장)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library: 분산 시스템의 도전 과제](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: (안정성, 지속적인 작업 및 맛 좋은 한 잔의 커피)](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**관련 동영상:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures(이벤트 중심 아카텍처 및 Amazon EventBridge 소개) 및 Amazon EventBridge(MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small(루프 닫기 및 마음 열기: 규모에 상관없이 시스템을 제어하는 방법) ARC337(일정한 작업 포함) ](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small(루프 닫기 및 마음 열기: 규모에 상관없이 시스템을 제어하는 방법) ARC337(느슨한 결합, 일정한 작업, 정적 안정성 포함)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures(이벤트 중심 아키텍처로 전환)(SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP04 모든 응답의 멱등성 유지
멱등성이 있는 서비스는 각 요청이 정확히 한 번만 완료되도록 합니다. 이렇게 하면 다수의 동일한 요청에서 단일 요청과 동일한 결과가 나옵니다. 멱등성이 있는 서비스를 사용하면 클라이언트가 요청이 오류로 여러 번 처리될 것이라는 염려 없이 재시도를 시행할 수 있습니다. 이를 위해 클라이언트는 멱등성 토큰을 사용하여 API 요청을 실행할 수 있으며 요청이 반복될 때마다 동일한 토큰이 사용됩니다. 멱등성이 있는 서비스 API는 토큰을 사용하여 요청이 처음 완료되었을 때 반환된 응답과 동일한 응답을 반환합니다.
분산 시스템에서 작업을 최대 한 번(클라이언트가 한 번만 요청) 또는 최소 한 번(클라이언트가 성공 확인을 수신할 때까지 계속 요청) 수행하기는 쉽습니다. 그러나 작업의 멱등성을 보장하기는 어렵습니다. 즉 작업을 *정확히* 한 번 수행하여 다수의 동일한 요청에서 단일 요청과 동일한 결과를 얻기는 어렵습니다. API에서 멱등성 토큰을 사용하면 서비스가 중복 레코드를 생성하지 않고 부작용 없이 변경 요청을 한 번 이상 수신할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 모든 응답의 멱등성을 유지합니다. 멱등성이 있는 서비스는 각 요청이 정확히 한 번만 완료되도록 합니다. 이렇게 하면 다수의 동일한 요청에서 단일 요청과 동일한 결과가 나옵니다.
+ 클라이언트는 멱등성 토큰을 사용하여 API 요청을 실행할 수 있으며 요청이 반복될 때마다 동일한 토큰이 사용됩니다. 멱등성이 있는 서비스 API는 토큰을 사용하여 요청이 처음 완료되었을 때 반환된 응답과 동일한 응답을 반환합니다.
+ [Amazon EC2: Ensuring Idempotency(멱등성 보장)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
## 리소스
**관련 문서:**
+ [Amazon EC2: Ensuring Idempotency(멱등성 보장)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library: 분산 시스템의 도전 과제](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: Reliability, constant work, and a good cup of coffee(안정성, 지속적인 작업 및 맛 좋은 한 잔의 커피)](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**관련 동영상:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge(이벤트 중심 아카텍처 및 Amazon EventBridge 소개)(MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small(루프 닫기 및 마음 열기: 규모에 상관없이 시스템을 제어하는 방법) ARC337(느슨한 결합, 일정한 작업, 정적 안정성 포함)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures(이벤트 중심 아키텍처로 전환)(SVS308)](https://youtu.be/h46IquqjF3E)
# REL 5 분산 시스템에서 장애 완화 또는 극복을 위한 상호 작용은 어떻게 설계합니까?
분산 시스템에서 구성 요소(예: 서버 또는 서비스)는 통신 네트워크를 사용하여 상호 연결됩니다. 워크로드는 이러한 네트워크에서 데이터 손실 또는 지연 시간이 발생하더라도 안정적으로 작동해야 합니다. 분산 시스템의 구성 요소는 다른 구성 요소나 워크로드에 부정적인 영향을 미치지 않는 방식으로 작동해야 합니다. 이러한 모범 사례를 준수하면 워크로드가 스트레스 또는 장애를 견디고, 더 빠르게 이를 복구하며, 이러한 장애의 영향을 완화할 수 있습니다. 그러면 결과적으로 MTTR(평균 복구 시간)이 개선됩니다.
**Topics**
+ [REL05-BP01 관련 하드 종속성을 소프트 종속성으로 변환하는 정상적인 성능 저하 구현](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 요청 제한](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 재시도 호출 제어 및 제한](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 빠른 실패 및 대기열 제한](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 클라이언트 시간 제한 설정](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 가능한 경우 서비스를 스테이트리스로 설계](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 비상 레버 구현](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 관련 하드 종속성을 소프트 종속성으로 변환하는 정상적인 성능 저하 구현
구성 요소의 종속성이 비정상 상태인 경우에도 구성 요소 자체가 성능이 저하된 방식으로 작동할 수 있습니다. 예를 들어 종속성 호출이 실패하면 미리 결정된 정적 응답으로 장애 조치됩니다.
서비스 A가 서비스 B를 호출하고 서비스 B는 서비스 C를 호출하는 경우
![\[서비스 B가 서비스 C를 호출할 때 서비스 C가 실패하는 것을 보여주는 다이어그램. 서비스 B는 성능이 저하된 응답을 서비스 A에 반환함\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/graceful-degradation.png)
서비스 B가 서비스 C를 호출할 때 서비스 B는 서비스 C로부터 오류 또는 시간 초과를 수신합니다. 서비스 B는 서비스 C(및 여기에 포함된 데이터)의 응답이 없는 대신 가능한 것을 반환합니다. 이 값은 마지막으로 캐시된 정상 값이 될 수 있습니다. 또는 서비스 B는 서비스 C에서 수신했을 수 있는 것에 대해 미리 결정된 정적 응답을 대체할 수 있습니다. 그런 다음 호출자인 서비스 A에 성능이 저하된 응답을 반환할 수 있습니다. 이 정적 응답이 없다면 서비스 C의 장애가 서비스 B를 통해 서비스 A로 계단식으로 전달되어 가용성이 손실됩니다.
강한 종속성에 대한 가용성 방정식의 승인자( [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122)참조)에 따라 C의 가용성 손실은 B의 유효 가용성에 심각한 영향을 미칩니다. 서비스 B는 정적 응답을 반환함으로써 C의 장애를 완화하고 성능이 저하되기는 하지만 서비스 C의 가용성을 100%처럼 보이게 만듭니다(오류 조건에서 정적 응답을 성공적으로 반환한다는 가정하에). 정적 응답은 오류를 반환하는 것에 대한 단순한 대안이며 다른 수단을 사용하여 응답을 다시 계산하려는 시도가 아닙니다. 완전히 다른 메커니즘에서 동일한 결과를 얻기 위한 이러한 시도를 폴백 동작이라고 하는데 이는 피해야 할 안티패턴입니다.
단계적 성능 저하의 또 다른 예는 *회로 차단기 패턴입니다.*. 장애가 일시적인 경우에는 재시도 전략을 사용해야 합니다. 일시적이지 않고 작업이 실패할 가능성이 있는 경우 회로 차단기 패턴은 실패할 가능성이 있는 요청을 수행하지 못하도록 클라이언트를 차단합니다. 요청이 정상적으로 처리될 때는 회로 차단기가 닫히고 요청이 전송됩니다. 원격 시스템에서 오류를 반환하기 시작하거나 지연 시간이 길어지면 회로 차단기가 열리고 종속성이 무시되거나 덜 포괄적이지만 간단하게 얻을 수 있는 응답(단순한 응답 캐시일 수 있음)으로 결과가 대체됩니다. 시스템은 주기적으로 종속성 호출을 시도해 복구 여부를 확인합니다. 종속성이 복구된 경우에는 회로 차단기가 닫힙니다.
![\[회로 차단기가 열리고 닫힌 상태를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/circuit-breaker.png)
다이어그램에 표시된 닫힌 상태와 열린 상태 외에, 열린 상태에서 구성 가능한 기간이 지나면 회로 차단기가 반개방 상태로 전환될 수 있습니다. 이 상태에서는 평소보다 훨씬 낮은 속도로 주기적으로 서비스 호출이 시도됩니다. 이 탐색기는 서비스의 상태를 확인하는 데 사용됩니다. 반개방 상태에서 여러 번 성공하면 회로 차단기가 닫힌 상태로 전환되고 정상 요청이 재개됩니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 관련 하드 종속성을 소프트 종속성으로 변환하는 정상적인 성능 저하를 구현합니다. 구성 요소의 종속성이 비정상 상태인 경우에도 구성 요소 자체가 성능이 저하된 방식으로 작동할 수 있습니다. 예를 들어 종속성 호출이 실패하면 미리 결정된 정적 응답으로 장애 조치됩니다.
+ 정적 응답을 반환함으로써 워크로드는 종속성에서 발생하는 장애를 완화합니다.
+ [Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability(Well-Architected 실습: 레벨 300: 상태 확인 구현 및 종속성 관리를 통한 안정성 개선)](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
+ 재시도 작업이 실패할 가능성이 있는 경우 이를 감지하고 회로 차단기 패턴을 이용해 클라이언트가 실패한 호출을 실행하지 못하도록 합니다.
+ [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html)
## 리소스
**관련 문서:**
+ [Amazon API Gateway: 처리량 향상을 위해 API 요청 제한](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker('Release It\$1' 도서의 회로 차단기 요약)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [AWS의 오류 재시도 및 지수 백오프](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard 'Release It\$1 Design and Deploy Production-Ready Software(Release It\$1 프로덕션 지원 소프트웨어 설계 및 배포)'](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [Amazon Builders' Library: 분산 시스템의 폴백 방지](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: 심각한 수준의 대기열 백로그 방지](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: 캐싱 관련 당면 과제 및 전략](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Amazon Builders' Library: 시간 제한, 재시도 및 지터를 사용한 백오프](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**관련 동영상:**
+ [재시도, 백오프 및 지터: AWS re:Invent 2019: Introducing The Amazon Builders’ Library(Amazon Builders’ Library 소개)(DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**관련 예시:**
+ [Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability(Well-Architected 실습: 레벨 300: 상태 확인 구현 및 종속성 관리를 통한 안정성 개선)](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL05-BP02 요청 제한
요청 제한은 예기치 않은 수요 증가에 대응하기 위한 완화 패턴입니다. 일부 요청은 처리되지만 정의된 제한을 초과하는 요청은 거부되고 병목 현상이 발생했음을 나타내는 메시지를 반환합니다. 클라이언트는 요청을 다시 중단하고 중단하거나 더 느린 속도로 다시 시도할 것이라는 기대입니다.
각 노드나 셀이 처리할 수 있는 확인된 요청 용량을 처리하도록 서비스를 설계해야 합니다. 이 용량은 로드 테스트를 통해 설정할 수 있습니다. 그런 다음 요청 도착 속도를 추적해야 하며, 임시 도착 속도가 이 한도를 초과하는 경우의 적절한 대응 방식은 요청이 쓰로틀링되었음을 알리는 것입니다. 그러면 사용자는 사용 가능 용량이 있을 수 있는 다른 노드 또는 셀에 대해 요청을 다시 시도할 수 있습니다. Amazon API Gateway는 요청을 제한할 수 있는 방법을 제공합니다. Amazon SQS와 Amazon Kinesis는 요청을 버퍼링하고 요청 속도를 원활하게 하고 비동기식으로 처리할 수 있는 요청에 대한 조절 필요성을 완화할 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 요청을 제한합니다. 예기치 않은 수요 증가에 대응하기 위한 완화 패턴입니다. 일부 요청은 처리되지만 정의된 제한을 초과하는 요청은 거부되고 병목 현상이 발생했음을 나타내는 메시지를 반환합니다. 클라이언트는 요청을 다시 중단하고 중단하거나 더 느린 속도로 다시 시도할 것이라는 기대입니다.
+ Amazon API Gateway 사용
+ [처리량 향상을 위해 API 요청 조절](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
## 리소스
**관련 문서:**
+ [Amazon API Gateway: 처리량 향상을 위해 API 요청 제한](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS의 오류 재시도 및 지수 백오프](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders' Library: 분산 시스템의 폴백 방지](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: 심각한 수준의 대기열 백로그 방지](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: 시간 제한, 재시도 및 지터를 사용한 백오프](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [처리량 향상을 위해 API 요청 조절](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
**관련 동영상:**
+ [재시도, 백오프 및 지터: AWS re:Invent 2019: Introducing The Amazon Builders’ Library(Amazon Builders’ Library 소개)(DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP03 재시도 호출 제어 및 제한
지수 백오프를 사용하여 점진적으로 더 긴 간격 후에 다시 시도합니다. 지터를 도입하여 이러한 재시도 간격을 무작위로 지정하고 최대 재시도 횟수를 제한합니다.
분산 소프트웨어 시스템의 일반적인 구성 요소로는 서버, 로드 밸런서, 데이터베이스 및 DNS 서버가 있습니다. 작동 중일 때 장애가 발생하면 이러한 구성 요소 중 모든 구성 요소에서 오류가 생성되기 시작할 수 있습니다. 오류를 처리하는 기본 기술은 클라이언트 측에 재시도를 구현하는 것입니다. 이 기술은 애플리케이션의 안정성과 가용성을 높입니다. 그러나 오류가 발생하는 즉시 클라이언트가 실패한 작업을 대규모로 다시 시도할 경우 새 요청 및 만료된 요청이 각각 네트워크 대역폭을 두고 경합하여 네트워크가 빠르게 포화 상태가 될 수 있습니다. 이로 인해 *재시도 폭풍* 이 발생하고 서비스 가용성이 떨어집니다. 이 패턴은 전체 시스템 장애가 발생할 때까지 계속될 수 있습니다.
이러한 상황을 방지하려면 일반적인 *지수 백오프* )을 사용해야 합니다. 지수 백오프 알고리즘은 재시도가 수행되는 속도를 점진적으로 줄여 네트워크 정체를 방지합니다.
AWS의 SDK를 비롯한 많은 SDK 및 소프트웨어 라이브러리가 이러한 알고리즘 버전을 구현합니다. 하지만 **백오프 알고리즘이 존재한다고 가정하지 말고 항상 이를 테스트하고 확인하십시오.**
단순한 백오프만으로는 충분하지 않습니다. 분산 시스템에서는 모든 클라이언트가 동시에 백오프되어 재시도 호출의 클러스터가 생성될 수 있기 때문입니다. Marc Brooker의 블로그 게시물 [Exponential Backoff and Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/)에는 지수 백오프에서 wait() 함수를 수정하여 재시도 호출 클러스터를 방지하는 방법이 설명되어 있습니다. 해결 방법은 *지터* 를 wait() 함수에 추가하는 것입니다. 장시간의 재시도를 방지하려면 구현 시 백오프를 최대값으로 제한해야 합니다.
마지막으로, *최대 재시도 횟수* 또는 재시도를 실패로 처리할 경과 시간을 구성하는 것이 중요합니다. AWS SDK는 이 기능을 기본적으로 구현하며 이 기능은 구성이 가능합니다. 스택에서 아래에 있는 서비스의 경우 최대 재시도 제한이 0 또는 1이면 위험이 제한될 수 있지만, 재시도가 스택에서 더 위에 있는 서비스로 위임되므로 여전히 유효합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 재시도 호출을 제어 및 제한합니다. 지수 백오프를 사용하여 점진적으로 더 긴 간격 후에 다시 시도합니다. 지터를 도입하여 이러한 재시도 간격을 무작위로 지정하고 최대 재시도 횟수를 제한합니다.
+ [AWS의 오류 재시도 및 지수 백오프](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ Amazon SDK는 기본적으로 재시도와 지수 백오프를 구현합니다. 자체 종속 서비스를 호출할 때 종속성 계층에 비슷한 로직을 구현합니다. 사용 사례를 기반으로 시간 초과 대상 및 재시도 중단 시점을 결정합니다.
## 리소스
**관련 문서:**
+ [Amazon API Gateway: 처리량 향상을 위해 API 요청 제한](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS의 오류 재시도 및 지수 백오프](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders' Library: 분산 시스템의 폴백 방지](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: 심각한 수준의 대기열 백로그 방지](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: 캐싱 관련 당면 과제 및 전략](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Amazon Builders' Library: 시간 제한, 재시도 및 지터를 사용한 백오프](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**관련 동영상:**
+ [재시도, 백오프 및 지터: AWS re:Invent 2019: Introducing The Amazon Builders’ Library(Amazon Builders’ Library 소개)(DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP04 빠른 실패 및 대기열 제한
워크로드가 요청에 성공적으로 응답할 수 없는 경우 빠르게 실패합니다. 이렇게 하면 요청에 연결된 리소스를 해제할 수 있고 리소스가 부족한 경우 서비스 복구를 허용할 수 있습니다. 워크로드가 성공적으로 응답할 수 있지만 요청 속도가 너무 높은 경우에는 대기열을 사용하여 요청을 버퍼링합니다. 하지만 긴 대기열을 허용하지 마십시오. 대기열이 길면 클라이언트가 이미 포기한 무효 요청을 처리할 수 있습니다.
이 모범 사례는 요청의 서버 측 또는 수신자에 적용됩니다.
대기열은 시스템의 여러 수준에서 생성될 수 있습니다. 대기열에서는 최근 요청보다 더 이상 응답이 필요하지 않은 오래된 무효 요청이 먼저 처리되므로 빠른 복구 기능에 심각한 영향을 미칠 수 있습니다. 그러므로 대기열이 있는 위치를 숙지해야 합니다. 일반적으로 대기열은 워크플로 또는 데이터베이스에 기록된 작업에 숨겨집니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 빠르게 실패하고 대기열을 제한합니다. 워크로드가 요청에 성공적으로 응답할 수 없는 경우 빠르게 실패합니다. 이렇게 하면 요청에 연결된 리소스를 해제할 수 있고 리소스가 부족한 경우 서비스 복구를 허용할 수 있습니다. 워크로드가 성공적으로 응답할 수 있지만 요청 속도가 너무 높은 경우에는 대기열을 사용하여 요청을 버퍼링합니다. 하지만 긴 대기열을 허용하지 마십시오. 대기열이 길면 클라이언트가 이미 포기한 무효 요청을 처리할 수 있습니다.
+ 서비스가 부담을 받고 있는 상황에서 빠른 실패를 구현합니다.
+ [Fail Fast(빠른 실패)](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ 대기열을 제한합니다. 대기열 기반 시스템에서는 처리가 중지되었는데도 메시지가 계속 수신될 경우 처리되지 않은 메시지가 대용량 백로그에 누적되어 처리 시간이 늘어날 수 있습니다. 작업이 너무 늦게 완료되어 결과가 소용 없게 되고, 결국 대기열을 통해 방지되었어야 할 가용성 히트가 발생할 수 있습니다.
+ [Amazon Builders' Library: 심각한 수준의 대기열 백로그 방지](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
## 리소스
**관련 문서:**
+ [AWS에서의 오류 재시도 및 지수 백오프](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Fail Fast(빠른 실패)](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [Amazon Builders' Library: 분산 시스템의 폴백 방지](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: 심각한 수준의 대기열 백로그 방지](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: 캐싱 관련 당면 과제 및 전략](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Amazon Builders' Library: 시간 제한, 재시도 및 지터를 사용한 백오프](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**관련 동영상:**
+ [재시도, 백오프 및 지터: AWS re:Invent 2019: Amazon Builders’ Library 소개(DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP05 클라이언트 시간 제한 설정
시간 제한을 적절히 설정하고, 체계적으로 확인합니다. 기본값을 사용해서는 안 됩니다. 기본값은 일반적으로 너무 높게 설정됩니다.
이 모범 사례는 요청의 클라이언트 측 또는 발신자에 적용됩니다.
원격 호출과 일반적으로 프로세스 전체의 모든 호출에 연결 시간 제한과 요청 시간 제한을 모두 설정합니다. 기본적인 시간 제한 기능을 제공하는 프레임워크가 많지만 기본값이 무한하거나 너무 높은 경우가 많으므로 주의해야 합니다. 값이 너무 높으면 클라이언트가 시간 제한이 발생할 때까지 대기하는 동안 리소스가 계속 소비되기 때문에 시간 제한의 유용성이 감소합니다. 값이 너무 낮으면 백엔드에서 트래픽이 증가하고 너무 많은 요청이 재시도되므로 지연 시간이 증가할 수 있습니다. 일부 경우에는 모든 요청이 재시도되기 때문에 이로 인해 전체 중단이 발생할 수 있습니다.
Amazon에서 시간 제한, 재시도 및 지터를 사용한 백오프를 사용하는 방법에 대한 자세한 내용은 다음을 참조하십시오. [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card).
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 원격 호출과 일반적으로 프로세스 전체의 모든 호출에 연결 시간 제한과 요청 시간 제한을 모두 설정합니다. 기본적인 시간 제한 기능을 제공하는 프레임워크가 많지만 기본값이 무한하거나 너무 높은 경우가 많으므로 주의해야 합니다. 값이 너무 높으면 클라이언트가 시간 제한이 발생할 때까지 대기하는 동안 리소스가 계속 소비되기 때문에 시간 제한의 유용성이 감소합니다. 값이 너무 낮으면 백엔드에서 트래픽이 증가하고 너무 많은 요청이 재시도되므로 지연 시간이 증가할 수 있습니다. 일부 경우에는 모든 요청이 재시도되기 때문에 이로 인해 전체 중단이 발생할 수 있습니다.
+ [AWS SDK: 재시도 및 시간 제한](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
## 리소스
**관련 문서:**
+ [AWS SDK: 재시도 및 시간 제한](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon API Gateway: 처리량 향상을 위해 API 요청 제한](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS에서의 오류 재시도 및 지수 백오프](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders' Library: 시간 제한, 재시도 및 지터를 사용한 백오프](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**관련 동영상:**
+ [재시도, 백오프 및 지터: AWS re:Invent 2019: Amazon Builders’ Library 소개(DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP06 가능한 경우 서비스를 스테이트리스로 설계
서비스는 상태를 필요로 하지 않거나 디스크 및 메모리의 로컬로 저장된 데이터에 종속성이 없도록 서로 다른 클라이언트 요청 간에 상태를 오프로드해야 합니다. 이를 통해 가용성에 영향을 주지 않고 서버를 원하는 방식으로 교체할 수 있습니다. Amazon ElastiCache 또는 Amazon DynamoDB는 오프로드된 상태에 적합한 대상입니다.
![\[이 스테이스리스 웹 애플리케이션에서는 세션 상태가 Amazon ElastiCache로 오프로드됩니다.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/stateless-webapp.png)
사용자 또는 서비스는 애플리케이션과 상호 작용할 때 세션을 구성하는 일련의 상호 작용을 수행하는 경우가 많습니다. 세션은 애플리케이션을 사용하는 동안 요청 간에 유지되는 사용자의 고유한 데이터입니다. 상태 비저장 애플리케이션은 이전 상호 작용에 대한 지식을 필요로 하지 않으며 세션 정보를 저장하지 않는 애플리케이션입니다.
스테이스리스로 설계된 경우 AWS Lambda 또는 AWS Fargate와 같은 서버리스 컴퓨팅 서비스를 사용할 수 있습니다.
서버 대체 외에 상태 비저장 애플리케이션의 또 다른 이점은 사용 가능한 컴퓨팅 리소스(예: EC2 인스턴스 및 AWS Lambda 함수)로 모든 요청을 처리할 수 있기 때문에 수평적으로 확장할 수 있다는 것입니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 애플리케이션을 스테이스리스로 생성합니다. 무상태 애플리케이션은 수평 확장을 가능하게 하며, 개별 노드의 장애에 대한 내결함성이 있습니다.
+ 요청 파라미터에 실제로 저장될 수 있는 상태를 제거합니다.
+ 상태가 필요한지 여부를 조사한 후 상태 추적을 Amazon ElastiCache, Amazon RDS, Amazon DynamoDB 또는 서드 파티 분산 데이터 솔루션과 같은 복원성이 있는 다중 영역 캐시 데이터 스토어로 옮깁니다. 복원성이 있는 데이터 스토어로 옮길 수 없는 상태를 저장합니다.
+ 일부 데이터(쿠키 등)는 헤더 또는 쿼리 파라미터로 전달될 수 있습니다.
+ 리팩터링을 통해 요청에 빠르게 전달될 수 있는 상태를 제거합니다.
+ 일부 데이터는 요청별로 필요하지 않으며 요청에 따라 검색 시 검색될 수 있습니다.
+ 비동기식으로 검색할 수 있는 데이터를 제거합니다.
+ 필수 상태 요구 사항을 충족하는 데이터 스토어를 결정합니다.
+ 비관계형 데이터를 위한 NoSQL 데이터베이스를 고려합니다.
## 리소스
**관련 문서:**
+ [Amazon Builders' Library: 분산 시스템의 폴백 방지](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: 심각한 수준의 대기열 백로그 방지](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: 캐싱 관련 당면 과제 및 전략](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
# REL05-BP07 비상 레버 구현
비상 레버는 워크로드의 가용성에 미치는 영향을 신속하게 완화할 수 있는 프로세스입니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 비상 레버를 구현합니다. 이 프로세스는 워크로드의 가용성에 미치는 영향을 신속하게 완화할 수 있는 프로세스입니다. 이 프로세스는 근본 원인이 없는 상태에서 작동할 수 있습니다. 이상적인 비상 레버는 완전히 결정적인 활성화 및 비활성화 기준을 제공하여 확인자에 대한 인지 부담을 0으로 줄여줍니다. 레버는 수동인 경우가 많지만 자동화할 수도 있습니다.
+ 예시 레버:
+ 모든 로봇 트래픽 차단
+ 동적 페이지 대신 정적 페이지 제공
+ 종속성으로의 호출 빈도 축소
+ 종속성으로부터의 호출 제한
+ 비상 레버 구현 및 사용을 위한 팁
+ 레버가 활성화되면 더 적은 수의 작업을 수행
+ 단순하게 유지하고 바이모달 동작을 방지
+ 레버를 정기적으로 테스트
+ 다음은 비상 레버가 아닌 작업의 예입니다.
+ 용량 추가
+ 서비스를 사용하는 클라이언트의 서비스 소유자를 호출하고 호출을 줄이도록 요청
+ 코드 변경 및 릴리스
# 변경 사항 관리
**Topics**
+ [REL 6 워크로드 리소스는 어떻게 모니터링합니까?](w2aac19b9b9b5.md)
+ [REL 7 수요 변경에 따라 조정되도록 워크로드를 설계하려면 어떻게 해야 합니까?](w2aac19b9b9b7.md)
+ [REL 8 변경 사항은 어떻게 적용합니까?](w2aac19b9b9b9.md)
# REL 6 워크로드 리소스는 어떻게 모니터링합니까?
로그와 지표는 워크로드의 상태를 파악할 수 있는 유용한 도구입니다. 로그 및 지표를 모니터링하여 임계값을 초과하거나 중요한 이벤트가 발생하면 알림을 보내도록 워크로드를 구성할 수 있습니다. 모니터링을 수행하면 워크로드가 저성능 임계값을 초과하거나 장애가 발생할 때를 인식하고 이에 대응하여 자동으로 복구할 수 있습니다.
**Topics**
+ [REL06-BP01 워크로드의 모든 구성 요소 모니터링(생성)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 지표 정의 및 계산(집계)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 알림 전송(실시간 처리 및 경보)](rel_monitor_aws_resources_notification_monitor.md)
+ [REL06-BP04 응답 자동화(실시간 처리 및 경보)](rel_monitor_aws_resources_automate_response_monitor.md)
+ [REL06-BP05 분석](rel_monitor_aws_resources_storage_analytics.md)
+ [REL06-BP06 정기적인 검토 시행](rel_monitor_aws_resources_review_monitoring.md)
+ [REL06-BP07 시스템을 통한 요청의 종단 간 추적 모니터링](rel_monitor_aws_resources_end_to_end.md)
# REL06-BP01 워크로드의 모든 구성 요소 모니터링(생성)
Amazon CloudWatch 또는 서드파티 도구를 사용하여 워크로드의 구성 요소를 모니터링합니다. AWS Health 대시보드를 사용하여 AWS 서비스를 모니터링합니다.
프런트엔드, 비즈니스 로직 및 스토리지 계층을 포함하여 워크로드의 모든 구성 요소를 모니터링해야 합니다. 필요한 경우 주요 지표를 정의하고 로그에서 지표를 추출하는 방법을 설명하고 해당 경보 이벤트를 트리거하는 임계값을 설정합니다. 지표가 워크로드의 핵심 성과 지표(KPI)와 연관이 있도록 해야 하며 지표와 로그를 사용하여 서비스 성능 저하의 조기 지표를 파악합니다. 예를 들어, 분당 성공적으로 처리된 주문 수와 같은 비즈니스 성과와 관련된 지표는 CPU 사용량과 같은 기술적 지표보다 워크로드 문제를 더 빠르게 알려줍니다. AWS Health 대시보드를 사용하여 AWS 리소스의 기반이 되는 AWS 서비스의 성능 및 가용성에 대한 맞춤형 보기를 제공합니다.
클라우드에서 모니터링은 새로운 기회를 제공합니다. 대부분의 클라우드 공급업체는 사용자 지정 가능한 후크를 개발했으며 여러 계층의 워크로드를 모니터링하는 데 도움이 되는 인사이트를 제공할 수 있습니다. Amazon CloudWatch 등의 AWS 서비스는 통계 및 기계 학습 알고리즘을 적용하여 시스템 및 애플리케이션의 지표를 지속적으로 분석하고, 일반적인 기준을 결정하며, 사용자의 개입을 최소화하면서 이상 현상을 알립니다. 이상 탐지 알고리즘은 지표의 계절성과 추세 변화를 설명합니다.
AWS는 사용할 수 있는 모니터링 및 로그 정보를 풍부하게 제공하며 사용자는 워크로드별 지표를 정의하고, 수요가 있는 프로세스를 변경하고, ML 전문성과 상관없이 기계 학습 기법을 도입하는 데 이 정보를 사용할 수 있습니다.
또한 모든 외부 엔드포인트를 모니터링하여 기본 구현과 독립되어 있는지 확인합니다. 이 능동 모니터링은 *사용자 Canary라고도 하는*가상 트랜잭션에도 수행할 수 있지만 카나리 배포와 혼동해서는 안 됩니다. 가상 트랜잭션은 워크로드의 클라이언트가 수행하는 일반적인 다수의 태스크 매칭 작업을 주기적으로 실행합니다. 이 태스크의 기간은 짧아야 하며 테스트 중에 워크로드에 과부하가 발생하지 않아야 합니다. Amazon CloudWatch Synthetics를 사용하면 엔드포인트 및 API 모니터링을 위한 [가상 Canary를 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 할 수 있습니다. 가상 Canary 클라이언트 노드를 AWS X-Ray 콘솔과 함께 사용하여 선택한 기간에 오류, 장애 또는 조절 속도 문제를 경험하는 가상 Canary를 식별할 수도 있습니다.
**원하는 결과:**
워크로드의 모든 구성 요소로부터 핵심적인 지표를 수집하고 사용하여 워크로드 안정성과 최적의 사용자 경험을 보장합니다. 워크로드가 비즈니스 성과를 달성하지 못하고 있음을 탐지하면 재해 상황임을 빠르게 선언하고 인시던트에서 복구할 수 있습니다.
**일반적인 안티 패턴:**
+ 워크로드에 대한 외부 인터페이스만 모니터링
+ 워크로드별 지표를 생성하지 않으며 워크로드에서 사용하는 AWS 서비스에서 제공되는 지표에만 의존함
+ 워크로드에서 기술적인 지표만 사용하며 워크로드가 기여하는 비기술적 KPI와 관련한 지표는 모니터링하지 않음
+ 프로덕션 트래픽 및 단순한 상태 확인에 의존하여 워크로드 상태를 모니터링하고 평가함
**이 모범 사례 정립의 이점:** 워크로드의 모든 티어에서 모니터링할 경우 워크로드를 구성하는 구성 요소의 문제를 보다 신속하게 예측하고 해결할 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
1. **가능한 경우 로깅을 활성화합니다.** 모니터링 데이터는 워크로드의 모든 구성 요소로부터 수집해야 합니다. S3 Access Logs 등의 추가 로깅을 활성화하고 워크로드가 워크로드별 데이터를 로깅하도록 합니다. Amazon ECS, Amazon EKS, Amazon EC2, Elastic Load Balancing, AWS Auto Scaling, Amazon EMR 등의 서비스로부터 CPU, 네트워크 I/O, 디스크 I/O 평균 지표를 수집합니다. 참조 [CloudWatch 지표를 게시하는 AWS 서비스](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 에서 CloudWatch에 지표를 게시하는 AWS 서비스의 목록을 참조합니다.
1. **모든 기본 지표를 검토하고 데이터 수집에 간극이 있는지 확인합니다.** 모든 서비스에서는 기본 지표를 생성합니다. 기본 지표를 수집하면 워크로드 구성 요소 간의 종속성을 이해하고 구성 요소 안정성과 성능이 워크로드에 어떤 영향을 미치는지 파악할 수 있습니다. 직접 지표를 생성하고 [지표를](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) CloudWatch에 게시할 수 있습니다. AWS CLI 또는 API를 사용하면 됩니다. 이
1. **모든 지표를 평가하여 워크로드의 각 AWS 서비스에 어떤 지표를 알릴지 결정합니다.** 워크로드 안정성에 큰 영향을 미치는 지표의 하위 집합을 선택할 수도 있습니다. 핵심 지표와 임계값에 집중하면 [알림](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 의 수를 정리하고 허위 양성을 최소화할 수 있습니다.
1. **알림과 알림이 트리거된 후 워크로드의 복구 프로세스를 정의합니다.** 알림을 정의하면 인시던트로부터 복구하는 데 필요한 단계를 빠르게 알리고, 에스컬레이션하고, 단계를 따라 사전에 정해진 Recovery Time Objective(RTO)를 달성할 수 있습니다. 전용 인프라에서 [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) 를 사용하여 자동화된 워크플로를 호출하고 정의된 임계값에 따라 복구 절차를 시작할 수 있습니다.
1. **워크로드 상태에 대한 관련 데이터를 수집하기 위해 가상 트랜잭션을 사용하는 방법을 알아보세요.** 가상 모니터링은 고객과 같은 경로를 따르고 같은 작업을 수행하므로 워크로드에 고객 트래픽이 없더라도 고객 경험을 지속적으로 확인할 수 있습니다. 이렇게 [가상 트랜잭션을](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)사용함으로써 고객보다 먼저 문제를 발견할 수 있습니다.
## 리소스
**관련 모범 사례:**
+ [REL11-BP03 모든 계층에서 복구 자동화](rel_withstand_component_failures_auto_healing_system.md)
**관련 문서:**
+ [AWS Health 대시보드 시작하기 - 계정 상태](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)
+ [CloudWatch 지표를 게시하는 AWS 서비스](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Network Load Balancer에 대한 액세스 로그](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html)
+ [Application Load Balancer에 대한 액세스 로그](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html)
+ [AWS Lambda의 Amazon CloudWatch Logs 액세스](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html)
+ [Amazon S3 서버 액세스 로깅](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html)
+ [Classic Load Balancer에 대한 액세스 로그 활성화(Classic Load Balancer에 대한 액세스 로그 활성화)](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html)
+ [Amazon S3로 로그 데이터 내보내기](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [Amazon EC2 인스턴스에 CloudWatch 에이전트 설치](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html)
+ [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Amazon CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Amazon CloudWatch 지표 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Canary 사용(Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Amazon CloudWatch Logs란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
**사용 설명서:**
+ [추적 생성](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)
+ [Amazon EC2 Linux 인스턴스의 메모리 및 디스크 지표 모니터링](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html)
+ [컨테이너 인스턴스와 CloudWatch Logs 사용](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [VPC 흐름 로그](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html)
+ [Amazon DevOps Guru란 무엇입니까?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [AWS X-Ray란 무엇입니까?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
**관련 블로그:**
+ [Amazon CloudWatch Synthetics 및 AWS X-Ray를 사용한 디버깅](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
**관련 예시 및 워크숍:**
+ [AWS Well-Architected 실습: 운영 우수성 - 종속성 모니터링](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/)
+ [Amazon Builders' Library: 운영 가시성을 위한 분산 시스템 계측](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [관찰 가능성 워크숍](https://catalog.workshops.aws/observability/en-US)
# REL06-BP02 지표 정의 및 계산(집계)
로그 데이터를 저장하고 필요한 경우 필터를 적용하여 특정 로그 이벤트 수 또는 로그 이벤트 타임스탬프에서 계산된 지연 시간과 같은 지표를 계산합니다.
Amazon CloudWatch 및 Amazon S3는 기본 집계 및 스토리지 계층으로 사용됩니다. AWS Auto Scaling 및 Elastic Load Balancing와 같은 일부 서비스에서는 클러스터나 인스턴스 전반에 걸쳐 CPU 로드 또는 평균 요청 지연 시간 관련 기본 지표가 기본적으로 제공됩니다. VPC Flow Logs 및 AWS CloudTrail과 같은 스트리밍 서비스의 경우에는 이벤트 데이터가 CloudWatch Logs로 전달되며, 이벤트 데이터에서 지표를 추출하려면 지표 필터를 정의하고 적용해야 합니다. 이렇게 하면 시계열 데이터가 나오며 알림을 트리거하도록 정의한 CloudWatch 경보에 대한 입력으로 이 데이터를 사용할 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 지표를 정의 및 계산(집계)합니다. 로그 데이터를 저장하고 필요한 경우 필터를 적용하여 특정 로그 이벤트 수 또는 로그 이벤트 타임스탬프에서 계산된 지연 시간과 같은 지표를 계산합니다.
+ 지표 필터는 로그 데이터가 CloudWatch Logs에 전송될 때 찾아야 하는 용어와 패턴을 정의합니다. CloudWatch Logs는 이 지표 필터를 사용하여 로그 데이터를 숫자 형식의 CloudWatch 지표로 변환하여 사용자가 그래프를 작성하거나 경보를 설정할 수 있도록 합니다.
+ [로그 데이터 검색 및 필터링](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ 신뢰할 수 있는 서드 파티 도구를 사용하여 로그를 집계합니다.
+ 해당 서드 파티의 지침을 따릅니다. 대부분의 서드 파티 제품은 CloudWatch 및 Amazon S3와 통합됩니다.
+ 일부 AWS 서비스는 로그를 Amazon S3에 직접 게시할 수 있습니다. Amazon S3에 저장하는 것이 로그의 주요 요구 사항인 경우, 추가 인프라를 설정하지 않고도 로그를 생성하는 서비스가 로그를 Amazon S3로 직접 전송하도록 할 수 있습니다.
+ [Amazon S3로 로그를 직접 전송](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
## 리소스
**관련 문서:**
+ [Amazon CloudWatch Logs Insights 샘플 쿼리](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Amazon CloudWatch Synthetics 및 AWS X-Ray를 사용한 디버깅](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [로그 데이터 검색 및 필터링](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Amazon S3로 로그를 직접 전송](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
+ [Amazon Builders' Library: 운영 가시성을 위한 분산 시스템 계측](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP03 알림 전송(실시간 처리 및 경보)
중요한 이벤트가 발생할 때 알아야 하는 조직에 알림이 전송됩니다.
Amazon Simple Notification Service(Amazon SNS) 주제로 알림을 전송한 다음 원하는 수의 구독자에게 푸시할 수 있습니다. 예를 들어 Amazon SNS는 기술 직원이 응답할 수 있도록 특정 이메일 별칭으로 알림을 전달할 수 있습니다.
**일반적인 안티 패턴:**
+ 임계값을 너무 낮게 구성하여 알림이 너무 많이 전송되도록 함
+ 향후 조사할 수 있도록 경보를 보관하지 않음
**이 모범 사례 정립의 이점:** 이벤트에 대한 알림(응답할 수 있고 자동으로 해결할 수 있는 알림 포함)을 통해 이벤트 기록을 확보할 수 있으며 향후에 다른 방식으로 이벤트를 처리할 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 실시간 처리 및 경보 설정을 수행합니다. 중요한 이벤트가 발생할 때 알아야 하는 조직에 알림이 전송됩니다.
+ Amazon CloudWatch 대시보드는 CloudWatch 콘솔의 맞춤형 홈페이지로, 다른 리전에 분산되어 있는 리소스까지 포함하여 모든 리소스를 단일 보기에서 모니터링하는 데 이용할 수 있습니다.
+ [Amazon CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ 지표가 한도를 초과하는 경우 경보를 생성합니다.
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## 리소스
**관련 문서:**
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [Amazon Builders' Library: 운영 가시성을 위한 분산 시스템 계측](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Amazon CloudWatch 지표 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
# REL06-BP04 응답 자동화(실시간 처리 및 경보)
: 이벤트가 감지되면 자동화를 사용하여 실패한 구성 요소를 대체하는 등의 조치를 취합니다.
알림을 통해 AWS Auto Scaling 이벤트를 트리거할 수 있으며, 그러면 클러스터가 수요 변경에 대응할 수 있습니다. 서드 파티 티켓 시스템용 통합 지점으로 사용 가능한 Amazon Simple Queue Service(Amazon SQS)로 알림을 전송할 수도 있습니다. AWS Lambda에서도 알림을 구독하여 변경에 동적으로 대응하는 비동기 서버리스 모델을 사용자에게 제공할 수 있습니다. AWS Config는 AWS 리소스 구성을 지속적으로 모니터링하고 기록하며 [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 을 트리거하여 문제를 해결할 수 있습니다.
Amazon DevOps Guru는 애플리케이션 리소스가 비정상적으로 작동하는지를 자동으로 모니터링하고 표적화된 권장 사항을 제공하여 문제 파악 및 해결 시간을 단축합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ Amazon DevOps Guru를 사용하여 자동화된 작업을 수행합니다. Amazon DevOps Guru는 애플리케이션 리소스가 비정상적으로 작동하는지를 자동으로 모니터링하고 표적화된 권장 사항을 제공하여 문제 파악 및 해결 시간을 단축합니다.
+ [Amazon DevOps Guru란 무엇입니까?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ AWS Systems Manager를 사용하여 자동화된 작업을 수행합니다. AWS Config는 AWS 리소스 구성을 지속적으로 모니터링하고 기록하며 AWS Systems Manager Automation을 트리거하여 문제를 해결할 수 있습니다.
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ Systems Manager Automation 문서를 생성하고 사용합니다. 이는 자동화 프로세스를 실행할 때 Systems Manager가 관리형 인스턴스 및 기타 AWS 리소스에서 수행하는 작업을 정의합니다.
+ [자동화 문서 작업(플레이북)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ Amazon CloudWatch가 경보 상태 변화 이벤트를 Amazon EventBridge에 전송합니다. 응답을 자동화하는 EventBridge 규칙을 생성합니다.
+ [AWS 리소스의 이벤트에서 트리거되는 EventBridge 규칙 생성](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ 응답 자동화를 위한 계획을 수립하고 실행합니다.
+ 모든 알림 응답 절차의 인벤토리를 작성합니다. 작업 순위를 정하기 전에 알림 응답을 계획해야 합니다.
+ 수행해야 할 특정 작업이 있는 모든 작업의 인벤토리를 작성합니다. 이러한 작업은 대부분 런북에 문서화됩니다. 예기치 않은 이벤트의 알림에 대한 플레이북도 있어야 합니다.
+ 런북 및 플레이북을 조사하여 자동화 가능한 작업을 모두 파악합니다. 일반적으로, 정의할 수 있는 작업은 대부분 자동화할 수 있습니다.
+ 오류가 발생하기 쉽거나 시간이 많이 걸리는 활동을 최우선으로 합니다. 오류의 원인을 제거하고 해결 시간을 단축하는 데 따른 효과가 가장 크기 때문입니다.
+ 자동화를 수행하기 위한 계획을 수립합니다. 자동화 및 업데이트를 위한 계획을 활성 상태로 유지합니다.
+ 수작업 요구 사항을 검토하여 자동화할 여지가 없는지 확인합니다. 수작업 프로세스를 검토하여 자동화 기회를 확인합니다.
## 리소스
**관련 문서:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS 리소스의 이벤트에서 트리거되는 EventBridge 규칙 생성](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [Amazon Builders' Library: 운영 가시성을 위한 분산 시스템 계측](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Amazon DevOps Guru란 무엇입니까?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [자동화 문서 작업(플레이북)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
# REL06-BP05 분석
로그 파일 및 지표 기록을 수집하고 이를 분석하여 더 광범위한 추세 및 워크로드 인사이트를 확보합니다.
Amazon CloudWatch Logs Insights는 로그 데이터를 분석하는 데 사용할 수 있는 [단순하지만 강력한 쿼리 언어](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) 를 지원합니다. Amazon CloudWatch Logs 또한 구독을 지원하므로 데이터를 Amazon S3로 원활하게 보내 여기서 데이터를 사용하거나 Amazon Athena로 보내 데이터를 쿼리할 수 있습니다. 다양한 형식의 쿼리도 지원됩니다. 참조 [지원되는 SerDes 및 데이터 형식](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html) (Amazon Athena 사용 설명서에 있음)에서 자세한 내용을 참조하세요. 방대한 로그 파일 세트를 분석하려면 Amazon EMR 클러스터를 실행하여 페타바이트 규모의 분석을 실행할 수 있습니다.
AWS 파트너와 서드파티에서 제공하는 다양한 도구를 집계, 처리, 저장 및 분석에 사용할 수 있습니다. 이러한 도구에는 New Relic, Splunk, Loggly, Logstash, CloudHealth 및 Nagios가 포함됩니다. 그러나 시스템과 애플리케이션 외부에서 생성되는 로그는 각 클라우드 공급자별로 다르며 각 서비스별로 다른 경우도 많습니다.
모니터링 프로세스에서 간과되는 경우가 많은 작업 중 하나로 데이터 관리를 들 수 있습니다. 데이터 모니터링을 위한 보존 요구 사항을 확인한 후 그에 따라 수명 주기 정책을 적용해야 합니다. Amazon S3는 S3 버킷 수준에서 수명 주기 관리를 지원합니다. 버킷의 각 경로에 이 수명 주기 관리 기능을 각기 다르게 적용할 수 있습니다. 수명 주기 종료가 가까워지면 장기 저장을 위해 데이터를 Amazon Glacier로 전환한 다음 보존 기간이 종료되면 데이터를 만료 처리할 수 있습니다. S3 Intelligent-Tiering 스토리지 클래스는 성능 영향이나 운영 오버헤드 없이 데이터를 가장 비용 효율적인 티어로 자동으로 이동하여 비용을 최적화하도록 설계되었습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ CloudWatch Logs Insights를 사용하면 Amazon CloudWatch Logs의 로그 데이터를 대화식으로 검색하고 분석할 수 있습니다.
+ [CloudWatch Logs Insights를 사용한 로그 데이터 분석](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Amazon CloudWatch Logs Insights 샘플 쿼리](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ Amazon CloudWatch Logs를 사용하여 사용할 수 있는 Amazon S3에 로그를 전송하거나 Amazon Athena에 전송하여 데이터를 쿼리합니다.
+ [Athena를 사용하여 Amazon S3 서버 액세스 로그를 분석하려면 어떻게 해야 합니까?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ 서버 액세스 로그 버킷에 대한 S3 수명 주기 정책을 생성합니다. 로그 파일을 주기적으로 제거하도록 수명 주기 정책을 구성합니다. 이러한 정책을 구성하면 Athena에서 각 쿼리에 대해 분석되는 데이터의 양이 줄어듭니다.
+ [S3 버킷에 대한 수명 주기 정책을 생성하려면 어떻게 해야 하나요?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
## 리소스
**관련 문서:**
+ [Amazon CloudWatch Logs Insights 샘플 쿼리](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [CloudWatch Logs Insights를 사용한 로그 데이터 분석](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Amazon CloudWatch Synthetics 및 AWS X-Ray를 사용한 디버깅](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [S3 버킷에 대한 수명 주기 정책을 생성하려면 어떻게 해야 하나요?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
+ [Athena를 사용하여 Amazon S3 서버 액세스 로그를 분석하려면 어떻게 해야 합니까?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [Amazon Builders' Library: 운영 가시성을 위한 분산 시스템 계측](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP06 정기적인 검토 시행
워크로드 모니터링이 구현되는 방식을 자주 검토하고 중요한 이벤트 및 변경 사항에 따라 업데이트합니다.
효과적인 모니터링의 기반은 주요 비즈니스 지표입니다. 비즈니스 우선 순위가 변경됨에 따라 이러한 지표가 워크로드에 반영되는지 확인하십시오.
모니터링을 감사하면 애플리케이션이 가용성 목표를 달성하는 시기를 확인하는 데 도움이 됩니다. 근본 원인 분석을 수행하려면 장애 발생 시에 수행된 작업을 검색하는 기능이 필요합니다. AWS는 인시던트 중에 서비스의 상태를 추적할 수 있는 서비스를 제공합니다.
+ **Amazon CloudWatch Logs:** 로그를 저장하고 해당 내용을 검사할 수 있는 서비스입니다.
+ **Amazon CloudWatch Logs Insights**: 대량 로그를 몇 초 만에 분석할 수 있는 완전관리형 서비스입니다. 이 서비스는 빠른 대화형 쿼리 및 시각화를 제공합니다.
+ **AWS Config:** 다양한 시점에서 사용된 AWS 인프라를 확인할 수 있습니다.
+ **AWS CloudTrail:** 특정 시간에 호출된 AWS API 및 기준으로 사용된 원칙을 확인할 수 있는 서비스입니다.
AWS에서는 주간 회의를 개최하여 [운영 성과를 검토하고](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 알게 된 내용을 팀 간에 공유합니다. AWS에는 많은 팀이 있기 때문에 검토할 워크로드를 무작위로 선택하는 [The Wheel](https://aws.amazon.com/blogs/opensource/the-wheel/) 을 만들었습니다. 운영 성능 검토 및 지식 공유를 위한 정기 케이던스를 설정하면 운영 팀의 성과를 개선하는 역량을 발전시킬 수 있습니다.
**일반적인 안티 패턴:**
+ 기본 지표만 수집
+ 모니터링 전략을 설정한 후 다시 검토하지 않음
+ 주요 변경 사항이 배포될 때 모니터링에 대해 논의하지 않음
**이 모범 사례 수립의 이점:** 모니터링을 정기적으로 검토하면 예상된 문제가 실제로 발생할 때 알림에 대응하는 것이 아니라 잠재적인 문제를 미리 예측할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 워크로드에 대해 여러 대시보드를 생성합니다. 주요 비즈니스 지표는 물론, 다양한 사용량에서 예상되는 워크로드의 상태와 가장 관련성이 높은 것으로 확인된 기술 지표도 포함된 최상위 대시보드가 있어야 합니다. 또한 검사할 수 있는 다양한 애플리케이션 티어와 종속성에 대한 대시보드도 필요합니다.
+ [Amazon CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ 워크로드 대시보드에 대한 정기적인 검토 일정을 예약하고 검토를 수행합니다. 대시보드를 정기적으로 검사합니다. 검사하는 세부 수준을 나타내는 다양한 케이던스를 구성할 수 있습니다.
+ 지표에서 추세를 검사합니다. 지표 값을 과거 값과 비교하여 조사해야 할 문제가 있음을 시사하는 추세가 나타나는지 확인합니다. 이러한 예로는 지연 시간 증가, 주요 비즈니스 기능 감소, 장애 응답 증가 등이 있습니다.
+ 지표에서 특이값/이상 항목을 검사합니다. 평균 또는 중간값은 특이값 및 이상 항목을 감출 수 있습니다. 해당 기간 동안의 가장 높은 값과 가장 낮은 값을 살펴보고 극단적인 값의 원인을 조사합니다. 이러한 원인을 계속 제거하면서 극단성을 낮추면 워크로드 성능의 일관성을 지속적으로 개선할 수 있습니다.
+ 동작의 급격한 변화를 찾습니다. 지표의 수량 또는 방향이 갑자기 바뀔 경우, 애플리케이션이 변경되었거나 외부 요인이 발생한 것일 수 있습니다. 이 같은 외부 요인으로 인해 추적할 지표를 추가해야 할 수 있습니다.
## 리소스
**관련 문서:**
+ [Amazon CloudWatch Logs Insights 샘플 쿼리](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Amazon CloudWatch Synthetics 및 AWS X-Ray를 사용한 디버깅](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [Amazon Builders' Library: 운영 가시성을 위한 분산 시스템 계측](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Amazon CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
# REL06-BP07 시스템을 통한 요청의 종단 간 추적 모니터링
개발자는 AWS X-Ray 또는 서드파티 도구를 사용하여 분산 시스템을 보다 쉽게 분석하고 디버깅하여 애플리케이션과 기반 서비스의 성능을 파악할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 시스템을 통한 요청의 엔드 투 엔드 추적을 모니터링합니다. AWS X-Ray는 애플리케이션이 처리하는 요청에 대한 데이터를 수집하고, 최적화 문제와 기회를 식별하기 위해 데이터를 보고, 필터링하고, 인사이트를 얻는 데 사용할 수 있는 도구를 제공하는 웹 서비스입니다. 애플리케이션에 대한 요청이 추적되면, 해당 요청 및 응답뿐 아니라 애플리케이션이 다운스트림 AWS 리소스, 마이크로서비스, 데이터베이스 및 웹 API에 대해 수행한 호출과 관련하여 자세한 정보를 확인할 수 있습니다.
+ [AWS X-Ray란 무엇입니까?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Amazon CloudWatch Synthetics 및 AWS X-Ray를 사용한 디버깅](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
## 리소스
**관련 문서:**
+ [Amazon CloudWatch Synthetics 및 AWS X-Ray를 사용한 디버깅](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [One Observability Workshop](https://observability.workshop.aws/)
+ [Amazon Builders' Library: 운영 가시성을 위한 분산 시스템 계측](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Canary 사용(Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [AWS X-Ray란 무엇입니까?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
# REL 7 수요 변경에 따라 조정되도록 워크로드를 설계하려면 어떻게 해야 합니까?
확장 가능한 워크로드는 리소스를 자동으로 추가하거나 제거하여 특정 시기의 수요에 리소스 공급을 맞출 수 있는 탄력성을 제공합니다.
**Topics**
+ [REL07-BP01 리소스를 확보하거나 조정할 때 자동화 사용](rel_adapt_to_changes_autoscale_adapt.md)
+ [REL07-BP02 워크로드 장애 감지 시 리소스 확보](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [REL07-BP03 워크로드에 더 많은 리소스가 필요한 것으로 감지되면 리소스 확보](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [REL07-BP04 워크로드 로드 테스트](rel_adapt_to_changes_load_tested_adapt.md)
# REL07-BP01 리소스를 확보하거나 조정할 때 자동화 사용
손상된 리소스를 교체하거나 워크로드 크기를 조정할 때 Amazon S3 및 AWS Auto Scaling과 같은 관리형 AWS 서비스를 사용하여 프로세스를 자동화합니다. 서드 파티 도구 및 AWS SDK를 사용하여 크기를 자동 조정할 수도 있습니다.
관리형 AWS 서비스에는 Amazon S3, Amazon CloudFront, AWS Auto Scaling, AWS Lambda, Amazon DynamoDB, AWS Fargate, Amazon Route 53가 있습니다.
AWS Auto Scaling을 사용하면 손상된 인스턴스를 감지하고 교체할 수 있습니다. 또한 [Amazon EC2](https://aws.amazon.com/ec2/) 인스턴스 및 스팟 플릿, [Amazon ECS](https://aws.amazon.com/ecs/) 태스크, [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 테이블 및 인덱스와 [Amazon Aurora](https://aws.amazon.com/aurora/) 복제본에 대한 조정 계획을 수립할 수도 있습니다.
EC2 인스턴스의 크기를 조정할 때는 여러 가용 영역(3개 이상 권장)을 사용하고 용량을 추가하거나 제거하여 이러한 가용 영역 간의 균형을 유지해야 합니다. ECS 태스크 또는 Kubernetes 포드(Amazon Elastic Kubernetes Service를 사용하는 경우) 역시 여러 개의 가용 영역에 분산되어야 합니다.
AWS Lambda를 사용하는 경우에는 인스턴스가 자동으로 조정됩니다. 함수에 대한 이벤트 알림이 수신될 때마다 AWS Lambda가 컴퓨팅 플릿 내에서 여유 용량을 신속하게 찾고 할당된 동시성까지 코드를 실행합니다. 사용자는 필요한 동시성이 특정 Lambda와 Service Quotas에 구성되어 있는지 확인해야 합니다.
Amazon S3는 높은 요청 속도를 처리하도록 자동으로 확장됩니다. 예를 들어 애플리케이션은 버킷에서 접두사마다 초당 3,500개 이상의 PUT/COPY/POST/DELETE 및 5,500개의 GET/HEAD 요청을 전송할 수 있습니다. 버킷의 접두사 수에는 제한이 없습니다. 읽기를 병렬화하여 읽기 또는 쓰기 성능을 높일 수 있습니다. 예를 들어 Amazon S3 버킷에서 10개의 접두사를 생성하여 읽기를 병렬화하는 경우 읽기 성능을 초당 55,000개의 읽기 요청으로 확장할 수 있습니다.
Amazon CloudFront 또는 신뢰할 수 있는 콘텐츠 전송 네트워크(CDN)를 구성하고 사용합니다. CDN은 더 빠른 최종 사용자 응답 시간을 제공할 수 있으며 콘텐츠 요청을 캐시에서 처리하므로 워크로드의 크기를 확대할 필요가 줄어듭니다.
**일반적인 안티 패턴:**
+ 자동 복구를 위해 Auto Scaling 그룹을 구현하지만 탄력성은 구현하지 않음
+ Auto Scaling을 사용하여 트래픽의 대규모 증가에 대응
+ 고도의 상태 저장 애플리케이션을 배포하여 탄력성 옵션을 없앰
**이 모범 사례 수립의 이점:** 자동화는 리소스를 배포하고 폐기할 때 수작업으로 인한 오류가 발생할 가능성을 없앱니다. 자동화는 배포 또는 폐기 요구 사항에 대한 느린 대응으로 인해 비용이 초과하거나 서비스가 거부될 위험성을 없앱니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ AWS Auto Scaling을 구성하고 사용합니다. 애플리케이션을 모니터링하고 용량을 자동으로 조정하여 최저 비용으로 안정적이고 예측 가능한 성능을 유지할 수 있습니다. AWS Auto Scaling을 사용하면 여러 서비스에 걸쳐 여러 리소스에 대한 애플리케이션 크기 조정을 설정할 수 있습니다.
+ [AWS Auto Scaling이란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ Amazon EC2 인스턴스, 스팟 플릿, Amazon ECS 태스크, Amazon DynamoDB 테이블 및 인덱스, Amazon Aurora 복제본, AWS Marketplace 어플라이언스에 적절하게 Auto Scaling을 구성합니다.
+ [DynamoDB Auto Scaling을 통한 처리량 용량 자동 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ 서비스 API 작업을 사용하여 경보, 확장 정책, 가동 준비 시간 및 중단 시간을 지정합니다.
+ Elastic Load Balancing을 사용합니다. 로드 밸런서는 경로별 또는 네트워크 연결별로 로드를 분산할 수 있습니다.
+ [Elastic Load Balancing이란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ Application Load Balancers는 경로별로 로드를 배포할 수 있습니다.
+ [Application Load Balancer란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ 도메인 이름의 하위 경로를 기준으로 다른 워크로드에 트래픽을 분산하도록 Application Load Balancer를 구성합니다.
+ Application Load Balancers를 사용해 AWS Auto Scaling과 통합하는 방식으로 수요를 관리해 로드를 분산할 수 있습니다.
+ [오토 스케일링 그룹과 함께 로드 밸런서 사용](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ Network Load Balancer는 연결별로 로드를 분산합니다.
+ [Network Load Balancer란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ TCP를 사용하여 다른 워크로드로 트래픽을 분산하도록 Network Load Balancer를 구성하거나 워크로드가 일정한 IP 주소 집합을 갖도록 합니다.
+ Network Load Balancer를 사용해 AWS Auto Scaling과 통합하는 방식으로 수요를 관리해 로드를 분산할 수 있습니다.
+ 가용성 높은 DNS 공급자를 사용합니다. DNS 이름을 사용하면 사용자가 IP 주소 대신 이름을 입력하여 워크로드에 액세스하고 이 정보를 정의된 범위, 즉 일반적으로 워크로드 사용자의 경우 전역적으로 배포할 수 있습니다.
+ Amazon Route 53 또는 신뢰할 수 있는 DNS 제공업체를 사용합니다.
+ [Amazon Route 53란 무엇입니까?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ Route 53를 사용하여 CloudFront 배포 및 로드 밸런서를 관리합니다.
+ 관리할 도메인 및 하위 도메인을 결정하십시오.
+ ALIAS 또는 CNAME 레코드를 사용하여 적절한 레코드 세트를 생성합니다.
+ [레코드 작업](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)
+ AWS 글로벌 네트워크를 사용하여 사용자로부터 애플리케이션으로의 경로를 최적화합니다. AWS Global Accelerator는 30초 이내에 애플리케이션 엔드포인트의 상태를 지속적으로 모니터링하고 트래픽을 정상 엔드포인트로 리디렉션합니다.
+ AWSGlobal Accelerator는 로컬 또는 글로벌 사용자에 대해 애플리케이션의 가용성과 성능을 개선하는 서비스입니다. Application Load Balancers, Network Load Balancer 또는 Amazon EC2 인스턴스 등, 하나 또는 여러 AWS 리전에서 애플리케이션 엔드포인트에 고정된 진입점 역할을 하는 고정 IP 주소를 제공합니다.
+ [AWS Global Accelerator란 무엇입니까?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ Amazon CloudFront 또는 신뢰할 수 있는 콘텐츠 전송 네트워크(CDN)를 구성하고 사용합니다. 콘텐츠 전송 네트워크를 사용하면 최종 사용자 입장에서는 응답 시간을 단축할 수 있으며 워크로드를 불필요하게 확장할 수 있는 콘텐츠 요청을 처리할 수 있습니다.
+ [Amazon CloudFront란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ 워크로드에 Amazon CloudFront 배포를 구성하거나 서드 파티 CDN을 사용합니다.
+ CloudFront의 IP 범위를 엔드포인트 보안 그룹 또는 액세스 정책에 사용함으로써 워크로드에 대한 액세스를 제한하여 CloudFront에서만 액세스할 수 있도록 할 수 있습니다.
## 리소스
**관련 문서:**
+ [APN 파트너: 자동화된 컴퓨팅 솔루션의 생성을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27)
+ [AWS Auto Scaling: 조정 계획 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: 오토 스케일링과 함께 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [DynamoDB Auto Scaling을 통한 처리량 자동 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [오토 스케일링 그룹과 함께 로드 밸런서 사용](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ [AWS Global Accelerator란 무엇입니까?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [Amazon EC2 Auto Scaling란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [AWS Auto Scaling이란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ [Amazon CloudFront란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected)
+ [Amazon Route 53란 무엇입니까?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [Elastic Load Balancing이란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [Network Load Balancer란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [Application Load Balancer란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [레코드 작업](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)
# REL07-BP02 워크로드 장애 감지 시 리소스 확보
가용성이 영향을 받는 경우 필요에 따라 리소스를 사후에 확장하여 워크로드 가용성을 복원합니다.
먼저 상태 확인과 이러한 확인에 대한 기준을 구성하여 리소스 부족으로 인해 가용성이 영향을 받는 시기를 나타내야 합니다. 그런 다음 적절한 담당자에게 수동으로 리소스를 조정하도록 알리거나 자동화를 트리거하여 자동으로 리소스를 조정합니다.
워크로드에 맞게 적절하게 수동으로 규모를 조정할 수 있습니다. 예를 들어 AWS Management Console 또는 AWS CLI를 통해 Auto Scaling 그룹의 EC2 인스턴스 수를 변경하거나 DynamoDB 테이블의 처리량을 수정할 수 있습니다. 하지만 가능한 경우에는 항상 자동화를 사용해야 합니다( **리소스를 확보하거나 조정할 때 자동화 사용**)는 SAP NetWeaver Guide Finder 및 SAP NetWeaver Security Guide를 참조하세요.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 워크로드 장애 감지 시 리소스를 확보합니다. 가용성이 영향을 받는 경우 필요에 따라 리소스를 사후에 확장하여 워크로드 가용성을 복원합니다.
+ AWS Auto Scaling의 핵심 구성 요소인 크기 조정 계획을 사용하여 리소스 크기 조정을 위한 지침 집합을 구성합니다. AWS CloudFormation을 사용하거나 AWS 리소스에 태그를 추가하는 경우 애플리케이션마다 서로 다른 리소스 집합에 대해 크기 조정 계획을 설정할 수 있습니다. AWS Auto Scaling은 각 리소스에 맞춤화된 크기 조정 전략에 대한 권장 사항을 제공합니다. 크기 조정 계획을 생성하면 AWS Auto Scaling이 동적 조정과 예측 조정 방식을 결합하여 조정 전략을 지원합니다.
+ [AWS Auto Scaling: 조정 계획 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Amazon EC2 Auto Scaling을 사용하면 애플리케이션의 로드를 처리하는 데 사용할 수 있는 적절한 수의 Amazon EC2 인스턴스를 확보할 수 있습니다. Auto Scaling 그룹이라는 EC2 인스턴스 모음을 생성합니다. 각 Auto Scaling 그룹의 최소 인스턴스 수를 지정할 수 있으며, Amazon EC2 Auto Scaling은 사용하면 그룹의 크기가 이 값 아래로 내려가지 않게 합니다. 각 오토 스케일링 그룹의 최대 인스턴스 수를 지정할 수 있으며, Amazon EC2 Auto Scaling은 그룹의 크기가 이 값을 초과하지 않게 합니다.
+ [Amazon EC2 Auto Scaling이란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ Amazon DynamoDB Auto Scaling은 AWS Application Auto Scaling 서비스를 사용하여 사용자를 대신해 실제 트래픽 패턴에 따라 프로비저닝된 처리량 용량을 동적으로 조정합니다. 따라서 테이블 또는 글로벌 보조 인덱스를 통해 프로비저닝된 읽기 및 쓰기 용량을 늘려 조절 없이 급증하는 트래픽을 처리할 수 있습니다.
+ [DynamoDB Auto Scaling을 통한 처리량 자동 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
## 리소스
**관련 문서:**
+ [APN 파트너: 자동화된 컴퓨팅 솔루션의 생성을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27)
+ [AWS Auto Scaling: 조정 계획 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: 오토 스케일링과 함께 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [DynamoDB Auto Scaling을 통한 처리량 자동 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Amazon EC2 Auto Scaling이란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP03 워크로드에 더 많은 리소스가 필요한 것으로 감지되면 리소스 확보
수요를 충족하고 가용성에 영향을 미치지 않도록 리소스를 사전에 확장합니다.
많은 AWS 서비스가 수요에 맞춰 자동으로 확장됩니다. Amazon EC2 인스턴스 또는 Amazon ECS 클러스터를 사용하는 경우 워크로드 수요에 해당하는 사용량 지표에 따라 이러한 자동 조정이 수행되도록 구성할 수 있습니다. Amazon EC2의 경우 평균 CPU 사용률, 로드 밸런서 요청 수 또는 네트워크 대역폭을 사용하여 EC2 인스턴스를 스케일아웃(또는 스케일인)할 수 있습니다. Amazon ECS의 경우 평균 CPU 사용률, 로드 밸런서 요청 수 및 메모리 사용률을 사용하여 ECS 작업을 스케일 아웃(또는 스케일 인)할 수 있습니다. AWS에서 Target Auto Scaling을 사용하면 Autoscaler가 가정용 온도 조절기처럼 작동하여 리소스를 추가하거나 제거함으로써 지정한 목표 값(예: 70%의 CPU 사용률)을 유지합니다.
또한 AWS Auto Scaling은 기계 학습을 사용하여 각 리소스의 기간별 워크로드를 분석하고 향후 2일간의 로드를 주기적으로 예측하는 [Predictive Auto Scaling](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)을 수행할 수도 있습니다.
리틀의 법칙은 필요한 컴퓨팅 인스턴스(EC2 인스턴스, 동시 Lambda 함수 등) 수를 계산하는 데 도움이 됩니다.
*L* = *λW*
L = 인스턴스 수(또는 시스템의 평균 동시성)
λ = 요청이 도착하는 평균 속도(요청/초)
W = 시스템이 각 요청에 소비하는 평균 시간(초)
예를 들어 100rps에서 각 요청을 처리하는 데 0.5초가 걸리는 경우 수요를 따라가려면 50개의 인스턴스가 필요합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 워크로드에 더 많은 리소스가 필요한 것으로 감지되면 리소스를 확보합니다. 수요를 충족하고 가용성에 영향을 미치지 않도록 리소스를 사전에 확장합니다.
+ 지정된 요청 속도를 처리하는 데 필요한 컴퓨팅 리소스(컴퓨팅 동시성)를 계산합니다.
+ [Telling Stories About Little's Law](https://brooker.co.za/blog/2018/06/20/littles-law.html)
+ 사용량에 대한 과거 패턴이 있는 경우 Amazon EC2 Auto Scaling에 대한 예약된 조정을 설정합니다.
+ [Amazon EC2 Auto Scaling의 예약된 조정](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ AWS 예측 크기 조정을 사용합니다.
+ [Predictive Scaling for EC2, Powered by Machine Learning(기계 학습 기반 EC2용 예측 확장)](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
## 리소스
**관련 문서:**
+ [AWS Auto Scaling: 조정 계획 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: 오토 스케일링과 함께 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [DynamoDB Auto Scaling을 통한 처리량 자동 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Predictive Scaling for EC2, Powered by Machine Learning(기계 학습 기반 EC2용 예측 확장)](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Amazon EC2 Auto Scaling의 예약된 조정](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ [Telling Stories About Little's Law](https://brooker.co.za/blog/2018/06/20/littles-law.html)
+ [Amazon EC2 Auto Scaling란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP04 워크로드 로드 테스트
확장 작업이 워크로드의 필요 사항을 충족하는지 측정하기 위한 로드 테스트 방식을 채택하십시오.
지속적인 로드 테스트를 수행하는 것이 중요합니다. 로드 테스트를 통해 한계점을 찾고 워크로드의 성능을 테스트할 수 있습니다. AWS를 사용하면 프로덕션 워크로드의 규모를 모델링하는 임시 테스트 환경을 쉽게 설정할 수 있습니다. 클라우드에서는 온디맨드 방식으로 프로덕션 규모의 테스트 환경을 만들고, 테스트를 완료한 다음 해당 리소스를 폐기할 수 있습니다. 테스트 환경을 실행하는 동안에만 비용을 지불하면 되기 때문에 온프레미스 테스트 비용의 몇 분의 일에 불과한 가격으로 실제 환경을 시뮬레이션할 수 있습니다.
또한 프로덕션에서의 로드 테스트는 프로덕션 시스템에 스트레스가 가해지는 실전 연습의 일부로 간주되어야 하며 고객 사용량이 적은 시간에는 모든 직원이 결과를 해석하고 발생하는 문제를 해결해야 합니다.
**일반적인 안티 패턴:**
+ 구성이 프로덕션 환경과 동일하지 않은 배포에 대해 로드 테스트 수행
+ 전체 워크로드가 아니라 워크로드의 개별 부분에 대해서만 로드 테스트 수행
+ 대표적인 실제 요청 세트가 아니라 요청의 하위 집합을 사용하여 로드 테스트 수행
+ 예상 부하보다 작은 안전 계수로 부하 테스트 수행
**이 모범 사례 수립의 이점:** 로드 시 장애가 발생하는 아키텍처의 구성 요소를 알고 있으며, 해당 로드에 곧 도달할 것임을 나타내는 지표를 식별하고 조사하여 문제를 해결할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 로드 테스트를 수행하여 워크로드의 어느 측면에 용량을 추가 또는 제거해야 하는지 파악합니다. 로드 테스트에는 프로덕션 환경에서 수신하는 것과 유사한 대표 트래픽이 있어야 합니다. 계측한 지표를 모니터링하면서 로드를 늘려 리소스를 추가 또는 제거해야 하는 시점을 나타내는 지표를 결정합니다.
+ [AWS에서의 분산 로드 테스트: 수천 명의 연결된 사용자 시뮬레이션](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ 요청의 조합을 식별합니다. 다양한 요청 조합이 있을 수 있으므로 트래픽 조합을 식별할 때 다양한 시간 프레임을 살펴봐야 합니다.
+ 로드 드라이버를 구현합니다. 사용자 지정 코드, 오픈 소스 또는 상용 소프트웨어를 사용하여 로드 드라이버를 구현할 수 있습니다.
+ 처음에는 작은 용량을 사용하여 로드 테스트를 수행합니다. 인스턴스 또는 컨테이너 하나 정도의 작은 용량으로 로드를 유도하면 즉각적인 효과가 나타납니다.
+ 더 큰 용량에 대해 로드 테스트를 수행합니다. 분산된 부하에서는 효과가 다르게 나타나므로 가능한 한 제품 환경에 가깝게 테스트해야 합니다.
## 리소스
**관련 문서:**
+ [AWS에서의 분산 로드 테스트: 수천 명의 연결된 사용자 시뮬레이션](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
# REL 8 변경 사항은 어떻게 적용합니까?
새로운 기능을 배포하고 워크로드와 운영 환경에서 알려진 소프트웨어를 실행하고 예측 가능한 방식으로 패치 또는 교체할 수 있도록 하려면 변경 사항을 제어해야 합니다. 이러한 변경이 제어되지 않으면 변경의 영향을 예측하거나 변경으로 인해 발생하는 문제를 해결하기가 어려워집니다.
**Topics**
+ [REL08-BP01 배포와 같은 표준 활동에 런북 사용](rel_tracking_change_management_planned_changemgmt.md)
+ [REL08-BP02 배포의 일부로 기능 테스트 통합](rel_tracking_change_management_functional_testing.md)
+ [REL08-BP03 배포의 일부로 복원력 테스트 통합](rel_tracking_change_management_resiliency_testing.md)
+ [REL08-BP04 변경 불가능한 인프라를 사용하여 배포](rel_tracking_change_management_immutable_infrastructure.md)
+ [REL08-BP05 자동화를 통한 변경 사항 배포](rel_tracking_change_management_automated_changemgmt.md)
# REL08-BP01 배포와 같은 표준 활동에 런북 사용
런북은 특정 결과를 달성하기 위한 미리 정의된 절차입니다. 수동 또는 자동으로 표준 활동을 수행할 때 런북을 사용합니다. 워크로드 배포, 워크로드 패치 적용 또는 DNS 수정과 같은 활동이 여기에 포함됩니다.
예를 들어 [배포 중에 롤백이 안전한지 확인하는 프로세스를 준비합니다.](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments). 서비스를 안정적으로 유지하려면 고객 중단 없이 배포를 롤백할 수 있는지 확인하는 것이 중요합니다.
런북 절차를 수행할 때는 유효하고 효과적인 수동 프로세스에서 시작하고, 이를 코드에 구현한 다음, 필요한 경우 자동으로 실행되도록 트리거합니다.
고도로 자동화된 정교한 워크로드의 경우에도 [게임 데이를 실행하거나](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays) 엄격한 보고 및 감사 요구 사항을 충족할 때 런북을 유용하게 사용할 수 있습니다.
플레이북은 특정 인시던트에 대응하여 사용되며 런북은 특정 결과를 달성하기 위해 사용됩니다. 런북은 일상적인 활동에 대한 것이고, 플레이북은 일상적이지 않은 이벤트에 대응하는 데 사용되는 경우가 많습니다.
**일반적인 안티 패턴:**
+ 프로덕션 환경에서 계획되지 않은 구성 변경 수행
+ 더 빠르게 배포하기 위해 계획의 단계를 건너뛰고, 그 결과 배포에 실패
+ 변경 사항 되돌리기를 테스트하지 않고 변경 수행
**이 모범 사례 수립의 이점:** 변경 계획을 효과적으로 수립하면 영향을 받는 모든 시스템을 파악할 수 있으므로 변경 사항을 성공적으로 실행할 수 있습니다. 테스트 환경에서 변경 사항을 검증하면 신뢰성을 높일 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 런북에 절차를 문서화하면 잘 알려진 이벤트에 일관된 방식으로 신속하게 대응할 수 있습니다.
+ [AWS Well-Architected Framework: 개념: 런북](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ 코드형 인프라의 원칙을 사용해 인프라를 정의합니다. AWS CloudFormation 또는 신뢰할 수 있는 서드 파티 제품을 사용하여 인프라를 정의하면 버전 제어 소프트웨어를 통한 변경 사항의 각 버전을 차례대로 확인할 수 있습니다.
+ AWS CloudFormation 또는 신뢰할 수 있는 서드 파티 제품을 사용하여 인프라를 정의합니다.
+ [AWS CloudFormation이란 무엇인가요?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ 우수한 소프트웨어 설계 원칙으로 분리된 단일 템플릿을 생성합니다.
+ 구현 권한, 템플릿 및 책임자를 결정합니다.
+ [AWS Identity and Access Management로 액세스 제어 ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)
+ 버전을 제어하려면 AWS CodeCommit 또는 신뢰할 수 있는 서드 파티 도구와 같은 소스 제어를 사용합니다.
+ [AWS CodeCommit이란 무엇입니까?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
## 리소스
**관련 문서:**
+ [APN 파트너: 자동화된 배포 솔루션의 생성을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace: 배포 자동화에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [AWS Well-Architected Framework: 개념: 런북](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ [AWS CloudFormation이란 무엇인가요?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [AWS CodeCommit이란 무엇입니까?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
**관련 예시:**
+ [플레이북 및 런북으로 운영 자동화](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL08-BP02 배포의 일부로 기능 테스트 통합
기능 테스트는 자동화된 배포의 일부로 실행됩니다. 성공 기준이 충족되지 않으면 파이프라인이 중지되거나 롤백됩니다.
이러한 테스트는 파이프라인에서 프로덕션 전에 준비되는 사전 프로덕션 환경에서 실행됩니다. 이 작업을 배포 파이프라인의 일부로 수행하는 것이 가장 좋습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 배포의 일부로 기능 테스트를 통합합니다. 기능 테스트는 자동화된 배포의 일부로 실행됩니다. 성공 기준이 충족되지 않으면 파이프라인이 중지되거나 롤백됩니다.
+ AWS CodePipeline에 모델링된 소프트웨어 릴리스 파이프라인의 '테스트 작업'을 실행하는 중에 AWS CodeBuild를 호출합니다. 이 기능을 사용하면 단위 테스트, 정적 코드 분석, 통합 테스트 등 코드에 대해 다양한 테스트를 손쉽게 실행할 수 있습니다.
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild(AWS CodePipeline, AWS CodeBuild를 사용한 단위 및 맞춤형 통합 테스트 관련 지원 추가)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ AWS Marketplace 솔루션을 사용하여 소프트웨어 제공 파이프라인의 일부로 자동화된 테스트를 실행합니다.
+ [소프트웨어 테스트 자동화](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## 리소스
**관련 문서:**
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild(AWS CodePipeline, AWS CodeBuild를 사용한 단위 및 맞춤형 통합 테스트 관련 지원 추가)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [소프트웨어 테스트 자동화](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [AWS CodePipeline란 무엇입니까?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
# REL08-BP03 배포의 일부로 복원력 테스트 통합
복원력 테스트( [카오스 엔지니어링의 원칙 사용)](https://principlesofchaos.org/)는 사전 프로덕션 환경에서 자동화된 배포 파이프라인에 포함되어 실행됩니다.
이러한 테스트는 프로덕션 전 환경에서 파이프라인에서 준비되고 실행됩니다. 또한 프로덕션 환경에서도 다음의 일부로 실행되어야 합니다. [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays).
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 배포의 일부로 복원력 테스트를 통합합니다. 프로덕션 환경에서 격변의 조건을 견딜 수 있는 워크로드의 기능에 대한 신뢰성을 확보하기 위해 시스템을 실험하는 분야인 카오스 엔지니어링을 사용합니다.
+ 복원력 테스트는 결함 또는 리소스 저하를 발생시켜 워크로드가 설계된 복원력으로 대응하는지 평가합니다.
+ [Well-Architected lab: Level 300: Testing for Resiliency of EC2 RDS and S3(Well-Architected 실습: 레벨 300: EC2 RDS 및 S3의 복원력 테스트)](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
+ 이러한 테스트는 자동화된 배포 파이프라인의 사전 프로덕션 환경에서 정기적으로 실행할 수 있습니다.
+ 또한 예약된 게임 데이의 일부로 프로덕션에서 실행해야 합니다.
+ 카오스 엔지니어링 원칙을 사용하여 다양한 장애 하에서 워크로드의 성능이 어떻게 나타날지에 대한 가설을 제안한 다음 복원력 테스트를 사용하여 가설을 테스트합니다.
+ [Principles of Chaos Engineering(카오스 엔지니어링의 원칙)](https://principlesofchaos.org/)
## 리소스
**관련 문서:**
+ [Principles of Chaos Engineering(카오스 엔지니어링의 원칙)](https://principlesofchaos.org/)
+ [AWS Fault Injection Simulator란 무엇입니까?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**관련 예시:**
+ [Well-Architected lab: Level 300: Testing for Resiliency of EC2 RDS and S3(Well-Architected 실습: 레벨 300: EC2 RDS 및 S3의 복원력 테스트)](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
# REL08-BP04 변경 불가능한 인프라를 사용하여 배포
변경 불가능한 인프라는 프로덕션 워크로드의 현재 위치에서 업데이트, 보안 패치 또는 구성 변경이 발생하지 않도록 규정하는 모델입니다. 변경이 필요한 경우 아키텍처가 새 인프라에 구축되고 프로덕션 환경에 배포됩니다.
변경 불가능한 인프라 패러다임의 가장 일반적인 구현 형태는 ***변경 불가능한 서버입니다.***. 즉, 서버에 업데이트 또는 수정이 필요한 경우 이미 사용 중인 서버를 업데이트하는 대신 새 서버가 배포됩니다. 따라서 SSH를 통해 서버에 로그인하고 소프트웨어 버전을 업데이트하는 대신 애플리케이션의 모든 변경은 코드 리포지토리에 소프트웨어를 푸시(예: git push)하는 것으로 시작됩니다. 변경이 불가능한 인프라에서는 변경이 허용되지 않으므로 배포된 시스템의 상태를 확신할 수 있습니다. 변경이 불가능한 인프라는 본질적으로 더 일관되고 안정적이며 예측 가능하며 소프트웨어 개발 및 운영의 여러 측면을 간소화합니다.
변경이 불가능한 인프라에서 애플리케이션을 배포할 때는 Canary 또는 블루/그린 배포를 사용합니다.
[https://martinfowler.com/bliki/CanaryRelease.html](https://martinfowler.com/bliki/CanaryRelease.html) 는 일반적으로 단일 서비스 인스턴스에서 실행되는 새 버전(Canary)으로 소수의 사용자를 연결하는 방식입니다. 그런 다음 생성되는 동작 변경 또는 오류를 면밀히 조사합니다. 중대한 문제가 발생하여 사용자에게 이전 버전을 다시 제공해야 하는 경우에는 Canary에서 트래픽을 제거할 수 있습니다. 배포가 정상적으로 진행되면 배포가 완료될 때까지 변경 사항에서 오류를 모니터링하면서 원하는 속도로 배포를 계속 진행할 수 있습니다. Canary 배포를 지원하는 배포 구성을 사용하여 AWS CodeDeploy를 구성할 수 있습니다.
[https://martinfowler.com/bliki/BlueGreenDeployment.html](https://martinfowler.com/bliki/BlueGreenDeployment.html) 는 Canary 배포와 비슷합니다. 단, 전체 애플리케이션 플릿이 병렬로 배포됩니다. 이 패턴에서는 블루와 그린의 두 스택에서 번갈아 가며 배포를 수행합니다. 이 패턴에서도 새 버전으로 트래픽을 전송한 다음 배포에 문제가 발생하면 이전 버전으로 장애 복구할 수 있습니다. 일반적으로 모든 트래픽은 한 번에 전환되지만, Amazon Route 53의 가중치 기반 DNS 라우팅 기능을 사용하면 각 버전에 대한 트래픽의 일부를 사용하여 새 버전의 채택을 유도할 수도 있습니다. 블루/그린 배포를 지원하는 배포 구성을 사용하여 AWS CodeDeploy와 AWS Elastic Beanstalk를 구성할 수 있습니다.
![\[AWS Elastic Beanstalk 및 Amazon Route 53를 사용한 블루/그린 배포를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/blue-green-deployment.png)
변경 불가능한 인프라의 이점:
+ **구성 드리프트 감소:** 알려진 기본 버전 제어 구성에서 서버를 자주 교체하면 인프라가 알려진 상태로 **재설정되므로** 구성 드리프트가 방지됩니다.
+ **간소화된 배포**: 업그레이드를 지원할 필요가 없으므로 배포가 간소화됩니다. 업그레이드는 단지 새로운 배포일 뿐입니다.
+ **안정성 있는 원자 단위 배포:** 배포가 성공적으로 완료되거나 아무 것도 변경되지 않습니다. 따라서 배포 프로세스의 신뢰도가 개선됩니다.
+ **빠른 롤백 및 복구 프로세스를 통해 배포 안전성 개선:** 이전 작업 버전이 변경되지 않으므로 배포가 더 안전합니다. 오류가 감지되면 롤백할 수 있습니다.
+ **일관된 테스트 및 디버깅 환경:** 모든 서버에 동일한 이미지가 사용되므로 환경 간에 차이가 없습니다. 하나의 빌드가 여러 환경에 배포됩니다. 또한 일관되지 않은 환경이 방지되고 테스트 및 디버깅이 간소화됩니다.
+ **확장성 개선:** 서버가 기본 이미지를 사용하고 일관적이며 반복 가능하므로 자동 조정이 간단합니다.
+ **간소화된 도구 체인**: 프로덕션 소프트웨어 업그레이드를 관리하는 구성 관리 도구를 제거할 수 있으므로 도구 체인이 간소화됩니다. 서버에 추가 도구 또는 에이전트가 설치되지 않습니다. 변경은 기본 이미지에 수행되고 테스트된 후 롤아웃됩니다.
+ **보안 강화:** 서버에 대한 모든 변경을 거부하면 인스턴스에서 SSH를 비활성화하고 키를 제거할 수 있습니다. 이렇게 하면 공격 벡터가 줄어들어 조직의 보안 태세를 개선할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 변경 불가능한 인프라를 사용하여 배포합니다. 변경 불가능한 인프라는 프로덕션 시스템의 *현재 위치에서* 업데이트, 보안 패치 또는 구성 변경이 발생하지 않도록 규정하는 모델입니다. 변경이 필요한 경우 새 버전의 아키텍처가 구축되고 프로덕션 환경에 배포됩니다.
+ [블루/그린 배포 개요](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [Deploying Serverless Applications Gradually(점진적으로 서버리스 애플리케이션 배포)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [변경 불가능한 인프라: 불변성을 통한 안정성, 일관성 및 신뢰성](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
## 리소스
**관련 문서:**
+ [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
+ [Deploying Serverless Applications Gradually(점진적으로 서버리스 애플리케이션 배포)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [변경 불가능한 인프라: 불변성을 통한 안정성, 일관성 및 신뢰성](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [블루/그린 배포 개요](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [Amazon Builders' Library: 배포 중 롤백 안전 보장](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
# REL08-BP05 자동화를 통한 변경 사항 배포
배포 및 패치 적용이 자동화되므로 부정적인 영향이 제거됩니다.
프로덕션 시스템을 변경하는 것은 조직에서 가장 위험 부담이 큰 영역에 속합니다. 배포는 소프트웨어를 통해 해결할 수 있는 업무상의 문제와 더불어 해결해야 하는 가장 중요한 문제로 간주됩니다. 오늘날에는 배포 관련 문제를 해결하려면 운영 과정에서 해당하는 모든 영역(변경 사항 테스트/배포, 용량 추가/제거, 데이터 마이그레이션 포함)에 자동화를 사용해야 합니다. AWS CodePipeline을 사용하면 워크로드를 해제하는 데 필요한 단계를 관리할 수 있습니다. 여기에는 AWS CodeDeploy를 사용하여 Amazon EC2 인스턴스, 온프레미스 인스턴스, 서버리스 Lambda 함수 또는 Amazon ECS 서비스에 대한 애플리케이션 코드 배포를 자동화하는 배포 상태가 포함됩니다.
**권장 사항**
일반적인 통념으로는 가장 어려운 작업 절차에 사람을 투입하는 것이 좋다고 하지만 AWS에서는 바로 그런 이유로 가장 어려운 절차를 자동화할 것을 권장합니다.
**일반적인 안티 패턴:**
+ 수동으로 변경 수행
+ 비상 워크플로를 통해 자동화 단계를 건너뜀
+ 계획을 따르지 않음
**이 모범 사례 수립의 이점:** 자동화를 사용하여 모든 변경 사항을 배포하면 인적 오류가 발생할 가능성이 사라지고 프로덕션을 변경하기 전에 테스트하여 계획이 완료되었는지 확인할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 배포 파이프라인을 자동화합니다. 배포 파이프라인을 사용하면 이상 징후의 자동 테스트 및 탐지를 실행하여 프로덕션 배포 전 특정 단계에서 파이프라인을 중지하거나 변경 사항을 자동으로 롤백할 수 있습니다.
+ [Amazon Builders' Library: 배포 중 롤백 안전 보장](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [Amazon Builders' Library: 지속적 전달을 통한 신속한 배포](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ AWS CodePipeline 또는 신뢰할 수 있는 서드 파티 제품을 사용하여 파이프라인을 정의하고 실행합니다.
+ 코드 저장소에 변경 사항이 전달되고 나서 실행되도록 파이프라인을 구성합니다.
+ [AWS CodePipeline이란 무엇입니까?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ Amazon Simple Notification Service(Amazon SNS) 및 Amazon Simple Email Service(Amazon SES)를 사용하여 파이프라인의 문제에 대한 알림을 전송하거나 Amazon Chime과 같은 팀 채팅 도구에 통합합니다.
+ [Amazon Simple Notification Service란 무엇입니까?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [Amazon SES란 무엇입니까?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [Amazon Chime이란 무엇일까요?](https://docs.aws.amazon.com/chime/latest/ug/what-is-chime.html)
+ [Automate chat messages with webhooks(Webhook으로 채팅 메시지 기능 자동화)](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
## 리소스
**관련 문서:**
+ [APN 파트너: 자동화된 배포 솔루션의 생성을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace: 배포 자동화에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [Automate chat messages with webhooks(Webhook으로 채팅 메시지 기능 자동화)](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
+ [Amazon Builders' Library: 배포 중 롤백 안전 보장](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [Amazon Builders' Library: 지속적 전달을 통한 신속한 배포](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ [AWS CodePipeline란 무엇입니까?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ [CodeDeploy란 무엇입니까?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ [Amazon SES란 무엇입니까?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [Amazon Simple Notification Service란 무엇입니까?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
**관련 동영상:**
+ [AWS Summit 2019: CI/CD on AWS(AWS 기반 CI/CD)](https://youtu.be/tQcF6SqWCoY)
# 장애 관리
**Topics**
+ [REL 9 데이터는 어떻게 백업합니까?](w2aac19b9c11b5.md)
+ [REL 10 장애 격리를 사용하여 워크로드를 보호하려면 어떻게 해야 합니까?](w2aac19b9c11b7.md)
+ [REL 11 구성 요소 장애를 견디도록 워크로드를 설계하려면 어떻게 해야 합니까?](w2aac19b9c11b9.md)
+ [REL 12 안정성은 어떻게 테스트합니까?](w2aac19b9c11c11.md)
+ [REL 13 DR(재해 복구)를 어떻게 계획합니까?](w2aac19b9c11c13.md)
# REL 9 데이터는 어떻게 백업합니까?
RTO(복구 시간 목표) 및 RPO(복구 시점 목표)에 대한 요구 사항을 충족하도록 데이터, 애플리케이션 및 구성을 백업합니다.
**Topics**
+ [REL09-BP01 백업해야 하는 모든 데이터 확인 및 백업 또는 소스에서 데이터 재현](rel_backing_up_data_identified_backups_data.md)
+ [REL09-BP02 백업 보안 및 암호화](rel_backing_up_data_secured_backups_data.md)
+ [REL09-BP03 자동으로 데이터 백업 수행](rel_backing_up_data_automated_backups_data.md)
+ [REL09-BP04 백업 무결성 및 프로세스를 확인하기 위해 데이터의 주기적인 복구 수행](rel_backing_up_data_periodic_recovery_testing_data.md)
# REL09-BP01 백업해야 하는 모든 데이터 확인 및 백업 또는 소스에서 데이터 재현
모든 AWS 데이터 스토어는 백업 기능을 제공합니다. Amazon RDS 및 Amazon DynamoDB 등의 서비스는 추가적으로 시점 복구(PITR)를 활성화하는 자동화된 백업을 지원합니다. 따라서 현재 시간으로부터 최대 5분 전까지 원하는 시점으로 백업을 복원할 수 있습니다. 많은 AWS 서비스는 백업을 다른 AWS 리전으로 복사할 수 있는 기능을 제공합니다. AWS Backup 도구는 AWS 서비스 전체에서 데이터 보호를 중앙 집중화하고 자동화하는 기능을 제공합니다.
Amazon S3는 자체 관리형 및 AWS 관리형 데이터 소스의 백업 목적지로 사용할 수 있습니다. Amazon EBS, Amazon RDS, Amazon DynamoDB 등의 AWS 서비스는 기본적으로 백업을 생성하는 기능이 내장되어 있습니다. 서드 파티 백업 소프트웨어를 사용할 수도 있습니다.
온프레미스 데이터는 AWS 클라우드로 백업될 수 있습니다. 여기에는 [AWS Storage Gateway](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) 또는 [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)를 사용하면 됩니다. Amazon S3 버킷은 AWS에 이 데이터를 저장하는 데 사용할 수 있습니다. Amazon S3는 [Amazon Glacier 또는 S3 Glacier Deep Archive](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html) 등의 여러 스토리지 티어를 제공하여 데이터 스토리지의 비용을 절감해 줍니다.
다른 소스에서 데이터를 재현하여 데이터 복구 요구 사항을 충족할 수 있습니다. 예: [Amazon ElastiCache 복제본 노드](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) 또는 [RDS 읽기 전용 복제본을](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) 사용하면 기본 데이터가 손실되었을 때 데이터를 재현할 수 있습니다. 이런 소스를 사용하여 [Recovery Point Objective(RPO) 또는 Recovery Time Objective(RTO)를](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html)충족할 수 있는 경우 백업이 필요하지 않을 수 있습니다. 또 다른 예로, Amazon EMR을 사용하는 경우 HDFS 데이터 스토어를 백업할 필요가 없습니다(S3에서 [EMR로 데이터를 재현할 수 있는 한)](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/).
백업 전략을 선택할 때는 데이터 복구에 걸리는 시간을 고려하시기 바랍니다. 데이터를 복구하는 데 필요한 시간은 백업의 유형(백업 전략의 경우) 또는 데이터 재현 메커니즘의 복잡성에 따라 달라집니다. 이 시간은 워크로드의 RTO 이내여야 합니다.
**원하는 결과:**
데이터 소스가 식별되고 중요도에 따라 분류됩니다. 그런 다음 RPO에 따라 데이터 복구 전략을 수립합니다. 이 전략에는 데이터 소스 백업 또는 다른 소스에서 데이터를 재현하는 기능이 포함됩니다. 데이터가 손실될 경우 구현된 전략에 따라 정의된 RPO 또는 RTO 내에 복구 또는 데이터 재현이 가능합니다.
**클라우드 성숙도 단계:** Foundational
**일반적인 안티 패턴:**
+ 워크로드의 모든 데이터 소스와 그 중요도를 알지 못함
+ 중요한 데이터 소스의 백업을 생성하지 않음
+ 중요도를 기준으로 사용하지 않고 일부 데이터 소스의 백업만 생성함
+ RPO가 정의되지 않았거나 백업 주기가 RPO에 부합하지 않음
+ 백업이 필요한지 또는 데이터를 다른 소스에서 재현할 수 있는지 평가하지 않음
**이 모범 사례 수립의 이점:** 백업이 필요한 지점을 파악하고 백업 생성을 위한 메커니즘을 구현하거나 외부 소스에서 데이터를 재현할 수 있는 경우 중단 시 데이터를 복원하고 복구하는 역량이 향상됩니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
워크로드에 사용되는 AWS 서비스 및 리소스의 백업 기능을 숙지하고 사용합니다. 대부분의 AWS 서비스는 워크로드 데이터를 백업할 수 있는 기능을 제공합니다.
**구현 단계:**
1. **워크로드의 모든 데이터 소스를 파악합니다**. 데이터는 [데이터베이스](https://aws.amazon.com/products/databases/), [볼륨](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html), [파일 시스템](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html), [로깅 시스템](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)및 [객체 스토리지와 같이 다양한 리소스에 저장될 수 있습니다](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html). 애플리케이션이 이 시나리오에서 다루지 않는 검색 기능을 사용하는 경우 **리소스** 섹션에서 **관련 문서를** 참조하여 데이터가 저장되는 다양한 AWS 서비스와 이런 서비스가 제공하는 백업 기능에 관해 알아보세요.
1. **중요도에 따라 데이터 소스를 분류합니다.**. 데이터 세트마다 워크로드의 중요도가 다르므로 복원력에 대한 요구 사항도 달라집니다. 예를 들어, 어떤 데이터는 매우 중요하며 0에 가까운 RPO가 필요하지만 어떤 데이터는 덜 중요하며 더 높은 RPO와 일부 데이터 손실을 용인할 수 있습니다. 마찬가지로, 데이터 세트마다 RTO 요구 사항이 다릅니다.
1. **AWS 또는 서드 파티 서비스를 사용하여 데이터 백업을 생성합니다**. [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 은 AWS에 있는 다양한 데이터 소스의 백업을 생성할 수 있는 관리형 서비스입니다. 이런 서비스의 대부분은 백업을 생성하는 기능이 기본적으로 내장되어 있습니다. AWS Marketplace에도 이런 기능을 제공하는 솔루션이 많이 있습니다. 아래 나열된 **리소스** 에서 다양한 AWS 서비스에서 백업을 생성하는 방법에 관한 정보를 확인할 수 있습니다.
1. **백업되지 않는 데이터의 경우 데이터 재현 메커니즘을 수립합니다**. 여러 가지 이유로 다른 소스에서 재현될 수 있는 데이터는 백업하지 않기로 결정할 수 있습니다. 백업을 저장하는 데는 비용이 들기 때문에 백업을 생성하기보다는 필요할 때 다른 소스에서 데이터를 재현하는 것이 더 저렴한 상황이 있을 수도 있습니다. 또는 백업을 복원하는 작업이 다른 소스에서 데이터를 재현하는 것보다 더 오래 걸려 RTO를 준수할 수 없을 수도 있습니다. 그런 경우에는 장단점을 비교하여 데이터 복구가 필요할 때 다른 소스에서 데이터를 재현하는 방법에 대한 프로세스를 효과적으로 정의하여 수립해야 합니다. 예를 들면, Amazon S3의 데이터를 데이터 웨어하우스(예: Amazon Redshift) 또는 MapReduce 클러스터(예: Amazon EMR)로 로드한 경우 다른 소스에서 데이터를 재현할 수 있습니다. 이러한 분석 결과가 어딘가에 저장되어 있거나 재현될 수만 있다면 데이터 웨어하우스 또는 MapReduce 클러스터의 장애로 인해 데이터 손실이 발생하지 않습니다. 소스에서 복제할 수 있는 다른 예로는 캐시(예: Amazon ElastiCache) 또는 RDS 읽기 전용 복제본이 있습니다.
1. **데이터 백업 주기를 설정합니다**. 데이터 소스의 백업을 생성하는 일은 주기적으로 이루어져야 하며 빈도는 RPO에 따라 다릅니다.
**구현 계획의 작업 수준:** 보통
## 리소스
**관련 모범 사례:**
[REL13-BP01 가동 중단 시간 및 데이터 손실 시의 복구 목표 정의](rel_planning_for_recovery_objective_defined_recovery.md)
[REL13-BP02 복구 목표 달성을 위해 정의된 복구 전략 사용](rel_planning_for_recovery_disaster_recovery.md)
**관련 문서:**
+ [AWS Backup이란 무엇입니까?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [AWS DataSync란 무엇입니까?](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)
+ [Volume Gateway란 무엇입니까?](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html)
+ [APN 파트너: 백업을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: 백업에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Amazon EBS 스냅샷](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Amazon EFS 백업](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [Amazon FSx for Windows File Server 백업](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [ElastiCache for Redis의 백업 및 복원](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
+ [Neptune에서 DB 클러스터 스냅샷 생성](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html)
+ [DB 스냅샷 생성](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)
+ [일정에 따라 트리거되는 EventBridge 규칙 생성](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [리전 간 복제](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) (Amazon S3 사용)
+ [EFS-to-EFS AWS Backup](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/)
+ [Amazon S3로 로그 데이터 내보내기](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [객체 수명 주기 관리](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)
+ [DynamoDB에 대한 온디맨드 백업 및 복원](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html)
+ [DynamoDB의 특정 시점으로 복구](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html)
+ [Amazon OpenSearch Service 인덱스 스냅샷 작업](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html)
**관련 동영상:**
+ [AWS re:Invent 2021 - AWS를 사용한 백업, 재해 복구, 랜섬웨어 예방](https://www.youtube.com/watch?v=Ru4jxh9qazc)
+ [AWS Backup 데모: 계정 간 및 리전 간 백업](https://www.youtube.com/watch?v=dCy7ixko3tE)
+ [AWS re:Invent 2019: AWS Backup 심층 분석, ft. Rackspace 지원)(STG341)](https://youtu.be/av8DpL0uFjc)
**관련 예시:**
+ [Well-Architected 실습: Amazon S3에 대한 양방향 리전 간 복제(CRR) 구현](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
+ [Well-Architected lab: Testing Backup and Restore of Data(Well-Architected 실습: 데이터 백업 및 복원 테스트)](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
+ [Well-Architected 실습: 분석 워크로드에 대한 백업 및 장애 복구로 복원](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)
+ [Well-Architected 실습: 재해 복구 -백업 및 복원](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/)
# REL09-BP02 백업 보안 및 암호화
AWS IAM 등의 인증 및 권한 부여를 사용하여 백업에 대한 액세스를 제어하고 감지합니다. 백업의 데이터 무결성이 침해되었을 경우 암호화 기법을 사용하여 예방 및 감지합니다.
Amazon S3는 유휴 데이터 암호화를 위한 다양한 방법을 지원합니다. Amazon S3는 서버 측 암호화를 사용하여 객체를 암호화되지 않은 데이터로 수락한 다음 저장 시 암호화합니다. 클라이언트측 암호화를 사용하면 데이터가 Amazon S3로 전송되기 전에 워크로드 애플리케이션에서 데이터가 암호화됩니다. 어느 방법을 사용하든 AWS Key Management Service(AWS KMS)를 사용하여 데이터 키를 생성 및 저장하거나 사용자가 관리하는 자체 키를 제공할 수 있습니다. AWS KMS를 사용하면 IAM을 사용하여 데이터 키와 해독된 데이터에 접근할 수 있는 사용자와 접근할 수 없는 사용자에 대한 정책을 설정할 수 있습니다.
Amazon RDS의 경우 데이터베이스를 암호화하도록 선택하면 백업도 암호화됩니다. DynamoDB 백업은 항상 암호화됩니다.
**일반적인 안티 패턴:**
+ 백업과 복원 자동화에 대한 액세스 권한을 데이터에 대한 액세스 권한과 동일하게 설정
+ 백업을 암호화하지 않음
**이 모범 사례 수립의 이점:** 백업의 보안을 유지하면 데이터 변조가 방지되며, 데이터 암호화는 데이터가 실수로 노출될 경우 해당 데이터에 대한 액세스를 방지합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 각 데이터 스토어에 암호화를 사용합니다. 소스 데이터가 암호화되면 백업도 암호화됩니다.
+ RDS에서 암호화를 활성화합니다. RDS 인스턴스를 생성할 때 AWS Key Management Service를 사용하여 저장 데이터의 암호화를 구성할 수 있습니다.
+ [Amazon RDS 리소스 암호화](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ EBS 볼륨에 대해 암호화를 활성화합니다. 볼륨 생성 시 기본 암호화를 구성하거나 고유한 키를 지정할 수 있습니다.
+ [Amazon EBS 암호화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ 필수 Amazon DynamoDB 암호화를 사용합니다. DynamoDB는 모든 저장 데이터를 암호화합니다. 계정에 저장된 키를 지정하는 AWS에서 소유하는 AWS KMS 키 또는 AWS 관리형 KMS 키를 사용할 수 있습니다.
+ [저장 시 DynamoDB 암호화](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [암호화된 테이블 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ Amazon EFS에 저장된 데이터를 암호화합니다. 파일 시스템을 생성할 때 암호화를 구성합니다.
+ [Encrypting Data and Metadata in EFS(EFS의 데이터 및 메타데이터 암호화)](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ 원본 및 대상 리전에 암호화를 구성합니다. KMS에 저장된 키를 사용하여 Amazon S3에서 저장 데이터 암호화를 구성할 수 있지만 키는 리전별로 다릅니다. 복제를 구성할 때 대상 키를 지정할 수 있습니다.
+ [CRR Additional Configuration: Replicating Objects Created with Server-Side Encryption (SSE) Using Encryption Keys stored in AWS KMS(CRR 추가 구성: AWS KMS에 저장된 암호화 키를 사용하여 서버 측 암호화(SSE)로 생성된 객체 복제)](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ 백업에 액세스할 수 있는 최소 권한을 구현합니다. 보안 모범 사례에 따라 백업, 스냅샷 및 복제본에 대한 액세스를 제한합니다.
+ [보안 원칙: AWS Well-Architected](./wat.pillar.security.en.html)
## 리소스
**관련 문서:**
+ [AWS Marketplace: 백업에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Amazon EBS 암호화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ [Amazon S3: 암호화를 사용하여 데이터 보호](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html)
+ [CRR Additional Configuration: Replicating Objects Created with Server-Side Encryption (SSE) Using Encryption Keys stored in AWS KMS(CRR 추가 구성: AWS KMS에 저장된 암호화 키를 사용하여 서버 측 암호화(SSE)로 생성된 객체 복제)](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ [저장 시 DynamoDB 암호화](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Amazon RDS 리소스 암호화](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ [Encrypting Data and Metadata in EFS(EFS의 데이터 및 메타데이터 암호화)](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ [Encryption for Backups in AWS(AWS의 백업 암호화)](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)
+ [암호화된 테이블 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ [보안 원칙: AWS Well-Architected](./wat.pillar.security.en.html)
**관련 예시:**
+ [Well-Architected lab: Implementing Bi-Directional Cross-Region Replication (CRR) for Amazon S3(Well-Architected 실습: Amazon S3에 대한 양방향 크로스 리전 복제(CRR) 구현)](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
# REL09-BP03 자동으로 데이터 백업 수행
Recovery Point Objective(RPO)에 정의된 정기적인 일정 또는 데이터 세트의 변경에 따라 백업이 자동으로 생성되도록 구성합니다. 적은 데이터 손실을 요구하는 중요한 데이터 세트는 자주 자동으로 백업되어야 합니다. 반면 일부 손실은 용인하는 중요도가 상대적으로 낮은 데이터의 경우 더 낮은 빈도로 백업할 수 있습니다.
AWS Backup을 사용하여 다양한 AWS 데이터 소스의 자동화된 데이터 백업을 생성할 수 있습니다. Amazon RDS 인스턴스는 5분마다 거의 지속적으로 백업할 수 있으며 Amazon S3 객체는 15분마다 거의 지속적으로 백업될 수 있으므로 백업 기록에서 특정 시점으로 시점 복구(PITR)가 가능합니다. Amazon EBS 볼륨, Amazon DynamoDB 테이블 또는 Amazon FSx 파일 시스템과 같은 다른 AWS 데이터 소스의 경우 AWS Backup은 최대 빈도 1시간 간격으로 자동화된 백업을 실행할 수 있습니다. 이러한 서비스는 네이티브 백업 기능 또한 제공합니다. 특정 시점 복구가 가능한 자동화된 백업을 제공하는 AWS 서비스에는 [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html), [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html)및 [Amazon Keyspaces(Apache Cassandra용)](https://docs.aws.amazon.com/keyspaces/latest/devguide/PointInTimeRecovery.html) 가 있으며, 백업 기록에서 특정 시점으로 복구될 수 있습니다. 다른 AWS 데이터 스토리지 서비스는 대부분 최대 빈도 1시간 간격으로 주기적 백업 일정을 수립하는 기능을 제공합니다.
Amazon RDS 및 Amazon DynamoDB는 특정 시점 복구를 통해 지속적 백업을 지원합니다. Amazon S3 버전 관리는 한 번 활성화화면 자동으로 수행됩니다. [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) 를 사용하면 Amazon EBS 스냅샷의 생성, 복사, 삭제를 자동화할 수 있습니다. 또한 Amazon EBS 기반 Amazon Machine Image(AMI) 및 기본 Amazon EBS 스냅샷의 생성, 복사, 사용 중단 및 등록 취소도 자동화할 수 있습니다.
AWS Backup은 백업 자동화 및 기록을 중앙 집중식으로 볼 수 있는 완전관리형 정책 기반 백업 솔루션을 제공합니다. AWS Storage Gateway를 사용하여 클라우드뿐 아니라 온프레미스의 여러 AWS 서비스에 걸쳐 데이터 백업을 중앙 집중화하고 자동화합니다.
Amazon S3는 버전 관리에 더해 복제 기능도 제공합니다. 전체 S3 버킷을 같거나 다른 AWS 리전의 다른 버킷에 자동으로 복제할 수 있습니다.
**원하는 결과:**
정해진 주기로 데이터 소스의 백업을 생성하는 자동화된 프로세스
**일반적인 안티 패턴:**
+ 수동으로 백업 수행
+ 백업을 지원하는 리소스를 사용하지만 자동화 대상에 백업을 포함하지 않음
**이 모범 사례 수립의 이점:** 백업을 자동화하면 RPO를 기준으로 주기적으로 백업이 생성되며, 생성되지 않은 경우 알림을 보냅니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
1. **현재 수동으로 백업되는** 데이터 소스를 식별합니다. 이에 대한 가이드는 [REL09-BP01 백업해야 하는 모든 데이터 확인 및 백업 또는 소스에서 데이터 재현](rel_backing_up_data_identified_backups_data.md) 페이지를 참조합니다.
1. **워크로드의 RPO를** 결정합니다. 이에 대한 가이드는 [REL13-BP01 가동 중단 시간 및 데이터 손실 시의 복구 목표 정의](rel_planning_for_recovery_objective_defined_recovery.md) 페이지를 참조합니다.
1. **자동화된 백업 솔루션 또는 관리형 서비스를 사용합니다**. AWS Backup은 클라우드 및 온프레미스에서 [AWS 서비스 전체의 데이터 보호를 중앙 집중화하고 자동화할 수 있는 완전관리형 서비스입니다](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups). 백업 계획은 백업할 리소스와 백업이 생성되어야 하는 빈도를 정의하는 규칙을 생성할 수 있는 AWS Backup의 기능입니다. 이 빈도는 2단계에서 설정한 RPO를 기반으로 해야 합니다. [이 WA 실습에서는](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) AWS Backup을 사용하여 자동화된 백업을 생성하는 과정을 직접 체험해 보도록 가이드를 제공합니다. 데이터를 저장하는 AWS 서비스에서는 대부분 기본적으로 백업 기능을 제공합니다. 예를 들어, RDS를 사용하여 시점 복구(PITR) 기능이 있는 자동화된 백업을 생성할 수 있습니다.
1. **온프레미스 데이터 소스 또는 메시지 대기열과 같이** 자동화된 백업 솔루션 또는 관리형 서비스에서 지원되지 않는 데이터 소스의 경우 신뢰할 수 있는 서드 파티 솔루션을 사용하여 자동화된 백업을 생성하는 것을 고려하세요. 아니면 AWS CLI 또는 SDK를 사용하여 백업 생성을 위한 자동화를 생성할 수 있습니다. AWS Lambda 함수 또는 AWS Step Functions를 사용하여 데이터 백업 생성의 로직을 정의하고 Amazon EventBridge를 사용하여 RPO(2단계에서 설정함)를 기반으로 정해진 빈도에 실행합니다.
**구현 계획의 작업 수준:** 낮음
## 리소스
**관련 문서:**
+ [APN 파트너: 백업을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: 백업에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [일정에 따라 트리거되는 EventBridge 규칙 생성](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [AWS Backup이란 무엇입니까?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [AWS Step Functions란 무엇입니까?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
**관련 동영상:**
+ [AWS re:Invent 2019: AWS Backup 심층 분석, ft. Rackspace 지원)(STG341)](https://youtu.be/av8DpL0uFjc)
**관련 예시:**
+ [Well-Architected lab: Testing Backup and Restore of Data(Well-Architected 실습: 데이터 백업 및 복원 테스트)](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL09-BP04 백업 무결성 및 프로세스를 확인하기 위해 데이터의 주기적인 복구 수행
복구 테스트를 수행하여 백업 프로세스 구현이 RTO(복구 시간 목표) 및 RPO(복구 시점 목표)를 충족하는지 검증합니다.
AWS를 사용하면 테스트 환경을 구축하고 백업을 복원하여 RTO 및 RPO 기능을 평가하고 데이터 콘텐츠와 무결성에 대한 테스트를 실행할 수 있습니다.
또한 Amazon RDS와 Amazon DynamoDB는 PITR(특정 시점 복구)을 지원합니다. 연속 백업을 사용하면 데이터 세트를 지정된 날짜 및 시간의 상태로 복원할 수 있습니다.
**원하는 결과:** 효과적으로 정의된 메커니즘을 사용하여 백업의 데이터가 주기적으로 복구되어 워크로드에 정해진 Recovery Time Objective(RTO) 내에 복구가 가능하도록 합니다. 원본 데이터가 손상되거나 액세스가 불가능하지 않고 Recovery Point Objective(RPO)에서 허용되는 데이터 손실만 이루어진 채로 백업이 원본 데이터가 포함된 리소스로 복원되는지 확인합니다.
**일반적인 안티 패턴:**
+ 백업을 복원하지만 복원이 사용 가능한 상태인지 확인하기 위해 데이터를 쿼리하거나 검색하지 않음
+ 백업이 존재한다고 가정함
+ 시스템의 백업이 완전히 작동하며 시스템에서 데이터를 복구할 수 있다고 가정함
+ 복원 시점 또는 백업에서의 데이터 복구가 워크로드의 RTO 이내에 이루어진다고 가정함
+ 백업에 포함된 데이터가 워크로드의 RPO에 부합한다고 가정함
+ 런북을 사용하지 않거나 정해진 자동화된 절차를 벗어나 필요에 따라 복원함
**이 모범 사례 수립의 이점:** 백업의 복구를 테스트하면 데이터가 손실되거나 손상되는 것을 걱정하지 않고 필요할 때 데이터를 복원할 수 있으며, 복원 및 복구가 워크로드의 RTO 내에 이루어지도록 하며, 데이터 손실이 있는 경우 워크로드의 RPO에 부합하도록 할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
백업 및 복원 기능을 테스트하면 중단 시 백업 및 복원 수행의 역량에 대한 신뢰도를 높일 수 있습니다. 주기적으로 백업을 새로운 위치에 복원하고 테스트를 실행하여 데이터의 무결성을 확인합니다. 수행해야 하는 일반적인 테스트로는
모든 데이터를 사용 가능한지, 데이터가 손상되지 않았는지, 모든 데이터에 액세스할 수 있는지, 데이터 손실이 있는 경우 워크로드의 RPO에 부합하는지 확인하는 작업이 있습니다. 이러한 테스트는 복구 메커니즘의 속도가 워크로드의 RTO에 부합할 만큼 빠른지 확인하는 데도 도움이 됩니다.
1. **데이터 소스 식별.** 현재 백업되는 데이터 소스를 식별하고 이 백업이 어디에 저장되는지 파악합니다. 구현 가이드는 [REL09-BP01 백업해야 하는 모든 데이터 확인 및 백업 또는 소스에서 데이터 재현](rel_backing_up_data_identified_backups_data.md) 항목을 참조하십시오.
1. **데이터 검증을 위한 기준 수립.** 각 데이터 소스의 데이터 검증을 위한 기준을 수립합니다. 데이터 유형마다 속성이 다르며 서로 다른 검증 메커니즘이 필요할 수 있습니다. 확신을 갖고 프로덕션에 사용하기 전에 이 데이터가 어떻게 검증될 수 있는지 고려하십시오. 데이터를 검증하는 일반적인 방법으로는 데이터 유형, 형식, 체크섬, 크기 등의 데이터 및 백업 속성을 사용하고 이러한 속성과 사용자 지정 검증 로직을 결합하는 것입니다. 예를 들어, 복원된 리소스와 백업이 생성된 당시의 데이터 소스의 체크섬 값을 비교해 볼 수 있습니다.
1. **RTO 및 RPO 설정.** 데이터 중요도에 따라 데이터 복구에 대한 RTO와 RPO를 설정합니다. 구현 가이드는 [REL13-BP01 가동 중단 시간 및 데이터 손실 시의 복구 목표 정의](rel_planning_for_recovery_objective_defined_recovery.md) 항목을 참조하십시오.
1. **복구 기능 평가**. 백업 및 복원 전략을 검토하여 RTO 및 RPO를 충족하는지 파악하고 필요에 따라 전략을 조정합니다. 그리고 [AWS Resilience Hub를 사용하면](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-policy.html)워크로드의 평가를 실행할 수 있습니다. 이 평가를 통해 애플리케이션 구성을 복원력 정책과 비교하고 RTO 및 RPO 목표가 충족될 수 있는지 보고합니다.
1. **테스트 복원 수행.** 데이터 복원을 위해 프로덕션에서 사용되는 현재 설정된 프로세스를 사용하여 테스트 복원을 수행합니다. 이 프로세스는 원본 데이터 소스가 백업되는 방법, 백업 자체의 형식 및 스토리지 위치 또는 다른 소스에서의 데이터 재현 여부에 따라 달라집니다. 예를 들어, [AWS Backup과 같은 관리형 서비스를 사용하는 경우 이 프로세스는 새로운 리소스에 백업을 복원하는 것처럼 단순합니다](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html). AWS Elastic Disaster Recovery를 사용하는 경우 [복구 드릴을 시작할 수 있습니다](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html).
1. **데이터 복구 검증.** 2단계에서 데이터 검증을 위해 설정한 기준에 따라 이전 단계에서 복원된 리소스로 데이터 복구를 검증합니다. 복원되고 복구된 데이터에 백업 시 가장 최신 레코드/항목이 포함되어 있습니까? 이 데이터가 워크로드의 RPO에 부합합니까?
1. **필요한 시간 측정.** 복원 및 복구에 필요한 시간을 측정하고 이 시간을 3단계에서 설정한 RTO와 비교합니다. 프로세스가 워크로드의 RTO에 부합합니까? 예를 들어, 복원 프로세스가 시작됐을 때의 타임스탬프와 복구 검증이 완료됐을 때의 타임스탬프를 비교하여 프로세스에 걸린 시간을 계산합니다. 모든 AWS API 호출에는 타임스탬프가 찍히며 [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)에서 확인할 수 있습니다. 이 정보가 복원 프로세스가 시작된 시간에 대한 세부 정보를 제공하지만 검증이 완료된 종료 타임스탬프는 검증 로직에서 기록되어야 합니다. 자동화된 프로세스를 사용하는 경우 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 등의 서비스를 사용하여 이 정보를 저장할 수 있습니다. 또한 많은 AWS 서비스에서 특정 작업이 발생한 시점의 타임스탬프가 기록된 정보가 표시되는 이벤트 기록을 제공합니다. AWS Backup 내에서 백업 및 복원 작업을 *작업(Job)*이라고 하며, 이 작업에는 메타데이터에 타임스탬프 정보가 포함되어 있어 복원 및 복구에 필요한 시간을 측정하는 데 사용할 수 있습니다.
1. **이해 관계자에게 알림.** 데이터 검증이 실패하거나 복원 및 복구에 필요한 시간이 워크로드에 정해진 RTO를 초과하는 경우 이해 관계자에게 알립니다. 이를 위한 자동화를 구현할 때 [예를 들면 이 실습에서](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)Amazon Simple Notification Service(Amazon SNS) 등의 서비스를 사용하여 이메일 또는 SMS로 이해 관계자에게 푸시 알림을 보낼 수 있습니다. [이 메시지를 Amazon Chime, Slack, Microsoft Teams와 같은 메시징 애플리케이션에 게시하거나](https://aws.amazon.com/premiumsupport/knowledge-center/sns-lambda-webhooks-chime-slack-teams/) 이 메시지를 사용하여 [AWS Systems Manager OpsCenter를 통해 OpsItems로 태스크를 생성할 수도 있습니다](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-creating-OpsItems.html).
1. **주기적으로 실행되도록 프로세스 자동화**. 예를 들어, AWS Lambda 또는 AWS Step Functions의 State Machine과 같은 서비스를 사용하면 복원 및 복구 프로세스를 자동화할 수 있으며, Amazon EventBridge를 사용하여 아래 아키텍처 다이어그램에서 보이는 것처럼 이 자동 워크플로를 주기적으로 트리거할 수 있습니다. 자세한 방법은 [Automate data recovery validation with AWS Backup(AWS Backup으로 데이터 복구 검증 자동화)](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/)을 참조하십시오. 또한 [이 Well-Architected 실습](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) 에서는 여기에 나온 단계 중 여러 개를 자동화하는 방법에 대한 실습을 제공합니다.
![\[자동화된 백업 및 복원 프로세스를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/automated-backup-restore-process.png)
**구현 계획의 작업 수준:** 검증 기준의 복잡성에 따라 보통에서 높음
## 리소스
**관련 문서:**
+ [Automate data recovery validation with AWS Backup(AWS Backup으로 데이터 복구 검증 자동화)](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/)
+ [APN 파트너: 백업을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: 백업에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Creating an EventBridge Rule That Triggers on a Schedule(일정에 따라 트리거되는 EventBridge 규칙 생성)](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [DynamoDB에 대한 온디맨드 백업 및 복원](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html)
+ [AWS Backup란 무엇입니까?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [AWS Step Functions란 무엇입니까?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [AWS Elastic Disaster Recovery란 무엇입니까?](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
**관련 예시:**
+ [Well-Architected lab: Testing Backup and Restore of Data(Well-Architected 실습: 데이터 백업 및 복원 테스트)](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL 10 장애 격리를 사용하여 워크로드를 보호하려면 어떻게 해야 합니까?
장애 격리 경계는 워크로드 내부 장애의 영향을 제한된 수의 구성 요소로 제한합니다. 경계 외부의 구성 요소는 장애가 발생하더라도 영향을 받지 않습니다. 다수의 장애 격리 경계를 사용하여 워크로드에 미치는 영향을 제한할 수 있습니다.
**Topics**
+ [REL10-BP01 워크로드를 여러 위치에 배포](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 다중 위치 배포에 적합한 위치 선택](rel_fault_isolation_select_location.md)
+ [REL10-BP03 단일 위치로 제약된 구성 요소의 복구 자동화](rel_fault_isolation_single_az_system.md)
+ [REL10-BP04 격벽 아키텍처를 사용하여 영향 범위 제한](rel_fault_isolation_use_bulkhead.md)
# REL10-BP01 워크로드를 여러 위치에 배포
워크로드 데이터와 리소스를 여러 가용 영역에 분산하거나 필요한 경우 AWS 리전 전체에 분산합니다. 필요에 따라 다양한 위치를 사용할 수 있습니다.
AWS의 서비스 설계 관련 기본 원칙 중 하나는 기본 물리적 인프라에서 단일 장애 지점이 없어야 한다는 것입니다. 이 원칙을 준수하려면 가용 영역 여러 개를 사용하며 단일 영역에서 장애가 발생해도 복원이 가능한 소프트웨어와 시스템을 구축해야 합니다. 마찬가지로, 시스템은 단일 컴퓨팅 노드, 단일 스토리지 볼륨 또는 단일 데이터베이스 인스턴스에서 장애가 발생하더라도 복원 가능하도록 구축됩니다. 중복 구성 요소를 사용하는 시스템을 구축할 때는 구성 요소가 독립적(AWS 리전의 경우 자율적)으로 작동해야 합니다. 중복 구성 요소를 사용한 이론적 가용성 계산에서 얻을 수 있는 이점은 이것이 사실인 경우에만 유효합니다.
**가용 영역(AZ)**
AWS 리전은 서로 독립적으로 설계된 여러 개의 가용 영역으로 구성됩니다. 화재, 홍수, 태풍 등의 자연 재해로 인한 상관 장애 시나리오를 방지하기 위해 각 가용 영역은 물리적으로 유의미하게 떨어져 있도록 분리됩니다. 또한 각 가용 영역에는 독립된 물리적 인프라(다목적 전원에 대한 전용 연결, 대기 백업 전원, 독립 기계 서비스, 가용 영역 내/외부의 독립 네트워크 연결)가 포함되어 있습니다. 이 설계는 이 시스템 중 하나에서 발생한 장애가 영향을 받은 하나의 가용 영역에만 국한되도록 합니다. 가용 영역은 지리적으로는 분리되지만 같은 지역에 배치되어 높은 처리량과 낮은 지연 시간의 네트워킹이 가능합니다. 동기식으로 데이터를 복제하는 등(예: 데이터베이스 간에) 전체 AWS 리전(여러 개의 물리적으로 독립적인 데이터 센터로 구성된 모든 가용 영역의 AWS 리전)을 워크로드의 하나의 논리적 배포 대상으로 취급할 수 있습니다. 그러면 액티브/액티브 또는 액티브/대기 구성에서 가용 영역을 사용할 수 있습니다.
가용 영역은 서로 독립되어 있으므로 워크로드가 여러 영역을 사용하도록 아키텍팅된 경우 워크로드 가용성이 높아집니다. 일부 AWS 서비스(Amazon EC2 인스턴스 데이터 영역 포함)는 해당 서비스가 위치한 가용 영역과 운명을 같이하는 엄격한 영역별 서비스로 배포됩니다. 그러나 다른 가용 영역에 있는 Amazon EC2 인스턴스는 영향을 받지 않고 계속해서 작동합니다. 마찬가지로, 한 가용 영역에서의 장애로 인해 Amazon Aurora 데이터베이스에 장애가 발생하면 영향을 받지 않은 가용 영역에 있는 읽기 전용 복제본 Aurora 인스턴스가 자동으로 기본으로 승격될 수 있습니다. 반면 Amazon DynamoDB 등의 리전별 AWS 서비스는 사용자가 가용 영역 배치를 구성할 필요 없이 해당 서비스에 설정된 가용성 설계 목표를 달성하기 위해 내부적으로 액티브/액티브 구성에서 여러 가용 영역을 사용합니다.
![\[3개의 가용 영역에 배포된 다중 계층 아키텍처를 보여주는 다이어그램. Amazon S3와 Amazon DynamoDB는 항상 자동으로 다중 AZ에 유지됩니다. 또한 ELB는 3개 영역 모두에 배포됩니다.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/multi-tier-architecture.png)
AWS 컨트롤 플레인에서는 대개 전체 리전(여러 가용 영역) 내의 리소스를 관리하는 기능이 제공되지만, Amazon EC2, Amazon EBS 등의 특정 컨트롤 플레인에는 단일 가용 영역으로 결과를 필터링하는 기능도 있습니다. 이처럼 결과가 필터링되면 요청은 지정된 가용 영역에서만 처리되므로 다른 가용 영역이 중단될 가능성이 낮아집니다. 이 AWS CLI 예시는 us-east-2c 가용 영역에서만 Amazon EC2 인스턴스 정보를 가져오는 것을 보여줍니다.
```
AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c
```
*AWS 로컬 영역*
AWS 로컬 영역은 서브넷 및 EC2 인스턴스와 같은 영역 단위 AWS 리소스에 대한 배치 위치로 선택될 수 있다는 점에서 해당 AWS 리전 내의 가용 영역과 유사하게 작동합니다. 이러한 로컬 영역은 연결된 AWS 리전이 아니라 현재 AWS 리전이 없는 대규모 인구, 산업 및 IT 센터에 가까운 곳에 위치한다는 점에서 특별합니다. 그럼에도 불구하고 로컬 영역의 로컬 워크로드와 AWS 리전에서 실행 중인 워크로드 간에는 고대역폭의 안전한 연결이 유지됩니다. 지연 시간이 짧아야 하는 요구 사항을 충족하기 위해 사용자에게 더 가까운 위치에 워크로드를 배포하려면 AWS 로컬 영역을 사용해야 합니다.
**Amazon 글로벌 엣지 네트워크**
Amazon 글로벌 엣지 네트워크는 전 세계 도시의 엣지 로케이션으로 구성됩니다. Amazon CloudFront는 이 네트워크를 사용하여 최종 사용자에게 더 짧은 지연 시간으로 콘텐츠를 전송합니다. AWS Global Accelerator를 사용하면 이러한 엣지 로케이션에 워크로드 엔드포인트를 생성하여 사용자와 가까운 AWS 글로벌 네트워크로의 온보딩을 제공할 수 있습니다. Amazon API Gateway는 CloudFront 배포를 사용하여 엣지 최적화 API 엔드포인트를 활성화함으로써 가장 가까운 엣지 로케이션을 통한 클라이언트 접근을 가속화합니다.
*AWS 리전*
AWS 리전은 자율적으로 작동하도록 설계되므로 다중 리전 접근 방식을 사용하려면 각 리전에 서비스의 전용 복사본을 배포해야 합니다.
다중 리전 접근법은 일회성의 대규모 이벤트가 발생할 때 복구 목표를 달성하기 위한 *재해 복구* 전략에 자주 사용됩니다. 이러한 전략에 대한 자세한 내용은 [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) 을 참조하십시오. 그러나 여기에서는 시간 경과에 따라 평균 업타임 목표를 달성하는 *가용성*에 집중합니다. 목표가 고가용성인 경우 다중 리전 아키텍처가 일반적으로 액티브/액티브로 설계됩니다. 여기에서 각 서비스 복사본은 각각의 리전에서 액티브(요청을 서비스함)입니다.
**추천**
단일 AWS 리전 안에서 다중 AZ 전략을 사용하여 대부분의 워크로드에 대한 가용성 목표를 충족할 수 있습니다. 워크로드에 매우 높은 가용성 요구 사항이 있는 경우 또는 다중 리전 아키텍처를 요구하는 다른 비즈니스 목표가 있는 경우에만 다중 리전 아키텍처를 고려하십시오.
AWS는 교차 리전에서 서비스를 운영할 수 있는 기능을 제공합니다. 예를 들어, AWS는 Amazon Simple Storage Service(Amazon S3) 복제본, Amazon RDS 읽기 전용 복제본(Aurora 읽기 전용 복제본 포함), Amazon DynamoDB 글로벌 테이블을 사용하여 지속적인 비동기식 데이터 복제를 제공합니다. 지속적인 복제본을 통해 각 액티브 리전에서 거의 즉시 데이터의 버전을 사용할 수 있습니다.
AWS CloudFormation을 사용하면 인프라를 정의하고 AWS 계정 및 AWS 리전 전체에 일관적으로 배포할 수 있습니다. 또한 AWS CloudFormation StackSets는 한 번의 작업으로 여러 계정과 리전에 AWS CloudFormation 스택을 생성, 업데이트, 삭제할 수 있도록 이 기능을 확장합니다. Amazon EC2 인스턴스 배포의 경우 AMI(Amazon Machine Image)를 사용하여 하드웨어 구성 및 설치된 소프트웨어 같은 정보를 제공합니다. 필요한 AMI를 생성하고 이것을 액티브 리전에 복사하는 Amazon EC2 Image Builder 파이프라인을 구현할 수 있습니다. 그렇게 하면 이 *Golden AMI에* 새로운 각 리전에 워크로드를 배포하고 스케일 아웃하는 데 필요한 모든 것이 포함됩니다.
트래픽을 라우팅하기 위해 Amazon Route 53 및 AWS Global Accelerator에서 모두 어떤 사용자가 어떤 액티브 리전 엔드포인트로 이동하는지를 결정하는 정책을 정의할 수 있습니다. Global Accelerator를 사용하면 트래픽 다이얼을 설정하여 각 애플리케이션 엔드포인트로 이동하는 트래픽의 비율을 제어할 수 있습니다. Route 53는 이 비율 접근법과 함께 지리 근접 및 지연 시간 기반 접근법 등 여러 정책을 지원합니다. Global Accelerator는 AWS 엣지 서버의 광범위한 네트워크를 자동으로 활용하여 트래픽이 가능한 한 빨리 AWS 네트워크 백본을 사용하도록 온보딩함으로써 요청 지연 시간을 단축합니다.
이런 기능은 모두 각 리전의 자율성을 보존하도록 작동합니다. 이 방식의 예외는 Amazon CloudFront 및 Amazon Route 53와 같이 글로벌 엣지 제공 기능을 제공하는 서비스와 AWS Identity and Access Management(IAM) 서비스용 컨트롤 플레인 등의 몇 가지뿐입니다. 대부분의 서비스는 전적으로 단일 리전 내에서 작동합니다.
**온프레미스 데이터 센터**
온프레미스 데이터 센터에서 실행되는 워크로드의 경우 가능하면 하이브리드 환경을 설계합니다. AWS Direct Connect는 온프레미스에서 AWS로 연결되는 전용 네트워크 연결을 제공하므로 두 환경에서 모두 워크로드를 실행할 수 있습니다.
또 다른 옵션은 AWS Outposts를 사용하여 온프레미스에서 AWS 인프라 및 서비스를 실행하는 것입니다. AWS Outposts는 AWS 인프라, AWS 서비스, API 및 도구를 온프레미스 데이터 센터로 확장하는 완전관리형 서비스입니다. AWS 클라우드에서 사용되는 것과 동일한 하드웨어 인프라가 데이터 센터에 설치됩니다. AWS Outposts는 가장 가까운 AWS 리전에 연결됩니다. 그런 다음에는 AWS Outposts를 사용하여 지연 시간이 짧아야 하거나 로컬 데이터 처리 요구 사항이 있는 워크로드를 지원할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 다중 가용 영역 및 AWS 리전을 선택합니다. 워크로드 데이터와 리소스를 여러 가용 영역에 분산하거나 필요한 경우 AWS 리전 전체에 분산합니다. 필요에 따라 다양한 위치를 사용할 수 있습니다.
+ 리전별 서비스는 가용 영역 전체에 배포됩니다.
+ 여기에는 Amazon S3, Amazon DynamoDB, AWS Lambda(VPC에 연결되지 않은 경우)가 포함됩니다.
+ 컨테이너, 인스턴스 및 함수 기반 워크로드를 여러 가용 영역에 배포합니다. 캐시를 비롯한 다중 영역 데이터 스토어를 사용합니다. VPC에서 실행할 때 EC2 Auto Scaling, ECS 태스크 배치, AWS Lambda 함수 구성의 기능 및 ElastiCache 클러스터를 사용합니다.
+ Auto Scaling 그룹을 배포할 때는 서로 다른 가용 영역에 있는 서브넷을 사용합니다.
+ [예: 가용 영역 전반에 인스턴스 분산](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Amazon ECS 태스크 배치 전략](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Amazon VPC에서 리소스에 액세스하도록 AWS Lambda 함수 구성](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ [리전 및 가용 영역 선택](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ Auto Scaling 그룹을 배포할 때는 서로 다른 가용 영역에 있는 서브넷을 사용합니다.
+ [예: 가용 영역 전반에 인스턴스 분산](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ ECS 작업 배치 파라미터를 사용하여 DB 서브넷 그룹을 지정합니다.
+ [Amazon ECS 태스크 배치 전략](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ VPC에서 실행할 기능을 구성할 때 여러 가용 영역의 서브넷을 사용합니다.
+ [Amazon VPC에서 리소스에 액세스하도록 AWS Lambda 함수 구성](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ ElastiCache 클러스터를 통해 여러 가용 영역을 사용합니다.
+ [리전 및 가용 영역 선택](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ 워크로드를 여러 리전에 배포해야 하는 경우 다중 리전 전략을 선택합니다. 단일 AWS 리전 내에서 다중 가용 영역 전략을 사용하여 대부분의 신뢰성 요구 사항을 충족할 수 있습니다. 비즈니스 요구 사항을 충족하는 데 필요한 경우 다중 리전 전략을 사용합니다.
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications(다중 리전 액티브-액티브 애플리케이션을 위한 아키텍처 패턴)(ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ 다른 AWS 리전으로 백업하면 필요할 때 데이터를 사용할 수 있다는 보장이 추가됩니다.
+ 일부 워크로드의 경우 규제 요건에 따라 다중 리전 전략을 사용해야 합니다.
+ 워크로드의 AWS Outposts를 평가합니다. 온프레미스 데이터 센터에 대한 지연 시간이 짧아야 하거나 로컬 데이터 처리 요구 사항을 충족해야 하는 워크로드의 경우 AWS Outposts를 사용하여 온프레미스에서 AWS 인프라와 서비스를 실행합니다.
+ [AWS Outposts란 무엇입니까?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
+ AWS 로컬 영역이 사용자에게 서비스를 제공하는 데 도움이 되는지 확인합니다. 짧은 지연 시간에 대한 요구 사항이 있는 경우 AWS 로컬 영역이 사용자 근처에 있는지 확인합니다. 그렇다면 이를 사용하여 해당 사용자에게 더 가까운 위치에 워크로드를 배포합니다.
+ [AWS 로컬 영역 FAQ](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
## 리소스
**관련 문서:**
+ [AWS 글로벌 인프라](https://aws.amazon.com/about-aws/global-infrastructure)
+ [AWS 로컬 영역 FAQ](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Amazon ECS 태스크 배치 전략](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [리전 및 가용 영역 선택](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ [예: 가용 영역 전반에 인스턴스 분산](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [전역 테이블: DynamoDB를 사용한 다중 리전 복제](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Amazon Aurora 글로벌 데이터베이스 사용](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [Creating a Multi-Region Application with AWS Services(AWS 서비스로 다중 리전 애플리케이션 생성) 블로그 시리즈](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [AWS Outposts란 무엇입니까?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
**관련 동영상:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications(다중 리전 액티브-액티브 애플리케이션을 위한 아키텍처 패턴)(ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure(AWS 글로벌 네트워크 인프라 혁신 및 운영)(NET339)](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 다중 위치 배포에 적합한 위치 선택
## 원하는 결과
고가용성을 위해서는 그림 10에 나온 것과 같이 가능하면 언제나 워크로드 구성 요소를 여러 개의 가용 영역(AZ)에 배포하세요. 복원력에 대한 요구 사항이 매우 높은 워크로드의 경우 다중 리전 아키텍처에 대한 옵션을 신중하게 평가하세요.
![\[다른 AWS 리전에 백업되고 복원력이 있는 다중 AZ 데이터베이스 배포를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/multi-az-architecture.png)
## 일반적인 안티 패턴
+ 다중 AZ 아키텍처로 요구 사항을 충족할 수 있는데 다중 리전 아키텍처로 설계함
+ 복원력과 다중 위치 요구 사항이 구성 요소 간에 다를 경우 애플리케이션 구성 요소 간의 종속성을 고려하지 않음
## 이 모범 사례 수립의 이점
복원력을 위해서는 방어 계층을 구축하는 접근 방식을 사용해야 합니다. 하나의 계층은 다중 AZ를 사용하여 가용성이 높은 아키텍처를 구축함으로써 더 작고 더 일반적인 장애를 예방하고 또 다른 방어 계층은 만연한 자연 재해와 리전 수준의 장애와 같은 드문 이벤트를 예방하도록 설계합니다. 이 두 번째 계층에는 애플리케이션이 여러 AWS 리전에 분산되도록 하는 아키텍팅이 포함됩니다.
+ 99.5% 가용성과 99.99% 가용성의 차이는 월간 3.5시간이 넘습니다. 워크로드가 여러 가용 영역에 있는 경우 워크로드의 예상 가용성은 최대 99.99%에 그치게 됩니다.
+ 워크로드를 여러 가용 영역에서 실행하면 전력, 냉각기, 네트워킹에서의 장애와 화재나 홍수와 같은 대부분의 자연 재해로 인한 장애를 격리할 수 있습니다.
+ 워크로드에 다중 리전 전략을 구현하면 한 나라의 광범위한 지역에 영향을 미치는 만연한 자연 재해나 리전 전체에 발생한 기술적 장애로부터 워크로드를 보호할 수 있습니다. 다중 리전 아키텍처를 구현하는 일은 매우 복잡할 수 있으며 대개 대부분의 워크로드에는 필요하지 않다는 점을 참고하시기 바랍니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
가용 영역 한 곳의 중단이나 일부 소실에 따른 재해 이벤트의 경우 단일 AWS 리전 내 다중 가용 영역에 고가용성 워크로드를 구현하면 자연 재해와 기술 재해의 위험을 완화하는 데 도움이 됩니다. 각 AWS 리전은 여러 가용 영역으로 구성되며, 각 가용 영역은 상당히 멀리 떨어진 다른 영역에 발생한 장애의 영향을 받지 않습니다. 그러나 서로 상당히 멀리 떨어진 여러 가용 영역 구성 요소가 소실될 위험이 있는 재해 이벤트의 경우 리전 전체에 영향을 주는 장애를 완화하는 재해 복구 옵션을 구현해야 합니다. 매우 높은 복원력을 요구하는 워크로드(핵심 인프라, 건강 관련 애플리케이션, 금융 시스템 인프라 등)의 경우 다중 리전 전략이 필요할 수 있습니다.
## 구현 단계
1. 워크로드를 평가하고 복원력에 대한 요구 사항을 다중 가용 영역 접근법(단일 AWS 리전)으로 충족할 수 있는지, 아니면 다중 리전 접근법이 필요한지 결정합니다. 이런 요구 사항을 충족하기 위해 다중 리전 아키텍처를 구현하면 복잡성이 가중되므로 사용 사례와 요구 사항을 신중하게 고려해야 합니다. 복원력 요구 사항은 단일 AWS 리전을 사용하여 대부분 충족할 수 있습니다. 여러 리전을 사용해야 하는지 결정할 때는 다음과 같은 요구 사항을 고려하세요.
1. **재해 복구(DR)**: 가용 영역 한 곳의 중단이나 일부 소실에 따른 재해 이벤트의 경우 단일 AWS 리전 내 다중 가용 영역에 고가용성 워크로드를 구현하면 자연 재해와 기술 재해의 위험을 완화하는 데 도움이 됩니다. 서로 상당히 멀리 떨어진 여러 가용 영역 구성 요소가 소실될 위험이 있는 재해 이벤트의 경우, 자연 재해를 완화하거나 리전 전체에 영향을 주는 기술적 장애를 완화하는 여러 리전에 걸친 재해 복구를 구현해야 합니다.
1. **고가용성(HA)**: 다중 리전 아키텍처(각 리전에 여러 개의 가용 영역 사용)를 사용하여 99.99% 이상의 가용성을 달성할 수 있습니다.
1. **스택 현지화**: 전 세계 사용자를 대상으로 워크로드를 배포할 때는 다양한 AWS 리전에 현지화된 스택을 배포하여 해당 리전의 사용자에게 제공할 수 있습니다. 언어, 통화, 저장되는 데이터의 유형이 현지화의 대상이 될 수 있습니다.
1. **사용자에 대한 근접성:** 전 세계 사용자에게 워크로드를 배포할 때는 최종 사용자에게 가까운 AWS 리전에 스택을 배포하여 지연 시간을 단축할 수 있습니다.
1. **데이터 레지던시**: 일부 워크로드에는 특정 사용자의 데이터가 특정 국가의 국경 내에 남아 있어야 한다는 데이터 레지던시 요구 사항이 적용됩니다. 해당 규제에 따라 해당 국경 내의 AWS 리전에 전체 스택을 배포할지, 데이터만 배포할지 선택할 수 있습니다.
1. AWS 서비스에서 제공하는 다중 AZ 기능의 예는 다음과 같습니다.
1. EC2 또는 ECS를 사용하여 워크로드를 보호하기 위해 컴퓨팅 리소스 앞에 Elastic Load Balancer를 배포합니다. 그런 다음 Elastic Load Balancing가 비정상 영역의 인스턴스를 탐지하고 정상 영역으로 트래픽을 라우팅하는 솔루션을 제공합니다.
1. [Application Load Balancers 시작하기](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancer-getting-started.html)
1. [Network Load Balancer 시작하기](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-getting-started.html)
1. 로드 밸런싱을 지원하지 않는 상용 기성품 소프트웨어를 실행하는 EC2 인스턴스의 경우 다중 AZ 재해 복구 방법론을 구현하여 일종의 내결함성을 달성할 수 있습니다.
1. [REL13-BP02 복구 목표 달성을 위해 정의된 복구 전략 사용](rel_planning_for_recovery_disaster_recovery.md)
1. Amazon ECS 태스크의 경우 세 개의 가용 영역에 균등하게 서비스를 배포하여 가용성과 비용의 균형을 달성합니다.
1. [Amazon ECS 가용성 모범 사례 \$1 컨테이너](https://aws.amazon.com/blogs/containers/amazon-ecs-availability-best-practices/)
1. Aurora Amazon RDS가 아닌 경우 구성 옵션으로 다중 AZ를 선택할 수 있습니다. 기본 데이터베이스 인스턴스가 실패하면 Amazon RDS가 자동으로 대기 데이터베이스를 승격하여 다른 가용 영역의 트래픽을 수신하도록 합니다. 다중 리전 읽기 전용 복제본도 복원력을 향상하기 위해 생성할 수 있습니다.
1. [Amazon RDS 다중 AZ 배포](https://aws.amazon.com/rds/features/multi-az/)
1. [다른 AWS 리전에 읽기 전용 복제본 생성](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.XRgn.html)
1. AWS 서비스에서 제공하는 다중 리전 기능의 예는 다음과 같습니다.
1. 서비스에서 자동으로 다중 AZ 가용성이 제공되는 Amazon S3 워크로드의 경우 다중 리전 배포가 필요하다면 다중 리전 액세스 포인트를 고려하세요.
1. [Amazon S3에서의 다중 리전 액세스 포인트](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html)
1. 서비스에서 자동으로 다중 AZ 가용성이 제공되는 DynamoDB 테이블의 경우 기존 테이블을 글로벌 테이블로 쉽게 변환하여 다중 리전의 이점을 누릴 수 있습니다.
1. [단일 리전 Amazon DynamoDB 테이블을 글로벌 테이블로 변환](https://aws.amazon.com/blogs/aws/new-convert-your-single-region-amazon-dynamodb-tables-to-global-tables/)
1. 워크로드에 Application Load Balancers 또는 Network Load Balancer가 선행된다면 AWS Global Accelerator를 사용하여 정상 엔드포인트가 포함된 다중 리전으로 트래픽을 이동시킴으로써 애플리케이션의 가용성을 향상합니다.
1. [AWS Global Accelerator의 표준 액셀러레이터 엔드포인트 - AWS Global Accelerator(amazon.com)](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoints.html)
1. AWS EventBridge를 사용하는 애플리케이션의 경우 교차 리전 버스를 사용하여 이벤트를 선택한 다른 리전에 전달하는 방법을 고려해 보세요.
1. [AWS 리전 간에 Amazon EventBridge 이벤트 전송 및 수신](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
1. Amazon Aurora 데이터베이스의 경우 여러 AWS 리전에 걸친 Aurora 글로벌 데이터베이스를 고려하세요. 기존 클러스터를 수정하여 새로운 리전을 추가할 수도 있습니다.
1. [Amazon Aurora 글로벌 데이터베이스 시작하기](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-getting-started.html)
1. 워크로드에 AWS Key Management Service(AWS KMS) 암호화 키가 포함되어 있는 경우 다중 리전 키가 애플리케이션에 적합한지 고려하세요.
1. [AWS KMS의 다중 리전 키](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
1. 다른 AWS 서비스 기능의 경우 [AWS 서비스로 다중 리전 애플리케이션 생성에 대한 블로그 시리즈를 참고하세요.](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
**구현 계획의 작업 수준: **보통에서 높음
## 리소스
**관련 문서:**
+ [AWS 서비스로 다중 리전 애플리케이션 생성 시리즈](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [AWS의 재해 복구(DR) 아키텍처, 파트 IV: 다중 사이트 액티브/액티브](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)
+ [AWS 글로벌 인프라](https://aws.amazon.com/about-aws/global-infrastructure)
+ [AWS 로컬 영역 FAQ](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [AWS의 재해 복구(DR) 아키텍처, 파트 I: 클라우드에서의 복구 전략](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [클라우드마다 다른 재해 복구](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-is-different-in-the-cloud.html)
+ [전역 테이블: DynamoDB를 사용한 다중 리전 복제](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
**관련 동영상:**
+ [AWS re:Invent 2018: 다중 리전 액티브-액티브 애플리케이션을 위한 아키텍처 패턴(ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Auth0: 자동 장애 조치를 통해 매월 15억 건 이상의 로그인으로 확장할 수 있는 다중 리전 고가용성 아키텍처 사용](https://www.youtube.com/watch?v=vGywoYc_sA8)
**관련 예시:**
+ [AWS의 재해 복구(DR) 아키텍처, 파트 I: 클라우드에서의 복구 전략](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [DTCC, 온프레미스에서 수행할 수 있는 수준 이상의 복원력 달성](https://aws.amazon.com/solutions/case-studies/DTCC/)
+ [Expedia Group, 다중 리전 다중 가용 영역 아키텍처를 전용 DNS 서비스와 함께 사용하여 애플리케이션의 복원력 강화](https://aws.amazon.com/solutions/case-studies/expedia/)
+ [Uber: 다중 리전 Kafka용 재해 복구](https://eng.uber.com/kafka/)
+ [Netflix: 다중 리전 복원력을 위한 액티브/액티브 전략 사용](https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b)
+ [Atlassian 클라우드를 위한 데이터 레지던시를 구축하는 방법](https://www.atlassian.com/engineering/how-we-build-data-residency-for-atlassian-cloud)
+ [Intuit TurboTax, 두 개의 리전에서 실행](https://www.youtube.com/watch?v=286XyWx5xdQ)
# REL10-BP03 단일 위치로 제약된 구성 요소의 복구 자동화
워크로드의 구성 요소를 단일 가용 영역 또는 온프레미스 데이터 센터에서만 실행해야 하는 경우 정의된 복구 목표 내에서 워크로드를 완전히 재구축할 수 있는 기능을 구현해야 합니다.
기술적 제약으로 인해 워크로드를 여러 위치에 배포하는 모범 사례를 따를 수 없다면 복원력을 달성할 수 있는 대체 경로를 구현해야 합니다. 이러한 경우를 위해 필요한 인프라를 다시 생성하고, 애플리케이션을 다시 배포하고, 필요한 데이터를 다시 생성하는 기능을 자동화해야 합니다.
예를 들어 Amazon EMR은 지정된 클러스터의 모든 노드를 동일한 가용 영역에서 시작합니다. 동일한 영역에서 클러스터를 실행하면 데이터 접근 속도가 빨라져 작업 흐름의 성능이 개선되기 때문입니다. 워크로드 복원력에 이 구성 요소가 필요한 경우 클러스터와 해당 데이터를 다시 배포할 수 있어야 합니다. 또한 Amazon EMR의 경우 다중 AZ를 사용하는 것 이외의 방법으로 중복성을 프로비저닝해야 합니다. 다음을 프로비저닝할 수 있습니다. [다중 노드](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html). 그리고 [EMRFS(EMR 파일 시스템)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html)를 사용하면 EMR의 데이터를 Amazon S3에 저장한 다음 여러 가용 영역 또는 AWS 리전에 걸쳐 복제할 수 있습니다.
Amazon Redshift와 마찬가지로 클러스터는 기본적으로 사용자가 선택한 AWS 리전 내에서 임의로 선택된 가용 영역에 프로비저닝됩니다. 모든 클러스터 노드는 동일한 영역에 프로비저닝됩니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 자가 복구를 구현합니다. 가능한 경우 자동 크기 조정을 사용하여 인스턴스 또는 컨테이너를 배포합니다. 자동 크기 조정을 사용할 수 없는 경우 EC2 인스턴스에 대한 자동 복구를 사용하거나 Amazon EC2 또는 ECS 컨테이너 수명 주기 이벤트를 기반으로 자가 복구 자동화를 구현합니다.
+ 단일 인스턴스 IP 주소, 프라이빗 IP 주소, 탄력적 IP 주소 및 인스턴스 메타데이터가 필요하지 않은 인스턴스 및 컨테이너 워크로드에 Auto Scaling 그룹을 사용합니다.
+ [EC2 Auto Scaling이란 무엇일까요?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [서비스 자동 크기 조정](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ 시작 구성 사용자 데이터를 사용하여 대부분의 워크로드를 자가 복구할 수 있는 자동화를 구현할 수 있습니다.
+ 단일 인스턴스 ID 주소, 프라이빗 IP 주소, 탄력적 IP 주소 및 인스턴스 메타데이터가 필요한 워크로드에 EC2 인스턴스 자동 복구를 사용합니다.
+ [인스턴스 복구](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ 자동 복구는 인스턴스 장애가 감지될 때 SNS 주제로 복구 상태 알림을 전송합니다.
+ 자동 크기 조정 또는 EC2 복구를 사용할 수 없는 경우 EC2 인스턴스 수명 주기 이벤트 또는 ECS 이벤트를 사용하여 자가 복구를 자동화합니다.
+ [EC2 Auto Scaling 수명 주기 후크](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Amazon ECS 이벤트](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ 이벤트를 사용하여 필요한 프로세스 로직에 따라 구성 요소를 복구하는 자동화를 호출합니다.
## 리소스
**관련 문서:**
+ [Amazon ECS 이벤트](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [EC2 Auto Scaling 수명 주기 후크](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [인스턴스 복구](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [서비스 자동 크기 조정](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ [EC2 Auto Scaling이란 무엇일까요?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL10-BP04 격벽 아키텍처를 사용하여 영향 범위 제한
이 패턴은 선박의 격벽처럼 장애를 소수의 요청 또는 클라이언트 하위 집합으로 제한하여 손상된 요청 수를 제한하고 대부분의 요청은 오류 없이 계속될 수 있도록 합니다. 데이터에 대한 격벽은 종종 파티션으로 불리며 서비스에 대한 격벽은 셀이라고 합니다.
그리고 *셀 기반 아키텍처*에서 각 셀은 서비스의 완전한 독립 인스턴스이며 최대 크기가 고정되어 있습니다. 로드가 증가하면 셀을 추가하는 방법으로 워크로드 규모를 늘립니다. 파티션 키는 수신 트래픽에서 요청을 처리할 셀을 결정하는 데 사용됩니다. 모든 장애는 장애가 발생한 단일 셀로 제한되므로 다른 셀은 오류 없이 계속되고 손상된 요청의 수가 제한됩니다. 따라서 셀 간의 상호 작용을 최소화하고 각 요청에서 복잡한 매핑 서비스를 실행할 필요가 없도록 적절한 파티션 키를 식별하는 것이 중요합니다. 복잡한 매핑을 실행해야 하는 서비스에서는 문제가 매핑 서비스로 이전될 뿐이며, 셀 간 상호 작용을 수행해야 하는 서비스에서는 셀 간에 종속 관계가 형성되므로 상호 작용을 통해 개선 가능한 가용성의 수준도 낮아집니다.
![\[셀 기반 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/cell-based-architecture.png)
Colm MacCarthaigh의 AWS 블로그 게시물에 Amazon Route 53에서 [https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/) 개념을 사용하여 고객 요청을 샤드로 격리하는 방법이 설명되어 있습니다. 이 사례에서 샤드는 2개 이상의 셀로 구성됩니다. 고객(또는 리소스 또는 격리하려는 대상)의 트래픽은 파티션 키에 따라 할당된 샤드로 라우팅됩니다. 샤드당 2개씩 8개의 셀이 있고 샤드 4개에 고객이 나누어져 있는 경우 문제가 발생하면 25%의 고객이 영향을 받게 됩니다.
![\[전통 샤드로 나뉜 서비스를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/service-divided-into-traditional-shards.png)
셔플 샤딩을 사용하면 각각 두 개의 셀로 구성된 가상 샤드를 만들고 고객을 이러한 가상 샤드 중 하나에 할당합니다. 문제가 발생하면 전체 서비스의 1/4이 손실될 수 있지만 이 방식의 고객 또는 리소스 할당은 셔플 샤딩의 영향 범위가 25%보다 크게 낮아짐을 의미합니다. 8개의 셀에는 2개 셀로 구성된 28개의 고유한 조합이 있습니다. 즉, 28개의 셔플 샤드(가상 샤드)가 가능합니다. 고객이 수백 또는 수천 명이고 각 고객을 셔플 샤드에 할당하는 경우 문제의 영향 범위는 1/28에 불과합니다. 이는 일반 샤딩보다 7배 더 뛰어난 수치입니다.
![\[셔플 샤드로 나뉜 서비스를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/service-divided-into-shuffle-shards.png)
샤드는 셀 외에 서버, 대기열 또는 기타 리소스에도 사용될 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 격벽 아키텍처를 사용합니다. 이 패턴은 선박의 격벽처럼 장애를 소수의 요청 또는 사용자 하위 집합으로 제한하여 손상된 요청 수를 제한하고 대부분의 요청은 오류 없이 계속될 수 있도록 합니다. 데이터에 대한 격벽은 종종 파티션으로 불리며 서비스에 대한 격벽은 셀이라고 합니다.
+ [Well-Architected lab: Fault isolation with shuffle sharding(Well-Architected 실습: 셔플 샤딩으로 장애 격리)](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
+ [셔플 샤딩: AWS re:Invent 2019: Amazon Builders’ Library 소개(DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS re:Invent 2018: AWS가 장애의 영향 범위를 최소화하는 방법(ARC338)](https://youtu.be/swQbA4zub20)
+ 워크로드에 대한 셀 기반 아키텍처를 평가합니다. 셀 기반 아키텍처에서 각 셀은 서비스의 완전한 독립 인스턴스이며 최대 크기가 고정되어 있습니다. 로드가 증가하면 셀을 추가하는 방법으로 워크로드 규모를 늘립니다. 파티션 키는 수신 트래픽에서 요청을 처리할 셀을 결정하는 데 사용됩니다. 모든 장애는 장애가 발생한 단일 셀로 제한되므로 다른 셀은 오류 없이 계속되고 손상된 요청의 수가 제한됩니다. 따라서 셀 간의 상호 작용을 최소화하고 각 요청에서 복잡한 매핑 서비스를 실행할 필요가 없도록 적절한 파티션 키를 식별하는 것이 중요합니다. 복잡한 매핑을 실행해야 하는 서비스에서는 문제가 매핑 서비스로 이전될 뿐이며, 셀 간 상호 작용을 수행해야 하는 서비스에서는 개별 셀의 독립성 수준이 낮아지므로 셀의 자율성이 유지되는 경우 개선 가능한 가용성의 수준도 낮아집니다.
+ Colm MacCarthaigh의 AWS 블로그 게시물에 Amazon Route 53에서 셔플 샤딩 개념을 사용하여 고객 요청을 샤드로 격리하는 방법이 설명되어 있습니다.
+ [Shuffle Sharding: Massive and Magical Fault Isolation(셔플 샤딩: 마법 같은 대규모 장애 격리)](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
## 리소스
**관련 문서:**
+ [Shuffle Sharding: Massive and Magical Fault Isolation(셔플 샤딩: 마법 같은 대규모 장애 격리)](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
+ [Amazon Builders' Library: 셔플 샤딩을 사용한 워크로드 격리](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
**관련 동영상:**
+ [AWS re:Invent 2018: AWS가 장애의 영향 범위를 최소화하는 방법(ARC338)](https://youtu.be/swQbA4zub20)
+ [셔플 샤딩: AWS re:Invent 2019: Amazon Builders’ Library 소개(DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
**관련 예시:**
+ [Well-Architected lab: Fault isolation with shuffle sharding(Well-Architected 실습: 셔플 샤딩으로 장애 격리)](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
# REL 11 구성 요소 장애를 견디도록 워크로드를 설계하려면 어떻게 해야 합니까?
고가용성 및 낮은 MTTR(평균 복구 시간)이 요구되는 워크로드는 복원력을 고려하여 설계해야 합니다.
**Topics**
+ [REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 정상 리소스로 장애 조치](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 모든 계층에서 복구 자동화](rel_withstand_component_failures_auto_healing_system.md)
+ [REL11-BP04 복구 중 컨트롤 플레인이 아닌 데이터 영역 사용](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP05 정적 안정성을 사용하여 바이모달 동작 방지](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 이벤트가 가용성에 영향을 미치는 경우 알림 전송](rel_withstand_component_failures_notifications_sent_system.md)
# REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지
워크로드 상태를 지속적으로 모니터링하여 성능 저하 또는 장애가 발생하는 즉시 수동 및 자동화된 시스템을 통해 이를 인식할 수 있도록 합니다. 비즈니스 가치를 기반으로 KPI(핵심 성능 지표)를 모니터링합니다.
모든 복구 메커니즘은 문제를 신속하게 탐지하는 기능에서 시작되어야 합니다. 기술적 장애를 먼저 감지하여 해결합니다. 그러나 가용성은 비즈니스 가치를 제공하는 워크로드의 기능에 따라 결정되므로 이 요구 사항을 측정하는 핵심 성과 지표(KPI)를 탐지 및 수정 전략의 핵심 척도로 사용해야 합니다.
**일반적인 안티 패턴:**
+ 경보가 구성되지 않았기 때문에 알림 없이 중단이 발생합니다.
+ 경보가 존재하지만 대응 시간이 충분하지 않은 임계치에 있습니다.
+ 지표는 RTO(복구 시간 목표)를 충족하기에 충분한 지표가 수집되지 않는 경우가 많습니다.
+ 워크로드의 고객용 계층만 능동적으로 모니터링됩니다.
+ 기술 지표만 수집하며 비즈니스 기능 지표는 수집하지 않습니다.
+ 워크로드의 사용자 경험을 측정하는 지표가 없습니다.
**이 모범 사례 수립의 이점:** 모든 계층에서 적절한 모니터링을 사용하면 감지 시간을 단축하여 복구 시간을 줄일 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 복구 목표에 따라 구성 요소의 수집 간격을 결정합니다.
+ 모니터링 간격은 필요한 복구 속도에 따라 달라집니다. 복구 시간은 복구에 걸리는 시간에 따라 결정되므로 이 시간과 RTO(복구 시간 목표)를 고려하여 수집 빈도를 결정해야 합니다.
+ 구성 요소에 대한 세부 모니터링을 구성합니다.
+ EC2 인스턴스 및 Auto Scaling에 대한 세부 모니터링이 필요한지 결정합니다. 세부 모니터링은 1분 간격 지표를 제공하며 기본 모니터링은 5분 간격 지표를 제공합니다.
+ [인스턴스에 대한 세부 모니터링 활성화 또는 비활성화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Amazon CloudWatch를 사용하여 오토 스케일링 및 인스턴스 모니터링](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ RDS에 대한 향상된 모니터링이 필요한지 결정합니다. 향상된 모니터링은 RDS 인스턴스의 에이전트를 사용하여 RDS 인스턴스의 여러 프로세스 또는 스레드에 대한 유용한 정보를 가져옵니다.
+ [Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ 비즈니스 핵심 성과 지표(KPI)를 측정하는 사용자 지정 지표를 생성합니다. 워크로드는 주요 비즈니스 기능을 구현합니다. 이러한 기능은 간접 문제가 발생하는 시기를 식별하는 데 도움이 되는 KPI로 사용되어야 합니다.
+ [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ 사용자 canary를 사용하여 사용자 경험의 장애를 모니터링합니다. 가장 중요한 테스트 중 하나는 고객 행동을 실행하고 시뮬레이션할 수 있는 가상 트랜잭션 테스트(‘Canary 테스트’라고도 하지만 카나리 배포와는 다름)입니다. 다양한 원격 위치에서 워크로드 엔드포인트에 대해 이러한 테스트를 지속적으로 실행합니다.
+ [Amazon CloudWatch Synthetics로 사용자 Canary 생성 지원](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ 사용자 경험을 추적하는 사용자 지정 지표를 생성합니다. 고객의 경험을 계측할 수 있으면 소비자 경험이 저하되는 시기를 결정할 수 있습니다.
+ [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ 워크로드의 일부가 제대로 작동하지 않는 시기를 감지하고 리소스의 크기를 자동 조정해야 하는 시점을 알려주는 경보를 설정합니다. 경보를 사용하면 대시보드에 경보를 시각적으로 표시하고, Amazon SNS 또는 이메일을 통해 알림을 전송하며, Auto Scaling을 통해 워크로드의 리소스를 스케일 업 또는 다운할 수 있습니다.
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ 지표를 시각화하는 대시보드를 생성합니다. 대시보드를 사용하면 추세, 이상값 및 기타 잠재적 문제의 지표를 시각적으로 표시하거나, 조사가 필요할 수 있는 문제를 표시할 수 있습니다.
+ [CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
## 리소스
**관련 문서:**
+ [Amazon CloudWatch Synthetics로 사용자 Canary 생성 지원](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [인스턴스에 대한 세부 모니터링 활성화 또는 비활성화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Amazon CloudWatch를 사용하여 오토 스케일링 및 인스턴스 모니터링](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**관련 예시:**
+ [Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability(Well-Architected 실습: 레벨 300: 상태 확인 구현 및 종속성 관리를 통한 안정성 개선)](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP02 정상 리소스로 장애 조치
리소스 장애가 발생할 경우 정상 리소스가 계속해서 요청을 처리할 수 있는지 확인합니다. 위치 장애(예: 가용 영역 또는 AWS 리전)의 경우, 손상되지 않은 위치의 정상 리소스로 장애 조치할 수 있는 시스템을 갖추고 있어야 합니다.
Elastic Load Balancing, AWS Auto Scaling 등의 AWS 서비스는 리소스와 가용 영역에 걸쳐 로드를 분산하도록 도와줍니다. 따라서 남아 있는 상태가 양호한 리소스로 트래픽을 이동시켜 개별 리소스(예: EC2 인스턴스)의 장애 또는 가용 영역의 장애를 완화할 수 있습니다. 다중 리전 워크로드의 경우 이 작업이 더 복잡합니다. 예를 들어 리전 간 읽기 전용 복제본을 사용하여 데이터를 여러 AWS 리전에 배포할 수 있지만, 장애 조치가 발생할 경우 읽기 전용 복제본을 기본으로 승격하고 트래픽을 해당 위치로 지정해야 합니다. Amazon Route 53 및 AWS Global Accelerator는 AWS 리전 전체에 트래픽을 라우팅하도록 도와줍니다.
워크로드에서 Amazon S3 또는 Amazon DynamoDB와 같은 AWS 서비스를 사용하는 경우 이러한 서비스는 여러 가용 영역에 자동으로 배포됩니다. 장애가 발생하면 AWS 컨트롤 플레인이 자동으로 정상적인 위치로 트래픽을 라우팅합니다. 데이터가 여러 가용 영역에 중복으로 저장되고 가용성이 유지됩니다. Amazon RDS의 경우 구성 옵션으로 다중 AZ를 선택해야 합니다. 그러면 장애 시 AWS가 자동으로 트래픽을 정상 인스턴스로 보냅니다. Amazon EC2 인스턴스, Amazon ECS 태스크 또는 Amazon EKS 포드의 경우에는 배포할 가용 영역을 선택합니다. 그러면 Elastic Load Balancing이 비정상 영역에서 인스턴스를 감지하고 정상적인 영역으로 트래픽을 라우팅합니다. Elastic Load Balancing을 사용하는 경우 온프레미스 데이터 센터의 구성 요소로 트래픽을 라우팅할 수도 있습니다.
다중 리전 접근 방식(온프레미스 데이터 센터도 포함될 수 있음)의 경우 Amazon Route 53를 사용하여 인터넷 도메인을 정의하고, 트래픽이 정상적인 리전으로 라우팅되도록 상태 확인을 포함하는 라우팅 정책을 할당할 수 있습니다. 또는 AWS Global Accelerator가 제공하는 정적 IP 주소를 애플리케이션의 고정된 진입점으로 사용하고 인터넷 대신 AWS 글로벌 네트워크를 사용하여 선택한 AWS 리전의 엔드포인트로 라우팅하여 성능과 신뢰성을 개선할 수 있습니다.
AWS에서는 장애 복구를 고려한 서비스 설계 방식이 사용됩니다. 즉, 장애에서 복구하는 시간과 데이터에 대한 영향을 최소화하는 방식으로 서비스가 설계됩니다. AWS 서비스는 기본적으로 한 리전 내의 여러 복제본에 저장된 요청만 승인하는 데이터 스토어를 사용합니다. 이러한 서비스와 리소스에는 Amazon Aurora, Amazon Relational Database Service(Amazon RDS) Multi-AZ DB 인스턴스, Amazon S3, Amazon DynamoDB, Amazon Simple Queue Service(Amazon SQS), Amazon Elastic File System(Amazon EFS) 등이 있습니다. 이러한 서비스/리소스는 셀 기반 격리와 가용 영역에서 제공되는 장애 격리 기능을 사용하도록 구성됩니다. AWS의 운영 절차에서는 자동화가 광범위하게 사용됩니다. 또한 서비스 중단 시 빠르게 복구할 수 있도록 교체 및 다시 시작 기능도 최적화됩니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 정상 리소스로 장애 조치합니다. 리소스 장애가 발생할 경우 정상 리소스가 계속해서 요청을 처리할 수 있는지 확인합니다. 위치 장애(예: 가용 영역 또는 AWS 리전)의 경우, 손상되지 않은 위치의 정상 리소스로 장애 조치할 수 있는 시스템을 갖추고 있어야 합니다.
+ 워크로드에서 Amazon S3 또는 Amazon DynamoDB와 같은 AWS 서비스를 사용하는 경우 이러한 서비스는 여러 가용 영역에 자동으로 배포됩니다. 장애가 발생하면 AWS 컨트롤 플레인이 자동으로 정상적인 위치로 트래픽을 라우팅합니다.
+ Amazon RDS의 경우 구성 옵션으로 다중 AZ를 선택해야 합니다. 그러면 장애 시 AWS가 자동으로 트래픽을 정상 인스턴스로 보냅니다.
+ [Amazon RDS를 위한 고가용성(다중 AZ)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ Amazon EC2 인스턴스 또는 Amazon ECS 태스크의 경우에는 배포할 가용 영역을 선택합니다. 그러면 Elastic Load Balancing이 비정상 영역에서 인스턴스를 감지하고 정상적인 영역으로 트래픽을 라우팅합니다. Elastic Load Balancing을 사용하는 경우 온프레미스 데이터 센터의 구성 요소로 트래픽을 라우팅할 수도 있습니다.
+ 다중 리전 접근 방식(온프레미스 데이터 센터도 포함될 수 있음)의 경우 정상적인 위치의 데이터와 리소스가 계속해서 요청을 처리할 수 있는지 확인합니다.
+ 예를 들어 리전 간 읽기 전용 복제본을 사용하여 데이터를 여러 AWS 리전에 배포할 수 있지만, 기본 위치에 장애가 발생할 경우 읽기 전용 복제본을 마스터로 승격하고 트래픽을 해당 위치로 지정해야 합니다.
+ [Amazon RDS 읽기 전용 복제본 개요](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ Amazon Route 53를 사용하여 인터넷 도메인을 정의하고 트래픽이 정상적인 리전으로 라우팅되도록 상태를 확인하는 등 라우팅 정책을 할당할 수 있습니다. 또는 AWS Global Accelerator가 제공하는 정적 IP 주소를 애플리케이션의 고정된 진입점으로 사용하고 퍼블릭 인터넷 대신 AWS 글로벌 네트워크를 사용하여 선택한 AWS 리전의 엔드포인트로 라우팅하여 성능과 신뢰성을 개선할 수 있습니다.
+ [Amazon Route 53: 라우팅 정책 선택](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [AWS Global Accelerator란 무엇입니까?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
## 리소스
**관련 문서:**
+ [APN 파트너: 내결함성 자동화를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: 내결함성에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: Using Auto Healing to Replace Failed Instances(AWS OpsWorks: 자동 복구를 사용하여 실패한 인스턴스 대체)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Amazon Route 53: 라우팅 정책 선택](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Amazon RDS를 위한 고가용성(다중 AZ)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ [Amazon RDS 읽기 전용 복제본 개요](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ [Amazon ECS 태스크 배치 전략](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Creating Kubernetes Auto Scaling Groups for Multiple Availability Zones(여러 가용 영역에 Kubernetes Auto Scaling 그룹 생성)](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/)
+ [AWS Global Accelerator란 무엇입니까?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
**관련 예시:**
+ [Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability(Well-Architected 실습: 레벨 300: 상태 확인 구현 및 종속성 관리를 통한 안정성 개선)](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP03 모든 계층에서 복구 자동화
장애가 감지되면 자동화된 기능을 사용하여 수정 작업을 수행합니다.
*재시작 기능* 은 장애를 해결하는 데 사용할 수 있는 중요한 도구입니다. 분산 시스템에서 모범 사례는 앞서 설명한 것처럼 가능한 경우 서비스를 상태 비저장으로 만드는 것입니다. 이렇게 하면 재시작 시 데이터 손실 또는 가용성이 손실되는 것을 방지할 수 있습니다. 클라우드에서는 재시작의 일부로 전체 리소스(예: EC2 인스턴스 또는 Lambda 함수)를 대체할 수 있으며 이러한 대체는 일반적으로 필수적입니다. 재시작은 그 자체로 장애를 복구할 수 있는 단순하면서도 안정적인 방법입니다. 워크로드에는 다양한 유형의 장애가 발생합니다. 장애는 하드웨어, 소프트웨어, 통신 및 작업 과정에서 발생할 수 있습니다. 서로 다른 유형의 장애를 각각 격리, 식별 및 수정하는 새로운 메커니즘을 구성하는 대신 여러 범주의 장애를 동일한 복구 전략에 매핑하는 것이 좋습니다. 인스턴스는 하드웨어 결함, 운영 체제 버그, 메모리 누수 또는 기타 원인으로 인해 장애를 경험할 수 있습니다. 이러한 장애가 발생할 경우 각 상황에 맞춰진 수정 조치를 구축하는 대신 인스턴스 장애로 처리하십시오. 인스턴스를 종료하고 AWS Auto Scaling을 통해 인스턴스를 교체합니다. 나중에 환경 외부에서 장애 발생 리소스 분석을 수행할 수 있습니다.
또 다른 예는 네트워크 요청을 다시 시작하는 기능입니다. 네트워크 시간 제한 장애와 종속성 장애(종속성이 오류를 반환함)에 대해 같은 복구 방식이 적용됩니다. 두 이벤트는 모두 시스템에 비슷한 영향을 주므로, 한 이벤트를 “특수 사례”로 처리하는 대신 지수 백오프 및 지터를 통해 제한적으로 재시도하는 비슷한 전략이 적용됩니다.
*재시작 기능* 은 복구 중심 컴퓨팅 및 고가용성 클러스터 아키텍처에 포함된 복구 메커니즘입니다.
Amazon EventBridge를 사용하면 CloudWatch 경보 또는 다른 AWS 서비스의 상태 변경과 같은 이벤트를 모니터링하고 필터링할 수 있습니다. 그런 다음 이벤트 정보를 기반으로 AWS Lambda, AWS Systems Manager Automation 또는 다른 대상을 트리거하여 워크로드에 대한 맞춤형 수정 로직을 실행할 수 있습니다.
EC2 인스턴스 상태를 확인하도록 Amazon EC2 Auto Scaling을 구성할 수 있습니다. 인스턴스가 실행 중 이외의 상태이거나 시스템 상태가 손상된 경우 Amazon EC2 Auto Scaling은 해당 인스턴스를 비정상으로 간주하고 대체 인스턴스를 시작합니다. AWS OpsWorks를 사용하는 경우 OpsWorks 계층 수준에서 EC2 인스턴스의 자동 복구 기능을 구성할 수 있습니다.
대규모 교체(예: 전체 가용 영역이 손실됨)의 경우 한 번에 여러 개의 새 리소스를 확보하는 대신 정적 안정성을 통해 고가용성을 유지하는 것이 좋습니다.
**일반적인 안티 패턴:**
+ 인스턴스 또는 컨테이너에 개별적으로 애플리케이션 배포.
+ 자동 복구를 사용하지 않고 여러 위치에 배포할 수 없는 애플리케이션을 배포.
+ 자동 크기 조정 및 자동 복구로 복구하지 못한 애플리케이션을 수동으로 복구.
**이 모범 사례 수립의 이점:** 자동 복구는 워크로드를 한 번에 한 위치에만 배포할 수 있는 경우에도 평균 복구 시간을 단축하고 워크로드의 가용성을 보장합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ Auto Scaling 그룹을 사용하여 워크로드에 계층을 배포합니다. Auto Scaling은 무상태 애플리케이션에서 자가 복구를 수행하고 용량을 추가 및 제거할 수 있습니다.
+ [AWS Auto Scaling 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ 여러 위치에 배포할 수 없고 장애 발생 시 재부팅이 허용되는 애플리케이션이 배포되어 있는 EC2 인스턴스에 자동 복구를 구현합니다. 애플리케이션을 여러 위치에 배포할 수 없는 경우 자동 복구를 사용하여 장애가 발생한 하드웨어를 교체하고 인스턴스를 다시 시작할 수 있습니다. 인스턴스 메타데이터 및 관련 IP 주소는 물론 Amazon EBS 볼륨과 Elastic File System 및 Lustre/Windows용 파일 시스템의 탑재 지점도 유지됩니다.
+ [Amazon EC2 자동 복구](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store(Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System(Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Amazon FSx for Lustre란 무엇입니까?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [Amazon FSx for Windows File Server란 무엇입니까?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
+ AWS OpsWorks를 사용하는 경우 계층 수준에서 EC2 인스턴스의 자동 복구 기능을 구성할 수 있습니다.
+ [AWS OpsWorks: Using Auto Healing to Replace Failed Instances(AWS OpsWorks: 자동 복구를 사용하여 실패한 인스턴스 대체)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ 자동 크기 조정 또는 자동 복구를 사용할 수 없거나 자동 복구가 실패할 경우 AWS Step Functions 및 AWS Lambda를 사용하여 자동 복구를 구현합니다. 자동 크기 조정을 사용할 수 없고, 자동 복구를 사용할 수 없거나 자동 복구가 실패하는 경우 AWS Step Functions 및 AWS Lambda를 사용하여 복구를 자동화할 수 있습니다.
+ [AWS Step Functions란 무엇입니까?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [AWS Lambda란 무엇입니까?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ Amazon EventBridge를 사용하면 CloudWatch 경보 또는 다른 AWS 서비스의 상태 변경과 같은 이벤트를 모니터링하고 필터링할 수 있습니다. 그런 다음 이벤트 정보를 기반으로 AWS Lambda(또는 다른 대상)를 트리거하여 워크로드에 대한 사용자 지정 수정 로직을 실행할 수 있습니다.
+ [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## 리소스
**관련 문서:**
+ [APN 파트너: 내결함성 자동화를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: 내결함성에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: Using Auto Healing to Replace Failed Instances(AWS OpsWorks: 자동 복구를 사용하여 실패한 인스턴스 대체)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Amazon EC2 자동 복구](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store(Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System(Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [AWS Auto Scaling 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [AWS Lambda란 무엇입니까?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Step Functions란 무엇입니까?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Amazon FSx for Lustre란 무엇입니까?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [Amazon FSx for Windows File Server란 무엇입니까?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
**관련 동영상:**
+ [AWS의 정적 안정성: AWS re:Invent 2019: Introducing The Amazon Builders’ Library(Amazon Builders’ Library 소개)(DOP328)](https://youtu.be/sKRdemSirDM?t=704)
**관련 예시:**
+ [Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability(Well-Architected 실습: 레벨 300: 상태 확인 구현 및 종속성 관리를 통한 안정성 개선)](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP04 복구 중 컨트롤 플레인이 아닌 데이터 영역 사용
제어 영역은 리소스를 구성하는 데 사용되며, 데이터 영역은 서비스 제공에 사용됩니다. 일반적으로 데이터 영역은 제어 영역보다 가용성 설계 목표가 더 높으며, 일반적으로 덜 복잡합니다. 복원력에 영향을 미칠 가능성이 있는 이벤트에 대해 복구 또는 완화 대응을 구현할 때 제어 영역 작업을 사용하면 아키텍처의 전반적인 복원력이 감소될 수 있습니다. 예를 들어, Amazon Route 53 데이터 영역을 사용하면 상태 확인을 기반으로 DNS 쿼리를 안정적으로 라우팅할 수 있지만, Route 53 라우팅 정책을 업데이트할 때 컨트롤 플레인을 사용하므로 복구에 사용할 수 없습니다.
Route 53 데이터 영역은 DNS 쿼리에 응답하고 상태 확인을 수행 및 평가합니다. Route 53 데이터 영역은 전역에 배포되며 [100% 가용성 서비스 수준에 관한 계약(SLA)을 위해 설계됩니다.](https://aws.amazon.com/route53/sla/) Route 53 리소스를 생성, 업데이트, 삭제하는 데 사용하는 Route 53 관리 API 및 콘솔은 DNS를 관리할 때 필요한 강력한 일관성과 내구성을 우선시하도록 설계된 컨트롤 플레인에서 실행됩니다. 이를 위해 컨트롤 플레인은 하나의 리전(US East (N. Virginia))에 위치합니다. 두 시스템 모두 안정성이 높게 구축되었지만 컨트롤 플레인은 SLA에 포함되지 않습니다. 데이터 영역의 복원력 높은 설계가 컨트롤 플레인과 달리 가용성을 유지하는 상황이 드물게 있을 수 있습니다. 재해 복구 및 장애 조치 메커니즘에는 데이터 영역 기능을 사용하여 가능한 한 최고 수준의 신뢰성을 제공하십시오.
데이터 영역, 컨트롤 플레인, 고가용성 목표를 충족하기 위해 AWS에서 서비스를 구축하는 방법에 관한 자세한 내용은 [가용 영역을 사용한 정적 안정성](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) 문서와 [Amazon Builders' Library를 참조하십시오.](https://aws.amazon.com/builders-library/)
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 재해 복구에 Amazon Route 53를 사용할 때 컨트롤 플레인이 아닌 데이터 영역을 사용합니다. Route 53 Application Recovery Controller를 사용하면 준비 상태 확인 및 라우팅 제어를 통해 장애 조치를 관리하고 조정할 수 있습니다. 이러한 기능은 애플리케이션의 장애 복구 성능을 지속적으로 모니터링하며, 이를 통해 여러 AWS 리전, 가용 영역 및 온프레미스에서 애플리케이션 복구를 제어할 수 있습니다.
+ [What is Route 53 Application Recovery Controller?(Amazon Route 53 Application Recovery Controller란 무엇입니까?)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Creating Disaster Recovery Mechanisms Using Amazon Route 53(Amazon Route 53를 사용하여 재해 복구 메커니즘 생성)](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [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/)
+ [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 2: Multi-Region stack(Amazon Route 53 Application Recovery Controller를 사용하여 복원력이 높은 애플리케이션 구축, 파트 2: 다중 리전 스택)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ 데이터 영역을 사용할 작업과 컨트롤 플레인을 사용할 작업을 파악합니다.
+ [Amazon Builders' Library: Avoiding overload in distributed systems by putting the smaller service in control(소규모 서비스 제어를 통한 분산 시스템 오버로드 방지)](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [Amazon DynamoDB API(컨트롤 플레인 및 데이터 영역)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [AWS Lambda 실행](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (컨트롤 플레인 및 데이터 영역으로 분할)
+ [AWS Lambda 실행](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (컨트롤 플레인 및 데이터 영역으로 분할)
## 리소스
**관련 문서:**
+ [APN 파트너: 내결함성 자동화를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: 내결함성에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [Amazon Builders' Library: Avoiding overload in distributed systems by putting the smaller service in control(소규모 서비스 제어를 통한 분산 시스템 오버로드 방지)](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [Amazon DynamoDB API(컨트롤 플레인 및 데이터 영역)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [AWS Lambda 실행](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (컨트롤 플레인 및 데이터 영역으로 분할)
+ [AWS Elemental MediaStore Data Plane(AWS Elemental MediaStore 데이터 영역)](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [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/)
+ [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 2: Multi-Region stack(Amazon Route 53 Application Recovery Controller를 사용하여 복원력이 높은 애플리케이션 구축, 파트 2: 다중 리전 스택)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [Creating Disaster Recovery Mechanisms Using Amazon Route 53(Amazon Route 53를 사용하여 재해 복구 메커니즘 생성)](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [What is Route 53 Application Recovery Controller?(Amazon Route 53 Application Recovery Controller란 무엇입니까?)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
**관련 예시:**
+ [Amazon Route 53 Application Recovery Controller 소개](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
# REL11-BP05 정적 안정성을 사용하여 바이모달 동작 방지
바이모달 동작은 워크로드가 정상 모드와 장애 모드에서 다른 동작을 보이는 것을 말합니다. 예를 들어 가용 영역에 장애가 발생할 경우 새 인스턴스를 시작하는 방법을 사용할 수 있습니다. 그러나 이 방법 대신 정적으로 안정적이며 한 모드에서만 작동하는 워크로드를 구축해야 합니다. 한 AZ가 제거된 경우 제거된 영역의 워크로드 로드를 처리하기에 충분한 인스턴스를 각 가용 영역에 프로비저닝한 다음 Elastic Load Balancing 또는 Amazon Route 53 상태 확인을 사용하여 손상된 인스턴스에서 로드를 이동합니다.
컴퓨팅 배포(예: EC2 인스턴스 또는 컨테이너)에서 정적 안정성은 최고의 안정성을 제공합니다. 정적 안정성은 비용 문제와 비교하여 검토되어야 합니다. 컴퓨팅 파워를 적게 프로비저닝하고 장애 발생 시 새 인스턴스를 시작하는 방법이 비용은 더 저렴합니다. 그러나 대규모 장애(예: 가용 영역 장애)의 경우 이 접근 방식은 장애가 발생하기 전에 대비하는 것이 아니라 장애가 발생할 때 대응하는 방법에 의존하기 때문에 효율성이 떨어집니다. 따라서 워크로드의 안정성 요구 사항과 비용 요구 사항을 비교해야 합니다. 사용하는 가용 영역이 많을수록 정적 안정성을 유지하는 데 필요한 추가 컴퓨팅 용량은 줄어듭니다.
![\[가용 영역에 걸친 EC2 인스턴스의 정적 안정성을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/static-stability.png)
트래픽이 전환된 후에는 AWS Auto Scaling을 사용하여 장애가 발생한 영역의 인스턴스를 비동기식으로 교체하고 정상 영역에서 인스턴스를 시작합니다.
바이모달 동작의 또 다른 예는 시스템이 전체 시스템의 구성 상태를 새로 고치려고 시도할 수 있는 네트워크 시간 제한입니다. 그러면 다른 구성 요소에 예기치 않은 로드가 더해져 해당 구성 요소에 장애가 발생하고 또 다른 예기치 않은 결과가 야기될 수 있습니다. 이 부정적인 피드백 루프는 워크로드의 가용성에 영향을 미칩니다. 대신 정적으로 안정적이며 한 모드에서만 작동하는 시스템을 구축해야 합니다. 일정한 작업을 수행하고 항상 고정된 케이던스에서 구성 상태를 새로 고치는 것이 정적으로 안정된 설계의 하나일 수 있습니다. 호출이 실패하면 워크로드는 이전에 캐시된 값을 사용하고 경보를 트리거합니다.
바이모달 동작의 또 다른 예로 장애 발생 시 클라이언트에서 워크로드 캐시를 우회하는 것을 허용하는 동작이 있습니다. 이는 클라이언트 요구 사항을 수용한 솔루션처럼 보이지만 워크로드의 수요가 크게 변경되고 장애를 초래할 가능성이 높으므로 허용해서는 안 됩니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 정적 안정성을 사용하여 바이모달 동작을 방지합니다. 바이모달 동작은 워크로드가 정상 모드와 장애 모드에서 다른 동작을 보이는 것을 말합니다. 예를 들어 가용 영역에 장애가 발생할 경우 새 인스턴스를 시작하는 방법을 사용할 수 있습니다.
+ [Minimizing Dependencies in a Disaster Recovery Plan(재해 복구 계획의 종속성 최소화)](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Amazon Builders' Library: 가용 영역을 사용한 정적 안정성](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [AWS의 정적 안정성: AWS re:Invent 2019: Amazon Builders’ Library 소개(DOP328)](https://youtu.be/sKRdemSirDM?t=704)
+ 그러나 이 방법 대신 정적으로 안정적이고 한 모드에서만 작동하는 시스템을 구축해야 합니다. 한 가용 영역이 제거된 경우 제거된 영역의 워크로드 로드를 처리하기에 충분한 인스턴스를 각 영역에 프로비저닝한 다음 Elastic Load Balancing 또는 Amazon Route 53 상태 확인을 사용하여 손상된 인스턴스에서 로드를 이동합니다.
+ 바이모달 동작의 또 다른 예로 장애 발생 시 클라이언트에서 워크로드 캐시를 우회하는 것을 허용하는 동작이 있습니다. 이는 클라이언트 요구 사항을 수용하는 솔루션처럼 보이지만 워크로드의 수요가 크게 변경되고 장애를 초래할 가능성이 높으므로 허용해서는 안 됩니다.
## 리소스
**관련 문서:**
+ [Minimizing Dependencies in a Disaster Recovery Plan(재해 복구 계획의 종속성 최소화)](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Amazon Builders' Library: 가용 영역을 사용한 정적 안정성](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
**관련 동영상:**
+ [AWS의 정적 안정성: AWS re:Invent 2019: Amazon Builders’ Library 소개(DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 이벤트가 가용성에 영향을 미치는 경우 알림 전송
중대한 이벤트가 감지되면 이벤트로 인해 야기된 문제가 자동으로 해결된 경우에도 알림이 전송됩니다.
자동 복구를 사용하면 워크로드의 안정성을 유지할 수 있습니다. 그러나 자동 복구로 인해 해결해야 할 근본적인 문제가 가려질 수도 있습니다. 적절한 모니터링 및 이벤트를 구현하면 자동 복구로 해결된 문제를 포함한 문제의 패턴을 감지하여 근본 원인 문제를 해결할 수 있습니다. 장애 발생을 기준으로 Amazon CloudWatch Alarms를 트리거할 수 있으며 자동화된 복구 작업의 실행을 기준으로 트리거할 수도 있습니다. 이메일을 보내거나 Amazon SNS 통합을 사용하여 서드파티 인시던트 추적 시스템에 인시던트를 기록하도록 CloudWatch Alarms를 구성할 수 있습니다.
**일반적인 안티 패턴:**
+ 누구도 조치를 취하지 않는 경보 전송
+ 자동 복구 자동화를 수행하지만 복구가 필요한 것을 알리지 않음.
**이 모범 사례 수립의 이점:** 복구 이벤트에 대한 알림이 전송되면 자주 발생하는 문제가 무시되지 않습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 비즈니스 핵심 성과 지표(KPI)가 낮은 임계값을 초과할 때 이러한 지표에 대한 경보를 전송합니다. 비즈니스 KPI에 대해 낮은 임계값 경보를 설정하면 워크로드를 사용할 수 없거나 작동하지 않는 시기를 파악하는 데 도움이 됩니다.
+ [정적 임계값을 기반으로 CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ 복구 자동화를 호출하는 이벤트에 대한 경보 SNS API를 직접 호출하여 생성한 자동화를 통해 알림을 보낼 수 있습니다.
+ [Amazon Simple Notification Service란 무엇입니까?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
## 리소스
**관련 문서:**
+ [정적 임계값을 기반으로 CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon Simple Notification Service란 무엇입니까?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
# REL 12 안정성은 어떻게 테스트합니까?
프로덕션 환경의 스트레스에 대한 복원력을 가지도록 워크로드를 설계한 후 설계대로 작동하고 예상한 복원력을 제공하는지 확인할 수 있는 유일한 방법은 테스트입니다.
**Topics**
+ [REL12-BP01 플레이북을 사용하여 장애 조사](rel_testing_resiliency_playbook_resiliency.md)
+ [REL12-BP02 인시던트 사후 분석 수행](rel_testing_resiliency_rca_resiliency.md)
+ [REL12-BP03 기능 요구 사항 테스트](rel_testing_resiliency_test_functional.md)
+ [REL12-BP04 확장 및 성능 요구 사항 테스트](rel_testing_resiliency_test_non_functional.md)
+ [REL12-BP05 카오스 엔지니어링을 이용한 복원력 테스트](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP06 정기적으로 게임 데이 진행](rel_testing_resiliency_game_days_resiliency.md)
# REL12-BP01 플레이북을 사용하여 장애 조사
잘 알려지지 않은 장애 시나리오에 일관되고 신속하게 대응할 수 있도록 플레이북에 조사 프로세스를 문서화합니다. 플레이북은 장애 시나리오에 영향을 미치는 요인을 식별하기 위해 수행되는 미리 정의된 단계입니다. 문제가 확인되거나 에스컬레이션될 때까지 각 프로세스 단계의 결과를 사용하여 다음에 수행할 단계를 결정합니다.
플레이북은 사후 대응적 조치를 효과적으로 수행하기 위해 반드시 수행해야 하는 사전 예방적 계획입니다. 플레이북에 포함되지 않은 장애 시나리오가 프로덕션 환경에서 발생할 경우 이 문제를 먼저 해결합니다(화재 진압). 그런 다음 돌아가서 문제를 해결하기 위해 취한 단계를 살펴보고 이를 사용하여 플레이북에 새 항목을 추가합니다.
플레이북은 특정 인시던트에 대응하여 사용되며 런북은 특정 결과를 달성하기 위해 사용됩니다. 런북은 일상적인 활동에 대해 사용되고, 플레이북은 일상적이지 않은 이벤트에 대응하는 데 사용되는 경우가 많습니다.
**일반적인 안티 패턴:**
+ 문제를 진단하거나 인시던트에 대응하는 프로세스를 모른 상태에서 워크로드 배포를 계획합니다.
+ 이벤트를 조사할 때 로그 및 지표를 수집할 시스템에 대한 무계획적 결정
+ 데이터를 검색할 수 있을 만큼 오래 지표 및 이벤트를 유지하지 않음
**이 모범 사례 수립의 이점:** 플레이북을 캡처하면 프로세스를 일관되게 따를 수 있습니다. 플레이북을 코드화하면 수작업으로 인한 오류 발생을 최소화할 수 있습니다. 플레이북을 자동화하면 팀원의 개입 요구 사항을 없애거나 개입을 시작할 때 추가 정보를 제공함으로써 이벤트에 대응하는 시간을 단축할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 플레이북을 사용하여 문제를 파악합니다. 플레이북은 문제 조사를 위한 문서화된 프로세스입니다. 플레이북에 프로세스를 문서화하면 장애 발생 시나리오에 일관되고 빠르게 대응할 수 있습니다. 플레이북은 적절한 기술을 보유한 팀원이 해당하는 정보를 수집하고, 장애의 잠재적 출처를 확인하고, 결함 위치를 구분하고, 발생 요인을 확인(인시던트 사후 분석 수행)하는 데 필요한 정보와 지침을 포함해야 합니다.
+ 코드로 플레이북을 구현합니다. 플레이북을 스크립트로 작성하여 작업을 코드로 수행하면 일관성을 유지하고 수동 프로세스에서 발생하는 오류를 최소화할 수 있습니다. 플레이북은 문제의 발생 요인을 식별하는 데 필요할 수 있는 다양한 단계를 나타내는 여러 스크립트로 구성할 수 있습니다. 플레이북 활동의 일부분으로 런북 활동을 트리거하거나 수행할 수도 있고, 확인된 이벤트 대응 과정에서 플레이북 실행 여부를 묻는 메시지를 표시할 수도 있습니다.
+ [AWS Systems Manager를 사용하여 운영 플레이북 자동화](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Lambda란 무엇입니까?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## 리소스
**관련 문서:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [AWS Systems Manager를 사용하여 운영 플레이북 자동화](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Canary 사용(Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [AWS Lambda란 무엇입니까?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
**관련 예시:**
+ [플레이북 및 런북으로 운영 자동화](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL12-BP02 인시던트 사후 분석 수행
고객에게 영향을 주는 이벤트를 검토하고 발생 요인과 예방 조치 항목을 식별합니다. 이 정보를 사용하여 재발을 제한하거나 방지하는 완화 기능을 개발합니다. 신속하고 효과적인 대응을 위한 절차를 개발합니다. 목표 대상에 맞게 적절히 발생 요인과 수정 조치를 전달합니다. 필요한 경우 다른 관계자들에게 이러한 원인을 전달하는 방법을 마련합니다.
기존 테스트에서 문제가 발견되지 않은 이유를 평가합니다. 테스트가 아직 없는 경우 이 사례에 대한 테스트를 추가합니다.
**일반적인 안티 패턴:**
+ 발생 요인을 찾지만, 다른 잠재적 문제와 해결 방법을 계속 자세히 살펴보지는 않음
+ 인적 오류 원인만 식별하며, 인적 오류를 예방할 수 있는 교육이나 자동화는 제공하지 않음
**이 모범 사례 정립의 이점:** 인시던트 사후 분석을 수행하고 결과를 공유하면 다른 워크로드에서 동일한 발생 요인이 나타날 경우 위험을 완화할 수 있으며 인시던트가 발생하기 전에 해결하거나 자동 복구를 구현할 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 인시던트 사후 분석을 위한 표준을 수립합니다. 우수한 인시던트 사후 분석은 시스템의 다른 위치에서 사용되는 아키텍처 패턴이 있는 문제에 대해 공통 솔루션을 제안할 수 있는 기회를 제공합니다.
+ 발생 요인을 솔직하게 밝히면서도 책임을 따지지 않도록 합니다.
+ 문제를 문서화하지 않으면 문제를 시정할 수 없습니다.
+ 인시던트 사후 분석에서 책임을 따지지 않으면서 제안된 시정 조치를 공정하게 평가하도록 하고 애플리케이션 팀의 솔직한 자체 평가와 협업을 유도합니다.
+ 발생 요인을 확인하는 프로세스를 사용합니다. 재발을 제한하거나 방지하기 위한 완화책을 개발하고 빠르고 효과적인 대응을 위한 절차를 개발할 수 있도록 이벤트의 발생 요인을 식별하고 문서화하는 프로세스를 마련합니다. 목표 대상에 맞게 적절히 발생 요인을 알립니다.
+ [로그 분석이란 무엇일까요?](https://aws.amazon.com/log-analytics/)
## 리소스
**관련 문서:**
+ [로그 분석이란 무엇일까요?](https://aws.amazon.com/log-analytics/)
+ [오류 수정(COE)을 개발해야 하는 이유](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
# REL12-BP03 기능 요구 사항 테스트
단위 테스트와 필수 기능을 검증하는 통합 테스트 등의 기법을 사용합니다.
이러한 테스트는 구축 및 배포 작업의 일부로 자동으로 실행될 때 최상의 결과를 제공합니다. 예를 들어 개발자가 AWS CodePipeline을 사용하여 소스 리포지토리에 변경 사항을 커밋하면 CodePipeline이 변경 사항을 자동으로 감지합니다. 이러한 변경 사항이 구축되고 테스트가 실행됩니다. 테스트가 완료되면 테스트를 위해 구축된 코드가 스테이징 서버에 배포됩니다. CodePipeline은 스테이징 서버에서 통합 또는 로드 테스트와 같은 더 많은 테스트를 실행합니다. 이러한 테스트가 성공적으로 완료되면 CodePipeline은 테스트되고 승인된 코드를 프로덕션 인스턴스에 배포합니다.
또한 가장 중요한 테스트 중 하나는 고객 행동을 실행하고 시뮬레이션할 수 있는 가상 트랜잭션 테스트( *Canary 테스트라고도 하지만*카나리 배포와는 다름)입니다. 다양한 원격 위치에서 워크로드 엔드포인트에 대해 이러한 테스트를 지속적으로 실행합니다. Amazon CloudWatch Synthetics를 사용하면 엔드포인트 및 API 모니터링을 위한 [Canary를 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 기능 요구 사항을 테스트합니다. 여기에는 단위 테스트와 필수 기능을 검증하는 통합 테스트가 포함됩니다.
+ [CodePipeline를 AWS CodeBuild와 함께 사용하여 코드 테스트 및 빌드 실행](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild(AWS CodePipeline, AWS CodeBuild를 사용한 단위 및 맞춤형 통합 테스트 관련 지원 추가)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [Continuous Delivery and Continuous Integration(지속적 전달 및 지속적 통합)](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Canary 사용(Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [소프트웨어 테스트 자동화](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## 리소스
**관련 문서:**
+ [APN 파트너: 지속적 통합 파이프라인 구현을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Continuous+Integration)
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild(AWS CodePipeline, AWS CodeBuild를 사용한 단위 및 맞춤형 통합 테스트 관련 지원 추가)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [AWS Marketplace: 지속적인 통합에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Continuous+integration)
+ [Continuous Delivery and Continuous Integration(지속적 전달 및 지속적 통합)](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [소프트웨어 테스트 자동화](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [CodePipeline를 AWS CodeBuild와 함께 사용하여 코드 테스트 및 빌드 실행](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [Canary 사용(Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
# REL12-BP04 확장 및 성능 요구 사항 테스트
워크로드가 조정 및 성능 요구 사항을 충족하는지 확인하기 위한 로드 테스트 등의 기법을 사용합니다.
클라우드에서는 워크로드에 대한 프로덕션 규모의 테스트 환경을 필요할 때 생성할 수 있습니다. 축소된 인프라에서 이러한 테스트를 실행하는 경우 관찰된 결과를 프로덕션 환경에서 발생할 것으로 생각되는 범위까지 확장해야 합니다. 실제 사용자에게 영향을 주지 않도록 주의하고 실제 사용자 데이터 및 손상된 사용 통계 또는 프로덕션 보고서와 충돌하지 않도록 테스트 데이터에 태그를 지정하면 프로덕션에서도 로드 및 성능 테스트를 수행할 수 있습니다.
테스트를 통해 기본 리소스, 조정 설정, 서비스 할당량 및 복원력 설계가 로드 조건에서 예상대로 작동하는지 확인합니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 크기 조정 및 성능 요구 사항을 테스트합니다. 로드 테스트를 수행하여 워크로드가 크기 조정 및 성능 요구 사항을 충족하는지 확인합니다.
+ [AWS에서의 분산 로드 테스트: 수천 명의 연결된 사용자 시뮬레이션](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
+ 프로덕션 환경과 동일한 환경에 애플리케이션을 배포하고 로드 테스트를 수행합니다.
+ 코드형 인프라를 사용하여 프로덕션 환경과 최대한 유사한 환경을 구축합니다.
## 리소스
**관련 문서:**
+ [AWS에서의 분산 로드 테스트: 수천 명의 연결된 사용자 시뮬레이션](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
# REL12-BP05 카오스 엔지니어링을 이용한 복원력 테스트
시스템이 불리한 조건에서 어떻게 반응하는지 파악하려면 프로덕션 내 환경 또는 프로덕션과 최대한 가까운 환경에서 카오스 실험을 정기적으로 실행합니다.
** 원하는 결과: **
워크로드의 복원력은 이벤트 중 워크로드의 알려진 예상 동작을 확인하는 복원력 테스트 이외에 장애 주입 실험 또는 예기치 않은 부하 발생의 형태로 카오스 엔지니어링을 적용하여 정기적으로 확인합니다. 카오스 엔지니어링과 복원력 테스트를 결합하여 구성 요소 장애 시 워크로드가 중단되지 않고, 예기치 않은 중단이 발생한 경우에도 영향을 최소화하거나 아무런 영향 없이 복구할 수 있다는 확신을 얻을 수 있습니다.
** 일반적인 안티 패턴: **
+ 복원력을 뛰어나게 설계했으나 장애 발생 시 워크로드가 전체적으로 작동하는 방식을 확인하지 않습니다.
+ 실제 조건 및 예상되는 부하에서 절대 실험하지 않습니다.
+ 실험을 코드로 처리하지 않고 개발 주기 전체에서 유지 관리하지 않습니다.
+ 카오스 실험을 CI/CD 파이프라인의 일부로 또한 배포 범위 외부에서도 실행하지 않습니다.
+ 어떤 결함을 실험할지 결정할 때 과거의 인시던트 후 분석 사용에 소홀합니다.
** 이 모범 사례 확립의 이점:** 워크로드의 복원력을 확인하기 위해 장애를 도입하면 탄력적인 설계의 복구 절차가 실제 장애 발생 시에도 잘 작동할 것으로 확신할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 보통
## 구현 가이드
카오스 엔지니어링은 서비스 공급자, 인프라, 워크로드 및 구성 요소 수준에서 고객에게 미치는 영향을 최소화하거나 아무런 영향을 미치지 않으면서 제어되는 방식으로 실제 중단(시뮬레이션)을 지속적으로 도입할 수 있는 역량을 팀에 제공합니다. 이렇게 하면 팀이 장애로부터 배우고 워크로드의 복원력을 관찰, 측정 및 개선하고 이벤트 발생 시 알림이 전달되고 팀이 알림을 받는지 확인할 수 있습니다.
지속적으로 수행하면 카오스 엔지니어링은 해결하지 않고 두면 가용성과 운영에 부정적인 영향을 미칠 수 있는 결함을 강조해서 보여줄 수 있습니다.
**참고**
카오스 엔지니어링은 프로덕션 환경의 급변하는 조건을 견딜 수 있는 시스템의 역량을 확신하기 위해 시스템에 대해 수행하는 실험 분야입니다. [Principles of Chaos Engineering(카오스 엔지니어링의 원칙)](https://principlesofchaos.org/)
시스템이 중단을 견딜 수 있는 경우 카오스 엔지니어링은 자동화되어 회귀 테스트로 유지 관리해야 합니다. 이러한 방식으로 카오스 실험은 시스템 개발 수명 주기(SDLC) 및 CI/CD 파이프라인의 일부로 수행해야 합니다.
구성 요소 장애 발생 시 워크로드가 중단되지 않는지 확인하기 위해 실험의 일부로 실제 이벤트를 도입합니다. 예를 들어, Amazon EC2 인스턴스 손실 또는 기본 Amazon RDS 데이터베이스 인스턴스 장애 조치로 실험하고 워크로드가 영향을 받지 않는지(또는 최소한의 영향만 받는지) 확인합니다. 구성 요소 장애를 결합하여 가용 영역에서 중단으로 인해 발생할 수 있는 이벤트를 시뮬레이션합니다.
애플리케이션 수준 장애(예: 충돌)의 경우 메모리 및 CPU 소진 등과 같은 원인으로 시작할 수 있습니다.
간헐적 네트워크 중단으로 인한 외부 종속에 대한 [폴백 또는 장애 조치 메커니즘](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) 을 확인하려면 구성 요소가 몇 초에서 몇 시간까지 지속될 수 있는 지정된 기간에 서드파티 제공업체에 대한 액세스를 차단하여 해당 이벤트를 시뮬레이션해야 합니다.
그 외의 모드에서 성능이 저하되면 기능이 저하되고 응답 속도가 느려져서 서비스가 일시적으로 중단되는 경우가 많습니다. 이러한 성능 저하는 대개 중요 서비스의 지연 시간 증가 및 불안정한 네트워크 연결(패킷이 삭제됨)로 인해 발생합니다. 지연 시간, 삭제된 메시지 및 DNS 장애 등과 같은 네트워킹 효과를 비롯한 장애를 사용한 실험에는 이름 확인 불가, DNS 서비스에 연결 불가 또는 종속적 서비스에 연결 설정 불가가 포함될 수 있습니다.
**카오스 엔지니어링 도구:**
AWS Fault Injection Service(AWS FIS)은(는) CD 파이프라인의 일부로 또는 파이프라인 외부에서 사용할 수 있는 장애 주입 실험을 실행하는 데 사용되는 완전관리형 서비스입니다. AWS FIS은(는) 카오스 엔지니어링 게임 데이 중 사용하기 좋습니다. Amazon EC2, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service(Amazon EKS) 및 Amazon RDS을(를) 비롯한 여러 유형의 리소스 간에 동시 장애 발생을 지원합니다. 이러한 장애에는 리소스 종료, 강제 장애 조치, CPU 또는 메모리에 스트레스 유발, 제한, 지연 시간 및 패킷 손실이 포함됩니다. Amazon CloudWatch 경보와 통합되므로 테스트가 예상치 못한 영향을 미치는 경우 실험을 롤백하기 위해 중지 조건을 가드레일로 설정할 수 있습니다.
![\[워크로드에 장애 주입 실험을 실행할 수 있도록 AWS 리소스와 통합된 AWS Fault Injection Service을(를) 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/fault-injection-simulator.png)
장애 주입 실험을 위한 서드파티 옵션도 몇 가지 있습니다. 여기에는 오픈 소스 도구(예: [Chaos Toolkit](https://chaostoolkit.org/), [Chaos Mesh](https://chaos-mesh.org/)및 [Litmus Chaos](https://litmuschaos.io/))와 상용 옵션(예: Gremlin)이 포함됩니다. AWS에 삽입할 수 있는 장애 범위를 확장하기 위해 AWS FIS이(가) [Chaos Mesh 및 Litmus Chaos와 통합되어](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/)여러 도구 간에 장애 주입 워크플로를 조정할 수 있습니다. 예를 들어, 임의로 선택된 비율의 클러스터 노드를 AWS FIS 장애 작업을 사용하여 종료하는 동안 Chaos Mesh 또는 Litmus 결함을 사용하여 포드의 CPU에 대한 스트레스 테스트를 실행할 수 있습니다.
## 구현 단계
+ 실험에 사용할 장애를 결정합니다.
워크로드 설계의 복원력을 평가합니다. 해당 설계( [Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)의 모범 사례를 사용하여 생성됨)는 중요한 종속성, 과거 이벤트, 알려진 문제 및 규정 준수 요구 사항을 기반으로 위험을 설명합니다. 복원력을 유지하기 위한 설계 요소와 완화하도록 설계된 장애를 나열합니다. 이러한 목록 작성에 대한 자세한 내용은 이전 인시던트 재발을 방지하기 위한 프로세스 생성 방법을 안내하는 [운영 준비 검토 백서](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 를 참조하세요. 장애 모드 및 영향 분석(FMEA) 프로세스는 장애의 구성 요소 수준 및 장애가 워크로드에 미치는 영향을 분석하기 위한 프레임워크를 제공합니다. FMEA는 Adrian Cockcroft가 장애 모드 및 지속적인 복원력에서 [자세히 설명합니다](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5).
+ 각 장애에 우선순위를 할당합니다.
처음에는 높음, 보통 또는 낮음 등과 같이 대략적인 분류로 시작합니다. 우선순위를 평가하려면 장애 빈도와 장애가 전체 워크로드에 미치는 영향을 고려해야 합니다.
주어진 장애의 빈도를 고려할 때 확인 가능한 경우 이 워크로드에 대한 이전 데이터를 분석합니다. 확인할 수 없는 경우에는 유사한 환경에서 실행되는 다른 워크로드의 데이터를 사용합니다.
주어진 장애의 영향을 고려할 때 장애의 범위가 클수록 일반적으로 영향도 커집니다. 또한 워크로드 설계 및 용도도 고려합니다. 예를 들어, 소스 데이터 스토어에 액세스하는 기능은 데이터 변환 및 분석을 수행하는 워크로드에 중요합니다. 이러한 경우 액세스 장애와 제한된 액세스 및 지연 시간 삽입에 대한 실험의 우선순위를 지정할 수 있습니다.
인시던트 후 분석은 장애 모드의 빈도 및 영향을 파악하기 위한 좋은 데이터 출처입니다.
할당된 우선순위를 사용하여 어떤 장애를 먼저 실험할지, 새로운 장애 주입 실험을 개발할 순서를 결정합니다.
+ 수행하는 각 실험에 대해 카오스 애플리케이션 및 지속적인 복원력 플라이휠을 따릅니다.
![\[개선, 안정 상태, 가설, 실험 실행 및 확인 단계를 보여주는 카오스 엔지니어링 및 연속 복원력 플라이휠 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/chaos-engineering-flywheel.png)
+ 안정 상태를 정상 동작을 나타내는 워크로드의 측정 가능한 출력으로 정의합니다.
예상한 대로 안정적으로 작동하면 워크로드가 안정 상태를 보이는 것입니다. 따라서 안정 상태를 정의하기 전에 워크로드가 정상인지 확인합니다. 특정 비율의 장애는 허용 가능한 한도 내에서 발생할 수 있기 때문에 안정 상태라고 해서 장애 발생 시 워크로드에 미치는 영향이 반드시 없는 것은 아닙니다. 안정 상태는 실험 중 관찰하는 기준선으로, 다음 단계에서 정의하는 가설이 예상대로 나타나지 않는 경우 이상이 있음을 강조합니다.
예를 들어, 결제 시스템의 안정 상태를 성공률 99%, 왕복 시간 500ms의 300 TPS 처리로 정의할 수 있습니다.
+ 워크로드가 장애에 반응할 방법에 대한 가설을 작성합니다.
올바른 가설은 안정 상태 유지를 위해 장애 완화에 기대되는 작동 방식을 기반으로 합니다. 가설은 워크로드가 특정 완화를 수행하도록 설계되었기 때문에 특정 유형의 장애 발생 시 시스템 또는 워크로드가 계속해서 안정 상태를 유지할 것이라고 가정합니다. 특정 유형의 장애 및 완화가 가설에 명시되어 있어야 합니다.
가설에는 다음 템플릿을 사용할 수 있습니다(하지만 다르게 표현할 수도 있음).
**참고**
만약 *특정 장애* 가 발생하면 *워크로드 명칭* 워크로드가 *비즈니스 또는 기술 지표의 영향* 을 유지하기 위한 *완화 제어 조치를 설명합니다*.
예를 들면 다음과 같습니다.
+ Amazon EKS 노드 그룹 중 20%의 노드가 종료되면 트랜잭션 생성 API가 100ms에서 요청의 99%를 계속해서 제공합니다(안정 상태). Amazon EKS 노드는 5분 이내에 복구되고 포드는 실험 시작 후 8분 이내에 트래픽을 예약하고 처리합니다. 3분 이내에 알림이 전송됩니다.
+ 단일 Amazon EC2 인스턴스 장애가 발생하면 주문 시스템의Elastic Load Balancing 상태 확인 기능이 Elastic Load Balancing에 나머지 정상 인스턴스에만 요청을 보내도록 하고 동시에 Amazon EC2 Auto Scaling에서는 장애가 발생한 인스턴스를 교체하여 서버 측(5xx) 오류의 증가율을 0.01% 미만으로 유지합니다(안정 상태).
+ 1차 Amazon RDS 데이터베이스 인스턴스에서 장애가 발생하면 공급망 데이터 컬렉션 워크로드는 장애 조치를 취하고 대기Amazon RDS 데이터베이스 인스턴스에 연결하여 데이터베이스 읽기 또는 쓰기 오류를 1분 미만으로 유지합니다(안정 상태).
+ 장애를 도입하여 실험을 실행합니다.
실험은 기본적으로 장애 발생 시 안전해야 하며 워크로드에서 허용해야 합니다. 워크로드에서 장애가 발생할 것임을 아는 경우 실험을 실행하지 마세요. known-unknowns 또는 unknown-unknowns를 찾으려면 카오스 엔지니어링을 사용해야 합니다. *Known-unknowns* 는 알고 있지만 완전히 파악하지 못한 항목이며, *unknown-unknowns* 는 알지 못할 뿐만 아니라 완전히 파악하지 못한 항목입니다. 실패할 것을 알고 있는 워크로드에 대한 실험에서는 새로운 인사이트를 얻을 수 없습니다. 실험은 주의해서 계획해야 하고 영향 범위가 명확해야 하며 예기치 못한 변동 발생 시 적용할 수 있는 롤백 메커니즘을 제공해야 합니다. 실사에서 워크로드가 실험을 통과해야 한다고 나타나면 실험을 계속 진행합니다. 장애 주입을 위한 옵션은 여러 가지가 있습니다. AWS에서의 워크로드의 경우 [AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) 에서는 작업이라 부르는 미리 정의된 다양한 장애 시뮬레이션을 [해당 알림에 대한 작업이](https://docs.aws.amazon.com/fis/latest/userguide/actions.html). 또한 다음 문서를 사용하여 AWS FIS에서 실행하는 사용자 지정 작업을 정의할 수도 있습니다. [AWS Systems Manager 문서](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html).
스크립트에 워크로드의 현재 상태를 파악하는 기능이 없고, 스크립트가 로그를 내보낼 수 없고, 가능한 경우 롤백 메커니즘 및 중지 조건을 제공할 수 없는 경우에는 카오스 실험에 사용자 지정 스크립트를 사용하지 않는 것이 좋습니다.
카오스 엔지니어링을 지원하는 효율적인 프레임워크 또는 도구 세트는 실험의 현재 상태를 추적하고, 로그를 내보내고, 실험의 제어되는 실행을 지원하기 위한 롤백 메커니즘을 제공해야 합니다. 실험 시 예기치 못한 변동이 발생하는 경우 실험을 롤백하는 안전 메커니즘과 분명하게 정의된 범위가 있는 실험을 수행하도록 허용하는 AWS FIS 등과 같은 확립된 서비스로 시작합니다. AWS FIS을(를) 사용한 다양한 실험에 대해 알아보려면 [Resilient and Well-Architected Apps with Chaos Engineering lab(카오스 엔지니어링을 사용해 잘 설계된 복원력이 뛰어난 앱 실습)을 참조하세요](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US). 또한 [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) 은(는) 워크로드를 분석하여 AWS FIS에서 구현 및 실행하도록 선택할 수 있는 실험을 생성합니다.
**참고**
모든 실험에 대해 범위와 그 영향을 명확하게 이해해야 합니다. 프로덕션 환경에서 실행하기 전에 비프로덕션 환경에서 먼저 장애를 시뮬레이션하는 것이 좋습니다.
실험은 가능한 경우 제어 및 실험적 시스템 배포를 둘 다 실행하는 [카나리 배포](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) 를 사용하여 실제 로드를 받는 프로덕션 환경에서 실행해야 합니다. 프로덕션 환경에서 처음으로 실험하는 경우 잠재적인 영향을 완화하기 위해 사용량이 적은 시간에 실험을 실행하는 것이 좋습니다. 또한 실제 고객 트래픽 사용의 위험이 너무 큰 경우에는 프로덕션 인프라에서 제어 및 실험적 배포에 대해 가상 트래픽을 사용하여 실험을 실행할 수 있습니다. 프로덕션 환경을 사용할 수 없는 경우 가급적 프로덕션 환경과 유사한 프로덕션 전 환경에서 실험을 실행합니다.
실험이 허용 가능한 제한을 벗어나 프로덕션 트래픽 또는 다른 시스템에 영향을 미치지 않도록 가드레일을 설정하고 모니터링해야 합니다. 가드레일 지표에 대해 정의한 임곗값에 도달한 경우 실험을 중지하기 위한 중지 조건을 설정합니다. 중지 조건에는 워크로드의 안정 상태에 대한 지표와 장애를 도입하는 구성 요소에 대한 지표를 포함해야 합니다. 또한 [종합 모니터링](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (사용자 canary라고도 함)은 일반적으로 사용자 프록시로 포함해야 하는 한 가지 지표입니다. [AWS FIS에 대한 중지 조건](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html) 은 실험 템플릿의 일부로 지원되며 템플릿당 최대 5개의 중지 조건을 사용할 수 있습니다.
카오스 원칙 중 한 가지는 실험 범위 및 그 영향을 최소화하는 것입니다.
단기적인 부정적 영향 중 일부를 허용해야 하지만 실험의 여파를 최소화하고 제한하는 것은 카오스 엔지니어의 책임이자 의무입니다.
실험 범위 및 잠재적인 영향을 확인하기 위한 방법은 먼저 비프로덕션 환경에서 실험을 수행하여 실험 중 중지 조건의 임곗값이 예상대로 활성화되고 프로덕션 환경에서 직접 실험하지 않고 관찰을 통해 예외를 포착할 수 있는지 확인하는 것입니다.
장애 주입 실험을 실행할 때 책임 당사자 모두가 알림을 잘 받았는지 확인합니다. 운영 팀, 서비스 신뢰성 팀, 고객 지원 팀 등과 같은 적절한 팀과 소통하여 실험 실행 시점과 기대하는 결과에 대해 알립니다. 이러한 팀에 통신 도구를 제공하여 부정적인 영향을 확인한 경우 실험을 실행하는 팀에 알릴 수 있도록 합니다.
워크로드와 기본 시스템을 원래 정상 상태로 복원해야 합니다. 보통, 워크로드의 탄력적인 설계는 스스로 복구됩니다. 하지만 일부 장애 설계 또는 장애가 발생한 실험에서는 워크로드를 예기치 않은 장애 상태로 둘 수 있습니다. 따라서 실험을 마치면 이 점을 인식하고 워크로드 및 시스템을 복원해야 합니다. AWS FIS를 사용하면 작업 파라미터 내에서 롤백 구성을 설정할 수 있습니다(후속 작업이라고도 함). 후속 작업은 대상을 작업 실행 전의 상태로 되돌립니다. 자동 작업(예: AWS FIS 사용)이든 수동 작업이든 상관 없이 후속 작업은 장애 감지 및 처리 방법을 설명하는 플레이북의 일부여야 합니다.
+ 가설을 확인합니다.
[Principles of Chaos Engineering(카오스 엔지니어링의 원칙)](https://principlesofchaos.org/) 은 워크로드의 안정 상태를 확인하는 방법에 대한 다음 지침을 제공합니다.
시스템의 내부 특성보다는 시스템의 측정 가능한 결과에 중점을 둡니다. 단기간의 결과에 대한 측정값은 시스템의 안정 상태에 대한 프록시를 구성합니다. 전체 시스템의 처리량, 오류 발생률 및 지연 시간 백분위수는 모두 안정 상태 동작을 나타내는 관심 지표일 수 있습니다. 실험 중 체계적인 동작 패턴에 집중하여 카오스 엔지니어링은 시스템 작동 방식 확인이 아니라 시스템이 잘 작동하는지를 확인합니다.
이전 두 가지 예에서는 서버측(5xx) 오류 증가를 0.01% 미만으로, 데이터베이스 읽기 및 쓰기 오류를 1분 미만으로 지정한 안정 상태 지표를 포함합니다.
5xx 오류는 워크로드의 클라이언트가 직접 경험하는 장애 모드의 결과이기 때문에 좋은 지표입니다. 데이터베이스 오류 측정은 장애의 직접적인 결과이기 때문에 적절하긴 하지만 실패한 고객 요청 수 또는 고객에게 표시된 오류 수 등과 같은 클라이언트 영향 측정으로 보충해야 합니다. 또한 워크로드의 클라이언트가 직접 액세스할 수 있는 API 또는 URI에 종합 모니터(사용자 canary라고도 함)를 포함합니다.
+ 복원력을 위해 워크로드 설계를 개선합니다.
안정 상태가 유지되지 않는 경우 장애를 완화하기 위해 워크로드 설계를 어떻게 개선할 수 있는지 조사하여 [AWS Well-Architected 신뢰성 원칙](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)에 대한 모범 사례를 적용합니다. 추가 지침 및 리소스는 [AWS 빌더 라이브러리](https://aws.amazon.com/builders-library/)에서 찾을 수 있습니다. 이 라이브러리는 특히, [상태 확인 개선 방법](https://aws.amazon.com/builders-library/implementing-health-checks/) 또는 [애플리케이션 코드에서 백오프를 사용하여 재시도 채택 방법](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)에 대한 문서를 호스트합니다.
이러한 변경 사항을 구현한 후에는 실험을 다시 실행하여(카오스 엔지니어링 프라이휠에서 점선으로 표시됨) 변경 사항의 영향을 확인합니다. 확인 단계에서 가설이 참으로 입증되면 워크로드가 안정 상태이므로 주기가 계속됩니다.
+ 실험을 정기적으로 실행합니다.
카오스 실험은 주기이고 카오스 엔지니어링의 일부로 주기적으로 실행해야 합니다. 워크로드가 실험의 가설을 충족하면 CI/CD 파이프라인의 회귀 부분으로 계속해서 실행되도록 실험을 자동화해야 합니다. 이렇게 하는 방법을 알아보려면 [AWS CodePipeline을(를) 사용하여 AWS FIS 실험을 실행하는 방법](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/)에 관한 블로그를 참조하세요. 이 실습은 [CI/CD 파이프라인에서 반복 AWS FIS 실험](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html) 에 관한 내용으로, 직접 적용해 볼 수 있습니다.
장애 주입 실험은 게임 데이의 일부이기도 합니다( [REL12-BP06 정기적으로 게임 데이 진행](rel_testing_resiliency_game_days_resiliency.md)참조). 게임 데이에서는 장애나 이벤트를 시뮬레이션하여 시스템, 프로세스 및 팀 대응을 확인합니다. 게임 데이의 목적은 이례적인 이벤트 발생 시 팀이 수행해야 할 작업을 실제로 수행해보는 것입니다.
+ 실험 결과를 캡처하고 저장합니다.
장애 주입 실험의 결과는 캡처한 다음 지속해야 합니다. 나중에 실험 결과 및 추세를 분석할 수 있도록 필요한 데이터(예: 시간, 워크로드 및 조건)를 모두 포함합니다. 결과의 예에는 대시보드 스냅샷, 지표 데이터베이스의 CSV 덤프 또는 이벤트에 대해 손으로 작성한 기록, 실험에서 관찰한 내용 등이 있을 수 있습니다. [AWS FIS(으)로 기록한 실험은](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) 이러한 데이터 캡처의 일부일 수 있습니다.
## 리소스
**관련 모범 사례:**
+ [REL08-BP03 배포의 일부로 복원력 테스트 통합](rel_tracking_change_management_resiliency_testing.md)
+ [REL13-BP03 재해 복구 구현을 테스트하여 구현 확인](rel_planning_for_recovery_dr_tested.md)
**관련 문서:**
+ [AWS Fault Injection Service란 무엇인가요?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
+ [AWS Resilience Hub란 무엇인가요?](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
+ [Principles of Chaos Engineering(카오스 엔지니어링의 원칙)](https://principlesofchaos.org/)
+ [Chaos Engineering: Planning your first experiment(카오스 엔지니어링: 첫 번째 실험 계획)](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde)
+ [Resilience Engineering: Learning to Embrace Failure(복원력 엔지니어링: 실패를 수용하는 방법 학습)](https://queue.acm.org/detail.cfm?id=2371297)
+ [카오스 엔지니어링 스토리](https://github.com/ldomb/ChaosEngineeringPublicStories)
+ [분산 시스템의 폴백 방지](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/)
+ [카오스 실험을 위한 카나리 배포](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db)
**관련 동영상:**
+ [AWS re:Invent 2020: Testing resiliency using chaos engineering(카오스 엔지니어링을 사용하여 복원력 테스트)(ARC316)](https://www.youtube.com/watch?v=OlobVYPkxgg)
+ [AWS re:Invent 2019: Improving resiliency with chaos engineering(카오스 엔지니어링을 사용하여 복원력 개선)(DOP309-R1)](https://youtu.be/ztiPjey2rfY)
+ [AWS re:Invent 2019: Performing chaos engineering in a serverless world(서버리스 환경에서 카오스 엔지니어링 수행)(CMY301)](https://www.youtube.com/watch?v=vbyjpMeYitA)
**관련 예시:**
+ [Well-Architected lab: Level 300: Testing for Resiliency of Amazon EC2, Amazon RDS, and Amazon S3(Amazon EC2, Amazon RDS 및 Amazon S3의 복원력 테스트)](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
+ [Chaos Engineering on AWS lab(AWS에서 카오스 엔지니어링 실습)](https://chaos-engineering.workshop.aws/en/)
+ [Resilient and Well-Architected Apps with Chaos Engineering lab(카오스 엔지니어링을 사용해 잘 설계된 복원력이 뛰어난 앱 실습)을 참조하세요](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US)
+ [Serverless Chaos lab(서버리스 카오스 실습)](https://catalog.us-east-1.prod.workshops.aws/workshops/3015a19d-0e07-4493-9781-6c02a7626c65/en-US/serverless)
+ [Measure and Improve Your Application Resilience with AWS Resilience Hub lab(AWS Resilience Hub를 사용하여 애플리케이션 복원력 측정 및 개선 실습)](https://catalog.us-east-1.prod.workshops.aws/workshops/2a54eaaf-51ee-4373-a3da-2bf4e8bb6dd3/en-US/200-labs/1wordpressapplab)
** 관련 도구: **
+ [AWS Fault Injection Service](https://aws.amazon.com/fis/)
+ AWS Marketplace: [Gremlin Chaos Engineering Platform](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney)
+ [Chaos Toolkit](https://chaostoolkit.org/)
+ [Chaos Mesh](https://chaos-mesh.org/)
+ [Litmus](https://litmuschaos.io/)
# REL12-BP06 정기적으로 게임 데이 진행
실제 장애 시나리오에 영향을 받을 직원들과 함께 게임 데이를 정기적으로 수행하여 프로덕션에 최대한 근접한 장애 및 이벤트 대응 절차(프로덕션 환경의 장애 절차 포함)를 연습합니다. 게임 데이에서는 프로덕션 이벤트가 사용자에게 영향을 미치지 않도록 하는 조치가 시행됩니다.
게임 데이에서는 장애나 이벤트를 시뮬레이션하여 시스템, 프로세스 및 팀 대응을 테스트합니다. 게임 데이의 목적은 이례적인 이벤트 발생 시 팀이 수행해야 할 작업을 실제로 수행해보는 것입니다. 그러면 어느 분야에서 개선이 필요한지 파악하고, 조직이 이벤트에 대처하는 경험을 쌓도록 도울 수 있습니다. 팀이 대응 방법을 *체득할 수 있도록* 게임 데이를 정기적으로 진행해야 합니다.
복원력을 위한 설계가 마련되고 비 프로덕션 환경에서 이 설계를 테스트한 후에는 실전 연습을 통해 모든 구성 요소가 프로덕션에서 예상대로 작동하는지 확인합니다. 실전 연습, 특히 첫 번째 실전 연습에서는 엔지니어와 운영 팀이 모두 모여 실전 연습의 일정과 내용에 대한 정보를 숙지합니다. 런북이 준비되어 있습니다. 프로덕션 시스템에서 미리 정해진 방식으로 발생할 수 있는 장애 이벤트를 비롯한 시뮬레이션 이벤트가 실행되고 영향이 평가됩니다. 모든 시스템이 설계대로 작동할 경우 감지 및 자가 복구가 수행됩니다. 영향은 거의 없습니다. 그러나 부정적인 영향이 관찰되면 테스트가 롤백되고 워크로드 문제가 해결됩니다. 필요한 경우 런북을 사용하여 수동으로 문제를 해결합니다. 게임 데이는 프로덕션에서 수행되는 경우가 많으므로 고객의 가용성에 영향을 미치는 일이 없도록 모든 예방 조치를 취해야 합니다.
**일반적인 안티 패턴:**
+ 절차를 문서화하지만 결코 연습하지 않음
+ 테스트 연습에 비즈니스 의사 결정권자가 참여하지 않음
**이 모범 사례 수립의 이점:** 게임 데이를 정기적으로 실시하면 실제 인시던트가 발생할 때 모든 직원이 정책과 절차를 따르도록 하고 이러한 정책과 절차가 적절한지 검증할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 런북 및 플레이북을 정기적으로 실행하도록 게임 데이 수행 게임 데이에는 비즈니스 소유자, 개발 직원, 운영 직원 및 인시던트 대응 팀 등 프로덕션 이벤트에 관련된 모든 사람이 참여해야 합니다.
+ 로드 또는 성능 테스트를 실행한 다음 장애 주입을 실행합니다.
+ 런북에서 이상이 있는지 찾고 플레이북을 연습할 기회가 있는지 살펴봅니다.
+ 런북에서 벗어난 경우 해당 런북을 구체화하거나 동작을 수정합니다. 플레이북을 실행하는 경우, 사용되었어야 하는 런북을 식별하거나 새로운 런북을 만듭니다.
## 리소스
**관련 문서:**
+ [AWS 게임 데이란 무엇입니까?](https://aws.amazon.com/gameday/)
**관련 동영상:**
+ [AWS re:Invent 2019: Improving resiliency with chaos engineering(카오스 엔지니어링을 사용하여 복원력 개선)(DOP309-R1)](https://youtu.be/ztiPjey2rfY)
**관련 예시:**
+ [AWS Well-Architected 실습 - 복원력 테스트](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# 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)