개요

카오스 엔지니어링과 복원력 테스트 비교

복원력 테스트는 결정적입니다. 즉, 애플리케이션에서 구현된 회로 차단기, 재시도, 장애 조치 또는 폴백과 같은 복원력 메커니즘에 대해 알려진 특성을 검증합니다. 이러한 애플리케이션 구성 요소가 사용자 영향을 최소화하거나 전혀 주지 않으면서 제어된 중단을 어떻게 흡수하는지 확인합니다. 따라서 복원력 테스트는 통과/실패 결과를 생성하기 위해 애플리케이션 구성 요소에 주입되는 알려진 장애 모드의 검증에 중점을 둡니다. 복원력 태세에 회귀가 발생하지 않도록 파이프라인의 한 단계로 복원력 테스트를 지속적으로 실행해야 합니다. 복원력 테스트에서는 실제 구성 요소에 대해 테스트를 실행하지 않고 특정 구성 요소를 시뮬레이션하는 모APIs를 실행하는 경우가 많습니다. 이 접근 방식을 사용하면 제어된 환경에서 장애 시나리오를 일관되고 재현 가능하게 테스트할 수 있으므로 자동화된 파이프라인 통합 및 회귀 테스트에 적합합니다.

반면 카오스 엔지니어링은 비결정적입니다. 즉, 가설을 기반으로 하며 애플리케이션과 해당 종속성(사람, 프로세스 및 기술)이 예상치 못한 장애 모드를 어떻게 흡수, 적응 및 복구하는지에 대한 멘탈 모델을 검증합니다. 따라서 카오스 엔지니어링은 결함을 조기에 포착하고 대규모 이벤트로 전환되기 전에 이를 해결하는 것을 목표로 알 수 없는 장애 모드의 end-to-end 확인에 중점을 둡니다. 카오스 엔지니어링은 지속적인 학습을 촉진하며 별도의 카오스 파이프라인 또는 임시 실험을 통해 연습해야 합니다. 이를 통해 코드 배포 시 개발자의 생산성을 저해하지 않고 언제든지 여러 실험을 실행할 수 있습니다.

카오스 엔지니어링 프로세스는 종종 카오스 게임 데이로 시작합니다. 카오스 게임 데이는 팀이 의도적으로 제어된 장애 또는 장애를 애플리케이션에 주입하는 전용 이벤트입니다. 게임 데이는 점진적입니다. 하위 수준 환경(예: 개발 또는 테스트)에서 시작하고 신뢰도가 높아짐에 따라 점차 상위 수준 환경(예: 스테이징 및 사전 프로덕션)으로 이동합니다. 이러한 환경을 체계적으로 이동하면 팀은 시스템이 프로덕션에 도달하기 전에 주입된 결함을 제대로 견딜 수 있는지 확인할 수 있습니다. 이러한 체계적인 진행은 카오스 실험이 프로덕션 환경에서 수행될 때까지 팀이 시스템의 복원력 기능에 대한 상당한 신뢰를 구축하도록 보장합니다. 게임 데이 프로세스는 예상치 못한 프로덕션 중단 시 학습 스트레스를 없애면서 애플리케이션 아키텍처 및 운영 관행의 약점과 취약성을 식별하는 선제적 접근 방식입니다.

카오스 엔지니어링의 가치

오늘날의 세계에서는 복잡한 시스템이 보편적입니다. 금융 시장부터 의료에 이르기까지 우리 라이프의 여러 측면에서 중요한 역할을 합니다. 이러한 시스템은 항상 작동해야 합니다. 그러나 복잡한 시스템은 종종 심각한 결과를 초래할 수 있는 예상치 못한 이벤트 및 동작에 취약합니다. 조직은 중단이 발생할지 여부를 걱정하는 대신 중단을 계획해야 합니다. 핵심 또는 미션 크리티컬 비즈니스 서비스에 시나리오 테스트를 적용하여 이를 수행할 수 있습니다. 여기서 카오스 엔지니어링이 시작됩니다.

