Chaos Engineering

Update: 2021년, AWS에서 제공하는 카오스 엔지니어링 서비스인 장애 주입 실험기(Fault Injection Simulator, FIS)를 출시하였다. 그래서 서비스 장애 주입 실험기를 활용하는 카오스 엔지니어링 테라폼 예제(https://github.com/Young-ook/terraform-aws-fis/)를 만들었다. EC2 오토스케일링 그룹, EKS 컨테이너 클러스터, RDS 데이터베이스 클러스터, Redis 클러스터, VPC 네트워크를 대상으로 장애를 주입하는 카오스 엔지니어링을 직접 실습 해볼 수 있다.

---

카오스 엔지니어링(Chaos Engineering)이라는 이름만 들었다면, 여러가지 상상이 떠오를 것이다. 아니다, 어쩌면 모든 사람이 같은 생각을 떠 올렸을 수도 있다. 우주가 탄생하기 전 혼돈의 상태를 떠올렸을 것이고, 그러한 무질서 상태가 펼쳐지는 무서운 상상을 했을 것이다. 많은 사람들이 그러하듯, 카오스라는 말은 익숙한 무엇인가를 떠올리게 한다. 그러나 다르게 곱씹어보면 피부로 와닿을만큼 설명하기 어렵다. 게다가 기술을 바탕으로 무엇인가를 만들거나 가공하는 ‘엔지니어링’과 결합했을 때는 어떤 것을 떠올려야할 지 정말 혼란스럽다.

처음에 카오스 엔지니어링을 알게 된 것은 2012년 정도였던 것 같다. 엄밀하게는 카오스 몽키(Chaos Monkey)였다. 아마존 클라우드(AWS)에서 동작하는 서비스를 개발하고 운영한지 1년 정도 되었을 때였다. 그 즈음 아마존 클라우드를 적극적으로 활용하는 넷플릭스(Netflix)는 꽤 큰 서비스 불가 문제를 겪었다. 그런데 그들의 반응이 예상밖이어서 놀라웠다. 보다 철저하게 준비해서 미래를 대비하겠다고 그들의 블로그에 선언했던 것이다.

당시 한국의 많은 기업들은 역시나 아미존 클라우드는 위험해서 불안하니 직접 구축한 데이터센터를 유지해야 한다고 주장했다. 같은 상황에 대해 넷플릭스는 완전히 대비되는 반응을 보였는데, 당시에 매우 인상깊었기 때문에 회사의 내부 세미나에 이 내용을 소개했다. 클라우드 기술 세미나의 마지막 슬라이드에 '그래도 우리는 클라우드로 간다' 라는 넷플릭스의 선언^[각주:1]을 담았다.

당시 발생한 문제는 넷플릭스에게는 꽤 큰 손실을 입히는 사고였고 아마존의 책임이 없지는 않았다. 많은 경쟁자들은 목소리를 높여 다시 데이터센터로 돌아가야 한다고 말했다. 조금 양보하더라도 모든 서비스 서버를 아마존으로 옮기는 것은 위험하다고 주장했다. 그러나 넷플릭스는 반대의 선택을 했다. 당시 데이터센터를 일부 갖고 있었지만, 오히려 적극적으로 아마존 클라우드로 옮기기로 한 것이다. 대신 이렇게 문제가 발생할 수 있다는 경험을 양분삼아 아마존 클라우드의 크고 작은 사용불가 상황을 적극적으로 대응하는 것으로 전략을 세웠다.

카오스 몽키는 그러한 넷플릭스의 전략과 철학을 담은 도구로 탄생하였다. 서버는 언제든 멈출 수 있지만 서비스는 멈추지 않도록 만드는 것이었다. 서버가 응답하지 않을 수 있는, 서버가 동작할 하드웨어에 문제가 생기는 상황을 일부러 만들어 보는 것이다. 마치 원숭이에게 휴대전화를 쥐어주는 것과 비슷한 상황을 연출하는 것이다. 원숭이가 이 새로운 물건을 어떻게 할 지 우리가 예측하기 어렵기 때문에 이러한 시험은 혹독한 조건 속에 제품을 노출 시키고 제품의 품질을 점검해 볼 수 있게 해준다.

이것을 몽키 테스팅(Monkey Testing)이라고 부른다. 이름에서 떠올릴 수 있듯이 카오스 몽키는 서버가 겪을 수 있는 현실의 문제를 인위적으로 제공하는 도구이다. 그래서 카오스 몽키가 어떤 인스턴스(Instance)를 마구잡이로 망가트렸을 때 고객이 느끼는 전체 서비스가 어떻게 되는 지 살펴 볼 수 있는 것이다.

누군가는 카오스 엔지니어링이 지옥같은 현실을 체험하게 만드는 가혹한 방법론이라고 생각할 수 있다. 어쩌면 냉혹하고 비인격적인 프로의 세계를 말하는 것이라고 생각할 수 있다. 실제 그러한 점이 없는 것은 아니다. 2013년 즈음 넷플릭스의 제안을 받고 사무실에 다녀온 친구의 말을 빌리자면 상주하는 소수의 핵심 직원들은 분리된 자기 자리가 있었지만 나머지 직원들은 특별한 자리 없이 랩톱을 들고 다닌다고 하였다. 지독한 성과주의를 지향하는 넷플릭스의 기업문화를 보고 넷플릭스의 제안을 거절했다는 그 친구의 말도 들을 수 있었다. 넷플릭스는 마치 프로구단처럼 동작한다. 그래서 카오스 엔지니어링이 실전에서 성과를 내는 선수를 재계약하고 성적이 좋지 않은 선수는 방출하는 방식의 냉혹한 방법론인 것을 부정할 수는 없다.

그러나 앞서 말한 사례와 같이 같은 현상이라도 해석은 다를 수 있다. 카오스 엔지니어링은 훈련이 잘 된 선수들을 데려와서 바로 실전에 투입하고 버리는 방법을 말하는 것이 아니라고 생각한다. 선수들을 골탕먹이기위해 혼돈에 빠트리는 나쁜 술수인 것도 아니라고 생각한다.

오히려 카오스 엔지니어링은 혼란을 야기시키는 것이 아니라, 혼란을 제어하기 위한 기술이라고 생각한다. 아무리 뛰어난 선수라도 훈련과 적응이 필요하다. 혹독하겠지만, 실전에서 겪을 수 있는 문제상황을 재현해보면서 대비 훈련을 한다면 선수가 성장하는데 많은 도움이 될 것이다. 팀 전체가 이런 과정을 거쳤다면, 그 팀이 좋은 성과를 내는 것은 어쩌면 당연하다. 그래서 카오스 엔지니어링은 실전에서 일어날 수 있는 문제상황을 인위적으로 주입해서 쭉쩡이를 걸러내는 냉혹한 방법론이지만, 다른 한 편으로는 현실세계에서 일어날 수 있는 문제상황을 예측하고 대비하는 과정에 우선순위를 두는 방법론이라고 할 수 있다.

무작위로 운영 중인 클라우드 서버를 무작위로 망가트리겠다는 시험문제를 미리 유출하는 친절한 출제위원의 의도를 파악한다면 오히려 더 쉽고 명확해진다. 그렇게 방침(철학)이 결정되면 모든 서비스는 현실에서 발생할 수 있는 문제를 예측하고 대응하는 방향으로 발전한다. 따라서 운영환경에서 서버 인스턴스 일부가 무작위로 망가진다해도 서비스 전체는 오뚝이처럼 제자리로 돌아오도록 설계^[각주:2]할 수 있게 되는 것이다. 그러다보면 문제가 발생했을 때, 얼마의 시간이 걸리면 복구가 가능한 지 말할 수 있는 수준까지 된다.

서비스 서버 설계, 개발, 운영을 다년간 직접 해 본 경험으로 볼때 장애가 발생하면 주변에서 다음과 같은 질문들을 듣게된다. 원인이 무엇인가요? 사용자 영향은 얼마나 되나요? 어느 정도 걸리면 문제가 해결될까요? 라는 질문이었는데, 대부분의 담당자들은 즉답을 못했고 원인파악과 응급처치하느라 정신없었다.

그러나 내가 직접 담당했던 서비스는 이러한 상황을 미리 대비해서 이렇게 답변했다. "서버 한 대가 망가졌으면 연결된 세션(Session)이 몇 개이고 몇 명의 사용자가 순간적인 연결해제를 겪을 것입니다. 그러나 곧바로 다른 서버로 연결해서 작업을 이어갈 것입니다. 그리고 망가진 서버를 버리고 새로운 서버를 올리는 데 6분 정도 걸립니다. 오토스케일링(Auto-scaling) 에서 인스턴스를 새로 띄우는 시간이 대략 4-5분 정도이고 셰프(Chef) 레시피(Recipe)가 동작하는데 1분 정도 걸립니다. 또는 쿠버네티스(Kubernetes)에서 동작하는 스핀에커(Spinnaker)의 경우 컨테이너(Container)가 재시작하는데 10초 걸립니다."

카오스 엔지니어링은 불명확한 것을 줄이기 위한 방법이며 기술이다. 우리가 과학을 통해 자연의 법칙을 이해하고 그 것을 이용해서 건물을 올리거나 자동차를 만들어서 사용하는 것이 엔지니어링인 것처럼, 카오스 엔지니어링은 예측 불가능한 (서비스 운영) 환경을 예측 가능한 상황으로 만들기 위한 노력이라고 생각한다.

---

 

1. https://www.bloter.net/newsView/blt201207100011 [본문으로]
2. Resilience [본문으로]