기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

지속적인 카오스 엔지니어링 실험 수명 주기

이전 단원에서 설명한 대로 다양한 방식으로 카오스 엔지니어링 실험을 구현할 수 있습니다. 모든 경우에 의미 있는 카오스 실험을 구축하는 핵심은 애플리케이션, 과거 인시던트 및 구현된 문제 해결을 이해하고 복원력 또는 보안과 같은 조사 영역을 명확하게 이해하는 것입니다. 애플리케이션에 대한 지식은 애플리케이션의 잠재적 약점에 대한 가설을 수립하고 장애가 주입될 때 애플리케이션의 탐지, 해결 및 복구 방법을 이해하는 데 도움이 됩니다.

카오스 실험 수명 주기에는 다음 단계가 포함됩니다.

이러한 단계는 다이어그램에 설명되어 있으며 다음 단원에서 설명합니다.

목표 정의 및 기대치 설정

각 실험 전에 목표와 기대치가 구체적이고 측정 가능하며 달성 가능하고 관련성이 있고 시간 제한이 있는지 확인합니다. 다음을 명확하게 정의합니다.

대상 애플리케이션 선택

카오스 엔지니어링은 강력한 기술이지만 가치를 극대화하려면 신중한 우선순위 지정이 필요합니다. 카오스 엔지니어링 작업에 집중할 위치를 결정할 때는 먼저 비즈니스의 중요한 서비스를 고려하세요. 팀에게 소프트웨어 개발 수명 주기 단계를 반복하고 먼저 테스트 환경에 결함을 주입하도록 요청합니다. 비즈니스 크리티컬 애플리케이션은 수익, 고객 경험 및 핵심 운영과 직접적인 관련이 있습니다. 이러한 서비스에 대한 카오스 실험을 통해 조직과 잠재적으로 전체 시장에 심각한 영향을 미칠 수 있는 취약성이 해결되지 않는 경우 발견할 수 있습니다. 예를 들어 먼저 거래 시스템 또는 주문 시스템과 같은 고객 대면 서비스에 집중합니다. 이러한 중앙 서비스의 우선순위를 지정하면 시간 투자당 가장 많은 보호를 제공합니다.

중요한 서비스 후에는 데이터베이스, 메시지 대기열, 네트워크 및 공유 서비스 APIs와 같은 기본 구성 요소를 살펴봅니다. 이러한 구성 요소는 조직 전체에서 공유 구성 요소 또는 서비스로 사용될 수 있으므로 장애가 발생하면 광범위한 문제가 발생합니다. 인프라 서비스의 복원력을 확인하면 인프라 서비스 위에 종속 애플리케이션이 충돌하지 않을 것이라는 확신을 얻을 수 있습니다. 예를 들어 Kafka 클러스터를 분해하는 카오스 엔지니어링 실험은 다운스트림 애플리케이션의 내결함성에 대해 많은 것을 드러냅니다. 시스템 인프라는 고객을 직접 대면하지는 않지만 주요 카오스 엔지니어링 대상입니다.

사람, 프로세스, 시설 정보 및 서드 파티 종속성의 정신적 격차를 매핑하는 것을 잊지 마세요. 조직의 내충격성 목표에 맞지 않으면 심각한 중단을 일으킬 수 있기 때문입니다. 카오스 엔지니어링의 ROI를 측정하는 방법에 대한 자세한 내용은 전략적 필요성으로 카오스 엔지니어링에 투자 전략 문서에서 카오스 엔지니어링의 ROI 정량화를 참조하세요.

다음 다이어그램은 다양한 서비스 계층에서 카오스 실험을 실행하기 위한 투자 수익률을 보여줍니다.

멘탈 맵 정렬(애플리케이션 검색)

임시 실험 또는 게임 데이를 실행할 때 애플리케이션의 세부 정보를 매핑하는 데 초점을 맞춘 화이트보딩 세션을 개최하여 애플리케이션 검색 프로세스를 시작합니다. (카오스 파이프라인에서 실험을 실행하는 경우 대상 애플리케이션을 정의하여 멘탈 맵을 이미 정렬했을 것입니다.) 멘탈 격차를 이해하는 좋은 방법은 하급 팀원이 먼저 애플리케이션의 다이어그램을 그린 다음 더 많은 고위 직원에게 다이어그램에 점진적으로 추가하도록 요청하는 것입니다. 이렇게 하면 경험 수준 전반의 이해 격차를 발견할 수 있습니다.

