9.6 카오스 엔지니어링과 복원력 테스트

개요와 동기

카오스 엔지니어링은 프로덕션의 격동하는 조건을 견디는 시스템의 능력에 대한 확신을 쌓으려고 시스템에 실험을 돌리는 규율 있는 실천입니다. 이름이 무모하게 들리며, 그것이 가장 먼저 잊어야 할 것입니다. 카오스 엔지니어링은 무작위로 부수고 무언가 배우기를 바라는 것이 아닙니다. 정반대입니다. 사용자가 발견하기 전에 약점을 발견하도록 현실적인 실패를 주입하는 통제되고 가설 주도적인 방법입니다. 시스템이 실패에 직면하리라는 것은 이미 압니다. 모든 실제 시스템이 그렇기 때문입니다. 유일한 질문은 롤백이 준비된 화요일 오후에 그 실패를 만나느냐, 무슨 일인지 전혀 모르는 채 가장 바쁜 시간의 새벽 3시에 만나느냐입니다.

큰 팀에게 이것이 중요한 이유는 복잡성이 누구든 검사로 추론할 수 있는 능력을 넘어섰기 때문입니다. 현대 서비스는 수십, 수백 개 구성 요소의 그물이며, 각각 자기 타임아웃, 재시도, 캐시, 실패 모드가 있고, 그 사이의 상호작용이 어떤 아키텍처 다이어그램도 예측하지 못하는 창발적 행동을 만듭니다. 코드를 리뷰하고, 상자를 그리고, 느린 의존성이 세 홉 떨어진 서비스를 무너뜨리는 재시도 폭풍을 촉발할 때 여전히 허를 찔릴 수 있습니다. 카오스 엔지니어링은 그 상호작용을 경험적으로 탐색하는 방법이며, 그래서 복원력은 가정하는 것이 아니라 검증한 것이 됩니다.

기업과 정부 맥락은 판돈을 올리고 점점 의무도 올립니다. 금융 규제 기관은 이제 기업이 심각하지만 그럴듯한 시나리오에 대해 운영 복원력을 테스트하고 중단을 거치며 핵심 서비스를 계속 돌릴 수 있음을 입증하기를 기대합니다. 정부 기관은 필수 공공 서비스가 장애, 재해, 사이버 공격을 살아남도록 업무 연속성 연습을 운영합니다. 두 세계 모두에서 “버틸 것 같다”는 감사자나 시민에게 받아들일 수 있는 답이 아닙니다. 카오스 엔지니어링은 증거를 줍니다. 이 장은 사이트 신뢰성 엔지니어링(9.1장)과 3.5장의 복원력 패턴 위에 서고, 인시던트 관리(9.3장) 및 재해 복구(9.5장)에 긴밀히 연결됩니다.

핵심 원칙

혼돈을 만들지 말고 확신을 쌓으십시오. 목표는 구경거리가 아니라 검증된 복원력입니다. 모든 실험은 시스템이 스트레스 아래서 어떻게 행동하는지에 대한 특정 질문에 답합니다.
정상 상태를 먼저 정의하십시오. “건강함”이 어떤 모습인지의 분명하고 측정 가능한 정의 없이는 문제를 탐지할 수 없습니다.
가설을 세우십시오. 결함을 주입하기 전에 무슨 일이 일어날지 진술하십시오. 놀람은 발견이고, 놀람이 없는 것도 발견입니다.
피해 범위를 최소화하고 가두십시오. 작게 시작하고, 실제 사용자를 보호하고, 확신이 커질 때만 범위를 넓히십시오.
신중하게 프로덕션을 선호하십시오. 실패는 실제 트래픽, 실제 데이터, 실제 규모 아래서 다르게 행동합니다. 거기서 테스트할 자격을 얻으십시오.
지속적 검증 쪽으로 자동화하십시오. 한 번 고친 약점은 회귀할 수 있습니다. 지속적으로 테스트되는 복원력이 참으로 유지됩니다.
실패는 판결이 아니라 스승입니다. 발견은 시스템을 개선합니다. 실험을 돌린 사람을 비난할 이유가 결코 아닙니다.

권장 사항

결함 하나를 주입하기 전에 전제 조건을 확립한다

