카오스 엔지니어링: 프로덕션을 의도적으로 중단하기 (다시는 고장 나지 않도록)
Source: Dev.to
2 AM 페이지 스토리
오전 2시 7분입니다.
🚨 프로덕션 다운 – 높은 오류율
모든 체크리스트를 다 확인했고, 시스템은 “고가용성”이라고 했지만, 단 하나의 노드가 죽었습니다.
그날 밤은 고통스러운 진실을 가르쳐 줍니다: 문서상으로는 신뢰성 있어 보이는 시스템이라도 실제 장애 상황에서는 살아남지 못할 수 있다는 사실을.
Chaos Engineering이란?
Chaos Engineering은 시스템이 장애 상황에서 어떻게 동작하는지 배우기 위해 의도적으로 파괴하는 실천입니다.
쉽게 말해: 안전한 시간대에, 통제된 실패를 만들어서 2 AM에 프로덕션이 교훈을 주지 않게 합니다.
왜 존재하는가
- 현대 시스템은 분산되어 있다.
- 장애는 불가피하다.
- 사람은 엣지 케이스를 예측하기 어렵다.
Chaos Engineering은 현실을 받아들이고 싸우지 않습니다.
기존 테스트의 한계
| 기존 테스트는 …를 전제로 한다 | 현실은 …를 보여준다 |
|---|---|
| 의존성이 정상적으로 동작한다 | 데이터베이스가 느려지기도 하고, 단순히 다운되지 않는다 |
| 네트워크가 신뢰할 수 있다 | 네트워크는 거짓말을 하고, 지연이 급증한다 |
| 지연 시간이 예측 가능하다 | 서드파티 API가 무작위로 타임아웃한다 |
| 부분적인 장애는 연쇄되지 않는다 | 분산 시스템은 창의적인 방식으로 실패한다 |
대부분의 장애는 알 수 없는 알 수 없는(unknown unknowns) 에서 비롯되며, 이는 코드 버그가 아니라는 점을 보여줍니다. Chaos Engineering은 사용자가 겪기 전에 그 알 수 없는 상황들을 찾아냅니다.
“건강한” 시스템 정의
- 요청 성공률
- 지연 시간 퍼센타일
- 오류 예산
- 비즈니스 KPI
명확한 정상 상태 메트릭이 없으면, 눈을 가리고 무작위로 부수는 것과 다를 바 없습니다.
실제 장애 유형 (모의나 시뮬레이션이 아님)
- 파드(kill)
- 지연 추가
- 네트워크 호출 차단
- CPU 스로틀링
이들은 실제 트래픽, 실제 데이터, 실제 혼돈 속에서 프로덕션에서 수행됩니다—점진적으로, 안전한 시간대에, 롤백 플랜과 예정된 다운타임을 두고.
실험 예시
# Kill a pod
kubectl delete pod payment-service-xyz- 서비스 간에 500 ms 지연 추가
- 패킷 10 % 손실
노출되는 문제: 재시도 폭풍, 타임아웃 설정 오류, 데이터베이스 지연, Redis 가용성 상실, 서드파티 500 오류, CPU 스로틀링, 메모리 압박, 디스크 가득참 등.
Chaos 실험 수행 방법
- 핵심 서비스 선택
- 정상 상태 메트릭 정의 (성공률, 지연, 오류 예산)
- 비프로덕션에서 시작
- 단일 파드 삭제
- 모든 현상 관찰
- 약점 보완
- 반복 및 확장
- 트래픽이 적은 시간대에 프로덕션으로 이동
- 의존성에 지연 추가
- DB 느려짐 시뮬레이션
작고 통제된 혼돈이 전혀 없는 것보다 낫다.
흔히 쓰이는 Chaos 도구
- Chaos Monkey – 최초의 Chaos 도구
- LitmusChaos – 쿠버네티스 네이티브, 오픈소스
- Gremlin – 통제된 엔터프라이즈급 Chaos
- AWS FIS – AWS 네이티브 장애 주입
도구가 Chaos Engineering을 하는 것이 아니라, 사고방식이 합니다.
예시 시나리오 (Kubernetes + Spring Boot)
- 스택: Java Spring Boot 마이크로서비스, Kubernetes (EKS), HPA 활성화, Redis 캐시, PostgreSQL DB
- Chaos: 피크 트래픽 중에 파드 50 % 삭제
관찰된 장애:
- 커넥션 풀 고갈
- DB 재시도 폭주
- SLA 초과 지연 스파이크
- 회로 차단기 부재, 과도한 재시도, 잘못된 타임아웃 설정
추가된 완화 조치:
- Resilience4j (회로 차단기, 조정된 재시도 및 타임아웃)
- 개선된 readiness probe
결과: 시스템이 Chaos를 견뎌냈으며, 책임감 있게 적용하면 Chaos Engineering이 효과적임을 증명했습니다.
Chaos Engineering 원칙
- 가설 기반 – 정상 상태에 대한 명확한 가설부터 시작한다.
- 측정 기반 – 실험 전·중·후에 메트릭을 수집한다.
- 역전 가능 – 빠르게 롤백할 수 있도록 한다.
- 목적 있는 무작위성 – 단순히 “무작위 파괴”가 아니라 의미 있는 목적을 가진다.
탄탄한 모니터링, 쉬운 롤백, 오류 예산, 시스템을 이해하는 온콜 팀이 필요합니다. 관찰 가능성이 없으면 Chaos는 단지 잡음에 불과합니다.
기대 효과
- 프로덕션 장애 감소
- 사고 대응 속도 향상
- 배포 안전성 강화
- 시스템 설계 개선
- 온콜 엔지니어의 자신감 상승
“작동하길 바란다”는 기대를 버리고 그것이 작동한다는 것을 안다는 수준에 도달합니다.
시작하기
- 위험도가 낮은 대상 선택 (예: 비핵심 마이크로서비스)
- 정상 상태 메트릭 정의 (성공률, 지연, 오류 예산)
- 작은 실험 실행 (파드 하나 삭제, 지연 추가)
- 관찰·학습·반복
범위를 점진적으로 확대하고, 트래픽이 적은 시간대에 프로덕션 실험을 진행합니다.
마무리 생각
오늘 프로덕션 시스템에서 하나를 죽인다면, 가장 먼저 어떤 것이 망가질까요?
댓글에 생각, 전쟁 이야기, 혹은 의문을 남겨 주세요—다음에 페이지가 울리기 전에 서로 배워봅시다.