다이어그램은 애플리케이션의 직접 업스트림 및 다운스트림 종속성과 중요한 타사 통합을 모두 보여야 합니다. 애플리케이션을 통한 요청의 예상 흐름에 정렬이 있는지 확인합니다. 주요 워크플로와 사용자 여정을 매핑하여 고객이 애플리케이션을 사용하는 방법을 명확하게 파악할 수 있습니다. 시퀀스 다이어그램을 사용하여이 정보를 캡처하는 것이 좋습니다.

이 공동 작업 세션 후 팀은 애플리케이션의 공유된 멘탈 모델, 중요한 종속성 및 모니터링 기능, 정보에 입각한 결정을 내려 잠재적 카오스 실험을 진행하거나 취소할 수 있는 위험에 대한 이해가 있어야 합니다.

애플리케이션의 알려진 문제 해결

카오스 엔지니어링 실험은 애플리케이션의 결함을 사전에 표시하도록 설계되었습니다. 지연 시간 증가, 서버 재부팅 또는 가용 영역 전원 장애와 같은 장애를 주입하여 실제 중단을 허용할 수 있는 애플리케이션의 기능을 확인할 수 있습니다. 그러나이 프로세스는 대상 애플리케이션의 기본 수준의 안정성과 상태를 가정합니다. 이미 문제가 있는 애플리케이션에서 카오스 실험을 실행하면 더 깊은 문제가 마스킹될 위험이 있습니다.

카오스 엔지니어링을 수행하기 전에 팀은 애플리케이션의 알려진 결함, 버그 및 성능 문제를 해결해야 합니다.

가설과 실험 정의

애플리케이션 또는 조직 내 다른 애플리케이션에 중단을 일으킨 과거 인시던트는 카오스 실험 아이디어를 위한 훌륭한 소스 역할을 할 수 있습니다. 예를 들어 구성 오류 또는 누락된 복원력 패턴으로 인해 이전 중단이 트리거되었습니까? 카오스 실험을 통해 인시던트 기록을 검토하고 실제 실패의 근본 원인을 재생하는 것은 향후 유사한 문제에 대한 복원력을 개발하는 효과적인 방법입니다.

실험 개념의 또 다른 중요한 소스는 애플리케이션에 가장 익숙한 엔지니어, 아키텍트 및 운영자로부터 직접 얻을 수 있습니다. 팀원이 애플리케이션을 크게 방해할 수 있다고 생각되는 가상의 실패 시나리오를 제출하도록 허용하면 내부자 지식을 기반으로 아이디어를 수집할 수 있습니다. 그런 다음 애플리케이션 팀은 이러한 제안된 시나리오 중 잠재적 영향이 가장 큰 시나리오를 평가하거나 알려지지 않은 가장 큰 위험을 노출할 수 있습니다. 위험도 높고 이해도가 낮은 시나리오에 대한 카오스 실험을 대상으로 하면 중요한 학습을 생성하고 향후 문제를 방지할 수 있습니다.

세 번째 아이디어 출처는 복원력 모델링을 수행하여 식별된 비즈니스 손실로 이어질 수 있는 조건을 예측하는 것입니다. 일부 복원력 모델링 연습에서는 복원력 모델을 구축하는 구성 요소 기반 접근 방식을 사용하는 반면, 시스템 기반 접근 방식을 사용하는 경우도 있습니다. 구성 요소 기반 접근 방식은 "구성 요소 x가 과도한 부하를 받거나 실패한 경우 어떻게 됩니까?"라는 질문을 합니다. 그런 다음 복원력 모델을 개발하는 팀은 이러한 시나리오가 더 광범위한 애플리케이션에 미치는 영향을 추측하고 시나리오의 영향을 감지하고 완화하기 위해 현재 시행 중인 모니터링 및 예방 제어를 식별합니다. 또는 시스템 기반 접근 방식은 하향식 프로세스를 따라 "웹 스토어 프런트에서 오래된 인벤토리 수준을 표시하고 있습니다"와 같은 원치 않는 애플리케이션 상태를 강조하고 애플리케이션 팀이 이러한 방식으로 애플리케이션이 동작할 수 있는 조건을 예측하도록 초대합니다.

실험의 운영 준비 상태 확인

앞의 관찰성 섹션에 설명된 대로 애플리케이션 및 동작에 대한 부정적인 조건의 영향을 측정하려면 정량화 가능한 지표가 필요합니다. 애플리케이션의 동작을 측정할 수 있으면 부정적인 조건이 애플리케이션에 영향을 미쳤는지 여부와 어느 정도 영향을 미쳤는지 확인할 수 있습니다.

