Chaos Engineering & Fault Injection

1. Overview

카오스 엔지니어링과 결함 주입(Chaos Engineering & Fault Injection)은 "장애는 막을 수 없다"는 분산 시스템의 절망적인 전제를 인정하고, 실전에서 진짜 장애가 터지기 전에 일부러 서버에 불을 질러 방어 시스템이 제대로 작동하는지 검증하는 넷플릭스 발(發) 궁극의 예방 의학을 해부합니다.

학습자는 멀쩡히 돌아가는 프로덕션 서버의 랜선을 무작위로 뽑아버리는 **카오스 몽키(Chaos Monkey)**의 충격적인 철학을 뜯어보고, 이것이 무책임한 테러가 아니라 철저히 통제된 '폭발 반경(Blast Radius)' 안에서 시스템의 취약점을 백신처럼 찾아내는 고도의 과학적 실험임을 이해합니다. 나아가 하위 마이크로서비스가 죽었을 때 내 서비스까지 연쇄적으로 무너지는(Cascading Failure) 참사를 물리적으로 차단하는 서킷 브레이커(Circuit Breaker) 패턴을 장악합니다. 마지막으로, 타임아웃(Timeout)과 지연 주입(Latency Injection)을 통해 느린 응답이 차라리 500 에러보다 전체 시스템을 더 악독하게 파괴한다는 비동기 병목의 심연을 지배하는 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Chaos Engineering (카오스 엔지니어링): 가설 수립, 폭발 반경 제어, 정상 상태(Steady State) 모니터링, 카오스 몽키.
• Fault Injection (결함 주입): 패킷 드롭(Packet Drop), 지연 주입(Latency Injection), 프로세스 킬(Kill).
• Cascading Failures (연쇄 장애): 마이크로서비스 간 장애 전파 메커니즘.
• Circuit Breaker Pattern (서킷 브레이커): 장애를 감지하고 회로를 차단해(Open) 호출(Call) 자체를 튕겨내는 Fail-fast 방어막.

Out-of-Scope

• AWS Fault Injection Simulator (FIS) 튜닝: 특정 클라우드 툴의 사용법 → 클라우드 벤더 매뉴얼 영역으로 위임.
• 분산 트랜잭션 롤백(Saga): 상태 불일치 해결 로직 → 07-02-04 Distributed Transactions 영역.

Boundaries

• Testing vs Chaos Engineering: '테스트(QA/Unit Test)'는 코드가 잘 짜였는지(Known Properties) 확인하기 위해 로컬이나 개발 환경에서 수행하는 작업입니다. 반면 '카오스 엔지니어링'은 완벽하게 짠 코드라도 "운영 서버의 A 가용 영역(AZ) 전체가 정전되면 트래픽이 B로 넘어가는가?(Unknown Properties)"를 실험하기 위해, 실제 프로덕션(운영) 환경 혹은 그와 $100\%$ 동일한 환경에서 수행하는 생존 훈련임을 명확히 구분합니다.

3. Counterexample

• 느린 응답의 공포 (The Latency Death): 주문 서비스가 결제 API를 호출합니다. 결제 서버가 뻗어서 'Connection Refused(즉각 에러)'를 뱉으면 주문 서버는 바로 "결제 실패"를 유저에게 띄우고 스레드를 반납합니다. 그런데 만약 결제 서버가 죽진 않았는데 응답을 '30초' 동안 안 주고 버티면(Latency)? 주문 서버의 스레드 100개가 모두 결제를 기다리다 30초 동안 기절(Block)하고, 결국 주문 서버까지 메모리 터져서 연쇄 사망(Cascading Failure)합니다. 차라리 빠르고 시원하게 죽는 게(Fail-fast) 느리게 앓는 것보다 100배 낫다는 분산 시스템의 진리를 무시한 안티 패턴입니다.
• 통제 불능의 카오스 몽키: "카오스 엔지니어링이 유행이래!"라며 주니어 개발자가 금요일 오후 3시에 프로덕션 RDBMS 마스터 노드의 프로세스를 강제로 킬(Kill)해버립니다. 회사의 결제가 마비되고 주말 내내 복구 작업을 합니다. 카오스 엔지니어링은 무작정 폭탄을 던지는 것이 아닙니다. 반드시 "A가 죽으면 B로 우회할 것이다"라는 완벽한 가설을 세우고, 폭발 반경(Blast Radius)을 유저의 $1\%$ 로 좁힌 뒤, 언제든 1초 만에 실험을 중단(Abort)할 수 있는 안전장치(Safety)를 걸고 수행해야 함을 간과한 무지몽매한 테러 행위입니다.

