2020.05.15

넷플릭스에 탄력성을 가져온 원숭이 부대 ‘카오스 몽키’ 알아보기

Scott Carey | InfoWorld
DVD 대여업을 하던 넷플릭스가 비디오 스트리밍을 위한 분산 클라우드 시스템으로 전환하던 시기에 처음 고안한 카오스 몽키(Chaos Monkey)는 이후 형태와 규모를 불문하고 모든 소프트웨어 개발 조직에 적용되는 엔지니어링 원칙으로 자리잡았다. 핵심 원리는 의도적으로 시스템에 장애를 일으킴으로써 시스템의 탄력성을 더 높일 방법을 알아낸다는 것이다.
 
2011년 7월, 당시 넷플릭스의 클라우드 및 시스템 인프라 책임자였던 유리 아즈라일레브스키와 클라우드 솔루션 책임자 아리엘 자이틀린이 처음 카오스 몽키를 주제로 올린 넷플릭스 블로그 글에 따르면 카오스 몽키는 아마존 웹 서비스 인프라의 프로덕션 인스턴스를 무작위로 마비시키도록 고안됐다. 그렇게 해서 약점이 노출되면 넷플릭스 엔지니어들이 더 나은 자동 복구 메커니즘을 구축해 이 약점을 없애도록 하는 것이 목적이었다.
 
블로그 글을 보면 카오스 몽키라는 재미있는 이름은 “무기를 든 야생 원숭이가 데이터센터(또는 클라우드 영역)에 들어와 무작위로 인스턴스를 파괴하고 케이블을 끊더라도 중단 없이 고객에게 서비스를 계속 제공한다는 개념”에서 유래됐다.
 
ⓒ Getty Images Bank


전 넷플릭스 엔지니어인 노라 존스와 케이시 로젠탈이 카오스 몽키를 주제로 써서 오라일리 미디어(O’Reilly Media)를 통해 출판한 책 '카오스 엔지니어링(Chaos Engineering)'에 의하면 실무에서 카오스 몽키는 간단한 애플리케이션이 “매일 각 클러스터에서 임의의 인스턴스를 선택해서 영업 시간 중 특정 시점에 경고 없이 이 인스턴스를 끄는” 방식으로 진행된다.
 
카오스 몽키의 개념은 가장 약한 부분이 어디인지 파악하면 엔지니어가 문제에 대처하는 자동화된 트리거를 설정할 수 있고 이를 통해 한밤중에 장애 발생으로 엔지니어가 호출될 일이 없다는 것이다. 이후 카오스 몽키는 카오스 엔지니어링이라는 이름 아래에 종합적인 카오스 원칙으로 발전했다.
 

넷플릭스의 카오스 몽키

카오스 몽키는 2010년을 전후해 넷플릭스 엔지니어링 과정에서 탄생했다. 현재는 마이크로소프트 소유의 깃허브에서 일하는 그레그 오젤은 당시 넷플릭스의 새로운 클라우드 기반 아키텍처에 탄력성을 구축하는 일을 맡았다.
 
오젤은 Inforworld와의 인터뷰에서 “카오스 몽키가 엔지니어링 측면의 큰 위업은 아니라고 생각한다. 그보다도 카오스 몽키의 가치는 DVD 대여업에서 인터넷을 통한 스트리밍으로 전환하던 당시 넷플릭스에 꼭 필요했던 사고방식의 변화를 가져왔다는 데 있다”고 말했다.
 
초창기에 넷플릭스 엔지니어들은 각각 특정 유형의 장애를 담당하는 오픈소스 툴의 이른바 “원숭이 부대(Simian Army)”를 사용해서 카오스 몽키가 AWS 클러스터를 중단시키는 것을 시작으로 시스템에 온갖 장애와 문제를 일으켰다.
 
