(넷플릭스) 넷플릭스의 카오스 엔지니어링

백그라운드

페이스북을 하다가, AWS 사용자 모임에서 카오스 엔지니어링 관련 밋업을 한다는 글을 발견했다.

마이크로서비스 아키텍처, 카오스라는 단어 때문에 카오스 엔지니어링이라는 것에 관심을 갖게 되었다.

카오스 엔지니어링이란 어떤 개념인지 찾아보고, 정리해보고자 한다.

카오스 엔지니어링 탄생 배경

규모있는 시스템을 빠르게 나눠서 개발하고, 관리를 편하게 하기 위하여 마이크로서비스 아키텍처 같은 분산 시스템 아키텍처가 등장했다.

그러나 서비스별 로직을 개별 서버로 분리해냈어도, 각 시스템들은 서로 상호작용하고 있다.

그래서 한 군데에서 장애가 발생하면, 이 장애가 여기저기 퍼지게 된다. 

게다가 문제들이 여러 시스템에서 얽히고 설켜서, 디버깅하기도 어려운 상황이 발생되기도 한다.

이러한 영향은 아래와 같은 문제들을 발생시킨다. 

- 어디서 문제가 난건지 파악하기 어렵기 때문에, 사람들이 부적절한 대응을 하게 만든다. 

- 한 서버에서 장애가 나서, 타임아웃에 걸리게 된다면, 불필요하게 계속 다른 서버에 Retry call을 날리는 상황도 생길 수 있다.

- 만약 클라이언트에서 정상적으로 Response를 받지 못했을 때, 계속 API를 호출하는 구조라면, 컨트롤러 역할을 하는 서버에 트래픽이 마구 몰릴 수 도 있다.

- 장애는 한군데에서 발생한건데, 이로 인한 영향으로 다른 서버나 코드에서 에러가 발생하게 된다. 이 경우, 에러 디버깅을 더 힘들게 만든다. 

( Aㅏ...! 뭔지 알거같다..! 내가 다루고 있는 시스템도 마이크로 서비스 아키텍처를 기반으로 구성되어 있다. 그래서 한 서버에서 장애가 나면 여러군데에서 장애가 퍼진다. 그러면 여러 코드에서 에러가 난다. 그러면 장애가 났을 때, 실제로 문제가 발생한 부분을 찾으려면 한참 헤매야한다. 카오스 엔지니어링이 필요해진 배경을 내가 이미 겪고있다! )

그래서 프로덕션 환경에서 크리티컬한 장애를 발생시키는 요소를 사전에 인지하고, 찾아내서 개선해야하는 필요성이 생겼다. 

카오스 엔지니어링은 이러한 시스템 약점을 실험을 통해 쉽게 찾을 수 있게 도와주는 방법론이라고 보면 된다. 

시스템의 약점을 찾아내는 방법은 아래와 같다. 

1. 시스템이 "정상 상태"임을 측정할 수 있는 지표를 만들어야한다. 

   => 광고 시스템을 예로 들자면... 노출량의 변동폭이 일정 이상인 경우 비정상 상태로 볼 수 있을 것 같다. 

2. 실험 그룹 / 대조 그룹에서 "정상 상태"가 계속 지속될거라고 가정을 해둔다. 

3. 그다음 프로덕션 환경에서 시스템에 영향을 비칠 수 있는 변수들을 리스트업한다. 

    => 예를 들어 특정 서버에 버그가 있어서 500이 떨어지는 상황, 아니면.. 통신하는 서버의 응답속도가 늦어져서 타임아웃이 나느 상황 등 ..

4. 위의 변수들을 실험 그룹에 재현해보면서, 각 변수들이 시스템의 상태에 어떤 영향을 미치는지 파악하면 된다. 

실험 그룹을 비정상상태로 만드는게 쉽지 않다면, 시스템에 자부심을 느껴도 된다! 왜냐믄 카오스를 느끼기 어려운 시스템인거니까~

그리고 이 실험결과를 통해 발견된 약점들은 대규모 시스템에 영향을 미치기전에 개선하는게 필요하다. 

참고 

PRINCIPLES OF CHAOS ENGINEERING

http://principlesofchaos.org/

넷플릭스의 카오스 엔지니어링의 원칙

http://channy.creation.net/blog/1173#.Wkd-oVSMjMV

( 유튜브 영상 ) Mastering Chaos - A Netflix Guide to Microservices 

https://youtu.be/CZ3wIuvmHeM

넷플릭스 기술 블로그 - Chaos Engineering 101

https://medium.com/production-ready/chaos-engineering-101-1103059fae44