카오스 엔지니어링은 성숙한 시스템에는 힘의 승수이고 미성숙한 시스템에는 부채입니다. 시작하기 전에 세 가지가 갖춰져 있어야 합니다. 첫째, 관측 가능성, 곧 바깥에서 시스템이 무엇을 하는지 보게 하는 지표, 로그, 트레이스입니다. 관찰할 수 없는 실험은 아무것도 가르쳐 주지 않기 때문입니다. 둘째, 성공한 실험과 해로운 실험을 실시간으로 구별할 수 있도록 서비스 수준 목표나 건강한 정상 상태의 동등한 정의(9.1장)입니다. 셋째, 실험이 실제 사용자를 위협하는 순간 멈추고 몇 초 안에 정상 서비스를 복원할 수 있는 빠르고 믿을 만한 롤백 또는 중단 경로입니다. 시스템을 측정하고, 그 건강한 상태를 정의하고, 벼랑에서 끌어올 수 없다면 아직 카오스 실험을 돌리지 마십시오. 그 역량을 먼저 구축하십시오. 어느 쪽이든 스스로 값을 합니다.

정상 상태를 정의하고 진짜 가설을 세운다

모든 실험은 정상이 측정 가능한 용어로 어떤 모습인지 적는 것으로 시작합니다. 요청 성공률 99.9퍼센트 이상, 결제 지연 95번째 백분위수에서 400밀리초 미만, 큐 깊이가 임계값 미만. 이것이 정상 상태 정의이며, 내부 배관이 아니라 사용자에게 보이는 건강을 반영해야 합니다. 그다음 가설을 쉬운 말로 진술하십시오. “추천 서비스에 300밀리초의 지연을 더하면, 페이지가 추천을 선택 사항으로 다루고 200밀리초 후 타임아웃하므로 제품 페이지는 여전히 지연 예산 안에서 렌더링될 것이다.” 이제 반증 가능한 주장이 생겼습니다. 실험을 돌리면 두 가지 좋은 일 중 하나가 일어납니다. 시스템이 예측대로 행동해 확신이 얻어지거나, 그렇지 않아 엔지니어가 지켜보는 가운데 여러분의 조건으로 싸게 실제 약점을 찾습니다.

임의의 것이 아니라 현실적인 결함을 주입한다

주입하는 결함은 시스템이 실제로 겪는 실패를 반영해야 합니다. 오류를 의도적으로 도입해 시스템이 어떻게 반응하는지 시험하는 결함 주입은 실제 프로덕션 인시던트에서 끌어온 메뉴를 줍니다. 느린 의존성이나 포화된 네트워크 링크를 시뮬레이션하려면 지연을 주입하십시오. 실패하는 하류 서비스를 시뮬레이션하려면 HTTP 500이나 연결 거부를 반환하는 오류를 주입하십시오. 압박 아래서 시스템이 어떻게 저하되는지 보려면 CPU, 메모리, 디스크, 파일 디스크립터를 소비하는 자원 고갈을 주입하십시오. 데이터베이스, 캐시, 큐, 제3자 API 전체를 닿을 수 없게 만들어 의존성 실패를 주입하십시오. 구성 요소가 별도 기계에서 돌며 신뢰할 수 없는 네트워크로 통신하는 분산 시스템에서 이런 것이 실제 장애를 지배하는 실패입니다. 실제로 일을 깨뜨리는 것은 깨끗한 충돌이 아니라 지연과 부분 실패이므로, 실험을 지저분한 중간 쪽으로 가중하십시오.

복원력 메커니즘이 실제로 동작함을 검증한다

여기서 카오스 엔지니어링이 값을 합니다. 시스템에는 여러분을 보호하기로 되어 있는 메커니즘이 가득합니다. 호출자가 영원히 기다리지 않게 하는 타임아웃, 일시적 깜빡임을 덮는 재시도, 실패하는 의존성을 두드리는 것을 멈추는 서킷 브레이커, 주 시스템이 죽으면 스탠바이로 전환하는 장애 조치입니다. 3.5장에서 다룬 이 패턴들이 갇힌 문제와 연쇄 장애의 차이입니다. 문제는 그것이 존재하는 조건에서 테스트되는 경우가 드물다는 것입니다. 호출자 자신의 마감이 2초인데 30초로 설정된 타임아웃은 아무것도 하지 않습니다. 백오프 없는 재시도는 힘겨워하는 서비스 하나를 몰려드는 떼로 바꿉니다. 한 번도 실행되지 않은 서킷 브레이커는 잘못 설정되어 결코 발동하지 않거나 끊임없이 발동할 수 있습니다. 카오스 실험은 이 각각이 막으려던 결함이 실제로 도착했을 때 설계대로 행동함을 확인하는 방법입니다. 테스트되지 않은 모든 안전 메커니즘은 실험이 아니라고 증명할 때까지 고장 난 것으로 가정하십시오.

자동화하기 전에 게임 데이로 시작한다