지금은 새로운 툴에 밀려 대부분 퇴역했지만 첫 원숭이 부대에는 RESTful 클라이언트-서버 통신 계층에 인공적인 지연을 유발하는 레이턴시 몽키(Latency Monkey), 각 인스턴스에서 실행되고 다른 외부 상태 신호(예를 들어 CPU 부하)도 모니터링해서 비정상 인스턴스를 감지해 필요한 경우 서비스에서 제거하는 상태 확인에 개입하는 닥터 몽키(Doctor Monkey) 등이 포함됐다.
 
카오스 콩(Chaos Kong)은 카오스 몽키에서 한 단계 더 발전해서 전체 AWS 가용성 영역의 중단을 시뮬레이션했다. 2015년 넷플릭스 블로그에 따르면 “AWS 지역을 사용할 수 없게 되는 경우는 극히 드물지만 어쨌든 발생하는 일”이다.
 
글은 이어 “지역 단위의 중단을 시뮬레이션하는 실험을 정기적으로 실행함으로써 조기에 모든 시스템 약점을 파악해 수정할 수 있었다. US-EAST-1이 실제로 사용할 수 없게 되는 상황이 발생했을 때 넷플릭스 시스템은 충분히 견고했기 때문에 트래픽 페일오버를 원활하게 처리할 수 있었다”고 썼다.
 
존스와 로젠탈이 책에서 쓴 바와 같이 카오스 콩을 인프라에 풀어놓는 것은 스트리밍 서비스의 모든 측면을 모니터링하기 위해 소집된 ‘워룸’에서의 힘든 싸움이었으며 몇 시간 동안 지속됐다
 
2년 뒤인 2017년 7월, 넷플릭스는 카오스 오토메이션 플랫폼(Chaos Automation Platform: ChAP)을 공개했다. 블로그 글에 따르면 ChAP는 배포 파이프라인에서 사용자가 지정한 서비스를 확인한 다음 해당 서비스의 실험 및 제어 클러스터를 실행하고 각각에 소량의 트래픽을 라우팅한다.
 

카오스 엔지니어링 원칙

기초인 카오스 몽키 방식은 빠르게 발전해서 카오스 콩을 통해 점점 더 배포 규모를 키우고 나중에는 카오스 엔지니어링이라는 형식을 갖췄다. 넷플릭스는 2015년에 자체적인 공식 카오스 엔지니어링 팀을 구성했다. 이 팀의 리더는 현재 스티치 픽스(Stitch Fix)의 엔지니어링 책임자인 브루스 웡이었다.
 
카오스 몽키의 최초 고안자 중 몇 명이 정리한 카오스 엔지니어링 원칙은 “프로덕션 환경의 예측할 수 없는 상황에 버틸 수 있는 확고한 시스템 역량을 구축하기 위한 실험 방법”이다.
 
실무에서는 다음과 같은 4단계의 형식을 취한다.

1. 시스템의 “정상 상태”를 정의해 정상 동작의 기준선을 설정한다.
2. 대조군과 실험군 양쪽에서 모두 이 정상 상태가 계속된다는 가설을 세운다.
3. 서버 멈춤, 하드 드라이브 고장, 네트워크 연결 끊김과 같은 실제 상황을 반영하는 변수를 도입한다.
4. 대조군과 실험군 사이의 차이점을 확인해 가설이 틀렸음을 입증한다.
 
정상 상태를 무너뜨리기가 어렵다면 견고한 시스템이고, 약점이 있다면 찾아서 수정해야 한다.
 
존스와 로젠탈은 “원칙이 공개되고 5년 동안 카오스 엔지니어링은 발전을 거듭해 새로운 산업의 새로운 과제를 충족했다. 이 방법의 원칙과 기반은 소프트웨어 산업 전반에서, 그리고 새로운 분야로 도입이 확산됨에 따라 앞으로도 계속해서 발전할 것이 확실하다”고 말했다.
 

카오스 몽키를 사용한 카오스 엔지니어링

