‘일부러 먹통내라’ 카오스 엔지니어링 접근법 따라잡기

일반적인 통념은 '고장 난 게 아니라면 아무것도 건들지 마라'라고 말한다. 하지만 카오스 엔지니어링은 '어떻게 되는지 봐야 하니 여기저기 고장내뜨려 보자'라는 역발상으로 중단 사태에 대비한다.
 

온라인 그룹 카오스 커뮤니티(Chaos Community)는 카오스 엔지니어링을 "격변하는 생산 환경에서 시스템이 어떠한 위기 상황도 견뎌낼 수 있는지 확인하기 위해 실험하는 분야"라고 정의한다.

카오스 엔지니어링에서는 기본적으로 시스템에 압박 테스트를 시행한 후 발생하리라고 예상한 결과와 실제로 발생한 결과를 비교한다. 목표는 회복탄력성 개선이다. 

커리어 내내 네트워크 유지에 전념해온 실무자들에 네트워크를 일부러 중단한다는 개념은 약간 미친 짓처럼 느껴질 수 있다.
 

카오스 엔지니어링이 필요한 이유 

포레스트 리서치 선임 애널리스트 데이빗 무터는 멀티클라우드 플랫폼에 걸쳐 네트워크가 분산되어 있고 사이버공격이 빈번해지는 환경에서 카오스 엔지니어링이 효과적인 대비책이라고 주장했다.

무터는 "분산화된 시스템이 완전히 이해하기에 너무 복잡하다는 점이 문제다. 시스템이 전혀 예기치 못한 문제를 일으킬 가능성이 다분하다. 그래서 현대 네트워크 시스템의 모든 회복탄력성 개선 작업은 예측불가능성을 기본으로 깔고 가야한다"라고 말했다.
 
사고 관리 소프트웨어 제공업체 젤리(Jeli)의 창립자 겸 CEO이자, 넷플릭스에서 근무하며 네트워크 카오스 엔지니어링을 개척했던 노라 존스는 "네트워크는 한 번 구축해놓고 방치해놓을 수 있는 시스템이 아니다"라고 덧붙였다.

존스는 "네트워크를 테스트한다는 개념은 CPU나 그 밖의 모든 시스템과 같아야 한다. 위험한 사건을 시뮬레이션하고, 미지의 위험을 드러내야 한다"라고 설명했다. 카오스 엔지니어링은 연속 인증 개념, 즉, 어떤 것도 100% 안정적일 수 없으며 한 순간에 무너질 수 있다는 전제를 한다. 그는 카오스 엔지니어링이 "궁지에 빠지지 않기 위한 끝없는 싸움이며 운영 접근 방법에 있어 사고방식의 변화를 요구한다"라고 덧붙였다.
 

카오스 엔지니어링 실험 사례

무터는 함께 일했던 회사가 실시한 카오스 실험 사례를 소개했다. 바로 포트를 일부로 잘못 구성하는 실험이었다. "실험의 목표는 포트가 잘못 구성됐을 때 방화벽이 탐지해 차단한 후, 이를 즉시 기록해 보안팀에게 안정적으로 알릴 수 있는지 확인하는 것이었다"라고 그는 설명했다.
 
카오스 실험은 잘못 구성된 포트를 생산 환경 내에 주기적으로 도입하는 방식으로 실시됐다. 절반의 경우 방화벽이 예상대로 행동했지만 나머지 경우 포트를 차단하지 못했다. 단, 보조 클라우드 구성 도구는 포트를 완벽하게 차단했다. 

무터는 "이 보조 도구가 보안팀에게 알림을 전달하지 않았다는 점이 문제였다. 결과적으로 이 실험 덕분에 방화벽의 결함뿐만 아니라 보안 팀의 사건 탐지 및 대응 절차에 숨겨져 있던 결함도 발견했다"라고 설명했다. 
 

이상해 보여도 다 이유가 있다

만약 카오스 엔지니어링이 네트워크 또는 보안 팀이 몰랐던 결함을 무작위로 발생시켜 실제로 생산 네트워크를 중단시키거나 성능 문제를 일으킨다면 쓸모가 없을 것이다.

카오스 엔지니어링의 방법론은 매우 구체적이다. 무터는 무엇보다 카오스 엔지니어링이 주로 수행되는 장소는 비생산 환경이라고 말했다.

그는 "무작위로 고장을 내는 것이 아니라 용납할 수 없는 위험 상황을 미리 판단한다. 그 위험에 대한 가설을 세우고 그 가설이 참인지 아닌지 확인할 카오스 실험을 실시한다"라고 설명했다.
 
