# REL 11  구성 요소 장애를 견디도록 워크로드를 설계하려면 어떻게 해야 합니까? 고가용성 및 낮은 MTTR(평균 복구 시간)이 요구되는 워크로드는 복원력을 고려하여 설계해야 합니다. **Topics** + [REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지](rel_withstand_component_failures_monitoring_health.md) + [REL11-BP02 정상 리소스로 장애 조치](rel_withstand_component_failures_failover2good.md) + [REL11-BP03 모든 계층에서 복구 자동화](rel_withstand_component_failures_auto_healing_system.md) + [REL11-BP04 복구 중 컨트롤 플레인이 아닌 데이터 영역 사용](rel_withstand_component_failures_avoid_control_plane.md) + [REL11-BP05 정적 안정성을 사용하여 바이모달 동작 방지](rel_withstand_component_failures_static_stability.md) + [REL11-BP06 이벤트가 가용성에 영향을 미치는 경우 알림 전송](rel_withstand_component_failures_notifications_sent_system.md) # REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지 워크로드 상태를 지속적으로 모니터링하여 성능 저하 또는 장애가 발생하는 즉시 수동 및 자동화된 시스템을 통해 이를 인식할 수 있도록 합니다. 비즈니스 가치를 기반으로 KPI(핵심 성능 지표)를 모니터링합니다. 모든 복구 메커니즘은 문제를 신속하게 탐지하는 기능에서 시작되어야 합니다. 기술적 장애를 먼저 감지하여 해결합니다. 그러나 가용성은 비즈니스 가치를 제공하는 워크로드의 기능에 따라 결정되므로 이 요구 사항을 측정하는 핵심 성과 지표(KPI)를 탐지 및 수정 전략의 핵심 척도로 사용해야 합니다. **일반적인 안티 패턴:** + 경보가 구성되지 않았기 때문에 알림 없이 중단이 발생합니다. + 경보가 존재하지만 대응 시간이 충분하지 않은 임계치에 있습니다. + 지표는 RTO(복구 시간 목표)를 충족하기에 충분한 지표가 수집되지 않는 경우가 많습니다. + 워크로드의 고객용 계층만 능동적으로 모니터링됩니다. + 기술 지표만 수집하며 비즈니스 기능 지표는 수집하지 않습니다. + 워크로드의 사용자 경험을 측정하는 지표가 없습니다. **이 모범 사례 수립의 이점:** 모든 계층에서 적절한 모니터링을 사용하면 감지 시간을 단축하여 복구 시간을 줄일 수 있습니다. **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 ## 구현 가이드 + 복구 목표에 따라 구성 요소의 수집 간격을 결정합니다. + 모니터링 간격은 필요한 복구 속도에 따라 달라집니다. 복구 시간은 복구에 걸리는 시간에 따라 결정되므로 이 시간과 RTO(복구 시간 목표)를 고려하여 수집 빈도를 결정해야 합니다. + 구성 요소에 대한 세부 모니터링을 구성합니다. + EC2 인스턴스 및 Auto Scaling에 대한 세부 모니터링이 필요한지 결정합니다. 세부 모니터링은 1분 간격 지표를 제공하며 기본 모니터링은 5분 간격 지표를 제공합니다. + [인스턴스에 대한 세부 모니터링 활성화 또는 비활성화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) + [Amazon CloudWatch를 사용하여 오토 스케일링 및 인스턴스 모니터링](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) + RDS에 대한 향상된 모니터링이 필요한지 결정합니다. 향상된 모니터링은 RDS 인스턴스의 에이전트를 사용하여 RDS 인스턴스의 여러 프로세스 또는 스레드에 대한 유용한 정보를 가져옵니다. + [Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) + 비즈니스 핵심 성과 지표(KPI)를 측정하는 사용자 지정 지표를 생성합니다. 워크로드는 주요 비즈니스 기능을 구현합니다. 이러한 기능은 간접 문제가 발생하는 시기를 식별하는 데 도움이 되는 KPI로 사용되어야 합니다. + [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + 사용자 canary를 사용하여 사용자 경험의 장애를 모니터링합니다. 가장 중요한 테스트 중 하나는 고객 행동을 실행하고 시뮬레이션할 수 있는 가상 트랜잭션 테스트(‘Canary 테스트’라고도 하지만 카나리 배포와는 다름)입니다. 다양한 원격 위치에서 워크로드 엔드포인트에 대해 이러한 테스트를 지속적으로 실행합니다. + [Amazon CloudWatch Synthetics로 사용자 Canary 생성 지원](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) + 사용자 경험을 추적하는 사용자 지정 지표를 생성합니다. 고객의 경험을 계측할 수 있으면 소비자 경험이 저하되는 시기를 결정할 수 있습니다. + [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + 워크로드의 일부가 제대로 작동하지 않는 시기를 감지하고 리소스의 크기를 자동 조정해야 하는 시점을 알려주는 경보를 설정합니다. 경보를 사용하면 대시보드에 경보를 시각적으로 표시하고, Amazon SNS 또는 이메일을 통해 알림을 전송하며, Auto Scaling을 통해 워크로드의 리소스를 스케일 업 또는 다운할 수 있습니다. + [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + 지표를 시각화하는 대시보드를 생성합니다. 대시보드를 사용하면 추세, 이상값 및 기타 잠재적 문제의 지표를 시각적으로 표시하거나, 조사가 필요할 수 있는 문제를 표시할 수 있습니다. + [CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) ## 리소스 **관련 문서:** + [Amazon CloudWatch Synthetics로 사용자 Canary 생성 지원](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) + [인스턴스에 대한 세부 모니터링 활성화 또는 비활성화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) + [Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) + [Amazon CloudWatch를 사용하여 오토 스케일링 및 인스턴스 모니터링](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) + [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + [CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) **관련 예시:** + [Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability(Well-Architected 실습: 레벨 300: 상태 확인 구현 및 종속성 관리를 통한 안정성 개선)](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html) # REL11-BP02 정상 리소스로 장애 조치 리소스 장애가 발생할 경우 정상 리소스가 계속해서 요청을 처리할 수 있는지 확인합니다. 위치 장애(예: 가용 영역 또는 AWS 리전)의 경우, 손상되지 않은 위치의 정상 리소스로 장애 조치할 수 있는 시스템을 갖추고 있어야 합니다. Elastic Load Balancing, AWS Auto Scaling 등의 AWS 서비스는 리소스와 가용 영역에 걸쳐 로드를 분산하도록 도와줍니다. 따라서 남아 있는 상태가 양호한 리소스로 트래픽을 이동시켜 개별 리소스(예: EC2 인스턴스)의 장애 또는 가용 영역의 장애를 완화할 수 있습니다. 다중 리전 워크로드의 경우 이 작업이 더 복잡합니다. 예를 들어 리전 간 읽기 전용 복제본을 사용하여 데이터를 여러 AWS 리전에 배포할 수 있지만, 장애 조치가 발생할 경우 읽기 전용 복제본을 기본으로 승격하고 트래픽을 해당 위치로 지정해야 합니다. Amazon Route 53 및 AWS Global Accelerator는 AWS 리전 전체에 트래픽을 라우팅하도록 도와줍니다. 워크로드에서 Amazon S3 또는 Amazon DynamoDB와 같은 AWS 서비스를 사용하는 경우 이러한 서비스는 여러 가용 영역에 자동으로 배포됩니다. 장애가 발생하면 AWS 컨트롤 플레인이 자동으로 정상적인 위치로 트래픽을 라우팅합니다. 데이터가 여러 가용 영역에 중복으로 저장되고 가용성이 유지됩니다. Amazon RDS의 경우 구성 옵션으로 다중 AZ를 선택해야 합니다. 그러면 장애 시 AWS가 자동으로 트래픽을 정상 인스턴스로 보냅니다. Amazon EC2 인스턴스, Amazon ECS 태스크 또는 Amazon EKS 포드의 경우에는 배포할 가용 영역을 선택합니다. 그러면 Elastic Load Balancing이 비정상 영역에서 인스턴스를 감지하고 정상적인 영역으로 트래픽을 라우팅합니다. Elastic Load Balancing을 사용하는 경우 온프레미스 데이터 센터의 구성 요소로 트래픽을 라우팅할 수도 있습니다. 다중 리전 접근 방식(온프레미스 데이터 센터도 포함될 수 있음)의 경우 Amazon Route 53를 사용하여 인터넷 도메인을 정의하고, 트래픽이 정상적인 리전으로 라우팅되도록 상태 확인을 포함하는 라우팅 정책을 할당할 수 있습니다. 또는 AWS Global Accelerator가 제공하는 정적 IP 주소를 애플리케이션의 고정된 진입점으로 사용하고 인터넷 대신 AWS 글로벌 네트워크를 사용하여 선택한 AWS 리전의 엔드포인트로 라우팅하여 성능과 신뢰성을 개선할 수 있습니다. AWS에서는 장애 복구를 고려한 서비스 설계 방식이 사용됩니다. 즉, 장애에서 복구하는 시간과 데이터에 대한 영향을 최소화하는 방식으로 서비스가 설계됩니다. AWS 서비스는 기본적으로 한 리전 내의 여러 복제본에 저장된 요청만 승인하는 데이터 스토어를 사용합니다. 이러한 서비스와 리소스에는 Amazon Aurora, Amazon Relational Database Service(Amazon RDS) Multi-AZ DB 인스턴스, Amazon S3, Amazon DynamoDB, Amazon Simple Queue Service(Amazon SQS), Amazon Elastic File System(Amazon EFS) 등이 있습니다. 이러한 서비스/리소스는 셀 기반 격리와 가용 영역에서 제공되는 장애 격리 기능을 사용하도록 구성됩니다. AWS의 운영 절차에서는 자동화가 광범위하게 사용됩니다. 또한 서비스 중단 시 빠르게 복구할 수 있도록 교체 및 다시 시작 기능도 최적화됩니다. **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 ## 구현 가이드 + 정상 리소스로 장애 조치합니다. 리소스 장애가 발생할 경우 정상 리소스가 계속해서 요청을 처리할 수 있는지 확인합니다. 위치 장애(예: 가용 영역 또는 AWS 리전)의 경우, 손상되지 않은 위치의 정상 리소스로 장애 조치할 수 있는 시스템을 갖추고 있어야 합니다. + 워크로드에서 Amazon S3 또는 Amazon DynamoDB와 같은 AWS 서비스를 사용하는 경우 이러한 서비스는 여러 가용 영역에 자동으로 배포됩니다. 장애가 발생하면 AWS 컨트롤 플레인이 자동으로 정상적인 위치로 트래픽을 라우팅합니다. + Amazon RDS의 경우 구성 옵션으로 다중 AZ를 선택해야 합니다. 그러면 장애 시 AWS가 자동으로 트래픽을 정상 인스턴스로 보냅니다. + [Amazon RDS를 위한 고가용성(다중 AZ)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) + Amazon EC2 인스턴스 또는 Amazon ECS 태스크의 경우에는 배포할 가용 영역을 선택합니다. 그러면 Elastic Load Balancing이 비정상 영역에서 인스턴스를 감지하고 정상적인 영역으로 트래픽을 라우팅합니다. Elastic Load Balancing을 사용하는 경우 온프레미스 데이터 센터의 구성 요소로 트래픽을 라우팅할 수도 있습니다. + 다중 리전 접근 방식(온프레미스 데이터 센터도 포함될 수 있음)의 경우 정상적인 위치의 데이터와 리소스가 계속해서 요청을 처리할 수 있는지 확인합니다. + 예를 들어 리전 간 읽기 전용 복제본을 사용하여 데이터를 여러 AWS 리전에 배포할 수 있지만, 기본 위치에 장애가 발생할 경우 읽기 전용 복제본을 마스터로 승격하고 트래픽을 해당 위치로 지정해야 합니다. + [Amazon RDS 읽기 전용 복제본 개요](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) + Amazon Route 53를 사용하여 인터넷 도메인을 정의하고 트래픽이 정상적인 리전으로 라우팅되도록 상태를 확인하는 등 라우팅 정책을 할당할 수 있습니다. 또는 AWS Global Accelerator가 제공하는 정적 IP 주소를 애플리케이션의 고정된 진입점으로 사용하고 퍼블릭 인터넷 대신 AWS 글로벌 네트워크를 사용하여 선택한 AWS 리전의 엔드포인트로 라우팅하여 성능과 신뢰성을 개선할 수 있습니다. + [Amazon Route 53: 라우팅 정책 선택](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) + [AWS Global Accelerator란 무엇입니까?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) ## 리소스 **관련 문서:** + [APN 파트너: 내결함성 자동화를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=automation) + [AWS Marketplace: 내결함성에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance) + [AWS OpsWorks: Using Auto Healing to Replace Failed Instances(AWS OpsWorks: 자동 복구를 사용하여 실패한 인스턴스 대체)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html) + [Amazon Route 53: 라우팅 정책 선택](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) + [Amazon RDS를 위한 고가용성(다중 AZ)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) + [Amazon RDS 읽기 전용 복제본 개요](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) + [Amazon ECS 태스크 배치 전략](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html) + [Creating Kubernetes Auto Scaling Groups for Multiple Availability Zones(여러 가용 영역에 Kubernetes Auto Scaling 그룹 생성)](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/) + [AWS Global Accelerator란 무엇입니까?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) **관련 예시:** + [Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability(Well-Architected 실습: 레벨 300: 상태 확인 구현 및 종속성 관리를 통한 안정성 개선)](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html) # REL11-BP03 모든 계층에서 복구 자동화 장애가 감지되면 자동화된 기능을 사용하여 수정 작업을 수행합니다. *재시작 기능* 은 장애를 해결하는 데 사용할 수 있는 중요한 도구입니다. 분산 시스템에서 모범 사례는 앞서 설명한 것처럼 가능한 경우 서비스를 상태 비저장으로 만드는 것입니다. 이렇게 하면 재시작 시 데이터 손실 또는 가용성이 손실되는 것을 방지할 수 있습니다. 클라우드에서는 재시작의 일부로 전체 리소스(예: EC2 인스턴스 또는 Lambda 함수)를 대체할 수 있으며 이러한 대체는 일반적으로 필수적입니다. 재시작은 그 자체로 장애를 복구할 수 있는 단순하면서도 안정적인 방법입니다. 워크로드에는 다양한 유형의 장애가 발생합니다. 장애는 하드웨어, 소프트웨어, 통신 및 작업 과정에서 발생할 수 있습니다. 서로 다른 유형의 장애를 각각 격리, 식별 및 수정하는 새로운 메커니즘을 구성하는 대신 여러 범주의 장애를 동일한 복구 전략에 매핑하는 것이 좋습니다. 인스턴스는 하드웨어 결함, 운영 체제 버그, 메모리 누수 또는 기타 원인으로 인해 장애를 경험할 수 있습니다. 이러한 장애가 발생할 경우 각 상황에 맞춰진 수정 조치를 구축하는 대신 인스턴스 장애로 처리하십시오. 인스턴스를 종료하고 AWS Auto Scaling을 통해 인스턴스를 교체합니다. 나중에 환경 외부에서 장애 발생 리소스 분석을 수행할 수 있습니다. 또 다른 예는 네트워크 요청을 다시 시작하는 기능입니다. 네트워크 시간 제한 장애와 종속성 장애(종속성이 오류를 반환함)에 대해 같은 복구 방식이 적용됩니다. 두 이벤트는 모두 시스템에 비슷한 영향을 주므로, 한 이벤트를 “특수 사례”로 처리하는 대신 지수 백오프 및 지터를 통해 제한적으로 재시도하는 비슷한 전략이 적용됩니다. *재시작 기능* 은 복구 중심 컴퓨팅 및 고가용성 클러스터 아키텍처에 포함된 복구 메커니즘입니다. Amazon EventBridge를 사용하면 CloudWatch 경보 또는 다른 AWS 서비스의 상태 변경과 같은 이벤트를 모니터링하고 필터링할 수 있습니다. 그런 다음 이벤트 정보를 기반으로 AWS Lambda, AWS Systems Manager Automation 또는 다른 대상을 트리거하여 워크로드에 대한 맞춤형 수정 로직을 실행할 수 있습니다. EC2 인스턴스 상태를 확인하도록 Amazon EC2 Auto Scaling을 구성할 수 있습니다. 인스턴스가 실행 중 이외의 상태이거나 시스템 상태가 손상된 경우 Amazon EC2 Auto Scaling은 해당 인스턴스를 비정상으로 간주하고 대체 인스턴스를 시작합니다. AWS OpsWorks를 사용하는 경우 OpsWorks 계층 수준에서 EC2 인스턴스의 자동 복구 기능을 구성할 수 있습니다. 대규모 교체(예: 전체 가용 영역이 손실됨)의 경우 한 번에 여러 개의 새 리소스를 확보하는 대신 정적 안정성을 통해 고가용성을 유지하는 것이 좋습니다. **일반적인 안티 패턴:** + 인스턴스 또는 컨테이너에 개별적으로 애플리케이션 배포. + 자동 복구를 사용하지 않고 여러 위치에 배포할 수 없는 애플리케이션을 배포. + 자동 크기 조정 및 자동 복구로 복구하지 못한 애플리케이션을 수동으로 복구. **이 모범 사례 수립의 이점:** 자동 복구는 워크로드를 한 번에 한 위치에만 배포할 수 있는 경우에도 평균 복구 시간을 단축하고 워크로드의 가용성을 보장합니다. **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 ## 구현 가이드 + Auto Scaling 그룹을 사용하여 워크로드에 계층을 배포합니다. Auto Scaling은 무상태 애플리케이션에서 자가 복구를 수행하고 용량을 추가 및 제거할 수 있습니다. + [AWS Auto Scaling 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) + 여러 위치에 배포할 수 없고 장애 발생 시 재부팅이 허용되는 애플리케이션이 배포되어 있는 EC2 인스턴스에 자동 복구를 구현합니다. 애플리케이션을 여러 위치에 배포할 수 없는 경우 자동 복구를 사용하여 장애가 발생한 하드웨어를 교체하고 인스턴스를 다시 시작할 수 있습니다. 인스턴스 메타데이터 및 관련 IP 주소는 물론 Amazon EBS 볼륨과 Elastic File System 및 Lustre/Windows용 파일 시스템의 탑재 지점도 유지됩니다. + [Amazon EC2 자동 복구](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) + [Amazon Elastic Block Store(Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) + [Amazon Elastic File System(Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) + [Amazon FSx for Lustre란 무엇입니까?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) + [Amazon FSx for Windows File Server란 무엇입니까?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) + AWS OpsWorks를 사용하는 경우 계층 수준에서 EC2 인스턴스의 자동 복구 기능을 구성할 수 있습니다. + [AWS OpsWorks: Using Auto Healing to Replace Failed Instances(AWS OpsWorks: 자동 복구를 사용하여 실패한 인스턴스 대체)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html) + 자동 크기 조정 또는 자동 복구를 사용할 수 없거나 자동 복구가 실패할 경우 AWS Step Functions 및 AWS Lambda를 사용하여 자동 복구를 구현합니다. 자동 크기 조정을 사용할 수 없고, 자동 복구를 사용할 수 없거나 자동 복구가 실패하는 경우 AWS Step Functions 및 AWS Lambda를 사용하여 복구를 자동화할 수 있습니다. + [AWS Step Functions란 무엇입니까?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) + [AWS Lambda란 무엇입니까?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) + Amazon EventBridge를 사용하면 CloudWatch 경보 또는 다른 AWS 서비스의 상태 변경과 같은 이벤트를 모니터링하고 필터링할 수 있습니다. 그런 다음 이벤트 정보를 기반으로 AWS Lambda(또는 다른 대상)를 트리거하여 워크로드에 대한 사용자 지정 수정 로직을 실행할 수 있습니다. + [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) ## 리소스 **관련 문서:** + [APN 파트너: 내결함성 자동화를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=automation) + [AWS Marketplace: 내결함성에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance) + [AWS OpsWorks: Using Auto Healing to Replace Failed Instances(AWS OpsWorks: 자동 복구를 사용하여 실패한 인스턴스 대체)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html) + [Amazon EC2 자동 복구](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) + [Amazon Elastic Block Store(Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) + [Amazon Elastic File System(Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) + [AWS Auto Scaling 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) + [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [AWS Lambda란 무엇입니까?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) + [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) + [AWS Step Functions란 무엇입니까?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) + [Amazon FSx for Lustre란 무엇입니까?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) + [Amazon FSx for Windows File Server란 무엇입니까?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) **관련 동영상:** + [AWS의 정적 안정성: AWS re:Invent 2019: Introducing The Amazon Builders’ Library(Amazon Builders’ Library 소개)(DOP328)](https://youtu.be/sKRdemSirDM?t=704) **관련 예시:** + [Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability(Well-Architected 실습: 레벨 300: 상태 확인 구현 및 종속성 관리를 통한 안정성 개선)](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html) # REL11-BP04 복구 중 컨트롤 플레인이 아닌 데이터 영역 사용 제어 영역은 리소스를 구성하는 데 사용되며, 데이터 영역은 서비스 제공에 사용됩니다. 일반적으로 데이터 영역은 제어 영역보다 가용성 설계 목표가 더 높으며, 일반적으로 덜 복잡합니다. 복원력에 영향을 미칠 가능성이 있는 이벤트에 대해 복구 또는 완화 대응을 구현할 때 제어 영역 작업을 사용하면 아키텍처의 전반적인 복원력이 감소될 수 있습니다. 예를 들어, Amazon Route 53 데이터 영역을 사용하면 상태 확인을 기반으로 DNS 쿼리를 안정적으로 라우팅할 수 있지만, Route 53 라우팅 정책을 업데이트할 때 컨트롤 플레인을 사용하므로 복구에 사용할 수 없습니다. Route 53 데이터 영역은 DNS 쿼리에 응답하고 상태 확인을 수행 및 평가합니다. Route 53 데이터 영역은 전역에 배포되며 [100% 가용성 서비스 수준에 관한 계약(SLA)을 위해 설계됩니다.](https://aws.amazon.com/route53/sla/) Route 53 리소스를 생성, 업데이트, 삭제하는 데 사용하는 Route 53 관리 API 및 콘솔은 DNS를 관리할 때 필요한 강력한 일관성과 내구성을 우선시하도록 설계된 컨트롤 플레인에서 실행됩니다. 이를 위해 컨트롤 플레인은 하나의 리전(US East (N. Virginia))에 위치합니다. 두 시스템 모두 안정성이 높게 구축되었지만 컨트롤 플레인은 SLA에 포함되지 않습니다. 데이터 영역의 복원력 높은 설계가 컨트롤 플레인과 달리 가용성을 유지하는 상황이 드물게 있을 수 있습니다. 재해 복구 및 장애 조치 메커니즘에는 데이터 영역 기능을 사용하여 가능한 한 최고 수준의 신뢰성을 제공하십시오. 데이터 영역, 컨트롤 플레인, 고가용성 목표를 충족하기 위해 AWS에서 서비스를 구축하는 방법에 관한 자세한 내용은 [가용 영역을 사용한 정적 안정성](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) 문서와 [Amazon Builders' Library를 참조하십시오.](https://aws.amazon.com/builders-library/) **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 ## 구현 가이드 + 재해 복구에 Amazon Route 53를 사용할 때 컨트롤 플레인이 아닌 데이터 영역을 사용합니다. Route 53 Application Recovery Controller를 사용하면 준비 상태 확인 및 라우팅 제어를 통해 장애 조치를 관리하고 조정할 수 있습니다. 이러한 기능은 애플리케이션의 장애 복구 성능을 지속적으로 모니터링하며, 이를 통해 여러 AWS 리전, 가용 영역 및 온프레미스에서 애플리케이션 복구를 제어할 수 있습니다. + [What is Route 53 Application Recovery Controller?(Amazon Route 53 Application Recovery Controller란 무엇입니까?)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) + [Creating Disaster Recovery Mechanisms Using Amazon Route 53(Amazon Route 53를 사용하여 재해 복구 메커니즘 생성)](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) + [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack(Amazon Route 53 Application Recovery Controller를 사용하여 복원력이 높은 애플리케이션 구축, 파트 1: 단일 리전 스택)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/) + [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 2: Multi-Region stack(Amazon Route 53 Application Recovery Controller를 사용하여 복원력이 높은 애플리케이션 구축, 파트 2: 다중 리전 스택)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/) + 데이터 영역을 사용할 작업과 컨트롤 플레인을 사용할 작업을 파악합니다. + [Amazon Builders' Library: Avoiding overload in distributed systems by putting the smaller service in control(소규모 서비스 제어를 통한 분산 시스템 오버로드 방지)](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/) + [Amazon DynamoDB API(컨트롤 플레인 및 데이터 영역)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html) + [AWS Lambda 실행](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (컨트롤 플레인 및 데이터 영역으로 분할) + [AWS Lambda 실행](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (컨트롤 플레인 및 데이터 영역으로 분할) ## 리소스 **관련 문서:** + [APN 파트너: 내결함성 자동화를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=automation) + [AWS Marketplace: 내결함성에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance) + [Amazon Builders' Library: Avoiding overload in distributed systems by putting the smaller service in control(소규모 서비스 제어를 통한 분산 시스템 오버로드 방지)](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/) + [Amazon DynamoDB API(컨트롤 플레인 및 데이터 영역)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html) + [AWS Lambda 실행](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (컨트롤 플레인 및 데이터 영역으로 분할) + [AWS Elemental MediaStore Data Plane(AWS Elemental MediaStore 데이터 영역)](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html) + [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack(Amazon Route 53 Application Recovery Controller를 사용하여 복원력이 높은 애플리케이션 구축, 파트 1: 단일 리전 스택)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/) + [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 2: Multi-Region stack(Amazon Route 53 Application Recovery Controller를 사용하여 복원력이 높은 애플리케이션 구축, 파트 2: 다중 리전 스택)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/) + [Creating Disaster Recovery Mechanisms Using Amazon Route 53(Amazon Route 53를 사용하여 재해 복구 메커니즘 생성)](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) + [What is Route 53 Application Recovery Controller?(Amazon Route 53 Application Recovery Controller란 무엇입니까?)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) **관련 예시:** + [Amazon Route 53 Application Recovery Controller 소개](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/) # REL11-BP05 정적 안정성을 사용하여 바이모달 동작 방지 바이모달 동작은 워크로드가 정상 모드와 장애 모드에서 다른 동작을 보이는 것을 말합니다. 예를 들어 가용 영역에 장애가 발생할 경우 새 인스턴스를 시작하는 방법을 사용할 수 있습니다. 그러나 이 방법 대신 정적으로 안정적이며 한 모드에서만 작동하는 워크로드를 구축해야 합니다. 한 AZ가 제거된 경우 제거된 영역의 워크로드 로드를 처리하기에 충분한 인스턴스를 각 가용 영역에 프로비저닝한 다음 Elastic Load Balancing 또는 Amazon Route 53 상태 확인을 사용하여 손상된 인스턴스에서 로드를 이동합니다. 컴퓨팅 배포(예: EC2 인스턴스 또는 컨테이너)에서 정적 안정성은 최고의 안정성을 제공합니다. 정적 안정성은 비용 문제와 비교하여 검토되어야 합니다. 컴퓨팅 파워를 적게 프로비저닝하고 장애 발생 시 새 인스턴스를 시작하는 방법이 비용은 더 저렴합니다. 그러나 대규모 장애(예: 가용 영역 장애)의 경우 이 접근 방식은 장애가 발생하기 전에 대비하는 것이 아니라 장애가 발생할 때 대응하는 방법에 의존하기 때문에 효율성이 떨어집니다. 따라서 워크로드의 안정성 요구 사항과 비용 요구 사항을 비교해야 합니다. 사용하는 가용 영역이 많을수록 정적 안정성을 유지하는 데 필요한 추가 컴퓨팅 용량은 줄어듭니다. ![\[가용 영역에 걸친 EC2 인스턴스의 정적 안정성을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/static-stability.png) 트래픽이 전환된 후에는 AWS Auto Scaling을 사용하여 장애가 발생한 영역의 인스턴스를 비동기식으로 교체하고 정상 영역에서 인스턴스를 시작합니다. 바이모달 동작의 또 다른 예는 시스템이 전체 시스템의 구성 상태를 새로 고치려고 시도할 수 있는 네트워크 시간 제한입니다. 그러면 다른 구성 요소에 예기치 않은 로드가 더해져 해당 구성 요소에 장애가 발생하고 또 다른 예기치 않은 결과가 야기될 수 있습니다. 이 부정적인 피드백 루프는 워크로드의 가용성에 영향을 미칩니다. 대신 정적으로 안정적이며 한 모드에서만 작동하는 시스템을 구축해야 합니다. 일정한 작업을 수행하고 항상 고정된 케이던스에서 구성 상태를 새로 고치는 것이 정적으로 안정된 설계의 하나일 수 있습니다. 호출이 실패하면 워크로드는 이전에 캐시된 값을 사용하고 경보를 트리거합니다. 바이모달 동작의 또 다른 예로 장애 발생 시 클라이언트에서 워크로드 캐시를 우회하는 것을 허용하는 동작이 있습니다. 이는 클라이언트 요구 사항을 수용한 솔루션처럼 보이지만 워크로드의 수요가 크게 변경되고 장애를 초래할 가능성이 높으므로 허용해서는 안 됩니다. **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 ## 구현 가이드 + 정적 안정성을 사용하여 바이모달 동작을 방지합니다. 바이모달 동작은 워크로드가 정상 모드와 장애 모드에서 다른 동작을 보이는 것을 말합니다. 예를 들어 가용 영역에 장애가 발생할 경우 새 인스턴스를 시작하는 방법을 사용할 수 있습니다. + [Minimizing Dependencies in a Disaster Recovery Plan(재해 복구 계획의 종속성 최소화)](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/) + [Amazon Builders' Library: 가용 영역을 사용한 정적 안정성](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) + [AWS의 정적 안정성: AWS re:Invent 2019: Amazon Builders’ Library 소개(DOP328)](https://youtu.be/sKRdemSirDM?t=704) + 그러나 이 방법 대신 정적으로 안정적이고 한 모드에서만 작동하는 시스템을 구축해야 합니다. 한 가용 영역이 제거된 경우 제거된 영역의 워크로드 로드를 처리하기에 충분한 인스턴스를 각 영역에 프로비저닝한 다음 Elastic Load Balancing 또는 Amazon Route 53 상태 확인을 사용하여 손상된 인스턴스에서 로드를 이동합니다. + 바이모달 동작의 또 다른 예로 장애 발생 시 클라이언트에서 워크로드 캐시를 우회하는 것을 허용하는 동작이 있습니다. 이는 클라이언트 요구 사항을 수용하는 솔루션처럼 보이지만 워크로드의 수요가 크게 변경되고 장애를 초래할 가능성이 높으므로 허용해서는 안 됩니다. ## 리소스 **관련 문서:** + [Minimizing Dependencies in a Disaster Recovery Plan(재해 복구 계획의 종속성 최소화)](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/) + [Amazon Builders' Library: 가용 영역을 사용한 정적 안정성](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) **관련 동영상:** + [AWS의 정적 안정성: AWS re:Invent 2019: Amazon Builders’ Library 소개(DOP328)](https://youtu.be/sKRdemSirDM?t=704) # REL11-BP06 이벤트가 가용성에 영향을 미치는 경우 알림 전송 중대한 이벤트가 감지되면 이벤트로 인해 야기된 문제가 자동으로 해결된 경우에도 알림이 전송됩니다. 자동 복구를 사용하면 워크로드의 안정성을 유지할 수 있습니다. 그러나 자동 복구로 인해 해결해야 할 근본적인 문제가 가려질 수도 있습니다. 적절한 모니터링 및 이벤트를 구현하면 자동 복구로 해결된 문제를 포함한 문제의 패턴을 감지하여 근본 원인 문제를 해결할 수 있습니다. 장애 발생을 기준으로 Amazon CloudWatch Alarms를 트리거할 수 있으며 자동화된 복구 작업의 실행을 기준으로 트리거할 수도 있습니다. 이메일을 보내거나 Amazon SNS 통합을 사용하여 서드파티 인시던트 추적 시스템에 인시던트를 기록하도록 CloudWatch Alarms를 구성할 수 있습니다. **일반적인 안티 패턴:** + 누구도 조치를 취하지 않는 경보 전송 + 자동 복구 자동화를 수행하지만 복구가 필요한 것을 알리지 않음. **이 모범 사례 수립의 이점:** 복구 이벤트에 대한 알림이 전송되면 자주 발생하는 문제가 무시되지 않습니다. **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 ## 구현 가이드 + 비즈니스 핵심 성과 지표(KPI)가 낮은 임계값을 초과할 때 이러한 지표에 대한 경보를 전송합니다. 비즈니스 KPI에 대해 낮은 임계값 경보를 설정하면 워크로드를 사용할 수 없거나 작동하지 않는 시기를 파악하는 데 도움이 됩니다. + [정적 임계값을 기반으로 CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) + 복구 자동화를 호출하는 이벤트에 대한 경보 SNS API를 직접 호출하여 생성한 자동화를 통해 알림을 보낼 수 있습니다. + [Amazon Simple Notification Service란 무엇입니까?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) ## 리소스 **관련 문서:** + [정적 임계값을 기반으로 CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) + [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [Amazon Simple Notification Service란 무엇입니까?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)