[keyword] 17장 - 카오스 공학

인스턴스를 죽인다는 생각은 과격해보일 수 있지만 미친 생각은 아니다. 이것이 카오스 공학이라고 불리는 새로 떠오르는 분야다. (중략) 아마도 가장 유명한 카오스 공학의 예는 넷플릭스의 카오스 멍키일 것이다. (p.442, 444)

실제 넷플릭스에 사례가 있어서 놀랐습니다. 운영 환경의 인스턴스를 한대 다운시킴에도 정상적으로 돌아가는지 안정성 테스트를 한다는 것 자체가, 개발 쪽에 투자를 많이 한다는 것으로 느껴졌어요. (보통은 비용절감을 위해 서버 대수를 최소화할 것이라 생각했어서요. ~그리고 처음에는 인스턴스 한대를 꺼버린다길래 뭐지...? 미친 사람인가? 싶었는데 ㅋㅋ~)

어떤 의미에서 넷플릭스는 카오스 멍키 도입이 쉬웠다. 넷플릭스의 고객은 영상이 처음에 잘 재생되지 않더라도 재생 버튼을 다시 누르는 데 익숙하다. 그들은 <기묘한 이야기> 의 결말을 잘라 먹는 것만 빼면 어떤 것도 용서할 것이다. 요청 하나하나의 가치가 대체불가능한 시스템에서는 카오스 공학이 적합한 방식은 아니다. (p.447)

카오스 공학이 꼭 정답은 아니라고 말해주는 키워드 같아서 적어봤습니다. 결국 상황에 맞는 안정성 테스트를 진행해야 한다! 고 읽혔어요.

각자의 서비스가 카오스 테스트를 견디지 못할 것 같으면 첫 회차는 제외시켜줄테니 연락을 달라고 이메일을 보냈다. 답장이 많이 오지는 않았다. (중략) 결국 한 주간 QA가 중단되었고 필자는 회사에서 일하는 모든 사람을 거의 다 만나게 되었다. 이 이야기의 교훈은, 카오스 공학은 새 동료와 만날 수 있는 가장 빠른 방법이지만 좋은 방법은 아니라는 것이다. (p.450)

선택적 참여, 선택적 제외 방식의 어마어마(?)한 차이에 대해 놀라게 된 포인트여서 적어봤습니다. 안정된 아키텍처를 지닌 회사가 아닌 경우, 선택적 제외 방식으로 카오스 공학을 적용하는 것은 조금 무리일 수도 있다고 생각이 들었습니다.

caffeine-library / release-everything

[keyword] 17장 - 카오스 공학 #48

주제

연관 챕터

47