무터는 이어 "테스트군과 대조군을 두어야 한다. 그래야 뭔가 잘못되었을 때 그 원인이 테스트군에 주입한 결함 때문이지, 테스트군과 무관한데 실험을 실시할 때 우연히 동시에 일어난 어떤 다른 요인 때문인지 확인할 수 있다"라고 덧붙였다. 

그는 과학 실험과 마찬가지로 가설이 반증될 수 있어야 한다고 강조했다. 그는 "실험을 하고 그 실험이 성공할 때마다 내 가설이 정확하다는 자신감이 커진다"라면서 "만일 실험이 실패하더라도 잘못된 가정을 바로잡을 기회와 시스템에 관한 새로운 정보를 발견한 셈이다"라고 말했다.

카오스 실험의 대표적인 장점은 실제로 어떤 문제가 비즈니스에 큰 영향을 미치기 전에 문제를 찾아 낸다는 점이다. 무터는 "결제 서비스를 중단시킬 수 있지만 아직 잘 알려지지 않은 문제가 있다고 해보자. 그 취약점을 통제된 (비생산) 환경에서, 즉, 결함을 즉시 차단할 수 있는 곳에서 사람들이 상황을 적극적으로 모니터링할 때 발견하고 싶은가, 아니면 핵심 운영 직원이 우연히 휴가 중인 금요일 저녁에 예기치 않게 발생하면 좋겠는가?"라며 되물었다. 
 

카오스 엔지니어링 활용 시 최선의 방책

기업들이 카오스 엔지니어링 실험을 할 때 적용할 수 있는 최선의 방책이 여럿 있다.

애플리케이션 개발자 참여시키기: 무터는 "복잡한 분산 아키텍처가 있을 때 개발자들은 애플리케이션의 한계에 대해 좋은 직감을 갖추기 어렵다. 카오스 엔지니어링이 소프트웨어 개발 및 테스트 과정의 일부가 되면 개발자들은 자신의 코드에서 미처 생각하지 못했던 오류를 더 많이 발견하게 된다. 이를 통해 애초부터 본인의 가정에 의문을 제기하는 습관이 생긴다"라고 말했다.

의사소통 개선하기: 존스는 넷플릭스에서 회사가 카오스 엔지니어링 도구를 직접 구축한 후 나중에 오픈소스화 했다고 전했다.  그는 카오스 엔지니어링의 핵심은 "엔지니어들이 회복탄력성 있는 시스템을 구축하도록 반강제적인 시스템을 만들려는 것이었다"라며 "다들 언제든지 서버가 중단될 위험이 있다는 점을 알았다. 시스템은 모든 예기치 못한 상황을 처리할 수 있어야 했다"라고 말했다. 또한 그는 "이런 일이 일어날 때 올바른 당사자와 소통하는 방법을 직원들이 알아야 한다"라고 말했다.

올바른 실험 고르기: 카오스 엔지니어링 도구 및 지원 서비스 제공업체 하니스(Harness)의 엔지니어링 책임자 우마 무카라는 카오스 실험이 "오늘날 복잡한 분산 시스템에 예기치 못한 가동 중단 사태가 일어난 상황을 모델링하여 테스트할 목적으로 가장 널리 사용되는 테스트라고 해도 무방하다"라고 말했다. 무라카는 기업들이 카오스 엔지니어링을 두 가지 서비스 사이의 네트워크 지연을 검증하고 코드 내 회복탄력성 메커니즘 확인하는 데 사용할 수 있다고 설명했다. 또한 업스트림 의존성에 미치는 영향을 파악할 목적으로 서비스 통화에 트래픽 추가, 애플리케이션이나 서비스의 회복 탄력성을 파악할 목적으로 네트워크 스트림 내에 패킷 손상 도입 등과 같은 구체적인 실험 용도로 활용할 수 있다고 말했다.

보안 팀을 의사소통에 포함시키기: 무터는 카오스 엔지니어링을 네트워크 보안을 포함한 모든 복잡한 분산 시스템에 적용할 수 있다면서 "보안에 대한 카오스 엔지니어링의 사고방식은 아무리 완벽해지려고 노력해도 보안 통제장치는 언젠가 실패할 것이라 가정하는 것이다"라고 말했다. 일례로, 한 은행은 측정 중인 지표를 바꿀 목적으로 카오스 엔지니어링을 활용했다. 덕분에 아무런 사태가 발생하지 않는 시스템을 하염없이 모니터링 하는 대신 어떤 보안장치가 실제로 위기에 효과적으로 대응하는지 확인할 수 있었다고 무터는 전했다. 

카오스 제어 요령

카오스 엔지니어링 실험은 서버가 한가할 때뿐만 아니라 분주할 때도 실시될 수 있다. 잘못하면 실제로 네트워크를 중단시키는 불상사가 일어날지 모르는 일이다. 다음 지침을 따르는 것이 중요한 이유다.