결함을 지속적으로 주입하는 자동화된 플랫폼으로 시작하지 마십시오. 게임 데이로 시작하십시오. 팀이 모여 시나리오를 고르고, 통제된 환경에 결함을 주입하고, 함께 지켜보는 예약된 실습입니다. 그보다 앞서, 시스템을 건드리지 않고 화이트보드 위에서 시나리오를 이야기하는 테이블탑 연습은 거의 위험 없이 런북, 알림, 소유권의 간극을 드러냅니다. 게임 데이는 진입로입니다. 가설을 세우고, 피해 범위를 가두고, 스트레스 아래의 시스템을 읽는 근육을 쌓고, 누구든 프로덕션에서 실험을 돌리게 하기 전에 필요한 리더십과 이웃 팀과의 신뢰를 쌓습니다. 또한 기술이 실제 인시던트 중 온콜 엔지니어가 쓰는 것과 같으므로 인시던트 대응을 직접 강화합니다(9.3장). 첫 게임 데이는 스테이징에서, 그다음 작은 피해 범위로 조용한 시간대의 프로덕션에서 돌린 뒤 확대하십시오.

피해 범위를 의도적으로 가둔다

가장 중요한 단일 안전 실천은 모든 실험의 잠재적 해악을 제한하는 것입니다. 무언가를 가르칠 수 있는 가장 작은 범위로 시작하십시오. 인스턴스 하나, 트래픽의 1퍼센트, 핵심이 아닌 의존성 하나, 가용 영역 하나입니다. 시작하기 전에 중단 조건을 정의하고, 정상 상태 지표에 연결하고, 실험 중단을 지켜보는 누구든 촉발할 수 있는 단일 행동으로 만드십시오. 팀이 깨어 있고 인력이 갖춰진 업무 시간에 돌리기를 선호하십시오. 놀람이 아무도 지켜보지 않는 인시던트가 되는 밤사이가 아니라. 더 작은 실험이 깨끗하게 돌았고 확신이 정말 높아졌을 때만 피해 범위를 넓히십시오. 가둠의 규율이 카오스 엔지니어링과 스스로 일으킨 장애를 가릅니다.

지속적이고 자동화된 복원력 검증 쪽으로 자란다

가끔의 게임 데이는 약점을 찾지만 시스템은 매일 바뀌고, 지난 분기의 수정은 조용히 회귀할 수 있습니다. 성숙한 최종 상태는 지속적 검증입니다. 파이프라인이나 일정에 따라 자동으로 돌아가는 선별된 복원력 실험 집합으로, 타임아웃, 재시도 정책, 장애 조치 경로의 회귀가 다음 실제 장애 중이 아니라 며칠 안에 잡힙니다. 프로덕션에서 인스턴스를 무작위로 종료해 엔지니어가 인스턴스 손실을 견디는 서비스를 만들도록 강제하는 Netflix의 카오스 몽키 같은 도구가 명성을 얻은 곳이 여기입니다. 수동 실행에서 이미 이해하고 신뢰하는 실험만 자동화하십시오. 미성숙한 시스템 위의 지속적 카오스는 확신이 아니라 인시던트를 생성하는 방법입니다.

실험을 재해 복구 및 인시던트 학습과 연결한다

카오스 엔지니어링은 홀로 살지 않습니다. 리전 전체 손실, 데이터베이스 장애 조치, 백업에서 복원 같은 더 크고 드문 시나리오는 재해 복구 테스트(9.5장)에 속하며, 게임 데이는 그 계획이 테스트되지 않은 문서로 썩는 것을 두는 대신 연습하기에 가장 좋은 수단인 경우가 많습니다. 다른 한편, 약점을 드러내는 모든 실험은 실제 인시던트와 같은 학습 루프(9.3장)에 공급되어야 합니다. 비난 없는 글, 추적되는 수정, 수정이 유지됨을 확인하는 후속 실험입니다. 카오스 발견, 재해 복구 훈련, 인시던트 회고가 모두 복원력 작업의 하나의 백로그로 흐르면 흩어진 일회성 연습 대신 복리의 수익을 얻습니다.

장단점

결정	장점	단점
프로덕션에서 테스트	실제 트래픽, 데이터, 규모. 발견이 참	가둠이 실패하면 사용자에 위험. 성숙도 필요
스테이징에서만 테스트	안전하고 판돈이 낮고 시작이 쉬움	실세계 행동을 놓침. 거짓 확신
수동 게임 데이	기술과 신뢰를 쌓음. 낮은 도구 비용	드묾. 발견이 눈에 띄지 않고 회귀할 수 있음
지속적 자동화된 카오스	회귀를 빨리 잡음. 확장됨	먼저 성숙한 도구와 관측 가능성 필요
넓은 피해 범위	큰 체계적 약점을 드러냄	높은 위험. 실수가 인시던트가 됨
좁은 피해 범위	안전하고 통제 가능	창발적인 서비스 간 실패를 놓칠 수 있음

