# REL 12 안정성은 어떻게 테스트합니까?
프로덕션 환경의 스트레스에 대한 복원력을 가지도록 워크로드를 설계한 후 설계대로 작동하고 예상한 복원력을 제공하는지 확인할 수 있는 유일한 방법은 테스트입니다.
**Topics**
+ [REL12-BP01 플레이북을 사용하여 장애 조사](rel_testing_resiliency_playbook_resiliency.md)
+ [REL12-BP02 인시던트 사후 분석 수행](rel_testing_resiliency_rca_resiliency.md)
+ [REL12-BP03 기능 요구 사항 테스트](rel_testing_resiliency_test_functional.md)
+ [REL12-BP04 확장 및 성능 요구 사항 테스트](rel_testing_resiliency_test_non_functional.md)
+ [REL12-BP05 카오스 엔지니어링을 이용한 복원력 테스트](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP06 정기적으로 게임 데이 진행](rel_testing_resiliency_game_days_resiliency.md)
# REL12-BP01 플레이북을 사용하여 장애 조사
잘 알려지지 않은 장애 시나리오에 일관되고 신속하게 대응할 수 있도록 플레이북에 조사 프로세스를 문서화합니다. 플레이북은 장애 시나리오에 영향을 미치는 요인을 식별하기 위해 수행되는 미리 정의된 단계입니다. 문제가 확인되거나 에스컬레이션될 때까지 각 프로세스 단계의 결과를 사용하여 다음에 수행할 단계를 결정합니다.
플레이북은 사후 대응적 조치를 효과적으로 수행하기 위해 반드시 수행해야 하는 사전 예방적 계획입니다. 플레이북에 포함되지 않은 장애 시나리오가 프로덕션 환경에서 발생할 경우 이 문제를 먼저 해결합니다(화재 진압). 그런 다음 돌아가서 문제를 해결하기 위해 취한 단계를 살펴보고 이를 사용하여 플레이북에 새 항목을 추가합니다.
플레이북은 특정 인시던트에 대응하여 사용되며 런북은 특정 결과를 달성하기 위해 사용됩니다. 런북은 일상적인 활동에 대해 사용되고, 플레이북은 일상적이지 않은 이벤트에 대응하는 데 사용되는 경우가 많습니다.
**일반적인 안티 패턴:**
+ 문제를 진단하거나 인시던트에 대응하는 프로세스를 모른 상태에서 워크로드 배포를 계획합니다.
+ 이벤트를 조사할 때 로그 및 지표를 수집할 시스템에 대한 무계획적 결정
+ 데이터를 검색할 수 있을 만큼 오래 지표 및 이벤트를 유지하지 않음
**이 모범 사례 수립의 이점:** 플레이북을 캡처하면 프로세스를 일관되게 따를 수 있습니다. 플레이북을 코드화하면 수작업으로 인한 오류 발생을 최소화할 수 있습니다. 플레이북을 자동화하면 팀원의 개입 요구 사항을 없애거나 개입을 시작할 때 추가 정보를 제공함으로써 이벤트에 대응하는 시간을 단축할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 플레이북을 사용하여 문제를 파악합니다. 플레이북은 문제 조사를 위한 문서화된 프로세스입니다. 플레이북에 프로세스를 문서화하면 장애 발생 시나리오에 일관되고 빠르게 대응할 수 있습니다. 플레이북은 적절한 기술을 보유한 팀원이 해당하는 정보를 수집하고, 장애의 잠재적 출처를 확인하고, 결함 위치를 구분하고, 발생 요인을 확인(인시던트 사후 분석 수행)하는 데 필요한 정보와 지침을 포함해야 합니다.
+ 코드로 플레이북을 구현합니다. 플레이북을 스크립트로 작성하여 작업을 코드로 수행하면 일관성을 유지하고 수동 프로세스에서 발생하는 오류를 최소화할 수 있습니다. 플레이북은 문제의 발생 요인을 식별하는 데 필요할 수 있는 다양한 단계를 나타내는 여러 스크립트로 구성할 수 있습니다. 플레이북 활동의 일부분으로 런북 활동을 트리거하거나 수행할 수도 있고, 확인된 이벤트 대응 과정에서 플레이북 실행 여부를 묻는 메시지를 표시할 수도 있습니다.
+ [AWS Systems Manager를 사용하여 운영 플레이북 자동화](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Lambda란 무엇입니까?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## 리소스
**관련 문서:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [AWS Systems Manager를 사용하여 운영 플레이북 자동화](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Canary 사용(Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [AWS Lambda란 무엇입니까?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
**관련 예시:**
+ [플레이북 및 런북으로 운영 자동화](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL12-BP02 인시던트 사후 분석 수행
고객에게 영향을 주는 이벤트를 검토하고 발생 요인과 예방 조치 항목을 식별합니다. 이 정보를 사용하여 재발을 제한하거나 방지하는 완화 기능을 개발합니다. 신속하고 효과적인 대응을 위한 절차를 개발합니다. 목표 대상에 맞게 적절히 발생 요인과 수정 조치를 전달합니다. 필요한 경우 다른 관계자들에게 이러한 원인을 전달하는 방법을 마련합니다.
기존 테스트에서 문제가 발견되지 않은 이유를 평가합니다. 테스트가 아직 없는 경우 이 사례에 대한 테스트를 추가합니다.
**일반적인 안티 패턴:**
+ 발생 요인을 찾지만, 다른 잠재적 문제와 해결 방법을 계속 자세히 살펴보지는 않음
+ 인적 오류 원인만 식별하며, 인적 오류를 예방할 수 있는 교육이나 자동화는 제공하지 않음
**이 모범 사례 정립의 이점:** 인시던트 사후 분석을 수행하고 결과를 공유하면 다른 워크로드에서 동일한 발생 요인이 나타날 경우 위험을 완화할 수 있으며 인시던트가 발생하기 전에 해결하거나 자동 복구를 구현할 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 인시던트 사후 분석을 위한 표준을 수립합니다. 우수한 인시던트 사후 분석은 시스템의 다른 위치에서 사용되는 아키텍처 패턴이 있는 문제에 대해 공통 솔루션을 제안할 수 있는 기회를 제공합니다.
+ 발생 요인을 솔직하게 밝히면서도 책임을 따지지 않도록 합니다.
+ 문제를 문서화하지 않으면 문제를 시정할 수 없습니다.
+ 인시던트 사후 분석에서 책임을 따지지 않으면서 제안된 시정 조치를 공정하게 평가하도록 하고 애플리케이션 팀의 솔직한 자체 평가와 협업을 유도합니다.
+ 발생 요인을 확인하는 프로세스를 사용합니다. 재발을 제한하거나 방지하기 위한 완화책을 개발하고 빠르고 효과적인 대응을 위한 절차를 개발할 수 있도록 이벤트의 발생 요인을 식별하고 문서화하는 프로세스를 마련합니다. 목표 대상에 맞게 적절히 발생 요인을 알립니다.
+ [로그 분석이란 무엇일까요?](https://aws.amazon.com/log-analytics/)
## 리소스
**관련 문서:**
+ [로그 분석이란 무엇일까요?](https://aws.amazon.com/log-analytics/)
+ [오류 수정(COE)을 개발해야 하는 이유](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
# REL12-BP03 기능 요구 사항 테스트
단위 테스트와 필수 기능을 검증하는 통합 테스트 등의 기법을 사용합니다.
이러한 테스트는 구축 및 배포 작업의 일부로 자동으로 실행될 때 최상의 결과를 제공합니다. 예를 들어 개발자가 AWS CodePipeline을 사용하여 소스 리포지토리에 변경 사항을 커밋하면 CodePipeline이 변경 사항을 자동으로 감지합니다. 이러한 변경 사항이 구축되고 테스트가 실행됩니다. 테스트가 완료되면 테스트를 위해 구축된 코드가 스테이징 서버에 배포됩니다. CodePipeline은 스테이징 서버에서 통합 또는 로드 테스트와 같은 더 많은 테스트를 실행합니다. 이러한 테스트가 성공적으로 완료되면 CodePipeline은 테스트되고 승인된 코드를 프로덕션 인스턴스에 배포합니다.
또한 가장 중요한 테스트 중 하나는 고객 행동을 실행하고 시뮬레이션할 수 있는 가상 트랜잭션 테스트( *Canary 테스트라고도 하지만*카나리 배포와는 다름)입니다. 다양한 원격 위치에서 워크로드 엔드포인트에 대해 이러한 테스트를 지속적으로 실행합니다. Amazon CloudWatch Synthetics를 사용하면 엔드포인트 및 API 모니터링을 위한 [Canary를 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 기능 요구 사항을 테스트합니다. 여기에는 단위 테스트와 필수 기능을 검증하는 통합 테스트가 포함됩니다.
+ [CodePipeline를 AWS CodeBuild와 함께 사용하여 코드 테스트 및 빌드 실행](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild(AWS CodePipeline, AWS CodeBuild를 사용한 단위 및 맞춤형 통합 테스트 관련 지원 추가)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [Continuous Delivery and Continuous Integration(지속적 전달 및 지속적 통합)](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Canary 사용(Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [소프트웨어 테스트 자동화](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## 리소스
**관련 문서:**
+ [APN 파트너: 지속적 통합 파이프라인 구현을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Continuous+Integration)
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild(AWS CodePipeline, AWS CodeBuild를 사용한 단위 및 맞춤형 통합 테스트 관련 지원 추가)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [AWS Marketplace: 지속적인 통합에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Continuous+integration)
+ [Continuous Delivery and Continuous Integration(지속적 전달 및 지속적 통합)](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [소프트웨어 테스트 자동화](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [CodePipeline를 AWS CodeBuild와 함께 사용하여 코드 테스트 및 빌드 실행](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [Canary 사용(Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
# REL12-BP04 확장 및 성능 요구 사항 테스트
워크로드가 조정 및 성능 요구 사항을 충족하는지 확인하기 위한 로드 테스트 등의 기법을 사용합니다.
클라우드에서는 워크로드에 대한 프로덕션 규모의 테스트 환경을 필요할 때 생성할 수 있습니다. 축소된 인프라에서 이러한 테스트를 실행하는 경우 관찰된 결과를 프로덕션 환경에서 발생할 것으로 생각되는 범위까지 확장해야 합니다. 실제 사용자에게 영향을 주지 않도록 주의하고 실제 사용자 데이터 및 손상된 사용 통계 또는 프로덕션 보고서와 충돌하지 않도록 테스트 데이터에 태그를 지정하면 프로덕션에서도 로드 및 성능 테스트를 수행할 수 있습니다.
테스트를 통해 기본 리소스, 조정 설정, 서비스 할당량 및 복원력 설계가 로드 조건에서 예상대로 작동하는지 확인합니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 크기 조정 및 성능 요구 사항을 테스트합니다. 로드 테스트를 수행하여 워크로드가 크기 조정 및 성능 요구 사항을 충족하는지 확인합니다.
+ [AWS에서의 분산 로드 테스트: 수천 명의 연결된 사용자 시뮬레이션](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
+ 프로덕션 환경과 동일한 환경에 애플리케이션을 배포하고 로드 테스트를 수행합니다.
+ 코드형 인프라를 사용하여 프로덕션 환경과 최대한 유사한 환경을 구축합니다.
## 리소스
**관련 문서:**
+ [AWS에서의 분산 로드 테스트: 수천 명의 연결된 사용자 시뮬레이션](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
# REL12-BP05 카오스 엔지니어링을 이용한 복원력 테스트
시스템이 불리한 조건에서 어떻게 반응하는지 파악하려면 프로덕션 내 환경 또는 프로덕션과 최대한 가까운 환경에서 카오스 실험을 정기적으로 실행합니다.
** 원하는 결과: **
워크로드의 복원력은 이벤트 중 워크로드의 알려진 예상 동작을 확인하는 복원력 테스트 이외에 장애 주입 실험 또는 예기치 않은 부하 발생의 형태로 카오스 엔지니어링을 적용하여 정기적으로 확인합니다. 카오스 엔지니어링과 복원력 테스트를 결합하여 구성 요소 장애 시 워크로드가 중단되지 않고, 예기치 않은 중단이 발생한 경우에도 영향을 최소화하거나 아무런 영향 없이 복구할 수 있다는 확신을 얻을 수 있습니다.
** 일반적인 안티 패턴: **
+ 복원력을 뛰어나게 설계했으나 장애 발생 시 워크로드가 전체적으로 작동하는 방식을 확인하지 않습니다.
+ 실제 조건 및 예상되는 부하에서 절대 실험하지 않습니다.
+ 실험을 코드로 처리하지 않고 개발 주기 전체에서 유지 관리하지 않습니다.
+ 카오스 실험을 CI/CD 파이프라인의 일부로 또한 배포 범위 외부에서도 실행하지 않습니다.
+ 어떤 결함을 실험할지 결정할 때 과거의 인시던트 후 분석 사용에 소홀합니다.
** 이 모범 사례 확립의 이점:** 워크로드의 복원력을 확인하기 위해 장애를 도입하면 탄력적인 설계의 복구 절차가 실제 장애 발생 시에도 잘 작동할 것으로 확신할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 보통
## 구현 가이드
카오스 엔지니어링은 서비스 공급자, 인프라, 워크로드 및 구성 요소 수준에서 고객에게 미치는 영향을 최소화하거나 아무런 영향을 미치지 않으면서 제어되는 방식으로 실제 중단(시뮬레이션)을 지속적으로 도입할 수 있는 역량을 팀에 제공합니다. 이렇게 하면 팀이 장애로부터 배우고 워크로드의 복원력을 관찰, 측정 및 개선하고 이벤트 발생 시 알림이 전달되고 팀이 알림을 받는지 확인할 수 있습니다.
지속적으로 수행하면 카오스 엔지니어링은 해결하지 않고 두면 가용성과 운영에 부정적인 영향을 미칠 수 있는 결함을 강조해서 보여줄 수 있습니다.
**참고**
카오스 엔지니어링은 프로덕션 환경의 급변하는 조건을 견딜 수 있는 시스템의 역량을 확신하기 위해 시스템에 대해 수행하는 실험 분야입니다. [Principles of Chaos Engineering(카오스 엔지니어링의 원칙)](https://principlesofchaos.org/)
시스템이 중단을 견딜 수 있는 경우 카오스 엔지니어링은 자동화되어 회귀 테스트로 유지 관리해야 합니다. 이러한 방식으로 카오스 실험은 시스템 개발 수명 주기(SDLC) 및 CI/CD 파이프라인의 일부로 수행해야 합니다.
구성 요소 장애 발생 시 워크로드가 중단되지 않는지 확인하기 위해 실험의 일부로 실제 이벤트를 도입합니다. 예를 들어, Amazon EC2 인스턴스 손실 또는 기본 Amazon RDS 데이터베이스 인스턴스 장애 조치로 실험하고 워크로드가 영향을 받지 않는지(또는 최소한의 영향만 받는지) 확인합니다. 구성 요소 장애를 결합하여 가용 영역에서 중단으로 인해 발생할 수 있는 이벤트를 시뮬레이션합니다.
애플리케이션 수준 장애(예: 충돌)의 경우 메모리 및 CPU 소진 등과 같은 원인으로 시작할 수 있습니다.
간헐적 네트워크 중단으로 인한 외부 종속에 대한 [폴백 또는 장애 조치 메커니즘](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) 을 확인하려면 구성 요소가 몇 초에서 몇 시간까지 지속될 수 있는 지정된 기간에 서드파티 제공업체에 대한 액세스를 차단하여 해당 이벤트를 시뮬레이션해야 합니다.
그 외의 모드에서 성능이 저하되면 기능이 저하되고 응답 속도가 느려져서 서비스가 일시적으로 중단되는 경우가 많습니다. 이러한 성능 저하는 대개 중요 서비스의 지연 시간 증가 및 불안정한 네트워크 연결(패킷이 삭제됨)로 인해 발생합니다. 지연 시간, 삭제된 메시지 및 DNS 장애 등과 같은 네트워킹 효과를 비롯한 장애를 사용한 실험에는 이름 확인 불가, DNS 서비스에 연결 불가 또는 종속적 서비스에 연결 설정 불가가 포함될 수 있습니다.
**카오스 엔지니어링 도구:**
AWS Fault Injection Service(AWS FIS)은(는) CD 파이프라인의 일부로 또는 파이프라인 외부에서 사용할 수 있는 장애 주입 실험을 실행하는 데 사용되는 완전관리형 서비스입니다. AWS FIS은(는) 카오스 엔지니어링 게임 데이 중 사용하기 좋습니다. Amazon EC2, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service(Amazon EKS) 및 Amazon RDS을(를) 비롯한 여러 유형의 리소스 간에 동시 장애 발생을 지원합니다. 이러한 장애에는 리소스 종료, 강제 장애 조치, CPU 또는 메모리에 스트레스 유발, 제한, 지연 시간 및 패킷 손실이 포함됩니다. Amazon CloudWatch 경보와 통합되므로 테스트가 예상치 못한 영향을 미치는 경우 실험을 롤백하기 위해 중지 조건을 가드레일로 설정할 수 있습니다.
![\[워크로드에 장애 주입 실험을 실행할 수 있도록 AWS 리소스와 통합된 AWS Fault Injection Service을(를) 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/fault-injection-simulator.png)
장애 주입 실험을 위한 서드파티 옵션도 몇 가지 있습니다. 여기에는 오픈 소스 도구(예: [Chaos Toolkit](https://chaostoolkit.org/), [Chaos Mesh](https://chaos-mesh.org/)및 [Litmus Chaos](https://litmuschaos.io/))와 상용 옵션(예: Gremlin)이 포함됩니다. AWS에 삽입할 수 있는 장애 범위를 확장하기 위해 AWS FIS이(가) [Chaos Mesh 및 Litmus Chaos와 통합되어](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/)여러 도구 간에 장애 주입 워크플로를 조정할 수 있습니다. 예를 들어, 임의로 선택된 비율의 클러스터 노드를 AWS FIS 장애 작업을 사용하여 종료하는 동안 Chaos Mesh 또는 Litmus 결함을 사용하여 포드의 CPU에 대한 스트레스 테스트를 실행할 수 있습니다.
## 구현 단계
+ 실험에 사용할 장애를 결정합니다.
워크로드 설계의 복원력을 평가합니다. 해당 설계( [Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)의 모범 사례를 사용하여 생성됨)는 중요한 종속성, 과거 이벤트, 알려진 문제 및 규정 준수 요구 사항을 기반으로 위험을 설명합니다. 복원력을 유지하기 위한 설계 요소와 완화하도록 설계된 장애를 나열합니다. 이러한 목록 작성에 대한 자세한 내용은 이전 인시던트 재발을 방지하기 위한 프로세스 생성 방법을 안내하는 [운영 준비 검토 백서](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 를 참조하세요. 장애 모드 및 영향 분석(FMEA) 프로세스는 장애의 구성 요소 수준 및 장애가 워크로드에 미치는 영향을 분석하기 위한 프레임워크를 제공합니다. FMEA는 Adrian Cockcroft가 장애 모드 및 지속적인 복원력에서 [자세히 설명합니다](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5).
+ 각 장애에 우선순위를 할당합니다.
처음에는 높음, 보통 또는 낮음 등과 같이 대략적인 분류로 시작합니다. 우선순위를 평가하려면 장애 빈도와 장애가 전체 워크로드에 미치는 영향을 고려해야 합니다.
주어진 장애의 빈도를 고려할 때 확인 가능한 경우 이 워크로드에 대한 이전 데이터를 분석합니다. 확인할 수 없는 경우에는 유사한 환경에서 실행되는 다른 워크로드의 데이터를 사용합니다.
주어진 장애의 영향을 고려할 때 장애의 범위가 클수록 일반적으로 영향도 커집니다. 또한 워크로드 설계 및 용도도 고려합니다. 예를 들어, 소스 데이터 스토어에 액세스하는 기능은 데이터 변환 및 분석을 수행하는 워크로드에 중요합니다. 이러한 경우 액세스 장애와 제한된 액세스 및 지연 시간 삽입에 대한 실험의 우선순위를 지정할 수 있습니다.
인시던트 후 분석은 장애 모드의 빈도 및 영향을 파악하기 위한 좋은 데이터 출처입니다.
할당된 우선순위를 사용하여 어떤 장애를 먼저 실험할지, 새로운 장애 주입 실험을 개발할 순서를 결정합니다.
+ 수행하는 각 실험에 대해 카오스 애플리케이션 및 지속적인 복원력 플라이휠을 따릅니다.
![\[개선, 안정 상태, 가설, 실험 실행 및 확인 단계를 보여주는 카오스 엔지니어링 및 연속 복원력 플라이휠 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/chaos-engineering-flywheel.png)
+ 안정 상태를 정상 동작을 나타내는 워크로드의 측정 가능한 출력으로 정의합니다.
예상한 대로 안정적으로 작동하면 워크로드가 안정 상태를 보이는 것입니다. 따라서 안정 상태를 정의하기 전에 워크로드가 정상인지 확인합니다. 특정 비율의 장애는 허용 가능한 한도 내에서 발생할 수 있기 때문에 안정 상태라고 해서 장애 발생 시 워크로드에 미치는 영향이 반드시 없는 것은 아닙니다. 안정 상태는 실험 중 관찰하는 기준선으로, 다음 단계에서 정의하는 가설이 예상대로 나타나지 않는 경우 이상이 있음을 강조합니다.
예를 들어, 결제 시스템의 안정 상태를 성공률 99%, 왕복 시간 500ms의 300 TPS 처리로 정의할 수 있습니다.
+ 워크로드가 장애에 반응할 방법에 대한 가설을 작성합니다.
올바른 가설은 안정 상태 유지를 위해 장애 완화에 기대되는 작동 방식을 기반으로 합니다. 가설은 워크로드가 특정 완화를 수행하도록 설계되었기 때문에 특정 유형의 장애 발생 시 시스템 또는 워크로드가 계속해서 안정 상태를 유지할 것이라고 가정합니다. 특정 유형의 장애 및 완화가 가설에 명시되어 있어야 합니다.
가설에는 다음 템플릿을 사용할 수 있습니다(하지만 다르게 표현할 수도 있음).
**참고**
만약 *특정 장애* 가 발생하면 *워크로드 명칭* 워크로드가 *비즈니스 또는 기술 지표의 영향* 을 유지하기 위한 *완화 제어 조치를 설명합니다*.
예를 들면 다음과 같습니다.
+ Amazon EKS 노드 그룹 중 20%의 노드가 종료되면 트랜잭션 생성 API가 100ms에서 요청의 99%를 계속해서 제공합니다(안정 상태). Amazon EKS 노드는 5분 이내에 복구되고 포드는 실험 시작 후 8분 이내에 트래픽을 예약하고 처리합니다. 3분 이내에 알림이 전송됩니다.
+ 단일 Amazon EC2 인스턴스 장애가 발생하면 주문 시스템의Elastic Load Balancing 상태 확인 기능이 Elastic Load Balancing에 나머지 정상 인스턴스에만 요청을 보내도록 하고 동시에 Amazon EC2 Auto Scaling에서는 장애가 발생한 인스턴스를 교체하여 서버 측(5xx) 오류의 증가율을 0.01% 미만으로 유지합니다(안정 상태).
+ 1차 Amazon RDS 데이터베이스 인스턴스에서 장애가 발생하면 공급망 데이터 컬렉션 워크로드는 장애 조치를 취하고 대기Amazon RDS 데이터베이스 인스턴스에 연결하여 데이터베이스 읽기 또는 쓰기 오류를 1분 미만으로 유지합니다(안정 상태).
+ 장애를 도입하여 실험을 실행합니다.
실험은 기본적으로 장애 발생 시 안전해야 하며 워크로드에서 허용해야 합니다. 워크로드에서 장애가 발생할 것임을 아는 경우 실험을 실행하지 마세요. known-unknowns 또는 unknown-unknowns를 찾으려면 카오스 엔지니어링을 사용해야 합니다. *Known-unknowns* 는 알고 있지만 완전히 파악하지 못한 항목이며, *unknown-unknowns* 는 알지 못할 뿐만 아니라 완전히 파악하지 못한 항목입니다. 실패할 것을 알고 있는 워크로드에 대한 실험에서는 새로운 인사이트를 얻을 수 없습니다. 실험은 주의해서 계획해야 하고 영향 범위가 명확해야 하며 예기치 못한 변동 발생 시 적용할 수 있는 롤백 메커니즘을 제공해야 합니다. 실사에서 워크로드가 실험을 통과해야 한다고 나타나면 실험을 계속 진행합니다. 장애 주입을 위한 옵션은 여러 가지가 있습니다. AWS에서의 워크로드의 경우 [AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) 에서는 작업이라 부르는 미리 정의된 다양한 장애 시뮬레이션을 [해당 알림에 대한 작업이](https://docs.aws.amazon.com/fis/latest/userguide/actions.html). 또한 다음 문서를 사용하여 AWS FIS에서 실행하는 사용자 지정 작업을 정의할 수도 있습니다. [AWS Systems Manager 문서](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html).
스크립트에 워크로드의 현재 상태를 파악하는 기능이 없고, 스크립트가 로그를 내보낼 수 없고, 가능한 경우 롤백 메커니즘 및 중지 조건을 제공할 수 없는 경우에는 카오스 실험에 사용자 지정 스크립트를 사용하지 않는 것이 좋습니다.
카오스 엔지니어링을 지원하는 효율적인 프레임워크 또는 도구 세트는 실험의 현재 상태를 추적하고, 로그를 내보내고, 실험의 제어되는 실행을 지원하기 위한 롤백 메커니즘을 제공해야 합니다. 실험 시 예기치 못한 변동이 발생하는 경우 실험을 롤백하는 안전 메커니즘과 분명하게 정의된 범위가 있는 실험을 수행하도록 허용하는 AWS FIS 등과 같은 확립된 서비스로 시작합니다. AWS FIS을(를) 사용한 다양한 실험에 대해 알아보려면 [Resilient and Well-Architected Apps with Chaos Engineering lab(카오스 엔지니어링을 사용해 잘 설계된 복원력이 뛰어난 앱 실습)을 참조하세요](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US). 또한 [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) 은(는) 워크로드를 분석하여 AWS FIS에서 구현 및 실행하도록 선택할 수 있는 실험을 생성합니다.
**참고**
모든 실험에 대해 범위와 그 영향을 명확하게 이해해야 합니다. 프로덕션 환경에서 실행하기 전에 비프로덕션 환경에서 먼저 장애를 시뮬레이션하는 것이 좋습니다.
실험은 가능한 경우 제어 및 실험적 시스템 배포를 둘 다 실행하는 [카나리 배포](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) 를 사용하여 실제 로드를 받는 프로덕션 환경에서 실행해야 합니다. 프로덕션 환경에서 처음으로 실험하는 경우 잠재적인 영향을 완화하기 위해 사용량이 적은 시간에 실험을 실행하는 것이 좋습니다. 또한 실제 고객 트래픽 사용의 위험이 너무 큰 경우에는 프로덕션 인프라에서 제어 및 실험적 배포에 대해 가상 트래픽을 사용하여 실험을 실행할 수 있습니다. 프로덕션 환경을 사용할 수 없는 경우 가급적 프로덕션 환경과 유사한 프로덕션 전 환경에서 실험을 실행합니다.
실험이 허용 가능한 제한을 벗어나 프로덕션 트래픽 또는 다른 시스템에 영향을 미치지 않도록 가드레일을 설정하고 모니터링해야 합니다. 가드레일 지표에 대해 정의한 임곗값에 도달한 경우 실험을 중지하기 위한 중지 조건을 설정합니다. 중지 조건에는 워크로드의 안정 상태에 대한 지표와 장애를 도입하는 구성 요소에 대한 지표를 포함해야 합니다. 또한 [종합 모니터링](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (사용자 canary라고도 함)은 일반적으로 사용자 프록시로 포함해야 하는 한 가지 지표입니다. [AWS FIS에 대한 중지 조건](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html) 은 실험 템플릿의 일부로 지원되며 템플릿당 최대 5개의 중지 조건을 사용할 수 있습니다.
카오스 원칙 중 한 가지는 실험 범위 및 그 영향을 최소화하는 것입니다.
단기적인 부정적 영향 중 일부를 허용해야 하지만 실험의 여파를 최소화하고 제한하는 것은 카오스 엔지니어의 책임이자 의무입니다.
실험 범위 및 잠재적인 영향을 확인하기 위한 방법은 먼저 비프로덕션 환경에서 실험을 수행하여 실험 중 중지 조건의 임곗값이 예상대로 활성화되고 프로덕션 환경에서 직접 실험하지 않고 관찰을 통해 예외를 포착할 수 있는지 확인하는 것입니다.
장애 주입 실험을 실행할 때 책임 당사자 모두가 알림을 잘 받았는지 확인합니다. 운영 팀, 서비스 신뢰성 팀, 고객 지원 팀 등과 같은 적절한 팀과 소통하여 실험 실행 시점과 기대하는 결과에 대해 알립니다. 이러한 팀에 통신 도구를 제공하여 부정적인 영향을 확인한 경우 실험을 실행하는 팀에 알릴 수 있도록 합니다.
워크로드와 기본 시스템을 원래 정상 상태로 복원해야 합니다. 보통, 워크로드의 탄력적인 설계는 스스로 복구됩니다. 하지만 일부 장애 설계 또는 장애가 발생한 실험에서는 워크로드를 예기치 않은 장애 상태로 둘 수 있습니다. 따라서 실험을 마치면 이 점을 인식하고 워크로드 및 시스템을 복원해야 합니다. AWS FIS를 사용하면 작업 파라미터 내에서 롤백 구성을 설정할 수 있습니다(후속 작업이라고도 함). 후속 작업은 대상을 작업 실행 전의 상태로 되돌립니다. 자동 작업(예: AWS FIS 사용)이든 수동 작업이든 상관 없이 후속 작업은 장애 감지 및 처리 방법을 설명하는 플레이북의 일부여야 합니다.
+ 가설을 확인합니다.
[Principles of Chaos Engineering(카오스 엔지니어링의 원칙)](https://principlesofchaos.org/) 은 워크로드의 안정 상태를 확인하는 방법에 대한 다음 지침을 제공합니다.
시스템의 내부 특성보다는 시스템의 측정 가능한 결과에 중점을 둡니다. 단기간의 결과에 대한 측정값은 시스템의 안정 상태에 대한 프록시를 구성합니다. 전체 시스템의 처리량, 오류 발생률 및 지연 시간 백분위수는 모두 안정 상태 동작을 나타내는 관심 지표일 수 있습니다. 실험 중 체계적인 동작 패턴에 집중하여 카오스 엔지니어링은 시스템 작동 방식 확인이 아니라 시스템이 잘 작동하는지를 확인합니다.
이전 두 가지 예에서는 서버측(5xx) 오류 증가를 0.01% 미만으로, 데이터베이스 읽기 및 쓰기 오류를 1분 미만으로 지정한 안정 상태 지표를 포함합니다.
5xx 오류는 워크로드의 클라이언트가 직접 경험하는 장애 모드의 결과이기 때문에 좋은 지표입니다. 데이터베이스 오류 측정은 장애의 직접적인 결과이기 때문에 적절하긴 하지만 실패한 고객 요청 수 또는 고객에게 표시된 오류 수 등과 같은 클라이언트 영향 측정으로 보충해야 합니다. 또한 워크로드의 클라이언트가 직접 액세스할 수 있는 API 또는 URI에 종합 모니터(사용자 canary라고도 함)를 포함합니다.
+ 복원력을 위해 워크로드 설계를 개선합니다.
안정 상태가 유지되지 않는 경우 장애를 완화하기 위해 워크로드 설계를 어떻게 개선할 수 있는지 조사하여 [AWS Well-Architected 신뢰성 원칙](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)에 대한 모범 사례를 적용합니다. 추가 지침 및 리소스는 [AWS 빌더 라이브러리](https://aws.amazon.com/builders-library/)에서 찾을 수 있습니다. 이 라이브러리는 특히, [상태 확인 개선 방법](https://aws.amazon.com/builders-library/implementing-health-checks/) 또는 [애플리케이션 코드에서 백오프를 사용하여 재시도 채택 방법](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)에 대한 문서를 호스트합니다.
이러한 변경 사항을 구현한 후에는 실험을 다시 실행하여(카오스 엔지니어링 프라이휠에서 점선으로 표시됨) 변경 사항의 영향을 확인합니다. 확인 단계에서 가설이 참으로 입증되면 워크로드가 안정 상태이므로 주기가 계속됩니다.
+ 실험을 정기적으로 실행합니다.
카오스 실험은 주기이고 카오스 엔지니어링의 일부로 주기적으로 실행해야 합니다. 워크로드가 실험의 가설을 충족하면 CI/CD 파이프라인의 회귀 부분으로 계속해서 실행되도록 실험을 자동화해야 합니다. 이렇게 하는 방법을 알아보려면 [AWS CodePipeline을(를) 사용하여 AWS FIS 실험을 실행하는 방법](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/)에 관한 블로그를 참조하세요. 이 실습은 [CI/CD 파이프라인에서 반복 AWS FIS 실험](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html) 에 관한 내용으로, 직접 적용해 볼 수 있습니다.
장애 주입 실험은 게임 데이의 일부이기도 합니다( [REL12-BP06 정기적으로 게임 데이 진행](rel_testing_resiliency_game_days_resiliency.md)참조). 게임 데이에서는 장애나 이벤트를 시뮬레이션하여 시스템, 프로세스 및 팀 대응을 확인합니다. 게임 데이의 목적은 이례적인 이벤트 발생 시 팀이 수행해야 할 작업을 실제로 수행해보는 것입니다.
+ 실험 결과를 캡처하고 저장합니다.
장애 주입 실험의 결과는 캡처한 다음 지속해야 합니다. 나중에 실험 결과 및 추세를 분석할 수 있도록 필요한 데이터(예: 시간, 워크로드 및 조건)를 모두 포함합니다. 결과의 예에는 대시보드 스냅샷, 지표 데이터베이스의 CSV 덤프 또는 이벤트에 대해 손으로 작성한 기록, 실험에서 관찰한 내용 등이 있을 수 있습니다. [AWS FIS(으)로 기록한 실험은](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) 이러한 데이터 캡처의 일부일 수 있습니다.
## 리소스
**관련 모범 사례:**
+ [REL08-BP03 배포의 일부로 복원력 테스트 통합](rel_tracking_change_management_resiliency_testing.md)
+ [REL13-BP03 재해 복구 구현을 테스트하여 구현 확인](rel_planning_for_recovery_dr_tested.md)
**관련 문서:**
+ [AWS Fault Injection Service란 무엇인가요?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
+ [AWS Resilience Hub란 무엇인가요?](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
+ [Principles of Chaos Engineering(카오스 엔지니어링의 원칙)](https://principlesofchaos.org/)
+ [Chaos Engineering: Planning your first experiment(카오스 엔지니어링: 첫 번째 실험 계획)](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde)
+ [Resilience Engineering: Learning to Embrace Failure(복원력 엔지니어링: 실패를 수용하는 방법 학습)](https://queue.acm.org/detail.cfm?id=2371297)
+ [카오스 엔지니어링 스토리](https://github.com/ldomb/ChaosEngineeringPublicStories)
+ [분산 시스템의 폴백 방지](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/)
+ [카오스 실험을 위한 카나리 배포](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db)
**관련 동영상:**
+ [AWS re:Invent 2020: Testing resiliency using chaos engineering(카오스 엔지니어링을 사용하여 복원력 테스트)(ARC316)](https://www.youtube.com/watch?v=OlobVYPkxgg)
+ [AWS re:Invent 2019: Improving resiliency with chaos engineering(카오스 엔지니어링을 사용하여 복원력 개선)(DOP309-R1)](https://youtu.be/ztiPjey2rfY)
+ [AWS re:Invent 2019: Performing chaos engineering in a serverless world(서버리스 환경에서 카오스 엔지니어링 수행)(CMY301)](https://www.youtube.com/watch?v=vbyjpMeYitA)
**관련 예시:**
+ [Well-Architected lab: Level 300: Testing for Resiliency of Amazon EC2, Amazon RDS, and Amazon S3(Amazon EC2, Amazon RDS 및 Amazon S3의 복원력 테스트)](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
+ [Chaos Engineering on AWS lab(AWS에서 카오스 엔지니어링 실습)](https://chaos-engineering.workshop.aws/en/)
+ [Resilient and Well-Architected Apps with Chaos Engineering lab(카오스 엔지니어링을 사용해 잘 설계된 복원력이 뛰어난 앱 실습)을 참조하세요](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US)
+ [Serverless Chaos lab(서버리스 카오스 실습)](https://catalog.us-east-1.prod.workshops.aws/workshops/3015a19d-0e07-4493-9781-6c02a7626c65/en-US/serverless)
+ [Measure and Improve Your Application Resilience with AWS Resilience Hub lab(AWS Resilience Hub를 사용하여 애플리케이션 복원력 측정 및 개선 실습)](https://catalog.us-east-1.prod.workshops.aws/workshops/2a54eaaf-51ee-4373-a3da-2bf4e8bb6dd3/en-US/200-labs/1wordpressapplab)
** 관련 도구: **
+ [AWS Fault Injection Service](https://aws.amazon.com/fis/)
+ AWS Marketplace: [Gremlin Chaos Engineering Platform](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney)
+ [Chaos Toolkit](https://chaostoolkit.org/)
+ [Chaos Mesh](https://chaos-mesh.org/)
+ [Litmus](https://litmuschaos.io/)
# REL12-BP06 정기적으로 게임 데이 진행
실제 장애 시나리오에 영향을 받을 직원들과 함께 게임 데이를 정기적으로 수행하여 프로덕션에 최대한 근접한 장애 및 이벤트 대응 절차(프로덕션 환경의 장애 절차 포함)를 연습합니다. 게임 데이에서는 프로덕션 이벤트가 사용자에게 영향을 미치지 않도록 하는 조치가 시행됩니다.
게임 데이에서는 장애나 이벤트를 시뮬레이션하여 시스템, 프로세스 및 팀 대응을 테스트합니다. 게임 데이의 목적은 이례적인 이벤트 발생 시 팀이 수행해야 할 작업을 실제로 수행해보는 것입니다. 그러면 어느 분야에서 개선이 필요한지 파악하고, 조직이 이벤트에 대처하는 경험을 쌓도록 도울 수 있습니다. 팀이 대응 방법을 *체득할 수 있도록* 게임 데이를 정기적으로 진행해야 합니다.
복원력을 위한 설계가 마련되고 비 프로덕션 환경에서 이 설계를 테스트한 후에는 실전 연습을 통해 모든 구성 요소가 프로덕션에서 예상대로 작동하는지 확인합니다. 실전 연습, 특히 첫 번째 실전 연습에서는 엔지니어와 운영 팀이 모두 모여 실전 연습의 일정과 내용에 대한 정보를 숙지합니다. 런북이 준비되어 있습니다. 프로덕션 시스템에서 미리 정해진 방식으로 발생할 수 있는 장애 이벤트를 비롯한 시뮬레이션 이벤트가 실행되고 영향이 평가됩니다. 모든 시스템이 설계대로 작동할 경우 감지 및 자가 복구가 수행됩니다. 영향은 거의 없습니다. 그러나 부정적인 영향이 관찰되면 테스트가 롤백되고 워크로드 문제가 해결됩니다. 필요한 경우 런북을 사용하여 수동으로 문제를 해결합니다. 게임 데이는 프로덕션에서 수행되는 경우가 많으므로 고객의 가용성에 영향을 미치는 일이 없도록 모든 예방 조치를 취해야 합니다.
**일반적인 안티 패턴:**
+ 절차를 문서화하지만 결코 연습하지 않음
+ 테스트 연습에 비즈니스 의사 결정권자가 참여하지 않음
**이 모범 사례 수립의 이점:** 게임 데이를 정기적으로 실시하면 실제 인시던트가 발생할 때 모든 직원이 정책과 절차를 따르도록 하고 이러한 정책과 절차가 적절한지 검증할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 런북 및 플레이북을 정기적으로 실행하도록 게임 데이 수행 게임 데이에는 비즈니스 소유자, 개발 직원, 운영 직원 및 인시던트 대응 팀 등 프로덕션 이벤트에 관련된 모든 사람이 참여해야 합니다.
+ 로드 또는 성능 테스트를 실행한 다음 장애 주입을 실행합니다.
+ 런북에서 이상이 있는지 찾고 플레이북을 연습할 기회가 있는지 살펴봅니다.
+ 런북에서 벗어난 경우 해당 런북을 구체화하거나 동작을 수정합니다. 플레이북을 실행하는 경우, 사용되었어야 하는 런북을 식별하거나 새로운 런북을 만듭니다.
## 리소스
**관련 문서:**
+ [AWS 게임 데이란 무엇입니까?](https://aws.amazon.com/gameday/)
**관련 동영상:**
+ [AWS re:Invent 2019: Improving resiliency with chaos engineering(카오스 엔지니어링을 사용하여 복원력 개선)(DOP309-R1)](https://youtu.be/ztiPjey2rfY)
**관련 예시:**
+ [AWS Well-Architected 실습 - 복원력 테스트](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)