시험의 한계를 설정하라 
존스는 "모든 엔지니어가 고장을 내며 돌아다니도록 방임해서는 안 된다. 카오스 엔지니어링은 일종의 단련법이다. 좀더 구체적으로는 도구보다 단련법에 가깝다. 따라서, 카오스 엔지니어링의 효과를 보려면 적절한 심리적 안전 및 학습 문화를 전파하는 것이 먼저다다"라고 강조했다.

기존 사고 대응 시스템을 참고하라 
카오스 엔지니어링으로 미래에 일어날 지도 모르는 사건에 대비하기 전, 사실 더 먼저 해야 할 것은 과거의 교훈부터 먼저 확인하는 것이라고 존스는 말했다. 그는 "카오스 엔지니어링을 고려하고 있는 기업이라면 이미 중단 사태를 여럿 겪었을 가능성이 높다. 이 경험에서 얻은 교훈을 체화하는 것이 먼저다"라고 당부했다. 

언제든지 코드 뽑을 준비를 해라 
무터는 필요 시 카오스 활동을 즉시 중단할 수 있는 수단이 있어야 한다고 강조했다. 특히 이를 자동화하면 더욱더 효과적이라고 그는 덧붙였다. 그는 "모든 카오스 실험은 뭔가 잘못될 경우 피해 범위를 최소화하도록 설계되어야 한다"라며 "이는 인프라 계층, 애플리케이션 계층, 또는 비즈니스 계층에서 있을 수 있다. 예를 들어, 인프라 계층에서는 결함을 한정된 연결로 분리해놔야 한다"라고 설명했다. 

카오스 팀과 개발팀을 연합하라 
무터는 "중앙집중화된 카오스 엔지니어링 팀은 규모를 확장하기 어렵다. 따라서 서버 애플리케이션 개발팀을 카오스 실험에 참여시켜야 한다. 관여하지 않으면 회복탄력성에 대해 배울 기회를 갖지 못할 것이다. 카오스 엔지니어링 문화를 도입하는 의미가 없어질 것"이라면서 카오스 팀과 개발팀을 별개로 보는 이분법적 사고를 버려야 한다고 조언했다. 

그는 "일례로, 과거에 한 소프트웨어 회사에서 개발팀은 인프라 팀이 디스크 공간을 충분히 제공하지 않는다며 비난하고, 인프라 팀은 이에 맞서 개발자들이 왜 그렇게 비효율적인 코드를 작성했느냐고 지적했다"라고 말했다. 

회사가 진정한 카오스 엔지니어링 사고방식을 받아들인 뒤에는 디스크 공간이 부족한 원인에 대해 손가락질 하는 대신 공간이 부족할 때도 최대한 시스템을 매끄럽게 구동하는 방식을 같이 모색했다고 무터는 전했다.  

실험실 같은 문화를 조성하라 
무카라는 카오스 엔지니어링을 활용하려는 기업은 일단 과학 실험실 같은 문화와 분위기를 갖춰야 한다고 말했다. 
그는 "그 어떤 시스템도 완벽할 수는 없다. 하지만 여전히 고객은 시스템이 항상 가동되길 원하며, 이런 기대에 부응하기 위해서는 오랜 기간에 걸친 끈질긴 실험으로 시스템의 다양한 상황에서 어떻게 반응하는지 속속들이 파악해야만 한다"라고 말했다. 

결과를 공유하고 보여줘라     
무카라는 "개선점을 발견할 때마다 실험 결과를 이해관계자에게 공유하면 지지를 얻을 수 있다"라고 말했다. 예를 들어 제품 관리 임원진에 시스템이 어떤 고장 유형에 대비되어 있는지, 회복탄력성 메커니즘은 어떤 식으로 테스트했는지 보고하는 식이다. 무라카는 "이렇게 정보를 공유하면 제품 관리 팀은 시스템의 가용성에 대한 확신을 얻게 되며, 어떤 고장 유형에 취약한지도 미리 인지할 수 있다"라고 설명했다. 

예를 들면, 시스템을 어떤 고장 모드에 대해 보호하는지, 회복탄력성 메커니즘은 어떻게 성공적으로 테스트했는지를 제품 관리 지도부에 보고한다. 무라카는 "이를 통해 제품 관리 지도부는 시스템과 시스템이 유지해야 하는 가용성을 이해함에 있어 확신을 얻게 된다. 시스템이 어떤 고장 모드에 취약한지를 알려 줄 수도 있다. 그러면 최소한 관리자는 이런 위험이 발생할 가능성을 염두에 두고 제품을 운영하게 된다"라고 말했다. ciokr@idg.co.kr