4. Prerequisites

• SLO와 관측 가능성 (Basic): 시스템의 정상 상태(Steady State)를 판단하는 메트릭 지표. (07-05-01 Observability)
• 비동기와 타임아웃 (Basic): Blocking 호출이 시스템에 미치는 스레드 고갈 현상. (07-04-03 Reactive)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 원숭이를 프로덕션에 풀어라 (The Chaos Philosophy)

• Why to Learn: 재난 상황(서버 다운)이 1년에 한 번 발생하면 엔지니어들은 패닉에 빠지지만, 매일 서버가 무작위로 죽는 환경이라면 엔지니어들이 알아서 자동 복구 시스템을 깎아내는 역설적 내성을 기르기 위함입니다.
• What to Learn:
  • Concepts: Chaos Engineering, Chaos Monkey, Fault Injection(결함 주입), Known Unknowns (알려지지 않은 취약점).
  • Skills: "A가 죽으면 B로 넘어간다"는 가설(Hypothesis) 기반의 장애 테스트 설계.
• How to Learn:
  • 1단계: 가설 수립(Hypothesis): "우리는 AWS 서울 리전에 로드밸런서와 서버 3대를 깔았다. 내 가설은 '서버 1대가 죽어도 로드밸런서가 즉시 남은 2대로 트래픽을 돌려 유저 SLI(에러율)에 변동이 없을 것이다'이다."
  • 2단계: 원숭이 투입: 평온한 화요일 오후 2시에 스크립트를 켜서 프로덕션 서버 1대의 전원을 뽑아버립니다(Kill). 5분 뒤 대시보드(SLI)를 확인합니다. 에러가 안 튀면 가설 증명 성공(회복성 확인). 에러가 미친 듯이 튀면(예: 세션이 날아감) 우리가 몰랐던 취약점(Unknowns)을 대재앙 전에 싼값에 찾아낸 개이득인 상황을 해부합니다.
• Implement: 로컬 카오스 몽키 파이썬 스크립트. 도커(Docker) 컨테이너 3개(web-1, web-2, web-3)가 로드밸런서 뒤에서 도는 환경. 스크립트가 10초마다 무작위 컨테이너 하나를 docker kill 하고 5초 뒤에 docker start로 부활시키는 행위를 반복할 때, 클라이언트의 HTTP 200 응답률이 100% 유지되는지 검증하는 데모.

Recommended

Core Topic 02: 폭발 반경과 실험의 룰 (Blast Radius & Steady State)

• Why to Learn: 실험이 진짜 재앙으로 번져 회사 매출이 날아가는 것을 막기 위해, 철저히 통제된 환경(격리)에서 실험을 설계하고 멈추는 과학자적 기율을 장악하기 위함입니다.
• What to Learn:
  • Concepts: Blast Radius (폭발 반경), Steady State (정상 상태 - 대조군), Abort Button (긴급 중단).
  • Skills: 네트워크 계층(Service Mesh)을 활용한 $1\%$ 트래픽 결함 주입 룰 세팅.