카오스 몽키의 오픈소스 버전을 시스템에서 실행하려면 깃허브에 있는 몇 가지 전제 조건을 충족해야 한다.
 
카오스 몽키는 서비스로 실행되지 않으므로 깃허브 페이지의 설명에 따라 크론(cron) 작업을 설정해야 한다. 이 작업이 매일 한 번씩 카오스 몽키를 호출해서 중단 일정을 생성한다.
 
이 버전의 카오스 몽키를 사용하려면 오픈소스인 넷플릭스의 지속적 제공 플랫폼인 스핀네이커(Spinnaker)를 사용해야 한다. 스핀네이커는 특정 조직에서 이 방법을 도입하는 역량을 제한할 수 있다. 또한 카오스 몽키를 사용하려면 버전 5.6 이상의 MySQL 호환 데이터베이스도 필요하다.
 
서비스 소유자가 스핀네이커를 통해 카오스 몽키 구성을 설정한다. 카오스 몽키는 스핀네이커를 통해 작동하면서 서비스가 어떻게 배포되었는지에 대한 정보를 입수하고 지정된 빈도와 일정에 따라 무작위로 인스턴스(가상 머신 또는 컨테이너)를 종료한다
 
물론 카오스 몽키 구현은 시스템 탄력성 문제를 해결하기 위한 어렵고 복잡한 작업의 시작일 뿐이다. 카오스 몽키는 시스템의 약점을 노출하는 역할만 하므로 이후 데브옵스 또는 시스템 엔지니어링 팀이 원인을 파악해 해결책을 마련해야 한다.
 
오젤은 “툴 자체는 비용이 많이 들지 않지만 툴에 대응하기 위한 투자에는 많은 비용이 든다”고 말했다. 또한 카오스 엔지니어링에 집중하기 위해서는 새로운 기능에 투입된 인력까지 빼서 탄력성 강화에 투입해야 한다. 오젤은 “이 스펙트럼에서의 위치는 기업마다 다르므로 각자가 적절히 결정해서 리소스를 늘리거나 줄여야 한다”고 말했다.
 
존스와 로젠탈은 초기 넷플릭스 엔지니어가 “특히 금융 기관으로부터 큰 반발에 직면했다”고 말했다.
 
은행의 경우 카오스 몽키가 미치는 파급력이 더 크지만 그래도 중단은 발생한다. 책은 “캐피털 원(Capital One)을 필두로 많은 금융 조직은 통제 불능의 대대적인 사고를 방지하기 위해 카오스 엔지니어링과 같은 선제적 전략을 신중하게 구현해서 위험을 파악함으로써 사고방식을 바꿨다”고 썼다.
 

카오스 엔지니어링 리소스

카오스 엔지니어링에 관한 최신 결정판은 위에서도 언급했듯이 전 넷플릭스 엔지니어인 노라 존스와 케이시 로젠탈이 2020년 4월에 출판한 카오스 엔지니어링이다. 2017년에 두 저자를 포함한 여러 저자들이 출판한 카오스 엔지니어링을 바탕으로 많은 부분이 추가됐다. 더 실무적인 개요서가 필요한 경우 러스 마일스가 쓴 카오스 엔지니어링 배우기(Learning Chaos Engineering)가 있다.
 
넷플릭스는 깃허브를 통해 튜토리얼, 문서, 오류 카운터, 중단 검사기, 암호 해독 툴을 포함한 풍부한 관련 리소스를 제공한다.
 
카오스 엔지니어링을 위한 상용 툴을 판매하는 그렘린(Gremlin)도 자체적으로 다양한 리소스를 제공한다. 그렘린의 리소스는 PDF 형식이며 온라인에서 무료로 받을 수 있다. 또한 그렘린은 카오스 콘프(Chaos Conf), 슬랙 채널을 포함한 다양한 커뮤니티 활동도 지원한다. editor@itworld.co.kr 