중심 긴장은 현실성 대 안전입니다. 가장 원하는 발견은 프로덕션에서 나옵니다. 시스템이 실제 트래픽, 실제 데이터, 실제 규모를 맞닥뜨리는 유일한 곳이기 때문인데, 프로덕션은 정확히 잘못된 실험이 사용자를 해치는 곳이기도 합니다. 해결은 어느 한쪽을 고르는 것이 아닙니다. 점진적으로 프로덕션 쪽으로 나아가는 자격을 얻는 것입니다. 전제 조건을 입증하고, 스테이징에서 예행연습하고, 라이브 지표에 연결된 중단 조건과 함께 작고 잘 가둔 실험을 프로덕션에서 돌리고, 증거가 쌓일 때만 범위를 넓히십시오. 다른 반복되는 긴장인 수동 대 자동도 시간이 지나며 같은 방식으로 해결됩니다. 이해와 신뢰를 쌓도록 수동으로 시작한 뒤, 의존하게 된 실험을 자동화해 한 번 검증한 복원력이 검증된 채 유지되게 하십시오.

팀과 논의할 질문

카오스 실험을 돌릴 준비가 정말 되어 있으며, 어떻게 알겠습니까? 정교하게 들리니까 결함을 주입하고 싶어지지만, 관찰할 수 없고, 건강의 분명한 정의가 없고, 빠른 롤백이 없는 시스템에 대한 카오스 엔지니어링은 그저 스스로 일으킨 다운타임입니다. 이 논의에 정직한 증거를 가져오십시오. 요청 성공률과 지연을 실시간으로 볼 수 있는가, 합의된 정상 상태 정의가 있는가, 실험을 중단하고 몇 초 안에 복구할 수 있는가. 큰 팀에서 답은 서비스마다 다른 경우가 많으므로, 유용한 산출물은 서비스가 실험 자격을 얻기 전에 넘어야 하는 준비 기준입니다. 규제 환경에서 그 준비 기준은 감사자에게 보일 수 있는 통제 역할도 합니다. 정직한 답이 준비되지 않았다는 것이라면, 이번 분기에 할 수 있는 가장 가치 있는 카오스 작업은 준비되게 해 주는 관측 가능성과 롤백 역량을 구축하는 것입니다.
피해 범위 정책은 무엇이며, 누가 실험을 멈출 권한이 있습니까? 모든 카오스 실험은 실제 사용자에게 어느 정도 위험을 지며, 가치 있는 발견과 스스로 일으킨 인시던트의 차이는 얼마나 단단히 가뒀느냐입니다. 구체적 한도를 이야기하십시오. 트래픽의 얼마, 인스턴스 몇 개, 어느 환경, 하루 중 언제, 어떤 지표 임계값이 실행을 자동으로 중단하는지입니다. 각 실험을 누가 지켜보고 누가 단일 행동 킬 스위치를 쥐는지 미리 정하십시오. 아무도 빨리 멈출 수 없는 실험은 가둬진 것이 아니기 때문입니다. 큰 조직에서 이 정책이 많은 팀이 어느 한 팀도 실수로 공유 의존성을 무너뜨리지 않고 실험하게 해 줍니다. 답은 적히고, 영향받을 수 있는 서비스의 팀과 합의되고, 프로덕션에서 무엇이든 돌리기 위한 전제 조건으로 다뤄져야 합니다.
어떤 복원력 메커니즘이 우리를 보호한다고 믿으며, 실제로 테스트해 본 적이 있습니까? 대부분의 시스템에는 한 번 구성되고 존재 이유인 실패 아래서 실행된 적 없는 타임아웃, 재시도, 서킷 브레이커, 캐시, 장애 조치 경로가 가득합니다. 의존하는 메커니즘의 목록을 만든 뒤, 각각에 대해 실제 주입된 결함 아래서 동작함이 마지막으로 검증된 때를 물으십시오. 경쟁하는 고려는 시간입니다. 각 메커니즘을 검증하는 데는 엔지니어링 노력이 들고 기능 마감은 항상 있습니다. 그 반론에 맞서 반증을 가져오십시오. 동작하는 서킷 브레이커나 올바른 타임아웃이 가뒀을 과거 장애의 비용입니다. 답은 안심되는 가정된 보호 목록을 우선순위가 매겨진 실험 백로그로 바꿔야 하며, 실패가 가장 아플 메커니즘부터 시작합니다.
스테이징이 아니라 프로덕션에서 실험을 돌리기 전에 무엇이 참이어야 하며, 오늘 그 자격을 얻은 서비스는 어느 것입니까? 가장 원하는 발견은 프로덕션에서 나옵니다. 시스템이 실제 트래픽, 실제 데이터, 실제 규모를 만나는 유일한 곳이기 때문인데, 프로덕션은 잘못된 실험이 실제 사용자를 해치는 단 하나의 곳이기도 합니다. 큰 팀의 정직한 현실은 서비스마다 준비도 수준이 다르다는 것이므로, 일괄적인 “프로덕션 카오스 금지” 규칙은 최고의 학습을 낭비하고 일괄적인 “허용”은 스스로 일으킨 장애를 부릅니다. 서비스별로 증거를 가져오십시오. 관측 가능성의 품질, 정상 상태가 정의되고 알림 가능한지, 롤백이 얼마나 빠른지, 승격을 정당화할 깨끗한 스테이징 실험의 이력입니다. 기업과 정부 환경에서는 프로덕션 관문을 누가 승격을 승인하고 어떤 중단 조건이 라이브 지표에 연결되는지 이름 붙이는 문서화된 통제에 묶어, 감사자가 팀이 실제 사용자와 즉흥적으로 한 것이 아니라 의도적이고 증거 있는 결정을 보게 하십시오.
카오스 실험이 약점을 드러내면 그 발견은 어디로 가며, 손대지 않은 채 썩는 것을 어떻게 막습니까? 약점을 발견하지만 결코 고치지 않는 프로그램은 노력을 태우고, 신뢰를 침식하고, 실험이 연극이라고 사람들에게 가르치므로 없는 것보다 나쁩니다. 경쟁하는 압력은 항상 기능 로드맵입니다. 복원력 수정은 막았을 장애가 실제로 도착하기 전까지는 다음 릴리스만큼 급해 보이는 경우가 드뭅니다. 논의에 복원력 백로그의 현재 상태를 가져오십시오. 열려 있는 카오스 발견이 몇 개인지, 가장 오래된 것이 얼마나 되었는지, 실험, 재해 복구 훈련, 인시던트 회고의 발견이 하나의 공유 큐로 흐르는지 팀에 흩어지는지입니다. 누가 각 수정을 소유하고 누가 수정이 유지됨을 확인하는 후속 실험을 돌리는지 합의하십시오. 크거나 규제된 조직에서는 고정된 주기로 백로그를 리뷰하고 복원력 수정을 기능보다 우선시할 권한이 있는 포럼의 이름을 정하십시오. 아무도 닫을 책임이 없는 발견은 제거된 것이 아니라 단지 문서화된 위험이기 때문입니다.
실험 일부를 지속적 검증으로 자동화할 준비가 되어 있으며, 구체적으로 어느 것입니까? 가끔의 게임 데이는 약점을 찾지만 시스템은 매일 바뀌고 지난 분기의 수정은 조용히 회귀할 수 있으므로, 성숙한 최종 상태는 자동으로 돌아 며칠 안에 회귀를 잡는 선별된 실험 집합입니다. 위험은 너무 일찍 자동화하는 것입니다. 관측 가능성이 약한 미성숙한 시스템 위의 지속적 카오스는 통찰보다 빨리 인시던트를 생성합니다. 완전히 신뢰할 만큼 충분히 수동으로 돌려 본 실험의 목록, 무인으로 그것들을 다스릴 피해 범위 통제와 중단 조건, 아무도 지켜보지 않는 새벽 3시에 잘못 돌아가는 자동 실행을 잡을 모니터링을 가져오십시오. 큰 기업이나 공공 기관에서는 무인 결함 주입이 부르는 추가 정밀 검토를 저울질하십시오. 변경 관리 승인, 각 자동 실행이 남겨야 하는 감사 추적, 실제 인시던트와 겹치는 예약된 실험에 대한 분명한 책무입니다. 이미 이해하는 실험만 자동화하고, 나머지는 같은 신뢰를 얻을 때까지 수동으로 유지하십시오.