• How to Learn:
  • 1단계: 정상 상태(Steady State) 정의: "우리 서비스의 평상시 상태는 초당 1,000 TPS, 지연 시간 200ms, 에러율 $0.1\%$ 이다." 이를 베이스라인으로 긋고 모니터링 대시보드에 고정합니다.
  • 2단계: 폭발 반경 제어: 모든 유저에게 장애를 일으키는 건 미친 짓입니다. Istio 같은 서비스 메시를 이용해, "사내 IP로 들어온 유저" 혹은 "전체 트래픽의 $1\%$ 룰렛에 당첨된 유저"에게만 'DB 5초 지연(Latency Injection)'을 쏘아봅니다. 만약 전체 에러율(Steady State)이 위험 수위로 흔들리면 즉각 Abort(중단) 스위치를 눌러 원상 복구시키는 안전 제어 장치를 뜯어봅니다.
• Implement: 트래픽 가중치 기반 결함 주입 라우터. 클라이언트 요청이 들어올 때 random.random()으로 주사위를 굴려, $95\%$ 의 유저는 정상 통과, $5\%$ 의 유저에게 의도적인 sleep(3)(지연 주입)을 걸어주는 미들웨어. 이때 시스템 전체 TPS가 어떻게 영향을 받는지 모니터링 출력.

Practical

Core Topic 03: 죽음의 도미노, 연쇄 장애와 타임아웃 (Cascading & The Latency Trap)

• Why to Learn: 하위 서비스가 깔끔하게 뻗어버리는 것보다, '어중간하게 살아서 응답을 질질 끄는 것'이 마이크로서비스 아키텍처 전체를 몰살시키는 가장 끔찍한 바이러스임을 깨닫기 위함입니다.
• What to Learn:
  • Concepts: Cascading Failures (연쇄 장애), Latency Trap, Thread Exhaustion (스레드 고갈), Timeout Tuning, Retry Storm.
  • Skills: 의존성 체인(Dependency Chain)에서 적절한 타임아웃(Timeout) 방어막 설정.
• How to Learn:
  • 1단계: 느린 죽음(Latency): Front -> API -> DB 구조. DB가 락에 걸려 평소 10ms이던 응답이 30초로 늘었습니다. API 서버 스레드 100개가 DB 응답을 기다리며 멈춰섭니다(Block).
  • 2단계: 도미노 붕괴(Cascading): 이제 API 서버가 스레드가 없어 멈추니, Front 서버의 스레드도 API 응답을 기다리며 멈춥니다. 결함 주입(Latency Injection)을 통해 "하위 서비스 하나가 느려지면 1분 안에 전사 서버가 다 터지는" 연쇄 장애의 끔찍한 파급력을 해부합니다. 이를 막기 위해 API 서버가 DB 호출 시 반드시 Timeout=1초를 걸어 스레드를 강제 회수해야 하는 생존의 법칙을 뜯어봅니다.
• Implement: 연쇄 장애 시뮬레이터. Client -> Service_A(max_threads=10) -> Service_B. Service_B에 결함 주입(sleep 5초). Client가 20개의 비동기 요청을 발사하면, 1초 만에 Service_A의 스레드 10개가 모두 물려버리고, 나머지 10개 요청은 아예 수신조차 못 하고 터져버리는 스레드 풀 고갈 현상 렌더링.

Advanced

Core Topic 04: 두꺼비집을 내려라, 서킷 브레이커 (The Circuit Breaker)

• Why to Learn: 타임아웃(1초)을 걸어놔도 트래픽이 1만 개면 결국 스레드는 계속 1초씩 낭비하며 병목을 앓습니다. 아예 "저놈 죽었으니 당분간 접근 금지" 표지판을 박고 호출 자체를 원천 차단하는 궁극의 지혈법을 장악하기 위함입니다.
• What to Learn:
  • Concepts: Circuit Breaker Pattern, Closed (정상), Open (차단), Half-Open (정찰), Fail-Fast (빠른 실패), Fallback (우회 로직).
  • Skills: Resilience4j 등을 활용하여 하위 서비스 장애 시 즉각 Fallback(캐시 데이터 등)으로 응답을 돌리는 방어벽 구축.
