지난 2018년 1월 17일 GS타워 12층에서 'Chaos Engineering Community' 첫번째 모임이 있었다. 그 내용을 간단하게 정리해본다.


문제인식

부하테스트 혹은 품질테스트 등의 정형화된 테스트만으로는 운영 중에 Microservice에서 발생하는 문제를 해결할 수 없다.

Chaos Engineering

'운영' 서비스의 각종 장애 조건을 견딜 수 있는 시스템의 신뢰성을 확보하기 위해 분산 시스템을 실험하고 배우는 분야

  • 적용단계

    1. 정상 동작을 나타내는 시스템의 측정 가능 통계치로 '정상 상태' 정의하기

    2. 정상 상태가 대조군과 실험군 모두에서 계속될 것이라고 가정하기

    3. 서버 장애, 하드 디스크 오작동, 네트워크 끊김 같은 실제 문제 변수 정의

    4. 대조군과 실험군 사이의 정상 상태 차이를 조사하여 가설 검증하기

  • 카오스 엔지니어링 고급 원칙

    1. 정상 상태 행동에 관한 가설 구축

    2. 현실 세계의 문제 시도하기

    3. 실제 운영환경에서 실험하기

    4. 자동화를 통한 지속적 실험

    5. 폭발 반경 최소화

      • 장애 발생범위 통제

      • Circuit breaker, Bulkheads(격벽, 피해 확산 막음), DITTO(Do Idempotent Things to Others)


  • 개발팀: 예상치 못한 애플리케이션 오류에 대한 사람들의 대처가 오히려 문제를 키우기도 함.

    • 급히 고쳐서 처리하겠다는 생각

    • 서비스를 잠시 중단하더라도 확실하게 처리하고 재발을 방지하자.

    • 개발팀이 신뢰받고 힘이 필요하다고 생각함

토론해볼 문제: 카오스 엔지니어링

  • Q: DevOps vs SRE(Site Reliability Engineering) vs Chaos?

  • Q: 서비스 중 장애유발에 의한 피해대응태도는?

  • Q: 클라우드와 마이크로 서비스는 필수적인가?

  • Q: 카오스를 적용하기 힘든 서비스 종류가 있는가?

  • Q: 개발자의 몫인가? 운영자의 몫인가 아니면 DevOps 의 몫인가?

정리

카오스 엔지니어링은 '클라우드'환경에서 '마이크로서비스(Microservice)' 아키텍처를 도입했을 때 서비스 운영 중에 발생할 수 있는 문제를 카오스 엔지니어링팀이 발생시키고 장애가 발생하면서 생기는 파장을 확인하여 이를 해결하여 서비스를 더욱 안정적으로 하는 것을 목표로 하고 있다.

이를 시도해보기 위해서는 '클라우드' + '마이크로서비스 아키텍처' + '규모' + '자원'이 가능해야 하지 않을까 하는 생각이 든다. 저것 중 한가지라도 부족하면 시도해보기 어려운 분야가 아닐까.

참고




저작자표시

'DevOps' 카테고리의 다른 글

AWS 서울리전(Seoul Region) 설립, 이제 시작  (0) 2016.01.08

+ Recent posts

티스토리툴바