2020.05.15

넷플릭스에 탄력성을 가져온 원숭이 부대 ‘카오스 몽키’ 알아보기

Scott Carey | InfoWorld
DVD 대여업을 하던 넷플릭스가 비디오 스트리밍을 위한 분산 클라우드 시스템으로 전환하던 시기에 처음 고안한 카오스 몽키(Chaos Monkey)는 이후 형태와 규모를 불문하고 모든 소프트웨어 개발 조직에 적용되는 엔지니어링 원칙으로 자리잡았다. 핵심 원리는 의도적으로 시스템에 장애를 일으킴으로써 시스템의 탄력성을 더 높일 방법을 알아낸다는 것이다.
 
2011년 7월, 당시 넷플릭스의 클라우드 및 시스템 인프라 책임자였던 유리 아즈라일레브스키와 클라우드 솔루션 책임자 아리엘 자이틀린이 처음 카오스 몽키를 주제로 올린 넷플릭스 블로그 글에 따르면 카오스 몽키는 아마존 웹 서비스 인프라의 프로덕션 인스턴스를 무작위로 마비시키도록 고안됐다. 그렇게 해서 약점이 노출되면 넷플릭스 엔지니어들이 더 나은 자동 복구 메커니즘을 구축해 이 약점을 없애도록 하는 것이 목적이었다.
 
블로그 글을 보면 카오스 몽키라는 재미있는 이름은 “무기를 든 야생 원숭이가 데이터센터(또는 클라우드 영역)에 들어와 무작위로 인스턴스를 파괴하고 케이블을 끊더라도 중단 없이 고객에게 서비스를 계속 제공한다는 개념”에서 유래됐다.
 
ⓒ Getty Images Bank


전 넷플릭스 엔지니어인 노라 존스와 케이시 로젠탈이 카오스 몽키를 주제로 써서 오라일리 미디어(O’Reilly Media)를 통해 출판한 책 '카오스 엔지니어링(Chaos Engineering)'에 의하면 실무에서 카오스 몽키는 간단한 애플리케이션이 “매일 각 클러스터에서 임의의 인스턴스를 선택해서 영업 시간 중 특정 시점에 경고 없이 이 인스턴스를 끄는” 방식으로 진행된다.
 
카오스 몽키의 개념은 가장 약한 부분이 어디인지 파악하면 엔지니어가 문제에 대처하는 자동화된 트리거를 설정할 수 있고 이를 통해 한밤중에 장애 발생으로 엔지니어가 호출될 일이 없다는 것이다. 이후 카오스 몽키는 카오스 엔지니어링이라는 이름 아래에 종합적인 카오스 원칙으로 발전했다.
 

넷플릭스의 카오스 몽키

카오스 몽키는 2010년을 전후해 넷플릭스 엔지니어링 과정에서 탄생했다. 현재는 마이크로소프트 소유의 깃허브에서 일하는 그레그 오젤은 당시 넷플릭스의 새로운 클라우드 기반 아키텍처에 탄력성을 구축하는 일을 맡았다.
 
오젤은 Inforworld와의 인터뷰에서 “카오스 몽키가 엔지니어링 측면의 큰 위업은 아니라고 생각한다. 그보다도 카오스 몽키의 가치는 DVD 대여업에서 인터넷을 통한 스트리밍으로 전환하던 당시 넷플릭스에 꼭 필요했던 사고방식의 변화를 가져왔다는 데 있다”고 말했다.
 
초창기에 넷플릭스 엔지니어들은 각각 특정 유형의 장애를 담당하는 오픈소스 툴의 이른바 “원숭이 부대(Simian Army)”를 사용해서 카오스 몽키가 AWS 클러스터를 중단시키는 것을 시작으로 시스템에 온갖 장애와 문제를 일으켰다.
 