분야별 관점

스타트업. 속도와 생존이 지배하므로 카오스 플랫폼에는 아무것도 쓰지 마십시오. 실패가 정말 여러분을 죽일 단 하나의 의존성, 보통 결제, 인증, 주 데이터 저장소에 대해 스테이징에서 90분짜리 게임 데이 하나를 돌리십시오. 조잡한 프록시나 죽인 프로세스로 실패를 주입하고, 무엇이 깨지는지 보고, 빠진 타임아웃이나 대체 경로를 고치고, 넘어가십시오. 요점은 인력을 둘 수 없는 규율을 만드는 것이 아니라 고객이 겪기 전에 명백한 스스로 일으킨 장애를 싸게 잡는 것입니다.

소기업. 신뢰성 전문가도 빠듯한 예산도 없으니 복원력 테스트를 인력을 두는 프로그램이 아니라 주기적이고 의도적인 연습으로 다루십시오. 전담 플랫폼을 사는 대신 클라우드 제공자나 관리형 도구가 이미 포함한 결함 주입 기능에 기대고, 고객이 알아챌 소수의 의존성에 실험을 집중하십시오. 보험으로 구성하십시오. 백업이 복원되고 결제가 우아하게 저하됨을 확인하는 데 쓴 한나절이, 그렇지 않음을 증명하는 장애보다 훨씬 쌉니다.

