Chaos Engineering & Fault Injection

1. Overview

카오스 엔지니어링 및 장애 주입(Chaos Engineering & Fault Injection, CEI)은 시스템이 "작동할 것이다"라는 믿음을 넘어, 실제로 부수고 흔들어봄으로써 하드웨어와 소프트웨어의 숨겨진 균열을 수리적으로 증명하는 파괴적 검증 공학입니다.

학습자는 정상 상태(Steady State)를 수치로 정의하고, 네트워크 지연, 인스턴스 종료, 디스크 포화 등 다양한 실패 가설을 물리적으로 실험하는 절차를 배웁니다. 특히, 실험의 여파가 실제 유저에게 미치는 물리적 범위인 **폭발 반경(Blast Radius)**을 제어하는 법과, 장애 발생 시 시스템이 스스로를 방어하는 **자가 치유(Self-healing)**의 수리적 사상을 익힙니다. 이를 통해 이론상의 고가용성을 넘어, 실제 전선에서 검증된 하이엔드 복원력(Resilience) 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Chaos Principles: 정상 상태 가설 수립과 변수 주입의 수리적 실험 단계
• Fault Injection Types: Network (지연/손실), Resource (CPU/RAM/IO), State (Kill/Time drift)
• Blast Radius Control: 카나리(Canary) 그룹 등을 이용한 물리적 실험 범위 격리
• Resilience Verification: 서킷 브레이커, 재시도, 페일오버의 하드웨어 작동 실효성 검증
• Automated Chaos: CI/CD 파이프라인 내의 상시 장애 주입 수리 모델

Out-of-Scope

• 보안 공격을 가정한 침투 테스트 (10-02-XX 영역으로 위임)
• 단순한 유닛/통합 테스트의 모킹(Mocking) (09-03-XX 영역에서 분담)

Boundaries

• CEI vs. Disaster Recovery: DR(07-03-04)이 '재난 시의 매뉴얼 실행'에 집중한다면, CEI는 '평상시에 장애를 내어 시스템의 설계상 허점을 미리 찾는 행위'로서 구분합니다.

3. Counterexample

• 단순히 "서버 막 꺼보기"라 설명하는 것은 CEI 학습이 아닙니다. 왜 시스템의 **정상 상태(Steady State)**를 메트릭으로 수치화하지 않은 실험이 기술적 유희에 불과한지 수리 증명할 수 있어야 하며, 폭발 반경 제어 없이 운영 환경에서 진행하는 실험이 왜 비즈니스에 대한 물리적 '테러' 행위가 되는지 논증하지 못한다면 CEI의 공학적 도덕성을 이해하지 못한 것입니다.

4. Prerequisites

• Reliability Engineering & SRE Fundamentals (Basic): 가용성 지표 이해가 필수입니다. (07-00-XX 기반 역량)
• Monitoring, Observability & Distributed Tracing (Recommended): 메트릭 관측 도구 활용이 권장됩니다. (07-05-02 MOD)

5. Learning Map

1. Defining Normal: 흔든 뒤에도 돌아와야 할 시스템의 물리적 '평온한 수치'를 정합니다.
2. Injecting Pain: 서버를 끄거나 응답을 늦추는 수리적 고통 변수를 주입합니다.
3. Calculating Impact: 아픔이 어디까지 퍼지고, 하드웨어가 어떻게 비명(Alert)을 지르는지 관찰합니다.
4. Resilient Evolution: 실험으로 찾아낸 허점을 아키텍처로 보완하여, 불사의 시스템을 완성합니다.

6. Learning Topics

Basic

Core: 카오스 엔지니어링의 5단계 원칙 (Chaos Principles)

• Why to Learn: 무질서한 파괴가 아닌, 통제된 실험을 통해 시스템 신뢰도를 수리적으로 높이기 위해서입니다.
• What to Learn:
  • Steady State: 정상 작동 시의 물리 지표(TPS, Error Rate 등) 정의
  • Hypothesize: "A가 죽어도 B가 대신 처리할 것이다"라는 수리적 가설
  • Experiment & Analyze: 실제 주입 후 정상 상태 복구 여부 확인
• How to Learn:
  • 넷플릭스의 '카오스 몽키(Chaos Monkey)' 도입 사례를 분석하고, 하드웨어 수명이 짧은 클라우드에서의 복원력 필요성 도출 실습
  • 실험 전과 후의 시스템 상태를 '가용성 확률'로 수치화
• Implement: 현재 가용성 지표를 모니터링하며 실험 가동 여부를 판단하는 ExperimentGate

Recommended

Core: 장애 종류와 주입 물리 (Fault Injection Mechanics)

