Chaos Engineering
Chaos Engineering
시스템이 "잘 돌아가고 있다"는 건 장애가 없는 게 아니라 장애가 와도 버틸 수 있다는 뜻이다. Chaos Engineering은 그걸 미리 검증하는 방법이다.
한 줄 정의: 의도적으로 장애를 만들어서 시스템의 약점을 먼저 찾는 것
Netflix가 처음 만든 개념이다. 프로덕션 서버를 무작위로 죽이는 "Chaos Monkey"를 실제로 운영했고, 거기서 발전했다.
왜 하는가
테스트는 "예상한 시나리오"만 검증한다. 근데 실제 장애는 예상 밖에서 온다.
-
특정 서버가 갑자기 죽으면?
-
DB 응답이 10배 느려지면?
-
네트워크 패킷이 30% 손실되면?
이런 상황을 미리 만들어보면 시스템이 어떻게 반응하는지 알 수 있다. 모르는 채로 있다가 실제 장애 때 처음 보는 것보다 훨씬 낫다.
핵심 원칙
원칙 설명 가설 수립 "이게 죽어도 서비스는 정상이어야 한다"는 기대치를 먼저 정한다 최소 범위 영향 범위를 최대한 좁게 시작한다 (프로덕션 전체 X, 인스턴스 1개부터) 자동 중단 예상보다 피해가 커지면 즉시 중단할 수 있어야 한다 결과 분석 가설과 실제를 비교하고 약점을 문서화한다
실험 절차
-
정상 상태 정의: 지금 시스템의 정상 기준을 SLI로 정한다 (예: 에러율 < 1%)
-
가설 수립: "서버 1대가 죽어도 에러율 1% 미만이어야 한다"
-
실험 설계: 어떤 장애를 어떤 범위에서 주입할지 결정
-
실행: 장애 주입
-
관찰: 시스템이 가설대로 동작하는지 확인
-
복구 & 분석: 결과 기록, 약점 발견 시 개선
정상 상태 정의가 가장 먼저다. 지금 정상이 뭔지 알아야 가설을 세울 수 있기 때문이다.
대표 도구
도구 특징 Chaos Monkey Netflix 오픈소스, AWS EC2 인스턴스 랜덤 종료 Chaos Toolkit 오픈소스, 다양한 환경 지원 AWS Fault Injection Simulator AWS 관리형 서비스 Litmus Kubernetes 환경 특화
Game Day
Chaos Engineering을 팀 훈련으로 만든 것이 Game Day다.
정해진 날에 팀 전체가 모여서 의도적으로 장애를 내고, On-call 프로세스가 제대로 동작하는지 처음부터 끝까지 훈련한다. 알림이 제대로 오는지, Runbook대로 대응이 되는지, MTTA/MTTR이
목표치 안에 드는지 전부 확인한다.
정리
Chaos Engineering은 "장애가 안 나게 하는 것"이 아니라 "장애가 났을 때 시스템이 어떻게 반응하는지 미리 아는 것"이다.
일반 테스트가 예상한 시나리오를 검증한다면, Chaos Engineering은 예상 밖 상황을 검증한다. 둘은 대체 관계가 아니라 보완 관계다.