지금은 새로운 툴에 밀려 대부분 퇴역했지만 첫 원숭이 부대에는 RESTful 클라이언트-서버 통신 계층에 인공적인 지연을 유발하는 레이턴시 몽키(Latency Monkey), 각 인스턴스에서 실행되고 다른 외부 상태 신호(예를 들어 CPU 부하)도 모니터링해서 비정상 인스턴스를 감지해 필요한 경우 서비스에서 제거하는 상태 확인에 개입하는 닥터 몽키(Doctor Monkey) 등이 포함됐다.
 
카오스 콩(Chaos Kong)은 카오스 몽키에서 한 단계 더 발전해서 전체 AWS 가용성 영역의 중단을 시뮬레이션했다. 2015년 넷플릭스 블로그에 따르면 “AWS 지역을 사용할 수 없게 되는 경우는 극히 드물지만 어쨌든 발생하는 일”이다.
 
글은 이어 “지역 단위의 중단을 시뮬레이션하는 실험을 정기적으로 실행함으로써 조기에 모든 시스템 약점을 파악해 수정할 수 있었다. US-EAST-1이 실제로 사용할 수 없게 되는 상황이 발생했을 때 넷플릭스 시스템은 충분히 견고했기 때문에 트래픽 페일오버를 원활하게 처리할 수 있었다”고 썼다.
 
존스와 로젠탈이 책에서 쓴 바와 같이 카오스 콩을 인프라에 풀어놓는 것은 스트리밍 서비스의 모든 측면을 모니터링하기 위해 소집된 ‘워룸’에서의 힘든 싸움이었으며 몇 시간 동안 지속됐다
 
2년 뒤인 2017년 7월, 넷플릭스는 카오스 오토메이션 플랫폼(Chaos Automation Platform: ChAP)을 공개했다. 블로그 글에 따르면 ChAP는 배포 파이프라인에서 사용자가 지정한 서비스를 확인한 다음 해당 서비스의 실험 및 제어 클러스터를 실행하고 각각에 소량의 트래픽을 라우팅한다.
 

카오스 엔지니어링 원칙

기초인 카오스 몽키 방식은 빠르게 발전해서 카오스 콩을 통해 점점 더 배포 규모를 키우고 나중에는 카오스 엔지니어링이라는 형식을 갖췄다. 넷플릭스는 2015년에 자체적인 공식 카오스 엔지니어링 팀을 구성했다. 이 팀의 리더는 현재 스티치 픽스(Stitch Fix)의 엔지니어링 책임자인 브루스 웡이었다.
 
카오스 몽키의 최초 고안자 중 몇 명이 정리한 카오스 엔지니어링 원칙은 “프로덕션 환경의 예측할 수 없는 상황에 버틸 수 있는 확고한 시스템 역량을 구축하기 위한 실험 방법”이다.
 
실무에서는 다음과 같은 4단계의 형식을 취한다.

1. 시스템의 “정상 상태”를 정의해 정상 동작의 기준선을 설정한다.
2. 대조군과 실험군 양쪽에서 모두 이 정상 상태가 계속된다는 가설을 세운다.
3. 서버 멈춤, 하드 드라이브 고장, 네트워크 연결 끊김과 같은 실제 상황을 반영하는 변수를 도입한다.
4. 대조군과 실험군 사이의 차이점을 확인해 가설이 틀렸음을 입증한다.
 
정상 상태를 무너뜨리기가 어렵다면 견고한 시스템이고, 약점이 있다면 찾아서 수정해야 한다.
 
존스와 로젠탈은 “원칙이 공개되고 5년 동안 카오스 엔지니어링은 발전을 거듭해 새로운 산업의 새로운 과제를 충족했다. 이 방법의 원칙과 기반은 소프트웨어 산업 전반에서, 그리고 새로운 분야로 도입이 확산됨에 따라 앞으로도 계속해서 발전할 것이 확실하다”고 말했다.
 

카오스 몽키를 사용한 카오스 엔지니어링

