복원력과 디지털 성숙도가 높고 대시보드 및 기타 도구를 통해 높은 관측 가능성을 확보한 조직은 실험을 통해 발생하는 문제에 대해 즉각적인 조치를 취할 수 있으므로 카오스 엔지니어링을 도입해야 합니다. 이러한 관측 가능성이 부족한 조직⁴(ibm.com 외부 링크)은 카오스 엔지니어링을 통해 생성된 실험을 진행하는 데 시간이 너무 오래 소요될 수 있습니다.

카오스 엔지니어링은 클라우드, 특히 퍼블릭 클라우드 와 클라우드 네이티브 앱을 사용하는 조직에도 필수 요소입니다. 퍼블릭 클라우드에서는 클라우드 공급업체와의 조율이 필요한 중단 문제가 발생할 수 있으며, 이로 인해 온프레미스의 문제를 처리하는 것과는 다른 접근 방식이 발생합니다. 

Constellation Research⁵에 따르면 클라우드를 사용하는 기업에서는 클라우드와 서비스형 소프트웨어(SaaS)가 이러한 사고에 어떻게 영향을 미치는지 고려하지 않은 채 IT 사고에 접근하는 경우가 여전히 많습니다( ibm.com 외부 링크). 

또한 마이크로서비스의 사용이 늘어나면서 시스템에서 실행되는 호스트 또는 컨테이너의 수가 증가하면, 카오스 실험을 통해 발굴하고 해결할 수 있는 고유한 과제(ibm.com 외부 링크)도 생겨납니다. 복잡성을 코드 설계에서 시스템 운영으로 전환하면 복잡성이 없어지지는 않지만 자동화가 심화될 수 있습니다.

또한 카오스 엔지니어링은 조직이 지속적 통합 및 지속적 배포 (CI/CD) 파이프라인의 속도를 향상하는 데도 도움이 될 수 있습니다. 넷플릭스⁶(ibm.com 외부 링크)처럼 카오스 엔지니어링을 CI/CD에 통합할 경우 조직은 잠재적인 영향을 통제하면서 지속적인 실험을 자동화할 수 있습니다. 

마지막으로, 조직이 API를 통해 파트너와 점점 더 많이 연결된다는 사실은 해당 시스템의 문제가 다른 조직에도 영향을 미칠 수 있다는 것을 의미합니다.

카오스 엔지니어링을 구축하면 조직은 아키텍처의 약점을 파악하고 이를 수정하여 궁극적으로 향후 발생할 장애를 예측할 수 있는 능력을 키울 수 있습니다. 성공적인 카오스 엔지니어링은 조직이 고객에게 중대한 영향을 미치는 기술적 장애를 최소화하는 데 도움이 되며, 더 강력하고 탄력적이며 복잡한 시스템 아키텍처의 구축 또한 지원합니다. 조직이 카오스 엔지니어링을 추진하기로 결정했다면 다음 단계는 사전 프로덕션 환경에서 실행할지, 아니면 프로덕션 환경에서 실행할지를 결정하는 것입니다.

DevOps 팀에는 카오스 엔지니어링 실험을 통해 다양한 시스템 프로세스를 테스트할 수 있는 몇 가지 옵션이 있습니다.

• 대기 시간 주입: DevOps 팀에서 느리거나 실패한 네트워크 연결을 에뮬레이트하는 시나리오를 의도적으로 만듭니다. 여기에는 네트워크 지연 또는 느린 응답 시간의 도입이 포함됩니다.
• 장애 주입: 여기에는 오류가 다른 종속 시스템에 미치는 영향과 서비스 중단 여부를 확인하기 위해 의도적으로 시스템에 오류를 도입하는 작업이 포함됩니다. 장애 주입의 예로는 디스크 장애 유발, 프로세스 종료, 호스트 종료, 전원 또는 온도 상승 등이 있습니다. 장애 주입을 통해 조직은 문제가 발생할 경우 전체 시스템의 장애를 일으킬 수 있는 단일 장애 지점을 파악할 수 있습니다.
• 부하 발생: 이는 정상 작동을 훨씬 초과하는 상당한 수준의 트래픽을 전송하여 시스템에 의도적으로 스트레스를 주는 것입니다. 이를 통해 사이트 안정성 엔지니어(SRE)는 시스템의 병목을 파악할 수 있으며, 그 결과 확장성이 뛰어난 시스템을 구축할 수 있습니다. 
• 카나리아 테스트: 카나리아 테스트는 소규모 사용자 그룹을 대상으로 새로운 제품이나 기능을 출시하는 것입니다. 이렇게 하면 결함이나 버그가 일부 방문자에게만 영향을 미치고 나머지 방문자는 기존 웹사이트 환경을 계속 이용할 수 있습니다.

이상적인 카오스 엔지니어링 프로세스를 만들려면 조직이 대규모 분산 시스템을 마련할 수 있도록 몇 가지 원칙을 세워야 합니다.

• 시스템 파악: 여기에는 전체 시스템, 시스템에서 발생하는 새로운 속성 및 기능, 토폴로지, 아키텍처, 종속성, 정상 상태 동작, 출력 응답, 가용성, 지연 시간 및 처리량과 같은 특성에 대한 포괄적인 지식이 포함됩니다.
  