대기업. 문제는 규모에서 공유 의존성에 대해 많은 팀을 조율하는 것이므로, 모든 팀이 프로덕션에서 돌리기 전에 넘어야 하는 준비 기준, 피해 범위 정책, 중단 조건 연결을 표준화하십시오. 카오스 발견, 재해 복구 훈련, 인시던트 회고를 분명한 소유권이 있는 하나의 복원력 백로그로 라우팅하고, 분기별 게임 데이와 선별된 자동 실험 집합으로 증거와 함께 운영 복원력 기대를 충족하십시오. 누가 공유 서비스에 영향을 줄 수 있는지 다스려, 어느 한 팀의 실험이 다른 팀이 의존하는 인프라를 무너뜨리지 않게 하십시오.

정부. 조달 규칙, 투명성, 공적 책임이 일을 형성합니다. 업무 연속성 의무가 어차피 정기 연습을 요구하는 경우가 많으므로, 아무도 열지 않는 바인더가 아니라 진짜 발견을 낳는 라이브 게임 데이로 돌리고, 모든 실험, 그 피해 범위, 결과의 감사 추적을 유지하십시오. 결함 주입 도구를 조달하는 곳에서는 보안 및 데이터 처리 규칙 안에 들어맞기를 요구하고, 시민 대면 서비스의 프로덕션 실험은 엄격히 가둬지고 승인된 기간에 남겨 두십시오. 카오스 프로그램이 생산하는 증거가 바로 감독 기관이나 감사자가 보고 싶어 하는 것입니다.

사례

스타트업. 열다섯 명의 스타트업이 소수의 서비스에서 웹 앱을 운영하며 제3자 결제 API에 의존합니다. 카오스 플랫폼에 쓸 시간이 없으므로 팀은 스테이징에서 90분짜리 게임 데이를 돌립니다. 가설을 세웁니다. 결제 API가 오류를 반환하기 시작하면 결제 화면이 충돌하지 않고 분명한 재시도 메시지를 보이고 주문을 큐에 넣어야 한다. 단순한 프록시로 500 응답을 주입하고, 클라이언트 호출에 타임아웃이 없어 프론트엔드가 무한정 멈추는 것을 발견합니다. 타임아웃과 친절한 대체 경로를 더하고, 실험을 다시 돌려 수정을 확인하고, 공유 문서에 두 문단짜리 메모를 씁니다. 총비용은 한나절과 고객이 겪기 전에 잡은 아주 실제의 버그 하나입니다.

기업. 한 글로벌 은행이 심각하지만 그럴듯한 시나리오에 대해 규제 기관에 운영 복원력을 입증해야 합니다. 신뢰성 팀이 분기별 게임 데이와 프로덕션의 자동 실험 집합으로 이루어진 프로그램을 운영합니다. 한 시나리오는 엄격히 가둔 피해 범위와 거래 성공률에 묶인 중단 조건으로, 트래픽이 적은 기간에 주 거래 데이터베이스를 스탠바이로 장애 조치합니다. 첫 실행이 하류 대사 서비스에 백오프 없는 재시도 정책이 있어 부하 급등을 일으켜, 복구가 재해 복구 계획(9.5장)의 복구 시간 목표를 훨씬 넘어 지연됨을 드러냅니다. 발견은 인시던트 회고와 같은 백로그로 가고, 재시도 정책은 지수 백오프로 고쳐지며, 후속 실험이 이제 장애 조치가 목표 안에 끝남을 확인합니다. 연습 전체가 규제 기관에 대한 증거가 됩니다.

정부. 시민 대면 급여 포털을 운영하는 한 국가 기관은 중단을 거치며 업무 연속성을 유지해야 합니다. 연속성 계획을 아무도 열지 않는 바인더로 다루는 대신, 기관은 연간 연속성 연습을 라이브 게임 데이로 돌립니다. 팀은 주 데이터 센터의 손실을 시뮬레이션하고 보조 사이트로의 장애 조치를 따라가며, 따로 신원 확인 의존성에 지연을 주입해 포털이 우아하게 저하되는지 봅니다. 테스트되지 않은 모니터링 간극이 온콜 팀이 신원 서비스가 느려지는 것을 보지 못하게 해 알림이 늦게 발동했음을 알게 됩니다. 기관은 관측 가능성 간극을 닫고, 런북을 갱신하고, 다음 해에 같은 연습을 예약해, 컴플라이언스 요건을 핵심 공공 서비스를 위한 진짜 테스트된 복원력으로 바꿉니다.

