# 신뢰성
<a name="a-reliability"></a>

안정성 원칙에서는 워크로드의 기능이 필요한 때에 기능을 정확하고 일관되게 수행하는 역량에 대해 다룹니다. 구현 방법에 대한 선제적인 가이드는 [안정성 원칙 백서](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html?ref=wellarchitected-wp)단축할 수 있습니다.

**Topics**
+ [기반](a-foundations.md)
+ [워크로드 아키텍처](a-workload-architecture.md)
+ [변경 사항 관리](a-change-management.md)
+ [장애 관리](a-failure-management.md)

# 기반
<a name="a-foundations"></a>

**Topics**
+ [REL 1. 서비스 할당량과 제약 조건은 어떻게 관리합니까?](rel-01.md)
+ [REL 2. 네트워크 토폴로지는 어떻게 계획합니까?](rel-02.md)

# REL 1. 서비스 할당량과 제약 조건은 어떻게 관리합니까?
<a name="rel-01"></a>

클라우드 기반 워크로드 아키텍처에는 서비스 할당량(서비스 한도라고도 함)이라는 것이 있습니다. 이러한 할당량은 실수로 필요한 것보다 많은 리소스를 프로비저닝하는 것을 방지하고 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 및 제약 조건 인식
<a name="rel_manage_service_limits_aware_quotas_and_constraints"></a>

 워크로드 아키텍처에 대한 기본 할당량을 파악하고 할당량 증가 요청을 관리합니다. 디스크 또는 네트워크 등 어떤 클라우드 리소스 제약 조건이 잠재적인 영향을 미치는지 파악합니다. 

 **원하는 결과:** 고객은 서비스 성능 저하 또는 중단을 일으킬 수 있는 서비스 할당량 및 제약 조건에 도달했는지 확인하기 위해 주요 지표, 인프라 검토 및 자동화 개선 조치 단계를 모니터링하기 위한 적절한 지침을 구현하여 AWS 계정에서 서비스 성능 저하 또는 중단을 방지할 수 있습니다. 

 **일반적인 안티 패턴:** 
+ 하드 또는 소프트 할당량과 사용되는 서비스에 대한 한도를 파악하지 않고 워크로드를 배포합니다. 
+ 필요한 할당량을 분석 및 재구성하거나 미리 지원 팀에 연락하지 않고 대체 워크로드를 배포합니다. 
+ 클라우드 서비스에는 한도가 없고 속도, 한도, 횟수, 수량 등을 고려하지 않고 서비스를 사용할 수 있다고 가정합니다.
+  할당량이 자동으로 증가할 것이라고 가정합니다. 
+  할당량 요청의 프로세스 및 타임라인을 모릅니다. 
+  기본 클라우드 서비스 할당량이 리전 간에 비교되는 모든 서비스에 대해 동일하다고 가정합니다. 
+  서비스 제약 조건은 위반할 수 있고 시스템에서 리소스의 제약 조건을 벗어나 자동으로 스케일링하거나 한도 증가를 추가한다고 가정합니다. 
+  리소스 사용률을 강조하기 위해 피크 트래픽에서 애플리케이션을 테스트하지 않습니다. 
+  필요한 리소스 크기를 분석하지 않고 리소스를 프로비저닝합니다. 
+  실제 필요 또는 예상 피크를 잘 벗어나는 리소스 유형을 선택하여 용량을 오버프로비저닝합니다. 
+  새로운 고객 이벤트 또는 새로운 기술 배포에 앞서 새로운 수준의 트래픽에 대한 용량 요구 사항을 미리 평가하지 않습니다. 

 **이 모범 사례 확립의 이점:** 서비스 할당량 및 리소스 제약 조건을 모니터링하고 관리를 자동화하면 사전에 실패를 줄일 수 있습니다. 모범 사례를 따르지 않으면 고객 서비스에 대한 트래픽 패턴의 변화로 인해 서비스 중단 또는 성능 저하가 발생할 수 있습니다. 모든 리전과 계정에서 이러한 값을 모니터링 및 관리하여 애플리케이션이 불리하거나 계획되지 않은 이벤트 발생 시 복원력을 개선할 수 있습니다. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 Service Quotas는 250개 이상의 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에 대한 속도 제한)은 Amazon API Gateway 자체에서 사용량 계획을 구성하는 방법으로 설정됩니다. 구성을 통해 해당하는 서비스에 설정되는 기타 한도로는 프로비저닝된 IOPS, 할당된 Amazon RDS 스토리지 및 Amazon EBS 볼륨 할당이 있습니다. Amazon Elastic Compute Cloud에는 인스턴스, Amazon Elastic Block Store 및 탄력적 IP 주소 제한을 관리하는 데 도움이 되는 자체 서비스 한도 대시보드가 있습니다. 서비스 할당량이 애플리케이션 성능에 영향을 미치고 요구 사항에 맞춰 조정할 수 없는 사용 사례가 있는 경우 지원에 문의하여 완화 방법이 있는지 확인하세요. 

 서비스 할당량은 리전에 따라 다를 수 있으며 특성상 전역적일 수도 있습니다. 할당량에 도달한 AWS 서비스를 사용하면 정상적인 사용 시에도 예상대로 작동하지 않을 수 있으며 서비스 중단 또는 성능 저하를 일으킬 수 있습니다. 예를 들어, 서비스 할당량은 하나의 리전에서 사용되는 DL Amazon EC2 수를 제한하며, Auto Scaling 그룹(ASG)을 사용하여 트래픽 스케일링 중에 이러한 수량 제한에 도달할 수 있습니다. 

 각 계정에 대한 서비스 할당량은 정기적으로 사용에 대해 평가해 해당 계정에 대해 적절한 서비스 한도를 확인해야 합니다. 서비스 할당량은 필요한 것보다 더 많은 리소스를 실수로 프로비저닝하지 않기 위한 운영 가드레일로 존재합니다. 또한 서비스의 남용을 방지하기 위해 API 작업에 대한 요청 속도를 제한하기도 합니다. 

 서비스 제약 조건은 서비스 할당량과 다릅니다. 서비스 제약 조건은 서비스 유형에 따라 정의된 특정 리소스 한도를 나타냅니다. 여기에는 스토리지 용량(예: gp2에는 1GB\$116TB의 크기 제한이 있음) 또는 디스크 처리량(10,000 IOPS)이 있을 수 있습니다. 한도에 도달할 수 있는 사용량에 대해서는 리소스 유형의 제약 조건을 엔지니어링하고 지속적으로 평가해야 합니다. 예기치 않게 제약 조건에 도달한 경우 계정의 애플리케이션 또는 서비스가 성능이 저하되거나 중단될 수 있습니다. 

 서비스 할당량이 애플리케이션 성능에 영향을 미치는데 요구 사항에 맞춰 조정할 수 없는 사용 사례가 있는 경우 지원에 문의하여 완화 방법이 있는지 확인하세요. 고정 할당량 조정에 대한 자세한 내용은 [REL01-BP03 아키텍처를 통해 고정된 서비스 할당량 및 제약 조건 수용](rel_manage_service_limits_aware_fixed_limits.md)의 내용을 참조하세요. 

 Service Quotas 모니터링 및 관리를 지원하기 위한 여러 가지 AWS 서비스 및 도구가 있습니다. 할당량 수준을 자동으로 또는 수동으로 확인하려면 이러한 서비스 및 도구를 활용해야 합니다. 
+  AWS Trusted Advisor는 일부 서비스의 특정 측면에 대한 사용량 및 할당량을 표시하는 서비스 할당량 확인 기능을 제공합니다. 따라서 거의 할당량에 도달한 서비스를 식별하는 데 도움이 됩니다. 
+  AWS Management Console에서는 서비스 할당량 값을 표시하고, 새로운 할당량을 관리 및 요청하고, 할당량 요청 상태를 모니터링하고, 할당량 이력을 표시하는 방법을 제공합니다. 
+  AWS CLI 및 CDK에서는 서비스 할당량 수준과 사용을 자동으로 관리 및 모니터링하기 위한 프로그래밍 방식을 제공합니다. 

 **구현 단계** 

 Service Quotas의 경우: 
+ [AWS Service Quotas를 검토합니다.](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+  기존 서비스 할당량을 파악하려면 사용되는 서비스(예: IAM Access Analyzer)를 확인합니다. 서비스 할당량으로 제어되는 AWS 서비스는 약 250개가 있습니다. 그런 다음, 각 계정 및 리전 내에서 사용 가능한 특정 서비스 할당량 이름을 확인합니다. 리전당 약 3천개의 서비스 할당량 이름이 있습니다. 
+  AWS 계정에서 사용되는 [AWS 리소스](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)를 모두 찾기 위해 AWS Config을 사용하여 할당량 분석을 강화합니다. 
+  [AWS CloudFormation 데이터](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html)를 사용하여 사용된 AWS 리소스를 확인합니다. AWS Management Console에서 또는 [https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html) AWS CLI 명령을 통해 생성된 리소스를 확인합니다. 템플릿 자체에 배포하도록 구성된 리소스를 볼 수도 있습니다. 
+  배포 코드를 확인하여 워크로드에 필요한 모든 서비스를 결정합니다. 
+  적용되는 서비스 할당량을 확인합니다. Trusted Advisor 및 Service Quotas에서 프로그래밍 방식으로 액세스되는 정보를 활용합니다. 
+  서비스 할당량이 한계에 근접하거나 도달하면 알리도록 자동화된 모니터링 방법을 설정합니다([REL01-BP02 계정 및 리전 전체에서 서비스 할당량 관리](rel_manage_service_limits_limits_considered.md) 및 [REL01-BP04 할당량 모니터링 및 관리](rel_manage_service_limits_monitor_manage_limits.md) 참조). 
+  동일한 계정 내에서 서비스 할당량이 한 리전에서는 변경되었지만 다른 리전에서는 변경되지 않은 경우를 확인하도록 자동화된 프로그래밍 방식을 설정합니다([REL01-BP02 계정 및 리전 전체에서 서비스 할당량 관리](rel_manage_service_limits_limits_considered.md) 및 [REL01-BP04 할당량 모니터링 및 관리](rel_manage_service_limits_monitor_manage_limits.md) 참조). 
+  할당량 또는 서비스 제약 조건 오류가 있는지 확인하도록 애플리케이션 로그 및 지표 검사를 자동화합니다. 이러한 오류가 있는 경우 모니터링 시스템에 알림을 보냅니다. 
+  특정 서비스에 더 큰 할당량이 필요한 것이 확인되면 필요한 할당량 변경을 계산하기 위한 엔지니어링 절차를 수립합니다([REL01-BP05 할당량 관리 자동화](rel_manage_service_limits_automated_monitor_limits.md)). 
+  서비스 할당량 변경을 요청하기 위한 프로비저닝 및 승인 워크플로를 생성합니다. 여기에는 요청 거부 또는 부분 승인 시 예외 워크플로를 포함해야 합니다. 
+  프로덕션 또는 로드된 환경으로 롤아웃하기 전에 새로운 AWS 서비스를 프로비저닝하고 사용하기에 앞서 서비스 할당량을 검토하는 엔지니어링 방법을 생성합니다(예: 로드 테스트 계정). 

 서비스 제약 조건: 
+  리소스 제약 조건에 근접한 리소스에 대해 경고하는 모니터링 및 지표 방법을 설정합니다. CloudWatch를 지표 또는 로그 모니터링에 적절하게 활용합니다. 
+  애플리케이션 또는 시스템에 의미 있는 제약 조건이 있는 각 리소스에 대해 알림 임계값을 설정합니다. 
+  제약 조건에 거의 도달하면 리소스 유형을 변경하는 워크플로 및 인프라 관리 절차를 생성합니다. 이 워크플로에는 새 유형이 새로운 제약 조건이 있는 올바른 리소스 유형인지 확인하기 위한 모범 사례로 로드 테스트를 포함해야 합니다. 
+  기존 절차 및 프로세스를 사용하여 식별된 리소스를 권장되는 새 리소스 유형으로 마이그레이션합니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [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) 
+  [REL03-BP01 워크로드를 세그먼트화하는 방법 선택](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 워크로드를 여러 위치에 배포](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 모든 계층에서 복구 자동화](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP05 카오스 엔지니어링을 이용한 복원력 테스트](rel_testing_resiliency_failure_injection_resiliency.md) 

 **관련 문서:** 
+ [AWS Well-Architected Framework의 신뢰성 원칙: 가용성](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+  [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) 
+ [할당량 증가 요청 방법](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [서비스 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+  [Service Quotas 사용 설명서](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [AWS Fault Isolation Boundaries(AWS 장애 격리 경계)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Availability with redundancy(중복성이 적용된 가용성)](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [AWS for Data](https://aws.amazon.com/data/)
+ [지속적 통합이란 무엇인가요?](https://aws.amazon.com/devops/continuous-integration/)
+ [지속적 전달이란 무엇인가요?](https://aws.amazon.com/devops/continuous-delivery/)
+ [APN 파트너: 구성 관리를 지원할 수 있는 파트너](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS(AWS의 테넌트당 계정 SaaS 환경에서 계정 수명 주기 관리)](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)
+ [워크로드에서 API 제한 관리 및 모니터링](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations(AWS Organizations를 사용하여 대규모로 AWS Trusted Advisor 권장 사항 보기) ](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)
+ [Automating Service Limit Increases and Enterprise Support with AWS Control Tower(AWS Control Tower를 사용하여 서비스 한도 증가 및 엔터프라이즈 지원 자동화)](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)

 **관련 동영상:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 
+ [ View and Manage Quotas for AWS Services Using Service Quotas(Service Quotas를 사용하여 AWS 서비스에 대한 할당량 보기 및 관리)](https://www.youtube.com/watch?v=ZTwfIIf35Wc)
+ [AWS IAM 할당량 데모](https://www.youtube.com/watch?v=srJ4jr6M9YQ)

 **관련 도구:** 
+ [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/)
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/)
+ [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)

# REL01-BP02 계정 및 리전 전체에서 서비스 할당량 관리
<a name="rel_manage_service_limits_limits_considered"></a>

 여러 계정 또는 리전을 사용하는 경우 프로덕션 워크로드가 실행되는 모든 환경에서 적절한 할당량을 요청해야 합니다. 

 **원하는 결과:** 서비스 및 애플리케이션은 여러 계정 또는 리전에 적용되는 구성 또는 영역, 리전 또는 계정 장애 조치를 사용하는 탄력적인 설계의 구성으로 인한 서비스 할당량 소진의 영향을 받지 않아야 합니다. 

 **일반적인 안티 패턴:** 
+ 다른 격리 영역에서 용량을 유지하는 메커니즘 없이 한 격리 리전의 리소스 사용량을 확장하도록 허용합니다. 
+  격리 리전에서 모든 할당량을 독립적으로 수동으로 설정합니다. 
+  기본 리전이 아닌 리전에서 성능이 저하되는 동안 향후 필요한 할당량에 복원력 아키텍처(액티브 또는 패시브)의 영향을 고려하지 않습니다. 
+  할당량을 정기적으로 평가하지 않고 워크로드가 실행되는 모든 리전 및 계정에서 필요한 변경을 수행하지 않습니다. 
+  여러 리전 및 계정 간에 증가를 요청하는 데 [할당량 요청 템플릿](https://docs.aws.amazon.com/servicequotas/latest/userguide/organization-templates.html)을 사용하지 않습니다. 
+  할당량 증가가 컴퓨팅 예약 요청과 같이 비용에 영향을 미친다고 잘못 생각하여 서비스 할당량을 업데이트하지 않습니다. 

 **이 모범 사례 확립의 이점:** 리전별 서비스를 사용할 수 없는 경우 보조 리전 또는 계정에서 현재 로드를 처리할 수 있는지 확인합니다. 이는 리전 손실 중 발생하는 오류 수 또는 성능 저하 수준을 줄이는 데 도움이 됩니다. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 서비스 할당량은 계정별로 추적됩니다. 다른 언급이 없는 한, 각 할당량은 AWS 리전별로 다릅니다. 프로덕션 환경에 더해 적용 가능한 모든 비 프로덕션 환경에서도 할당량을 관리하여 테스트 및 개발에 방해가 되지 않도록 합니다. 높은 수준의 복원력을 유지하려면 지속적으로 서비스 할당량을 (자동 또는 수동으로) 평가해야 합니다. 

 *액티브/액티브*, *액티브/패시브 – 핫*, *액티브/패시브-콜드* 및 *액티브/패시브-파일럿 라이트* 접근 방식을 사용하는 설계의 구현으로 인해 여러 리전에 걸쳐 워크로드가 증가하는 경우 모든 리전 및 계정 할당량 수준을 파악해야 합니다. 서비스 할당량이 올바르게 설정되어 있더라도 과거 트래픽 패턴이 항상 좋은 지표는 아닙니다. 

 서비스 할당량 이름 제한이 모든 리전에 대해 항상 같은 것도 아닙니다. 한 리전에서 이 값은 5일 수 있으며 다른 리전에서는 10일 수 있습니다. 로드 발생 시 일정한 복원력을 제공하려면 이러한 할당량 관리는 동일한 서비스, 계정, 리전을 모두 포함해야 합니다. 

 여러 리전(액티브 리전 또는 패시브 리전) 간에 모든 서비스 할당량 차이를 조정하고 이러한 차이를 지속적으로 조정하기 위한 프로세스를 생성합니다. 패시브 리전 장애 조치의 테스트 계획은 피크 액티브 용량으로 확장되는 경우가 거의 없습니다. 즉, 게임 데이 또는 탁상 훈련(TTX) 방식은 리전 간 서비스 할당량의 차이를 찾지 못할 수 있고 올바른 한도를 유지하지 못할 수 있습니다. 

 지정된 특정 할당량에 대한 서비스 할당량 제한이 모든 리전이 아니라 한 리전에서 변경되는 조건인 *서비스 할당량 드리프트*는 추적 및 평가해야 하는 매우 중요한 조건입니다. 트래픽이 있는 리전 또는 트래픽이 발생할 수 있는 리전에서는 할당량 변경을 고려해야 합니다. 
+  서비스 요구 사항, 지연 시간, 규정, 재해 복구(DR) 요구 사항을 기준으로 관련 계정 및 리전을 선택합니다. 
+  모든 관련 계정, 리전 및 가용 영역의 서비스 할당량을 확인합니다. 한도는 계정 및 리전별로 관리됩니다. 이러한 값은 차이가 있는지 비교해야 합니다. 

 **구현 단계** 
+  사용 위험 수준을 벗어나 위반될 수 있는 Service Quotas 값을 검토합니다. AWS Trusted Advisor에서는 80% 및 90% 임계값 위반에 대한 알림을 제공합니다. 
+  (액티브/패시브 설계인 경우) 모든 패시브 리전에서 서비스 할당량에 대한 값을 검토합니다. 기본 리전에서 장애 발생 시 보조 리전에서 로드가 성공적으로 실행되는지 확인합니다. 
+  동일한 계정 내 리전 간에 서비스 할당량 드리프트가 발생했는지 여부 평가를 자동화하고 한도 변경에 적절하게 대응합니다. 
+  고객 조직 단위(OU)가 지원되는 방식으로 구성되어 있으면 여러 리전 및 계정에 적용해야 하는 모든 할당량의 변화를 반영하도록 서비스 할당량 템플릿을 업데이트해야 합니다. 
  +  템플릿을 생성하고 할당량 변경에 리전을 연결합니다. 
  +  필요한 모든 변경(리전, 한도 및 계정)에 대한 기존 서비스 할당량 템플릿을 모두 검토합니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [REL01-BP01 Service Quotas 및 제약 조건 인식](rel_manage_service_limits_aware_quotas_and_constraints.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) 
+  [REL03-BP01 워크로드를 세그먼트화하는 방법 선택](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 워크로드를 여러 위치에 배포](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 모든 계층에서 복구 자동화](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP05 카오스 엔지니어링을 이용한 복원력 테스트](rel_testing_resiliency_failure_injection_resiliency.md) 

 **관련 문서:** 
+ [AWS Well-Architected Framework의 신뢰성 원칙: 가용성](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+  [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) 
+ [할당량 증가 요청 방법](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [서비스 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+  [Service Quotas 사용 설명서](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [AWS Fault Isolation Boundaries(AWS 장애 격리 경계)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Availability with redundancy(중복성이 적용된 가용성)](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [AWS for Data](https://aws.amazon.com/data/)
+ [지속적 통합이란 무엇인가요?](https://aws.amazon.com/devops/continuous-integration/)
+ [지속적 전달이란 무엇인가요?](https://aws.amazon.com/devops/continuous-delivery/)
+ [APN 파트너: 구성 관리를 지원할 수 있는 파트너](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS(AWS의 테넌트당 계정 SaaS 환경에서 계정 수명 주기 관리)](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)
+ [워크로드에서 API 제한 관리 및 모니터링](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations(AWS Organizations를 사용하여 대규모로 AWS Trusted Advisor 권장 사항 보기) ](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)
+ [Automating Service Limit Increases and Enterprise Support with AWS Control Tower(AWS Control Tower를 사용하여 서비스 한도 증가 및 엔터프라이즈 지원 자동화)](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)

 **관련 동영상:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 
+ [ View and Manage Quotas for AWS Services Using Service Quotas(Service Quotas를 사용하여 AWS 서비스에 대한 할당량 보기 및 관리)](https://www.youtube.com/watch?v=ZTwfIIf35Wc)
+ [AWS IAM 할당량 데모](https://www.youtube.com/watch?v=srJ4jr6M9YQ)

 **관련 서비스:** 
+ [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/)
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/)
+ [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)

# REL01-BP03 아키텍처를 통해 고정된 서비스 할당량 및 제약 조건 수용
<a name="rel_manage_service_limits_aware_fixed_limits"></a>

변경할 수 없는 서비스 할당량, 서비스 제약 조건 및 물리적 리소스 한도를 알고 있어야 합니다. 이러한 한도가 신뢰성에 영향을 미치지 않도록 애플리케이션 및 서비스의 아키텍처를 설계합니다.

네트워크 대역폭, 서버리스 기능 호출 페이로드 크기, API 게이트웨이의 스로틀 버스트 속도 및 데이터베이스에 대한 동시 사용자 연결 등이 여기에 포함됩니다.

 **원하는 결과:** 애플리케이션 또는 서비스는 정상 조건 및 트래픽이 많은 조건에서 예상대로 수행됩니다. 해당 리소스의 고정 제약 조건 또는 서비스 할당량의 한계 내에서 작동하도록 설계되었습니다. 

 **일반적인 안티 패턴:** 
+ 확장 시 해당 설계에서 장애를 유발하는 설계 제약 조건이 있다는 사실을 인지하지 못한 채 하나의 서비스 리소스를 사용하는 설계 방식을 선택합니다.
+ 비현실적이며 테스트 중에 고정된 서비스 할당량에 도달하는 벤치마킹을 수행합니다. 예를 들어, 버스트 한도에서 테스트를 실행하면서, 오랜 시간 실행합니다.
+  고정된 서비스 할당량을 초과하는 경우 확장할 수 없거나 수정할 수 없는 설계를 선택합니다. 예를 들어, SQS 페이로드 크기는 256kb입니다. 
+  높은 트래픽 이벤트 동안 위험에 처할 수 있는 서비스 할당량의 임계값을 모니터링하고 경고하도록 관측성이 설계 및 구현되지 않았습니다. 

 **이 모범 사례 확립의 이점:** 애플리케이션이 중단이나 성능 저하 없이 예상되는 모든 서비스 부하 수준에서 실행되는지 확인합니다. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 중간 

## 구현 가이드
<a name="implementation-guidance"></a>

 더 큰 용량 단위로 대체되는 소프트 서비스 할당량 또는 리소스와 달리 AWS 서비스의 고정 할당량은 변경할 수 없습니다. 따라서 이러한 모든 유형의 AWS 서비스는 애플리케이션 설계에 사용될 때 잠재적인 하드 용량 한도에 대해 평가되어야 합니다. 

 하드 한도는 Service Quotas 콘솔에 표시됩니다. 열에 `ADJUSTABLE = No`가 표시되면 서비스에 하드 한도가 있는 것입니다. 하드 한도는 일부 리소스 구성 페이지에도 표시됩니다. 예를 들어 Lambda에는 조정할 수 없는 특정 하드 한도가 있습니다. 

 예를 들어 Python 애플리케이션을 Lambda 함수에서 실행하도록 설계할 때 Lambda가 15분 이상 실행될 가능성이 있는지 확인하기 위해 애플리케이션을 평가해야 합니다. 코드가 이 서비스 할당량 한도보다 더 오래 실행될 수 있는 경우 대체 기술 또는 설계를 고려해야 합니다. 프로덕션 배포 후 이 한도에 도달하면 애플리케이션은 문제를 해결할 수 있을 때까지 성능 저하 및 중단이 발생합니다. 소프트 할당량과 달리 긴급 심각도 1 이벤트에서도 이러한 한도를 변경할 수 있는 방법이 없습니다. 

 애플리케이션이 테스트 환경에 배포되면 하드 한도에 도달할 수 있는지 확인하기 위한 전략을 사용해야 합니다. 스트레스 테스트, 부하 테스트 및 카오스 테스트는 도입 테스트 계획의 일부여야 합니다. 

 **구현 단계** 
+  애플리케이션 설계 단계에서 사용할 수 있는 AWS 서비스의 전체 목록을 검토합니다. 
+  이러한 모든 서비스에 대한 소프트 할당량 한도 및 하드 할당량 한도를 검토합니다. 모든 한도가 Service Quotas 콘솔에 표시되는 것은 아닙니다. 일부 서비스는 [대체 위치에서 이러한 한도를 설명](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)합니다. 
+  애플리케이션을 설계할 때 비즈니스 결과, 사용 사례, 종속 시스템, 가용성 목표 및 재해 복구 개체와 같은 워크로드의 비즈니스 및 기술 동인을 검토합니다. 비즈니스 및 기술 동인이 워크로드에 적합한 분산 시스템을 식별하는 프로세스를 안내하도록 합니다. 
+  리전 및 계정 전체에서 서비스 부하를 분석합니다. 서비스의 많은 하드 한도가 리전을 기반으로 합니다. 그러나 일부 한도는 계정을 기반으로 합니다. 
+  영역 장애 및 리전 장애 시 리소스 사용량에 대한 복원력 아키텍처를 분석합니다. 액티브/액티브, 액티브/패시브 - 핫, 액티브/패시브 - 콜드 및 액티브/패시브 - 파일럿 라이트 접근 방식을 사용하는 다중 리전 설계의 진행에서 이러한 실패 사례는 더 높은 사용량을 야기할 것입니다. 이는 하드 한도에 도달할 수 있는 잠재적 사용 사례를 생성합니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [REL01-BP01 Service Quotas 및 제약 조건 인식](rel_manage_service_limits_aware_quotas_and_constraints.md) 
+  [REL01-BP02 계정 및 리전 전체에서 서비스 할당량 관리](rel_manage_service_limits_limits_considered.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) 
+  [REL03-BP01 워크로드를 세그먼트화하는 방법 선택](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 워크로드를 여러 위치에 배포](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 모든 계층에서 복구 자동화](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP05 카오스 엔지니어링을 이용한 복원력 테스트](rel_testing_resiliency_failure_injection_resiliency.md) 

 **관련 문서:** 
+ [AWS Well-Architected Framework의 신뢰성 원칙: 가용성](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+  [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) 
+ [할당량 증가 요청 방법](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [서비스 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+  [Service Quotas 사용 설명서](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [AWS Fault Isolation Boundaries(AWS 장애 격리 경계)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Availability with redundancy(중복성이 적용된 가용성)](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [AWS for Data](https://aws.amazon.com/data/)
+ [지속적 통합이란 무엇인가요?](https://aws.amazon.com/devops/continuous-integration/)
+ [지속적 전달이란 무엇인가요?](https://aws.amazon.com/devops/continuous-delivery/)
+ [APN 파트너: 구성 관리를 지원할 수 있는 파트너](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS(AWS의 테넌트당 계정 SaaS 환경에서 계정 수명 주기 관리)](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)
+ [워크로드에서 API 제한 관리 및 모니터링](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations(AWS Organizations를 사용하여 대규모로 AWS Trusted Advisor 권장 사항 보기) ](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)
+ [Automating Service Limit Increases and Enterprise Support with AWS Control Tower(AWS Control Tower를 사용하여 서비스 한도 증가 및 엔터프라이즈 지원 자동화)](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)
+ [Service Quotas에 사용되는 작업, 리소스 및 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html)

 **관련 동영상:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 
+ [ View and Manage Quotas for AWS Services Using Service Quotas(Service Quotas를 사용하여 AWS 서비스에 대한 할당량 보기 및 관리)](https://www.youtube.com/watch?v=ZTwfIIf35Wc)
+ [AWS IAM 할당량 데모](https://www.youtube.com/watch?v=srJ4jr6M9YQ)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small](https://www.youtube.com/watch?v=O8xLxNje30M)(루프 닫기 및 마음 열기: 규모에 상관없이 시스템을 제어하는 방법)

 **관련 도구:** 
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/)
+ [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)

# REL01-BP04 할당량 모니터링 및 관리
<a name="rel_manage_service_limits_monitor_manage_limits"></a>

 잠재적 사용량을 평가하고 할당량을 적절히 늘려 사용량 증가를 계획합니다. 

 **원하는 결과:** 관리 및 모니터링하는 액티브 자동화된 시스템이 배치되었습니다. 이러한 운영 솔루션은 할당량 사용량 임계값에 거의 도달하고 있는지 확인합니다. 이러한 문제는 요청된 할당량 변경에 의해 사전에 해결됩니다. 

 **일반적인 안티 패턴:** 
+ 서비스 할당량 임계값을 확인하도록 모니터링을 구성하지 않습니다.
+ 해당 값을 변경할 수 없는 경우에도 하드 한도에 대한 모니터링을 구성하지 않습니다.
+  소프트 할당량 변경을 요청하고 확보하는 데 필요한 시간이 즉각적이거나 짧은 기간이라고 가정합니다. 
+  서비스 할당량에 근접할 경우 알리는 경보를 구성하지만, 알림에 응답하는 프로세스를 갖추지 않습니다. 
+  AWS Service Quotas에서 지원하는 서비스에 대해서만 경보를 구성하고 다른 AWS 서비스는 모니터링하지 않습니다. 
+  액티브/액티브, 액티브/패시브 - 핫, 액티브/패시브 - 콜드 및 액티브/패시브 - 파일럿 라이트 접근 방식과 같은 여러 리전 복원력 설계에 대한 할당량 관리를 고려하지 않습니다. 
+  리전 간 할당량 차이를 평가하지 않습니다. 
+  특정 할당량 증가 요청에 대해 모든 리전의 요구 사항을 평가하지 않습니다. 
+  [다중 리전 할당량 관리를 위한 템플릿](https://docs.aws.amazon.com/servicequotas/latest/userguide/organization-templates.html)을 활용하지 않습니다. 

 **이 모범 사례 확립의 이점:** AWS Service Quotas를 자동으로 추적하고 이러한 할당량을 기준으로 사용량을 모니터링하면 할당량 한도에 근접할 경우 이를 알 수 있습니다. 이 모니터링 데이터를 사용하여 할당량 소진으로 인한 성능 저하를 제한할 수도 있습니다. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 중간 

## 구현 가이드
<a name="implementation-guidance"></a>

 지원되는 서비스의 경우 경고 또는 알람을 평가하고 보낼 수 있는 다양한 서비스를 구성하여 할당량을 모니터링할 수 있습니다. 사용량을 모니터링하는 데 도움이 될 수 있으며 할당량에 근접하면 알림을 받을 수 있습니다. 이러한 경보는 AWS Config, Lambda 함수, Amazon CloudWatch 또는 AWS Trusted Advisor에서 트리거될 수 있습니다. CloudWatch Logs의 지표 필터를 사용하여 로그의 패턴을 검색하고 추출하여 사용량이 할당량 임계값에 근접하는지 여부를 확인할 수도 있습니다. 

 **구현 단계** 

 모니터링: 
+  현재 리소스 사용 내역(버킷, 인스턴스)을 파악합니다. Amazon EC2 `DescribeInstances` API와 같은 서비스 API 작업을 사용하여 현재 리소스 사용량 내역을 수집합니다. 
+  다음을 사용하여 서비스에 필수적이며 적용 가능한 현재 할당량을 캡처합니다. 
  +  AWS Service Quotas 
  +  AWS Trusted Advisor 
  +  AWS 설명서 
  +  AWS 서비스별 페이지 
  +  AWS Command Line Interface(AWS CLI) 
  +  AWS Cloud Development Kit (AWS CDK) 
+  250개 이상의 AWS 서비스에 대한 할당량을 단일 위치에서 관리할 수 있는 AWS 서비스인 AWS Service Quotas를 사용합니다. 
+  Trusted Advisor 서비스 한도를 사용하여 다양한 임계값에서 현재 서비스 한도를 모니터링합니다. 
+  서비스 할당량 기록(콘솔 또는 AWS CLI)을 사용하여 리전별 증가를 확인합니다. 
+  필요한 경우 각 리전 및 각 계정의 서비스 할당량 변경 사항을 비교하여 동등성을 생성합니다. 

 관리: 
+  자동: AWS Config 사용자 지정 규칙을 설정하여 리전 간 서비스 할당량을 스캔하고 차이점을 비교합니다. 
+  자동: 예약된 Lambda 함수를 설정하여 리전 간 서비스 할당량을 스캔하고 차이점을 비교합니다. 
+  수동: AWS CLI, API 또는 AWS 콘솔을 통해 서비스 할당량을 스캔하여 리전 간 서비스 할당량을 스캔하고 차이점을 비교합니다. 차이점을 보고합니다. 
+  리전 간에 할당량 차이가 확인되면 필요한 경우 할당량 변경을 요청합니다. 
+  모든 요청 결과를 검토합니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [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-BP05 할당량 관리 자동화](rel_manage_service_limits_automated_monitor_limits.md) 
+  [REL01-BP06 현재의 할당량과 최대 사용량 간에 장애 조치를 수용할 만큼 여유가 충분히 있는지 확인](rel_manage_service_limits_suff_buffer_limits.md) 
+  [REL03-BP01 워크로드를 세그먼트화하는 방법 선택](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 워크로드를 여러 위치에 배포](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 모든 계층에서 복구 자동화](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP05 카오스 엔지니어링을 이용한 복원력 테스트](rel_testing_resiliency_failure_injection_resiliency.md) 

 **관련 문서:** 
+ [AWS Well-Architected Framework의 신뢰성 원칙: 가용성](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+  [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) 
+ [할당량 증가 요청 방법](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [서비스 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+  [Service Quotas 사용 설명서](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [AWS Fault Isolation Boundaries(AWS 장애 격리 경계)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Availability with redundancy(중복성이 적용된 가용성)](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [AWS for Data](https://aws.amazon.com/data/)
+ [지속적 통합이란 무엇인가요?](https://aws.amazon.com/devops/continuous-integration/)
+ [지속적 전달이란 무엇인가요?](https://aws.amazon.com/devops/continuous-delivery/)
+ [APN 파트너: 구성 관리를 지원할 수 있는 파트너](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS(AWS의 테넌트당 계정 SaaS 환경에서 계정 수명 주기 관리)](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)
+ [워크로드에서 API 제한 관리 및 모니터링](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations(AWS Organizations를 사용하여 대규모로 AWS Trusted Advisor 권장 사항 보기) ](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)
+ [Automating Service Limit Increases and Enterprise Support with AWS Control Tower(AWS Control Tower를 사용하여 서비스 한도 증가 및 엔터프라이즈 지원 자동화)](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)
+ [Service Quotas에 사용되는 작업, 리소스 및 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html)

 **관련 동영상:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 
+ [ View and Manage Quotas for AWS Services Using Service Quotas(Service Quotas를 사용하여 AWS 서비스에 대한 할당량 보기 및 관리)](https://www.youtube.com/watch?v=ZTwfIIf35Wc)
+ [AWS IAM 할당량 데모](https://www.youtube.com/watch?v=srJ4jr6M9YQ)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small](https://www.youtube.com/watch?v=O8xLxNje30M)(루프 닫기 및 마음 열기: 규모에 상관없이 시스템을 제어하는 방법)

 **관련 도구:** 
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/)
+ [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)

# REL01-BP05 할당량 관리 자동화
<a name="rel_manage_service_limits_automated_monitor_limits"></a>

 임계값에 근접했을 때 알림을 받을 수 있는 도구를 구현합니다. AWS Service Quotas API를 사용하여 할당량 증가 요청을 자동화할 수 있습니다. 

 CMDB(구성 관리 데이터베이스) 또는 티켓팅 시스템을 Service Quotas와 통합하면 할당량 증가 요청 및 현재 할당량 추적을 자동화할 수 있습니다. Service Quotas는 AWS SDK 외에도 AWS Command Line Interface(AWS CLI)를 사용한 자동화를 제공합니다. 

 **일반적인 안티 패턴:** 
+  스프레드시트에서 할당량 및 사용량 추적 
+  일별, 주별 또는 월별 사용량에 대한 보고서를 실행한 다음 사용량을 할당량과 비교 

 **이 모범 사례 정립의 이점:** AWS 서비스 할당량을 자동으로 추적하고 해당 할당량을 기준으로 사용량을 모니터링하면 할당량에 근접할 경우 이를 알 수 있습니다. 자동화를 설정하여 필요할 때 할당량 증가를 요청할 수 있습니다. 사용량이 반대로 감소 추세를 보일 경우 할당량을 일부 낮추면 위험 감소(자격 증명이 침해당한 경우) 및 비용 절감의 이점을 실현할 수 있습니다. 

 **이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  자동화된 모니터링 설정 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에 연락하도록 트리거를 설정합니다. 
    +  변경 이벤트를 수동으로 트리거합니다. 
    +  게임 데이를 실행하여 할당량 증가 변경 프로세스를 테스트합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 현재의 할당량과 최대 사용량 간에 장애 조치를 수용할 만큼 여유가 충분히 있는지 확인
<a name="rel_manage_service_limits_suff_buffer_limits"></a>

리소스는 실패하거나 액세스할 수 없는 경우에도 해당 리소스가 성공적으로 종료될 때까지 계속 할당량 계산에 포함될 수 있습니다. 장애가 있거나 액세스할 수 없는 리소스와 대체 리소스가 중복되는 부분이 할당량에 반영되는지 확인합니다. 이 차이를 계산할 때 네트워크 장애, 가용 영역 장애 또는 리전 장애와 같은 사용 사례를 고려해야 합니다.

 **원하는 결과:** 리소스 또는 리소스 액세스 가능성의 작거나 큰 장애는 현재 서비스 임계값 내에서 처리될 수 있습니다. 영역 장애, 네트워크 장애 또는 리전 장애도 리소스 계획에서 고려되었습니다. 

 **일반적인 안티 패턴:** 
+  장애 조치 시나리오를 고려하지 않고 현재의 수요를 기준으로 서비스 할당량을 설정합니다. 
+  서비스의 최대 할당량을 계산할 때 정적 안정성 원칙을 고려하지 않습니다. 
+  각 리전에 필요한 총 할당량을 계산할 때 액세스할 수 없는 리소스의 가능성을 고려하지 않습니다. 
+  일부 서비스에 대한 AWS 서비스 장애 격리 경계 및 잠재적인 비정상적인 사용 패턴을 고려하지 않습니다. 

 **이 모범 사례 확립의 이점:** 서비스 중단 이벤트가 애플리케이션 가용성에 영향을 미치는 경우 클라우드를 통해 이러한 이벤트를 완화하거나 복구하는 전략을 구현할 수 있습니다. 그러한 전략에는 장애가 발생하거나 액세스할 수 없는 리소스를 대체할 추가 리소스를 생성하는 작업이 포함되는 경우가 많습니다. 할당량 전략은 이러한 장애 조치 조건을 수용하고 서비스 한도 소진으로 인한 추가 저하를 계층화하지 않습니다. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 중간 

## 구현 가이드
<a name="implementation-guidance"></a>

 할당량 한도를 평가할 때 일부 성능 저하로 인해 발생할 수 있는 장애 조치 사례를 고려합니다. 다음 유형의 장애 조치 사례를 고려해야 합니다. 
+  중단되었거나 액세스할 수 없는 VPC 
+  액세스할 수 없는 서브넷 
+  가용 영역이 많은 리소스의 액세스 가능성에 영향을 줄 만큼 충분히 저하되었습니다. 
+  다양한 네트워킹 경로 또는 수신 및 송신 지점이 차단되거나 변경됩니다. 
+  많은 리소스의 액세스 가능성에 영향을 줄 정도로 리전의 성능이 충분히 저하되었습니다. 
+  여러 리소스가 있지만 모든 리소스가 리전 또는 가용 영역의 장애로 인해 영향을 받는 것은 아닙니다. 

 위 목록과 같은 실패는 장애 조치 이벤트를 시작하는 트리거가 될 수 있습니다. 장애 조치를 하기로 내린 결정은 비즈니스에 미치는 영향이 크게 다를 수 있으므로 상황과 고객마다 다릅니다. 그러나 애플리케이션 또는 서비스를 장애 조치하기로 운영상 결정할 때 장애 조치 위치에 있는 리소스의 용량 계획 및 관련 할당량은 이벤트 시작 전에 해결되어야 합니다. 

 발생할 수 있는 정상 사용량보다 높은 사용량을 고려하여 각 서비스에 대한 서비스 할당량을 검토합니다. 이러한 사용량은 네트워킹 또는 권한으로 인해 도달할 수 있지만 여전히 액티브 상태인 리소스와 관련이 있을 수 있습니다. 종료되지 않은 액티브 리소스는 여전히 서비스 할당량 제한에 포함됩니다. 

 **구현 단계** 
+  서비스 할당량과 최대 사용량 간에 장애 조치와 접근성 손실을 수용할 만큼 여유가 충분히 있는지 확인합니다. 
+  배치 패턴, 가용성 요청 사항, 서비스 사용량 증가를 고려해 서비스 할당량을 결정합니다. 
+  필요한 경우 할당량 증가를 요청합니다. 할당량 증가 요청이 반영될 시간을 고려합니다. 
+  신뢰성 요구 사항("9의 개수"라고도 함)을 확인합니다. 
+  장애 시나리오(예: 구성 요소, 가용 영역 또는 리전 손실)를 설정합니다. 
+  배포 방법(Canary, 블루/그린, 레드/블랙 또는 롤링 등)을 설정합니다. 
+  현재 한도에 적절한 버퍼(예: 15%)가 포함되어야 합니다. 
+  적절한 경우 정적 안정성(영역 및 리전)에 대한 계산을 포함합니다. 
+  사용량 증가 계획(사용 추세 모니터링 등)을 수립합니다. 
+  가장 중요한 워크로드에 대한 정적 안정성의 영향을 고려합니다. 모든 리전 및 가용 영역에서 정적으로 안정적인 시스템을 준수하는 리소스를 평가합니다. 
+  온디맨드 용량 예약을 사용하여 장애 조치 전에 용량을 예약하는 것을 고려합니다. 이는 장애 조치 중에 적절한 양과 유형의 리소스를 확보하여 가장 중요한 비즈니스 일정 중에 잠재적 위험을 줄일 수 있는 유용한 전략이 될 수 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [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) 
+  [REL03-BP01 워크로드를 세그먼트화하는 방법 선택](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 워크로드를 여러 위치에 배포](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 모든 계층에서 복구 자동화](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP05 카오스 엔지니어링을 이용한 복원력 테스트](rel_testing_resiliency_failure_injection_resiliency.md) 

 **관련 문서:** 
+ [AWS Well-Architected Framework의 신뢰성 원칙: 가용성](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+  [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) 
+ [할당량 증가 요청 방법](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [서비스 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+  [Service Quotas 사용 설명서](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [AWS Fault Isolation Boundaries(AWS 장애 격리 경계)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Availability with redundancy(중복성이 적용된 가용성)](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [AWS for Data](https://aws.amazon.com/data/)
+ [지속적 통합이란 무엇인가요?](https://aws.amazon.com/devops/continuous-integration/)
+ [지속적 전달이란 무엇인가요?](https://aws.amazon.com/devops/continuous-delivery/)
+ [APN 파트너: 구성 관리를 지원할 수 있는 파트너](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS(AWS의 테넌트당 계정 SaaS 환경에서 계정 수명 주기 관리)](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)
+ [워크로드에서 API 제한 관리 및 모니터링](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations(AWS Organizations를 사용하여 대규모로 AWS Trusted Advisor 권장 사항 보기) ](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)
+ [Automating Service Limit Increases and Enterprise Support with AWS Control Tower(AWS Control Tower를 사용하여 서비스 한도 증가 및 엔터프라이즈 지원 자동화)](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)
+ [Service Quotas에 사용되는 작업, 리소스 및 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html)

 **관련 동영상:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 
+ [ View and Manage Quotas for AWS Services Using Service Quotas(Service Quotas를 사용하여 AWS 서비스에 대한 할당량 보기 및 관리)](https://www.youtube.com/watch?v=ZTwfIIf35Wc)
+ [AWS IAM 할당량 데모](https://www.youtube.com/watch?v=srJ4jr6M9YQ)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small](https://www.youtube.com/watch?v=O8xLxNje30M)(루프 닫기 및 마음 열기: 규모에 상관없이 시스템을 제어하는 방법)

 **관련 도구:** 
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/)
+ [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)

# REL 2. 네트워크 토폴로지는 어떻게 계획합니까?
<a name="rel-02"></a>

워크로드는 여러 환경에 존재할 수 있습니다. 여기에는 다중 클라우드 환경(퍼블릭 액세스 및 프라이빗)과 기존 데이터 센터 인프라가 포함됩니다. 따라서 시스템 내부 및 시스템 간 연결, 퍼블릭 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 워크로드 퍼블릭 엔드포인트에 고가용성 네트워크 연결 사용
<a name="rel_planning_network_topology_ha_conn_users"></a>

 워크로드의 퍼블릭 엔드포인트에 대한 고가용성 네트워크 연결을 구축하면 연결 손실로 인한 가동 중지 시간을 줄이고 워크로드의 가용성 및 SLA를 개선하는 데 도움이 될 수 있습니다. 이러한 고가용성을 달성하려면 고가용성 DNS, 콘텐츠 전송 네트워크(CDN), API Gateway, 로드 밸런싱 또는 역방향 프록시를 사용합니다. 

 **원하는 결과:** 퍼블릭 엔드포인트에 대한 고가용성 네트워크 연결을 계획, 구축 및 운영하는 것이 중요합니다. 연결 손실로 인해 워크로드에 연결할 수 없게 되면 워크로드가 실행 중이고 사용 가능한 경우에도 고객은 시스템이 다운된 것으로 보게 됩니다. 워크로드 자체에 대한 복원력 있는 아키텍처와 함께 워크로드의 퍼블릭 엔드포인트를 위한 고가용성 및 복원력 있는 네트워크 연결을 결합하여 고객에게 가능한 최상의 가용성과 서비스 수준을 제공할 수 있습니다. 

 AWS Global Accelerator, Amazon CloudFront, Amazon API Gateway, AWS Lambda 함수 URL, AWS AppSync API 및 Elastic Load Balancing(ELB)은 모두 고가용성 퍼블릭 엔드포인트를 제공합니다.Amazon Route 53은 퍼블릭 엔드포인트 주소를 확인할 수 있는지 확인하기 위해 도메인 이름 확인을 위한 고가용성 DNS 서비스를 제공합니다. 

 로드 밸런싱 및 프록싱을 위해 AWS Marketplace 소프트웨어 어플라이언스를 평가할 수도 있습니다. 

 **일반적인 안티 패턴:** 
+ 고가용성을 위한 DNS 및 네트워크 연결을 계획하지 않고 고가용성 워크로드를 설계합니다.
+  개별 인스턴스 또는 컨테이너에서 퍼블릭 인터넷 주소를 사용하고 DNS를 통해 이러한 주소에 대한 연결을 관리합니다.
+  서비스를 찾기 위해 도메인 이름 대신 IP 주소를 사용합니다.
+  퍼블릭 엔드포인트에 대한 연결이 끊어지는 시나리오를 테스트하지 않습니다. 
+  네트워크 처리량 요구 사항 및 배포 패턴을 분석하지 않습니다. 
+  워크로드의 퍼블릭 엔드포인트에 대한 인터넷 네트워크 연결이 중단될 수 있는 시나리오를 테스트하고 계획하지 않습니다. 
+  콘텐츠 전송 네트워크를 사용하지 않고 대규모 지리적 영역에 콘텐츠(예: 웹 페이지, 정적 자산, 미디어 파일)를 제공합니다. 
+  DDoS(Distributed Denial Of Service) 공격에 대한 계획이 없습니다. DDoS 공격은 합법적인 트래픽을 차단하고 사용자의 가용성을 낮출 위험이 있습니다. 

 **이 모범 사례 확립의 이점:** 가용성이 높고 복원력이 뛰어난 네트워크 연결을 설계하면 사용자가 워크로드에 액세스하고 사용할 수 있습니다. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 퍼블릭 엔드포인트에 대한 고가용성 네트워크 연결 구축의 핵심은 트래픽 라우팅입니다. 트래픽이 엔드포인트에 도달할 수 있는지 확인하려면 DNS가 도메인 이름을 해당 IP 주소로 확인할 수 있어야 합니다. Amazon Route 53과 같이 가용성과 확장성이 뛰어난 [도메인 이름 시스템(DNS)](https://aws.amazon.com/route53/what-is-dns/)을 사용하여 도메인의 DNS 레코드를 관리합니다. Amazon Route 53에서 제공하는 상태 확인을 사용할 수도 있습니다. 상태 확인은 애플리케이션이 도달 가능하고 사용 가능하며 작동하는지 확인하며, 웹 페이지 또는 특정 URL 요청과 같은 사용자 행동을 모방하는 방식으로 설정할 수 있습니다. 장애가 발생하면 Amazon Route 53은 DNS 확인 요청에 응답하고 트래픽을 상태 엔드포인트로만 보냅니다. Amazon Route 53에서 제공하는 지리적 DNS 및 지연 시간 기반 라우팅 기능을 사용할 수도 있습니다. 

 워크로드 자체의 가용성이 높은지 확인하려면 Elastic Load Balancing(ELB)을 사용합니다. Amazon Route 53은 대상 컴퓨팅 인스턴스에 트래픽을 분산하는 ELB로 트래픽을 라우팅하는 데 사용할 수 있습니다. 서버리스 솔루션을 위해 AWS Lambda와 함께 Amazon API Gateway를 사용할 수도 있습니다. 고객은 여러 AWS 리전에서 워크로드를 실행할 수도 있습니다. [다중 사이트 액티브/액티브 패턴](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)을 사용하면 워크로드가 여러 리전의 트래픽을 처리할 수 있습니다. 다중 사이트 액티브/패시브 패턴을 사용하면 워크로드가 액티브 리전의 트래픽을 처리하는 동시에 데이터가 보조 리전으로 복제되고 기본 리전에서 장애가 발생할 경우 활성화됩니다. 그런 다음 Route 53 상태 확인을 사용하여 기본 리전의 모든 엔드포인트에서 보조 리전의 엔드포인트로의 DNS 장애 조치를 제어하여 사용자가 워크로드에 도달하고 사용할 수 있는지 확인할 수 있습니다. 

 Amazon CloudFront는 전 세계 엣지 로케이션 네트워크를 사용하여 요청을 처리함으로써 짧은 지연 시간과 높은 데이터 전송 속도로 콘텐츠를 배포하기 위한 간단한 API를 제공합니다. 콘텐츠 전송 네트워크(CDN)는 사용자와 가까운 위치에 있거나 캐시된 콘텐츠를 제공하여 고객에게 서비스를 제공합니다. 또한 콘텐츠에 대한 로드가 서버에서 CloudFront의 [엣지 로케이션](https://aws.amazon.com/products/networking/edge-networking/)으로 이동되므로 애플리케이션의 가용성도 향상됩니다. 엣지 로케이션 및 리전 엣지 캐시는 콘텐츠의 캐시된 복사본을 사용자와 가까이에 유지하여 빠른 검색과 워크로드의 도달 가능성 및 가용성을 높입니다. 

 사용자가 지리적으로 분산된 워크로드의 경우 AWS Global Accelerator는 애플리케이션의 가용성과 성능을 개선하는 데 도움이 됩니다. AWS Global Accelerator는 하나 이상의 AWS 리전에서 호스팅되는 애플리케이션에 대한 고정 진입점 역할을 하는 애니캐스트 정적 IP 주소를 제공합니다. 이렇게 하면 트래픽이 가능한 한 사용자와 가까운 AWS 글로벌 네트워크로 유입되어 워크로드의 도달 가능성과 가용성이 향상됩니다. AWS Global Accelerator는 또한 TCP, HTTP 및 HTTPS 상태 확인을 사용하여 애플리케이션 엔드포인트의 상태를 모니터링합니다. 엔드포인트의 상태 또는 구성이 변경되면 사용자 트래픽이 정상 엔드포인트로 리디렉션되어 사용자에게 최상의 성능과 가용성을 제공합니다. 또한 AWS Global Accelerator에는 독립 네트워크 영역에서 서비스하는 두 개의 정적 IPv4 주소를 사용하여 애플리케이션의 가용성을 높이는 장애 격리 설계가 있습니다. 

 DDoS 공격으로부터 고객을 보호하기 위해 AWS는 AWS Shield Standard를 제공합니다. Shield Standard는 자동으로 활성화되며 SYN/UDP 플러드 및 반사 공격과 같은 일반적인 인프라(계층 3 및 4) 공격으로부터 보호하여 AWS에서 애플리케이션의 고가용성을 지원합니다. 더 정교하고 더 큰 공격(예: UDP 플러드)에 대한 추가 보호를 위해 상태 고갈 공격(예: TCP SYN 플러드)을 방지하고 Amazon Elastic Compute Cloud(Amazon EC2), Elastic Load Balancing(ELB), Amazon CloudFront, AWS Global Accelerator 및 Route 53에서 실행되는 애플리케이션을 보호하기 위해 AWS Shield Advanced 사용을 고려할 수 있습니다. HTTP POST 또는 GET 플러드와 같은 애플리케이션 계층 공격으로부터 보호하려면 AWS WAF를 사용합니다. AWS WAF는 IP 주소, HTTP 헤더, HTTP 본문, URI 문자열, SQL 명령어 삽입 및 교차 사이트 스크립팅 조건을 사용하여 요청을 차단할지 또는 허용할지 결정할 수 있습니다. 

 **구현 단계** 

1.  고가용성 DNS 설정: Amazon Route 53은 가용성과 확장성이 뛰어난 [도메인 이름 시스템(DNS)](https://aws.amazon.com/route53/what-is-dns/) 웹 서비스입니다. Route 53은 사용자 요청을 AWS 또는 온프레미스에서 실행되는 인터넷 애플리케이션에 연결합니다. 자세한 내용은 [Amazon Route 53을 DNS 서비스로 구성](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring.html)을 참조하세요. 

1.  상태 확인 설정: Route 53을 사용할 때 정상 대상만 확인할 수 있는지 확인합니다. [Route 53 상태 확인을 생성하고 DNS 장애 조치를 구성](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html)하여 시작합니다. 상태 확인을 설정할 때 다음 측면을 고려해야 합니다. 

   1. [Amazon Route 53이 상태 확인이 정상인지 확인하는 방법](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-determining-health-of-endpoints.html)

   1. [상태 확인 생성, 업데이트 및 삭제](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-deleting.html)

   1. [상태 확인 상태 모니터링 및 알림 받기](https://docs.aws.amazon.com/)

   1. [Amazon Route 53 DNS 모범 사례](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-monitor-view-status.html)

1. [DNS 서비스를 엔드포인트에 연결합니다. ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-dns.html)

   1.  Elastic Load Balancing을 트래픽의 대상으로 사용하는 경우 로드 밸런서의 리전 엔드포인트를 가리키는 Amazon Route 53을 사용하여 [별칭 레코드](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)를 생성합니다. 별칭 레코드를 생성하는 동안 대상 상태 평가 옵션을 예로 설정합니다. 

   1.  API Gateway가 사용되는 서버리스 워크로드 또는 프라이빗 API의 경우 [Route 53을 사용하여 트래픽을 API Gateway](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html)로 보냅니다. 

1.  콘텐츠 전송 네트워크를 결정합니다. 

   1.  사용자에게 더 가까운 엣지 로케이션을 사용하여 콘텐츠를 제공하려면 [CloudFront가 콘텐츠를 제공하는 방법](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/HowCloudFrontWorks.html)을 이해하는 것부터 시작합니다. 

   1.  [간단한 CloudFront 배포](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.SimpleDistribution.html)로 시작합니다. 그런 다음 CloudFront는 콘텐츠를 제공할 위치와 콘텐츠 제공을 추적 및 관리하는 방법에 대한 세부 정보를 알고 있습니다. CloudFront 배포를 설정할 때 다음 측면을 이해하고 고려해야 합니다. 

      1. [캐싱이 CloudFront 엣지 로케이션에서 작동하는 방식](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio-explained.html)

      1. [CloudFront 캐시에서 직접 제공되는 요청 비율 증가(캐시 적중률)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio.html)

      1. [Amazon CloudFront Origin Shield 사용](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html)

      1. [CloudFront 오리진 장애 조치로 고가용성 최적화](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html)

1.  애플리케이션 계층 보호 설정: AWS WAF는 가용성에 영향을 미치거나 보안을 손상시키거나 과도한 리소스를 소비할 수 있는 일반적인 웹 악용 및 봇으로부터 보호하는 데 도움이 됩니다. 더 깊이 이해하려면 [AWS WAF의 작동 방식](https://docs.aws.amazon.com/waf/latest/developerguide/how-aws-waf-works.html)을 검토하고 애플리케이션 계층 HTTP POST 및 GET 플러드로부터 보호를 구현할 준비가 되면 [AWS WAF 시작하기](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html)를 검토하세요. CloudFront와 함께 AWS WAF를 사용할 수도 있습니다. [AWS WAF가 Amazon CloudFront 기능과 작동하는 방식](https://docs.aws.amazon.com/waf/latest/developerguide/cloudfront-features.html)에 대한 설명서를 참조하세요. 

1.  추가 DDoS 보호 설정: 기본적으로 모든 AWS 고객은 AWS Shield Standard를 사용하여 웹 사이트 또는 애플리케이션을 대상으로 하는 일반적이고 가장 자주 발생하는 네트워크 및 전송 계층 DDoS 공격으로부터 추가 비용 없이 보호를 받습니다. Amazon EC2, Elastic Load Balancing, Amazon CloudFront, AWS Global Accelerator 및 Amazon Route 53에서 실행되는 인터넷 연결 애플리케이션을 추가로 보호하기 위해 [AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-advanced-summary.html)를 고려하고 [DDoS 복원력이 있는 아키텍처의 예](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-resiliency.html)를 검토할 수 있습니다. DDoS 공격으로부터 워크로드와 퍼블릭 엔드포인트를 보호하려면 [AWS Shield Advanced 시작하기](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-ddos.html)를 검토하세요. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [REL10-BP01 워크로드를 여러 위치에 배포](rel_fault_isolation_multiaz_region_system.md) 
+  [REL10-BP02 다중 위치 배포에 적합한 위치 선택](rel_fault_isolation_select_location.md) 
+  [REL11-BP04 복구 중 컨트롤 플레인이 아닌 데이터 영역 사용](rel_withstand_component_failures_avoid_control_plane.md) 
+  [REL11-BP06 이벤트가 가용성에 영향을 미치는 경우 알림 전송](rel_withstand_component_failures_notifications_sent_system.md) 

 **관련 문서:** 
+  [APN 파트너: 네트워킹 계획을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [AWS Marketplace for Network Infrastructure](https://aws.amazon.com/marketplace/b/2649366011)(네트워크 인프라에 대한 AWS Marketplace) 
+  [AWS Global Accelerator란 무엇입니까?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
+  [Amazon CloudFront란 무엇입니까?](https://docs.aws.amazon.com/Amazon/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) 
+ [Network Connectivity capability - Establishing Your Cloud Foundations](https://docs.aws.amazon.com/whitepapers/latest/establishing-your-cloud-foundation-on-aws/network-connectivity-capability.html)(네트워크 연결 기능 - 클라우드 기반 구축)
+ [ What is Amazon API Gateway?](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)(Amazon API Gateway란 무엇입니까?)
+ [What are AWS WAF, AWS Shield, and AWS Firewall Manager?](https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html)(AWS WAF, AWS Shield 및 AWS Firewall Manager란 무엇입니까?)
+ [ What is Amazon Route 53 Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)(Amazon Route53 Application Recovery Controller란 무엇입니까?)
+ [Configure custom health checks for DNS failover](https://docs.aws.amazon.com/apigateway/latest/developerguide/dns-failover.html)(DNS 장애 조치를 위한 사용자 지정 상태 확인 구성)

 **관련 동영상:** 
+ [AWS re:Invent 2022 - Improve performance and availability with AWS Global Accelerator](https://www.youtube.com/watch?v=s5sjsdDC0Lg)(AWS re:Invent 2022 - AWS Global Accelerator로 성능 및 가용성 향상)
+ [AWS re:Invent 2020: Global traffic management with Amazon Route 53](https://www.youtube.com/watch?v=E33dA6n9O7I)(AWS re:Invent 2020: Amazon Route 53을 사용한 글로벌 트래픽 관리)
+ [AWS re:Invent 2022 - Operating highly available Multi-AZ applications](https://www.youtube.com/watch?v=mwUV5skJJ0s)(AWS re:Invent 2022 - 고가용성 다중 AZ 애플리케이션 운영)
+ [AWS re:Invent 2022 - Dive deep on AWS networking infrastructure](https://www.youtube.com/watch?v=HJNR_dX8g8c)(AWS re:Invent 2022 - AWS 네트워킹 인프라에 대해 자세히 알아보기)
+ [AWS re:Invent 2022 - Building resilient networks](https://www.youtube.com/watch?v=u-qamiNgH7Q)(AWS re:Invent 2022 - 복원력이 뛰어난 네트워크 구축)

 **관련 예시:** 
+ [Amazon Route 53 Application Recovery Controller(Route53 ARC)를 사용한 재해 복구](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/)
+ [복원력 워크숍](https://wellarchitectedlabs.com/reliability/)
+ [AWS Global Accelerator 워크숍](https://catalog.us-east-1.prod.workshops.aws/workshops/effb1517-b193-4c59-8da5-ce2abdb0b656/en-US)

# REL02-BP02 클라우드와 온프레미스 환경의 프라이빗 네트워크 간에 이중화된 연결 프로비저닝
<a name="rel_planning_network_topology_ha_conn_private_networks"></a>

 별도로 배포된 프라이빗 네트워크 간에 여러 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 연결을 위한 경로를 하나만 구성 

 **이 모범 사례 수립의 이점:** 클라우드 환경과 기업 또는 온프레미스 환경 간에 이중화된 연결을 구현하면 두 환경 간의 종속 서비스가 서로 안정적으로 통신할 수 있습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  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) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 서브넷 할당 계정 확인
<a name="rel_planning_network_topology_ip_subnet_allocation"></a>

 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 주소 수를 잘못 추정 
+  트래픽이 많은 여러 로드 밸런서를 동일한 서브넷에 배포 

 **이 모범 사례 정립의 이점:** 이렇게 하면 워크로드의 증가를 수용하고 확장 시 가용성을 계속 제공할 수 있습니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  성장, 규정 준수 및 다른 제품과 통합을 수용할 수 있도록 네트워크 계획을 수립합니다. 성장은 과소 평가될 수 있고 규정 준수는 변경될 수 있으며 적절한 계획 없이는 프라이빗 네트워크 연결을 구현하기가 어려울 수 있습니다. 
  +  서비스 요구 사항, 지연 시간, 규정, 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에 추가할 수 있습니다. 그러나 이 경우 주소 범위를 분할될 수 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 다대다 메시보다 허브 앤드 스포크 토폴로지 선호
<a name="rel_planning_network_topology_prefer_hub_and_spoke"></a>

 셋 이상의 네트워크 주소 공간(예: VPC와 온프레미스 네트워크)이 VPC 피어링, AWS Direct Connect 또는 VPN을 통해 연결되는 경우 AWS Transit Gateway가 제공하는 것과 같은 허브 앤드 스포크 모델을 사용합니다. 

 이러한 네트워크가 두 개 뿐인 경우에는 서로 연결하면 되지만 네트워크 수가 증가하면 이 메쉬 기반 연결의 복잡성이 크게 증가합니다. AWS Transit Gateway는 유지 관리가 간편한 허브 앤드 스포크 모델을 제공하므로 여러 네트워크에 걸쳐 트래픽을 라우팅할 수 있습니다. 

![\[AWS Transit Gateway를 사용하지 않는 경우를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/images/without-transit-gateway.png)


![\[AWS Transit Gateway를 사용하는 경우를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/images/with-transit-gateway.png)


 **일반적인 안티 패턴:** 
+  VPC 피어링을 사용하여 2개 이상의 VPC 연결 
+  각 VPC마다 여러 BGP 세션을 설정하여 여러 AWS 리전에 분산된 Virtual Private Cloud(VPC)에 걸쳐 있는 연결 설정 

 **이 모범 사례 정립의 이점:** 네트워크 수가 증가하면 이러한 메시 기반 연결의 복잡성이 크게 증가합니다. AWS Transit Gateway는 유지 관리가 간편한 허브 앤드 스포크 모델을 제공하므로 여러 네트워크에 트래픽을 라우팅할 수 있습니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  다대다 메시보다 허브 앤드 스포크 토폴로지를 선호합니다. 셋 이상의 네트워크 주소 공간(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) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 주소 범위 적용
<a name="rel_planning_network_topology_non_overlap_ip"></a>

 VPN을 통해 피어링되거나 연결된 경우 각 VPC의 IP 주소 범위가 겹치지 않아야 합니다. 마찬가지로, VPC와 온프레미스 환경 간의 IP 주소 충돌 또는 사용하는 다른 클라우드 공급자와의 IP 주소 충돌을 방지해야 합니다. 필요한 경우 프라이빗 IP 주소 범위를 할당할 수 있어야 합니다. 

 IPAM(IP 주소 관리) 시스템을 사용하는 것이 도움이 될 수 있습니다. AWS Marketplace에서 여러 IPAM을 사용할 수 있습니다. 

 **일반적인 안티 패턴:** 
+  VPC에서 온프레미스 또는 회사 네트워크와 동일한 IP 범위 사용 
+  워크로드를 배포하는 데 사용되는 VPC의 IP 범위를 추적하지 않음 

 **이 모범 사례 수립의 이점:** 네트워크를 능동적으로 계획하면 상호 연결된 네트워크에서 동일한 IP 주소가 여러 번 사용되는 것을 방지할 수 있습니다. 이렇게 하면 다른 애플리케이션을 사용하는 워크로드의 일부에서 라우팅 문제가 발생하는 것을 방지할 수 있습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  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) 어플라이언스를 사용할 수 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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) 

# 워크로드 아키텍처
<a name="a-workload-architecture"></a>

**Topics**
+ [REL 3. 워크로드 서비스 아키텍처는 어떻게 설계합니까?](rel-03.md)
+ [REL 4. 분산 시스템에서 장애 방지를 위한 상호 작용은 어떻게 설계합니까?](rel-04.md)
+ [REL 5. 분산 시스템에서 장애 완화 또는 극복을 위한 상호 작용은 어떻게 설계합니까?](rel-05.md)

# REL 3. 워크로드 서비스 아키텍처는 어떻게 설계합니까?
<a name="rel-03"></a>

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 워크로드를 세그먼트화하는 방법 선택
<a name="rel_service_architecture_monolith_soa_microservice"></a>

 워크로드 세그먼트화는 애플리케이션의 복원력 요구 사항을 결정할 때 중요합니다. 되도록 모놀리식 아키텍처는 피해야 합니다. 대신 어떤 애플리케이션 구성 요소를 마이크로 서비스로 나눌 수 있을지 신중하게 고려합니다. 가능한 경우 애플리케이션 요구 사항에 따라 서비스 지향 아키텍처(SOA)와 마이크로 서비스의 결합으로 마무리될 수도 있습니다. 상태 비저장일 수 있는 워크로드는 마이크로 서비스로 배포할 수 있습니다. 

 **원하는 결과:** 워크로드는 지원 가능하고 확장 가능하며 가능한 한 느슨하게 결합되어 있어야 합니다. 

 워크로드를 세그먼트화하는 방법을 선택할 때 복잡성 대비 이점의 균형을 고려합니다. 신제품의 첫 출시에 필요한 것과 처음부터 워크로드를 확장할 때 필요한 것은 다릅니다. 기존 모놀리식을 리팩터링할 때 애플리케이션이 상태 비저장을 향한 해체를 얼마나 잘 지원하는지 고려해야 합니다. 서비스를 더 작은 부분으로 나누면 잘 정의된 소규모 팀에서 이러한 부분을 개발하고 관리할 수 있습니다. 그러나 크기가 작은 서비스는 복잡성을 불러올 수 있고 여기에는 지연 시간 증가, 디버깅 복잡성, 운영 부담 증가가 포함됩니다. 

 **일반적인 안티 패턴:** 
+  [마이크로서비스 *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) 는 원자성 구성 요소의 상호 의존성이 커져 한 구성 요소의 장애가 훨씬 더 큰 장애로 이어져 구성 요소가 모놀리식처럼 경직되고 취약해질 수 있습니다. 

 **이 모범 사례 정립의 이점:** 
+  보다 구체적인 세그먼트를 사용하면 민첩성, 조직의 유연성 및 확장성이 향상됩니다. 
+  서비스 중단의 영향이 감소합니다. 
+  애플리케이션 구성 요소가 원자성이 더 큰 세그먼트화로 지원할 수 있는 여러 가능성 요구 사항을 가질 수 있습니다. 
+  워크로드를 지원하는 팀의 책임이 잘 정의됩니다. 

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 워크로드를 분할하는 방법에 따라 아키텍처 유형 선택 SOA 또는 마이크로서비스 아키텍처(또는 드문 경우 모놀리식 아키텍처)를 선택합니다. 처음에 모놀리식 아키텍처를 선택하더라도, 사용자 채택에 따라 제품을 확장할 때 SOA 또는 마이크로서비스로 변경할 수 있는 모듈식 아키텍처인지 확인해야 합니다. SOA와 마이크로서비스는 더 작게 분할할 수 있기 때문에 현대의 확장 가능하고 안정적인 아키텍처로 선호되지만 특히 마이크로서비스 아키텍처를 배포하는 경우 절충을 고려해야 합니다. 

 한 가지 주요 절충은 분산 컴퓨팅 아키텍처가 구축되므로 사용자 지연 시간 요구 사항을 충족하기가 더 어려워지며, 사용자 상호 작용을 디버그하고 추적하는 과정이 더 복잡해진다는 것입니다. AWS X-Ray을(를) 사용하면 이 문제를 해결할 수 있습니다. 관리 중인 애플리케이션의 수가 증가함에 따라 운영 복잡성이 증가하므로 다수의 독립 구성 요소를 배포해야 한다는 점도 고려해야 합니다. 

![\[모놀리식, 서비스 지향, 마이크로서비스 아키텍처 간 비교 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/images/monolith-soa-microservices-comparison.png)


## 구현 단계
<a name="implementation-steps"></a>
+  애플리케이션을 리팩터링 또는 구축하기에 적절한 아키텍처를 결정합니다. 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). 

 **구현 계획의 작업 수준:** 높음 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [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 특정 비즈니스 도메인 및 기능을 중심으로 서비스 구축
<a name="rel_service_architecture_business_domains"></a>

서비스 지향 아키텍처(SOA)는 비즈니스 요구 사항에 따라 명확하게 정의된 기능으로 서비스를 정의합니다. 마이크로서비스는 도메인 모델과 경계 컨텍스트를 사용하여 비즈니스 컨텍스트 경계를 따라 서비스 경계를 그립니다. 비즈니스 도메인 및 기능에 초점을 맞추면 팀이 서비스에 대한 독립적인 신뢰성 요구 사항을 정의하는 데 도움이 됩니다. 경계 컨텍스트는 비즈니스 로직을 분리하고 캡슐화하므로 팀이 장애 처리 방법을 더 잘 판단할 수 있습니다.

 **원하는 결과:** 엔지니어와 비즈니스 이해 관계자가 공동으로 경계 컨텍스트를 정의하고 이를 사용하여 특정 비즈니스 기능을 충족하는 서비스로 시스템을 설계합니다. 이러한 팀은 이벤트 스토밍과 같은 확립된 관행을 사용하여 요구 사항을 정의합니다. 새로운 애플리케이션은 잘 정의된 경계와 느슨한 결합이 가능하도록 설계됩니다. 기존 모놀리스는 [경계 컨텍스트로](https://martinfowler.com/bliki/BoundedContext.html) 분해되고 시스템 설계는 SOA 또는 마이크로서비스 아키텍처로 이동합니다. 모놀리스를 리팩터링하는 경우에는 버블 컨텍스트 및 모놀리스 분해 패턴과 같은 확립된 접근 방식이 적용됩니다. 

 도메인 지향 서비스는 상태를 공유하지 않는 하나 이상의 프로세스로 실행됩니다. 이들은 수요 변동에 독립적으로 대응하고 도메인별 요구 사항을 고려하여 장애 시나리오를 처리합니다. 

 **일반적인 안티 패턴:** 
+  팀이 특정 비즈니스 도메인 대신 UI 및 UX, 미들웨어 또는 데이터베이스와 같은 특정 기술 도메인을 중심으로 구성됩니다. 
+  애플리케이션이 여러 도메인 책임에 걸쳐 있습니다. 여러 경계 컨텍스트에 걸쳐 있는 서비스는 유지 관리가 더 어렵고 더 많은 테스트 작업이 필요하며 소프트웨어 업데이트에 여러 도메인 팀이 참여해야 할 수 있습니다. 
+  도메인 엔터티 라이브러리와 같은 도메인 종속성은 서비스 간에 공유되므로 한 서비스 도메인을 변경하려면 다른 서비스 도메인도 변경해야 합니다. 
+  서비스 계약과 비즈니스 로직은 엔터티를 공통적이고 일관된 도메인 언어로 표현하지 않으므로 변환 계층이 발생하여 시스템이 복잡해지고 디버깅 작업이 늘어납니다. 

 **이 모범 사례 확립의 이점:** 애플리케이션이 비즈니스 도메인을 기반으로 하는 독립적인 서비스로 설계되며 공통 비즈니스 언어를 사용합니다. 서비스를 독립적으로 테스트 및 배포할 수 있습니다. 서비스가 구현된 도메인에 대한 도메인별 복원력 요구 사항을 충족합니다. 

 **이 모범 사례가 확립되지 않았을 경우의 위험 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 도메인 중심 의사 결정(DDD)은 비즈니스 도메인을 중심으로 소프트웨어를 설계하고 구축하는 기본 접근 방식입니다. 비즈니스 도메인에 초점을 맞춘 서비스를 구축할 때는 기존 프레임워크를 사용하는 것이 좋습니다. 기존 모놀리식 애플리케이션에서 작업할 때 애플리케이션을 서비스로 현대화하는 확립된 기술을 제공하는 분해 패턴을 활용할 수 있습니다. 

![\[도메인 중심 의사 결정의 접근 방식을 보여주는 순서도입니다.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/images/domain-driven-decision.png)


 

## 구현 단계
<a name="implementation-steps"></a>
+  팀은 [이벤트 스토밍](https://serverlessland.com/event-driven-architecture/visuals/event-storming) 워크숍을 통해 이벤트, 명령, 집계, 도메인을 가벼운 스티커 노트 형식으로 빠르게 파악할 수 있습니다. 
+  도메인 컨텍스트에서 도메인 엔터티 및 기능이 형성되면 유사한 기능 및 특성을 공유하는 엔터티가 함께 그룹화되는 [경계 컨텍스트를](https://martinfowler.com/bliki/BoundedContext.html)사용하여 도메인을 서비스로 분할할 수 있습니다. 모델을 컨텍스트로 나누면 마이크로서비스의 경계를 지정하는 방법에 대한 템플릿을 사용할 수 있게 됩니다. 
  +  예를 들어 Amazon.com 웹 사이트 엔터티에는 패키지, 배송, 일정, 가격, 할인 및 통화가 포함될 수 있습니다. 
  +  패키지, 배송, 일정은 배송 컨텍스트로 그룹화되고 가격, 할인, 통화는 가격 컨텍스트로 그룹화됩니다. 
+  [모놀리스를 마이크로서비스로 분해](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html) 는 마이크로서비스 리팩터링 패턴을 설명합니다. 비즈니스 역량, 하위 도메인 또는 트랜잭션별 분해 패턴을 사용하는 것은 도메인 중심 접근 방식과 부합됩니다. 
+  예를 들어 [버블 컨텍스트](https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 등 전술적 기술을 사용하면 사전 재작성 및 DDD에 대한 완전한 약정 없이 기존 또는 레거시 애플리케이션에 DDD를 도입할 수 있습니다. 버블 컨텍스트 접근 방식에서는 새로 정의된 도메인 모델을 외부 영향으로부터 보호하는 [손상 방지 계층](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)또는 서비스 매핑 및 조정을 사용하여 작은 경계 컨텍스트가 설정됩니다. 

 팀이 도메인 분석을 수행하고 엔티티 및 서비스 계약을 정의한 후에는 AWS 서비스를 활용하여 도메인 중심 설계를 클라우드 기반 서비스로 구현할 수 있습니다. 
+  도메인의 비즈니스 규칙을 실행하는 테스트를 정의하여 개발을 시작하십시오. 테스트 기반 개발(TDD)과 동작 기반 개발(BDD)은 팀이 서비스가 비즈니스 문제 해결에 초점을 맞출 수 있도록 도와줍니다. 
+  비즈니스 도메인 요구 사항을 가장 잘 충족하는 [AWS 서비스](https://aws.amazon.com/microservices/) 및 [마이크로서비스 아키텍처를](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)선택합니다. 
  +  [AWS Serverless를](https://aws.amazon.com/serverless/) 사용하면 팀이 서버 및 인프라를 관리하는 대신 특정 도메인 로직에 집중할 수 있습니다. 
  +  [AWS의 컨테이너는](https://aws.amazon.com/containers/) 인프라 관리를 간소화하므로 도메인 요구 사항에 집중할 수 있습니다. 
  +  [목적별 데이터베이스를](https://aws.amazon.com/products/databases/) 통해 도메인 요구 사항을 가장 적합한 데이터베이스 유형에 맞출 수 있습니다. 
+  [AWS에서 육각형 아키텍처 구축에서는](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html) 기능적 요구 사항을 충족한 다음 통합 어댑터를 연결하기 위해 비즈니스 도메인에서 역방향으로 작업하여 서비스에 비즈니스 로직을 구축하는 프레임워크를 설명합니다. AWS 서비스를 통해 인터페이스 세부 정보를 비즈니스 로직과 분리하는 패턴은 팀이 도메인 기능에 집중하고 소프트웨어 품질을 개선하는 데 도움이 됩니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [REL03-BP01 워크로드를 세그먼트화하는 방법 선택](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL03-BP03 API별로 서비스 계약 제공](rel_service_architecture_api_contracts.md) 

 **관련 문서:** 
+ [AWS 마이크로서비스](https://aws.amazon.com/microservices/)
+  [AWS에서 마이크로서비스 구현](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  [모놀리식 유형을 마이크로서비스로 분할하는 방법](https://martinfowler.com/articles/break-monolith-into-microservices.html) 
+  [레거시 시스템으로 둘러싸여 있을 때 DDD 시작](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 
+ [ 도메인 중심 설계: 소프트웨어 중심부의 복잡성 해결 ](https://www.amazon.com/gp/product/0321125215)
+ [AWS에서 육각형 아키텍처 구축에서는 ](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html)
+ [ 모놀리스를 마이크로서비스로 분해 ](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html)
+ [ 이벤트 스토밍 ](https://serverlessland.com/event-driven-architecture/visuals/event-storming)
+ [ 경계 컨텍스트 간 메시지 ](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)
+ [ 마이크로서비스 ](https://www.martinfowler.com/articles/microservices.html)
+ [ 테스트 기반 개발 ](https://en.wikipedia.org/wiki/Test-driven_development)
+ [ 동작 기반 개발 ](https://en.wikipedia.org/wiki/Behavior-driven_development)

 **관련 예시:** 
+ [ 엔터프라이즈 클라우드 네이티브 워크숍 ](https://catalog.us-east-1.prod.workshops.aws/workshops/0466c70e-4216-4352-98d9-5a8af59c86b2/en-US)
+ [AWS에서 클라우드 네이티브 마이크로서비스 설계(DDD/EventStormingWorkshop 중) ](https://github.com/aws-samples/designing-cloud-native-microservices-on-aws/tree/main)

 **관련 도구:** 
+ [AWS 클라우드 데이터베이스 ](https://aws.amazon.com/products/databases/)
+ [AWS의 서버리스 ](https://aws.amazon.com/serverless/)
+ [AWS의 컨테이너는 ](https://aws.amazon.com/containers/)

# REL03-BP03 API별로 서비스 계약 제공
<a name="rel_service_architecture_api_contracts"></a>

서비스 계약은 컴퓨터가 인식할 수 있는 API 정의에 정의된 API 생산자 및 소비자 간의 문서화된 계약입니다. 계약 버전 관리 전략을 사용하면 소비자가 기존 API를 계속 사용하면서 준비가 될 때 애플리케이션을 최신 API로 마이그레이션할 수 있습니다. 생산자 배포는 계약을 준수하는 한 언제든지 가능합니다. 서비스 팀은 원하는 기술 스택을 사용하여 API 계약을 충족할 수 있습니다. 

 **원하는 결과:** 

 **일반적인 안티 패턴:** 서비스 지향 또는 마이크로서비스 아키텍처로 구축된 애플리케이션은 통합 런타임 종속성을 유지하면서 독립적으로 작동할 수 있습니다. API 소비자 또는 생산자에게 배포되는 변경 사항은 양측이 공통 API 계약을 준수하는 경우 전체 시스템의 안정성을 방해하지 않습니다. 서비스 API를 통해 통신하는 구성 요소는 독립적인 기능 릴리스를 수행하거나 런타임 종속성을 업그레이드하거나 서로 거의 또는 전혀 영향을 주지 않고 재해 복구(DR) 사이트로 장애 조치할 수 있습니다. 또한 개별 서비스는 다른 서비스를 함께 확장할 필요 없이 독립적으로 확장하여 리소스 수요를 흡수할 수 있습니다. 
+  강력한 형식의 스키마 없이 서비스 API를 생성합니다. 이를 통해 프로그래밍 방식으로 검증할 수 없는 API 바인딩 및 페이로드를 생성하는 데 사용할 수 없는 API가 생성됩니다. 
+  서비스 계약이 발전할 때 API 소비자가 업데이트 및 릴리스하거나 실패하도록 하는 버전 관리 전략을 채택하지 않습니다. 
+  도메인 컨텍스트 및 언어에서의 통합 실패를 설명하는 대신 기본 서비스 구현의 세부 정보를 유출하는 오류 메시지. 
+  서비스 구성 요소를 독립적으로 테스트할 수 있도록 API 계약을 사용하여 테스트 사례 및 모의 API 구현을 개발하지 않습니다. 

 **이 모범 사례 확립의 이점:** API 서비스 계약을 통해 통신하는 구성 요소로 구성된 분산 시스템은 신뢰성을 향상시킬 수 있습니다. 개발자는 컴파일 중에 형식 검사를 통해 개발 프로세스 초기에 잠재적 문제를 포착하여 요청 및 응답이 API 계약을 준수하고 필수 필드가 있는지 확인할 수 있습니다. API 계약은 API에 대한 명확한 자체 문서화 인터페이스를 제공하고 서로 다른 시스템과 프로그래밍 언어 간에 상호 운용성을 개선합니다. 

 **이 모범 사례가 확립되지 않았을 경우의 위험 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>

 비즈니스 도메인을 식별하고 워크로드 세분화를 결정한 후에는 서비스 API를 개발할 수 있습니다. 먼저 컴퓨터가 인식할 수 있는 API 서비스 계약을 정의한 다음 API 버전 관리 전략을 구현합니다. REST, GraphQL 또는 비동기 이벤트와 같은 일반 프로토콜을 통해 서비스를 통합할 준비가 되면 AWS 서비스를 아키텍처에 통합하여 구성 요소를 강력한 형식의 API 계약과 통합할 수 있습니다. 

 **서비스 API 계약을 위한 AWS 서비스** 

 AWS 서비스(예: [Amazon API Gateway](https://aws.amazon.com/api-gateway/), [AWS AppSync](https://aws.amazon.com/appsync/) 및 [Amazon EventBridge](https://aws.amazon.com/eventbridge/) )를 아키텍처에 통합하여 애플리케이션에서 API 서비스 계약을 사용할 수 있습니다. Amazon API Gateway는 네이티브 AWS 서비스 및 기타 웹 서비스와 직접 통합할 수 있도록 도와줍니다. API Gateway는 [OpenAPI 사양](https://github.com/OAI/OpenAPI-Specification) 및 버전 관리를 지원합니다. AWS AppSync는 관리형 [GraphQL](https://graphql.org/) 엔드포인트로, 쿼리, 변형, 구독을 위한 서비스 인터페이스를 정의하는 GraphQL 스키마를 정의하여 구성합니다. Amazon EventBridge는 이벤트 스키마를 사용하여 이벤트를 정의하고 이벤트에 대한 코드 바인딩을 생성합니다. 

## 구현 단계
<a name="implementation-steps"></a>
+  먼저 API에 대한 계약을 정의합니다. 계약은 API의 기능을 표현할 뿐만 아니라 API 입출력에 대해 강력한 형식의 데이터 객체와 필드를 정의합니다. 
+  API Gateway에서 API를 구성할 때 엔드포인트의 OpenAPI 사양을 가져오고 내보낼 수 있습니다. 
  +  [OpenAPI 정의 가져오기](https://docs.aws.amazon.com/apigateway/latest/developerguide/import-edge-optimized-api.html) API 생성을 단순화하고 [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/) 및 [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/)같은 AWS 코드형 인프라 도구와 통합될 수 있습니다. 
  +  [API 정의 내보내기](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) API 테스트 도구와의 통합을 단순화하고 서비스 소비자에게 통합 사양을 제공합니다. 
+  AWS AppSync로 GraphQL API를 정의하고 관리할 수 있습니다. 이를 위해 [GraphQL 스키마 파일을 정의하여](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) 계약 인터페이스를 생성하고 복잡한 REST 모델, 여러 데이터베이스 테이블 또는 레거시 서비스와의 상호 작용을 단순화합니다. 
+  [AWS Amplify](https://aws.amazon.com/amplify/) 프로젝트는 AWS AppSync와 통합되어 애플리케이션에서 사용할 강력한 형식의 JavaScript 쿼리 파일과 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 테이블용 AWS AppSync AppSync GraphQL 클라이언트 라이브러리를 생성합니다. 
+  Amazon EventBridge에서 서비스 이벤트를 사용하는 경우 이벤트는 스키마 레지스트리에 이미 있거나 OpenAPI Spec으로 정의한 스키마를 준수합니다. 레지스트리에 정의된 스키마를 사용하면 스키마 계약에서 클라이언트 바인딩을 생성하여 코드를 이벤트와 통합할 수도 있습니다. 
+  API 확장 또는 버전 관리. 선택적 필드 또는 필수 필드의 기본값으로 구성할 수 있는 필드를 추가할 때 더 간단한 옵션은 API를 확장하는 것입니다. 
  +  REST 및 GraphQL과 같은 프로토콜에 대한 JSON 기반 계약은 계약 확장에 적합할 수 있습니다. 
  +  SOAP와 같은 프로토콜에 대한 XML 기반 계약은 서비스 소비자와 함께 테스트하여 계약 연장 가능성을 결정해야 합니다. 
+  API 버전을 관리할 때는 단일 코드베이스에서 로직을 유지할 수 있도록 파사드를 사용하여 버전을 지원하는 프록시 버전 관리를 구현하는 것이 좋습니다. 
  +  API Gateway에서는 [요청 및 응답 매핑을](https://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#transforming-request-response-body) 사용하여 새 필드에 기본값을 제공하거나 요청 또는 응답에서 제거된 필드를 제거하는 파사드를 설정하여 계약 변경 사항을 간단하게 흡수할 수 있습니다. 이 접근 방식을 사용하면 기본 서비스가 단일 코드베이스를 유지할 수 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [REL03-BP01 워크로드를 세그먼트화하는 방법 선택](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL03-BP02 특정 비즈니스 도메인 및 기능을 중심으로 서비스 구축](rel_service_architecture_business_domains.md) 
+  [REL04-BP02 느슨하게 결합된 종속성 구현](rel_prevent_interaction_failure_loosely_coupled_system.md) 
+  [REL05-BP03 재시도 호출 제어 및 제한](rel_mitigate_interaction_failure_limit_retries.md) 
+  [REL05-BP05 클라이언트 시간 제한 설정](rel_mitigate_interaction_failure_client_timeouts.md) 

 **관련 문서:** 
+ [ API(애플리케이션 프로그래밍 인터페이스)란? ](https://aws.amazon.com/what-is/api/)
+ [AWS에서 마이크로서비스 구현 ](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.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/)
+ [ OpenAPI에 대한 API Gateway 확장 프로그램 작업 ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-swagger-extensions.html)
+ [ OpenAPI 사양 ](https://github.com/OAI/OpenAPI-Specification)
+ [ GraphQL: 스키마 및 형식 ](https:/graphql.org/learn/schema)
+ [ Amazon EventBridge 코드 바인딩 ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-code-bindings.html)

 **관련 예시:** 
+ [ Amazon API Gateway: OpenAPI를 사용하여 REST API 구성 ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [ OpenAPI를 사용한 Amazon API Gateway-Amazon DynamoDB CRUD 애플리케이션 ](https://serverlessland.com/patterns/apigw-ddb-openapi-crud?ref=search)
+ [ 서버리스 시대의 현대적 애플리케이션 통합 패턴: API Gateway 서비스 통합 ](https://catalog.us-east-1.prod.workshops.aws/workshops/be7e1ee7-b91f-493d-93b0-8f7c5b002479/en-US/labs/asynchronous-request-response-poll/api-gateway-service-integration)
+ [ Amazon CloudFront을 사용하여 헤더 기반 API Gateway 버전 관리 구현 ](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/)
+ [AWS AppSync: 클라이언트 애플리케이션 구축 ](https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app.html#aws-appsync-building-a-client-app)

 **관련 동영상:** 
+ [AWS SAM에서 OpenAPI를 사용하여 API Gateway 관리 ](https://www.youtube.com/watch?v=fet3bh0QA80)

 **관련 도구:** 
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)

# REL 4. 분산 시스템에서 장애 방지를 위한 상호 작용은 어떻게 설계합니까?
<a name="rel-04"></a>

분산 시스템에서 구성 요소(예: 서버 또는 서비스)는 통신 네트워크를 사용하여 상호 연결됩니다. 워크로드는 이러한 네트워크에서 데이터 손실 또는 지연 시간이 발생하더라도 안정적으로 작동해야 합니다. 분산 시스템의 구성 요소는 다른 구성 요소나 워크로드에 부정적인 영향을 미치지 않는 방식으로 작동해야 합니다. 여기에 나온 모범 사례는 장애를 방지하고 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 필요한 분산 시스템의 종류 식별
<a name="rel_prevent_interaction_failure_identify"></a>

 하드 실시간 분산 시스템에서는 응답을 동기식으로 신속하게 제공해야 하지만, 소프트 실시간 시스템에서는 응답하기 위한 몇 분 이상의 여유가 주어집니다. 오프라인 시스템은 배치 또는 비동기식 처리를 통해 응답을 처리합니다. 하드 실시간 분산 시스템은 안정성 요구 사항이 가장 엄격합니다. 

 요청/응답 서비스로 알려진 높은 수준의 실시간 분산 시스템과 관련된 문제가 [분산 시스템의 가장 어려운 문제라고](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 할 수 있습니다. 이 문제가 어려운 이유는 언제 도착할지 예상할 수 없는 요청에 대해 신속하게 응답을 제공해야 하기 때문입니다(예: 응답이 올 때까지 앞에서 대기하는 고객). 예를 들어 프런트엔드 웹 서버, 주문 파이프라인, 신용 카드 거래, 모든 AWS API 및 전화 통신이 여기에 포함됩니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  필요한 분산 시스템의 종류를 식별합니다. 분산 시스템에는 지연 시간, 확장 및 축소, 네트워킹 API에 대한 이해, 데이터 마샬링 및 마샬링 취소와 알고리즘(예: Paxos)의 복잡성과 같은 당면 과제가 있었습니다. 시스템이 커지고 분산화가 확대되자, 이론적으로는 극단적 사례에 해당했던 문제들이 주기적으로 발생하기 시작했습니다. 
  +  [Amazon Builders' Library: 분산 시스템의 도전 과제](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 
    +  하드 실시간 분산 시스템에서는 응답이 동기식으로 신속하게 제공되어야 합니다. 
    +  소프트 실시간 시스템은 상대적으로 응답 시간의 여유가 있어 분 단위 이상의 응답 시간이 허용됩니다. 
    +  오프라인 시스템은 배치 또는 비동기식 처리를 통해 응답을 처리합니다. 
    +  하드 실시간 분산 시스템은 안정성 요구 사항이 가장 엄격합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 느슨하게 결합된 종속성 구현
<a name="rel_prevent_interaction_failure_loosely_coupled_system"></a>

 대기열 처리 시스템, 스트리밍 시스템, 워크플로 및 로드 밸런서와 같은 종속성은 느슨하게 결합됩니다. 느슨한 결합은 한 구성 요소의 동작을 다른 종속 구성 요소에서 분리하여 복원력 및 민첩성을 높이는 데 도움이 됩니다. 

 밀결합된 시스템에서는 한 구성 요소를 변경하면 해당 구성 요소를 사용하는 다른 구성 요소도 변경해야 할 수 있으므로 결과적으로 모든 구성 요소의 성능이 저하될 수 있습니다. 느슨한 결합에서는 이 종속성이 분리되므로 종속 구성 요소는 버전이 지정되고 게시된 인터페이스만 알면 됩니다. 종속성 간에 느슨한 결합을 구현하면 한 구성 요소의 장애가 다른 구성 요소에 영향을 미치지 않도록 분리됩니다. 

 느슨한 결합을 사용하면 다른 종속 구성 요소에 미치는 위험을 최소화하면서 구성 요소의 코드를 수정하거나 기능을 추가할 수 있습니다. 또한 구성 요소 수준에서 세분화된 복원력을 지원하므로 종속성의 기본 구현을 스케일 아웃하거나 변경할 수도 있습니다. 

 느슨한 결합을 통해 복원력을 추가로 개선하려면 가능한 경우 구성 요소가 비동기식으로 상호 작용하도록 합니다. 이 모델은 즉각적인 응답이 필요하지 않고 요청이 등록되었다는 확인으로 충분한 상호 작용에 적합합니다. 이러한 상호 작용에는 이벤트를 생성하는 구성 요소와 이벤트를 사용하는 구성 요소가 포함됩니다. 두 구성 요소는 직접적인 지점 간 상호 작용을 통해 통합되지 않고 일반적으로 내구성이 있는 중간 스토리지 계층(예: Amazon SQS 대기열, Amazon Kinesis 또는 AWS Step Functions와 같은 스트리밍 데이터 플랫폼)을 통해 통합됩니다. 

![\[Diagram showing dependencies such as queuing systems and load balancers are loosely coupled\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/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를 직접 호출합니다. 
+  공유 데이터를 사용하여 밀결합합니다. 느슨하게 결합된 시스템은 공유 데이터베이스나 다른 형태의 밀결합된 데이터 스토리지를 통한 데이터 공유를 피해야 합니다. 그러지 않으면 밀결합이 다시 도입되어 확장성이 저해될 수 있습니다. 
+  배압을 무시합니다. 워크로드는 구성 요소가 동일한 속도로 데이터를 처리할 수 없을 때 들어오는 데이터의 속도를 늦추거나 중지할 수 있어야 합니다. 

 **이 모범 사례 확립의 이점:** 느슨한 결합은 한 구성 요소의 동작을 다른 종속 구성 요소에서 분리하여 복원력 및 민첩성을 높이는 데 도움이 됩니다. 한 구성 요소에서 발생한 장애는 다른 구성 요소로부터 격리됩니다. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 느슨하게 결합된 종속성을 구현합니다. 느슨하게 결합된 애플리케이션을 구축할 수 있는 솔루션은 다양합니다. 여기에는 완전관리형 대기열, 자동화된 워크플로, 이벤트 대응, API 등을 구현하기 위한 서비스가 포함됩니다. 이러한 서비스는 구성 요소의 동작을 다른 구성 요소로부터 분리하고 복원력과 민첩성을 높이는 데 도움이 될 수 있습니다. 
+  **이벤트 기반 아키텍처 구축:** [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)는 느슨하게 결합되고 분산된 이벤트 기반 아키텍처를 구축하는 데 도움이 됩니다. 
+  **분산 시스템에서 대기열 구현:** [Amazon Simple Queue Service(Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)를 사용하여 분산 시스템을 통합하고 분리할 수 있습니다. 
+  **구성 요소를 마이크로서비스로 컨테이너화:** [마이크로서비스](https://aws.amazon.com/microservices/)를 사용하면 잘 정의된 API를 통해 통신하는 작고 독립적인 구성 요소로 구성된 애플리케이션을 구축할 수 있습니다. [(Amazon Elastic Container Service)Amazon ECS, ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)[Amazon Elastic Kubernetes Service(Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)를 사용하면 컨테이너를 더 빠르게 시작할 수 있습니다. 
+  **Step Functions로 워크플로 관리:** [Step Functions](https://aws.amazon.com/step-functions/getting-started/)는 여러 AWS 서비스를 유연한 워크플로로 조율할 수 있도록 도와줍니다. 
+  **게시-구독(pub/sub) 메시징 아키텍처 활용:** [Amazon Simple Notification Service(Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)는 게시자(생산자)가 구독자(소비자)에게 메시지를 전달하도록 합니다. 

### 구현 단계
<a name="implementation-steps"></a>
+  이벤트 기반 아키텍처의 구성 요소는 이벤트로 인해 시작됩니다. 이벤트는 사용자가 장바구니에 품목을 추가하는 것과 같이 시스템에서 발생하는 작업입니다. 작업이 성공하면 시스템의 다음 구성 요소를 작동시키는 이벤트가 생성됩니다. 
  + [ Building Event-driven Applications with Amazon EventBridge ](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/)
  + [AWS re:Invent 2022 - Designing Event-Driven Integrations using Amazon EventBridge ](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+  분산 메시징 시스템에는 대기열 기반 아키텍처를 위해 구현해야 하는 세 가지 주요 부분이 있습니다. 분산 시스템의 구성 요소, 분리에 사용되는 대기열(Amazon SQS 서버에 분산됨), 대기열의 메시지입니다. 일반적인 시스템에는 메시지를 대기열로 보내는 생산자와 대기열에서 메시지를 수신하는 소비자가 있습니다. 대기열은 중복성을 위해 여러 Amazon SQS 서버에 메시지를 저장합니다. 
  + [ Basic Amazon SQS architecture ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
  + [ Send Messages Between Distributed Applications with Amazon Simple Queue Service ](https://aws.amazon.com/getting-started/hands-on/send-messages-distributed-applications/)
+  마이크로서비스를 잘 활용하면 개별 팀이 느슨하게 결합된 구성 요소를 관리하므로 유지 관리 가능성과 확장성이 향상됩니다. 또한 변경 시 동작을 단일 구성 요소로 분리할 수 있습니다. 
  + [AWS에서 마이크로서비스 구현 ](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
  + [ 아키텍트를 시작하겠습니다\$1 Architecting microservices with containers ](https://aws.amazon.com/blogs/architecture/lets-architect-architecting-microservices-with-containers/)
+  AWS Step Functions를 사용하면 분산 애플리케이션을 구축하고, 프로세스를 자동화하고, 마이크로서비스를 오케스트레이션하는 등의 작업을 수행할 수 있습니다. 여러 구성 요소를 자동화된 워크플로로 오케스트레이션하면 애플리케이션의 종속성을 분리할 수 있습니다. 
  + [ Create a Serverless Workflow with AWS Step Functions and AWS Lambda](https://aws.amazon.com/tutorials/create-a-serverless-workflow-step-functions-lambda/)
  + [AWS Step Functions 시작하기 ](https://aws.amazon.com/step-functions/getting-started/)

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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) 
+ [ Break up with your monolith ](https://pages.awscloud.com/break-up-your-monolith.html)
+ [ Orchestrate Queue-based Microservices with AWS Step Functions and Amazon SQS ](https://aws.amazon.com/tutorials/orchestrate-microservices-with-message-queues-on-step-functions/)
+ [ Basic Amazon SQS architecture ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [대기열 기반 아키텍처](https://docs.aws.amazon.com/wellarchitected/latest/high-performance-computing-lens/queue-based-architecture.html)

 **관련 동영상:** 
+  [AWS New York Summit 2019: Intro to Event-driven Architectures and 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 (includes loose coupling, constant work, static stability)](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 (API304)](https://youtu.be/2rikdPIFc_Q) 
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda ](https://www.youtube.com/watch?v=2rikdPIFc_Q)
+ [AWS re:Invent 2022 - Designing event-driven integrations using Amazon EventBridge ](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ [AWS re:Invent 2017: Elastic Load Balancing Deep Dive and Best Practices ](https://www.youtube.com/watch?v=9TwkMMogojY)

# REL04-BP03 일정한 작업 수행
<a name="rel_prevent_interaction_failure_constant_work"></a>

 대규모 로드가 급속도로 변경되면 시스템에서 장애가 발생할 수 있습니다. 예를 들어 서버 수천 대의 상태를 모니터링하는 상태 확인을 수행하는 워크로드의 경우 매번 동일한 크기의 페이로드(현재 상태의 전체 스냅샷)를 전송해야 합니다. 장애가 전혀 발생하지 않는 경우나, 또는 모든 서버에서 발생하는 경우와 무관하게 상태 확인 시스템은 대규모의 급속한 변경 없이 일정한 작업을 처리합니다. 

 예를 들어 상태 확인 시스템이 100,000개의 서버를 모니터링하는 경우 서버 장애율이 정상적으로 낮을 때는 서버에 가해지는 로드가 작습니다. 그러나 중대한 이벤트로 인해 이러한 서버의 절반이 비정상 상태가 될 때 상태 확인 시스템에서 알림 시스템을 업데이트하고 클라이언트로 상태를 전달하려면 상태 확인 시스템이 과부하가 될 수 있습니다. 그렇기 때문에 상태 확인 시스템에서는 매번 현재 상태의 전체 스냅샷을 전송하는 것이 낫습니다. 100,000개의 서버 상태(각각 비트로 표시됨)는 12.5KB 페이로드에 불과합니다. 장애가 발생한 서버가 없든 모든 서버에서 장애가 발생하든 상태 확인 시스템은 일정한 작업을 처리하므로 대규모의 급속한 변경이 시스템 안정성에 위협이 되지 않습니다. 이 방법으로 Amazon Route 53이 엔드포인트(예: IP 주소)에 대한 상태 확인을 수행하여 최종 사용자가 어떻게 엔드포인트에 라우팅되는지 판단합니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 낮음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  로드에 대규모의 급격한 변화가 있을 때 시스템에서 장애가 발생하지 않도록 일정하게 작업을 수행합니다. 
+  느슨한 결합 종속성을 구현합니다. 대기열 처리 시스템, 스트리밍 시스템, 워크플로 및 로드 밸런서와 같은 종속성은 약결합됩니다. 느슨한 결합은 한 구성 요소의 동작을 다른 종속 구성 요소에서 분리하여 복원력 및 민첩성을 높이는 데 도움이 됩니다. 
  +  [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만 개의 서버를 모니터링하는 상태 확인 시스템의 예에서 성공 또는 실패 횟수와 관계없이 페이로드 크기가 일정하게 유지되도록 워크로드를 엔지니어링합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 모든 응답의 멱등성 유지
<a name="rel_prevent_interaction_failure_idempotent"></a>

 멱등성이 있는 서비스는 각 요청이 정확히 한 번만 완료되도록 합니다. 이렇게 하면 다수의 동일한 요청에서 단일 요청과 동일한 결과가 나옵니다. 멱등성이 있는 서비스를 사용하면 클라이언트가 요청이 오류로 여러 번 처리될 것이라는 염려 없이 재시도를 시행할 수 있습니다. 이를 위해 클라이언트는 멱등성 토큰을 사용하여 API 요청을 실행할 수 있으며 요청이 반복될 때마다 동일한 토큰이 사용됩니다. 멱등성이 있는 서비스 API는 토큰을 사용하여 요청이 처음 완료되었을 때 반환된 응답과 동일한 응답을 반환합니다. 

 분산 시스템에서 작업을 최대 한 번(클라이언트가 한 번만 요청) 또는 최소 한 번(클라이언트가 성공 확인을 수신할 때까지 계속 요청) 수행하기는 쉽습니다. 그러나 작업의 멱등성을 보장하기는 어렵습니다. 즉 작업을 *정확히* 한 번 수행하여 다수의 동일한 요청에서 단일 요청과 동일한 결과를 얻기는 어렵습니다. API에서 멱등성 토큰을 사용하면 서비스가 중복 레코드를 생성하지 않고 부작용 없이 변경 요청을 한 번 이상 수신할 수 있습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  모든 응답의 멱등성을 유지합니다. 멱등성이 있는 서비스는 각 요청이 정확히 한 번만 완료되도록 합니다. 이렇게 하면 다수의 동일한 요청에서 단일 요청과 동일한 결과가 나옵니다. 
  +  클라이언트는 멱등성 토큰을 사용하여 API 요청을 실행할 수 있으며 요청이 반복될 때마다 동일한 토큰이 사용됩니다. 멱등성이 있는 서비스 API는 토큰을 사용하여 요청이 처음 완료되었을 때 반환된 응답과 동일한 응답을 반환합니다. 
    +  [Amazon EC2: Ensuring Idempotency(멱등성 보장)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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. 분산 시스템에서 장애 완화 또는 극복을 위한 상호 작용은 어떻게 설계합니까?
<a name="rel-05"></a>

분산 시스템에서 구성 요소(예: 서버 또는 서비스)는 통신 네트워크를 사용하여 상호 연결됩니다. 워크로드는 이러한 네트워크에서 데이터 손실 또는 지연 시간이 발생하더라도 안정적으로 작동해야 합니다. 분산 시스템의 구성 요소는 다른 구성 요소나 워크로드에 부정적인 영향을 미치지 않는 방식으로 작동해야 합니다. 이러한 모범 사례를 준수하면 워크로드가 스트레스 또는 장애를 견디고, 더 빠르게 이를 복구하며, 이러한 장애의 영향을 완화할 수 있습니다. 그러면 결과적으로 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 name="rel_mitigate_interaction_failure_graceful_degradation"></a>

애플리케이션 구성 요소는 종속성을 사용할 수 없게 되더라도 핵심 기능을 계속 수행해야 합니다. 약간 오래된 데이터, 대체 데이터를 제공하거나 데이터를 제공하지 않을 수도 있습니다. 이를 통해 핵심 비즈니스 가치를 제공하는 동시에 지역화된 장애로 인한 전체 시스템 기능의 방해를 최소한으로 줄일 수 있습니다.

 **원하는 결과:** 구성 요소의 종속성이 비정상 상태인 경우에도 구성 요소 자체가 성능이 저하된 방식으로 작동할 수 있습니다. 구성 요소의 장애 모드는 정상 작동으로 간주되어야 합니다. 워크플로는 이러한 장애가 완전한 장애로 이어지지 않거나 최소한 예측 가능하고 복구 가능한 상태로 이어지도록 설계되어야 합니다. 

 **일반적인 안티 패턴:** 
+  필요한 핵심 비즈니스 기능을 식별하지 못합니다. 종속성 실패 시에도 구성 요소가 작동하는지 테스트하지 않습니다. 
+  오류가 발생 시 또는 여러 종속성 중 하나만 사용할 수 없고 일부 결과가 여전히 반환될 수 있는 경우 데이터를 제공하지 않습니다. 
+  트랜잭션이 부분적으로 실패하면 일관되지 않은 상태가 발생합니다. 
+  중앙 파라미터 스토어에 액세스할 수 있는 다른 방법이 없습니다. 
+  새로 고침 실패로 인한 결과를 고려하지 않고 로컬 상태를 무효화하거나 비웁니다. 

 **이 모범 사례 확립의 이점:** 단계적 성능 저하를 통해 시스템 전체의 가용성이 향상되고 장애가 발생하더라도 가장 중요한 기능의 작동을 유지할 수 있습니다. 

 **이 모범 사례가 확립되지 않았을 경우의 위험 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 단계적 성능 저하를 구현하면 종속성 장애가 구성 요소 기능에 미치는 영향을 최소화하는 데 도움이 됩니다. 구성 요소가 종속성 장애를 감지하고 다른 구성 요소 또는 고객에게 미치는 영향을 최소화하는 방식으로 문제를 해결하는 것이 가장 좋습니다. 

 단계적 성능 저하를 고려하는 설계란 종속성 설계 시 잠재적인 장애 모드를 고려하는 것을 의미합니다. 각 장애 모드에서 구성 요소의 가장 중요한 기능을 대부분 또는 최소한 호출자 또는 고객에게 제공할 수 있는 방법을 마련하십시오. 이러한 고려 사항은 테스트 및 검증이 가능한 추가 요구 사항이 될 수 있습니다. 이상적으로는 구성 요소가 하나 이상의 종속성이 실패하더라도 적절한 방식으로 핵심 기능을 수행할 수 있어야 합니다. 

 이것은 기술적 논의인 만큼이나 비즈니스 논의이기도 합니다. 모든 비즈니스 요구 사항은 중요하며 가능하면 충족되어야 합니다. 그러나 모든 요구 사항이 충족되지 않을 때 어떤 일이 일어날지 묻는 것은 여전히 의미가 있습니다. 시스템은 가용성 및 일관성을 유지하도록 설계될 수 있지만 한 가지 요구 사항을 이루지 못하는 상황에서 어느 것이 더 중요할까요? 결제 처리의 경우 일관성이 필요할 수 있습니다. 실시간 애플리케이션의 경우 가용성이 필요할 수 있습니다. 고객 대상 웹 사이트의 경우 고객의 기대에 따라 답이 달라질 수 있습니다. 

 즉, 구성 요소의 요구 사항과 그 핵심 기능으로 간주되어야 하는 요소에 따라 달라진다는 의미입니다. 예를 들면 다음과 같습니다. 
+  전자 상거래 웹 사이트는 맞춤형 추천, 최고 순위 제품, 고객 주문 상태 등 다양한 시스템의 데이터를 랜딩 페이지에 표시할 수 있습니다. 한 업스트림 시스템에 장애가 발생하더라도 고객에게 오류 페이지를 표시하는 대신 다른 모든 데이터를 표시하는 것이 좋습니다. 
+  배치 쓰기를 수행하는 구성 요소는 개별 작업 중 하나가 실패하더라도 배치를 계속 처리할 수 있습니다. 재시도 메커니즘을 구현하는 것은 간단해야 합니다. 이렇게 하려면 어떤 작업이 성공했는지, 어떤 작업이 실패했는지, 왜 실패했는지에 대한 정보를 호출자에게 반환하거나 실패한 요청을 DLQ(Dead Letter Queue)에 넣어 비동기 재시도를 구현하면 됩니다. 실패한 작업에 대한 정보도 기록해야 합니다. 
+  트랜잭션을 처리하는 시스템은 개별 업데이트가 모두 실행되었는지 또는 전혀 실행되지 않았는지 확인해야 합니다. 분산 트랜잭션의 경우 동일한 트랜잭션의 이후 작업이 실패할 경우 Saga 패턴을 사용하여 이전 작업을 롤백할 수 있습니다. 여기서 핵심은 일관성을 유지하는 것입니다. 
+  시간이 중요한 시스템은 적시에 응답하지 않는 종속성을 처리할 수 있어야 합니다. 이러한 경우 회로 차단기 패턴을 사용할 수 있습니다. 종속성의 응답이 시간 제한하기 시작하면 시스템은 추가 호출이 이루어지지 않는 폐쇄 상태로 전환될 수 있습니다. 
+  애플리케이션은 파라미터 스토어에서 파라미터를 읽을 수 있습니다. 기본 파라미터 세트를 사용하여 컨테이너 이미지를 생성하고 파라미터 스토어를 사용할 수 없는 경우에 이러한 이미지를 사용하는 것이 유용할 수 있습니다. 

 구성 요소 장애 시 사용되는 경로는 테스트가 필요하며 기본 경로보다 훨씬 간단해야 합니다. 일반적으로 [폴백 전략은 피해야 합니다.](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/)같은 AWS 코드형 인프라 도구와 통합될 수 있습니다. 

## 구현 단계
<a name="implementation-steps"></a>

 외부 및 내부 종속성을 식별합니다. 종속성에서 어떤 종류의 장애가 발생할 수 있는지 고려합니다. 이러한 장애 발생 시 업스트림 및 다운스트림 시스템과 고객에게 미치는 부정적인 영향을 최소화할 수 있는 방법을 강구합니다. 

 다음은 종속성 목록 및 장애 발생 시 단계적으로 성능을 저하시키는 방법입니다. 

1.  **종속성의 부분적 실패:** 구성 요소가 다운스트림 시스템에 여러 요청을 보낼 수 있습니다. 이때 한 시스템에 여러 요청을 보내거나 여러 시스템에 한 번 요청할 수 있습니다. 비즈니스 상황에 따라 이를 처리하는 여러 방법이 적절할 수 있습니다(자세한 내용은 구현 지침의 이전 예시 참조). 

1.  **다운스트림 시스템이 높은 부하로 인해 요청을 처리할 수 없습니다.** 다운스트림 시스템에 대한 요청이 지속적으로 실패하는 경우 계속 재시도하는 것은 의미가 없습니다. 이로 인해 이미 과부하된 시스템에 추가 부하가 발생하고 복구가 더 어려워질 수 있습니다. 여기서 회로 차단기 패턴을 활용하여 다운스트림 시스템에 대한 호출 실패를 모니터링할 수 있습니다. 많은 수의 호출이 실패하면 다운스트림 시스템으로의 추가 요청 전송이 중단되고 다운스트림 시스템을 다시 사용할 수 있는지 여부를 테스트하기 위한 호출이 가끔 전송됩니다. 

1.  **파라미터 스토어를 사용할 수 없습니다.** 파라미터 스토어를 변환하기 위해 컨테이너 또는 머신 이미지에 포함된 소프트 종속성 캐싱 또는 정상적인 기본값을 사용할 수 있습니다. 참고로 이러한 기본값은 최신 상태로 유지되어야 하며 테스트 모음에 포함되어야 합니다. 

1.  **모니터링 서비스 또는 기타 비기능 종속성을 사용할 수 없습니다.** 구성 요소가 간헐적으로 로그, 지표 또는 추적을 중앙 모니터링 서비스로 보낼 수 없는 경우에도 비즈니스 기능을 평소처럼 실행하는 것이 가장 좋은 경우가 많습니다. 오랫동안 자동으로 지표를 로깅 또는 푸시하지 않는 것은 허용되지 않는 경우가 많습니다. 또한 일부 사용 사례에서는 규정 준수 요구 사항을 충족하기 위해 완전한 감사 항목이 필요할 수 있습니다. 

1.  **관계형 데이터베이스의 프라이머리 인스턴스를 사용하지 못할 수 있습니다.** 거의 모든 관계형 데이터베이스와 마찬가지로 Amazon Relational Database Service는 프라이머리 라이터 인스턴스를 하나만 가질 수 있습니다. 이로 인해 쓰기 워크로드에 단일 장애 지점이 생기고 규모 조정이 더 어려워집니다. 고가용성을 위한 다중 AZ 구성을 사용하거나 더 나은 규모 조정을 위해 Amazon Aurora 서버리스를 사용하면 이러한 문제를 부분적으로 완화할 수 있습니다. 고가용성 요구 사항이 매우 높은 경우 프라이머리 라이터에게 전혀 의존하지 않는 것이 좋습니다. 읽기만 하는 쿼리의 경우 읽기 전용 복제본을 사용할 수 있습니다. 이 복제본은 중복성과 스케일 업뿐만 아니라 스케일 아웃도 가능합니다. 예를 들어 Amazon Simple Queue Service 대기열에 쓰기를 버퍼링하여 프라이머리를 일시적으로 사용할 수 없는 경우에도 고객의 쓰기 요청을 계속 수락할 수 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 요청 제한
<a name="rel_mitigate_interaction_failure_throttle_requests"></a>

예상치 못한 수요 증가로 인한 리소스 고갈을 완화하기 위해 요청을 제한합니다. 제한 속도 이하의 요청은 처리되지만 정의된 한도를 초과한 요청은 거부되고 요청이 거부되었음을 알리는 메시지가 표시됩니다. 

 **원하는 결과:** 갑작스러운 고객 트래픽 증가, 플러딩 공격 또는 대량 재시도로 인한 대규모 볼륨 급증이 요청 제한을 통해 완화되므로 워크로드가 지원되는 요청 볼륨을 정상적으로 계속 처리할 수 있습니다. 

 **일반적인 안티 패턴:** 
+  API 엔드포인트 제한이 구현되지 않거나 예상 볼륨을 고려하지 않고 기본값으로 유지됩니다. 
+  API 엔드포인트가 로드 테스트되지 않거나 제한 한도가 테스트되지 않습니다. 
+  요청 크기 또는 복잡성을 고려하지 않고 요청 속도를 제한합니다. 
+  최대 요청 속도 또는 최대 요청 크기를 테스트하지만 둘 다 테스트하지는 않습니다. 
+  리소스가 테스트에서 설정된 한도대로 프로비저닝되지 않습니다. 
+  사용 계획이 애플리케이션 간(A2A) API 소비자를 위해 구성되거나 고려되지 않습니다. 
+  수평적으로 조정되는 대기열 소비자에게는 최대 동시성 설정이 구성되어 있지 않습니다. 
+  IP 주소별 속도 제한이 구현되지 않았습니다. 

 **이 모범 사례 확립의 이점:** 제한 한도를 설정한 워크로드는 예상치 못한 볼륨 급증 상황에서도 정상적으로 작동하고 수락된 요청 로드를 성공적으로 처리할 수 있습니다. API 및 대기열에 대한 요청이 갑자기 또는 지속적으로 급증하면 요청이 제한되어 요청 처리 리소스가 소진되지 않습니다. 속도 제한은 개별 요청자를 제한하므로 단일 IP 주소 또는 API 소비자로부터 오는 대량의 트래픽이 리소스를 소진하여 다른 소비자에게 영향을 미치는 일이 없습니다. 

 **이 모범 사례가 확립되지 않았을 경우의 위험 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 서비스는 알려진 용량의 요청을 처리하도록 설계되어야 합니다. 이 용량은 부하 테스트를 통해 설정할 수 있습니다. 요청 도착 속도가 한도를 초과할 경우 적절한 응답은 요청이 제한되었다는 신호를 보냅니다. 그러면 소비자가 오류를 처리하고 나중에 다시 시도할 수 있습니다. 

 서비스에 제한 구현이 필요한 경우 요청마다 토큰이 계산되는 토큰 버킷 알고리즘을 구현하는 것이 좋습니다. 토큰은 초당 제한 속도로 다시 충전되고 요청당 토큰 1개씩 비동기적으로 사용됩니다. 

![\[토큰 버킷 알고리즘을 설명하는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/images/token-bucket-algorithm.png)


 

 [Amazon API Gateway는](https://aws.amazon.com/api-gateway/) 계정 및 리전 한도에 따라 토큰 버킷 알고리즘을 구현하며 사용 계획을 통해 클라이언트별로 구성할 수 있습니다. 또한 [Amazon Simple Queue Service(Amazon SQS)](https://aws.amazon.com/sqs/) 및 [Amazon Kinesis는](https://aws.amazon.com/kinesis/) 요청을 버퍼링하여 요청 속도를 낮추고 처리 가능한 요청에 대해 더 높은 제한 속도를 허용할 수 있습니다. 마지막으로 [AWS WAF를](https://aws.amazon.com/waf/) 사용하여 비정상적으로 높은 부하를 유발하는 특정 API 소비자를 제한하는 속도 제한을 구현할 수 있습니다. 

## 구현 단계
<a name="implementation-steps"></a>

 API Gateway에서 API에 대한 제한 한도를 구성하고 제한이 초과되면 `429 Too Many Requests` 오류를 반환할 수 있습니다. AWS WAF를 AWS AppSync 및 API Gateway 엔드포인트와 함께 사용하여 IP 주소별 속도 제한을 활성화할 수 있습니다. 또한 시스템에서 비동기 처리를 허용할 수 있는 경우 메시지를 대기열 또는 스트림에 배치하여 서비스 클라이언트에 대한 응답 속도를 높일 수 있으며, 이를 통해 제한 속도를 높일 수 있습니다. 

 비동기 처리에서는 Amazon SQS를 AWS Lambda용 이벤트 소스로 구성한 경우 [최대 동시성을 구성하여](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) 높은 이벤트 속도가 워크로드 또는 계정의 다른 서비스에 필요한 사용 가능한 계정 동시 실행 할당량을 소모하지 않도록 할 수 있습니다. 

 API Gateway는 토큰 버킷의 관리형 구현을 제공하지만 API Gateway를 사용할 수 없는 경우 서비스용 토큰 버킷의 언어별 오픈 소스 구현(리소스의 관련 예제 참조)을 활용할 수 있습니다. 
+  리전별 계정 수준, 단계별 API 및 사용 계획 수준별 API 키에서 [API Gateway 제한 한도를](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 이해하고 구성합니다. 
+  플러드로부터 보호하고 악성 IP를 차단하기 위해 [AWS WAF 속도 제한 규칙을](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/) API Gateway 및 AWS AppSync 엔드포인트에 적용합니다. A2A 소비자를 위한 AWS AppSync API 키에도 속도 제한 규칙을 구성할 수 있습니다. 
+  AWS AppSync API에 속도 제한보다 많은 제한 제어가 필요한지 고려하고 필요한 경우 AWS AppSync 엔드포인트 앞에 API Gateway를 구성합니다. 
+  Amazon SQS 대기열이 Lambda 대기열 소비자를 위한 트리거로 설정된 경우 [최대 동시성을](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) 서비스 수준 목표를 충족할 만큼 충분히 처리하지만 다른 Lambda 함수에 영향을 미치는 동시성 한도를 소비하지 않는 값으로 설정합니다. Lambda에서 대기열을 사용할 때는 동일한 계정 및 리전의 다른 Lambda 함수에 예약된 동시성을 설정하는 것이 좋습니다. 
+  Amazon SQS 또는 Kinesis에 대한 기본 서비스 통합과 함께 API Gateway를 사용하여 요청을 버퍼링합니다. 
+  API Gateway를 사용할 수 없는 경우 언어별 라이브러리를 참조하여 워크로드에 토큰 버킷 알고리즘을 구현합니다. 예제 섹션을 확인하고 직접 조사하여 적합한 라이브러리를 찾으십시오. 
+  설정하려는 제한 또는 증가를 허용하려는 제한을 테스트하고 테스트된 제한을 문서화합니다. 
+  테스트에서 설정한 범위를 초과하여 제한을 늘리지 마십시오. 제한을 늘릴 때는 증가를 적용하기 전에 프로비저닝된 리소스가 이미 테스트 시나리오의 리소스와 동일하거나 더 큰지 확인합니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [REL04-BP03 일정한 작업 수행](rel_prevent_interaction_failure_constant_work.md) 
+  [REL05-BP03 재시도 호출 제어 및 제한](rel_mitigate_interaction_failure_limit_retries.md) 

 **관련 문서:** 
+  [Amazon API Gateway: 처리량 향상을 위해 API 요청 제한](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 
+ [AWS WAF: 속도 기반 규칙 문 ](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html)
+ [ Amazon SQS를 이벤트 소스로 사용하는 경우 AWS Lambda의 최대 동시성 소개 ](https://aws.amazon.com/blogs/compute/introducing-maximum-concurrency-of-aws-lambda-functions-when-using-amazon-sqs-as-an-event-source/)
+ [AWS Lambda: 최대 동시성 ](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency)

 **관련 예시:** 
+ [ 가장 중요한 세 가지 AWS WAF 속도 기반 규칙 ](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/)
+ [ Java Bucket4j ](https://github.com/bucket4j/bucket4j)
+ [ Python 토큰 버킷 ](https://pypi.org/project/token-bucket/)
+ [ Node 토큰 버킷 ](https://www.npmjs.com/package/tokenbucket)
+ [ .NET 시스템 스레딩 속도 제한 ](https://www.nuget.org/packages/System.Threading.RateLimiting)

 **관련 동영상:** 
+ [AWS AppSync를 사용하여 GraphQL API 보안 모범 사례 구현 ](https://www.youtube.com/watch?v=1ASMLeJ_15U)

 **관련 도구:** 
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon Kinesis ](https://aws.amazon.com/kinesis/)
+ [AWS WAF](https://aws.amazon.com/waf/)

# REL05-BP03 재시도 호출 제어 및 제한
<a name="rel_mitigate_interaction_failure_limit_retries"></a>

지수 백오프를 사용하여 각 재시도 간에 점진적으로 더 긴 간격으로 요청을 다시 시도합니다. 재시도 사이에 지터를 도입하여 재시도 간격을 무작위로 지정합니다. 최대 재시도 횟수를 제한합니다.

 **원하는 결과:** 분산 소프트웨어 시스템의 일반적인 구성 요소로는 서버, 로드 밸런서, 데이터베이스, DNS 서버가 있습니다. 이러한 구성 요소는 정상 작동 중에 일시적 또는 제한적인 오류로 또한 재시도에 관계없이 지속되는 오류로 요청에 응답할 수 있습니다. 클라이언트가 서비스에 요청을 전송할 때 요청은 메모리, 스레드, 연결, 포트 또는 기타 제한된 리소스를 포함하여 리소스를 소비합니다. 재시도를 제어하고 제한하는 것은 부하가 걸리는 시스템 구성 요소가 과부하되지 않도록 리소스 소비를 줄이고 최소화하기 위한 전략입니다. 

 클라이언트는 시간이 초과되거나 오류 응답을 수신하면 재시도 여부를 결정해야 합니다. 재시도할 경우 지터 및 최대 재시도 값이 포함된 지수 백오프가 발생합니다. 그 결과 백엔드 서비스 및 프로세스에서 부하가 감소하고 자가 복구 시간이 단축되어 복구 속도가 빨라지고 요청 처리가 성공적으로 이루어질 수 있습니다. 

 **일반적인 안티 패턴:** 
+  지수 백오프, 지터, 최대 재시도 값을 추가하지 않고 재시도를 구현합니다. 백오프 및 지터는 의도치 않게 공통 간격으로 조정된 재시도로 인한 인위적인 트래픽 급증을 방지하는 데 도움이 됩니다. 
+  효과를 테스트하지 않고 재시도를 구현하거나 재시도 시나리오를 테스트하지 않고 SDK에 재시도가 이미 내장되어 있다고 가정합니다. 
+  종속성에서 게시된 오류 코드를 이해하지 못하여 권한 부족을 나타내는 명확한 오류, 구성 오류 또는 수동 개입 없이는 해결되지 않을 것으로 예측되는 기타 조건을 포함하여 모든 오류를 재시도합니다. 
+  반복되는 서비스 장애에 대한 모니터링 및 경고를 포함하여 근본적인 문제를 파악하고 해결할 수 있도록 하는 관찰성 관행을 다루지 않습니다. 
+  기본 제공 또는 타사 재시도 기능이 충분할 때 사용자 지정 재시도 메커니즘을 개발합니다. 
+  재시도를 복잡하게 만드는 방식으로 애플리케이션 스택의 여러 계층에서 재시도하여 대량 재시도로 리소스가 더 소모됩니다. 이러한 오류가 애플리케이션의 종속성에 어떤 영향을 미치는지 파악한 다음 한 수준에서만 재시도를 구현해야 합니다. 
+  멱등성이 아닌 서비스 호출을 재시도하여 중복 결과 등 예상치 못한 부작용을 초래합니다. 

 **이 모범 사례 확립의 이점:** 재시도는 요청이 실패했을 때 클라이언트가 원하는 결과를 얻을 수 있도록 도와주지만, 원하는 응답을 받는 데 서버 시간을 더 많이 소비하기도 합니다. 오류가 드물거나 일시적인 경우 재시도가 유용합니다. 리소스 과부하로 인해 장애가 발생한 경우 재시도는 상황을 악화시킬 수 있습니다. 클라이언트 재시도 시 지터와 함께 지수 백오프를 추가하면 리소스 과부하로 인한 장애 발생 시 서버를 복구할 수 있습니다. 지터는 요청이 집중되어 급증하는 것을 방지하고 백오프는 일반 요청 부하에 재시도를 추가하여 발생하는 부하 에스컬레이션을 줄입니다. 마지막으로, 준안정 장애를 초래하는 백로그가 생성되지 않도록 최대 재시도 횟수 또는 경과 시간을 구성하는 것이 중요합니다. 

 **이 모범 사례가 확립되지 않았을 경우의 위험 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 재시도 호출을 제어하고 제한합니다. 지수 백오프를 사용하여 점진적으로 더 긴 간격 후에 다시 시도합니다. 지터를 도입하여 재시도 간격을 무작위로 지정하고 최대 재시도 횟수를 제한합니다. 

 일부 AWS SDK는 기본적으로 재시도와 지수 백오프를 구현합니다. 해당하는 경우 워크로드에 이러한 기본 제공 AWS 구현을 사용합니다. 멱등성이 있는 서비스를 호출하고 재시도가 클라이언트 가용성을 향상시키는 경우 워크로드에 유사한 로직을 구현합니다. 사용 사례를 기반으로 시간 제한 대상 및 재시도 중단 시점을 결정합니다. 이러한 재시도 사용 사례에 대한 테스트 시나리오를 구축하고 실행합니다. 

## 구현 단계
<a name="implementation-steps"></a>
+  애플리케이션 스택에서 애플리케이션이 의존하는 서비스에 대한 재시도를 구현하기 위한 최적의 계층을 결정합니다. 
+  선택한 언어에 대해 지수 백오프 및 지터가 포함된 검증된 재시도 전략을 구현하는 기존 SDK를 파악하고 직접 재시도 구현을 작성하는 것보다 이러한 전략을 우선적으로 사용합니다. 
+  재시도를 구현하기 전에 [서비스가 멱등성인지](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) 확인합니다. 재시도를 구현한 후에는 반드시 테스트를 거치고 프로덕션 환경에서 정기적으로 실행해야 합니다. 
+  AWS 서비스 API를 호출할 때는 [AWS SDK](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) 및 [AWS CLI를](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html) 사용하고 재시도 구성 옵션을 이해합니다. 기본값이 사용 사례에 맞는지 확인하고 필요에 따라 테스트하고 조정합니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [REL04-BP04 모든 응답의 멱등성 유지](rel_prevent_interaction_failure_idempotent.md) 
+  [REL05-BP02 요청 제한](rel_mitigate_interaction_failure_throttle_requests.md) 
+  [REL05-BP04 빠른 실패 및 대기열 제한](rel_mitigate_interaction_failure_fail_fast.md) 
+  [REL05-BP05 클라이언트 시간 제한 설정](rel_mitigate_interaction_failure_client_timeouts.md) 
+  [REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지](rel_withstand_component_failures_monitoring_health.md) 

 **관련 문서:** 
+  [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/) 
+ [ Exponential Backoff and Jitter ](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)
+ [ 멱등성 API로 안전한 재시도 ](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)

 **관련 예시:** 
+ [ Spring 재시도 ](https://github.com/spring-projects/spring-retry)
+ [ Resilience4j 재시도 ](https://resilience4j.readme.io/docs/retry)

 **관련 동영상:** 
+  [재시도, 백오프 및 지터: AWS re:Invent 2019: Introducing The Amazon Builders’ Library(Amazon Builders’ Library 소개)(DOP328)](https://youtu.be/sKRdemSirDM?t=1884) 

 **관련 도구:** 
+ [AWS SDK 및 도구: 재시도 동작 ](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)
+ [AWS Command Line Interface: AWS CLI 재시도 ](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html)

# REL05-BP04 빠른 실패 및 대기열 제한
<a name="rel_mitigate_interaction_failure_fail_fast"></a>

서비스가 요청에 제대로 응답하지 못하면 빠르게 실패합니다. 이렇게 하면 요청에 연결된 리소스를 해제할 수 있고 리소스가 부족한 경우 서비스 복구를 허용할 수 있습니다. 빠른 실패는 클라우드에서 매우 안정적인 워크로드를 구축하기 위해 활용할 수 있는 잘 정립된 소프트웨어 설계 패턴입니다. 대기열도 잘 정립된 엔터프라이즈 통합 패턴으로, 이를 통해 로드를 원활하게 수행하고 비동기 처리가 허용될 때 클라이언트가 리소스를 해제할 수 있습니다. 서비스가 정상 상태에서는 제대로 응답할 수 있지만 요청 속도가 너무 높아서 실패하는 경우 대기열을 사용하여 요청을 버퍼링하십시오. 하지만 긴 대기열 백로그가 쌓이도록 두지 마십시오. 그러면 클라이언트가 이미 포기한 무효 요청을 처리할 수 있습니다.

 **원하는 결과:** 시스템에서 리소스 경합, 시간 제한, 예외 또는 회색 실패가 발생하여 서비스 수준 목표를 달성할 수 없는 경우 빠른 실패 전략을 통해 시스템 복구 시간을 단축할 수 있습니다. 트래픽 스파이크를 흡수해야 하고 비동기 처리를 수용할 수 있는 시스템은 클라이언트가 대기열을 사용하여 요청을 백엔드 서비스에 버퍼링함으로써 요청을 신속하게 해제할 수 있도록 하여 신뢰성을 높일 수 있습니다. 요청을 대기열로 버퍼링할 때 대처할 수 없는 백로그를 방지하기 위해 대기열 관리 전략이 구현됩니다. 

 **일반적인 안티 패턴:** 
+  메시지 대기열을 구현하지만 DLQ(Dead Letter Queue) 볼륨에 DLQ 또는 경보를 구성하여 시스템 장애 시점을 감지하지는 않습니다. 
+  대기열 소비자가 지연되거나 오류로 인해 재시도되는 시기를 파악하기 위해 대기열에 있는 메시지의 대기 기간을 측정하는 것이 아니라 지연 시간을 측정합니다. 
+  업무상 더 이상 필요하지 않아 이러한 메시지를 처리할 가치가 없는 경우 대기열에서 백로깅된 메시지를 지우지 않습니다. 
+  후입선출(LIFO) 대기열이 클라이언트 요구 사항을 더 잘 충족할 때 선입선출(FIFO) 대기열을 구성합니다. 예를 들어 엄격한 순서가 필요하지 않고 백로그 처리가 모든 신규 요청과 시간이 중요한 요청을 지연시켜 모든 클라이언트가 서비스 수준 위반을 경험하는 경우입니다. 
+  작업 접수를 관리하고 요청을 내부 대기열에 배치하는 API를 노출하는 대신 내부 대기열을 클라이언트에 노출합니다. 
+  아주 많은 작업 요청 유형을 단일 대기열에 결합합니다. 그러면 리소스 수요가 요청 유형 전체에 분산되어 백로그 상태가 악화될 수 있습니다. 
+  서로 다른 모니터링, 시간 제한, 리소스 할당이 필요함에도 복잡한 요청과 단순한 요청을 동일한 대기열에서 처리합니다. 
+  소프트웨어에서 오류를 정상적으로 처리할 수 있는 상위 수준 구성 요소에 예외를 발생시키는 빠른 실패 메커니즘을 구현하기 위해 입력의 유효성을 확인하거나 어설션을 사용하지 않습니다. 
+  장애 리소스를 요청 라우팅에서 제거하지 않습니다(특히 장애가 충돌 및 다시 시작, 간헐적인 종속성 장애, 용량 감소 또는 네트워크 패킷 손실로 인한 실패 및 성공을 모두 표시하는 회색인 경우). 

 **이 모범 사례 확립의 이점:** 빠르게 실패하는 시스템은 디버깅과 수정이 더 쉬우며 릴리스가 프로덕션 환경에 게시되기 전에 코딩과 구성 문제를 드러내는 경우가 많습니다. 효과적인 대기열 전략이 통합된 시스템은 트래픽 급증 및 간헐적인 시스템 장애 상태에 대한 복원력과 신뢰성을 높입니다. 

 **이 모범 사례가 확립되지 않았을 경우의 위험 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 빠른 실패 전략은 소프트웨어 솔루션에 코딩할 수 있을 뿐만 아니라 인프라에 구성할 수도 있습니다. 대기열은 빠른 실패뿐만 아니라 시스템 구성 요소를 분리하여 부하를 원활하게 하는 간단하면서도 강력한 아키텍처 기법입니다. [Amazon CloudWatch는](https://aws.amazon.com/cloudwatch/) 장애를 모니터링하고 경보하는 기능을 제공합니다. 시스템에 장애가 발생한 것으로 확인되면 손상된 리소스를 제거하는 등 완화 전략을 실행할 수 있습니다. 시스템이 원활한 로드를 위해 [Amazon SQS](https://aws.amazon.com/sqs/) 및 기타 대기열 기술로 대기열을 구현할 때 대기열 백로그와 메시지 소비 실패를 관리하는 방법을 고려해야 합니다. 

## 구현 단계
<a name="implementation-steps"></a>
+  소프트웨어에 프로그래밍 방식 어설션 또는 특정 메트릭을 구현하고 이를 사용하여 시스템 문제에 대해 명시적으로 경고합니다. Amazon CloudWatch는 애플리케이션 로그 패턴과 SDK 계측을 기반으로 지표 및 경보를 생성하는 데 도움이 됩니다. 
+  CloudWatch 지표 및 경보를 사용하여 처리 지연 시간을 늘리거나 반복적으로 요청 처리를 실패하는 손상된 리소스를 차단합니다. 
+  백엔드 대기열 소비자가 요청을 처리하는 동안 클라이언트가 리소스를 해제하고 다른 작업을 계속할 수 있도록 요청을 수락하고 Amazon SQS를 사용하여 내부 대기열에 요청을 추가한 다음 메시지 생성 클라이언트에 성공 메시지로 응답하도록 API를 설계하여 비동기 처리를 사용합니다. 
+  현재 시간과 메시지 타임스탬프를 비교해 대기열에서 메시지를 제거할 때마다 CloudWatch 지표를 생성하여 대기열 처리 대기 시간을 측정하고 모니터링합니다. 
+  장애가 발생하여 메시지 처리가 실패했거나 서비스 수준 계약 내에서 처리할 수 없는 트래픽 스파이크가 발생하는 경우 오래된 트래픽이나 초과 트래픽을 스필오버 대기열로 넘깁니다. 이를 통해 새 작업을 우선적으로 처리하고 용량이 사용 가능한 경우 이전 작업을 우선적으로 처리할 수 있습니다. 이 기법은 LIFO 처리와 유사하며 모든 새 작업에 대해 정상적인 시스템 처리가 가능합니다. 
+  DLQ(Dead Letter Queue) 또는 재구동 대기열을 사용하여 백로그에서 처리할 수 없는 메시지를 나중에 조사하고 해결할 수 있는 위치로 옮깁니다. 
+  이전 메시지를 재시도하거나 허용되는 경우 현재 시간을 메시지 타임스탬프와 비교하고 더 이상 요청 클라이언트와 관련이 없는 메시지를 삭제합니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [REL04-BP02 느슨하게 결합된 종속성 구현](rel_prevent_interaction_failure_loosely_coupled_system.md) 
+  [REL05-BP02 요청 제한](rel_mitigate_interaction_failure_throttle_requests.md) 
+  [REL05-BP03 재시도 호출 제어 및 제한](rel_mitigate_interaction_failure_limit_retries.md) 
+  [REL06-BP02 지표 정의 및 계산(집계)](rel_monitor_aws_resources_notification_aggregation.md) 
+  [REL06-BP07 시스템을 통한 요청의 엔드 투 엔드 추적 모니터링](rel_monitor_aws_resources_end_to_end.md) 

 **관련 문서:** 
+ [ 심각한 수준의 대기열 백로그 방지 ](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs/)
+  [빠른 실패](https://www.martinfowler.com/ieeeSoftware/failFast.pdf) 
+ [ 내 Amazon SQS 대기열에서 메시지 백로그가 증가하는 것을 방지하려면 어떻게 해야 합니까? ](https://repost.aws/knowledge-center/sqs-message-backlog)
+ [ Elastic Load Balancing: 영역 전환 ](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/zonal-shift.html)
+ [ Amazon Route 53 Application Recovery Controller: 트래픽 장애 조치를 위한 라우팅 제어 ](https://docs.aws.amazon.com/r53recovery/latest/dg/getting-started-routing-controls.html)

 **관련 예시:** 
+ [ 엔터프라이즈 통합 패턴: 배달 못한 편지 채널 ](https://www.enterpriseintegrationpatterns.com/patterns/messaging/DeadLetterChannel.html)

 **관련 동영상:** 
+  [AWS re:Invent 2022 - Operating highly available Multi-AZ applications(고가용성 다중 AZ 애플리케이션 운영)](https://www.youtube.com/watch?v=mwUV5skJJ0s) 

 **관련 도구:** 
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon MQ ](https://aws.amazon.com/amazon-mq/)
+ [AWS IoT Core](https://aws.amazon.com/iot-core/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)

# REL05-BP05 클라이언트 시간 제한 설정
<a name="rel_mitigate_interaction_failure_client_timeouts"></a>

연결 및 요청에 대한 시간 제한을 적절하게 설정하고 체계적으로 확인합니다. 워크로드 세부 사항을 인식하지 못하므로 기본값에 의존하지 마십시오.

 **원하는 결과:** 클라이언트 시간 제한은 완료에 비정상적으로 많은 시간이 걸리는 요청 대기와 관련된 클라이언트, 서버, 워크로드의 비용을 고려해야 합니다. 시간 제한의 정확한 원인을 알 수 없기 때문에 클라이언트는 서비스에 대한 지식을 활용하여 생각되는 원인과 적절한 시간 제한에 대한 기대치를 세워야 합니다. 

 구성된 값에 따라 클라이언트 연결이 시간 제한됩니다. 시간 제한이 발생한 후 클라이언트는 작업을 중단하고 재시도 또는 [회로 차단기](https://martinfowler.com/bliki/CircuitBreaker.html)개방을 결정합니다. 이러한 패턴에서는 근본적인 오류 상태를 악화시킬 수 있는 요청 발행이 방지됩니다. 

 **일반적인 안티 패턴:** 
+  시스템 시간 제한 또는 기본 시간 제한을 인식하지 못합니다. 
+  정상적인 요청 완료 타이밍을 인식하지 못합니다. 
+  요청을 완료하는 데 비정상적으로 오래 걸리는 원인 또는 이러한 완료를 기다리는 데 따른 클라이언트, 서비스 또는 워크로드 성능의 비용을 인식하지 못합니다. 
+  네트워크가 손상되어 시간 제한에 도달한 후에만 요청이 실패할 확률과 시간 제한을 더 짧게 설정하지 않아 클라이언트와 워크로드에 발생할 수 있는 비용을 인식하지 못합니다. 
+  연결 및 요청 모두에 대한 시간 제한 시나리오를 테스트하지 않습니다. 
+  시간 제한을 매우 높게 설정합니다. 그러면 지연 시간이 길어지고 리소스 사용률이 증가할 수 있습니다. 
+  시간 제한을 매우 낮게 설정합니다. 그러면 인위적인 오류가 발생합니다. 
+  회로 차단기 및 재시도와 같은 원격 호출의 시간 제한 오류를 처리하기 위한 패턴을 간과합니다. 
+  서비스 호출 오류율, 지연 시간에 대한 서비스 수준 목표, 지연 시간 이상치에 대한 모니터링을 고려하지 않습니다. 이러한 지표를 통해 공격적이거나 허용되는 시간 제한의 인사이트를 얻을 수 있습니다. 

 **이 모범 사례 확립의 이점:** 원격 호출 시간 제한이 구성되고 시스템이 시간 제한을 정상적으로 처리하도록 설계되어 원격 호출이 비정상적으로 느리게 응답하고 서비스 클라이언트에서 시간 제한 오류를 정상적으로 처리할 때 리소스가 절약됩니다. 

 **이 모범 사례가 확립되지 않았을 경우의 위험 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 서비스 종속성 호출과 일반적으로 프로세스 전체의 모든 호출에 연결 시간 제한과 요청 시간 제한을 모두 설정합니다. 많은 프레임워크가 시간 제한 기능을 기본 제공하지만 일부 프레임워크에는 서비스 목표에 허용되는 것보다 높거나 무한한 기본값이 있으므로 주의해야 합니다. 값이 너무 높으면 클라이언트가 시간 제한이 발생할 때까지 대기하는 동안 리소스가 계속 소비되기 때문에 시간 제한의 유용성이 감소합니다. 값이 너무 낮으면 백엔드에서 트래픽이 증가하고 너무 많은 요청이 재시도되므로 지연 시간이 증가할 수 있습니다. 일부 경우에는 모든 요청이 재시도되기 때문에 이로 인해 전체가 중단될 수 있습니다. 

 시간 제한 전략을 결정할 때는 다음 사항을 고려하십시오. 
+  요청의 내용, 대상 서비스의 장애 또는 네트워킹 파티션 장애로 인해 요청을 처리하는 데 평소보다 시간이 오래 걸릴 수 있습니다. 
+  비정상적으로 비용이 많이 드는 콘텐츠를 요청하면 불필요한 서버 및 클라이언트 리소스가 소모될 수 있습니다. 이 경우 이러한 요청을 시간 초과시키고 재시도하지 않는 것이 리소스를 보존할 수 있습니다. 또한 서비스는 스로틀 및 서버 측 시간 제한으로 비정상적으로 비용이 많이 드는 콘텐츠로부터 스스로를 보호해야 합니다. 
+  서비스 장애로 인해 비정상적으로 오래 걸리는 요청은 시간 제한 후 재시도할 수 있습니다. 요청 및 재시도에 따른 서비스 비용을 고려해야 하지만, 원인이 국소적인 장애인 경우 재시도는 비용이 많이 들지 않으며 클라이언트 리소스 소비를 줄일 수 있습니다. 장애의 특성에 따라 시간 제한으로 인해 서버 리소스가 해제될 수도 있습니다. 
+  네트워크에서 요청 또는 응답을 전달하지 못해 완료하는 데 시간이 오래 걸리는 요청은 시간 초과 후 재시도할 수 있습니다. 요청 또는 응답이 전달되지 않았으므로 시간 제한의 길이와 상관없이 실패했을 것입니다. 이 경우 시간 초과로 인해 서버 리소스가 해제되지는 않지만 클라이언트 리소스가 해제되고 워크로드 성능이 향상됩니다. 

 재시도 및 회로 차단기와 같이 잘 정립된 설계 패턴을 활용하여 시간 제한을 원활하게 처리하고 빠른 실패 접근 방식을 지원할 수 있습니다. [AWS SDK](https://docs.aws.amazon.com/index.html#sdks) 및 [AWS CLI는](https://aws.amazon.com/cli/) 연결 및 요청 시간 제한을 모두 구성하고 지수 백오프 및 지터를 통한 재시도를 구성할 수 있습니다. [AWS Lambda](https://aws.amazon.com/lambda/) 함수는 시간 제한 구성을 지원하고 [AWS Step Functions에서는](https://aws.amazon.com/step-functions/)AWS 서비스 및 SDK와의 사전 구축된 통합을 활용하는 로우 코드 회로 차단기를 구축할 수 있습니다. [AWS App Mesh](https://aws.amazon.com/app-mesh/) Envoy는 시간 제한 및 회로 차단기 기능을 제공합니다. 

## 구현 단계
<a name="implementation-steps"></a>
+  원격 서비스 호출에 대한 시간 제한을 구성하고 기본 제공되는 언어 시간 제한 기능 또는 오픈 소스 시간 제한 라이브러리를 활용합니다. 
+  워크로드가 AWS SDK를 사용하여 호출하는 경우 설명서에서 언어별 시간 제한 구성을 검토하십시오. 
  + [ Python ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html)
  + [ PHP ](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.DefaultsMode.Configuration.html)
  + [ .NET ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
  + [ Ruby ](https://docs.aws.amazon.com/sdk-for-ruby/v3/developer-guide/timeout-duration.html)
  + [ Java ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
  + [ Go ](https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/retries-timeouts/#timeouts)
  + [ Node.js ](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Config.html)
  + [ C\$1\$1 ](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/client-config.html)
+  워크로드에서 AWS SDK 또는 AWS CLI 명령을 [사용하는](https://docs.aws.amazon.com/sdkref/latest/guide/feature-smart-config-defaults.html) 경우 `connectTimeoutInMillis` 및 `tlsNegotiationTimeoutInMillis`에 대한 AWS 구성 기본값을 설정하여 기본 시간 제한을 구성합니다. 
+  명령줄 [옵션](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html) `cli-connect-timeout` 및 `cli-read-timeout을` 적용하여 AWS 서비스에 대한 일회성 AWS CLI 명령을 제어합니다. 
+  오류 시나리오를 사전에 처리할 수 있도록 원격 서비스 호출의 시간 제한을 모니터링하고 지속적인 오류에 대한 경고를 설정합니다. 
+  호출 오류율, 대기 시간에 대한 서비스 수준 목표, 대기 시간 이상값에 대한 [CloudWatch 지표](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 및 [CloudWatch 이상 탐지를](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 구현하여 과도하게 공격적이거나 허용적인 시간 제한 관리의 인사이트를 얻습니다. 
+  시간 제한을 [Lambda 함수에](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html#configuration-timeout-console)구성합니다. 
+  API Gateway 클라이언트는 시간 제한을 처리할 때 자체 재시도를 구현해야 합니다. API Gateway는 다운스트림 통합에 대해 [50밀리초\$129초의 통합 시간 제한을](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html#api-gateway-execution-service-limits-table) 지원하고 통합 요청 시간 제한 시 재시도하지 않습니다. 
+  원격 호출이 시간 제한하는 경우 원격 호출을 방지하는 [회로 차단기](https://martinfowler.com/bliki/CircuitBreaker.html) 패턴을 구현합니다. 호출이 실패하지 않도록 회로를 개방하고 호출이 정상적으로 응답할 때 회로를 폐쇄합니다. 
+  컨테이너 기반 워크로드의 경우 [App Mesh Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy.html) 기능을 검토하여 기본 제공 시간 제한 및 회로 차단기를 활용합니다. 
+  특히 AWS 네이티브 SDK 및 지원되는 Step Functions 통합을 호출하여 워크로드를 간소화하는 경우 AWS Step Functions를 사용하여 원격 서비스 호출을 위한 로우 코드 회로 차단기를 구축합니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [REL05-BP03 재시도 호출 제어 및 제한](rel_mitigate_interaction_failure_limit_retries.md) 
+  [REL05-BP04 빠른 실패 및 대기열 제한](rel_mitigate_interaction_failure_fail_fast.md) 
+  [REL06-BP07 시스템을 통한 요청의 엔드 투 엔드 추적 모니터링](rel_monitor_aws_resources_end_to_end.md) 

 **관련 문서:** 
+  [AWS SDK: 재시도 및 시간 제한](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html) 
+  [Amazon Builders' Library: 시간 제한, 재시도 및 지터를 사용한 백오프](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) 
+ [ Amazon API Gateway 할당량 및 중요 참고 사항 ](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html)
+ [AWS Command Line Interface: 명령줄 옵션 ](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html)
+ [AWS SDK for Java 2.x: API 시간 제한 구성 ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [ 구성 객체 및 구성 참조를 사용하는 AWS Botocore ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#using-the-config-object)
+ [AWS SDK for .NET: 재시도 및 시간 제한 ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [AWS Lambda: Lambda 함수 옵션 구성 ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html)

 **관련 예시:** 
+ [AWS Step Functions 및 Amazon DynamoDB와 함께 회로 차단기 패턴 사용 ](https://aws.amazon.com/blogs/compute/using-the-circuit-breaker-pattern-with-aws-step-functions-and-amazon-dynamodb/)
+ [ Martin Fowler: CircuitBreaker ](https://martinfowler.com/bliki/CircuitBreaker.html?ref=wellarchitected)

 **관련 도구:** 
+ [AWS SDK ](https://docs.aws.amazon.com/index.html#sdks)
+ [AWS Lambda](https://aws.amazon.com/lambda/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/)
+ [AWS Command Line Interface](https://aws.amazon.com/cli/)

# REL05-BP06 가능한 경우 서비스를 스테이트리스로 설계
<a name="rel_mitigate_interaction_failure_stateless"></a>

 서비스는 상태를 필요로 하지 않거나 디스크 및 메모리의 로컬로 저장된 데이터에 종속성이 없도록 서로 다른 클라이언트 요청 간에 상태를 오프로드해야 합니다. 이를 통해 가용성에 영향을 주지 않고 서버를 원하는 방식으로 교체할 수 있습니다. Amazon ElastiCache 또는 Amazon DynamoDB는 오프로드된 상태에 적합한 대상입니다. 

![\[이 스테이스리스 웹 애플리케이션에서는 세션 상태가 Amazon ElastiCache로 오프로드됩니다.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/images/stateless-webapp.png)


 사용자 또는 서비스는 애플리케이션과 상호 작용할 때 세션을 구성하는 일련의 상호 작용을 수행하는 경우가 많습니다. 세션은 애플리케이션을 사용하는 동안 요청 간에 유지되는 사용자의 고유한 데이터입니다. 상태 비저장 애플리케이션은 이전 상호 작용에 대한 지식을 필요로 하지 않으며 세션 정보를 저장하지 않는 애플리케이션입니다. 

 스테이스리스로 설계된 경우 AWS Lambda 또는 AWS Fargate와 같은 서버리스 컴퓨팅 서비스를 사용할 수 있습니다. 

 서버 대체 외에 상태 비저장 애플리케이션의 또 다른 이점은 사용 가능한 컴퓨팅 리소스(예: EC2 인스턴스 및 AWS Lambda 함수)로 모든 요청을 처리할 수 있기 때문에 수평적으로 확장할 수 있다는 것입니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  애플리케이션을 스테이스리스로 생성합니다. 무상태 애플리케이션은 수평 확장을 가능하게 하며, 개별 노드의 장애에 대한 내결함성이 있습니다. 
  +  요청 파라미터에 실제로 저장될 수 있는 상태를 제거합니다. 
  +  상태가 필요한지 여부를 조사한 후 상태 추적을 Amazon ElastiCache, Amazon RDS, Amazon DynamoDB 또는 서드 파티 분산 데이터 솔루션과 같은 복원성이 있는 다중 영역 캐시 데이터 스토어로 옮깁니다. 복원성이 있는 데이터 스토어로 옮길 수 없는 상태를 저장합니다. 
    +  일부 데이터(쿠키 등)는 헤더 또는 쿼리 파라미터로 전달될 수 있습니다. 
    +  리팩터링을 통해 요청에 빠르게 전달될 수 있는 상태를 제거합니다. 
    +  일부 데이터는 요청별로 필요하지 않으며 요청에 따라 검색 시 검색될 수 있습니다. 
    +  비동기식으로 검색할 수 있는 데이터를 제거합니다. 
    +  필수 상태 요구 사항을 충족하는 데이터 스토어를 결정합니다. 
    +  비관계형 데이터를 위한 NoSQL 데이터베이스를 고려합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 비상 레버 구현
<a name="rel_mitigate_interaction_failure_emergency_levers"></a>

 비상 레버는 워크로드의 가용성에 미치는 영향을 신속하게 완화할 수 있는 프로세스입니다. 

 비상 레버는 알려진 메커니즘과 테스트를 거친 메커니즘을 사용하여 구성 요소 또는 종속성의 동작을 비활성화, 제한 또는 변경하는 방식으로 작동합니다. 이를 통해 예상치 못한 수요 증가로 인한 리소스 고갈이 유발하는 워크로드 장애를 완화하고 워크로드 내 비핵심 구성 요소에 장애가 미치는 영향을 줄일 수 있습니다. 

 **원하는 결과:** 비상 레버를 구현하면 올바른 것으로 확인된 프로세스를 구축하여 워크로드에서 핵심 구성 요소의 가용성을 유지할 수 있습니다. 비상 레버를 작동시키는 동안에도 워크로드는 단계적으로 줄어들고 비즈니스의 핵심 기능을 계속 수행해야 합니다. 단계적 성능 저하에 대한 자세한 내용은 [REL05-BP01 관련 하드 종속성을 소프트 종속성으로 변환하는 단계적 성능 저하 구현](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html)을 참조하세요. 

 **일반적인 안티 패턴:** 
+  비핵심 종속성의 장애가 핵심 워크로드의 가용성에 영향을 미칩니다. 
+  비핵심 구성 요소가 손상되었을 때 핵심 구성 요소 동작을 테스트하거나 확인하지 않습니다. 
+  비상 레버의 활성화 또는 비활성화에 대한 명확하고 결정적인 기준이 정의되어 있지 않습니다. 

 **모범 사례 확립의 이점:** 비상 레버를 구현하면 해석기에 확립된 프로세스를 제공하여 예상치 못한 수요 급증 또는 비핵심 종속성 장애에 대응하도록 함으로써 워크로드에서 핵심 구성 요소의 가용성을 높일 수 있습니다. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 중간 

## 구현 가이드
<a name="implementation-guidance"></a>
+  워크로드의 핵심 구성 요소를 식별합니다. 
+  비핵심 구성 요소의 장애를 견딜 수 있도록 워크로드의 핵심 구성 요소를 설계하고 설계합니다. 
+  테스트를 수행하여 비핵심 구성 요소에 장애가 발생한 경우 핵심 구성 요소의 동작을 검증합니다. 
+  관련 지표 또는 트리거를 정의하고 모니터링하여 비상 레버 절차를 시작합니다. 
+  비상 레버를 구성하는 절차를 수동 또는 자동으로 정의합니다. 

### 구현 단계
<a name="implementation-steps"></a>
+  워크로드에서 비즈니스의 핵심 구성 요소를 식별합니다. 
  +  워크로드의 각 기술 구성 요소를 관련 비즈니스 기능에 매핑하고 핵심 또는 비핵심으로 평가해야 합니다. Amazon의 핵심 기능과 비핵심 기능의 예를 보려면 [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering)를 참조하세요. 
  +  이런 과정은 기술 의사 결정이자 동시에 비즈니스 의사 결정이며 조직과 워크로드에 따라 다릅니다. 
+  비핵심 구성 요소의 장애를 견딜 수 있도록 워크로드의 핵심 구성 요소를 설계하고 설계합니다. 
  +  종속성 분석 중에 잠재적 장애 모드를 모두 고려하고 비상 레버 메커니즘이 다운스트림 구성 요소에 핵심 기능을 제공하는지 확인합니다. 
+  비상 레버를 작동시키는 동안 핵심 구성 요소의 동작을 검증하기 위한 테스트를 실시합니다. 
  +  바이모달 동작은 사용하지 마세요. 자세한 내용은 [REL11-BP05 정적 안정성을 사용하여 바이모달 동작 방지](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)를 참조하세요. 
+  관련 지표를 정의 및 모니터링하고 알림을 설정하여 비상 레버 절차를 시작합니다. 
  +  모니터링할 올바른 지표를 찾는 방법은 워크로드에 따라 다릅니다. 지표의 예로는 지연 시간 또는 종속성에 대한 요청 실패 횟수가 있습니다. 
+  비상 레버를 구성하는 절차를 수동 또는 자동으로 정의합니다. 
  +  여기에는 [로드 감소](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/), [요청 제한](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html) 또는 [단계적 성능 저하](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html) 구현과 같은 메커니즘이 포함될 수 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [REL05-BP01 관련 하드 종속성을 소프트 종속성으로 변환하는 단계적 성능 저하 구현](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html) 
+  [REL05-BP02 요청 제한](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html) 
+  [REL11-BP05 정적 안정성을 사용하여 바이모달 동작 방지](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html) 

 **관련 문서:** 
+ [안전한 자동 배포 자동화](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+  [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering) 

 **관련 동영상:** 
+ [AWS re:Invent 2020: Reliability, consistency, and confidence through immutability](https://www.youtube.com/watch?v=jUSYnRztttY)

# 변경 사항 관리
<a name="a-change-management"></a>

**Topics**
+ [REL 6. 워크로드 리소스는 어떻게 모니터링합니까?](rel-06.md)
+ [REL 7. 수요 변경에 따라 조정되도록 워크로드를 설계하려면 어떻게 해야 합니까?](rel-07.md)
+ [REL 8. 변경 사항은 어떻게 적용합니까?](rel-08.md)

# REL 6. 워크로드 리소스는 어떻게 모니터링합니까?
<a name="rel-06"></a>

로그와 지표는 워크로드의 상태를 파악할 수 있는 유용한 도구입니다. 로그 및 지표를 모니터링하여 임계값을 초과하거나 중요한 이벤트가 발생하면 알림을 보내도록 워크로드를 구성할 수 있습니다. 모니터링을 수행하면 워크로드가 저성능 임계값을 초과하거나 장애가 발생할 때를 인식하고 이에 대응하여 자동으로 복구할 수 있습니다.

**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 워크로드의 모든 구성 요소 모니터링(생성)
<a name="rel_monitor_aws_resources_monitor_resources"></a>

 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와 관련한 지표는 모니터링하지 않음 
+  프로덕션 트래픽 및 단순한 상태 확인에 의존하여 워크로드 상태를 모니터링하고 평가함 

 **이 모범 사례 정립의 이점:** 워크로드의 모든 티어에서 모니터링할 경우 워크로드를 구성하는 구성 요소의 문제를 보다 신속하게 예측하고 해결할 수 있습니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

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)사용함으로써 고객보다 먼저 문제를 발견할 수 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+ [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 지표 정의 및 계산(집계)
<a name="rel_monitor_aws_resources_notification_aggregation"></a>

 로그 데이터를 저장하고 필요한 경우 필터를 적용하여 특정 로그 이벤트 수 또는 로그 이벤트 타임스탬프에서 계산된 지연 시간과 같은 지표를 계산합니다. 

 Amazon CloudWatch 및 Amazon S3는 기본 집계 및 스토리지 계층으로 사용됩니다. AWS Auto Scaling 및 Elastic Load Balancing와 같은 일부 서비스에서는 클러스터나 인스턴스 전반에 걸쳐 CPU 로드 또는 평균 요청 지연 시간 관련 기본 지표가 기본적으로 제공됩니다. VPC Flow Logs 및 AWS CloudTrail과 같은 스트리밍 서비스의 경우에는 이벤트 데이터가 CloudWatch Logs로 전달되며, 이벤트 데이터에서 지표를 추출하려면 지표 필터를 정의하고 적용해야 합니다. 이렇게 하면 시계열 데이터가 나오며 알림을 트리거하도록 정의한 CloudWatch 경보에 대한 입력으로 이 데이터를 사용할 수 있습니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  지표를 정의 및 계산(집계)합니다. 로그 데이터를 저장하고 필요한 경우 필터를 적용하여 특정 로그 이벤트 수 또는 로그 이벤트 타임스탬프에서 계산된 지연 시간과 같은 지표를 계산합니다. 
  +  지표 필터는 로그 데이터가 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) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 알림 전송(실시간 처리 및 경보)
<a name="rel_monitor_aws_resources_notification_monitor"></a>

조직은 잠재적인 문제를 탐지하면 해당 직원과 시스템에 실시간 알림과 경고를 보내 이러한 문제에 신속하고 효과적으로 대응할 수 있도록 합니다.

 **원하는 결과:** 서비스 및 애플리케이션 지표를 기반으로 관련 경보를 구성하여 운영 이벤트에 신속하게 대응할 수 있습니다. 경보 임계값이 위반되면 적절한 인력과 시스템에 알림이 전송되어 근본적인 문제를 해결할 수 있습니다. 

 **일반적인 안티 패턴:** 
+ 임계값이 지나치게 높은 경보를 구성하여 중요한 알림을 보내지 못하는 상황
+ 임계값이 너무 낮은 경보를 구성하여 과도한 알림 노이즈로 인해 중요한 알림이 제대로 조치되지 않는 상황
+  사용량이 변경될 때 경보 및 임계값을 업데이트하지 않는 상황 
+  자동화된 작업을 통해 가장 잘 해결되는 경보에 대해, 자동화된 작업을 생성하지 않고 담당자에게 알림을 보내 과도한 알림이 전송되는 상황 

 **이 모범 사례 확립의 이점:** 적절한 인력과 시스템에 실시간 알림과 경고를 전송하면 문제를 조기에 탐지하고 운영 인시던트에 신속하게 대응할 수 있습니다. 

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 워크로드는 애플리케이션의 가용성에 영향을 미칠 수 있는 문제의 탐지 가능성을 개선하고 자동화된 대응을 위한 트리거 역할을 할 수 있도록 실시간 처리 및 경보 기능을 갖추어야 합니다. 조직은 정의된 지표로 경고를 생성하여 중요한 이벤트가 발생하거나 지표가 임계값을 초과할 때마다 알림을 수신하여 실시간 처리 및 경보를 수행할 수 있습니다. 

 [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 를 사용하면 [지표](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 와 정적 임계값, 이상 탐지 및 기타 기준에 기반한 CloudWatch 경보를 사용하는 복합 경보를 만들 수 있습니다. CloudWatch를 사용하여 구성할 수 있는 경보 유형에 대한 자세한 내용은 [CloudWatch 설명서의 알람 섹션](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)을 참조하십시오. 

 팀의 AWS 리소스 지표 및 경보에 대한 사용자 지정 보기를 구성할 수 있습니다. 이 경우 [CloudWatch 대시보드](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)를 사용할 수 있습니다. CloudWatch 콘솔의 사용자 지정 가능한 홈 페이지를 사용하면 여러 리전에 걸쳐 단일 보기에서 리소스를 모니터링할 수 있습니다. 

 경보는 다음에 알림을 보내는 것과 같은 하나 이상의 작업을 수행할 수 있습니다. [Amazon SNS 주제로 알림을 전송할 수 있습니다.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)이때 [Amazon EC2](https://aws.amazon.com/ec2/) 작업 또는 [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) 작업을 수행하거나 [OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 또는 [인시던트](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) 를 생성합니다(AWS Systems Manager에서). 

 Amazon CloudWatch는 경보 상태가 변경될 때 [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 를 사용하여 알림을 전송하고, 게시자(생산자)에서 구독자(소비자)에게 메시지를 전달합니다. Amazon SNS 알림 설정에 대한 자세한 내용은 [Amazon SNS 구성](https://docs.aws.amazon.com/sns/latest/dg/sns-configuring.html)을 참조하십시오. 

 CloudWatch에서 [EventBridge](https://aws.amazon.com/eventrbridge/) [이벤트를 전송합니다](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-eventbridge.html) (CloudWatch 경보가 생성, 업데이트, 삭제되거나 상태가 변경될 때마다). 이러한 이벤트와 함께 EventBridge를 사용하여 경보 상태가 변경될 때마다 사용자에게 알리거나 [Systems Manager자동화](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)를 사용하여 계정에서 이벤트를 자동으로 트리거하는 등의 작업을 수행하는 규칙을 만들 수 있습니다. 

** EventBridge 또는 Amazon SNS는 언제 사용해야 하나요? **

 이벤트 기반 애플리케이션을 개발하는 데 EventBridge와 Amazon SNS를 모두 사용할 수 있으며, 특정 요구 사항에 따라 선택이 달라집니다. 

 자체 애플리케이션, SaaS 애플리케이션 및 AWS 서비스의 이벤트에 반응하는 애플리케이션을 구축하려는 경우 Amazon EventBridge를 사용하는 것이 좋습니다. EventBridge는 타사 SaaS 파트너와 직접 통합되는 유일한 이벤트 기반 서비스입니다. 또한 EventBridge는 개발자가 계정에 리소스를 생성할 필요 없이 200개 이상의 AWS 서비스에서 이벤트를 자동으로 수집합니다. 

 EventBridge는 이벤트에 대해 정의된 JSON 기반 구조를 사용하며, 이벤트 본문 전체에 적용되는 규칙을 생성하여 [대상](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)에 전달할 이벤트를 선택할 수 있도록 도와줍니다. EventBridge는 현재 다음을 포함한 20개 이상의 AWS 서비스를 대상으로 지원합니다. [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html), [Amazon SQS](https://aws.amazon.com/sqs/), Amazon SNS, [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) 및 [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/)단축할 수 있습니다. 

 높은 팬 아웃(수천 또는 수백만 개의 엔드포인트)이 필요한 애플리케이션에는 Amazon SNS가 권장됩니다. 일반적으로 고객이 Amazon SNS를 규칙 대상으로 사용하여 필요한 이벤트를 필터링하고 여러 엔드포인트로 팬아웃하는 패턴을 볼 수 있습니다. 

 메시지는 비정형이며 모든 형식이 가능합니다. Amazon SNS는 Lambda, Amazon SQS, HTTP/S 엔드포인트, SMS, 모바일 푸시, 이메일 등 6가지 상이한 유형의 대상에 메시지를 전달할 수 있도록 지원합니다. Amazon SNS의 [일반적인 지연 시간은 30밀리초 미만입니다](https://aws.amazon.com/sns/faqs/). 다양한 AWS 서비스에서 Amazon SNS 메시지를 전송하도록 서비스를 구성하여 전송합니다(다음을 포함하여 30가지 이상: Amazon EC2, [Amazon S3](https://aws.amazon.com/s3/) 및 [Amazon RDS](https://aws.amazon.com/rds/)). 

### 구현 단계
<a name="implementation-steps"></a>

1.  경보를 생성합니다 [(Amazon CloudWatch 경보 사용)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). 

   1.  지표 경보에서는 단일 CloudWatch 지표 또는 CloudWatch 지표에 종속된 표현식을 모니터링합니다. 경보는 여러 시간 간격에 걸쳐 임계값과 비교한 지표 또는 표현식의 값에 따라 하나 이상의 작업을 시작합니다. 작업은 다음으로 알림을 보내는 것으로 구성될 수 있습니다. [Amazon SNS 주제로 알림을 전송합니다.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)이때 [Amazon EC2](https://aws.amazon.com/ec2/) 작업 또는 [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) 작업을 수행하거나 [OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 또는 [인시던트](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) 를 생성합니다(AWS Systems Manager에서). 

   1.  복합 경보는 사용자가 만든 다른 경보의 경보 조건을 고려하는 규칙 표현식으로 구성됩니다. 복합 경보는 모든 규칙 조건이 충족되는 경우에만 경보 상태로 전환됩니다. 복합 경보의 규칙 표현식에 지정된 경보에는 지표 경보 및 추가 복합 경보가 포함될 수 있습니다. 복합 경보는 상태가 변경될 때 Amazon SNS 알림을 보낼 수 있으며 다음을 생성할 수 있습니다. Systems Manager [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 또는 [인시던트](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) (경보 상태에 들어갔지만 Amazon EC2 또는 Auto Scaling 작업을 수행할 수 없는 경우). 

1.  그리고 [Amazon SNS 알림을 설정합니다](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html). CloudWatch 경보 생성 시, 경보 상태가 변경될 때 알림을 보내도록 Amazon SNS 토픽을 포함할 수 있습니다. 

1.  [EventBridge에서](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html) 지정된 CloudWatch 경보와 일치하는 규칙을 생성합니다. 각 규칙은 Lambda 함수를 비롯한 여러 대상을 지원합니다. 예를 들어, 사용 가능한 디스크 공간이 부족할 때 시작되는 경보를 정의하여 EventBridge 규칙을 통해 Lambda 함수를 트리거하여 공간을 정리할 수 있습니다. EventBridge 대상에 대한 자세한 내용은 [EventBridge 대상](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)을 참조하십시오. 

## 리소스
<a name="resources"></a>

 **관련 Well-Architected 모범 사례:** 
+  [REL06-BP01 워크로드의 모든 구성 요소 모니터링(생성)](rel_monitor_aws_resources_monitor_resources.md) 
+  [REL06-BP02 지표 정의 및 계산(집계)](rel_monitor_aws_resources_notification_aggregation.md) 
+  [REL12-BP01 플레이북을 사용하여 장애 조사](rel_testing_resiliency_playbook_resiliency.md) 

 **관련 문서:** 
+ [ Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [ CloudWatch Logs 인사이트 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+  [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) 
+ [ Amazon SNS 알림 설정 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)
+ [ CloudWatch 이상 탐지 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [ CloudWatch Logs 데이터 보호 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/protect-sensitive-log-data-types.html)
+ [ Amazon EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
+ [ Amazon Simple Notification Service ](https://aws.amazon.com/sns/)

 **관련 동영상:** 
+ [ reinvent 2022 observability 동영상 ](https://www.youtube.com/results?search_query=reinvent+2022+observability)
+ [AWS re:Invent 2022 - Observability best practices at Amazon ](https://www.youtube.com/watch?v=zZPzXEBW4P8)

 **관련 예시:** 
+  [One Observability Workshop](https://observability.workshop.aws/) 
+ [ Amazon CloudWatch 경보에 의한 피드백 제어를 통해 AWS Lambda로 연결되는 Amazon EventBridge ](https://serverlessland.com/patterns/cdk-closed-loop-serverless-control-pattern)

# REL06-BP04 응답 자동화(실시간 처리 및 경보)
<a name="rel_monitor_aws_resources_automate_response_monitor"></a>

 : 이벤트가 감지되면 자동화를 사용하여 실패한 구성 요소를 대체하는 등의 조치를 취합니다. 

 경보의 자동화된 실시간 처리가 구현되어 경보가 트리거될 때 시스템이 신속한 시정 조치를 취하고 장애 또는 서비스 저하를 방지할 수 있습니다. 경보에 대한 자동 대응에는 장애가 발생한 구성 요소 교체, 컴퓨팅 용량 조정, 정상적인 호스트, 가용 영역 또는 기타 리전으로 트래픽 리디렉션, 운영자에게 알림 등이 포함될 수 있습니다. 

 **원하는 결과:** 실시간 경보를 식별하고 서비스 수준 목표 및 서비스 수준에 관한 계약(SLA)을 유지하기 위해 적절한 조치를 취하도록 경보 자동 처리를 설정합니다. 자동화는 단일 구성 요소의 자가 복구 작업부터 전체 사이트 장애 조치에 이르기까지 다양합니다. 

 **일반적인 안티 패턴:** 
+  주요 실시간 경보의 명확한 인벤토리 또는 카탈로그가 없습니다. 
+  핵심 경보에 대한 자동 응답이 없습니다(예: 컴퓨팅이 거의 고갈될 때 오토 스케일링 실시). 
+  경보의 대응 조치가 상충합니다. 
+  운영자가 경고 알림을 받을 때 따라야 하는 표준 운영 절차(SOP)가 없습니다. 
+  구성 변경을 모니터링하지 않습니다(감지되지 않은 구성 변경으로 인해 워크로드에 다운타임이 발생할 수 있음). 
+  의도하지 않은 구성 변경을 취소할 전략이 없습니다. 

 **이 모범 사례 확립의 이점:** 경보 처리를 자동화하면 시스템 복원력을 개선할 수 있습니다. 시스템이 자동으로 시정 조치를 취하므로 사람이 개입하여 오류가 발생하기 쉬운 수동 작업이 줄어듭니다. 워크로드 운영이 가용성 목표를 충족하고 서비스 중단을 줄입니다. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 중간 

## 구현 가이드
<a name="implementation-guidance"></a>

 알림을 효과적으로 관리하고 대응을 자동화하려면 중요도와 영향을 기준으로 알림을 분류하고, 대응 절차를 문서화하고, 작업에 순위를 매기기 전에 대응을 계획합니다. 

 구체적인 조치가 필요한 작업을 식별하고(런북에 자세히 설명되어 있는 경우가 많음), 모든 런북과 플레이북을 검토하여 자동화할 수 있는 작업을 결정합니다. 작업을 정의할 수 있는 경우 대개 자동화할 수 있습니다. 작업을 자동화할 수 없는 경우 SOP에 수동 단계를 문서화하고 운영자에게 이 단계를 교육합니다. 알림 대응을 자동화하기 위한 계획을 수립하고 유지할 수 있는 자동화 기회를 위해 수동 프로세스에 지속적으로 검토합니다. 

### 구현 단계
<a name="implementation-steps"></a>

1.  **경보 인벤토리 생성:** 모든 경보 목록을 가져오려면 [AWS CLI](https://aws.amazon.com/cli/)에서 [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) `[describe-alarms](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarms.html)` 명령을 사용할 수 있습니다. 설정한 경보 수에 따라 페이지 매김을 사용하여 각 호출에 대한 경보의 일부를 검색해야 할 수도 있고, AWS SDK를 사용하여 [API 호출](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-describing-alarms.html)을 통해 경보를 가져올 수도 있습니다. 

1.  **모든 경보 동작 문서화:** 수동이든 자동이든 관계없이 모든 경보와 경보의 동작으로 런북을 업데이트합니다. [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/APIReference/Welcome.html)에서 사전 정의된 런북을 제공합니다. 런북에 대한 자세한 내용은 [런북을 사용한 작업](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)을 참조하세요. 런북 콘텐츠를 보는 방법에 대한 자세한 내용은 런북 콘텐츠 [런북 콘텐츠 보기](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html#view-automation-json)를 참조하세요. 

1.  **경보 동작 설정 및 관리:**조치가 필요한 경보의 경우 [CloudWatch SDK를 사용하여 자동 동작](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html)을 지정합니다. 예를 들어, 경보에 대한 작업을 생성 및 활성화하거나 비활성화하여 CloudWatch 경보를 기반으로 Amazon EC2 인스턴스 상태를 자동으로 변경할 수 있습니다. 

    또한 [Amazon EventBridge](https://aws.amazon.com/eventbridge/)를 사용하여 애플리케이션 가용성 문제나 리소스 변경과 같은 시스템 이벤트에 자동으로 대응할 수 있습니다. 규칙을 만들어 관심 있는 이벤트를 지정하고 이벤트가 규칙과 일치할 때 취해야 할 조치를 지정할 수 있습니다. 자동으로 시작할 수 있는 작업에는 [AWS Lambda](https://aws.amazon.com/lambda/) 함수 호출, [Amazon EC2](https://aws.amazon.com/ec2/) `Run Command` 호출, [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/)에 이벤트 릴레이, [EventBridge를 사용하여 Amazon EC2 자동화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/automating_with_eventbridge.html) 등이 포함됩니다. 

1.  **표준 운영 절차(SOP):** 애플리케이션 구성 요소를 기반으로 [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)에서 여러 개의 [SOP 템플릿](https://docs.aws.amazon.com/resilience-hub/latest/userguide/sops.html)을 추천합니다. 이러한 SOP를 사용하여 경보가 발생한 경우 운영자가 따라야 하는 모든 프로세스를 문서화할 수 있습니다. Resilience Hub의 추천에 따라 [SOP를 구성](https://docs.aws.amazon.com/resilience-hub/latest/userguide/building-sops.html)할 수도 있습니다. 이 경우 관련 복원력 정책이 포함된 Resilience Hub 애플리케이션과 해당 애플리케이션에 대한 과거 복원력 평가가 필요합니다. SOP에 대한 추천은 복원력 평가를 통해 작성됩니다. 

    Resilience Hub는 Systems Manager와 함께 사용되어 SOP의 기반으로 사용할 수 있는 여러 [SSM 문서](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-custom-ssm-doc.html)를 제공함으로써 SOP의 단계를 자동화합니다. 예를 들어Resilience Hub는 기존 SSM 자동화 문서를 기반으로 디스크 공간을 추가하기 위한 SOP를 추천할 수 있습니다. 

1.  **Amazon DevOps Guru를 사용하여 자동화된 작업 수행:** 애플리케이션 리소스가 비정상적으로 작동하는지를 자동으로 모니터링하고 표적화된 권장 사항을 제공하여 문제 파악 및 해결 시간을 단축하는 데 [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/)를 사용할 수 있습니다. DevOps Guru를 사용하면 Amazon CloudWatch 지표, [AWS Config](https://aws.amazon.com/config/), [AWS CloudFormation](https://aws.amazon.com/cloudformation/), [AWS X-Ray](https://aws.amazon.com/xray/)를 비롯한 여러 소스에서 운영 데이터 스트림을 거의 실시간으로 모니터링할 수 있습니다. 또한 DevOps Guru를 사용하여 OpsCenter에서 [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html)를 자동으로 생성하고 [추가 자동화를 위해 EventBridge](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-eventbridge.html)에 이벤트를 전송할 수 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [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) 
+  [REL08-BP01 배포와 같은 표준 활동에 런북 사용](rel_tracking_change_management_planned_changemgmt.md) 

 **관련 문서:** 
+  [AWS Systems Manager 자동화](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  [Creating an EventBridge Rule That Triggers on an Event from an AWS Resource](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) 

 **관련 동영상:** 
+ [AWS re:Invent 2022 - Observability best practices at Amazon](https://www.youtube.com/watch?v=zZPzXEBW4P8)(AWS re:Invent 2022 - Amazon에서의 관찰성 모범 사례)
+ [AWS re:Invent 2020: Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [ Introduction to AWS Resilience Hub](https://www.youtube.com/watch?v=_OTTCOjWqPo)
+ [ Create Custom Ticket Systems for Amazon DevOps Guru Notifications ](https://www.youtube.com/watch?v=Mu8IqWVGUfg)
+ [ Enable Multi-Account Insight Aggregation with Amazon DevOps Guru ](https://www.youtube.com/watch?v=MHezNcTSTbI)

 **관련 예시:** 
+ [복원력 워크숍](https://wellarchitectedlabs.com/reliability/)
+ [ Amazon CloudWatch and Systems Manager Workshop ](https://catalog.us-east-1.prod.workshops.aws/workshops/a8e9c6a6-0ba9-48a7-a90d-378a440ab8ba/en-US)

# REL06-BP05 분석
<a name="rel_monitor_aws_resources_storage_analytics"></a>

 로그 파일 및 지표 기록을 수집하고 이를 분석하여 더 광범위한 추세 및 워크로드 인사이트를 확보합니다. 

 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 스토리지 클래스는 성능 영향이나 운영 오버헤드 없이 데이터를 가장 비용 효율적인 티어로 자동으로 이동하여 비용을 최적화하도록 설계되었습니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  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) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 정기적인 검토 시행
<a name="rel_monitor_aws_resources_review_monitoring"></a>

 워크로드 모니터링이 구현되는 방식을 자주 검토하고 중요한 이벤트 및 변경 사항에 따라 업데이트합니다. 

 효과적인 모니터링의 기반은 주요 비즈니스 지표입니다. 비즈니스 우선 순위가 변경됨에 따라 이러한 지표가 워크로드에 반영되는지 확인하십시오. 

 모니터링을 감사하면 애플리케이션이 가용성 목표를 달성하는 시기를 확인하는 데 도움이 됩니다. 근본 원인 분석을 수행하려면 장애 발생 시에 수행된 작업을 검색하는 기능이 필요합니다. 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/) 을 만들었습니다. 운영 성능 검토 및 지식 공유를 위한 정기 케이던스를 설정하면 운영 팀의 성과를 개선하는 역량을 발전시킬 수 있습니다. 

 **일반적인 안티 패턴:** 
+  기본 지표만 수집 
+  모니터링 전략을 설정한 후 다시 검토하지 않음 
+  주요 변경 사항이 배포될 때 모니터링에 대해 논의하지 않음 

 **이 모범 사례 수립의 이점:** 모니터링을 정기적으로 검토하면 예상된 문제가 실제로 발생할 때 알림에 대응하는 것이 아니라 잠재적인 문제를 미리 예측할 수 있습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  워크로드에 대해 여러 대시보드를 생성합니다. 주요 비즈니스 지표는 물론, 다양한 사용량에서 예상되는 워크로드의 상태와 가장 관련성이 높은 것으로 확인된 기술 지표도 포함된 최상위 대시보드가 있어야 합니다. 또한 검사할 수 있는 다양한 애플리케이션 티어와 종속성에 대한 대시보드도 필요합니다. 
  +  [Amazon CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  워크로드 대시보드에 대한 정기적인 검토 일정을 예약하고 검토를 수행합니다. 대시보드를 정기적으로 검사합니다. 검사하는 세부 수준을 나타내는 다양한 케이던스를 구성할 수 있습니다. 
  +  지표에서 추세를 검사합니다. 지표 값을 과거 값과 비교하여 조사해야 할 문제가 있음을 시사하는 추세가 나타나는지 확인합니다. 이러한 예로는 지연 시간 증가, 주요 비즈니스 기능 감소, 장애 응답 증가 등이 있습니다. 
  +  지표에서 특이값/이상 항목을 검사합니다. 평균 또는 중간값은 특이값 및 이상 항목을 감출 수 있습니다. 해당 기간 동안의 가장 높은 값과 가장 낮은 값을 살펴보고 극단적인 값의 원인을 조사합니다. 이러한 원인을 계속 제거하면서 극단성을 낮추면 워크로드 성능의 일관성을 지속적으로 개선할 수 있습니다. 
  +  동작의 급격한 변화를 찾습니다. 지표의 수량 또는 방향이 갑자기 바뀔 경우, 애플리케이션이 변경되었거나 외부 요인이 발생한 것일 수 있습니다. 이 같은 외부 요인으로 인해 추적할 지표를 추가해야 할 수 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 시스템을 통한 요청의 엔드 투 엔드 추적 모니터링
<a name="rel_monitor_aws_resources_end_to_end"></a>

제품 팀이 문제를 더 쉽게 분석 및 디버그하고 성능을 개선할 수 있도록 서비스 구성 요소를 통해 처리되는 요청을 추적합니다.

 **원하는 결과:** 모든 구성 요소를 포괄적으로 추적할 수 있는 워크로드는 디버그하기 쉬우므로 근본 원인 찾기를 단순화하여 오류의 [평균 해결 시간(MTTR)](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html) 및 지연 시간이 개선됩니다. 엔드 투 엔드 추적은 영향을 받는 구성 요소를 찾고 오류 또는 지연 시간의 근본 원인을 자세히 조사하는 데 걸리는 시간을 줄여줍니다. 

 **일반적인 안티 패턴:** 
+  추적이 모든 구성 요소가 아니라 일부 구성 요소에서만 사용됩니다. 예를 들어 AWS Lambda를 추적하지 않으면 팀이 급증하는 워크로드에서 콜드 스타트로 인한 지연 시간을 명확하게 이해하지 못할 수 있습니다. 
+  Synthetic canary 또는 실제 사용자 모니터링(RUM)이 추적이 가능하도록 구성되지 않습니다. Canary 또는 RUM이 없으면 추적 분석에서 클라이언트 상호 작용 원격 측정이 생략되어 불완전한 성능 프로파일이 생성됩니다. 
+  하이브리드 워크로드에 클라우드 네이티브 및 타사 추적 도구가 모두 포함되지만 단일 추적 솔루션을 선택하고 완전히 통합하는 단계는 아직 수행하지 않았습니다. 선택한 추적 솔루션에 따라 클라우드 네이티브 추적 SDK를 사용하여 클라우드 네이티브가 아닌 구성 요소를 측정하거나 타사 도구를 클라우드 네이티브 추적 텔레메트리를 수집하도록 구성해야 합니다. 

 **이 모범 사례 확립의 이점:** 개발 팀은 문제에 대한 경고를 받으면 구성 요소별 로깅, 성능, 장애와의 상관 관계를 포함하여 시스템 구성 요소 상호 작용을 종합적으로 파악할 수 있습니다. 추적을 통해 근본 원인을 시각적으로 쉽게 식별할 수 있으므로 근본 원인을 조사하는 데 소요되는 시간이 줄어듭니다. 구성 요소 상호 작용을 자세히 이해하는 팀은 문제를 해결할 때 더 현명하고 빠른 의사 결정을 내릴 수 있습니다. 시스템 추적을 분석하면 재해 복구(DR) 장애 조치를 언제 실행할지, 자가 복구 전략을 가장 잘 구현할 수 있는 위치 등을 더 제대로 결정할 수 있어 궁극적으로 서비스에 대한 고객 만족도를 향상시킬 수 있습니다. 

 **이 모범 사례가 확립되지 않았을 경우의 위험 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>

 분산된 애플리케이션을 운영하는 팀은 추적 도구를 사용하여 상관 관계 식별자를 설정하고 요청 추적을 수집하며 연결된 구성 요소의 서비스 맵을 구축할 수 있습니다. 서비스 클라이언트, 미들웨어 게이트웨이 및 이벤트 버스, 컴퓨팅 구성 요소, 키 값 저장소 및 데이터베이스가 포함된 스토리지 등 모든 애플리케이션 구성 요소가 요청 추적에 포함되어야 합니다. 서비스 수준 계약과 목표에 대해 시스템 성능을 정확하게 평가할 수 있도록 엔드 투 엔드 추적 구성에 Synthetic canary와 실제 사용자 모니터링을 포함하여 원격 클라이언트 상호 작용과 지연 시간을 측정합니다. 

 이때 [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 및 [Amazon CloudWatch 애플리케이션 모니터링](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html) 계측 서비스를 사용하여 요청이 애플리케이션을 통과하는 동안 요청에 대한 전체 보기를 제공할 수 있습니다. X-Ray를 통해 애플리케이션 텔레메트리를 수집하여 페이로드, 함수, 추적, 서비스, API에서 이를 시각화하고 필터링할 수 있으며 노코드 또는 로우 코드 시스템 구성 요소에 대해 활성화할 수 있습니다. CloudWatch 애플리케이션 모니터링에는 추적을 지표, 로그, 경보와 통합하는 ServiceLens가 포함됩니다. 또한 CloudWatch 애플리케이션 모니터링에는 엔드포인트와 API를 모니터링하기 위한 Synthetics와 웹 애플리케이션 클라이언트를 측정하기 위한 실제 사용자 모니터링도 포함됩니다. 

## 구현 단계
<a name="implementation-steps"></a>
+  AWS X-Ray를 모든 지원되는 네이티브 서비스(예: [Amazon S3, AWS Lambda, Amazon API Gateway](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html))에서 사용합니다. 이러한 AWS 서비스에서는 코드형 인프라, AWS SDK 또는 AWS Management Console을 사용하여 구성 토글을 통해 X-Ray가 활성화됩니다. 
+  애플리케이션 계측 [AWS Distro for Open Telemetry 및 X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html) 또는 타사 수집 에이전트. 
+ 프로그래밍 언어별 구현은 [AWS X-Ray 개발자 가이드를](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 참조하십시오. 이러한 설명서 섹션에서는 애플리케이션 프로그래밍 언어와 관련된 HTTP 요청, SQL 쿼리 및 기타 프로세스의 계측 방법을 자세히 설명합니다.
+  X-Ray 추적을 [Amazon CloudWatch Synthetic Canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 및 [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 에 사용하여 최종 사용자 클라이언트에서 다운스트림 AWS 인프라를 통한 요청 경로를 분석합니다. 
+  팀이 문제에 대해 빠르게 경고를 받은 후 ServiceLens를 사용하여 추적 및 서비스 맵을 심층적으로 분석할 수 있도록 리소스 상태와 canary 텔레메트리를 기반으로 CloudWatch 추적 및 경보를 구성합니다. 
+  기본 추적 솔루션에 타사 도구를 사용하는 경우 [Datadog](https://docs.datadoghq.com/tracing/guide/serverless_enable_aws_xray/), [New Relic](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-x-ray-monitoring-integration/)또는 [Dynatrace](https://www.dynatrace.com/support/help/setup-and-configuration/setup-on-cloud-platforms/amazon-web-services/amazon-web-services-integrations/aws-service-metrics) 와 같은 타사 추적 도구에 대한 X-Ray 통합을 활성화합니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [REL06-BP01 워크로드의 모든 구성 요소 모니터링(생성)](rel_monitor_aws_resources_monitor_resources.md) 
+  [REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지](rel_withstand_component_failures_monitoring_health.md) 

 **관련 문서:** 
+  [AWS X-Ray란 무엇인가요?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 
+ [ Amazon CloudWatch: 애플리케이션 모니터링 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html)
+  [Amazon CloudWatch Synthetics 및 AWS X-Ray를 사용한 디버깅](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 
+  [Amazon Builders' Library: 운영 가시성을 위한 분산 시스템 계측](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+ [AWS X-Ray를 다른 AWS 서비스와 통합 ](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html)
+ [AWS Distro for OpenTelemetry 및 AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html)
+ [ Amazon CloudWatch: 합성 모니터링 사용 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [ Amazon CloudWatch: CloudWatch RUM 사용 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [ Amazon CloudWatch synthetics canary 및 Amazon CloudWatch 경보 설정 ](https://docs.aws.amazon.com/solutions/latest/devops-monitoring-dashboard-on-aws/set-up-amazon-cloudwatch-synthetics-canary-and-amazon-cloudwatch-alarm.html)
+ [ 가용성과 그 이후: AWS에 배포된 시스템의 복원력 파악 및 개선 ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html)

 **관련 예시:** 
+ [ One Observability Workshop ](https://catalog.workshops.aws/observability/en-US)

 **관련 동영상:** 
+ [AWS re:Invent 2022 - How to monitor applications across multiple accounts(여러 계정의 애플리케이션을 모니터링하는 방법) ](https://www.youtube.com/watch?v=kFGOkywu-rw)
+ [AWS 애플리케이션을 모니터링하는 방법 ](https://www.youtube.com/watch?v=UxWU9mrSbmA)

 **관련 도구:** 
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/pm/cloudwatch/)
+ [ Amazon Route 53 ](https://aws.amazon.com/route53/)

# REL 7. 수요 변경에 따라 조정되도록 워크로드를 설계하려면 어떻게 해야 합니까?
<a name="rel-07"></a>

확장 가능한 워크로드는 리소스를 자동으로 추가하거나 제거하여 특정 시기의 수요에 리소스 공급을 맞출 수 있는 탄력성을 제공합니다.

**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 리소스를 확보하거나 조정할 때 자동화 사용
<a name="rel_adapt_to_changes_autoscale_adapt"></a>

 손상된 리소스를 교체하거나 워크로드 크기를 조정할 때 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을 사용하여 트래픽의 대규모 증가에 대응 
+  고도의 상태 저장 애플리케이션을 배포하여 탄력성 옵션을 없앰 

 **이 모범 사례 수립의 이점:** 자동화는 리소스를 배포하고 폐기할 때 수작업으로 인한 오류가 발생할 가능성을 없앱니다. 자동화는 배포 또는 폐기 요구 사항에 대한 느린 대응으로 인해 비용이 초과하거나 서비스가 거부될 위험성을 없앱니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  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에서만 액세스할 수 있도록 할 수 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 워크로드 장애 감지 시 리소스 확보
<a name="rel_adapt_to_changes_reactive_adapt_auto"></a>

 가용성이 영향을 받는 경우 필요에 따라 리소스를 사후에 확장하여 워크로드 가용성을 복원합니다. 

 먼저 상태 확인과 이러한 확인에 대한 기준을 구성하여 리소스 부족으로 인해 가용성이 영향을 받는 시기를 나타내야 합니다. 그런 다음 적절한 담당자에게 수동으로 리소스 규모를 조정하도록 알리거나 자동화를 시작하여 자동으로 리소스 규모를 조정합니다. 

 워크로드에 맞게 수동으로 규모를 조정할 수 있습니다. 예를 들어 AWS Management Console 또는 AWS CLI를 통해 Auto Scaling 그룹의 EC2 인스턴스 수를 변경하거나 DynamoDB 테이블의 처리량을 수정할 수 있습니다. 하지만 가능하면 자동화를 사용해야 합니다. **리소스를 확보하거나 조정할 때 자동화 사용**을 참조하세요. 

 **원하는 결과:** 장애 또는 고객 경험 저하가 감지되면 가용성을 복원하기 위해 규모 조정 활동(자동 또는 수동)이 시작됩니다. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 중간 

## 구현 가이드
<a name="implementation-guidance"></a>

 워크로드의 모든 구성 요소에 대한 관찰성 및 모니터링을 구현하여 고객 경험을 모니터링하고 장애를 감지합니다. 필요한 리소스의 규모를 조정하는 절차를 수동 또는 자동으로 정의합니다. 자세한 내용은 [REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html)를 참조하세요. 

### 구현 단계
<a name="implementation-steps"></a>
+  필요한 리소스 규모를 조정하는 절차를 수동 또는 자동으로 정의합니다. 
  +  규모 조정 절차는 워크로드 내의 다양한 구성 요소가 어떻게 설계되었는지에 따라 달라집니다. 
  +  규모 조정 절차는 사용되는 기본 기술에 따라서도 달라집니다. 
    +  AWS Auto Scaling을 사용하는 구성 요소는 규모 조정 계획을 사용하여 리소스 규모 조정을 위한 일련의 지침을 구성할 수 있습니다. AWS CloudFormation을 사용하거나 AWS 리소스에 태그를 추가하는 경우 애플리케이션마다 서로 다른 리소스 세트에 규모 조정 계획을 설정할 수 있습니다. Auto Scaling은 각 리소스에 맞춤화된 규모 조정 전략에 대한 권장 사항을 제공합니다. 규모 조정 계획을 생성하면 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은 그룹이 이러한 기준에 미달하거나 기준을 초과하지 않도록 합니다. 자세한 내용은 [What is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)을 참조하세요. 
    +  Amazon DynamoDB Auto Scaling은 Application Auto Scaling 서비스를 사용하여 사용자를 대신해 실제 트래픽 패턴에 따라 프로비저닝된 처리량 용량을 동적으로 조정합니다. 따라서 테이블 또는 글로벌 보조 인덱스가 프로비저닝된 읽기 및 쓰기 용량을 늘려 제한 없이 급증하는 트래픽을 처리할 수 있습니다. 자세한 내용은 [DynamoDB Auto Scaling을 통한 처리량 자동 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)를 참조하세요. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+ [ REL07-BP01 리소스를 확보하거나 조정할 때 자동화 사용 ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_adapt_to_changes_autoscale_adapt.html)
+  [REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html) 

 **관련 문서:** 
+  [AWS Auto Scaling: 크기 조정 계획 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
+  [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 워크로드에 더 많은 리소스가 필요한 것으로 감지되면 리소스 확보
<a name="rel_adapt_to_changes_proactive_adapt_auto"></a>

 수요를 충족하고 가용성에 영향을 미치지 않도록 리소스를 사전에 확장합니다. 

 많은 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개의 인스턴스가 필요합니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  워크로드에 더 많은 리소스가 필요한 것으로 감지되면 리소스를 확보합니다. 수요를 충족하고 가용성에 영향을 미치지 않도록 리소스를 사전에 확장합니다. 
  +  지정된 요청 속도를 처리하는 데 필요한 컴퓨팅 리소스(컴퓨팅 동시성)를 계산합니다. 
    +  [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/) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 워크로드 로드 테스트
<a name="rel_adapt_to_changes_load_tested_adapt"></a>

 확장 작업이 워크로드의 필요 사항을 충족하는지 측정하기 위한 로드 테스트 방식을 채택하십시오. 

 지속적인 로드 테스트를 수행하는 것이 중요합니다. 로드 테스트를 통해 한계점을 찾고 워크로드의 성능을 테스트할 수 있습니다. AWS를 사용하면 프로덕션 워크로드의 규모를 모델링하는 임시 테스트 환경을 쉽게 설정할 수 있습니다. 클라우드에서는 온디맨드 방식으로 프로덕션 규모의 테스트 환경을 만들고, 테스트를 완료한 다음 해당 리소스를 폐기할 수 있습니다. 테스트 환경을 실행하는 동안에만 비용을 지불하면 되기 때문에 온프레미스 테스트 비용의 몇 분의 일에 불과한 가격으로 실제 환경을 시뮬레이션할 수 있습니다. 

 또한 프로덕션에서의 로드 테스트는 프로덕션 시스템에 스트레스가 가해지는 실전 연습의 일부로 간주되어야 하며 고객 사용량이 적은 시간에는 모든 직원이 결과를 해석하고 발생하는 문제를 해결해야 합니다. 

 **일반적인 안티 패턴:** 
+  구성이 프로덕션 환경과 동일하지 않은 배포에 대해 로드 테스트 수행 
+  전체 워크로드가 아니라 워크로드의 개별 부분에 대해서만 로드 테스트 수행 
+  대표적인 실제 요청 세트가 아니라 요청의 하위 집합을 사용하여 로드 테스트 수행 
+  예상 부하보다 작은 안전 계수로 부하 테스트 수행 

 **이 모범 사례 수립의 이점:** 로드 시 장애가 발생하는 아키텍처의 구성 요소를 알고 있으며, 해당 로드에 곧 도달할 것임을 나타내는 지표를 식별하고 조사하여 문제를 해결할 수 있습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  로드 테스트를 수행하여 워크로드의 어느 측면에 용량을 추가 또는 제거해야 하는지 파악합니다. 로드 테스트에는 프로덕션 환경에서 수신하는 것과 유사한 대표 트래픽이 있어야 합니다. 계측한 지표를 모니터링하면서 로드를 늘려 리소스를 추가 또는 제거해야 하는 시점을 나타내는 지표를 결정합니다. 
  +  [AWS에서의 분산 로드 테스트: 수천 명의 연결된 사용자 시뮬레이션](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 
    +  요청의 조합을 식별합니다. 다양한 요청 조합이 있을 수 있으므로 트래픽 조합을 식별할 때 다양한 시간 프레임을 살펴봐야 합니다. 
    +  로드 드라이버를 구현합니다. 사용자 지정 코드, 오픈 소스 또는 상용 소프트웨어를 사용하여 로드 드라이버를 구현할 수 있습니다. 
    +  처음에는 작은 용량을 사용하여 로드 테스트를 수행합니다. 인스턴스 또는 컨테이너 하나 정도의 작은 용량으로 로드를 유도하면 즉각적인 효과가 나타납니다. 
    +  더 큰 용량에 대해 로드 테스트를 수행합니다. 분산된 부하에서는 효과가 다르게 나타나므로 가능한 한 제품 환경에 가깝게 테스트해야 합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS에서의 분산 로드 테스트: 수천 명의 연결된 사용자 시뮬레이션](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 

# REL 8. 변경 사항은 어떻게 적용합니까?
<a name="rel-08"></a>

새로운 기능을 배포하고 워크로드와 운영 환경에서 알려진 소프트웨어를 실행하고 예측 가능한 방식으로 패치 또는 교체할 수 있도록 하려면 변경 사항을 제어해야 합니다. 이러한 변경이 제어되지 않으면 변경의 영향을 예측하거나 변경으로 인해 발생하는 문제를 해결하기가 어려워집니다. 

**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 배포와 같은 표준 활동에 런북 사용
<a name="rel_tracking_change_management_planned_changemgmt"></a>

 런북은 특정 결과를 달성하기 위한 미리 정의된 절차입니다. 수동 또는 자동으로 표준 활동을 수행할 때 런북을 사용합니다. 워크로드 배포, 워크로드 패치 적용 또는 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) 엄격한 보고 및 감사 요구 사항을 충족할 때 런북을 유용하게 사용할 수 있습니다. 

 플레이북은 특정 인시던트에 대응하여 사용되며 런북은 특정 결과를 달성하기 위해 사용됩니다. 런북은 일상적인 활동에 대한 것이고, 플레이북은 일상적이지 않은 이벤트에 대응하는 데 사용되는 경우가 많습니다. 

 **일반적인 안티 패턴:** 
+  프로덕션 환경에서 계획되지 않은 구성 변경 수행 
+  더 빠르게 배포하기 위해 계획의 단계를 건너뛰고, 그 결과 배포에 실패 
+  변경 사항 되돌리기를 테스트하지 않고 변경 수행 

 **이 모범 사례 수립의 이점:** 변경 계획을 효과적으로 수립하면 영향을 받는 모든 시스템을 파악할 수 있으므로 변경 사항을 성공적으로 실행할 수 있습니다. 테스트 환경에서 변경 사항을 검증하면 신뢰성을 높일 수 있습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  런북에 절차를 문서화하면 잘 알려진 이벤트에 일관된 방식으로 신속하게 대응할 수 있습니다. 
  +  [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) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 배포의 일부로 기능 테스트 통합
<a name="rel_tracking_change_management_functional_testing"></a>

 기능 테스트는 자동화된 배포의 일부로 실행됩니다. 성공 기준이 충족되지 않으면 파이프라인이 중지되거나 롤백됩니다. 

 이러한 테스트는 파이프라인에서 프로덕션 전에 준비되는 사전 프로덕션 환경에서 실행됩니다. 이 작업을 배포 파이프라인의 일부로 수행하는 것이 가장 좋습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  배포의 일부로 기능 테스트를 통합합니다. 기능 테스트는 자동화된 배포의 일부로 실행됩니다. 성공 기준이 충족되지 않으면 파이프라인이 중지되거나 롤백됩니다. 
  +  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) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 배포의 일부로 복원력 테스트 통합
<a name="rel_tracking_change_management_resiliency_testing"></a>

 복원력 테스트( [카오스 엔지니어링의 원칙 사용)](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). 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  배포의 일부로 복원력 테스트를 통합합니다. 프로덕션 환경에서 격변의 조건을 견딜 수 있는 워크로드의 기능에 대한 신뢰성을 확보하기 위해 시스템을 실험하는 분야인 카오스 엔지니어링을 사용합니다. 
  +  복원력 테스트는 결함 또는 리소스 저하를 발생시켜 워크로드가 설계된 복원력으로 대응하는지 평가합니다. 
    +  [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/) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 변경 불가능한 인프라를 사용하여 배포
<a name="rel_tracking_change_management_immutable_infrastructure"></a>

 변경 불가능한 인프라는 프로덕션 워크로드의 현재 위치에서 업데이트, 보안 패치 또는 구성 변경이 발생하지 않도록 규정하는 모델입니다. 변경이 필요한 경우 아키텍처가 새 인프라에 구축되고 프로덕션 환경에 배포됩니다. 

 변경 불가능한 인프라 배포 전략을 따라 워크로드 배포의 신뢰성, 일관성 및 재현성을 높입니다. 

 **원하는 결과:** 변경 불가능한 인프라를 사용했을 때 워크로드 내에서 인프라 리소스를 실행하기 위한 [인플레이스 수정](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/in-place-deployments.html)이 허용되지 않습니다. 대신 변경이 필요한 경우 필요한 변경 사항이 모두 포함하도록 업데이트된 신규 인프라 리소스 세트를 기존 리소스와 병렬로 배포합니다. 이 배포는 자동으로 검증되며, 성공하면 트래픽이 점차 새로운 리소스 세트로 이동합니다. 

 이 배포 전략은 소프트웨어 업데이트, 보안 패치, 인프라 변경, 구성 업데이트, 애플리케이션 업데이트 등에 적용됩니다. 

 **일반적인 안티 패턴:** 
+  실행 중인 인프라 리소스에 인플레이스 변경을 구현합니다. 

 **이 모범 사례 확립의 이점:** 
+  **환경 간 일관성 향상:** 환경 간에 인프라 리소스의 차이가 없으므로 일관성이 향상되고 테스트가 간소화됩니다. 
+  **구성 드리프트 감소:** 인프라 리소스를 버전이 관리되는 알려진 구성으로 대체하면 인프라가 테스트를 거쳐 신뢰할 수 있는 알려진 상태로 설정되므로 구성 드리프트가 발생하지 않습니다. 
+  **신뢰할 수 있는 원자 단위 배포:** 배포가 성공적으로 완료되거나 변경 사항이 없으므로 배포 프로세스의 일관성과 신뢰성이 향상됩니다. 
+  **간소화된 배포:** 업그레이드를 지원할 필요가 없으므로 배포가 간소화됩니다. 업그레이드는 단지 새로운 배포일 뿐입니다. 
+  **빠른 롤백 및 복구 프로세스를 통해 배포 안전성 개선:** 이전 작업 버전이 변경되지 않으므로 배포가 더 안전합니다. 오류가 감지되면 롤백할 수 있습니다. 
+  **보안 태세 강화:** 인프라 변경을 허용하지 않음으로써 원격 액세스 메커니즘(예: SSH)을 비활성화할 수 있습니다. 이렇게 하면 공격 벡터가 줄어들어 조직의 보안 태세를 개선할 수 있습니다. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 중간 

## 구현 가이드
<a name="implementation-guidance"></a>

 **자동화** 

 변경 불가능한 인프라 배포 전략을 정의할 때는 재현성을 높이고 인적 오류 가능성을 최소화하기 위해 최대한 [자동화](https://aws.amazon.com/iam/)를 사용하는 것이 좋습니다. 자세한 내용은 [REL08-BP05 자동화를 통한 변경 사항 배포](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_automated_changemgmt.html) 및 [안전한 자동 배포 자동화](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)를 참조하세요. 

 [코드형 인프라(IaC)](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)를 사용하면 인프라 프로비저닝, 오케스트레이션 및 배포 단계가 프로그래밍, 설명 및 선언적 방식으로 정의되고 소스 제어 시스템에 저장됩니다. 코드형 인프라를 활용하면 인프라 배포를 더 간단하게 자동화할 수 있고 인프라 불변성을 달성하는 데 도움이 됩니다. 

 **배포 패턴** 

 워크로드 변경이 필요한 경우 변경 불가능한 인프라 배포 전략에서는 필요한 모든 변경을 포함하여 새로운 인프라 리소스 세트를 배포해야 합니다. 이 새로운 리소스 세트는 사용자에게 미치는 영향을 최소화하는 롤아웃 패턴을 따르는 것이 중요합니다. 이 배포에는 두 가지 주요 전략이 있습니다. 

 [https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html): 일반적으로 단일 서비스 인스턴스에서 실행되는 새 버전(Canary)으로 소수의 사용자를 연결하는 방식입니다. 그런 다음 생성되는 동작 변경 또는 오류를 면밀히 조사합니다. 중대한 문제가 발생하여 사용자에게 이전 버전을 다시 제공해야 하는 경우에는 Canary에서 트래픽을 제거할 수 있습니다. 배포가 정상적으로 진행되면 배포가 완료될 때까지 변경 사항에서 오류를 모니터링하면서 원하는 속도로 배포를 계속 진행할 수 있습니다. 카나리 배포를 지원하는 [배포 구성](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)을 사용하여 AWS CodeDeploy를 구성할 수 있습니다. 

 [https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html): 카나리 배포와 비슷합니다. 단, 전체 애플리케이션 플릿이 병렬로 배포됩니다. 이 패턴에서는 블루와 그린의 두 스택에서 번갈아 가며 배포를 수행합니다. 이 패턴에서도 새 버전으로 트래픽을 전송한 다음 배포에 문제가 발생하면 이전 버전으로 장애 복구할 수 있습니다. 일반적으로 모든 트래픽이 한 번에 전환되지만, Amazon Route 53의 가중치 기반 DNS 라우팅 기능을 사용하면 각 버전에 대한 트래픽의 일부를 사용하여 새 버전의 채택을 유도할 수도 있습니다. 블루/그린 배포를 지원하는 배포 구성을 사용하여 AWS CodeDeploy와 [AWS Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2020-05-18-ts-deploy.html)를 구성할 수 있습니다. 

![\[Diagram showing blue/green deployment with AWS Elastic Beanstalk and Amazon Route 53\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/images/blue-green-deployment.png)


 **드리프트 감지** 

 *드리프트*는 인프라 리소스의 상태 또는 구성이 예상과 달라지게 하는 모든 변경으로 정의됩니다. 모든 유형의 관리되지 않는 구성 변경은 변경 불가능한 인프라의 개념에 어긋나므로 변경 불가능한 인프라를 성공적으로 구현하려면 이를 감지하고 수정해야 합니다. 

### 구현 단계
<a name="implementation-steps"></a>
+  실행 중인 인프라 리소스의 인플레이스 수정을 허용하지 않습니다. 
  +  [AWS Identity and Access Management(IAM)](https://aws.amazon.com/iam/)를 사용하여 AWS에서 서비스 및 리소스에 액세스할 수 있는 사용자 또는 대상을 지정하고, 세분화된 권한을 중앙에서 관리하고, 액세스를 분석하여 AWS 전체의 권한을 세분화할 수 있습니다. 
+  인프라 리소스 배포를 자동화하여 재현성을 높이고 인적 오류 가능성을 최소화합니다. 
  +  [AWS 기반 DevOps 소개 백서](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)에 설명되어 있는 것처럼 자동화는 AWS 서비스의 초석이며 모든 서비스, 기능 및 오퍼링에서 내부적으로 지원됩니다. 
  +  Amazon Machine Image(AMI)를 *[프리베이킹](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/prebaking-vs.-bootstrapping-amis.html)*하면 시작 시간을 단축할 수 있습니다. [EC2 Image Builder](https://aws.amazon.com/image-builder/)는 사용자 지정되고 안전한 최신 Linux 또는 Windows 사용자 지정 AMI의 생성, 유지 관리, 검증, 공유 및 배포를 자동화하는 데 도움이 되는 완전관리형 AWS 서비스입니다. 
  +  자동화를 지원하는 서비스의 예를 몇 가지 들자면 다음과 같습니다. 
    +  [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/)는 Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker로 개발한 웹 애플리케이션을 Apache, NGINX, Passenger, IIS 등의 친숙한 서버에 빠르게 배포하고 규모를 조정할 수 있는 서비스입니다. 
    +  [AWS Proton](https://aws.amazon.com/proton/)은 개발 팀이 인프라 프로비저닝, 코드 배포, 모니터링 및 업데이트에 필요한 모든 도구를 플랫폼 팀이 연결하고 조정할 수 있도록 지원합니다. AWS Proton은 서버리스 및 컨테이너 기반 애플리케이션의 코드형 인프라 자동 프로비저닝 및 배포를 지원합니다. 
  +  코드형 인프라를 활용하면 인프라 배포를 쉽게 자동화할 수 있고 인프라 불변성을 달성하는 데 도움이 됩니다. AWS는 프로그래밍, 설명 및 선언적 방식으로 인프라를 생성, 배포 및 유지 관리할 수 있는 서비스를 제공합니다. 
    +  [AWS CloudFormation](https://aws.amazon.com/cloudformation/)은 개발자가 질서 있고 예측 가능한 방식으로 AWS 리소스를 만들 수 있도록 도와줍니다. 리소스는 JSON 또는 YAML 형식을 사용하여 텍스트 파일로 작성됩니다. 템플릿에는 생성 및 관리되는 리소스 유형에 따라 특정 구문과 구조가 필요합니다. AWS Cloud9 등의 코드 편집기를 사용하여 JSON 또는 YAML로 리소스를 작성하고 이를 버전 관리 시스템에 체크인하면 CloudFormation이 명시된 서비스를 안전하고 반복 가능한 방식으로 구축합니다. 
    +  [AWS Serverless Application Model(AWS SAM)](https://aws.amazon.com/serverless/sam/)은 AWS에서 서버리스 애플리케이션을 구축하는 데 사용할 수 있는 오픈 소스 프레임워크입니다. AWS SAM은 다른 AWS 서비스와 통합되며 CloudFormation 서비스가 확장된 것입니다. 
    +  [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/)는 친숙한 프로그래밍 언어를 사용하여 클라우드 애플리케이션 리소스를 모델링하고 프로비저닝하는 오픈 소스 소프트웨어 개발 프레임워크입니다. TypeScript, Python, Java 및 .NET을 사용하여 애플리케이션 인프라를 모델링하는 데 AWS CDK를 사용할 수 있습니다. AWS CDK는 백그라운드에서 CloudFormation을 사용하여 안전하고 반복 가능한 방식으로 리소스를 프로비저닝합니다. 
    +  [AWS Cloud Control API](https://aws.amazon.com/cloudcontrolapi/)는 개발자들이 쉽고 일관된 방식으로 클라우드 인프라를 관리할 수 있도록 Create, Read, Update, Delete, List(CRUDL) API로 구성된 일반적인 세트를 제공합니다. 개발자는 일반적인 Cloud Control API API를 사용하여 AWS 서비스와 서드 파티 서비스의 수명 주기를 일관적으로 관리할 수 있습니다. 
+  사용자에게 미치는 영향을 최소화하는 배포 패턴을 구현합니다. 
  +  카나리 배포: 
    + [ API Gateway Canary 릴리스 배포 설정 ](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
    + [ Create a pipeline with canary deployments for Amazon ECS using AWS App Mesh](https://aws.amazon.com/blogs/containers/create-a-pipeline-with-canary-deployments-for-amazon-ecs-using-aws-app-mesh/)
  +  블루/그린 배포: [AWS에서의 블루/그린 배포 백서](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html)에서는 블루/그린 배포 전략을 구현하는 [예시 기법](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/implementation-techniques.html)을 설명합니다. 
+  구성 또는 상태 드리프트를 감지합니다. 자세한 내용은 [스택 및 리소스에 대한 비관리형 구성 변경 감지](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)를 참조하세요. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+ [ REL08-BP05 자동화를 통한 변경 사항 배포 ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_automated_changemgmt.html)

 **관련 문서:** 
+ [안전한 자동 배포 자동화](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [ Leveraging AWS CloudFormation to create an immutable infrastructure at Nubank ](https://aws.amazon.com/blogs/mt/leveraging-immutable-infrastructure-nubank/)
+ [Infrastructure as Code](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)
+ [ Implementing an alarm to automatically detect drift in AWS CloudFormation stacks ](https://docs.aws.amazon.com/blogs/mt/implementing-an-alarm-to-automatically-detect-drift-in-aws-cloudformation-stacks/)

 **관련 동영상:** 
+ [AWS re:Invent 2020: Reliability, consistency, and confidence through immutability ](https://www.youtube.com/watch?v=jUSYnRztttY)

# REL08-BP05 자동화를 통한 변경 사항 배포
<a name="rel_tracking_change_management_automated_changemgmt"></a>

 배포 및 패치 적용이 자동화되므로 부정적인 영향이 제거됩니다. 

 프로덕션 시스템을 변경하는 것은 조직에서 가장 위험 부담이 큰 영역에 속합니다. 배포는 소프트웨어를 통해 해결할 수 있는 업무상의 문제와 더불어 해결해야 하는 가장 중요한 문제로 간주됩니다. 오늘날에는 배포 관련 문제를 해결하려면 운영 과정에서 해당하는 모든 영역(변경 사항 테스트/배포, 용량 추가/제거, 데이터 마이그레이션 포함)에 자동화를 사용해야 합니다. AWS CodePipeline을 사용하면 워크로드를 해제하는 데 필요한 단계를 관리할 수 있습니다. 여기에는 AWS CodeDeploy를 사용하여 Amazon EC2 인스턴스, 온프레미스 인스턴스, 서버리스 Lambda 함수 또는 Amazon ECS 서비스에 대한 애플리케이션 코드 배포를 자동화하는 배포 상태가 포함됩니다. 

**권장 사항**  
 일반적인 통념으로는 가장 어려운 작업 절차에 사람을 투입하는 것이 좋다고 하지만 AWS에서는 바로 그런 이유로 가장 어려운 절차를 자동화할 것을 권장합니다. 

 **일반적인 안티 패턴:** 
+  수동으로 변경 수행 
+  비상 워크플로를 통해 자동화 단계를 건너뜀 
+  계획을 따르지 않음 

 **이 모범 사례 수립의 이점:** 자동화를 사용하여 모든 변경 사항을 배포하면 인적 오류가 발생할 가능성이 사라지고 프로덕션을 변경하기 전에 테스트하여 계획이 완료되었는지 확인할 수 있습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  배포 파이프라인을 자동화합니다. 배포 파이프라인을 사용하면 이상 징후의 자동 테스트 및 탐지를 실행하여 프로덕션 배포 전 특정 단계에서 파이프라인을 중지하거나 변경 사항을 자동으로 롤백할 수 있습니다. 
  +  [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) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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) 

# 장애 관리
<a name="a-failure-management"></a>

**Topics**
+ [REL 9. 데이터는 어떻게 백업합니까?](rel-09.md)
+ [REL 10. 장애 격리를 사용하여 워크로드를 보호하려면 어떻게 해야 합니까?](rel-10.md)
+ [REL 11. 구성 요소 장애를 견디도록 워크로드를 설계하려면 어떻게 해야 하나요?](rel-11.md)
+ [REL 12. 안정성은 어떻게 테스트합니까?](rel-12.md)
+ [REL 13. DR(재해 복구)를 어떻게 계획합니까?](rel-13.md)

# REL 9. 데이터는 어떻게 백업합니까?
<a name="rel-09"></a>

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 백업해야 하는 모든 데이터 확인 및 백업 또는 소스에서 데이터 복제
<a name="rel_backing_up_data_identified_backups_data"></a>

워크로드에 사용되는 데이터 서비스 및 리소스의 백업 기능을 숙지하고 사용합니다. 대부분의 서비스는 워크로드 데이터를 백업할 수 있는 기능을 제공합니다. 

 **원하는 결과:** 데이터 소스가 식별되고 중요도에 따라 분류됩니다. 그런 다음 RPO에 따라 데이터 복구 전략을 수립합니다. 이 전략에는 데이터 소스 백업 또는 다른 소스에서 데이터를 복제하는 기능이 포함됩니다. 데이터가 손실될 경우 구현된 전략에 따라 정의된 RPO 또는 RTO 내에 복구 또는 데이터 재현이 가능합니다. 

 **클라우드 성숙도 단계:** 기초 

 **일반적인 안티 패턴:** 
+  워크로드의 모든 데이터 소스와 그 중요도를 알지 못합니다. 
+  중요한 데이터 소스의 백업을 생성하지 않습니다. 
+  중요도를 기준으로 사용하지 않고 일부 데이터 소스의 백업만 생성합니다. 
+  RPO가 정의되지 않았거나 백업 주기가 RPO에 부합하지 않습니다. 
+  백업이 필요한지 또는 데이터를 다른 소스에서 복제할 수 있는지 평가하지 않습니다. 

 **이 모범 사례 확립의 이점:** 백업이 필요한 지점을 파악하고 백업 생성을 위한 메커니즘을 구현하거나 외부 소스에서 데이터를 복제할 수 있는 경우 중단 시 데이터를 복원하고 복구하는 역량이 향상됩니다. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 모든 AWS 데이터 스토어는 백업 기능을 제공합니다. Amazon RDS 및 Amazon DynamoDB 등의 서비스는 추가적으로 시점 복구(PITR)를 활성화하는 자동화된 백업을 지원합니다. 따라서 현재 시간으로부터 최대 5분 전까지 원하는 시점으로 백업을 복원할 수 있습니다. 많은 AWS 서비스는 백업을 다른 AWS 리전으로 복사할 수 있는 기능을 제공합니다. AWS Backup 도구는 AWS 서비스 전체에서 데이터 보호를 중앙 집중화하고 자동화하는 기능을 제공합니다. [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)를 사용하면 초 단위로 측정되는 Recovery Point Objective(RPO)를 사용하여 전체 서버 워크로드를 복사하고 온프레미스, 크로스 AZ 또는 크로스 리전에서 지속적인 데이터 보호를 유지할 수 있습니다. 

 Amazon S3는 자체 관리형 및 AWS 관리형 데이터 소스의 백업 목적지로 사용할 수 있습니다. Amazon EBS, Amazon RDS, Amazon DynamoDB 등의 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)를 사용하여 AWS 클라우드에 백업할 수 있습니다. Amazon S3 버킷을 사용하여 이 데이터를 AWS에 저장할 수 있습니다. Amazon S3는 데이터 스토리지 비용을 줄이기 위해 [Amazon Glacier 또는 Amazon 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) 또는 [Amazon 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로 작업하는 경우 [Amazon S3에서 Amazon EMR로 데이터를 복제](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/)할 수 있는 한 HDFS 데이터 스토어를 백업할 필요가 없을 수 있습니다. 

 백업 전략을 선택할 때는 데이터 복구에 걸리는 시간을 고려하시기 바랍니다. 데이터를 복구하는 데 필요한 시간은 백업의 유형(백업 전략의 경우) 또는 데이터 복제 메커니즘의 복잡성에 따라 달라집니다. 이 시간은 워크로드의 RTO 이내여야 합니다. 

 **구현 단계** 

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/Amazon/latest/logs/WhatIsLogs.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 Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)는 AWS 리전에 대한 자동화된 1초 미만의 데이터 복제를 처리합니다. 이런 AWS 서비스의 대부분은 백업을 생성하는 기능이 기본적으로 내장되어 있습니다. AWS Marketplace에도 이런 기능을 제공하는 솔루션이 많이 있습니다. 다양한 AWS 서비스에서 데이터 백업을 생성하는 방법에 대한 정보는 아래 나열된 **리소스**를 참조하세요. 

1.  **백업되지 않는 데이터의 경우 데이터 복제 메커니즘을 수립합니다**. 여러 가지 이유로 다른 소스에서 복제될 수 있는 데이터는 백업하지 않기로 결정할 수 있습니다. 백업을 저장하는 데는 비용이 들기 때문에 백업을 생성하기보다는 필요할 때 다른 소스에서 데이터를 복제하는 것이 더 저렴한 상황이 있을 수도 있습니다. 또는 백업을 복원하는 작업이 다른 소스에서 데이터를 복제하는 것보다 더 오래 걸려 RTO를 준수할 수 없을 수도 있습니다. 그런 경우에는 장단점을 비교하여 데이터 복구가 필요할 때 다른 소스에서 데이터를 복제하는 방법에 대한 프로세스를 효과적으로 정의하여 수립해야 합니다. 예를 들면, 분석을 위해 Amazon S3의 데이터를 데이터 웨어하우스(예: Amazon Redshift) 또는 MapReduce 클러스터(예: Amazon EMR)로 로드한 경우 다른 소스에서 데이터를 복제한 예가 될 수 있습니다. 이러한 분석 결과가 어딘가에 저장되어 있거나 재현될 수만 있다면 데이터 웨어하우스 또는 MapReduce 클러스터의 장애로 인해 데이터 손실이 발생하지 않습니다. 소스에서 복제할 수 있는 다른 예로는 캐시(예: Amazon ElastiCache) 또는 RDS 읽기 전용 복제본이 있습니다. 

1.  **데이터 백업 주기를 설정합니다**. 데이터 소스의 백업을 생성하는 일은 주기적으로 이루어져야 하며 빈도는 RPO에 따라 다릅니다. 

 **구현 계획의 작업 수준:** 보통 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 

[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란 무엇입니까?](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) 
+  [Creating an EventBridge Rule That Triggers on a Schedule](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)(일정에 따라 트리거되는 EventBridge 규칙 생성) 
+  Amazon S3로 [리전 간 복제](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) 
+  [EFS-to-EFS AWS Backup](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/) 
+  [Amazon S3로 로그 데이터 내보내기](https://docs.aws.amazon.com/Amazon/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 Elastic Disaster Recovery란 무엇입니까?](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)

 **관련 동영상:** 
+  [AWS re:Invent 2021 - Backup, disaster recovery, and ransomware protection with AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc)(AWS re:Invent 2021 - AWS를 통한 백업, 재해 복구 및 랜섬웨어 보호) 
+  [AWS Backup Demo: Cross-Account and Cross-Region Backup](https://www.youtube.com/watch?v=dCy7ixko3tE)(AWS Backup 데모: 크로스 계정 및 크로스 리전 백업) 
+  [AWS re:Invent 2019: Deep dive on AWS Backup, ft. Rackspace(STG341)](https://youtu.be/av8DpL0uFjc)(AWS re:Invent 2019: AWS Backup 심층 분석, ft. Rackspace(STG341)) 

 **관련 예시:** 
+  [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/) 
+  [Well-Architected lab: Testing Backup and Restore of Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)(Well-Architected 실습: 데이터 백업 및 복원 테스트) 
+  [ Well-Architected Lab - Backup and Restore with Failback for Analytics Workload(Well-Architected 실습 - 분석 워크로드에 대한 백업 및 페일백으로 복원)](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/) 
+  [ Well-Architected Lab - Disaster Recovery - Backup and Restore(Well-Architected 실습 - 재해 복구 - 백업 및 복원)](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/) 

# REL09-BP02 백업 보안 및 암호화
<a name="rel_backing_up_data_secured_backups_data"></a>

인증 및 권한 부여를 사용하여 백업에 대한 액세스를 제어하고 감지합니다. 백업의 데이터 무결성이 침해되었을 경우 암호화 기법을 사용하여 예방 및 감지합니다.

 **일반적인 안티 패턴:** 
+  백업과 복원 자동화에 대한 액세스 권한을 데이터에 대한 액세스 권한과 동일하게 설정 
+  백업을 암호화하지 않음 

 **이 모범 사례 확립의 이점:** 백업의 보안을 유지하면 데이터 변조가 방지되며, 데이터 암호화는 데이터가 실수로 노출될 경우 해당 데이터에 대한 액세스를 방지합니다. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 AWS Identity and Access Management(IAM) 등의 인증 및 권한 부여를 사용하여 백업에 대한 액세스를 제어하고 감지합니다. 백업의 데이터 무결성이 침해되었을 경우 암호화 기법을 사용하여 예방 및 감지합니다. 

 Amazon S3는 유휴 데이터 암호화를 위한 다양한 방법을 지원합니다. Amazon S3는 서버 측 암호화를 사용하여 객체를 암호화되지 않은 데이터로 수락한 다음 저장 시 암호화합니다. 클라이언트측 암호화를 사용하면 데이터가 Amazon S3로 전송되기 전에 워크로드 애플리케이션에서 데이터가 암호화됩니다. 어느 방법을 사용하든 AWS Key Management Service(AWS KMS)를 사용하여 데이터 키를 생성 및 저장하거나 사용자가 관리하는 자체 키를 제공할 수 있습니다. AWS KMS를 사용하면 IAM을 사용하여 데이터 키와 해독된 데이터에 접근할 수 있는 사용자와 접근할 수 없는 사용자에 대한 정책을 설정할 수 있습니다. 

 Amazon RDS의 경우 데이터베이스를 암호화하도록 선택하면 백업도 암호화됩니다. DynamoDB 백업은 항상 암호화됩니다. AWS Elastic Disaster Recovery를 사용하면 전송 중이거나 저장된 모든 데이터가 암호화됩니다. Elastic Disaster Recovery를 사용하면 기본 Amazon EBS 암호화 볼륨 암호화 키 또는 사용자 지정 고객 관리형 키를 사용하여 저장 데이터를 암호화할 수 있습니다. 

 **구현 단계** 

1.  각 데이터 스토어에 암호화를 사용합니다. 소스 데이터가 암호화되면 백업도 암호화됩니다. 
   + [Amazon RDS에서 암호화를 사용합니다](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html). RDS 인스턴스를 생성할 때 AWS Key Management Service를 사용하여 저장 데이터의 암호화를 구성할 수 있습니다. 
   + [Amazon EBS 볼륨에서 암호화를 사용합니다](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html). 볼륨 생성 시 기본 암호화를 구성하거나 고유한 키를 지정할 수 있습니다. 
   +  필수 [Amazon DynamoDB 암호화](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)를 사용합니다. DynamoDB는 모든 저장 데이터를 암호화합니다. 계정에 저장된 키를 지정하여 AWS 소유 AWS KMS 키 또는 AWS 관리형 KMS 키를 사용할 수 있습니다. 
   + [Amazon EFS에 저장된 데이터를 암호화합니다](https://docs.aws.amazon.com/efs/latest/ug/encryption.html). 파일 시스템을 생성할 때 암호화를 구성합니다. 
   +  원본 및 대상 리전에 암호화를 구성합니다. KMS에 저장된 키를 사용하여 Amazon S3에서 저장 데이터 암호화를 구성할 수 있지만 키는 리전별로 다릅니다. 복제를 구성할 때 대상 키를 지정할 수 있습니다. 
   +  기본 또는 사용자 지정 [Amazon EBS 암호화를 Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/volumes-drs.html#ebs-encryption)에 대해 사용할지 여부를 선택합니다. 이 옵션은 스테이징 영역 서브넷 디스크와 복제된 디스크에 복제된 저장 데이터를 암호화합니다. 

1.  백업에 액세스할 수 있는 최소 권한을 구현합니다. [보안 모범 사례](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)에 따라 백업, 스냅샷 및 복제본에 대한 액세스를 제한합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS Marketplace: 백업에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) 
+  [Amazon EBS Encryption](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)(Amazon EBS 암호화) 
+  [Amazon S3: Protecting Data Using Encryption](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html)(Amazon S3: 암호화를 사용하여 데이터 보호) 
+  [CRR Additional Configuration: Replicating Objects Created with Server-Side Encryption (SSE) Using Encryption Keys stored in AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)(CRR 추가 구성: AWS KMS에 저장된 암호화 키를 사용하여 서버 측 암호화(SSE)로 생성된 객체 복제) 
+  [DynamoDB Encryption at Rest](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)(DynamoDB 저장 시 암호화) 
+  [Encrypting Amazon RDS Resources](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)(Amazon RDS 리소스 암호화) 
+  [Encrypting Data and Metadata in Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)(EFS의 데이터 및 메타데이터 암호화) 
+  [Encryption for Backups in AWS](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)(AWS의 백업 암호화) 
+  [암호화된 테이블 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html) 
+  [Security Pillar - AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)(보안 원칙 - AWS Well-Architected Framework) 
+ [AWS Elastic Disaster Recovery란 무엇입니까?](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.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 자동으로 데이터 백업 수행
<a name="rel_backing_up_data_automated_backups_data"></a>

Recovery Point Objective(RPO)에 정의된 정기적인 일정 또는 데이터 세트의 변경에 따라 백업이 자동으로 생성되도록 구성합니다. 적은 데이터 손실을 요구하는 중요한 데이터 세트는 자주 자동으로 백업되어야 합니다. 반면 일부 손실은 용인하는 중요도가 상대적으로 낮은 데이터의 경우 더 낮은 빈도로 백업할 수 있습니다.

 **원하는 결과:** 정해진 주기로 데이터 소스의 백업을 생성하는 자동화된 프로세스 

 **일반적인 안티 패턴:** 
+  수동으로 백업 수행 
+  백업을 지원하는 리소스를 사용하지만 자동화 대상에 백업을 포함하지 않음 

 **이 모범 사례 확립의 이점:** 백업을 자동화하면 RPO를 기준으로 주기적으로 백업이 생성되며, 생성되지 않은 경우 알림을 보냅니다. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 중간 

## 구현 가이드
<a name="implementation-guidance"></a>

 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 Elastic Disaster Recovery는 소스 환경(온프레미스 또는 AWS)에서 대상 복구 리전으로 지속적인 블록 수준 복제를 제공합니다. 특정 시점 Amazon EBS 스냅샷은 서비스에서 자동으로 생성 및 관리됩니다. 

 AWS Backup은 백업 자동화 및 기록을 중앙 집중식으로 볼 수 있는 완전관리형 정책 기반 백업 솔루션을 제공합니다. AWS Storage Gateway를 사용하여 클라우드뿐 아니라 온프레미스의 여러 AWS 서비스에 걸쳐 데이터 백업을 중앙 집중화하고 자동화합니다. 

 Amazon S3는 버전 관리에 더해 복제 기능도 제공합니다. 전체 S3 버킷을 같거나 다른 AWS 리전의 다른 버킷에 자동으로 복제할 수 있습니다. 

 **구현 단계** 

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를 기반으로 해야 합니다. AWS Backup을 사용하여 자동 백업을 생성하는 방법에 대한 실습 지침은 [데이터 백업 및 복원 테스트](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)를 참조하세요. 데이터를 저장하는 AWS 서비스에서는 대부분 기본적으로 백업 기능을 제공합니다. 예를 들어, RDS를 사용하여 시점 복구(PITR) 기능이 있는 자동화된 백업을 생성할 수 있습니다. 

1.  자동화된 백업 솔루션 또는 관리형 서비스에서 **지원되지 않는 데이터 소스의 경우** 신뢰할 수 있는 서드 파티 솔루션을 사용하여 자동화된 백업을 생성하는 것을 고려하세요. 아니면 AWS CLI 또는 SDK를 사용하여 백업 생성을 위한 자동화를 생성할 수 있습니다. AWS Lambda 함수 또는 AWS Step Functions를 사용하여 데이터 백업 생성의 로직을 정의하고, Amazon EventBridge를 사용하여 RPO를 기반으로 정해진 빈도에 백업을 실행합니다. 

 **구현 계획의 작업 수준:** 낮음. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)(일정에 따라 트리거되는 EventBridge 규칙 생성) 
+  [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 re:Invent 2019: Deep dive on AWS Backup, ft. Rackspace(STG341)](https://youtu.be/av8DpL0uFjc) 

 **관련 예시:** 
+  [Well-Architected lab: Testing Backup and Restore of Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)(Well-Architected 실습: 데이터 백업 및 복원 테스트) 

# REL09-BP04 백업 무결성 및 프로세스를 확인하기 위해 데이터의 주기적인 복구 수행
<a name="rel_backing_up_data_periodic_recovery_testing_data"></a>

복구 테스트를 수행하여 백업 프로세스 구현이 Recovery Time Objective(RTO) 및 Recovery Point Objective(RPO)를 충족하는지 검증합니다.

 **원하는 결과:** 효과적으로 정의된 메커니즘을 사용하여 백업의 데이터가 주기적으로 복구되어 워크로드에 정해진 Recovery Time Objective(RTO) 내에 복구가 가능하도록 합니다. 원본 데이터가 손상되거나 액세스가 불가능하지 않고 Recovery Point Objective(RPO)에서 허용되는 데이터 손실만 이루어진 채로 백업이 원본 데이터가 포함된 리소스로 복원되는지 확인합니다. 

 **일반적인 안티 패턴:** 
+  백업을 복원하지만 복원이 사용 가능한 상태인지 확인하기 위해 데이터를 쿼리하거나 검색하지 않습니다. 
+  백업이 존재한다고 가정합니다. 
+  시스템의 백업이 완전히 작동하며 시스템에서 데이터를 복구할 수 있다고 가정합니다. 
+  복원 시점 또는 백업에서의 데이터 복구가 워크로드의 RTO 이내에 이루어진다고 가정합니다. 
+  백업에 포함된 데이터가 워크로드의 RPO에 부합한다고 가정합니다. 
+  런북을 사용하지 않거나 설정된 자동화 절차를 벗어나 필요에 따라 복원합니다. 

 **이 모범 사례 확립의 이점:** 백업의 복구를 테스트하면 데이터가 손실되거나 손상되는 것을 걱정하지 않고 필요할 때 데이터를 복원할 수 있으며, 복원 및 복구가 워크로드의 RTO 내에 이루어지도록 하며, 데이터 손실이 있는 경우 워크로드의 RPO에 부합하도록 할 수 있습니다. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 중간 

## 구현 가이드
<a name="implementation-guidance"></a>

 백업 및 복원 기능을 테스트하면 중단 시 백업 및 복원 수행의 역량에 대한 신뢰도를 높일 수 있습니다. 주기적으로 백업을 새로운 위치에 복원하고 테스트를 실행하여 데이터의 무결성을 확인합니다. 수행해야 하는 몇 가지 일반적인 테스트는 모든 데이터가 사용 가능한지, 손상되지 않았는지, 액세스 가능한지, 모든 데이터 손실이 워크로드에 대한 RPO 내에 속하는지 확인하는 것입니다. 이러한 테스트는 복구 메커니즘의 속도가 워크로드의 RTO에 부합할 만큼 빠른지 확인하는 데도 도움이 됩니다. 

 AWS를 사용하면 테스트 환경을 구축하고 백업을 복원하여 RTO 및 RPO 기능을 평가하고 데이터 콘텐츠와 무결성에 대한 테스트를 실행할 수 있습니다. 

 또한 Amazon RDS와 Amazon DynamoDB는 PITR(특정 시점 복구)을 지원합니다. 연속 백업을 사용하면 데이터 세트를 지정된 날짜 및 시간의 상태로 복원할 수 있습니다. 

 모든 데이터를 사용 가능한지, 데이터가 손상되지 않았는지, 모든 데이터에 액세스할 수 있는지, 데이터 손실이 있는 경우 워크로드의 RPO에 부합하는지 확인하는 작업이 있습니다. 이러한 테스트는 복구 메커니즘의 속도가 워크로드의 RTO에 부합할 만큼 빠른지 확인하는 데도 도움이 됩니다. 

 AWS Elastic Disaster Recovery는 Amazon EBS 볼륨의 지속적인 특정 시점 복구 스냅샷을 제공합니다. 소스 서버가 복제되면 구성된 정책에 따라 특정 시점 상태가 시간 경과에 따라 기록됩니다. Elastic Disaster Recovery는 트래픽을 리디렉션하지 않고 테스트 및 드릴 목적으로 인스턴스를 시작하여 이러한 스냅샷의 무결성을 확인하는 데 도움이 됩니다. 

 **구현 단계** 

1.  현재 백업되는 **데이터 소스를 식별**하고 이 백업이 어디에 저장되는지 파악합니다. 구현 가이드는 [REL09-BP01 백업해야 하는 모든 데이터 확인 및 백업 또는 소스에서 데이터 복제](rel_backing_up_data_identified_backups_data.md)의 내용을 참조하세요. 

1.  각 데이터 소스에 대한 **데이터 유효성 검사 기준을 설정합니다**. 다양한 유형의 데이터에는 다양한 유효성 검사 메커니즘이 필요할 수 있는 다양한 속성이 있습니다. 확신을 갖고 프로덕션에 사용하기 전에 이 데이터가 어떻게 검증될 수 있는지 고려하세요. 데이터를 검증하는 몇 가지 일반적인 방법은 데이터 유형, 형식, 체크섬, 크기 등의 데이터 및 백업 속성을 사용하거나 이러한 속성과 사용자 지정 검증 로직을 결합하는 것입니다. 예를 들어, 복원된 리소스와 백업이 생성된 당시의 데이터 소스의 체크섬 값을 비교해 볼 수 있습니다. 

1.  데이터 중요도에 따라 데이터 복구에 대한 **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 Recoveryy를 사용한 경우 [복구 훈련을 시작](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html)할 수 있습니다 

1.  데이터 유효성 검사를 위해 이전에 설정한 기준에 따라 복원된 리소스에서 **데이터 복구 유효성을 검사**합니다. 복원되고 복구된 데이터에 백업 시 가장 최신 레코드 또는 항목이 포함되어 있습니까? 이 데이터가 워크로드의 RPO에 부합합니까? 

1.  복원 및 복구에 **필요한 시간을 측정**하고 기존 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 내에서 백업 및 복원 작업을 *작업*이라고 하며 이러한 작업에는 복원 및 복구에 필요한 시간을 측정하는 데 사용할 수 있는 메타데이터의 일부로 타임스탬프 정보가 포함되어 있습니다. 

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](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/)(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/2023-10-03/framework/images/automated-backup-restore-process.png)


 **구현 계획의 작업 수준:** 검증 기준의 복잡성에 따라 중간에서 높음. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [Automate data recovery validation with AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/)(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](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)(일정에 따라 트리거되는 EventBridge 규칙 생성) 
+  [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://aws.amazon.com/disaster-recovery/) 

 **관련 예시:** 
+  [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. 장애 격리를 사용하여 워크로드를 보호하려면 어떻게 해야 합니까?
<a name="rel-10"></a>

장애 격리 경계는 워크로드 내부 장애의 영향을 제한된 수의 구성 요소로 제한합니다. 경계 외부의 구성 요소는 장애가 발생하더라도 영향을 받지 않습니다. 다수의 장애 격리 경계를 사용하여 워크로드에 미치는 영향을 제한할 수 있습니다.

**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 워크로드를 여러 위치에 배포
<a name="rel_fault_isolation_multiaz_region_system"></a>

 워크로드 데이터와 리소스를 여러 가용 영역에 분산하거나 필요한 경우 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/2023-10-03/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를 사용하여 지연 시간이 짧아야 하거나 로컬 데이터 처리 요구 사항이 있는 워크로드를 지원할 수 있습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  다중 가용 영역 및 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/) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 다중 위치 배포에 적합한 위치 선택
<a name="rel_fault_isolation_select_location"></a>

## 원하는 결과
<a name="desired-outcome"></a>

 고가용성을 위해서는 그림 10에 나온 것과 같이 가능하면 언제나 워크로드 구성 요소를 여러 개의 가용 영역(AZ)에 배포하세요. 복원력에 대한 요구 사항이 매우 높은 워크로드의 경우 다중 리전 아키텍처에 대한 옵션을 신중하게 평가하세요. 

![\[다른 AWS 리전에 백업되고 복원력이 있는 다중 AZ 데이터베이스 배포를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/images/multi-az-architecture.png)


## 일반적인 안티 패턴
<a name="common-anti-patterns"></a>
+  다중 AZ 아키텍처로 요구 사항을 충족할 수 있는데 다중 리전 아키텍처로 설계함 
+  복원력과 다중 위치 요구 사항이 구성 요소 간에 다를 경우 애플리케이션 구성 요소 간의 종속성을 고려하지 않음 

## 이 모범 사례 수립의 이점
<a name="benefits-of-establishing-this-best-practice"></a>

 복원력을 위해서는 방어 계층을 구축하는 접근 방식을 사용해야 합니다. 하나의 계층은 다중 AZ를 사용하여 가용성이 높은 아키텍처를 구축함으로써 더 작고 더 일반적인 장애를 예방하고 또 다른 방어 계층은 만연한 자연 재해와 리전 수준의 장애와 같은 드문 이벤트를 예방하도록 설계합니다. 이 두 번째 계층에는 애플리케이션이 여러 AWS 리전에 분산되도록 하는 아키텍팅이 포함됩니다. 
+  99.5% 가용성과 99.99% 가용성의 차이는 월간 3.5시간이 넘습니다. 워크로드가 여러 가용 영역에 있는 경우 워크로드의 예상 가용성은 최대 99.99%에 그치게 됩니다. 
+  워크로드를 여러 가용 영역에서 실행하면 전력, 냉각기, 네트워킹에서의 장애와 화재나 홍수와 같은 대부분의 자연 재해로 인한 장애를 격리할 수 있습니다. 
+  워크로드에 다중 리전 전략을 구현하면 한 나라의 광범위한 지역에 영향을 미치는 만연한 자연 재해나 리전 전체에 발생한 기술적 장애로부터 워크로드를 보호할 수 있습니다. 다중 리전 아키텍처를 구현하는 일은 매우 복잡할 수 있으며 대개 대부분의 워크로드에는 필요하지 않다는 점을 참고하시기 바랍니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 가용 영역 한 곳의 중단이나 일부 소실에 따른 재해 이벤트의 경우 단일 AWS 리전 내 다중 가용 영역에 고가용성 워크로드를 구현하면 자연 재해와 기술 재해의 위험을 완화하는 데 도움이 됩니다. 각 AWS 리전은 여러 가용 영역으로 구성되며, 각 가용 영역은 상당히 멀리 떨어진 다른 영역에 발생한 장애의 영향을 받지 않습니다. 그러나 서로 상당히 멀리 떨어진 여러 가용 영역 구성 요소가 소실될 위험이 있는 재해 이벤트의 경우 리전 전체에 영향을 주는 장애를 완화하는 재해 복구 옵션을 구현해야 합니다. 매우 높은 복원력을 요구하는 워크로드(핵심 인프라, 건강 관련 애플리케이션, 금융 시스템 인프라 등)의 경우 다중 리전 전략이 필요할 수 있습니다. 

## 구현 단계
<a name="implementation-steps"></a>

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/) 

 **구현 계획의 작업 수준: **보통에서 높음 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 단일 위치로 제약된 구성 요소의 복구 자동화
<a name="rel_fault_isolation_single_az_system"></a>

워크로드의 구성 요소를 단일 가용 영역 또는 온프레미스 데이터 센터에서만 실행해야 하는 경우 정의된 복구 목표 내에서 워크로드를 완전히 재구축할 수 있는 기능을 구현합니다.

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 중간 

## 구현 가이드
<a name="implementation-guidance"></a>

 기술적 제약으로 인해 워크로드를 여러 위치에 배포하는 모범 사례를 따를 수 없다면 복원력을 달성할 수 있는 대체 경로를 구현해야 합니다. 이러한 경우를 위해 필요한 인프라를 다시 생성하고, 애플리케이션을 다시 배포하고, 필요한 데이터를 다시 생성하는 기능을 자동화해야 합니다. 

 예를 들어 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 리전 내에서 임의로 선택된 가용 영역에 클러스터를 프로비저닝합니다. 모든 클러스터 노드는 동일한 영역에 프로비저닝됩니다. 

 온프레미스 데이터 센터에 배포된 상태 저장 서버 기반 워크로드의 경우 AWS Elastic Disaster Recovery를 사용하여 AWS에서 워크로드를 보호할 수 있습니다. 이미 AWS에서 호스팅되는 경우 Elastic Disaster Recovery를 사용하여 워크로드를 대체 가용 영역 또는 리전으로 보호할 수 있습니다. Elastic Disaster Recovery는 경량 스테이징 영역에 대한 지속적인 블록 수준 복제를 사용하여 온프레미스 및 클라우드 기반 애플리케이션의 빠르고 안정적인 복구를 제공합니다. 

 **구현 단계** 

1.  자가 복구를 구현합니다. 가능한 경우 자동 크기 조정을 사용하여 인스턴스 또는 컨테이너를 배포합니다. 자동 크기 조정을 사용할 수 없는 경우 EC2 인스턴스에 대한 자동 복구를 사용하거나 Amazon EC2 또는 ECS 컨테이너 수명 주기 이벤트를 기반으로 자가 복구 자동화를 구현합니다. 
   +  단일 인스턴스 IP 주소, 프라이빗 IP 주소, 탄력적 IP 주소 및 인스턴스 메타데이터가 필요하지 않은 인스턴스 및 컨테이너 워크로드에 [Amazon EC2 Auto Scaling 그룹](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)을 사용합니다. 
     +  시작 템플릿 사용자 데이터는 대부분의 워크로드를 자가 복구할 수 있는 자동화를 구현하는 데 사용할 수 있습니다. 
   +  단일 인스턴스 ID 주소, 프라이빗 IP 주소, 탄력적 IP 주소 및 인스턴스 메타데이터가 필요한 워크로드에 [Amazon EC2 인스턴스 자동 복구](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)를 사용합니다. 
     +  자동 복구는 인스턴스 장애가 감지될 때 SNS 주제로 복구 상태 알림을 전송합니다. 
   +  자동 크기 조정 또는 EC2 복구를 사용할 수 없는 경우 [Amazon EC2 인스턴스 수명 주기 이벤트](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)를 사용하여 자가 복구를 자동화합니다. 
     +  이벤트를 사용하여 필요한 프로세스 로직에 따라 구성 요소를 복구하는 자동화를 호출합니다. 
   +  [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)을 사용하여 단일 위치로 제한된 상태 저장 워크로드를 보호합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [Amazon ECS 이벤트](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) 
+  [Amazon 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) 
+  [Amazon EC2 Auto Scaling란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)

# REL10-BP04 격벽 아키텍처를 사용하여 영향 범위 제한
<a name="rel_fault_isolation_use_bulkhead"></a>

격벽 아키텍처(셀 기반 아키텍처라고도 함)를 구현하여 워크로드 내 장애의 영향을 제한된 수의 구성 요소로 제한합니다.

 **원하는 결과:** 셀 기반 아키텍처는 워크로드의 여러 격리된 인스턴스를 사용하며 여기에서 각 인스턴스를 셀이라고 합니다. 각 셀은 독립적이고 다른 셀과 상태를 공유하지 않으며 전체 워크로드 요청의 하위 집합을 처리합니다. 이렇게 하면 잘못된 소프트웨어 업데이트와 같은 오류의 잠재적 영향이 개별 셀과 처리 중인 요청으로 축소됩니다. 워크로드가 10개의 셀을 사용하여 100개의 요청을 처리하는 경우 장애가 발생하면 전체 요청의 90%는 장애의 영향을 받지 않습니다. 

 **일반적인 안티 패턴:** 
+  셀이 경계 없이 성장할 수 있도록 합니다. 
+  동시에 모든 셀에 코드 업데이트 또는 배포를 적용합니다. 
+  라우터 계층을 제외하고 셀 간에 상태 또는 구성 요소를 공유합니다. 
+  복잡한 비즈니스 또는 라우팅 로직을 라우터 계층에 추가합니다. 
+  셀 간 상호 작용을 최소화하지 않습니다. 

 **이 모범 사례 확립의 이점:** 셀 기반 아키텍처를 사용하면 많은 일반적인 유형의 오류가 셀 자체 내에 억제되어 추가적인 장애 격리를 제공합니다. 이러한 결함 경계는 실패한 코드 배포 또는 손상되거나 *포이즌 필 요청*이라고도 하는 특정 실패 모드를 트리거하는 요청과 같이 억제하기 어려운 실패 유형에 대한 복원력을 제공할 수 있습니다. 

## 구현 가이드
<a name="implementation-guidance"></a>

 선박의 격벽은 선체 파손이 선체의 한 섹션 내에 억제되도록 합니다. 복잡한 시스템에서 이 패턴은 장애 격리를 활성화하기 위해 종종 복제됩니다. 장애 격리 경계는 워크로드 내부 장애의 영향을 제한된 수의 구성 요소로 제한합니다. 경계 외부의 구성 요소는 장애가 발생하더라도 영향을 받지 않습니다. 다수의 장애 격리 경계를 사용하여 워크로드에 미치는 영향을 제한할 수 있습니다. AWS에서 고객은 여러 가용 영역 및 리전을 사용하여 장애 격리를 제공할 수 있지만 장애 격리의 개념은 워크로드의 아키텍처로도 확장될 수 있습니다. 

 전체 워크로드는 파티션 키로 분할된 셀입니다. 이 키는 서비스의 *세부 수준* 또는 최소한의 크로스 셀 상호 작용으로 서비스의 워크로드를 세분화할 수 있는 자연스러운 방식에 맞춰 조정되어야 합니다. 파티션 키로는 고객 ID, 리소스 ID 또는 대부분의 API 호출에서 쉽게 액세스할 수 있는 기타 파라미터를 예로 들 수 있습니다. 셀 라우팅 계층은 파티션 키를 기반으로 개별 셀에 요청을 배포하고 클라이언트에 단일 엔드포인트를 제공합니다. 

![\[셀 기반 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/images/cell-based-architecture.png)


 **구현 단계** 

 셀 기반 아키텍처를 설계할 때 고려해야 할 몇 가지 설계 고려 사항이 있습니다. 

1.  **파티션 키**: 파티션 키를 선택할 때 다음을 특별히 고려해야 합니다. 
   +  이 키는 서비스의 세부 수준 또는 최소한의 크로스 셀 상호 작용으로 서비스의 워크로드를 세분화할 수 있는 자연스러운 방식에 맞춰 조정되어야 합니다. 예를 들어 `고객 ID` 또는 `리소스 ID`등이 있습니다. 
   +  파티션 키는 모든 요청에서 직접 또는 다른 파라미터에 의해 결정론적으로 쉽게 추론될 수 있는 방식으로 사용 가능해야 합니다. 

1.  **영구 셀 매핑**: 업스트림 서비스는 해당 리소스의 수명 주기 동안 단일 셀과만 상호 작용해야 합니다. 
   +  워크로드에 따라 한 셀에서 다른 셀로 데이터를 마이그레이션하는 데 셀 마이그레이션 전략이 필요할 수 있습니다. 셀 마이그레이션이 필요할 수 있는 가능한 시나리오는 워크로드의 특정 사용자 또는 리소스가 너무 커져 전용 셀이 필요한 경우입니다. 
   +  셀은 셀 간에 상태 또는 구성 요소를 공유해서는 안 됩니다. 
   +  결과적으로 셀 간 상호 작용은 피하거나 최소로 유지해야 합니다. 이러한 상호 작용은 셀 간의 종속성을 생성하여 장애 격리 개선을 감소시키기 때문입니다. 

1.  **라우터 계층**: 라우터 계층은 셀 간에 공유되는 구성 요소이므로 셀과 동일한 구획화 전략을 따를 수 없습니다. 
   +  라우터 계층은 파티션 키를 셀에 매핑하기 위해 암호화 해시 함수와 모듈식 산술을 결합하는 것과 같이 컴퓨팅적으로 효율적인 방식으로 파티션 매핑 알고리즘을 사용하여 요청을 개별 셀에 배포하는 것이 좋습니다. 
   +  다중 셀 영향을 방지하려면 라우팅 계층을 가능한 한 단순하고 수평적으로 확장할 수 있어야 하므로 이 계층 내에서 복잡한 비즈니스 로직을 피해야 합니다. 그러면 예상되는 동작을 항상 쉽게 이해할 수 있게 하여 철저한 테스트 가능성을 허용하는 추가적인 이점이 있습니다. Colm MacCárthaigh가 [신뢰성, 지속적인 작업, 좋은 커피 한 잔](https://aws.amazon.com/builders-library/reliability-and-constant-work/)에서 설명한 것처럼 단순한 디자인과 지속적인 작업 패턴은 신뢰할 수 있는 시스템을 생성하고 안티프래질을 줄입니다. 

1.  **세포 크기**: 세포에는 최대 크기가 있어야 하며 그 이상으로 자라지 않아야 합니다. 
   +  중단점에 도달하고 안전한 작동 마진이 설정될 때까지 철저한 테스트를 수행하여 최대 크기를 식별해야 합니다. 테스트 사례를 구현하는 방법에 대한 자세한 내용은 다음을 참조하세요. [REL07-BP04 워크로드 로드 테스트](rel_adapt_to_changes_load_tested_adapt.md) 
   +  전체 워크로드는 셀 추가를 통해 증가하므로, 수요 증가에 따라 워크로드를 확장할 수 있습니다. 

1.  **다중 AZ 또는 다중 리전 전략**: 다양한 장애 도메인으로부터 보호하기 위해 여러 계층의 복원력을 활용해야 합니다. 
   +  복원력을 위해서는 방어 계층을 구축하는 접근 방식을 사용해야 합니다. 하나의 계층은 다중 AZ를 사용하여 가용성이 높은 아키텍처를 구축함으로써 더 작고 더 일반적인 장애를 예방하고 또 다른 방어 계층은 만연한 자연 재해와 리전 수준의 장애와 같은 드문 이벤트를 예방하도록 설계합니다. 이 두 번째 계층에는 애플리케이션이 여러 AWS 리전에 분산되도록 하는 아키텍팅이 포함됩니다. 워크로드에 다중 리전 전략을 구현하면 한 나라의 광범위한 리전에 영향을 미치는 만연한 자연 재해나 리전 전체에 발생한 기술적 장애로부터 워크로드를 보호할 수 있습니다. 다중 리전 아키텍처를 구현하는 일은 매우 복잡할 수 있으며 대개 대부분의 워크로드에는 필요하지 않다는 점을 참고하시기 바랍니다. 자세한 내용은 [REL10-BP02 다중 위치 배포에 적합한 위치 선택](rel_fault_isolation_select_location.md)단축할 수 있습니다. 

1.  **코드 배포**: 동시에 모든 셀에 코드 변경 사항을 배포하는 것보다 시차를 둔 코드 배포 전략을 선호해야 합니다. 
   +  이렇게 하면 잘못된 배포 또는 사람의 실수로 인해 여러 셀에 미치는 잠재적인 장애를 최소화하는 데 도움이 됩니다. 자세한 내용은 [안전한 핸드오프 배포 자동화](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)를 참조하세요. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 높음 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [REL07-BP04 워크로드 로드 테스트](rel_adapt_to_changes_load_tested_adapt.md) 
+  [REL10-BP02 다중 위치 배포에 적합한 위치 선택](rel_fault_isolation_select_location.md) 

 **관련 문서:** 
+  [Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)(안정성, 지속적인 작업 및 맛 좋은 한 잔의 커피) 
+ [AWS and Compartmentalization](https://aws.amazon.com/blogs/architecture/aws-and-compartmentalization/)(AWS 및 구획화)
+ [셔플 샤딩을 사용한 워크로드 격리](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
+  [안전한 핸드오프 배포 자동화](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) 

 **관련 동영상:** 
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small](https://www.youtube.com/watch?v=O8xLxNje30M)(루프 닫기 및 마음 열기: 규모에 상관없이 시스템을 제어하는 방법)
+  [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures(ARC338)](https://youtu.be/swQbA4zub20)(AWS가 장애의 영향 범위를 최소화하는 방법(ARC338)) 
+  [셔플 샤딩: AWS re:Invent 2019: Introducing The Amazon Builders’ Library](https://youtu.be/sKRdemSirDM?t=1373)(DOP328)(Amazon Builders’ Library 소개(DOP328)) 
+ [AWS Summit ANZ 2021 - Everything fails, all the time: Designing for resilience](https://www.youtube.com/watch?v=wUzSeSfu1XA)(AWS Summit ANZ 2021 - 항상 실패하는 모든 것: 복원력을 위한 설계)

 **관련 예시:** 
+  [Well-Architected lab: Fault isolation with shuffle sharding](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)(Well-Architected 실습: 셔플 샤딩으로 장애 격리) 

# REL 11. 구성 요소 장애를 견디도록 워크로드를 설계하려면 어떻게 해야 하나요?
<a name="rel-11"></a>

고가용성 및 낮은 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-BP07 가용성 목표 및 가동 시간 서비스 수준에 관한 계약(SLA)을 충족하도록 제품 설계](rel_withstand_component_failures_service_level_agreements.md)

# REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지
<a name="rel_withstand_component_failures_monitoring_health"></a>

 워크로드 상태를 지속적으로 모니터링하여 장애 또는 성능 저하가 발생하는 즉시 사용자 및 자동화된 시스템이 이를 인식할 수 있도록 합니다. 비즈니스 가치를 기반으로 KPI(핵심 성능 지표)를 모니터링합니다. 

 모든 복구 메커니즘은 문제를 신속하게 탐지하는 기능에서 시작되어야 합니다. 기술적 장애를 먼저 감지하여 해결합니다. 그러나 가용성은 비즈니스 가치를 제공하는 워크로드의 기능에 따라 결정되므로 이 요구 사항을 측정하는 핵심 성과 지표(KPI)를 탐지 및 수정 전략의 핵심 척도로 사용해야 합니다. 

 **원하는 결과:** 워크로드의 필수 구성 요소를 독립적으로 모니터링하여 언제 어디서 장애가 발생하는지 감지하고 이에 대해 경고합니다. 

 **일반적인 안티 패턴:** 
+  경보가 구성되지 않았기 때문에 알림 없이 중단이 발생합니다. 
+  경보가 존재하지만 대응 시간이 충분하지 않은 임계치에 있습니다. 
+  지표는 RTO(복구 시간 목표)를 충족하기에 충분한 지표가 수집되지 않는 경우가 많습니다. 
+  워크로드의 고객 대상 인터페이스만 능동적으로 모니터링됩니다. 
+  기술 지표만 수집하며 비즈니스 기능 지표는 수집하지 않습니다. 
+  워크로드의 사용자 경험을 측정하는 지표가 없습니다. 
+  너무 많은 모니터가 생성되었습니다. 

 **이 모범 사례 확립의 이점:** 모든 계층에서 적절한 모니터링을 사용하면 감지 시간을 단축하여 복구 시간을 줄일 수 있습니다. 

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 모니터링을 위해 검토할 모든 워크로드를 식별하십시오. 모니터링해야 할 워크로드의 모든 구성 요소를 식별했으면 이제 모니터링 간격을 결정해야 합니다. 모니터링 간격은 장애 감지에 걸리는 시간을 기준으로 복구를 시작할 수 있는 속도에 직접적인 영향을 미칩니다. 평균 감지 시간(MTTD)은 장애가 발생한 시점부터 수리 작업이 시작되는 시점까지의 시간입니다. 서비스 목록은 광범위하고 완전해야 합니다. 

 모니터링은 애플리케이션, 플랫폼, 인프라 및 네트워크를 포함한 애플리케이션 스택의 모든 계층을 포괄해야 합니다. 

 모니터링 전략은 회색 장애의 영향을 *고려해야 합니다*. 회색 장애에 대한 자세한 내용은 [ Advanced Multi-AZ Resilience Patterns(고급 다중 AZ 복원력 패턴) 백서에서](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) 회색 장애를 참조하세요. 

### 구현 단계
<a name="implementation-steps"></a>
+  모니터링 간격은 필요한 복구 속도에 따라 달라집니다. 복구 시간은 복구에 걸리는 시간에 따라 결정되므로 이 시간과 RTO(복구 시간 목표)를 고려하여 수집 빈도를 결정해야 합니다. 
+  구성 요소 및 관리형 서비스에 대한 세부 모니터링을 구성합니다. 
  +  EC2 [인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) 및 [Auto Scaling에](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) 대한 자세한 모니터링이 필요한지 여부를 결정합니다. 세부 모니터링은 1분 간격 지표를 제공하고, 기본 모니터링은 5분 간격 지표를 제공합니다. 
  +  EC2 [향상된 모니터링이](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) 필요한지 여부를 결정합니다. 향상된 모니터링은 RDS 인스턴스의 에이전트를 사용하여 여러 프로세스 또는 스레드에 대한 유용한 정보를 얻습니다. 
  +  다음을 위한 중요 서버리스 구성 요소의 모니터링 요구 사항을 결정합니다. [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html), [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/monitoring_automated_manual.html), [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html), [Amazon ECS](https://catalog.workshops.aws/observability/en-US/aws-managed-oss/amp/ecs), 그리고 모든 유형의 [로드 밸런서](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html). 
  +  다음을 위한 스토리지 구성 요소의 모니터링 요구 사항을 결정합니다. [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html), [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring_overview.html), [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/monitoring_overview.html) 및 [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html). 
+  비즈니스 핵심 성과 지표(KPI)를 [측정하는 사용자 지정 지표를](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 만듭니다. 워크로드는 주요 비즈니스 기능을 구현하며, 이는 간접적인 문제 발생 시점을 파악하는 데 도움이 되는 KPI로 사용되어야 합니다. 
+  사용자 Canary를 사용하여 사용자 경험의 장애 모니터링. [가장 중요한 테스트 프로세스 중 하나는](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 고객 행동을 실행하고 시뮬레이션할 수 있는 가상 트랜잭션 테스트(‘canary 테스트’라고도 하지만 카나리 배포와는 다름)입니다. 다양한 원격 위치에서 워크로드 엔드포인트에 대해 이러한 테스트를 지속적으로 실행합니다. 
+  비즈니스 핵심 성과 지표(KPI)를 [측정하는 사용자 지정 지표를](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 사용자의 경험을 추적합니다. 고객의 경험을 계측할 수 있으면 소비자 경험이 저하되는 시기를 결정할 수 있습니다. 
+  [워크로드의 일부가](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 제대로 작동하지 않는 시기를 감지하고 리소스의 크기를 자동 조정해야 하는 시점을 알려주는 알람을 설정합니다. 경보를 사용하면 대시보드에 경보를 시각적으로 표시하고, Amazon SNS 또는 이메일을 통해 알림을 전송하며, Auto Scaling을 통해 워크로드의 리소스 규모를 확장하거나 축소할 수 있습니다. 
+  비즈니스 핵심 성과 지표(KPI)를 [지표를](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 시각화하세요. 대시보드를 사용하면 추세, 이상값 및 기타 잠재적 문제의 지표를 시각적으로 표시하거나, 조사가 필요할 수 있는 문제를 표시할 수 있습니다. 
+  서비스에 대한 [분산 추적 모니터링을](https://aws.amazon.com/xray/faqs/) 생성하세요. 분산 모니터링을 사용하면 애플리케이션과 해당하는 기본 서비스의 성능을 파악하여 성능 문제 및 오류의 근본 원인을 식별하고 해결할 수 있습니다. 
+  모니터링 시스템 생성( [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) 또는 [X-Ray](https://aws.amazon.com/xray/faqs/)사용) 별도의 지역 및 계정에서 대시보드 및 데이터 수집. 
+  성능 저하가 [있을 수 있는](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/) AWS 리소스에 대한 가시성을 모니터링할 수 있도록 Amazon Health Aware 모니터링을 위한 통합을 생성합니다. 비즈니스 필수 워크로드의 경우 이 솔루션을 통해 AWS 서비스에 대한 선제적인 실시간 알림에 액세스할 수 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [가용성 정의](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 
+  [REL11-BP06 이벤트가 가용성에 영향을 미치는 경우 알림 전송](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.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를 사용하여 Auto Scaling 그룹 및 인스턴스 모니터링](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) 
+  [지역 간 교차 계정 CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) 
+  [지역 간 계정 X-Ray 추적 사용](https://aws.amazon.com/xray/faqs/) 
+  [가용성 요구 사항 파악](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/understanding-availability.html) 
+  [Amazon Health Aware(AHA) 구현](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/) 

 **관련 동영상:** 
+  [Mitigating gray failures](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) 

 **관련 예시:** 
+  [Well-Architected Lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html) 
+  [One Observability Workshop: Explore X-Ray](https://catalog.workshops.aws/observability/en-US/aws-native/xray/explore-xray) 

 **관련 도구:** 
+  [CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html) 

# REL11-BP02 정상 리소스로 장애 조치
<a name="rel_withstand_component_failures_failover2good"></a>

 리소스 장애가 발생하는 경우 정상 리소스가 계속해서 요청을 처리해야 합니다. 위치 장애(예: 가용 영역 또는 AWS 리전)의 경우, 손상되지 않은 위치의 정상 리소스로 장애 조치할 수 있는 시스템을 갖추고 있어야 합니다. 

 서비스를 설계할 때는 리소스, 가용 영역 또는 리전에 부하를 분산하세요. 따라서 트래픽을 정상적인 리소스로 전환하여 개별 리소스의 장애 또는 중단을 완화할 수 있습니다. 장애 발생 시 서비스를 검색하고 라우팅하는 방법을 고려해 보세요. 

 장애 복구를 염두에 두고 서비스를 설계하세요. AWS에서는 장애에서 복구하는 시간과 데이터에 대한 영향을 최소화하는 방식으로 서비스가 설계됩니다. AWS 서비스는 기본적으로 한 리전 내의 여러 복제본에 저장된 요청만 승인하는 데이터 스토어를 사용합니다. 이러한 서비스/리소스는 셀 기반 격리와 가용 영역에서 제공되는 장애 격리 기능을 사용하도록 구성됩니다. AWS의 운영 절차에서는 자동화가 광범위하게 사용됩니다. 또한 서비스 중단 시 빠르게 복구할 수 있도록 교체 및 다시 시작 기능도 최적화됩니다. 

 장애 조치를 허용하는 패턴과 디자인은 각 AWS 플랫폼 서비스마다 다릅니다. 대부분의 AWS 기본 관리형 서비스는 기본적으로 다중 가용 영역(예: Lambda 또는API Gateway)입니다. 다른 AWS 서비스(예: EC2 및 EKS)에서는 AZ에서 리소스 또는 데이터 스토리지의 장애 조치를 지원하기 위한 구체적인 모범 사례 설계가 필요합니다. 

 장애 조치 리소스가 정상인지 확인하고, 장애 조치 중인 리소스의 진행 상황을 추적하고, 비즈니스 프로세스 복구를 모니터링하도록 설정해야 합니다. 

 **원하는 결과:** 시스템은 새 리소스를 자동 또는 수동으로 사용하여 성능 저하를 복구할 수 있습니다. 

 **일반적인 안티 패턴:** 
+  장애에 대한 계획은 계획 및 설계 단계의 일부가 아닙니다. 
+  RTO와 RPO가 설정되지 않았습니다. 
+  모니터링이 충분하지 않아 장애가 발생한 리소스를 감지할 수 없습니다. 
+  장애 도메인의 적절한 격리가 되지 않습니다. 
+  다중 리전 장애 조치는 고려되지 않습니다. 
+  장애 탐지는 장애 조치를 결정할 때 너무 민감하거나 공격적입니다. 
+  장애 조치 설계를 테스트하거나 검증하지 않습니다. 
+  자동 복구 자동화를 수행하지만 복구가 필요한 것을 알리지 않습니다. 
+  너무 빨리 페일백하지 않도록 하는 완충 기간이 부족합니다. 

 **이 모범 사례 확립의 이점:** 점진적으로 성능이 저하되고 빠르게 복구되므로 장애 발생 시 안정성을 유지하는 복원력이 뛰어난 시스템을 구축할 수 있습니다. 

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 AWS 서비스, 즉 [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) 및 [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html)는 리소스 및 가용 영역 전체에 부하를 분산하는 데 도움이 됩니다. 따라서 남아 있는 상태가 양호한 리소스로 트래픽을 이동시켜 개별 리소스(예: EC2 인스턴스)의 장애 또는 가용 영역의 장애를 완화할 수 있습니다. 

 다중 리전 워크로드의 경우 설계가 더 복잡합니다. 예를 들어, 리전 간 읽기 전용 복제본을 사용하면 데이터를 여러 AWS 리전에 배포할 수 있습니다. 하지만 읽기 전용 복제본을 기본 복제본으로 승격한 다음 트래픽이 새 엔드포인트로 향하도록 하려면 여전히 장애 조치가 필요합니다. Amazon Route 53, Route 53, ARC, CloudFront, 및 AWS Global Accelerator은 여러 AWS 리전에 트래픽을 라우팅하는 데 도움이 될 수 있습니다. 

 Amazon S3, Lambda, API Gateway, Amazon SQS, Amazon SNS, Amazon SES, Amazon Pinpoint, Amazon ECR, AWS Certificate Manager, EventBridge, 또는 Amazon DynamoDB 등의 AWS 서비스는 AWS를 통해 여러 가용 영역에 자동으로 배포됩니다. 장애가 발생할 경우 이러한 AWS 서비스는 자동으로 트래픽을 정상 위치로 라우팅합니다. 데이터가 여러 가용 영역에 중복으로 저장되고 가용성이 유지됩니다. 

 Amazon RDS, Amazon Aurora, Amazon Redshift, Amazon EKS, 또는 Amazon ECS의 경우 다중 AZ는 구성 옵션입니다. AWS는 장애 조치가 시작된 경우 트래픽을 정상 인스턴스로 보낼 수 있습니다. 이 장애 조치는 AWS에 의해 또는 고객의 요구에 따라 수행될 수 있습니다. 

 Amazon EC2인스턴스Amazon Redshift, Amazon ECS 작업 또는 Amazon EKS 포드의 경우 배포할 가용 영역을 선택합니다. 일부 설계의 경우, Elastic Load Balancing는 비정상 영역의 인스턴스를 탐지하고 트래픽을 정상 구역으로 라우팅하는 솔루션을 제공합니다.Elastic Load Balancing 또한 온프레미스 데이터 센터의 구성 요소로 트래픽을 라우팅할 수 있습니다. 

 다중 리전 트래픽 장애 조치의 경우 재라우팅은 아마존 Route 53, ARC AWS Global AcceleratorRoute 53 Private DNS for VPCs, 또는CloudFront를 활용하여 인터넷 도메인을 정의하고 상태 확인을 포함한 라우팅 정책을 할당하여 트래픽을 정상 리전으로 라우팅하는 방법을 제공할 수 있습니다.AWS Global Accelerator는 애플리케이션에 대한 고정 진입점 역할을 하는 고정 IP 주소를 제공한 다음, 성능 및 안정성 향상을 위해 인터넷 대신 AWS 글로벌 네트워크를 사용하여 선택한 AWS 리전 엔드포인트로 라우팅합니다. 

### 구현 단계
<a name="implementation-steps"></a>
+  모든 적절한 애플리케이션과 서비스를 위한 장애 조치 설계를 생성합니다. 각 아키텍처 구성 요소를 분리하고 각 구성 요소에 대한 RTO 및 RPO를 충족하는 장애 조치 설계를 생성합니다. 
+  장애 조치 계획을 수립하는 데 필요한 모든 서비스를 갖춘 하위 환경(예: 개발 또는 테스트)을 구성합니다. 코드형 인프라(IaC) 를 사용하여 솔루션을 배포하여 반복성을 보장합니다. 
+  복구 사이트(예: 보조 리전)를 구성하여 장애 조치 설계를 구현하고 테스트합니다. 필요한 경우 테스트 리소스를 임시로 구성하여 추가 비용을 제한할 수 있습니다. 
+  어떤 장애 조치 계획을 AWS를 통해 자동화할지, 어떤 장애 조치 계획을 DevOps 프로세스로 자동화할 수 있는지, 어떤 장애 조치 계획을 수동으로 할지 결정하세요. 각 서비스의 RTO 및 RPO를 문서화하고 측정합니다. 
+  장애 조치 플레이북을 만들고 각 리소스, 애플리케이션, 서비스를 장애 조치하기 위한 모든 단계를 포함하세요. 
+  페일백 플레이북을 만들고 각 리소스, 애플리케이션, 서비스를 페일백하기 위한 모든 단계(타이밍 포함)를 포함합니다. 
+  계획을 세워 플레이북을 시작하고 연습하세요. 시뮬레이션과 카오스 테스트를 사용하여 플레이북 단계 및 자동화를 테스트하세요. 
+  위치 장애(예: 가용 영역 또는 AWS 리전)의 경우, 중단되지 않은 위치의 정상 리소스로 장애 조치할 수 있는 시스템을 갖추고 있어야 합니다. 장애 조치 테스트 전에 할당량, 자동 확장 수준, 실행 중인 리소스를 확인하세요. 

## 리소스
<a name="resources"></a>

 **관련 Well-Architected 모범 사례:** 
+  [REL13- 재해 복구 계획](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) 
+  [REL10 - 장애 격리를 사용하여 워크로드 보호](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) 

 **관련 문서:** 
+  [RTO 및 RPO 목표 설정](https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/) 
+  [애플리케이션 로드 밸런서로 ARC 설정](https://www.wellarchitectedlabs.com/reliability/disaster-recovery/workshop_5/) 
+  [Route 53 가중치 기반 라우팅을 사용한 장애 조치](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) 
+  [ARC를 통한 DR](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/) 
+  [자동 크기 조정 기능이 있는 EC2](https://github.com/adriaanbd/aws-asg-ecs-starter) 
+  [EC2 배포 - 다중 AZ](https://github.com/awsdocs/amazon-ec2-auto-scaling-user-) 
+  [ECS 배포 - 다중 AZ](https://github.com/aws-samples/ecs-refarch-cloudformation) 
+  [ARC를 사용하여 트래픽을 전환합니다.](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.failover-different-accounts.html) 
+  [Lambda Application Load Balancer 및 장애조치 포함](https://docs.aws.amazon.com/lambda/latest/dg/services-alb.html) 
+  [ACM 복제 및 장애 조치](https://github.com/aws-samples/amazon-ecr-cross-region-replication) 
+  [파라미터 저장소 복제 및 장애 조치](https://medium.com/devops-techable/how-to-design-an-ssm-parameter-store-for-multi-region-replication-support-aws-infrastructure-db7388be454d) 
+  [ECR 리전 간 복제 및 장애 조치](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-settings-configure.html) 
+  [시크릿 매니저 리전 간 복제 구성](https://disaster-recovery.workshop.aws/en/labs/basics/secrets-manager.html) 
+  [EFS 및 장애 조치를 위한 리전 간 복제 활성화](https://aws.amazon.com/blogs/aws/new-replication-for-amazon-elastic-file-system-efs/) 
+  [EFS 리전 간 복제 및 장애 조치](https://aws.amazon.com/blogs/storage/transferring-file-data-across-aws-regions-and-accounts-using-aws-datasync/) 
+  [네트워킹 장애 조치](https://docs.aws.amazon.com/whitepapers/latest/hybrid-connectivity/aws-dx-dxgw-with-vgw-multi-regions-and-aws-public-peering.html) 
+  [MRAP를 사용한 S3 엔드포인트 장애 조치](https://catalog.workshops.aws/s3multiregionaccesspoints/en-US/0-setup/1-review-mrap) 
+  [S3에 대한 교차 리전 복제 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) 
+  [ARC으로 리전 장애 조치 API Gateway](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjat_TNvev_AhVLlokEHaUeDSUQFnoECAYQAQ&url=https%3A%2F%2Fd1.awsstatic.com%2Fsolutions%2Fguidance%2Farchitecture-diagrams%2Fcross-region-failover-and-graceful-failback-on-aws.pdf&usg=AOvVaw0czthdzWiGlN9I-Dt0lAu3&opi=89978449) 
+  [다중 리전 글로벌 액셀러레이터를 사용한 장애 조치](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-multi-region-applications-in-aws-using-aws-global-accelerator/) 
+  [DRS로 장애 조치](https://docs.aws.amazon.com/drs/latest/userguide/failback-overview.html) 
+  [Amazon Route 53를 사용하여 재해 복구 메커니즘 생성](https://amazon.awsapps.com/workdocs/index.html#/document/2501b1ab648225c2d50ab420c4626ef143834fd0d646978629e5ea4e9b8f014b) 

 **관련 예시:** 
+  [AWS 재해 복구(DR)](https://disaster-recovery.workshop.aws/en/) 
+  [AWS 탄력적 재해 복구](https://catalog.us-east-1.prod.workshops.aws/workshops/080af3a5-623d-4147-934d-c8d17daba346/en-US) 

# REL11-BP03 모든 계층에서 복구 자동화
<a name="rel_withstand_component_failures_auto_healing_system"></a>

 장애가 감지되면 자동화된 기능을 사용하여 수정 작업을 수행합니다. 성능 저하는 내부 서비스 메커니즘을 통해 자동으로 해결되거나 수정 조치를 통해 리소스를 재시작하거나 제거해야 할 수 있습니다. 

 자체 관리 애플리케이션 및 지역 간 복구를 위해 기존 모범 사례에서 복구 설계 및 자동화된 [복구 프로세스를 가져올 수 있습니다](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/). 

 리소스를 재시작하거나 제거하는 기능은 장애를 해결하는 데 중요한 도구입니다. 가장 좋은 방법은 가능한 경우 서비스를 상태 비저장으로 만드는 것입니다. 이렇게 하면 리소스 재시작 시 데이터 손실 또는 가용성이 손실되는 것을 방지할 수 있습니다. 클라우드에서는 재시작의 일부로 전체 리소스(예: 컴퓨팅 인스턴스 또는 서버리스 함수)를 대체할 수 있으며 이러한 대체는 일반적으로 필수적입니다. 재시작은 그 자체로 장애를 복구할 수 있는 단순하면서도 안정적인 방법입니다. 워크로드에는 다양한 유형의 장애가 발생합니다. 장애는 하드웨어, 소프트웨어, 통신 및 작업 과정에서 발생할 수 있습니다. 

 재시작 또는 재시도는 네트워크 요청에도 적용됩니다. 네트워크 시간 제한 장애와 종속성 장애(종속성이 오류를 반환함)에 대해 같은 복구 방식이 적용됩니다. 두 이벤트는 모두 시스템에 비슷한 영향을 주므로, 한 이벤트를 특수 사례로 처리하는 대신 지수 백오프 및 지터를 통해 제한적으로 재시도하는 비슷한 전략이 적용됩니다. 재시작 기능은 복구 중심 컴퓨팅 및 고가용성 클러스터 아키텍처에 포함된 복구 메커니즘입니다. 

 **원하는 결과:** 장애 감지를 해결하기 위해 자동화된 조치가 수행됩니다. 

 **일반적인 안티 패턴:** 
+  자동 크기 조정 없이 리소스를 프로비저닝합니다. 
+  인스턴스 또는 컨테이너에 개별적으로 애플리케이션을 배포합니다. 
+  자동 복구를 사용하지 않고 여러 위치에 배포할 수 없는 애플리케이션을 배포합니다. 
+  자동 크기 조정 및 자동 복구로 복구하지 못한 애플리케이션을 수동으로 복구합니다. 
+  데이터베이스 장애 조치를 자동화할 수 없습니다. 
+  트래픽을 새 엔드포인트로 재라우팅하는 자동화된 방법이 부족합니다. 
+  스토리지 복제가 없습니다. 

 **이 모범 사례 확립의 이점:** 자동 복구를 통해 평균 복구 시간을 줄이고 가용성을 개선할 수 있습니다. 

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 Amazon EKS 또는 기타 Kubernetes 서비스를 위한 설계에는 최소 및 최대 복제본 또는 상태 저장 세트와 최소 클러스터 및 노드 그룹 크기가 모두 포함되어야 합니다. 이러한 메커니즘은 Kubernetes 컨트롤 플레인을 사용하여 장애를 자동으로 해결하면서 지속적으로 사용할 수 있는 최소한의 처리 리소스를 제공합니다. 

 컴퓨팅 클러스터를 사용하여 로드 밸런서를 통해 액세스하는 설계 패턴은 Auto Scaling 그룹을 활용해야 합니다. Elastic Load Balancing(ELB)는 들어오는 애플리케이션 트래픽을 하나 이상의 가용 영역에 있는 여러 대상 및 가상 어플라이언스에 자동으로 분산합니다. 

 부하 분산을 사용하지 않는 클러스터링된 컴퓨팅 기반 설계는 최소 하나 이상의 노드 손실을 고려하여 크기가 설계되어야 합니다. 이렇게 하면 새 노드를 복구하는 동안 서비스가 잠재적으로 줄어든 용량으로 계속 운영될 수 있습니다. 서비스 예로는 Mongo, DynamoDB Accelerator, Amazon Redshift, Amazon EMR, Cassandra, Kafka, MSK-EC2, Couchbase, ELK, 그리고 Amazon OpenSearch Service 등이 있습니다. 이러한 서비스 중 다수는 추가 자동 복구 기능을 사용하여 설계할 수 있습니다. 일부 클러스터 기술은 노드가 손실되면 자동 또는 수동 워크플로를 트리거하여 새 노드를 다시 생성하는 경고를 생성해야 합니다. AWS Systems Manager를 사용하여 이 워크플로를 자동화하여 문제를 신속하게 해결할 수 있습니다. 

 Amazon EventBridge를 사용하면 CloudWatch 경보 또는 다른 AWS 서비스의 상태 변경과 같은 이벤트를 모니터링하고 필터링할 수 있습니다. 그런 다음 이벤트 정보를 기반으로 AWS Lambda, Systems Manager 자동화 또는 기타 대상을 호출하여 워크로드에 대한 사용자 지정 수정 로직을 실행할 수 있습니다. Amazon EC2 Auto Scaling는 EC2 인스턴스 상태를 확인하도록 구성할 수 있습니다. 인스턴스가 실행 중 이외의 상태이거나 시스템 상태가 손상된 경우 Amazon EC2 Auto Scaling은 해당 인스턴스를 비정상으로 간주하고 대체 인스턴스를 시작합니다. 대규모 교체(예: 전체 가용 영역이 손실됨)의 경우 정적 안정성을 통해 고가용성을 유지하는 것이 좋습니다. 

### 구현 단계
<a name="implementation-steps"></a>
+  Auto Scaling그룹을 사용하여 워크로드에 티어를 배포합니다. [Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 은 상태 비저장 애플리케이션에서 자가 복구를 수행하고 용량을 추가 및 제거할 수 있습니다. 
+  앞서 언급한 컴퓨팅 인스턴스의 경우 로드 밸런싱을 [사용하고](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) 적절한 유형의 로드 밸런서를 선택합니다. 
+  Amazon RDS에 대한 복구를 고려하세요. 대기 인스턴스의 경우 [대기 인스턴스로 자동 장애 조치를](https://repost.aws/questions/QU4DYhqh2yQGGmjE_x0ylBYg/what-happens-after-failover-in-rds) 구성합니다. Amazon RDS 읽기 전용 복제본의 경우 읽기 전용 복제본을 기본 복제본으로 만들려면 자동화된 워크플로가 필요합니다. 
+  여러 위치에 [배포할 수 없고 장애 발생 시 재부팅이 허용되는](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) 애플리케이션이 배포되어 있는 EC2 인스턴스에 자동 복구를 구현합니다. 애플리케이션을 여러 위치에 배포할 수 없는 경우 자동 복구를 사용하여 장애가 발생한 하드웨어를 교체하고 인스턴스를 다시 시작할 수 있습니다. 인스턴스 메타데이터와 관련 IP 주소는 물론 [EBS 볼륨과](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) 마운트 지점이 [Amazon Elastic File System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) 또는 [Lustre 및](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) Windows용 [파일 시스템에 저장됩니다](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html). 그리고 [AWS OpsWorks를](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)사용하면 레이어 수준에서 EC2 인스턴스의 자동 복구를 구성할 수 있습니다. 
+  자동 스케일링 또는 자동 복구를 사용할 수 없거나 자동 복구에 실패한 경우 [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) 사용하여 자동 복구를 구현합니다. 자동 크기 조정을 사용할 수 없고, 자동 복구를 사용할 수 없거나 자동 복구가 실패하는 경우 AWS Step Functions 및 AWS Lambda을 사용하여 복구를 자동화할 수 있습니다. 
+  [Amazon EventBridge는](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 다른 AWS 서비스에서 [CloudWatch 알람이나](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 상태 변경과 같은 이벤트를 모니터링하고 필터링하는 데 사용할 수 있습니다. 그런 다음 이벤트 정보를 기반으로 AWS Lambda(또는 다른 대상)를 호출하여 워크로드에 대한 사용자 지정 수정 로직을 실행할 수 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [가용성 정의](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 
+  [REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) 

 **관련 문서:** 
+  [AWS Auto Scaling 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.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) 
+  [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: 자동 복구를 사용하여 실패한 인스턴스 대체](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html) 
+  [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란 무엇인가요?](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) 
+  [Amazon RDS 장애 조치](https://d1.awsstatic.com/rdsImages/IG1_RDS1_AvailabilityDurability_Final.pdf) 
+  [SSM - Systems Manager 자동화](https://docs.aws.amazon.com/resilience-hub/latest/userguide/integrate-ssm.html) 
+  [복원력이 뛰어난 아키텍처 모범 사례](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/) 

 **관련 동영상:** 
+  [자동 프로비저닝 및 규모 조정 OpenSearch Service](https://www.youtube.com/watch?v=GPQKetORzmE) 
+  [Amazon RDS 자동 장애 조치](https://www.youtube.com/watch?v=Mu7fgHOzOn0) 

 **관련 예시:** 
+  [Auto Scaling에 대한 워크숍](https://catalog.workshops.aws/general-immersionday/en-US/advanced-modules/compute/auto-scaling) 
+  [Amazon RDS 장애 조치 워크숍](https://catalog.workshops.aws/resilient-apps/en-US/rds-multi-availability-zone/failover-db-instance) 

 **관련 도구:** 
+  [CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html) 

# REL11-BP04 복구 중 컨트롤 플레인이 아닌 데이터 영역 사용
<a name="rel_withstand_component_failures_avoid_control_plane"></a>

 컨트롤 플레인은 리소스를 생성, 읽기/설명, 업데이트, 삭제, 목록(CRUDL)하는 데 사용되는 관리 API를 제공하는 반면, 데이터 영역은 일상적인 서비스 트래픽을 처리합니다. 복원력에 영향을 미칠 수 있는 이벤트에 대한 복구 또는 완화 대응을 구현할 때는 최소한의 컨트롤 플레인 작업을 사용하여 서비스를 복구, 재조정, 복원, 복구 또는 장애 조치하는 데 집중합니다. 데이터 플레인 작업은 이러한 성능 저하 이벤트가 발생하는 동안의 모든 활동을 대체해야 합니다. 

 예를 들어, 새 컴퓨팅 인스턴스 시작, 블록 스토리지 생성, 대기열 서비스 설명 등은 모두 컨트롤 플레인 작업입니다. 컴퓨팅 인스턴스를 시작할 때 컨트롤 플레인은 용량이 있는 물리적 호스트 찾기, 네트워크 인터페이스 할당, 로컬 블록 스토리지 볼륨 준비, 자격 증명 생성, 보안 규칙 추가와 같은 여러 작업을 수행해야 합니다. 컨트롤 플레인은 복잡한 오케스트레이션이 필요한 경우가 많습니다. 

 **원하는 결과:** 리소스가 손상된 상태가 되면 시스템은 트래픽을 손상된 리소스에서 정상 리소스로 전환하여 자동 또는 수동으로 복구할 수 있습니다. 

 **일반적인 안티 패턴:** 
+  트래픽을 재라우팅하기 위해 DNS 레코드 변경에 의존합니다. 
+  불충분하게 프로비저닝된 리소스로 인해 손상된 구성 요소를 대체하기 위한 컨트롤 플레인 스케일링 작업에 의존합니다. 
+  광범위한 다중 서비스, 다중 API 컨트롤 플레인 조치를 활용하여 모든 범주의 장애를 해결합니다. 

 **이 모범 사례 확립의 이점:** 자동화된 문제 해결의 성공률이 높아지면 평균 시간이 단축되고 워크로드의 가용성이 향상됩니다. 

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간: 특정 유형의 서비스 성능 저하의 경우 컨트롤 플레인이 영향을 받습니다. 개선을 위해 컨트롤 플레인을 광범위하게 사용하는 것에 의존하면 복구 시간(RTO)과 평균 복구 시간(MTTR)이 증가할 수 있습니다. 

## 구현 가이드
<a name="implementation-guidance"></a>

 데이터 영역 작업을 제한하려면 서비스를 복원하는 데 필요한 조치가 무엇인지 각 서비스를 평가하세요. 

 Amazon Application Recovery Controller (ARC) 활용하여 DNS 트래픽을 전환하세요. 이러한 기능은 애플리케이션의 장애 복구 성능을 지속적으로 모니터링하며, 이를 통해 여러 AWS 리전, 가용 영역 및 온프레미스에서 애플리케이션 복구를 제어할 수 있습니다. 

 Route 53 라우팅 정책은 컨트롤 플레인을 사용하므로 복구 시 컨트롤 플레인을 사용하지 마세요. Route 53 데이터 영역은 DNS 쿼리에 응답하고 상태 확인을 수행 및 평가합니다. 데이터 영역은 전역에 배포되며 [100% 가용성 서비스 수준에 관한 계약(SLA)을 위해 설계됩니다](https://aws.amazon.com/route53/sla/). 

 Route 53 리소스를 생성, 업데이트, 삭제하는 데 사용하는 Route 53 관리 API 및 콘솔은 DNS를 관리할 때 필요한 강력한 일관성과 내구성을 우선시하도록 설계된 컨트롤 플레인에서 실행됩니다. 이를 위해 컨트롤 플레인은 하나의 리전(미국 동부, 버지니아 북부)에 위치합니다. 두 시스템 모두 안정성이 높게 구축되었지만 컨트롤 플레인은 SLA에 포함되지 않습니다. 데이터 영역의 복원력 높은 설계가 컨트롤 플레인과 달리 가용성을 유지하는 상황이 드물게 있을 수 있습니다. 재해 복구 및 장애 조치 메커니즘에는 데이터 영역 기능을 사용하여 가능한 한 최고 수준의 신뢰성을 제공하십시오. 

 Amazon EC2의 경우 정적 안정성 설계를 사용하여 컨트롤 플레인 동작을 제한합니다. 컨트롤 플레인 작업에는 개별적으로 또는 Auto Scaling 그룹(ASG)을 사용한 리소스 규모 조정이 포함됩니다. 최고 수준의 복원력을 얻으려면 장애 조치에 사용되는 클러스터에 충분한 용량을 프로비저닝하세요. 이 용량 임계값을 제한해야 하는 경우 전체 엔드투엔드 시스템에 스로틀을 설정하여 총 트래픽이 제한된 리소스 세트에 도달하도록 안전하게 제한하십시오. 

 Amazon DynamoDB, Amazon API Gateway, 로드 밸런서 및 AWS Lambda 서버리스와 같은 서비스의 경우 이러한 서비스를 사용하면 데이터 영역을 활용할 수 있습니다. 하지만 새 함수, 로드 밸런서, API 게이트웨이 또는 DynamoDB 테이블을 생성하는 것은 컨트롤 플레인 작업이므로 이벤트 준비 및 장애 조치 리허설로 성능 저하 전에 완료해야 합니다. Amazon RDS의 경우, 데이터 영역 작업을 통해 데이터에 액세스할 수 있습니다. 

 데이터 영역, 컨트롤 플레인, 고가용성 목표를 충족하기 위해 AWS에서 서비스를 구축하는 방법에 관한 자세한 내용은 다음을 참조하세요. [가용 영역을 사용한 정적 안정성](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/). 

 데이터 영역을 사용할 작업과 제어 영역을 사용할 작업을 파악합니다. 

### 구현 단계
<a name="implementation-steps"></a>

 성능 저하 이벤트 후 복원해야 하는 각 워크로드에 대해 장애 조치 런북, 고가용성 설계, 자동 복구 설계 또는 HA 리소스 복원 계획을 평가하세요. 컨트롤 플레인 작업으로 간주될 수 있는 각 작업을 식별하세요. 

 컨트롤 작업을 데이터 영역 작업으로 변경하는 것을 고려해 보세요. 
+  Auto Scaling(컨트롤 플레인)과 사전 스케일링된 Amazon EC2 리소스(데이터 영역) 비교 
+  마이그레이션 Lambda 및 해당 스케일링 방법(데이터 영역) 또는 Amazon EC2 ASG(컨트롤 플레인) 
+  Kubernetes를 사용하는 모든 설계와 컨트롤 플레인 작업의 특성을 평가하세요. 포드를 추가하는 것은 Kubernetes의 데이터 영역 작업입니다. 작업은 포드를 추가하고 노드는 추가하지 않는 것으로 제한해야 합니다. 그리고 [오버프로비저닝된 노드는](https://www.eksworkshop.com/docs/autoscaling/compute/cluster-autoscaler/overprovisioning/) 컨트롤 플레인 작업을 제한하는 데 선호되는 방법입니다. 

 데이터 플레인 작업이 동일한 문제 해결에 영향을 줄 수 있는 다른 접근 방식을 고려해 보세요. 
+  Route 53 레코드 변경(컨트롤 플레인) 또는 ARC(데이터 영역) 
+ [ Route 53 자동 업데이트 향상을 위한 상태 점검 ](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)

 서비스가 업무상 중요한 경우 영향을 받지 않는 리전에서 더 많은 컨트롤 플레인 및 데이터 영역 작업을 수행할 수 있도록 보조 리전의 일부 서비스를 고려해 보세요. 
+  Amazon EC2 Auto Scaling 또는 기본 리전의 Amazon EKS와 보조 리전의 Amazon EC2 Auto Scaling이나 Amazon EKS를 비교하거나 트래픽을 보조 지역으로 라우팅하는 경우 (컨트롤 플레인 작업) 
+  보조 기본 리전에서 읽기 전용 복제본을 만들거나 기본 리전에서 동일한 작업 시도(컨트롤 플레인 작업) 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [가용성 정의](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 
+  [REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) 

 **관련 문서:** 
+  [APN 파트너: 내결함성 자동화를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=automation) 
+  [AWS Marketplace: 내결함성에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance) 
+  [소규모 서비스 제어를 통한 분산 시스템 오버로드 방지](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 데이터 영역](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html) 
+  [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/) 
+  [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 Route 53를 사용하여 재해 복구 메커니즘 생성](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) 
+  [Route 53 Application Recovery Controller란 무엇입니까?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+ [ Kubernetes 컨트롤 플레인 및 데이터 플레인 ](https://aws.amazon.com/blogs/containers/managing-kubernetes-control-plane-events-in-amazon-eks/)

 **관련 동영상:** 
+ [ 기본으로 돌아가기 - 정적 안정성 사용 ](https://www.youtube.com/watch?v=gy1RITZ7N7s)
+ [AWS 글로벌 서비스를 사용하여 복원력이 뛰어난 멀티사이트 워크로드 구축 ](https://www.youtube.com/watch?v=62ZQHTruBnk)

 **관련 예시:** 
+  [Amazon Route 53 Application Recovery Controller 소개](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/) 
+ [ 소규모 서비스 제어를 통한 분산 시스템 오버로드 방지 ](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [ 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/)
+ [ 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/)
+ [ 가용 영역을 사용한 정적 안정성 ](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)

 **관련 도구:** 
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)

# REL11-BP05 정적 안정성을 사용하여 바이모달 동작 방지
<a name="rel_withstand_component_failures_static_stability"></a>

 워크로드는 정적으로 안정적인 상태를 유지하고 단일 정상 모드에서만 작동해야 합니다. 바이모달 동작은 정상 모드와 장애 모드에서 워크로드가 서로 다른 동작을 보이는 경우입니다. 

 예를 들어 서로 다른 가용 영역에서 새 인스턴스를 시작하여 가용 영역 장애 복구를 시도할 수 있으며 이로 인해 장애 모드 중에 바이모달 응답이 발생할 수 있습니다. 그러나 이 방법 대신 정적으로 안정적이며 한 모드에서만 작동하는 워크로드를 구축해야 합니다. 이 예제에서 이러한 인스턴스는 장애가 발생하기 전에 두 번째 가용 영역에 프로비저닝되었어야 합니다. 이 정적 안정성 설계는 워크로드가 단일 모드에서만 작동하는지 확인합니다. 

 **원하는 결과:** 정상 모드와 장애 모드에서 워크로드가 바이모달 동작을 보이지 않습니다. 

 **일반적인 안티 패턴:** 
+  장애 범위에 관계없이 항상 리소스를 프로비저닝할 수 있다고 가정 
+  장애 발생 시 동적으로 리소스를 확보하려고 시도 
+  장애가 발생할 때까지 여러 영역 또는 리전에 걸쳐 적절한 리소스를 프로비저닝하지 않음 
+  컴퓨팅 리소스에 대해서만 정적이고 안정적인 설계를 고려 

 **이 모범 사례 확립의 이점:** 정적이고 안정적인 설계로 실행되는 워크로드는 정상 및 장애 이벤트 발생 시 예측 가능한 결과를 얻을 수 있습니다. 

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>

 바이모달 동작은 워크로드가 정상 모드와 장애 모드에서 다른 동작을 보일 때 발생합니다. 예를 들어 가용 영역에 장애가 발생할 경우 새 인스턴스를 시작하는 방법을 사용할 수 있습니다. 바이모달 동작의 예로는 한 AZ가 제거된 경우 안정적인 Amazon EC2 설계가 워크로드 로드를 처리하기에 충분한 인스턴스를 각 가용 영역에 프로비저닝하는 경우를 들 수 있습니다. 그런 다음 Elastic Load Balancing 또는 Amazon Route 53 상태를 확인하여 손상된 인스턴스로부터 로드를 이동합니다. 트래픽이 전환된 후에는 AWS Auto Scaling을 사용하여 장애가 발생한 영역의 인스턴스를 비동기식으로 교체하고 정상 영역에서 인스턴스를 시작합니다. 컴퓨팅 배포(예: EC2 인스턴스 또는 컨테이너)에서 정적 안정성은 최고의 신뢰성을 제공합니다. 

![\[가용 영역에 걸친 EC2 인스턴스의 정적 안정성을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/images/static-stability.png)


 모든 복원력 사례에서 워크로드를 유지 관리하는 데 따르는 비즈니스 가치 및 이 모델의 비용을 이 정적 안정성과 비교해야 합니다. 컴퓨팅 용량을 적게 프로비저닝하고 장애 발생 시 새 인스턴스를 시작하는 방법이 비용은 더 저렴하지만, 대규모 장애(예: 가용 영역 또는 리전 장애)의 경우 이 접근 방식은 영향을 받지 않는 영역 또는 리전에서 제공되는 충분한 리소스와 운영 플레인을 활용하기 때문에 덜 효과적입니다. 

 따라서 워크로드의 신뢰성 요구 사항과 비용 요구 사항도 비교해야 합니다. 정적 안정성 아키텍처는 가용 영역에 분산된 컴퓨팅 인스턴스, 데이터베이스 읽기 전용 복제본 설계, Kubernetes(Amazon EKS) 클러스터 설계, 다중 리전 장애 조치 아키텍처 등 다양한 아키텍처에 적용됩니다. 

 또한 각 영역에서 더 많은 리소스를 사용하여 더 정적으로 안정적인 설계를 구현할 수도 있습니다. 영역을 더 추가할수록 정적 안정성을 유지하는 데 필요한 추가 컴퓨팅 용량은 줄어듭니다. 

 바이모달 동작의 한 예는 시스템이 전체 시스템의 구성 상태를 새로 고치려고 시도할 수 있는 네트워크 시간제한입니다. 그러면 다른 구성 요소에 예기치 않은 로드가 더해져 해당 구성 요소에 장애가 발생하고 또 다른 예기치 않은 결과가 이어질 수 있습니다. 이 부정적인 피드백 루프는 워크로드의 가용성에 영향을 미칩니다. 대신 정적으로 안정적이며 한 모드에서만 작동하는 시스템을 구축할 수 있습니다. 일정한 작업을 수행하고 항상 고정된 케이던스에서 구성 상태를 새로 고치는 것이 정적으로 안정적인 설계의 하나일 것입니다. 호출이 실패하면 워크로드는 이전에 캐시된 값을 사용하고 경보를 트리거합니다. 

 바이모달 동작의 또 다른 예로 장애 발생 시 클라이언트에서 워크로드 캐시를 우회하는 것을 허용하는 동작이 있습니다. 이는 클라이언트 요구 사항을 수용한 솔루션처럼 보이지만 워크로드의 수요가 크게 변경될 수 있고 장애를 초래할 가능성이 높습니다. 

 중요 워크로드를 평가하여 이러한 유형의 레질리언스 설계가 필요한 워크로드를 결정합니다. 중요하다고 판단되는 워크로드에 대해서는 각 애플리케이션 구성 요소를 검토해야 합니다. 정적 안정성 평가가 필요한 서비스 유형의 예는 다음과 같습니다. 
+  **컴퓨팅**: Amazon EC2, EKS-EC2, ECS-EC2, EMR-EC2 
+  **데이터베이스**: Amazon Redshift, Amazon RDS, Amazon Aurora 
+  **스토리지**: Amazon S3(단일 영역), Amazon EFS(마운트), Amazon FSx(마운트) 
+  **로드 밸런서:** 특정 디자인에서 

### 구현 단계
<a name="implementation-steps"></a>
+  정적으로 안정적이고 한 모드에서만 작동하는 시스템을 구축합니다. 이 경우 가용 영역 또는 리전 하나가 제거된 경우 각 가용 영역 또는 리전에서 워크로드 용량을 처리할 만큼 충분한 인스턴스를 프로비저닝합니다. 다음과 같은 다양한 서비스를 사용하여 정상 리소스로 라우팅할 수 있습니다. 
  +  [교차 리전 DNS 라우팅](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html) 
  +  [MRAP Amazon S3 멀티리전 라우팅](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html) 
  +  [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) 
  +  [Amazon Application Recovery Controller (ARC)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+  데이터베이스 [읽기 전용 복제본을 구성하여](https://aws.amazon.com/rds/features/multi-az/) 단일 기본 인스턴스 또는 읽기 전용 복제본의 손실을 설명합니다. 읽기 전용 복제본으로 트래픽을 처리하는 경우 각 가용 영역 및 각 리전의 용량은 영역 또는 리전 장애 발생 시 필요한 전체 용량과 동일해야 합니다. 
+  가용 영역 장애 발생 시 저장된 데이터에 대해 정적으로 안정적으로 설계된 Amazon S3 스토리지에서 중요한 데이터를 구성합니다. 만약 [Amazon S3 One Zone-IA](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) 스토리지 클래스를 사용하는 경우, 해당 영역이 손실되면 저장된 데이터에 대한 액세스가 최소화되므로 이 스토리지 클래스를 정적으로 안정적인 것으로 간주해서는 안 됩니다. 
+  [로드 밸런서](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html) 가 잘못 구성되거나 특정 가용 영역을 서비스하도록 설계되는 경우가 간혹 있습니다. 이 경우 보다 복잡한 설계에서 여러 AZ에 워크로드를 분산하는 것이 정적으로 안정적인 설계일 수 있습니다. 원래 설계는 보안, 지연 시간 또는 비용상의 이유로 영역 간 트래픽을 줄이는 데 사용될 수 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 Well-Architected 모범 사례:** 
+  [가용성 정의](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 
+  [REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) 
+  [REL11-BP04 복구 중 컨트롤 플레인이 아닌 데이터 영역 사용](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html) 

 **관련 문서:** 
+  [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) 
+  [Fault Isolation Boundaries](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/appendix-a---partitional-service-guidance.html) 
+  [가용 영역을 사용한 정적 안정성](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) 
+  [다중 영역 RDS](https://aws.amazon.com/rds/features/multi-az/) 
+  [Minimizing Dependencies in a Disaster Recovery Plan(재해 복구 계획의 종속성 최소화)](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/) 
+  [교차 리전 DNS 라우팅](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html) 
+  [MRAP Amazon S3 멀티리전 라우팅](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html) 
+  [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) 
+  [ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+  [단일 영역 Amazon S3](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) 
+  [교차 영역 로드 밸런싱](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html) 

 **관련 동영상:** 
+  [AWS의 정적 안정성: AWS re:Invent 2019: Amazon Builders' Library(DOP328) 소개](https://youtu.be/sKRdemSirDM?t=704) 

 **관련 예시:** 
+  [Amazon Builders' Library: 가용 영역을 사용한 정적 안정성](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) 

# REL11-BP06 이벤트가 가용성에 영향을 미치는 경우 알림 전송
<a name="rel_withstand_component_failures_notifications_sent_system"></a>

 임계값 위반이 감지되면 문제를 일으킨 이벤트가 자동으로 해결된 경우에도 알림이 전송됩니다. 

 자동 복구를 사용하면 워크로드의 신뢰성을 유지할 수 있습니다. 그러나 자동 복구로 인해 해결해야 할 근본적인 문제가 가려질 수도 있습니다. 적절한 모니터링 및 이벤트를 구현하면 자동 복구로 해결된 문제를 포함한 문제의 패턴을 감지하여 근본 원인 문제를 해결할 수 있습니다. 

 복원력이 뛰어난 시스템은 성능 저하 이벤트가 해당 팀에 즉시 전달되도록 설계되었습니다. 이러한 알림은 하나 이상의 통신 채널을 통해 전송되어야 합니다. 

 **원하는 결과: **오류율, 지연 시간 또는 기타 중요한 핵심 성과 지표(KPI)와 같은 임계값을 위반하면 운영 팀에 즉시 알림이 전송되므로 이러한 문제를 최대한 빨리 해결하고 사용자에게 미치는 영향을 피하거나 최소화할 수 있습니다. 

 **일반적인 안티 패턴:** 
+  너무 많은 경보 전송 
+  실행 불가능한 경보 전송 
+  경보 임계값을 너무 높게(민감도 높음) 또는 너무 낮게(민감도 낮음) 설정 
+  외부 종속성에 대한 경보를 보내지 않음 
+  고려하지 않음 [고려해야 함](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) 모니터링 및 경보를 설계할 때 
+  복구 자동화를 수행하지만 해당 팀에 복구가 필요하다는 사실을 알리지 않음 

 **이 모범 사례 확립의 이점:** 운영 팀과 비즈니스 팀은 복구 알림을 통해 서비스 저하를 인지하고 즉시 대응하여 평균 탐지 시간(MTTD)과 평균 복구 시간(MTTR)을 모두 최소화할 수 있습니다. 또한 복구 이벤트에 대한 알림이 전송되면 어쩌다 발생하는 문제도 지나치지 않을 수 있습니다. 

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 보통. 적절한 모니터링 및 이벤트 알림 메커니즘을 구현하지 않으면 자동 복구로 해결된 문제를 포함하여 문제의 패턴을 감지하지 못할 수 있습니다. 팀은 사용자가 고객 서비스에 문의할 때나 우연히만 시스템 성능 저하 사실을 인지하게 됩니다. 

## 구현 가이드
<a name="implementation-guidance"></a>

 모니터링 전략을 정의할 때 경보가 울리는 것은 흔한 이벤트입니다. 이 이벤트에는 경보의 식별자, 즉 경보 상태(예: `경보 중` 또는 `확인`) 및 유발 원인에 대한 세부 정보가 포함되어 있을 것입니다. 대부분의 경우 경보 이벤트가 감지되고 이메일 알림이 전송되어야 합니다. 이것이 경보에 대한 작업의 예입니다. 경보 알림은 적절한 사용자에게 문제가 있음을 알려주기 때문에 관찰성에서 매우 중요합니다. 그러나 관찰성 솔루션에서 이벤트에 대한 작업이 성숙해지면 사람의 개입 없이 자동으로 문제를 해결할 수 있습니다. 

 KPI 모니터링 경보가 설정되면 임계값을 초과할 경우 해당 팀에 알림이 전송되어야 합니다. 이러한 알림은 성능 저하를 해결하기 위한 자동화된 프로세스를 트리거하는 데에도 사용될 수 있습니다. 

 보다 복잡한 임계값 모니터링의 경우 복합 경보를 고려해야 합니다. 복합 경보는 여러 KPI 모니터링 경보를 사용하여 운영 비즈니스 로직에 기반한 알림을 생성합니다. 이메일을 보내거나 Amazon SNS 통합 또는 Amazon EventBridge를 사용하여 서드파티 인시던트 추적 시스템에 인시던트를 기록하도록 CloudWatch Alarms를 구성할 수 있습니다. 

### 구현 단계
<a name="implementation-steps"></a>

 워크로드 모니터링 방식에 따라 다음과 같은 다양한 유형의 경보를 생성합니다. 
+  애플리케이션 경보는 워크로드의 일부가 제대로 작동하지 않는 경우를 감지하는 데 사용됩니다. 
+  [인프라 경보](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 리소스의 규모 조정 시점을 알려줍니다. 경보를 사용하면 대시보드에 경보를 시각적으로 표시하고, Amazon SNS 또는 이메일을 통해 알림을 전송하며, Auto Scaling을 통해 워크로드의 리소스 규모를 확장하거나 축소할 수 있습니다. 
+  간단한 [정적 경보](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) 지정된 평가 기간 중 지표가 정적 임계값을 위반하는 시점을 모니터링하기 위해 생성할 수 있습니다. 
+  [복합 경보](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) 여러 소스의 복잡한 경보를 설명할 수 있습니다. 
+  경보가 생성되면 적절한 알림 이벤트를 생성합니다. 직접 [Amazon SNS API를 호출하여](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 알림을 전송하고 문제 해결 또는 커뮤니케이션을 위한 자동화를 연결할 수 있습니다. 
+  성능 저하가 [있을 수 있는](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/) AWS 리소스에 대한 가시성을 모니터링할 수 있도록 Amazon Health Aware 모니터링을 위한 통합을 생성합니다. 비즈니스 필수 워크로드의 경우 이 솔루션을 통해 AWS 서비스에 대한 선제적인 실시간 알림에 액세스할 수 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 Well-Architected 모범 사례:** 
+  [가용성 정의](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.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) 
+  [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
+  [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Amazon Health Aware(AHA)](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/) 
+  [CloudWatch 복합 경보 설정](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) 
+  [AWS re:Invent 2022의 관찰성 관련 새로운 소식](https://aws.amazon.com/blogs/mt/whats-new-in-aws-observability-at-reinvent-2022/) 

 **관련 도구:** 
+  [CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html) 

# REL11-BP07 가용성 목표 및 가동 시간 서비스 수준에 관한 계약(SLA)을 충족하도록 제품 설계
<a name="rel_withstand_component_failures_service_level_agreements"></a>

가용성 목표 및 가동 시간 서비스 수준에 관한 계약(SLA)를 충족하도록 제품을 설계합니다. 가용성 목표 또는 가동 시간 SLA를 게시하거나 비공개로 동의하는 경우 아키텍처 및 운영 프로세스가 이를 지원하도록 설계되었는지 확인합니다. 

 **원하는 결과:** 각 애플리케이션에는 비즈니스 성과를 달성하기 위해 모니터링 및 유지 관리할 수 있는 성능 지표에 대해 정의된 가용성 및 SLA 목표가 있습니다. 

 **일반적인 안티 패턴:** 
+  SLA를 설정하지 않고 워크로드를 설계 및 배포합니다. 
+  SLA 지표는 근거나 비즈니스 요구 사항 없이 높게 설정됩니다. 
+  종속성 및 기본 SLA를 고려하지 않고 SLA를 설정합니다. 
+  애플리케이션 설계는 복원력에 대한 공동 책임 모델을 고려하지 않고 생성됩니다. 

 **이 모범 사례 확립의 이점:** 주요 복원력 목표를 기반으로 애플리케이션을 설계하면 비즈니스 목표와 고객 기대치를 충족하는 데 도움이 됩니다. 이러한 목표는 다양한 기술을 평가하고 다양한 장단점을 고려하는 애플리케이션 설계 프로세스를 추진하는 데 도움이 됩니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>

 애플리케이션 설계는 비즈니스, 운영 및 재무 목표에서 파생된 다양한 요구 사항 집합을 고려해야 합니다. 운영 요구 사항 내에서 워크로드는 적절하게 모니터링되고 지원될 수 있도록 특정 복원력 지표 대상을 가져야 합니다. 복원력 지표는 워크로드를 배포한 후에 설정하거나 파생해서는 안 됩니다. 설계 단계에서 정의해야 하며 다양한 결정과 장단점을 안내하는 데 도움이 됩니다. 
+  모든 워크로드에는 고유한 복원력 지표 세트가 있어야 합니다. 이러한 지표는 다른 비즈니스 애플리케이션과 다를 수 있습니다. 
+  종속성을 줄이면 가용성에 긍정적인 영향을 미칠 수 있습니다. 각 워크로드는 종속성과 해당 SLA를 고려해야 합니다. 일반적으로 가용성 목표가 워크로드 목표 이상인 종속성을 선택합니다. 
+  가능한 경우 종속성 손상에도 불구하고 워크로드가 올바르게 작동할 수 있도록 느슨하게 결합된 설계를 고려하세요. 
+  특히 복구 또는 성능 저하 중에 컨트롤 플레인 종속성을 줄입니다. 미션 크리티컬 워크로드에 대해 정적으로 안정적인 설계를 평가합니다. 리소스 스페어링을 사용하여 워크로드에서 이러한 종속성의 가용성을 높입니다. 
+  평균 탐지 시간(MTTD 및 평균 복구 시간(MTTR)을 줄임으로써 SLA를 달성하기 위해서는 관측성과 계측이 중요합니다. 
+  장애 빈도 감소(MTBF 증가), 장애 탐지 시간 단축(MTTD 감소) 및 복구 시간 단축(MTTR 감소)은 분산 시스템에서 가용성을 개선하는 데 사용되는 세 가지 요소입니다. 
+  워크로드에 대한 복원력 지표를 설정하고 충족하는 것은 모든 효과적인 설계의 기초입니다. 이러한 설계는 설계 복잡성, 서비스 종속성, 성능, 확장성 및 비용의 균형을 고려해야 합니다. 

 **구현 단계** 
+  다음 질문을 고려하여 워크로드 설계를 검토하고 문서화합니다. 
  +  워크로드에서 컨트롤 플레인은 어디에 사용됩니까? 
  +  워크로드는 내결함성을 어떻게 구현합니까? 
  +  확장, 자동 확장, 중복성 및 고가용성 구성 요소에 대한 디자인 패턴은 무엇입니까? 
  +  데이터 일관성 및 가용성에 대한 요구 사항은 무엇입니까? 
  +  리소스 절약 또는 리소스 정적 안정성에 대한 고려 사항이 있습니까? 
  +  서비스 종속성은 무엇입니까? 
+  이해관계자와 협력하면서 워크로드 아키텍처를 기반으로 SLA 지표를 정의합니다. 워크로드에서 사용하는 모든 종속성의 SLA를 고려합니다. 
+  SLA 목표가 설정되면 SLA를 충족하도록 아키텍처를 최적화합니다. 
+  SLA를 충족하는 설계가 설정되면 운영 변경, 프로세스 자동화 및 MTTD 및 MTTR 감소에 중점을 둔 런북을 구현합니다. 
+  배포되면 SLA를 모니터링하고 보고합니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [REL03-BP01 워크로드를 세그먼트화하는 방법 선택](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 워크로드를 여러 위치에 배포](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 모든 계층에서 복구 자동화](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP05 카오스 엔지니어링을 이용한 복원력 테스트](rel_testing_resiliency_failure_injection_resiliency.md) 
+  [REL13-BP01 가동 중단 시간 및 데이터 손실 시의 복구 목표 정의](rel_planning_for_recovery_objective_defined_recovery.md) 
+ [워크로드 상태 파악 파악](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-workload-health.html)

 **관련 문서:** 
+ [ Availability with redundancy(중복성이 적용된 가용성)](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [신뢰성 원칙 백서 - 가용성](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [ Measuring availability](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/measuring-availability.html)(가용성 측정)
+ [AWS Fault Isolation Boundaries(AWS 장애 격리 경계)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Shared Responsibility Model for Resiliency ](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/shared-responsibility-model-for-resiliency.html)(복원력을 위한 공동 책임 모델)
+ [가용 영역을 사용한 정적 안정성](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ [AWS 서비스 수준에 관한 계약(SLA)](https://aws.amazon.com/legal/service-level-agreements/)
+ [Guidance for Cell-based Architecture on AWS](https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/)(AWS의 셀 기반 아키텍처에 대한 지침)
+ [AWS infrastructure](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-infrastructure.html)(AWS 인프라)
+ [Advanced Multi-AZ Resiliance Patterns whitepaper](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html)(고급 다중 AZ 복원력 패턴 백서)

 **관련 서비스:** 
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)

# REL 12. 안정성은 어떻게 테스트합니까?
<a name="rel-12"></a>

프로덕션 환경의 스트레스에 대한 복원력을 가지도록 워크로드를 설계한 후 설계대로 작동하고 예상한 복원력을 제공하는지 확인할 수 있는 유일한 방법은 테스트입니다.

**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 플레이북을 사용하여 장애 조사
<a name="rel_testing_resiliency_playbook_resiliency"></a>

 잘 알려지지 않은 장애 시나리오에 일관되고 신속하게 대응할 수 있도록 플레이북에 조사 프로세스를 문서화합니다. 플레이북은 장애 시나리오에 영향을 미치는 요인을 식별하기 위해 수행되는 미리 정의된 단계입니다. 문제가 확인되거나 에스컬레이션될 때까지 각 프로세스 단계의 결과를 사용하여 다음에 수행할 단계를 결정합니다. 

 플레이북은 사후 대응적 조치를 효과적으로 수행하기 위해 반드시 수행해야 하는 사전 예방적 계획입니다. 플레이북에 포함되지 않은 장애 시나리오가 프로덕션 환경에서 발생할 경우 이 문제를 먼저 해결합니다(화재 진압). 그런 다음 돌아가서 문제를 해결하기 위해 취한 단계를 살펴보고 이를 사용하여 플레이북에 새 항목을 추가합니다. 

 플레이북은 특정 인시던트에 대응하여 사용되며 런북은 특정 결과를 달성하기 위해 사용됩니다. 런북은 일상적인 활동에 대해 사용되고, 플레이북은 일상적이지 않은 이벤트에 대응하는 데 사용되는 경우가 많습니다. 

 **일반적인 안티 패턴:** 
+  문제를 진단하거나 인시던트에 대응하는 프로세스를 모른 상태에서 워크로드 배포를 계획합니다. 
+  이벤트를 조사할 때 로그 및 지표를 수집할 시스템에 대한 무계획적 결정 
+  데이터를 검색할 수 있을 만큼 오래 지표 및 이벤트를 유지하지 않음 

 **이 모범 사례 수립의 이점:** 플레이북을 캡처하면 프로세스를 일관되게 따를 수 있습니다. 플레이북을 코드화하면 수작업으로 인한 오류 발생을 최소화할 수 있습니다. 플레이북을 자동화하면 팀원의 개입 요구 사항을 없애거나 개입을 시작할 때 추가 정보를 제공함으로써 이벤트에 대응하는 시간을 단축할 수 있습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  플레이북을 사용하여 문제를 파악합니다. 플레이북은 문제 조사를 위한 문서화된 프로세스입니다. 플레이북에 프로세스를 문서화하면 장애 발생 시나리오에 일관되고 빠르게 대응할 수 있습니다. 플레이북은 적절한 기술을 보유한 팀원이 해당하는 정보를 수집하고, 장애의 잠재적 출처를 확인하고, 결함 위치를 구분하고, 발생 요인을 확인(인시던트 사후 분석 수행)하는 데 필요한 정보와 지침을 포함해야 합니다. 
  +  코드로 플레이북을 구현합니다. 플레이북을 스크립트로 작성하여 작업을 코드로 수행하면 일관성을 유지하고 수동 프로세스에서 발생하는 오류를 최소화할 수 있습니다. 플레이북은 문제의 발생 요인을 식별하는 데 필요할 수 있는 다양한 단계를 나타내는 여러 스크립트로 구성할 수 있습니다. 플레이북 활동의 일부분으로 런북 활동을 트리거하거나 수행할 수도 있고, 확인된 이벤트 대응 과정에서 플레이북 실행 여부를 묻는 메시지를 표시할 수도 있습니다. 
    +  [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) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 인시던트 사후 분석 수행
<a name="rel_testing_resiliency_rca_resiliency"></a>

 고객에게 영향을 주는 이벤트를 검토하고 발생 요인과 예방 조치 항목을 식별합니다. 이 정보를 사용하여 재발을 제한하거나 방지하는 완화 기능을 개발합니다. 신속하고 효과적인 대응을 위한 절차를 개발합니다. 목표 대상에 맞게 적절히 발생 요인과 수정 조치를 전달합니다. 필요한 경우 다른 관계자들에게 이러한 원인을 전달하는 방법을 마련합니다. 

 기존 테스트에서 문제가 발견되지 않은 이유를 평가합니다. 테스트가 아직 없는 경우 이 사례에 대한 테스트를 추가합니다. 

 **원하는 결과:** 인시던트 사후 분석을 처리하는 일관되고 합의된 접근 방식이 마련되어 있습니다. 한 가지 메커니즘은 [오류 수정(COE) 프로세스](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)입니다. COE 프로세스는 인시던트의 근본 원인을 식별, 이해 및 해결하는 동시에 동일한 인시던트가 다시 발생할 가능성을 제한하는 메커니즘과 가드레일을 구축하는 데 도움이 됩니다. 

 **일반적인 안티 패턴:** 
+  발생 요인을 찾지만, 다른 잠재적 문제와 해결 방법을 계속 자세히 살펴보지는 않음 
+  인적 오류 원인만 식별하며, 인적 오류를 예방할 수 있는 교육이나 자동화는 제공하지 않음 
+  근본 원인을 이해하기보다는 책임을 전가하는 데 집중하여 공포의 문화를 조성하고 열린 의사소통을 방해합니다. 
+  인사이트를 공유하는 데 실패하여 인시던트 분석 결과를 소수의 사람만 알고 있고, 배운 교훈을 다른 사람들이 활용하지 못하게 합니다. 
+  제도적 지식을 포착할 메커니즘이 없기 때문에 학습한 교훈을 업데이트된 모범 사례의 형태로 보존하지 못해 귀중한 인사이트를 잃고 근본 원인이 동일하거나 유사한 인시던트가 반복적으로 발생합니다. 

 **이 모범 사례 확립의 이점:** 인시던트 사후 분석을 수행하고 결과를 공유하면 다른 워크로드에서 동일한 발생 요인이 나타날 경우 위험을 완화할 수 있으며 인시던트가 발생하기 전에 해결하거나 자동 복구를 구현할 수 있습니다. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 우수한 인시던트 사후 분석은 시스템의 다른 위치에서 사용되는 아키텍처 패턴이 있는 문제에 대해 공통 솔루션을 제안할 수 있는 기회를 제공합니다. 

 COE 프로세스의 초석은 문제를 문서화하고 해결하는 것입니다. 주요 근본 원인을 문서로 작성하고 검토 및 해결할 수 있는 표준 방식을 정의하는 것이 좋습니다. 인시던트 사후 분석 프로세스에 명확한 소유권을 부여합니다. 인시던트 조사 및 후속 조치를 감독할 책임이 있는 팀 또는 개인을 지정합니다. 

 책임을 전가하기보다는 학습과 개선에 초점을 맞추는 문화를 장려합니다. 개인에게 불이익을 주는 것이 아니라 향후 인시던트를 예방하는 것이 목표라는 점을 강조합니다. 

 인시던트 사후 분석을 수행하기 위한 잘 정의된 절차를 개발합니다. 이러한 절차에는 취해야 할 단계, 수집할 정보 및 분석 중에 해결해야 할 주요 질문이 요약되어 있어야 합니다. 즉각적인 원인을 넘어 근본 원인과 기여 요인을 식별하여 사고를 철저히 조사합니다. *[5가지 이유](https://en.wikipedia.org/wiki/Five_whys)*와 같은 기법을 사용하여 근본적인 문제를 심층적으로 분석합니다. 

 인시던트 분석을 통해 얻은 교훈의 리포지토리를 유지 관리합니다. 이러한 제도적 지식을 향후 인시던트 및 예방 노력에 참고할 수 있습니다. 인시던트 사후 분석에서 얻은 결과와 인사이트를 공유하고, 배운 교훈에 관해 논의하기 위해 누구나 참여할 수 있는 인시던트 사후 검토 모임을 개최합니다. 

### 구현 단계
<a name="implementation-steps"></a>
+  인시던트 사후 분석을 수행하는 과정에서 서로 비난하지 않도록 합니다. 이를 통해 인시던트에 관련된 사람들이 제안된 시정 조치에 대해 감정을 배제하고 팀 간의 솔직한 자체 평가와 협업을 촉진할 수 있습니다. 
+  중요한 문제를 문서화하는 표준화된 방법을 정의합니다. 이러한 문서의 구조를 예로 들면 다음과 같습니다. 
  +  무슨 일이 일어났나요? 
  +  문제가 고객과 비즈니스에 미친 영향 
  +  근본 원인 
  +  문제 지원을 위한 데이터 
    +  예: 지표 및 그래프 
  +  문제가 주요 핵심 요소(특히 보안)에 미친 영향 
    +  워크로드를 설계할 때는 업무 상황에 따라 이러한 핵심 요소를 절충해야 합니다. 이러한 비즈니스 의사 결정에 따라 엔지니어링 우선순위가 달라질 수 있습니다. 예를 들어 개발 환경에서는 안정성이 다소 낮아지더라도 비용을 절감하도록 최적화할 수 있고, 미션 크리티컬 솔루션의 경우에는 비용 증가를 감수하고 안정성을 기준으로 최적화할 수 있습니다. 하지만 고객 보호가 최우선이므로 모든 작업의 시작점은 항상 보안입니다. 
  +  문제를 통해 파악한 정보 
  +  진행 중인 시정 조치 
    +  조치 항목 
    +  관련 항목 
+  인시던트 사후 분석을 수행하기 위한 잘 정의된 표준 운영 절차를 만듭니다. 
+  표준화된 인시던트 보고 프로세스를 설정합니다. 초기 인시던트 보고서, 로그, 통신 및 인시던트 중에 취한 조치를 포함하여 모든 인시던트를 포괄적으로 문서화합니다. 
+  참고로 가동 중단이 일어나지 않더라도 인시던트일 수 있습니다. 중단이나 장애가 발생할 뻔한 상황, 시스템이 비즈니스 기능을 수행하면서도 예상치 못한 방식으로 작동하는 경우도 인시던트에 해당합니다. 
+  피드백과 교훈을 바탕으로 인시던트 사후 분석 프로세스를 지속적으로 개선합니다. 
+  지식 관리 시스템에서 주요 조사 결과를 캡처하고 개발자 가이드 또는 배포 전 체크리스트에 추가해야 할 패턴이 있는지 고려합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [Why you should develop a correction of error (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/) 

 **관련 동영상:** 
+ [ Amazon’s approach to failing successfully ](https://aws.amazon.com/builders-library/amazon-approach-to-failing-successfully/)
+ [AWS re:Invent 2021 - Amazon Builders’ Library: Operational Excellence at Amazon ](https://www.youtube.com/watch?v=7MrD4VSLC_w)

# REL12-BP03 기능 요구 사항 테스트
<a name="rel_testing_resiliency_test_functional"></a>

 단위 테스트와 필수 기능을 검증하는 통합 테스트 등의 기법을 사용합니다. 

 이러한 테스트는 구축 및 배포 작업의 일부로 자동으로 실행될 때 최상의 결과를 제공합니다. 예를 들어 개발자가 AWS CodePipeline을 사용하여 소스 리포지토리에 변경 사항을 커밋하면 CodePipeline이 변경 사항을 자동으로 감지합니다. 이러한 변경 사항이 구축되고 테스트가 실행됩니다. 테스트가 완료되면 테스트를 위해 구축된 코드가 스테이징 서버에 배포됩니다. CodePipeline은 스테이징 서버에서 통합 또는 로드 테스트와 같은 더 많은 테스트를 실행합니다. 이러한 테스트가 성공적으로 완료되면 CodePipeline은 테스트되고 승인된 코드를 프로덕션 인스턴스에 배포합니다. 

 또한 가장 중요한 테스트 중 하나는 고객 행동을 실행하고 시뮬레이션할 수 있는 가상 트랜잭션 테스트( *Canary 테스트라고도 하지만*카나리 배포와는 다름)입니다. 다양한 원격 위치에서 워크로드 엔드포인트에 대해 이러한 테스트를 지속적으로 실행합니다. Amazon CloudWatch Synthetics를 사용하면 엔드포인트 및 API 모니터링을 위한 [Canary를 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 할 수 있습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  기능 요구 사항을 테스트합니다. 여기에는 단위 테스트와 필수 기능을 검증하는 통합 테스트가 포함됩니다. 
  +  [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) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 확장 및 성능 요구 사항 테스트
<a name="rel_testing_resiliency_test_non_functional"></a>

 워크로드가 조정 및 성능 요구 사항을 충족하는지 확인하기 위한 로드 테스트 등의 기법을 사용합니다. 

 클라우드에서는 워크로드에 대한 프로덕션 규모의 테스트 환경을 필요할 때 생성할 수 있습니다. 축소된 인프라에서 이러한 테스트를 실행하는 경우 관찰된 결과를 프로덕션 환경에서 발생할 것으로 생각되는 범위까지 확장해야 합니다. 실제 사용자에게 영향을 주지 않도록 주의하고 실제 사용자 데이터 및 손상된 사용 통계 또는 프로덕션 보고서와 충돌하지 않도록 테스트 데이터에 태그를 지정하면 프로덕션에서도 로드 및 성능 테스트를 수행할 수 있습니다. 

 테스트를 통해 기본 리소스, 조정 설정, 서비스 할당량 및 복원력 설계가 로드 조건에서 예상대로 작동하는지 확인합니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  크기 조정 및 성능 요구 사항을 테스트합니다. 로드 테스트를 수행하여 워크로드가 크기 조정 및 성능 요구 사항을 충족하는지 확인합니다. 
  +  [AWS에서의 분산 로드 테스트: 수천 명의 연결된 사용자 시뮬레이션](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 
  +  [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected) 
    +  프로덕션 환경과 동일한 환경에 애플리케이션을 배포하고 로드 테스트를 수행합니다. 
      +  코드형 인프라를 사용하여 프로덕션 환경과 최대한 유사한 환경을 구축합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS에서의 분산 로드 테스트: 수천 명의 연결된 사용자 시뮬레이션](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 
+  [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected) 

# REL12-BP05 카오스 엔지니어링을 이용한 복원력 테스트
<a name="rel_testing_resiliency_failure_injection_resiliency"></a>

 시스템이 불리한 조건에서 어떻게 반응하는지 파악하려면 프로덕션 내 환경 또는 프로덕션과 최대한 가까운 환경에서 카오스 실험을 정기적으로 실행합니다. 

 ** 원하는 결과: ** 

 워크로드의 복원력은 이벤트 중 워크로드의 알려진 예상 동작을 확인하는 복원력 테스트 이외에 장애 주입 실험 또는 예기치 않은 부하 발생의 형태로 카오스 엔지니어링을 적용하여 정기적으로 확인합니다. 카오스 엔지니어링과 복원력 테스트를 결합하여 구성 요소 장애 시 워크로드가 중단되지 않고, 예기치 않은 중단이 발생한 경우에도 영향을 최소화하거나 아무런 영향 없이 복구할 수 있다는 확신을 얻을 수 있습니다. 

 ** 일반적인 안티 패턴: ** 
+  복원력을 뛰어나게 설계했으나 장애 발생 시 워크로드가 전체적으로 작동하는 방식을 확인하지 않습니다. 
+  실제 조건 및 예상되는 부하에서 절대 실험하지 않습니다. 
+  실험을 코드로 처리하지 않고 개발 주기 전체에서 유지 관리하지 않습니다. 
+  카오스 실험을 CI/CD 파이프라인의 일부로 또한 배포 범위 외부에서도 실행하지 않습니다. 
+  어떤 결함을 실험할지 결정할 때 과거의 인시던트 후 분석 사용에 소홀합니다. 

 ** 이 모범 사례 확립의 이점:** 워크로드의 복원력을 확인하기 위해 장애를 도입하면 탄력적인 설계의 복구 절차가 실제 장애 발생 시에도 잘 작동할 것으로 확신할 수 있습니다. 

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>

 카오스 엔지니어링은 서비스 공급자, 인프라, 워크로드 및 구성 요소 수준에서 고객에게 미치는 영향을 최소화하거나 아무런 영향을 미치지 않으면서 제어되는 방식으로 실제 중단(시뮬레이션)을 지속적으로 도입할 수 있는 역량을 팀에 제공합니다. 이렇게 하면 팀이 장애로부터 배우고 워크로드의 복원력을 관찰, 측정 및 개선하고 이벤트 발생 시 알림이 전달되고 팀이 알림을 받는지 확인할 수 있습니다. 

 지속적으로 수행하면 카오스 엔지니어링은 해결하지 않고 두면 가용성과 운영에 부정적인 영향을 미칠 수 있는 결함을 강조해서 보여줄 수 있습니다. 

**참고**  
카오스 엔지니어링은 프로덕션 환경의 급변하는 조건을 견딜 수 있는 시스템의 역량을 확신하기 위해 시스템에 대해 수행하는 실험 분야입니다. [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/2023-10-03/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에 대한 스트레스 테스트를 실행할 수 있습니다. 

## 구현 단계
<a name="implementation-steps"></a>
+  실험에 사용할 장애를 결정합니다. 

   워크로드 설계의 복원력을 평가합니다. 해당 설계( [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/2023-10-03/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) 이러한 데이터 캡처의 일부일 수 있습니다.

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [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 정기적으로 게임 데이 진행
<a name="rel_testing_resiliency_game_days_resiliency"></a>

 실제 장애 시나리오에 영향을 받을 직원들과 함께 게임 데이를 정기적으로 수행하여 프로덕션에 최대한 근접한 장애 및 이벤트 대응 절차(프로덕션 환경의 장애 절차 포함)를 연습합니다. 게임 데이에서는 프로덕션 이벤트가 사용자에게 영향을 미치지 않도록 하는 조치가 시행됩니다. 

 게임 데이에서는 장애나 이벤트를 시뮬레이션하여 시스템, 프로세스 및 팀 대응을 테스트합니다. 게임 데이의 목적은 이례적인 이벤트 발생 시 팀이 수행해야 할 작업을 실제로 수행해보는 것입니다. 그러면 어느 분야에서 개선이 필요한지 파악하고, 조직이 이벤트에 대처하는 경험을 쌓도록 도울 수 있습니다. 팀이 대응 방법을 *체득할 수 있도록* 게임 데이를 정기적으로 진행해야 합니다. 

 복원력을 위한 설계가 마련되고 비 프로덕션 환경에서 이 설계를 테스트한 후에는 실전 연습을 통해 모든 구성 요소가 프로덕션에서 예상대로 작동하는지 확인합니다. 실전 연습, 특히 첫 번째 실전 연습에서는 엔지니어와 운영 팀이 모두 모여 실전 연습의 일정과 내용에 대한 정보를 숙지합니다. 런북이 준비되어 있습니다. 프로덕션 시스템에서 미리 정해진 방식으로 발생할 수 있는 장애 이벤트를 비롯한 시뮬레이션 이벤트가 실행되고 영향이 평가됩니다. 모든 시스템이 설계대로 작동할 경우 감지 및 자가 복구가 수행됩니다. 영향은 거의 없습니다. 그러나 부정적인 영향이 관찰되면 테스트가 롤백되고 워크로드 문제가 해결됩니다. 필요한 경우 런북을 사용하여 수동으로 문제를 해결합니다. 게임 데이는 프로덕션에서 수행되는 경우가 많으므로 고객의 가용성에 영향을 미치는 일이 없도록 모든 예방 조치를 취해야 합니다. 

 **일반적인 안티 패턴:** 
+  절차를 문서화하지만 결코 연습하지 않음 
+  테스트 연습에 비즈니스 의사 결정권자가 참여하지 않음 

 **이 모범 사례 수립의 이점:** 게임 데이를 정기적으로 실시하면 실제 인시던트가 발생할 때 모든 직원이 정책과 절차를 따르도록 하고 이러한 정책과 절차가 적절한지 검증할 수 있습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  런북 및 플레이북을 정기적으로 실행하도록 게임 데이 수행 게임 데이에는 비즈니스 소유자, 개발 직원, 운영 직원 및 인시던트 대응 팀 등 프로덕션 이벤트에 관련된 모든 사람이 참여해야 합니다. 
  +  로드 또는 성능 테스트를 실행한 다음 장애 주입을 실행합니다. 
  +  런북에서 이상이 있는지 찾고 플레이북을 연습할 기회가 있는지 살펴봅니다. 
    +  런북에서 벗어난 경우 해당 런북을 구체화하거나 동작을 수정합니다. 플레이북을 실행하는 경우, 사용되었어야 하는 런북을 식별하거나 새로운 런북을 만듭니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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(재해 복구)를 어떻게 계획합니까?
<a name="rel-13"></a>

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 가동 중단 시간 및 데이터 손실 시의 복구 목표 정의
<a name="rel_planning_for_recovery_objective_defined_recovery"></a>

 워크로드에는 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/2023-10-03/framework/images/disaster-recovery-matrix.png)


 **일반적인 안티 패턴:** 
+  복구 목표가 정의되지 않음 
+  임의의 복구 목표 선택 
+  너무 관대하고 비즈니스 목표를 충족하지 못하는 복구 목표 선택 
+  가동 중단 시간 및 데이터 손실의 영향을 파악하지 않음 
+  워크로드 구성에서 달성할 수 없는 즉각 복구 또는 데이터 무손실과 같이 비현실적인 복구 목표 선택 
+  실제 비즈니스 목표보다 더 엄격한 복구 목표 선택. 이로 인해 워크로드에 필요한 수준 이상으로 DR 구현의 비용이 높아지고 DR 구현이 복잡해집니다. 
+  종속 워크로드와 호환되지 않는 복구 목표 선택 
+  규제 요구 사항을 고려하지 않은 복구 목표 
+  워크로드에 대한 RTO 및 RPO를 정의했으나 테스트하지 않음 

 **이 모범 사례 수립의 이점:** 재해 복구를 구현하는 데 기준이 될 시간 및 데이터 손실에 대한 복구 목표가 필요합니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 주어진 워크로드에서 가동 중단 시간 및 데이터 손실이 비즈니스에 미치는 영향을 파악해야 합니다. 가동 중단 시간이나 데이터 손실이 커질수록 일반적으로 영향이 커지지만, 영향이 어떻게 커지는지는 워크로드 유형에 따라 다를 수 있습니다. 예를 들어, 영향이 적을 때는 가동 중단 시간을 최대 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.  데이터에 대한 규제 또는 규정상의 제약은 무엇입니까? 

## 구현 워크시트
<a name="implementation-worksheet"></a>

 구현의 2 및 3단계에 이 워크시트를 사용하세요. 필요에 따라 질문을 추가하는 등 이 워크시트를 조정할 수 있습니다. 

<a name="worksheet"></a>![\[워크시트\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/images/worksheet.png)


 **구현 계획의 작업 수준: **낮음 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [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 복구 목표 달성을 위해 정의된 복구 전략 사용
<a name="rel_planning_for_recovery_disaster_recovery"></a>

워크로드의 복구 목표에 부합하는 재해 복구(DR) 전략을 정의합니다. 백업 및 복원, 대기(액티브/패시브), 액티브/액티브 등의 전략을 선택합니다.

 **원하는 결과:** 각 워크로드에 대해 워크로드가 DR 목표를 달성하도록 하는 DR 전략이 정의되고 구현되어 있습니다. 워크로드 간의 DR 전략은 재사용 가능한 패턴(예: 이전에 설명한 전략)을 활용합니다. 

 **일반적인 안티 패턴:** 
+  DR 목표가 유사한 워크로드에 일관적이지 않은 복구 절차를 구현합니다. 
+  재해가 발생했을 때 DR 전략이 임시로 구현되도록 합니다. 
+  재해 복구 계획을 마련하지 않았습니다. 
+  복구 시 컨트롤 플레인 작업에 의존합니다. 

 **이 모범 사례 확립의 이점:** 
+  정의된 복구 전략을 사용하면 공통적인 도구 및 테스트 절차를 사용할 수 있습니다. 
+  정의된 복구 전략을 사용하면 팀 간의 지식 공유와 팀이 소유한 워크로드에 대한 DR 구현이 향상됩니다. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 높음 DR 전략을 계획, 구현, 테스트하지 않으면 재해 발생 시 복구 목표를 달성하지 못할 가능성이 큽니다. 

## 구현 가이드
<a name="implementation-guidance"></a>

 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/2023-10-03/framework/images/disaster-recovery-strategies.png)

+  **백업 및 복원**(시간 단위 RPO, 24시간 이하의 RTO): 데이터와 애플리케이션을 DR 리전에 백업합니다. 자동화된 백업 또는 지속적인 백업을 사용하면 특정 시점 복구가 가능하여 경우에 따라서는 RPO를 5분까지 줄일 수 있습니다. 재해 이벤트 시 인프라를 배포하고(RTO를 단축하기 위해 코드형 인프라 사용), 코드를 배포하고, 백업 데이터를 복원하여 복구 리전에서 재해로부터 복구합니다. 
+  **파일럿 라이트**(분 단위 RPO, 10분 단위 RTO): 코어 워크로드의 인프라 복사본을 복구 리전에 프로비저닝합니다. 데이터를 복구 리전에 복제하고 복구 리전에서 백업을 생성합니다. 데이터베이스 및 객체 스토리지 등 데이터 복제 및 백업을 지원하는 데 필요한 리소스가 항상 실행됩니다. 애플리케이션 서버 또는 서버리스 컴퓨팅과 같은 기타 요소는 배포되지 않지만 필요에 따라 필수 구성 및 애플리케이션 코드로 생성될 수 있습니다. 
+  **웜 대기**(초 단위 RPO, 분 단위 RTO): 모든 기능을 갖추었지만 축소된 버전의 워크로드를 복구 리전에 항상 실행되는 상태로 유지합니다. 비즈니스 크리티컬 시스템은 완전히 복제되고 항상 실행되지만 플릿은 축소됩니다. 데이터가 복구 리전에 복제되며 실행됩니다. 복구 시기가 되면 시스템은 프로덕션 로드를 처리하기 위해 신속하게 확장됩니다. 웜 대기가 확장될수록 RTO 및 컨트롤 플레인 의존도는 낮아집니다. 완전히 확장되면 이것을 *상시 대기 방식*이라고 합니다. 
+  **다중 리전(다중 사이트) 액티브/액티브**(0에 가까운 RPO, 0일 수 있는 RTO): 워크로드가 여러 AWS 리전에 배포되고 능동적으로 트래픽을 처리합니다. 이 전략을 사용하려면 리전 전체에서 데이터를 동기화해야 합니다. 서로 다른 두 개 리전에 있는 복제본에 같은 레코드를 쓸 때 나타날 수 있는 충돌을 피하거나 처리해야 하는데, 그 방법이 복잡할 수 있습니다. 데이터 복제는 데이터 동기화에 유용하며 일부 유형의 재해로부터 보호해 주지만, 솔루션에 특정 시점 복구 옵션이 포함되지 않은 이상 데이터 손상 또는 중단으로부터 보호해 주지는 않습니다. 

**참고**  
 파일럿 라이트와 웜 대기 간의 차이를 이해하기 어려울 수 있습니다. 둘 다 복구 리전에 속한 환경과 기본 리전 자산의 복사본을 포함합니다. 차이점은 파일럿 라이트의 경우 먼저 추가 조치를 취하지 않으면 요청을 처리할 수 없지만 웜 대기는 축소된 용량 수준으로 트래픽을 즉시 처리할 수 있다는 점입니다. 파일럿 라이트를 사용하려면 서버를 켜야 하고 코어 인프라가 아닌 인프라를 추가로 배포해야 할 수 있으며 스케일 업해야 합니다. 반면 웜 대기를 사용하려면 스케일 업만 하면 됩니다. 다른 것은 이미 모두 배포되고 실행되는 상태입니다. RTO 및 RPO 요구 사항에 따라 두 전략 중에서 선택하십시오.   
 비용이 문제이고 웜 대기 전략에 정의된 것과 유사한 RPO 및 RTO 목표를 달성하려는 경우 파일럿 라이트 접근 방식을 취하고 향상된 RPO 및 RTO 목표를 제공하는 AWS Elastic Disaster Recovery와 같은 클라우드 네이티브 솔루션을 고려할 수 있습니다 

 **구현 단계** 

1.  **이 워크로드의 복구 요구 사항을 충족하는 DR 전략을 결정합니다.** 

 DR 전략을 선택할 때는 가동 중단 시간과 데이터 손실을 줄이는 것(RTO 및 RPO)과 전략 구현의 비용과 복잡성을 줄이는 것 사이에서 절충해야 합니다. 필요 이상으로 엄중한 전략을 구현하지 말아야 합니다. 불필요한 비용이 발생하기 때문입니다. 

 예를 들어, 다음 다이어그램에서 비즈니스는 허용 가능한 최대 RTO와 서비스 복원 전략에 지출할 수 있는 비용의 한계를 결정했습니다. 비즈니스의 목표를 감안할 때 파일럿 라이트 또는 웜 대기 DR 전략이 RTO와 비용 기준을 둘 다 만족시킵니다. 

![\[RTO와 비용에 따라 DR 전략을 선택하는 것을 보여주는 그래프\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/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/2023-10-03/framework/images/backup-restore-architecture.png)


 자세한 내용은 [Disaster Recovery (DR) Architecture on AWS, Part II: Backup and Restore with Rapid Recovery](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/)(AWS에서의 재해 복구(DR) 아키텍처, 파트 II: 빠른 복구와 백업 및 복원)를 참조하세요 

 **파일럿 라이트** 

 *파일럿 라이트* 접근 방식에서는 기본 리전에서 복구 리전으로 데이터를 복제합니다. 워크로드 인프라에 사용되는 코어 리소스가 복구 리전에 배포되지만 기능하는 스택이 되려면 기타 리소스 및 그 종속성이 여전히 필요합니다. 예를 들어 그림 20에서는 컴퓨팅 인스턴스가 배포되지 않았습니다. 

![\[파일럿 라이트 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/images/pilot-light-architecture.png)


 자세한 내용은 [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)(AWS에서의 재해 복구(DR) 아키텍처, 파트 III: 파일럿 라이트 및 웜 대기)를 참조하세요 

 **웜 대기** 

 *웜 대기* 접근법에서는 스케일 다운되었지만 완전히 기능하는 프로덕션 환경의 복사본이 다른 리전에 복사됩니다. 이 접근법은 파일럿 라이트의 개념을 확대하고 복구 시간을 단축합니다. 워크로드가 다른 리전에서 상시 실행되기 때문입니다. 복구 리전이 완전한 용량으로 배포되면 이것을 *상시 대기 방식*이라고 합니다. 

![\[그림 21: 웜 대기 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/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](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)(AWS에서의 재해 복구(DR) 아키텍처, 파트 III: 파일럿 라이트 및 웜 대기)를 참조하세요 

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

 *다중 사이트 액티브/액티브* 전략의 일부로 여러 리전에서 워크로드를 동시에 실행할 수 있습니다. 다중 사이트 액티브/액티브는 배포된 모든 리전에서 트래픽을 처리합니다. 고객은 DR과 다른 이유를 이 전략을 선택할 수 있습니다. 이 전략은 가용성을 높이기 위해서 또는 글로벌 사용자에게 워크로드를 배포하는 경우(사용자에게 엔드포인트를 가까이 가져가거나 해당 리전의 사용자에게 현지화된 스택을 배포하기 위해) 사용될 수 있습니다. DR 전략으로, 워크로드가 배포된 AWS 리전 중 하나에서 지원되지 않는다면 해당 리전이 철수되며 가용성을 유지하는 데 나머지 리전이 사용됩니다. 다중 사이트 액티브/액티브는 DR 전략 중 운영 측면에서 가장 복잡하며 비즈니스 요구 사항에 따라 필요한 경우에만 선택해야 합니다. 

![\[다중 사이트 액티브/액티브 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/images/multi-site-active-active-architecture.png)


 

 이 전략에 대한 자세한 내용은 [Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)(AWS에서의 재해 복구(DR) 아키텍처, 파트 IV: 다중 사이트 액티브/액티브 단원)를 참조하세요 

 **AWS Elastic Disaster Recovery** 

 재해 복구를 위해 파일럿 라이트 또는 웜 대기 전략을 고려하고 있다면, AWS Elastic Disaster Recovery는 이점이 개선된 대체 접근 방식을 제공할 수 있습니다. Elastic Disaster Recovery는 웜 대기와 유사한 RPO 및 RTO 목표를 제공할 수 있지만, 파일럿 라이트의 저비용 접근 방식을 유지합니다. Elastic Disaster Recovery는 초 단위의 RPO와 분 단위의 RTO를 달성하기 위해 지속적인 데이터 보호를 사용하여 기본 리전에서 복구 리전으로 데이터를 복제합니다. 데이터를 복제하는 데 필요한 리소스만 복구 영역에 배포되므로 파일럿 라이트 전략과 유사하게 비용이 절감됩니다. Elastic Disaster Recovery를 사용할 때 서비스는 장애 조치 또는 복구 드릴의 일부로 시작될 때 컴퓨팅 리소스의 복구를 조정하고 오케스트레이션합니다. 

![\[AWS Elastic Disaster Recovery의 작동 방식을 설명하는 아키텍처 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/framework/images/drs-architecture.png)


 

 **데이터 보호를 위한 기타 관행** 

 모든 전략에서 데이터 재해를 완화해야 합니다. 지속적인 데이터 복제는 일부 유형의 재해로부터 보호해 주지만, 전략에 저장된 데이터의 버전 관리 또는 특정 시점 복구 옵션이 포함되지 않은 이상 데이터 손상 또는 중단으로부터 보호해 주지는 않습니다. 복구 사이트에서 복제된 데이터를 백업하여 복제본 외에도 특정 시점 백업을 생성해야 합니다. 

 **하나의 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 자체에 장애가 발생하면) 대기 인스턴스가 기본 인스턴스로 승격되는 상시 대기 방식도 보여줍니다. 

![\[그림 24: 다중 AZ 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-10-03/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](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/)(Amazon Route53 Application Recovery Controller를 사용하여 복원력이 뛰어난 애플리케이션 구축, 파트 1: 단일 리전 스택)에 설명되어 있습니다. 여기에 나오는 전략은 리전의 작동 방식처럼 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)을 사용하면 [단일 템플릿](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)으로 배포된 스택이 액티브 상태인지 대기 상태인지 제어할 수 있습니다. Elastic Disaster Recovery를 사용할 때 서비스는 애플리케이션 구성 및 컴퓨팅 리소스의 복원을 복제하고 오케스트레이션합니다. 

 모든 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/UserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover)를 사용하는 경우 Aurora 글로벌 데이터베이스의 기존 복제 토폴로지가 유지됩니다. 따라서 기본 리전에 있는 이전의 읽기/쓰기 인스턴스가 복제본이 되고 복구 리전에서 업데이트를 수신합니다. 

 이 작업이 자동화되지 않는 경우 기본 리전에서 복구 리전의 데이터베이스의 복제본으로 데이터베이스를 다시 구축해야 합니다. 이때 이전의 기본 데이터베이스가 삭제되고 새로운 복제본이 생성되는 경우가 많습니다. 예를 들어 *계획되지 않은* 장애 조치를 가정한 Amazon Aurora 글로벌 데이터베이스로 이 작업을 수행하는 방법에 대한 지침은 이 실습: [Fail Back a Global Database](https://awsauroralabsmy.com/global/failback/)(글로벌 데이터베이스 페일백)를 참조하세요. 

 장애 조치 후 복구 리전에서 계속 실행할 수 있는 경우 이 리전을 새로운 기본 리전으로 만드는 것이 좋습니다. 이전의 기본 리전을 복구 리전으로 만들려면 위의 단계를 모두 따르면 됩니다. 일부 조직에서는 예약된 교체를 수행하여 기본 및 복구 리전을 주기적으로(예: 3개월마다) 교체합니다. 

 장애 조치 및 장애 복구가 필요한 모든 단계는 팀의 모든 멤버가 사용할 수 있는 플레이북에 유지 관리해야 하며 주기적으로 검토해야 합니다. 

 Elastic Disaster Recovery를 사용할 때 서비스는 페일백 프로세스를 오케스트레이션하고 자동화하는 데 도움이 됩니다. 자세한 내용은 [페일백 수행](https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html)을 참조하세요. 

 **구현 계획의 작업 수준:** 높음 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+ [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/) 
+  [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) 
+  [What Route 53 is Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)(Amazon Route 53 Application Recovery Controller란 무엇입니까?) 
+  [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) 

 **관련 동영상:** 
+  [Disaster Recovery of Workloads on AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)(AWS에서 워크로드의 재해 복구) 
+  [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications(ARC209-R2)](https://youtu.be/2e29I3dA8o4)(다중 리전 액티브-액티브 애플리케이션을 위한 아키텍처 패턴)(ARC209-R2) 
+  [AWS Elastic Disaster Recovery 시작하기 \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as) 

 **관련 예시:** 
+  [Well-Architected 실습 - 재해 복구](https://wellarchitectedlabs.com/reliability/disaster-recovery/) - DR 전략을 설명하는 일련의 워크숍 

# REL13-BP03 재해 복구 구현을 테스트하여 구현 확인
<a name="rel_planning_for_recovery_dr_tested"></a>

복구 사이트에 대한 장애 조치를 정기적으로 테스트하여 제대로 작동하고 RTO 및 RPO가 충족되는지 확인합니다.

 **일반적인 안티 패턴:** 
+  프로덕션 환경에서 장애 조치를 테스트하지 않음 

 **이 모범 사례 확립의 이점:** 재해 복구 계획을 정기적으로 테스트하면 필요할 때 제대로 작동하도록 보장하고 팀이 전략 실행 방법을 숙지하고 있는지 확인할 수 있습니다. 

 **이 모범 사례를 따르지 않을 경우 노출 위험도:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 거의 사용되지 않는 복구 경로를 개발하는 것은 피해야 할 패턴입니다. 읽기 전용 쿼리에 사용되는 보조 데이터 스토어를 예로 들 수 있습니다. 데이터 스토어에 데이터를 쓸 때 기본 스토어에서 장애가 발생하면 보조 데이터 스토어로 장애 조치를 진행할 수 있습니다. 이 장애 조치를 자주 테스트하지 않으면 보조 데이터 스토어의 기능에 대한 가정이 잘못될 수 있습니다. 예를 들어 마지막으로 테스트했을 때는 보조 용량이 충분했지만 이 시나리오에서는 더 이상 로드를 모두 처리하지 못할 수도 있습니다. 경험에 따르면 자주 테스트하는 경로만이 유일하게 작동하는 오류 복구 방법입니다. 이러한 이유로 인해 복구 경로를 적게 갖는 것이 가장 좋습니다. 복구 패턴을 설정하고 정기적으로 테스트할 수 있습니다. 복잡하거나 중요한 복구 경로가 있는 경우 해당 복구 경로의 작동을 확신하기 위해 프로덕션 환경에서 해당 장애를 정기적으로 연습해야 합니다. 앞에서 설명한 예의 경우에는 필요 여부에 관계없이 대기 스토어로 정기 장애 조치를 수행해야 합니다. 

 **구현 단계** 

1.  복구가 가능하도록 워크로드를 설계합니다. 복구 경로를 정기적으로 테스트합니다. 복구 지향 컴퓨팅은 복구를 향상시키는 시스템의 특성을 식별합니다. 이러한 특성으로는 격리 및 중복성, 변경 사항을 롤백하는 시스템 전체 기능, 상태 모니터링 및 결정 기능, 진단 제공 기능, 자동 복구, 모듈식 설계 및 재시작 기능 등이 있습니다. 지정된 시간에 지정한 상태로 복구를 수행할 수 있도록 복구 경로에 대해 연습하세요. 이 복구 과정에 런북을 사용하여 문제를 문서화하고 다음 테스트 전에 해결 방법을 찾습니다. 

1. Amazon EC2 기반 워크로드의 경우 [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)를 사용하여 DR 전략을 위한 드릴 인스턴스를 구현하고 시작합니다. AWS Elastic Disaster Recovery는 훈련을 효율적으로 실행할 수 있는 기능을 제공하여 장애 조치 이벤트를 준비하는 데 도움이 됩니다. 트래픽을 리디렉션하지 않고 테스트 및 드릴 목적으로 Elastic Disaster Recovery를 사용하여 인스턴스를 자주 시작할 수도 있습니다.

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) 
+  [AWS에서 워크로드의 재해 복구: 클라우드에서의 복구(AWS 백서)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 
+  [AWS Elastic Disaster Recovery 장애 조치 준비](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html) 
+  [The Berkeley/Stanford recovery-oriented computing project(Berkeley/Stanford 복구 중심 컴퓨팅 프로젝트)](http://roc.cs.berkeley.edu/) 
+  [AWSFault 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](https://youtu.be/2e29I3dA8o4)(다중 리전 액티브-액티브 애플리케이션을 위한 아키텍처 패턴) 
+  [AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS](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 사이트 또는 리전에서 구성 드리프트 관리
<a name="rel_planning_for_recovery_config_drift"></a>

 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 환경이 기존 환경과 일치하는지 확인하면 완전한 복구를 보장할 수 있습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  배포 파이프라인이 기본 사이트와 백업 사이트 모두에 제공되는지 확인합니다. 애플리케이션을 프로덕션에 배포하기 위한 배포 파이프라인은 개발 및 테스트 환경을 포함하여 지정된 모든 재해 복구 전략 위치에 배포해야 합니다. 
+  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) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 복구 자동화
<a name="rel_planning_for_recovery_auto_recovery"></a>

 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 재해 복구도 지원합니다. 

 **일반적인 안티 패턴:** 
+  자동 장애 조치와 자동 장애 복구를 동일하게 구현하면 장애가 발생할 때 플래핑을 유발할 수 있습니다. 

 **이 모범 사례 수립의 이점:** 자동 복구는 수작업으로 인한 오류 발생 가능성을 없앰으로써 복구 시간을 단축합니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  복구 경로를 자동화합니다. 짧은 복구 시간이 요구되는 고가용성 시나리오에서는 인간의 판단 및 수작업을 사용할 수 없습니다. 모든 상황에서 시스템이 자동으로 복구되어야 합니다. 
  +  자동 장애 조치 및 장애 복구를 위해 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/) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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)