Chaos Monkey Engineering

01 Apr 2023 enhanced-experience

  • 카오스 몽키(Chaos Monkey) 란?

의도적으로 문제상황(장애)을 만들어서 점검을 통해 시스템의 안정성, 탄력성 등을 확보하는 방법

어떻게 할 것인가?

  • 시작이 거창할 필요는 없다.
    • 일단 최소의 비용을 투입하여 정의하는 것이 중요하다.
  • 성능 테스트 등의 자료를 기반으로 정상 상태를 정의한다.
    • 또는 간단한 작업을 통하여 정상 상태를 만든다.
    • e.g. 요청과 함께 Kafka 에 Message 를 Produce하는 로직과 해당 Topic 을 Consume 하여 record 를 count 하는 기능 개발
      • produce 수와 consume 수가 같은걸 정상 상태로 정의한다.
      • 또는 n % 까지의 유실을 정상 상태로 정의한다.
  • 실험군과 대조군에 네트워크 단절, Server Fault 등의 변수를 적용하여 정상 상태를 비정상으로 만든다.
  • 정상 상태가 유지된다면, 견고한 시스템이다.
  • 비정상 상태일 경우에는 진단 이 필요하다.

진단 및 조치는?

  • 부족한 부분에 대해서 정리한다. (꼭 시급도를 같이 정리한다.)
    • 만약 크리티컬한 이슈가 발견된다면 빠르게 테스트 하고 조치하는 걸 추천한다.
  • 특정 기능에 대한 버그나 정확한 원인이 있다면 개선 일자를 잡아 놓고, 릴리즈 노트 등에 꼭 Change Log 에 포함하여 개선결과를 공유한다.
  • 애매한 상황에서 더 좋은 방법을 논의하여 개선해 나가야 한다면?
    • 각각 가설을 설정한다. 개선 방향 및 투입 비용 대비 효과 등을 정리하여 이어서 테스트한다던가, 다음 주기에 맞춰서 검증해 나간다.
    • 나은 방법이 나오게 된다면, 위와 같이 개선 일자를 잡고 결과를 공유한다.

얻을 수 있는 것은?

  • MSA 로 시스템이 구성되어 있거나, 라이브러리를 제공하는 경우 특정 모듈 등에 대한 신뢰성은 굉장히 중요하다.
  • 그런 관점에서 주기적 or 불규칙적으로 의도적 장애를 발생 시켜서 그걸 더 빠르게 정상화 시키거나 문제가 눈에 띄지 않는 대응책이 마련 되어 있다면, 일을 하는 많은 사람들에게 굉장한 신뢰를 줄 것이다.
  • 위 내용을 Report 로 쌓아 나가고, 부족한 점은 부족하다 인정하고 언제까지 대응하겠다. 등을 가시화 해주게 된다면, 사용자는 예측 가능성을 올릴 수 있을 것이다.
  • 그럼 자연적으로 시스템 안정성 취하고, 더 많은 고객을 유지 등을 할 수 있을 것이다.

주의해야할 점

  • 아무리 개발 환경에서 진행 하더라도 해당 시스템을 이용 하고 있는 다른 사용자가 있다면, 테스트로 인해 업무에 지장이 있다면 그 또한 스트레스일 것이고, 신뢰도 역시 떨어질 것이다.
    • 그들의 퇴근시간이 늘어날 것이니…
  • 격리된 환경에서 테스트 하는 것이 좋다.

결론

  • 엄청난 비용을 투입하여 테스트하는 것보다 작은 부분부터 가설을 설정하여 진행한다.
    • 오픈소스 등 여러 도구를 사용하기 보다는 일단 시작하면서 도구를 조금씩 추가하는걸 추천한다.
      • 오픈소스 학습 비용 등을 투입하는 것이 효율적 일지는 초기 테스트로 효과를 얻었을 때 결정해도 늦지 않을 것 같다.
    • 완벽한 시스템은 없다. 시스템을 구상 또는 개발하면서 아 이부분 찜찜한데? 하는 영역부터 꺼내어 시작하는걸 추천한다.
  • 시간이 지나면 데이터가 쌓일 것이고, 그건 엄청나게 귀한 자료가 될 것이다.
    • 휴먼 폴트가 지속 적으로 발생하는 부분이 보일 것이고, 특정 플랫폼을 이용하여 개선할 수 있는 영역도 보일 것이다.
    • 신규로 시스템을 구축할 때, 참고 자료가 될 것이다.

참고자료

  • https://www.itworld.co.kr/tags/71938/%EC%B9%B4%EC%98%A4%EC%8A%A4%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EB%A7%81/152680

Related Posts