카오스 엔지니어링은 위험을 완화하고 복원력을 개선하는 데 도움이 되는 복잡한 시스템을 관리하는 접근 방식을 제공합니다. 카오스 실험을 준비하려면 팀이 시스템 동작에 대한 가설을 개발해야 합니다.이 가설은 시스템 구축 방식과 운영 방식에 대한 이해를 심화합니다. 이 준비를 통해 발견되지 않은 상태로 남을 수 있는 멘탈 격차, 아키텍처 인사이트 및 운영 지식이 드러나는 경우가 많습니다. 복잡한 시스템이 장애에 어떻게 반응하는지 이해함으로써 카오스 엔지니어링은 시스템 설계 및 관리에서 투명성과 책임을 강화합니다. 조직이 카오스 엔지니어링을 더 자주 수행할수록 운영에 더 잘 대비할 수 있습니다. 카오스 엔지니어링을 사용하면 사용자 영향을 최소화하거나 전혀 주지 않으면서 구성 요소 장애를 견딜 수 있는 복원력이 뛰어난 애플리케이션을 설계하는 모범 사례를 수립할 수 있습니다. 이렇게 하면 중요한 애플리케이션이 예상 서비스 수준 및 내충격성 내에서 작동하는 동시에 자체 시스템에 대한 팀의 지식을 지속적으로 높일 수 있습니다.

불리한 조건 준비

를 빌드할 때 Amazon Elastic Compute Cloud(Amazon EC2), Amazon Simple Storage Service(Amazon S3)와 같은 리전 서비스 AWS, AWS Identity and Access Management (IAM)과 같은 글로벌 서비스, 타사 서비스형 소프트웨어(SaaS) 서비스, 온프레미스 서비스와 같은 다양한 유형의 서비스를 사용합니다. 각 서비스 유형은 고려해야 할 다양한 장애 도메인을 노출합니다. 자체적으로 발생한 이벤트 또는 조직이 제어할 수 없는 타사에서 발생한 이벤트에 어떻게 대비하나요?

애플리케이션이 불리한 조건에 어떻게 대응할 수 있는지 이해하는 데 도움이 되도록 AWS Fault Injection Service (AWS FIS)를 사용할 수 있습니다. AWS FIS 는 제어된 방식으로 결함 주입 실험을 실행하기 위한 완전 관리형 서비스입니다. 이 서비스를 사용하여 가용 영역 전원 중단 및 리전 간 연결 문제와 같은 AWS제공 시나리오를 주입하거나 서비스에서 제공하는 다양한 결함 작업을 함께 연결하여 자체 실험을 구축할 수 있습니다.를 AWS FIS 사용하면 팀이 일반적인 결함에 애플리케이션이 어떻게 반응하는지 지속적으로 연습하고 학습하고 결함을 감지할 때 결함을 해결할 수 있습니다.

제어된 카오스 엔지니어링 연습

카오스 제어 실험의 주요 원칙은 다음과 같습니다.

카오스 엔지니어링을 성공적으로 확장하려면 카오스 실험을 제어된 방식으로 구현해야 합니다. 를 사용할 때 Amazon CloudWatch 경보를 사용하여 중지 조건을 생성할 AWS FIS수 있습니다. 이러한 조건을 실험 템플릿에 통합하여 범위를 벗어나 마지막으로 알려진 상태로 롤백될 경우 실험이 중지되도록 할 수 있습니다. AWS FIS 또한는 안전 레버를 제공합니다. 이러한 레버를 사용하면는 다중 계정 실험을 AWS 리전포함하여의 계정에서 실행 중인 모든 실험을 AWS FIS 중지 및 롤백하고 새 실험이 시작되지 않도록 합니다. 이렇게 하면 거래 시간, 판매 이벤트 또는 제품 출시와 같은 특정 기간 동안 또는 애플리케이션 상태 경보에 대한 응답으로 오류가 주입되는 것을 방지할 수 있습니다. 안전 레버는 수동으로 해제될 때까지 계속 작동합니다.

카오스 실험을 수행할 때는 특히 실험이 프로덕션 환경에 있는 애플리케이션에 영향을 미칠 가능성이 있는 경우 환경에서 원치 않는 부작용을 방지하기 위한 보호 조치를 정의해야 합니다. 실험을 계획할 때 환경의 다른 애플리케이션에 미칠 수 있는 부정적인 영향을 예상합니다. 예를 들어 다른 애플리케이션은 실험의 일부인 애플리케이션에서 잘못된 메시지를 수신하거나, 요청 볼륨이 많거나, 인프라를 공유하는 경우 리소스 경합이 발생할 수 있습니다. 실험을 실행하기 전에 이러한 위험을 문서화하고 알려지거나 허용되지 않는 문제를 해결합니다.