• 실패 수용: 소프트웨어 엔지니어가 사건의 발생을 막기로 되어 있을 때 사건이 발생하도록 둔다는 것이 처음에는 역설적으로 보일 수 있습니다. 그러나 IT 서비스에서 중단은 항상 발생하기 마련이며, 조직 내 팀의 업무 외 시간에 문제가 발생하거나 이전에 그러한 문제를 겪어본 적 없는 상황보다는 통제된 환경에서 중단을 경험하고 선제적으로 해결책을 파악하는 것이 낫습니다.
• 정상 상태 동작 설정: 먼저 엔지니어링 팀은 시스템이 올바르게 실행될 때 어떻게 작동해야 하는지 정의하여 실험이 정상 상태에 어떤 영향을 미치는지 비교할 수 있어야 합니다.
• 실제 인시던트 파악: 카오스 엔지니어링 실험은 발생할 가능성이 없는 상황을 만들기 보다는 평상시에 일어날 수 있는 상황을 최대한 근접하게 재현해야 합니다. 발생할 수 있는 문제로는 네트워크 및 인프라 장애, 불량 코드, 전원 문제 및 트래픽 과부하가 있습니다.
• 게임 데이 만들기: 카오스 엔지니어링에서는 특정 날짜를 정해두고 여러 테스트를 진행하는 게임 데이에 환경을 연구하면 리소스를 최대한 활용하여 가능한 한 많은 문제를 식별하고 해결할 수 있습니다. 
• 자동화 활용: 어떤 규모의 조직에서든 카오스 엔지니어링을 사용하면 직접 진행할 경우 노동력이 너무 많이 드는 실험도 자동화할 수 있습니다. 이를 통해 카오스 엔지니어링을 진행하는 중에 IT 팀이 지는 부담을 일부 줄일 수 있습니다. 실험 설계, 장애 주입 및 인프라 프로비저닝은 조직에서 자동화할 수 있는 실험의 모든 양상입니다.
• 폭발 반경에 유의하기: 카오스 엔지니어는 고객에게 미치는 실제 피해를 최대한 줄일 수 있도록 폭발 반경을 최소화하기 위해 많은 노력을 기울여야 합니다. 폭발 반경을 최소화하는 몇 가지 방법은 다음과 같습니다.
  • 서비스의 하위 집합을 대상으로 설정: 카오스 엔지니어링이 특히 프로덕션 환경에서 조직의 서비스를 근본적으로 방해해서는 안 됩니다. 서비스의 특정 하위 집합을 대상으로 하면 인시던트 발생 시 영향을 최소화하여 전체 시스템을 중단시키지 않을 수 있습니다.
  • 제한된 시간 동안 실험 진행: 실험에는 시작과 끝이 있어야 합니다. 실험의 포인트는 인시던트를 생성하여 해결하는 것이지 오랫동안 확인되지 않은 상태 그대로 실행하는 것이 아닙니다.
  • 트래픽이 집중되는 시간대를 피해 실험 진행: 인시던트 발생 시 높은 용량이 시스템에 미치는 영향을 측정하려는 목적이 아니라면 조직은 피크 시간대에 실험을 실행하지 않아야 합니다. 
  • 개발 환경에서 실험 진행: 고객이 서비스 중단을 경험하지 않도록 하는 가장 간단한 방법은 사전 프로덕션 환경에서 진행하는 것입니다. 그러나 이렇게 하면 프로덕션 환경과 조건이 다를 수 있으며, 발생할 수 있는 상황에 대한 잘못된 정보가 제공될 수 있습니다. 이를 최소화하려면 사전 프로덕션 환경과 프로덕션 환경을 최대한 서로 미러링하십시오. 
  • 모든 구성 요소에 대한 실험: 조직의 시스템은 꾸준히 변화하기 때문에 카오스 실험에도 끝이 없습니다. 목표 또한 "모든 것"을 테스트하는 것이어야 합니다. 모든 구성 요소, 계층, 서비스 및 프로세스 전반에 걸쳐 종속성을 검사하십시오.

카오스 엔지니어링을 활용하는 조직은 프로덕션 환경에서 카오스 테스트를 진행할지, 아니면 사전 프로덕션 환경에서 진행할지 결정해야 합니다. 프로덕션 환경에서 카오스 엔지니어링을 진행하는 것이 가장 유용한 이유에는 몇 가지가 있습니다. 라이브 환경은 인시던트가 고객 경험에 어떤 영향을 미치는지 이해할 수 있는 가장 정확한 환경을 제공합니다. 사전 프로덕션 환경이 실제 환경과 정확히 일치하지 않아 실험에 약간의 가변성이 발생할 수 있다는 점이 또 다른 이유입니다.

예를 들어, 사전 프로덕션 환경의 인시던트는 라이브 환경과 트래픽 수준이 동일하지 않기 때문에 현실적인 대응이 불가능할 수 있습니다. 또한 해당 환경과 보안 구성이 동일하지 않을 수도 있습니다. 

일부 조직에서는 라이브 사이트에 의도적으로 문제를 일으키는 것을 두려워하여 사전 프로덕션 또는 개발 사이트에서 실험을 진행하기도 합니다. 이렇게 하면 발생하는 모든 문제가 실제 고객 경험에는 영향을 미치지 않습니다. 이러한 문제를 완화하기 위해 일부 조직에서는 라이브 프로덕션 환경으로 전환하기 전에 프로세스를 파악할 수 있도록 사전 프로덕션 환경에서 시작하기도 합니다.

조직은 위험 허용 범위에 따라 어떤 환경을 사용할지 선택할 수 있습니다. 궁극적으로 카오스 엔지니어링은 실제 대규모 문제를 테스트하는 것을 목표로 하므로 프로덕션 환경에서야 말로 현재 상황과 수정이 필요한 사항을 가장 정확하게 파악할 수 있습니다.