비즈니스 사례: 동기, ROI, TCO

카오스 엔지니어링의 수익은 일어나지 않는 장애에서 옵니다. 큰 서비스의 주요 장애 하나는 잃은 매출, 규제 과징금, 수습 노동, 서비스가 복구된 한참 뒤까지 남는 평판 손상으로 수만에서 수백만의 비용이 들 수 있습니다. 카오스 실험은 그 예측할 수 없고 비싼 놀람을, 엔지니어가 지켜보고 롤백이 준비된 채 여러분의 일정에 맞춰 고치는 싸고 예약된 발견으로 바꿉니다. 통제된 게임 데이 중에 깨진 타임아웃을 찾는 데는 한나절이 듭니다. 실제 인시던트 중에 찾으면 장애, 총동원의 허둥지둥, 사용자의 신뢰가 듭니다. 산수는 게임 데이 쪽으로 크게 기웁니다.

전제 조건이 갖춰지면 총소유비용은 소박합니다. 카오스 엔지니어링은 어차피 필요한 관측 가능성, 알림, 롤백 투자를 재사용하기 때문입니다. 정직한 비용은 실험을 돌리는 엔지니어링 시간, 결함을 주입하고 피해 범위를 가두는 약간의 도구, 리더십이 의도적으로 실패를 도입하는 것에 편안해지게 하는 문화적 작업입니다. 마지막이 진짜 장벽이며, 통과하는 길은 스테이징에서 시작해 돈이나 위험에 대응하는 발견을 보이고, 소수의 가둔 프로덕션 실험이 신뢰를 쌓게 하는 것입니다. 리더십을 설득하려면 카오스 엔지니어링을 측정할 수 있는 보험으로 구성하십시오. 최근 인시던트의 비용을 제시하고, 그중 어느 것을 복원력 실험이 잡았을지 보이고, 작게 시작해 스스로 입증할 때만 확대하는 프로그램을 제안하십시오. 규제 및 공공 부문 환경에서는 컴플라이언스 각도를 더하십시오. 운영 복원력 테스트와 연속성 연습이 점점 기대되며, 카오스 프로그램이 서류가 아니라 증거로 그 기대를 충족하는 방법이기 때문입니다.

안티패턴과 함정

관측 가능성 없는 카오스. 볼 수 없는 시스템에 결함을 주입하는 것은 추가 단계가 있는 짐작입니다. 해를 입히고 아무것도 배우지 못합니다.
정상 상태 정의 없음. 합의된 건강의 척도가 없으면 실험이 문제를 드러냈는지 일으켰는지 알 수 없습니다.
가설 없음. 무작위로 부수는 것은 카오스 엔지니어링이 아닙니다. 발견 없는 멋진 이름의 파괴 행위입니다.
가두지 않은 피해 범위. 작고 안전한 실험을 건너뛰고 곧장 프로덕션 전체 실패로 가면 테스트가 스스로 일으킨 장애가 됩니다.
중단 경로 없음. 즉시 멈출 수 없는 실험은 실험이 아니라 방아쇠를 기다리는 인시던트입니다.
너무 일찍 자동화. 미성숙한 시스템 위의 지속적 카오스는 통찰보다 빨리 인시던트를 생성합니다.
어디로도 가지 않는 발견. 약점을 발견하고 결코 고치지 않으면 연습이 낭비되고 프로그램 전체에 대한 신뢰가 침식됩니다.
나쁜 실험 뒤의 비난. 실제 결함을 드러낸 실험을 돌린 엔지니어를 벌하면 아무도 다음 실험을 돌리지 않는 것이 보장됩니다.

성숙도 모델

