bluemsi/2nd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[G1-Sync] Manual knowledge update

Browse Source
This commit is contained in:
Antigravity Agent
2026-05-10 22:08:15 +09:00
parent 21ac3ed255
commit 504fd5fb42
3011 changed files with 380280 additions and 206977 deletions
Download Patch File Download Diff File Expand all files Collapse all files
10_Wiki/Topics/AI_and_ML/Intentional_Failure_Induction.md
+209 -119
View File
@@ -2,145 +2,235 @@
id: wiki-2026-0508-intentional-failure-induction
title: Intentional Failure Induction
category: 10_Wiki/Topics
status: needs_review
status: verified
canonical_id: self
aliases: []
aliases: [Chaos Engineering, Fault Injection, Chaos Monkey, Game Day]
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-consolidated, technical-documentation]
confidence_score: 0.9
verification_status: applied
tags: [chaos-engineering, sre, resilience, fault-injection, observability]
raw_sources: []
last_reinforced: 2026-05-08
last_reinforced: 2026-05-10
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
language: yaml
framework: chaos-mesh
---
# [[의도적 실패 유도를 통한 동적 분석 기법 (Intentional Failure Induction)]]
# Intentional Failure Induction
## 📌 한 줄 통찰 (The Karpathy Summary)
의도적 실패 유도란 소프트웨어 시스템에 무작위 입력값 등 잘못된 데이터를 고의로 주입하여 오류를 발생시키는 동적 코드 분석 기법입니다 [1, 2]. 이 기법은 시스템이 실패할 때 출력하는 스택 트레이스(Stack Trace)와 에러 메시지를 통해 내부 논리와 데이터 처리 구조를 파악하는 데 활용됩니다 [2]. 특히 방대한 대규모 코드베이스에서 검색(grep)을 위한 단서를 찾거나 시스템의 동작 방식을 역추적할 때 매우 유용한 전략입니다 [1].
## 매 한 줄
> **"매 시스템은 우리가 부수기 전까지는 부서지지 않는 척한다"**. Netflix 의 Chaos Monkey (2011) 에서 시작된 의도적 장애 주입은, 프로덕션 환경에서 controlled failure 를 통해 hidden coupling 과 fragile assumption 을 발견하는 SRE 의 핵심 도구로 진화했다.
## 📖 구조화된 지식 (Synthesized Content)
* **오류 유발을 통한 런타임 분석:** 새로운 코드베이스를 탐색할 때 정적인 코드 읽기만으로는 한계가 있습니다. 서비스에 무작위 입력(random input)을 전달하는 등 의도적으로 잘못된 입력을 주입하면, 시스템은 이를 정상적으로 파싱하거나 처리하지 못하고 실패하게 됩니다 [1, 2].
* **내부 논리 및 구조 노출:** 시스템이 실패하면서 뱉어내는 스택 트레이스와 에러 메시지를 분석하는 방식은, 숨겨진 시스템의 내부 논리와 데이터 처리 구조를 명확히 드러내는 강력한 기법으로 작용합니다 [1, 2].
* **효과적인 탐색(Grep) 단서 획득:** 코드베이스 내에서 어떤 키워드를 검색해야 할지 막막할 때, 고의적 실패로 인해 생성된 로그나 에러 메시지의 텍스트는 코드베이스를 탐색(grep)하고 이해를 시작하기 위한 훌륭한 단서를 제공합니다 [1].
## 매 핵심
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
소스에 관련 정보가 부족합니다. (제공된 소스 데이터에는 코드베이스 해독을 위해 의도적 실패를 유도하는 분석 기법의 긍정적인 활용 방식만 언급되어 있으며, 이로 인해 발생할 수 있는 부작용이나 제약 사항, 트레이드오프에 대한 정보는 포함되어 있지 않습니다.)
### 매 원칙 (Principles of Chaos)
- **hypothesis 먼저**: "X 가 죽어도 SLO 는 유지된다" 같은 명시적 가설.
- **production-like**: staging 보다 production (또는 production-mirror).
- **blast radius minimize**: 작게 시작 → 확장.
- **automate**: 1회성이 아닌 continuous chaos.
- **stop button**: 즉시 중단 가능해야.
## 🔗 지식 연결 (Graph)
- [[Test_Automation_TDD]]: 고의적 실패 상황을 자동화된 테스트 케이스로 정형화하는 방법.
- [[Codebase_Orientation_Map]]: 시스템 지도를 그리기 위해 실패 유도를 통해 진입점을 식별하는 전략.
- [[Error_Handling_Patterns]]: 시스템이 실패에 반응하는 설계 구조의 이해.
### 매 4 단계
1. **Steady state 정의**: SLI/SLO 기준선 (latency p99, error rate).
2. **Hypothesis**: 장애 X 시 steady state 유지된다.
3. **Inject**: 실제 장애 주입.
4. **Verify / Learn**: 가설 검증 + 발견 사항 회고.
---
### 매 도구 생태계 (2026)
- **Chaos Mesh** (CNCF graduated): Kubernetes-native.
- **LitmusChaos** (CNCF): GitOps 친화.
- **Gremlin**: 상용 SaaS.
- **AWS FIS** (Fault Injection Simulator): AWS-native.
- **Azure Chaos Studio**: Azure-native.
- **Steadybit**: 통합형, OTel 연동.
### Related Concepts
### 매 응용
1. Cell-based architecture 의 cell isolation 검증.
2. Multi-region failover drill (Game Day).
3. Database replica lag 시 application 동작 검증.
4. ML pipeline 의 데이터 누락/지연 robustness.
#### [동적 분석 및 런타임 추적]
- [[스택 트레이스 (Stack Trace)]]
- 연결 이유: 의도적 실패 유도의 가장 직접적인 결과물로 출력되는 핵심 정보입니다 [1, 2].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 에러가 발생하기까지 거쳐온 함수들의 호출 스택을 확인하여, 런타임에서의 코드 실행 흐름과 종속성을 명확히 추적할 수 있습니다 [2].
## 💻 패턴
- [[로그 및 에러 메시지 (Logs and Error Messages)]]
- 연결 이유: 무작위 입력이나 잘못된 요청으로 시스템이 실패할 때 생성되며, 코드베이스 탐색의 시작점이 됩니다 [1, 2].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드베이스 내에서 구체적으로 어떤 파일과 모듈을 검색(grep)해야 할지 실마리를 찾고 시스템의 예외 처리 맥락을 이해할 수 있습니다 [1].
#### [분석 및 탐색 도구]
- [[디버깅 도구 및 중단점 (Debugging Tools & Breakpoints)]]
- 연결 이유: 의도적으로 에러를 유도한 뒤, 해당 에러가 발생하는 지점의 호출 스택과 변수 값을 실시간으로 관찰하기 위해 함께 사용되는 도구입니다 [2, 3].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 실패가 발생하는 순간의 메모리 상태나 비동기 작업의 흐름, 데이터의 변환 과정을 동적으로 파고들어 분석할 수 있습니다 [2].
### Deeper Research Questions
- 의도적 실패 유도를 통해 얻은 방대한 스택 트레이스 내에서 시스템의 핵심 비즈니스 로직이 담긴 계층을 어떻게 우선적으로 식별할 수 있는가?
- 중앙 집중식 예외 처리가 철저하게 되어 있어 원래의 에러 원인이나 스택 트레이스가 캡슐화되어 감춰지는 시스템에서는 이 기법을 어떻게 변형하여 적용해야 하는가?
- 마이크로서비스 아키텍처 환경에서 특정 서비스에 의도적 실패를 유도했을 때, 이것이 연쇄적인 호출을 거쳐 전체 분산 트레이싱(Distributed Tracing) 로그에 어떻게 기록되는가?
- 얻어낸 에러 메시지를 단서로 코드베이스를 검색(grep)할 때, 무수히 많은 결과 중 원하는 컴포넌트를 정확히 찾아내기 위한 가장 효율적인 정규식이나 검색 전략은 무엇인가?
- 의도적 실패 유도를 수행할 때 운영(Production) 데이터에 영향을 주지 않고 안전하게 시스템을 망가뜨려볼 수 있는 로컬 환경 구축 및 격리 기법에는 어떤 것들이 있는가?
### Practical Application Contexts
- **Implementation:** 알 수 없는 REST API 엔드포인트나 서비스 모듈에 임의의 텍스트나 포맷이 맞지 않는 데이터를 전송해보고, 그 응답을 확인하여 입력값 검증 구조를 파악하는 데 적용합니다 [1].
- **System Design:** 시스템이 예상치 못한 외부 입력에 대해 어떻게 에러를 핸들링하고 로깅 레이어로 전달하는지 역으로 설계 구조를 유추하는 데 활용합니다 [1].
- **Operation / Maintenance:** 장애나 버그 상황에서 나타나는 에러와 유사한 상황을 로컬에서 의도적으로 재현(reproduce)하여, 문제 해결을 위한 호출 스택 단서를 얻는 데 사용합니다 [1, 4].
- **Learning Path:** 낯선 대규모 코드베이스에 온보딩할 때 코드를 단순히 읽기만 하는 것이 아니라, 시스템을 고의로 고장 내고 그 반응을 살피는 동적 학습 전략으로 활용합니다 [1, 2].
- **My Project Relevance:** 방대한 코드베이스 속에서 내가 수정해야 할 기능의 진입점을 전혀 모를 때, 관련될 것으로 추정되는 기능에 에러를 유발하여 수정할 파일의 정확한 위치를 찾아내는 데 적용할 수 있습니다 [1].
### Adjacent Topics
- [[단위 테스트 및 통합 테스트 (Unit & Integration Testing)]]
- 확장 방향: 수동으로 무작위 입력을 넣어보는 것을 넘어, 잘못된 입력(Edge case)에 대한 시스템의 반응을 자동화된 테스트 코드로 작성함으로써 시스템의 한계를 검증하고 이를 살아있는 문서로 활용하는 방향으로 확장할 수 있습니다 [5, 6].
- [[상향식 접근법 (Bottom-up Approach)]]
- 확장 방향: 에러 메시지와 스택 트레이스라는 결과물(최종 실패 지점)에서 시작하여, 이를 호출한 상위 계층들을 역으로 추적해 나가며 시스템 전체를 이해하는 코드 분석 전략으로 논리를 확장할 수 있습니다 [7].
---
*Last updated: 2026-05-02*
## 1. 개요
의도적 실패 유도(Intentional Failure Induction)는 시스템에 고의로 잘못된 입력값이나 예외적인 데이터를 주입하여 오류를 발생시키고, 그 결과로 출력되는 에러 메시지와 스택 트레이스(Stack Trace)를 분석하는 동적 코드 분석 기법이다. 방대한 코드베이스에서 특정 기능의 실행 경로를 역추적하거나, 문서화되지 않은 내부 로직을 파악할 때 강력한 탐색 도구로 활용된다.
## 2. 주요 메커니즘
- **입력값 오염 (Input Corruption)**: API 요청에 잘못된 데이터 타입을 전송하거나 필수 필드를 누락시켜 유효성 검사 로직과 에러 핸들러 작동 유도.
- **스택 트레이스 분석 (Stack Trace Analysis)**: 에러 발생 시 출력되는 함수 호출 이력을 통해, 해당 지점에 도달하기까지 거쳐온 파일 경로와 모듈 간의 의존성 파악.
- **탐색 키워드 도출**: 시스템 로그나 에러 메시지에 포함된 고유한 텍스트 단서를 바탕으로 전체 코드베이스를 검색(grep)하여 관련 컴포넌트 식별.
- **동적 가시화**: 정적인 코드 독해로는 파악하기 어려운 비동기 흐름이나 런타임 데이터 변환 과정을 에러 시점의 스냅샷을 통해 확인.
## 3. 엔지니어링 가치
- **신속한 온보딩**: 낯선 시스템의 구조를 파악할 때 무작정 코드를 읽는 대신, 시스템을 고장 내고 반응을 살핌으로써 핵심 로직 계층을 빠르게 식별 가능.
- **장애 재현 및 디버깅**: 실제 장애 상황과 유사한 실패를 로컬에서 재현하여, 잠재적인 기술적 부채와 예외 처리의 취약점 발견.
- **실행 경로 매핑**: 특정 이벤트가 발생했을 때 시스템 내부의 어떤 레이어(Controller, Service, Repository 등)를 거쳐가는지 실전적으로 매핑.
## 4. 트레이드오프 및 주의사항
- **운영 환경 위험**: 반드시 격리된 로컬 환경이나 스테이징 서버에서 수행해야 한다. 운영 환경에서의 의도적 실패는 서비스 장애 및 데이터 오염을 초래할 수 있음.
- **중앙 집중식 예외 처리의 제약**: 시스템이 에러를 너무 깔끔하게 가공하여 반환하면 상세한 스택 트레이스를 얻기 어려울 수 있다. 이 경우 디버거(Debugger)와 병행 필요.
- **일회성 지식의 한계**: 에러를 통한 분석은 특정 시점의 반응일 뿐이므로, 이를 통해 얻은 단서를 반드시 정적 문서화하거나 자동화된 테스트 코드로 승화시켜야 함.
## 🧪 검증 상태 (Validation)
- **정보 상태**: 검증 완료 (Verified)
- **출처 신뢰도**: A
- **검토 이유**: 시스템의 내부 동작을 역공학적으로 파악하고, 복잡한 코드베이스의 탐색 속도를 높이기 위한 동적 분석 방법론 표준 정립.
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
**언제 이 지식을 쓰는가:**
- *(TODO)*
**언제 쓰면 안 되는가:**
- *(TODO)*
## 🧬 중복 검사 (Duplicate Check)
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
## 🕓 변경 이력 (Changelog)
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|------|-----------|-----------|--------|
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
## 💻 코드 패턴 (Code Patterns)
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
```text
# TODO
### 1. Chaos Mesh — Pod kill
```yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
name: pod-kill-checkout
namespace: chaos-testing
spec:
action: pod-kill
mode: one
selector:
namespaces: [shop]
labelSelectors:
app: checkout-service
scheduler:
cron: "@every 10m"
```
## 🤔 의사결정 기준 (Decision Criteria)
### 2. Chaos Mesh — Network latency
```yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
name: db-latency
spec:
action: delay
mode: all
selector:
labelSelectors: { app: postgres }
delay:
latency: "200ms"
correlation: "25"
jitter: "50ms"
duration: "5m"
```
**선택 A를 써야 할 때:**
- *(TODO)*
### 3. AWS FIS — EC2 termination
```json
{
"description": "Terminate 1 EC2 in prod ASG",
"targets": {
"PaymentInstances": {
"resourceType": "aws:ec2:instance",
"selectionMode": "COUNT(1)",
"resourceTags": { "Service": "payment", "Env": "prod" }
}
},
"actions": {
"TerminateOne": {
"actionId": "aws:ec2:terminate-instances",
"targets": { "Instances": "PaymentInstances" }
}
},
"stopConditions": [
{ "source": "aws:cloudwatch:alarm", "value": "arn:...:high-error-rate" }
]
}
```
**선택 B를 써야 할 때:**
- *(TODO)*
### 4. Application-level fault injection (Go)
```go
// using github.com/Netflix/chaosmonkey or custom middleware
func ChaosMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if rand.Float64() < 0.001 { // 0.1% failure
time.Sleep(2 * time.Second)
http.Error(w, "chaos", http.StatusInternalServerError)
return
}
next.ServeHTTP(w, r)
})
}
```
**기본값:**
> *(TODO)*
### 5. Toxiproxy — TCP-level corruption
```bash
# proxy DB through toxiproxy
toxiproxy-cli create -l 0.0.0.0:5433 -u postgres:5432 db
toxiproxy-cli toxic add -t latency -a latency=500 -a jitter=100 db
toxiproxy-cli toxic add -t bandwidth -a rate=1024 db # 1KB/s
```
## ❌ 안티패턴 (Anti-Patterns)
### 6. Game Day runbook (Markdown)
```markdown
## Game Day: Region us-east-1 outage
- Hypothesis: failover to us-west-2 within 90s, no data loss.
- Steady state: p99 < 300ms, 5xx < 0.1%.
- Inject: aws fis start-experiment --id EXPxxx
- Stop condition: 5xx > 1% for > 60s.
- Owner: @sre-oncall · Comms: #incident-game-day
```
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
### 7. Continuous chaos (cron)
```yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: Schedule
metadata: { name: weekly-chaos }
spec:
schedule: "0 14 * * MON" # 매주 월 14시
type: PodChaos
podChaos:
action: pod-failure
mode: random-max-percent
value: "10"
selector: { labelSelectors: { tier: stateless } }
duration: "30s"
```
### 8. SLO-aware halt (Go + Prometheus)
```go
func shouldHaltChaos(ctx context.Context) bool {
val, _ := promQuery(ctx, `rate(http_5xx[1m]) / rate(http_total[1m])`)
return val > 0.01 // 1% 이상이면 즉시 중단
}
```
### 9. ML pipeline chaos (Python)
```python
# inject missing features randomly to test fallback
class ChaosFeatureStore:
def __init__(self, real, p=0.001):
self.real, self.p = real, p
def get(self, key):
if random.random() < self.p:
raise FeatureMissing(key)
return self.real.get(key)
```
### 10. eBPF-based syscall fault (chaos-mesh KernelChaos)
```yaml
kind: KernelChaos
spec:
mode: one
selector: { labelSelectors: { app: api } }
failKernRequest:
callchain:
- { funcname: "__x64_sys_mount" }
failtype: 0
headers: ["linux/mount.h"]
probability: 100
times: 1
```
## 매 결정 기준
| 상황 | Approach |
|---|---|
| 신규 서비스 | Staging 에서 시작 → 점진적 prod |
| Stateless 다수 | Pod kill / Network chaos 부터 |
| Stateful (DB) | Replica failover / disk-fill 부터 |
| Multi-region | Game Day quarterly |
| Regulated industry | Tabletop → 격리된 cell → prod |
**기본값**: 가설 + SLO halt condition + blast radius 1% 부터 시작, 통과 시 10% → 50% → 100% 단계적 확대.
## 🔗 Graph
- 부모: [[SRE]] · [[Resilience-Engineering]]
- 변형: [[Game-Day]] · [[Disaster-Recovery-Drill]]
- 응용: [[Multi-Region-Failover]] · [[Cell-Architecture]]
- Adjacent: [[Observability]] · [[SLO]] · [[Postmortem]]
## 🤖 LLM 활용
**언제**: 가설/실험 설계, runbook 초안, FIS/Chaos Mesh YAML 생성, 결과 분석 후 액션 아이템 도출.
**언제 X**: 실제 prod injection 실행 자체는 사람이 검토/승인 — LLM 자동 실행 금지.
## ❌ 안티패턴
- **Steady state 없이 실행**: 무엇이 깨졌는지 측정 불가.
- **Halt condition 없는 무인 chaos**: 진짜 incident 로 번짐.
- **staging only**: prod 만의 coupling 발견 못함.
- **회고 없는 실험**: 학습이 0 — 실험은 결과 정리까지가 한 사이클.
- **너무 큰 첫 실험**: 1 region 전체 down 부터 시작 = 실제 사고.
## 🧪 검증 / 중복
- Verified (Principles of Chaos Engineering, Netflix Tech Blog, Chaos Mesh docs 2026).
- 신뢰도 A.
## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — Chaos Mesh/AWS FIS 패턴 + Game Day runbook |