• How to Learn:
  • 1단계: 차단(Open): API 서버가 DB를 불렀는데 타임아웃 1초가 연속 5번 터졌습니다. 서킷 브레이커(두꺼비집)가 '딱' 하고 내려갑니다(Open 상태). 이제 API 서버는 DB에 쿼리를 아예 날리지 않고 즉시(0.001초 만에) Fail-Fast 에러를 뿜거나, 준비된 예비 플랜(Fallback - "캐시된 옛날 데이터 보여주기")을 실행합니다. 스레드 1초 낭비를 원천 차단하는 마법입니다.
  • 2단계: 정찰(Half-Open): 두꺼비집을 내리고 10분이 지났습니다. DB가 살아났을 수도 있습니다. 서킷 브레이커가 두꺼비집을 살짝 올려(Half-Open) 트래픽 1~2개만 정찰병으로 보내봅니다. 정상 응답이 오면 완전히 두꺼비집을 올리고(Closed), 또 타임아웃 나면 다시 닫아버리는(Open) 자동 치유 아키텍처를 해부합니다.
• Implement: 서킷 브레이커 상태 머신 파이썬 클래스. call() 메서드 수행. 최근 5번 호출 중 실패율이 50%를 넘으면 상태를 OPEN으로 변경. 이후 들어오는 모든 call()은 실제 워커를 부르지 않고 즉각 CircuitOpenException을 던짐(Fail-fast). 3초 대기 후 HALF-OPEN 상태로 전이하여 단 한 번의 시도를 허용하는 회복(Recovery) 로직 콘솔 데모.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - Software Reliability and Testing (Chaos Engineering)
• [P5] SFIA - Enterprise IT Architecture (ARCH) - Resilient System Design

Secondary

• [Release It!: Design and Deploy Production-Ready Software] Michael T. Nygard - Circuit Breaker and Cascading Failures
• [Chaos Engineering: System Resiliency in Practice] Casey Rosenthal - Principles of Chaos Engineering

Industry

• [Netflix TechBlog] - Chaos Engineering Upgraded
• [MartinFowler.com] - CircuitBreaker Pattern

9. Final Checklist

Primary

• 개발 환경에서 수행하는 일반적인 단위 테스트(QA)와 달리, 카오스 엔지니어링(Chaos Engineering)이 반드시 프로덕션(운영) 환경에서 수행되어야만 숨겨진 네트워크 설정이나 락(Lock)의 취약점을 발견할 수 있는 이유를 설명할 수 있는가?
• 카오스 몽키로 결함을 주입하기 전에, 우리 서비스의 '정상 상태(Steady State, 예: 에러율 0.1% 이하)'를 정의하고, 이 지표가 흔들리면 즉시 실험을 중단(Abort)하는 폭발 반경 제어 룰을 설계할 수 있는가?

Secondary

• 마이크로서비스 A가 B를 동기적으로 호출할 때, B가 즉각 에러(Connection Refused)를 반환하는 것보다 10초 동안 응답을 지연(Latency)시키는 것이 A의 스레드 풀을 고갈시켜 연쇄 장애(Cascading Failure)를 유발하는 치명적인 악성 바이러스임을 증명할 수 있는가?
• 하위 서비스에 장애가 났을 때 클라이언트가 무한정 재시도(Retry Storm)를 때리는 것을 막기 위해, API 호출부에 적절한 타임아웃(Timeout) 컷오프와 지수 백오프(Exponential Backoff)를 강제하는 방어벽을 세울 수 있는가?

Industry

• 서킷 브레이커(Circuit Breaker)의 상태 전이(Closed → Open → Half-Open) 역학에서, Open 상태가 된 즉시 외부 호출을 멈추고 Fail-fast 에러를 던짐으로써 상위 서비스의 스레드 점유(1초 낭비)를 원천 차단하는 구조를 해부할 수 있는가?
• 서킷 브레이커가 작동(Open)하여 '개인화 추천 API'를 찌를 수 없을 때, 에러 페이지(500)를 렌더링하는 대신 캐시된 '오늘의 베스트 상품(Fallback)'을 즉각 렌더링하는 우아한 저하(Graceful Degradation) UX를 아키텍처 관점으로 설계할 수 있는가?