• Why to Learn: 실제 세상에서 일어날 수 있는 온갖 하드웨어 재난을 소프트웨어 환경에 재현하기 위함입니다.
• What to Learn:
  • Network Gremlins: 패킷 유실, 중복, 순서 뒤바뀜, 지연 주입 물리학
  • Resource Hogging: 특정 프로세스가 CPU나 RAM을 100% 점유하게 만드는 수법
  • Dependency Failure: 외부 API가 404나 500을 뱉거나 응답하지 않는 상황 시뮬레이션
• How to Learn:
  • 리눅스 tc 명령어나 카오스 메쉬(Chaos Mesh)를 이용해 특정 서비스의 네트워크 지연을 500ms로 늘리는 실습
  • 하드웨어 리소스 고갈 시 '연쇄 장애'가 일어나는 임계점($Threshold$) 찾기
• Implement: 무작위로 특정 하위 요청에 대해 지연을 발생시키는 LatencyProxy 모듈

Practical

Core: 폭발 반경 제어와 안전 장치 (Blast Radius Control)

• Why to Learn: 실험이 비즈니스 재앙으로 바뀌지 않도록 물리적 방화벽을 치기 위해서입니다.
• What to Learn:
  • Canary Deployment: 전체 유저의 1%에게만 장애 상황을 노출하는 수리적 격리
  • Automated Stop: 정상 상태가 무너지는 즉시 실험을 중단하고 원복하는 물리 장치
  • Game Day Execution: 수동 개입이 포함된 통제된 장애 시뮬레이션의 물리적 운영
• How to Learn:
  • 장애 주입 중 에러율이 5%를 넘으면 즉시 '롤백' 시그널을 보내는 자동화 루프 설계 실습
  • 실험 대상 서비스의 '의존성 맵'을 그려보고 피해가 어디까지 갈지 물리적 범위 산출
• Implement: 특정 조건 만족 시 진행 중인 장애 주입을 즉시 종료하는 EmergencyStop 회로

Advanced

Core: 지속적 복원력 강화 파이프라인 (Continuous Resilience)

• Why to Learn: 한 번의 실험이 아닌, 시스템의 성장에 맞춰 매일 복원력을 수리 검증하기 위함입니다.
• What to Learn:
  • Chaos as a Service: 개발자가 언제든 플랫폼에서 장애 실험을 할 수 있는 하드웨어 환경
  • Regression Testing for Faults: 고쳐진 설계 허점이 다시 나타나지 않도록 감사하는 물리학
  • Resilience Score: 시스템의 복원력 수준을 수치화하여 등급을 매기는 수리 모델
• How to Learn:
  • CI/CD 파이프라인의 스테이징 단계에서 자동으로 장애 주입 테스트를 통과해야 배포가 되는 구조 분석 실습
  • 대규모 인프라의 '카오스 로드맵'을 수립하고 분기별 점수 향상 목표 설정
• Implement: 여러 장애 시나리오를 순차적으로 실행하고 결과를 종합 보고하는 ResilienceTestSuite

7. Terminology

8. References

Primary

• [P1] CS2023 - AR/Architecture (Resilience and fault tolerance mechanisms) — Hardware context.
• [P2] SWEBOK v4.0 - Software Testing / Test Levels (Resilience testing) — Verification requirements.

Secondary

• [Chaos Engineering: System Resiliency in Practice] Casey Rosenthal et al. — The definitive text.
• [Antifragile: Things That Gain from Disorder] Nassim Taleb — Philosophical foundation for resilience.

Industry

• [Netflix: Chaos Monkey and the Simian Army] — Origin of the field.
• [AWS: Fault Injection Simulator (FIS) Documentation] — Cloud-native practice.

9. Final Checklist

Primary

• '카오스 엔지니어링'이 단순한 '장애 테스트'와 수리적/철학적으로 어떻게 다른지 설명 가능한가? (P2)
• '장애 주입' 상황에서도 시스템의 '성능 SLO'를 지키기 위해 물리적으로 작동해야 하는 아키텍처적 요소들을 기술할 수 있는 가? (P1)

Secondary

• '정상 상태 가설' 수립 시, 어떤 비즈니스 메트릭을 고르는 것이 하드웨어 장애를 가장 민감하게 물리적으로 포착할지 소통 가능한가?
• 폭발 반경을 수학적으로 계산하여, 실험 도중 최악의 상황이 발생해도 비즈니스 손실이 예산($Error Budget$)을 넘지 않게 설계할 수 있는 가?

Industry

• 서비스 가동 중 '데이터베이스 연결 지연' 상황을 카오스 실험으로 구현할 때, 유저에게 노출될 수 있는 물리적 에러 페이지 시나리오를 제안할 수 있는 가? (SFIA)
• '카오스 오픈 소스 도구(Chaos Mesh, Litmus)'를 활용하여 쿠버네티스 환경에서 특정 팟($Pod$)의 CPU를 물리적으로 압박하는 실험 순서를 수립할 수 있는 가?