애플리케이션에 영향을 미치는지 여부를 이해하는 가장 좋은 방법은 안정 상태를 측정하는 것입니다. 정상 상태는 정상적인 운영의 모습을 측정하며 일반적으로 특정 애플리케이션의 비즈니스 및 클라이언트 경험 지표와 일치합니다. 다음 단계로 넘어가기 전에 영향을 이해할 수 있는 관찰성이 있는지 확인하고 실험이 예상대로 진행되지 않을 경우 롤백 메커니즘을 준비합니다.

제어된 실험 및 시나리오 실행

에서는 프로덕션 환경에 있는 애플리케이션에 대해 초기 카오스 실험을 수행하지 않는 AWS것이 좋습니다. 카오스 실험의 목적은 애플리케이션이 스트레스가 많은 조건에서 작동하는 방식에 대해 새로운 것을 배우는 것입니다. 실험 중에 애플리케이션의 동작을 예측할 수 없으므로 프로덕션 환경에서 처음으로 실험을 수행하면 고객에게 영향을 미칠 수 있습니다. 따라서 항상 실제 사용자에게 영향을 미칠 가능성이 최소인 하위 레벨 환경에서 초기 카오스 실험을 실행한 다음 애플리케이션이 주입된 작업을 흡수, 적응 및 복구할 수 있는지 확인한 후 환경을 반복해야 합니다.

부록에 제공된 실험 계획 문서와 마찬가지로 주요 세부 정보를 캡처하는 문서를 사용하여 각 실험을 철저히 계획합니다. 포함할 중요 필드 중 일부는 정상 상태 정의, 가설 및 실패 주입 방법입니다. 카오스 실험의 계획, 실행 및 분석은 단일 아티팩트에서 다룰 수 있습니다.

실험에 대한 서면 계획을 완료한 후 문서에 설명된 계획된 중단을 주입하는 데 필요한 코드를 준비합니다.

실험 중 잠재적 영향을 캡처하려면 관찰성 메커니즘이 마련되어 있는지 확인합니다. AWS FIS 실험 보고서와 같은 실험 결과를 캡처할 자동화된 방법이 아직 없는 경우 실행 중에 메모를 하고 대시보드 스크린샷을 캡처하고 실험을 통해 팀을 리드할 팀원을 식별합니다.

학습 및 미세 조정

각 실험이 끝나면 팀으로 모여 카오스 실험을 검토하고 숙고합니다. 비난 없는 사고방식을 유지하기 위해 의식적으로 노력하세요. 목표는 비난하지 않고 최대한의 학습을 도출하는 데 전적으로 초점을 맞춘 개방적이고 건설적인 대화를 나누는 것입니다.

먼저 실험에 대한 안정 상태 정의와 가설을 검토합니다. 애플리케이션이 예상대로 작동했나요? 가정을 무효화한 놀람이 있었나요? 실험 중에 애플리케이션이 어떻게 반응했는지, 좋은지, 나쁜지에 대한 관찰을 논의합니다. 지표, 로그, 스크린샷 등 수집된 데이터는 정확히 어떤 일이 발생했는지에 대한 스토리를 전달해야 합니다.

판단력 대신에이 데이터 검토에 접근하고 학습 내용을 기반으로 애플리케이션 설계, 문서화, 모니터링 또는 기타 기능을 개선할 수 있는 영역을 식별합니다. 이러한 작업 항목은 애플리케이션을 더 복원력 있게 만들기 위한 후속 프로젝트로 캡처됩니다.

이 비난 없는 접근 방식을 통해 무엇이 잘못되었는지, 어떻게 해결할 수 있는지에 대해 솔직한 대화를 나눌 수 있습니다. 관련된 모든 사람의 긍정적인 의도를 가정하고 좋은 결과를 얻기 위해 노력하고 있다고 신뢰합니다. 공유된 목표는 지속적인 학습과 적응을 통한 조직의 성장과 발전입니다. 건설적이고 비난하지 않는 방식으로 수행되는 혼란 실험 검토는 팀이 애플리케이션과 조직을 장기적으로 더 안정적이고 복원력 있게 만드는 귀중한 인사이트를 얻을 수 있는 안전한 공간을 제공합니다. 초점은 사람이 아닌 학습에 있습니다. 팀 전체에 학습 내용을 분산하려면 실험 결과 보고서를 중앙 위치에 게시하고 다른 사람이 학습할 수 있도록 결과를 알립니다.