카오스 몽키의 오픈소스 버전을 시스템에서 실행하려면 깃허브에 있는 몇 가지 전제 조건을 충족해야 한다.
 
카오스 몽키는 서비스로 실행되지 않으므로 깃허브 페이지의 설명에 따라 크론(cron) 작업을 설정해야 한다. 이 작업이 매일 한 번씩 카오스 몽키를 호출해서 중단 일정을 생성한다.
 
이 버전의 카오스 몽키를 사용하려면 오픈소스인 넷플릭스의 지속적 제공 플랫폼인 스핀네이커(Spinnaker)를 사용해야 한다. 스핀네이커는 특정 조직에서 이 방법을 도입하는 역량을 제한할 수 있다. 또한 카오스 몽키를 사용하려면 버전 5.6 이상의 MySQL 호환 데이터베이스도 필요하다.
 
서비스 소유자가 스핀네이커를 통해 카오스 몽키 구성을 설정한다. 카오스 몽키는 스핀네이커를 통해 작동하면서 서비스가 어떻게 배포되었는지에 대한 정보를 입수하고 지정된 빈도와 일정에 따라 무작위로 인스턴스(가상 머신 또는 컨테이너)를 종료한다
 
물론 카오스 몽키 구현은 시스템 탄력성 문제를 해결하기 위한 어렵고 복잡한 작업의 시작일 뿐이다. 카오스 몽키는 시스템의 약점을 노출하는 역할만 하므로 이후 데브옵스 또는 시스템 엔지니어링 팀이 원인을 파악해 해결책을 마련해야 한다.
 
오젤은 “툴 자체는 비용이 많이 들지 않지만 툴에 대응하기 위한 투자에는 많은 비용이 든다”고 말했다. 또한 카오스 엔지니어링에 집중하기 위해서는 새로운 기능에 투입된 인력까지 빼서 탄력성 강화에 투입해야 한다. 오젤은 “이 스펙트럼에서의 위치는 기업마다 다르므로 각자가 적절히 결정해서 리소스를 늘리거나 줄여야 한다”고 말했다.
 
존스와 로젠탈은 초기 넷플릭스 엔지니어가 “특히 금융 기관으로부터 큰 반발에 직면했다”고 말했다.
 
은행의 경우 카오스 몽키가 미치는 파급력이 더 크지만 그래도 중단은 발생한다. 책은 “캐피털 원(Capital One)을 필두로 많은 금융 조직은 통제 불능의 대대적인 사고를 방지하기 위해 카오스 엔지니어링과 같은 선제적 전략을 신중하게 구현해서 위험을 파악함으로써 사고방식을 바꿨다”고 썼다.
 

카오스 엔지니어링 리소스

카오스 엔지니어링에 관한 최신 결정판은 위에서도 언급했듯이 전 넷플릭스 엔지니어인 노라 존스와 케이시 로젠탈이 2020년 4월에 출판한 카오스 엔지니어링이다. 2017년에 두 저자를 포함한 여러 저자들이 출판한 카오스 엔지니어링을 바탕으로 많은 부분이 추가됐다. 더 실무적인 개요서가 필요한 경우 러스 마일스가 쓴 카오스 엔지니어링 배우기(Learning Chaos Engineering)가 있다.
 
넷플릭스는 깃허브를 통해 튜토리얼, 문서, 오류 카운터, 중단 검사기, 암호 해독 툴을 포함한 풍부한 관련 리소스를 제공한다.
 
카오스 엔지니어링을 위한 상용 툴을 판매하는 그렘린(Gremlin)도 자체적으로 다양한 리소스를 제공한다. 그렘린의 리소스는 PDF 형식이며 온라인에서 무료로 받을 수 있다. 또한 그렘린은 카오스 콘프(Chaos Conf), 슬랙 채널을 포함한 다양한 커뮤니티 활동도 지원한다. editor@itworld.co.kr 


X