1단계, 시작: 복원력은 테스트되는 것이 아니라 가정됩니다. 실패는 실제 인시던트 중에 프로덕션에서 발견됩니다. 게임 데이도, 결함 주입도 없고, 건강이 어떤 모습인지의 분명한 정의도 없는 경우가 많습니다. 팀은 한 번에 한 장애씩, 어려운 방식으로 약점을 알게 됩니다.
2단계, 발전: 팀이 정의된 시나리오와 가설로 흔히 스테이징에서 가끔의 게임 데이를 돌립니다. 정상 상태가 몇몇 핵심 서비스에 정의되어 있고 기본적인 관측 가능성이 있습니다. 발견이 포착되고 일부가 고쳐지지만, 실천은 팀마다 일관되지 않고 확립된 방법이 아니라 개인 옹호자에 달려 있습니다.
3단계, 표준화: 카오스 실험이 문서화된 조직 전체의 실천이며, 서비스가 프로덕션에서 실험하기 전에 넘어야 하는 시행되는 피해 범위 정책, 중단 조건, 준비 기준이 있습니다. 실험은 통제된 조건에서 프로덕션에서 돌고, 발견은 인시던트 회고 및 재해 복구 훈련과 나란히 공유 복원력 백로그로 흐르며, 복원력 메커니즘은 가정되는 것이 아니라 검증됩니다. 모든 팀이 같은 플레이북을 따릅니다.
4단계, 관리: 프로그램이 기준선에 대해 데이터로 측정되고 통제됩니다. 복원력 커버리지(어느 핵심 서비스와 어느 메커니즘, 곧 타임아웃, 재시도, 서킷 브레이커, 장애 조치가 실제 주입된 결함 아래서, 얼마나 최근에 검증되었는지), 실험이 발견을 낳는 비율, 복원력 발견을 닫는 평균 시간, 이전에 검증된 메커니즘이 얼마나 자주 회귀하는지를 추적합니다. 이 지표는 고정된 주기로 리뷰되고, 프로덕션 승격은 의견이 아니라 증거로 관문 통제되며, 실험은 여전히 검증되지 않은 메커니즘의 측정된 위험으로 우선순위가 정해집니다.
5단계, 오케스트레이션: 선별된 실험 집합이 지속적으로 자동으로 돌아 며칠 안에 회귀를 잡고, 프로그램은 시스템과 위험 상황이 바뀜에 따라 적응합니다. 카오스 엔지니어링은 전달 파이프라인, 인시던트 학습, 재해 복구 테스트와 조직 전체에 통합되어, 새 서비스가 기본으로 복원력 검증을 물려받습니다. 복원력은 지속적으로 검증되는 시스템의 속성이며, 리더십은 프로그램을 특별한 이니셔티브가 아니라 증거로 다듬어지는 표준 위험 관리로 다룹니다.

논의를 위한 아이디어

조직에서 어느 서비스가 먼저 프로덕션에서 카오스 실험을 돌릴 자격을 얻는지 어떻게 결정하며, 그러려면 무엇이 참이어야 합니까?
카오스 실험이 심각한 약점을 드러내면 누가 수정을 소유하며, 그 발견이 백로그에 손대지 않은 채 있는 것을 어떻게 막습니까?
여러분의 맥락에서 카오스 실험, 재해 복구 훈련, 게임 데이의 선은 어디이며, 그 구별이 계획하는 방식에 정말 중요합니까?
프로덕션에 의도적으로 실패를 주입하는 것이 실제 장애를 기다리는 현상 유지보다 안전하다고 회의적인 경영진을 어떻게 설득하겠습니까?
팀이 다음 달 돌릴 수 있는 가장 작고 가장 가치 있는 첫 실험은 무엇이며, 무엇이 그것을 막겠습니까?
연속성 의무가 있는 시민 대면 공공 서비스와 사용자가 적은 내부 기업 도구 사이에서 복원력 테스트는 어떻게 달라야 합니까?

핵심 요점

카오스 엔지니어링은 무작위 파괴가 아니라 복원력에 대한 확신을 쌓는 규율 있고 가설 주도적인 실험입니다.
결함 하나를 주입하기 전에 관측 가능성, 정상 상태 정의, 빠른 롤백을 확립하십시오.
현실적인 결함(지연, 오류, 자원 고갈, 의존성 실패)을 주입해 타임아웃, 재시도, 서킷 브레이커, 장애 조치가 실제로 동작함을 검증하십시오.
테이블탑 연습과 게임 데이로 시작하고, 피해 범위를 의도적으로 가두고, 프로덕션과 자동화로 나아갈 자격을 얻으십시오.
발견이 하나의 복원력 백로그로 복리로 쌓이도록 실험을 재해 복구 테스트(9.5장) 및 인시던트 학습(9.3장)에 연결하십시오.
발견을 비난 없이 다루고 고치십시오. 교훈이 다뤄지지 않은 실험은 실험이 없는 것보다 나쁩니다.

참고 문헌과 더 읽을거리

Casey Rosenthal, Nora Jones, Chaos Engineering: System Resiliency in Practice
Russ Miles, Learning Chaos Engineering: Discovering and Overcoming System Weaknesses Through Experimentation
Mikolaj Pawlikowski, Chaos Engineering: Crash Test Your Applications
Ali Basiri et al., Chaos Engineering (IEEE Software, 2016)
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, Site Reliability Engineering: How Google Runs Production Systems
Michael T. Nygard, Release It! Design and Deploy Production-Ready Software
Principles of Chaos Engineering, principlesofchaos.org