혼돈 공학: 시스템 탄력성
혼돈 공학: 시스템 탄력성
1) 혼돈 공학의 이유
목표는 단어와 다이어그램이 아니라 실험을 통해 생산 아키텍처의 안정성을 입증하는 것입니다. 우리는 의도적으로 통제 된 실패를 만듭니다
시스템 동작에 대한 테스트 가설과 SLO 검증;
숨겨진 SPOF, 잘못된 타임 아웃/리트레이, 계단식 효과 감지;
훈련 팀: 게임 데이, 런북 운동, 커뮤니케이션;
"최고를 기대하는 것" 이 아니라 "기본적으로 지속 가능성" 문화를 형성합니다.
중요: 카오스 엔지니어링은 "모든 것을 깨뜨립 "이것은 과학적인 방법입니다: 정상 상태 → 가설 → 실험 → 결론 → 개선.
2) 기본 실험주기
1. 정상 상태 (기준): 어떤 SLI가 안정적입니까? (예를 들어, 99에서 성공 약 500ms. 95%).
2. 가설: 하나의 AZ가 손실되면 p95는 <10% 증가하고 가용성은 99 이상입니다. 9%.
3. 실험: 제한된 폭발 반경 및 정지 기준으로 계획된 파울.
4. 관찰: 메트릭/트레일/로그, 번 레이트 SLO, 비즈니스 SLI (예: 성공적인 예금).
5. 개선: 찾기 기록, 타임 아웃/제한/라우팅 변경, 런북 업데이트.
6. 자동화/회귀: 일정을 반복하고 CI/CD 및 게임 데이 캘린더에 추가하십시오.
3) 안전 우선
폭발 반경: 좁은 포드 (하나의 포드/인스턴스/경로/네임 스페이스) 로 시작하십시오.
가드 레일: SLO 연소율 (빠른/느린), 재 트레이 제한, QPS 제한, 사고 예산에 대한 경고.
중지 기준: "오류율> X% 또는 p99> Y ms N 분-즉시 중지 및 롤백".
Windows: 통화 중 근무 시간, 통지 된 이해 관계자, 동결 된 릴리스.
커뮤니케이션: IC/Tech 리드/Comms, 클리어 채널 (War-room), 메시지 템플릿.
4) 실패 클래스 및 가설 아이디어
네트워크: 지연/지터/손실, 부분 포트 드롭, 서비스/PSP 간의 "플롭" 통신.
컴퓨터/노드: 프로세스 죽이기, CPU 과열, 파일 디스크립터 소진, 좁은 연결 풀.
저장 및 데이터베이스: 대기 시간 디스크의 성장, 지연 복제본, 파편/리더 1 개 중지, 분할 뇌.
의존성: 외부 API의 저하, 공급자 제한, 5xx/429 버스트.
관리 변경: 실패한 릴리스, 불량 기능 플래그, 부분 롤아웃.
주변 측정기: CDN이 분해되고, DNA/Anycast 드리프트, WAF/봇 보호 장애가 발생합니다.
지역/AZ: 완전한 손실 또는 "부분" 사고 (약간 더 나쁘고 예측할 수 없음).
5) 도구 및 기술
Kubernetes: Chaos Mesh, Litmus, PowerfulSeal, kube-monkey.
구름: AWS 결함 주입 시뮬레이터 (FIS), 구름 근처의 결함 도메인.
네트워크/프록시: Toxiproxy (계산 독), tc/netem, iptables, Envoy 결함 (지연/중단), Istio 결함 주입.
프로세스/노드: 'stress-ng', cgroup/CPU 스로틀, 디스크 채우기.
트래픽 라우팅: GSLB/DNA 가중치, 가짜 검사를위한 카나리아/청록색 전환.
6) 샘플 스크립트 (Kubernetes)
6. 1 경로에서 지연/중단 (Istio VirtualService)
yaml apiVersion: networking. istio. io/v1alpha3 kind: VirtualService metadata: { name: api-chaos }
spec:
hosts: ["api. internal"]
http:
- route: [{ destination: { host: api-svc } }]
fault:
delay: { percentage: { value: 5 }, fixedDelay: 500ms }
abort: { percentage: { value: 1 }, httpStatus: 503 }가설: 클라이언트 타임 아웃/리트레이 및 CB는 p95 <300 ms 및 오류율 <0을 유지합니다. 5%.
6. 2 포드 킬 (카오스 메쉬)
yaml apiVersion: chaos-mesh. org/v1alpha1 kind: PodChaos metadata: { name: kill-one-api }
spec:
action: pod-kill mode: one selector:
namespaces: ["prod"]
labelSelectors: { "app": "api" }
duration: "2m"가설: 밸런서와 HPA는 p99> 20% 의 성장없이 한 인스턴스의 손실을 보상합니다.
6. 3 네트워크 혼돈 (데이터베이스 지연)
yaml apiVersion: chaos-mesh. org/v1alpha1 kind: NetworkChaos metadata: { name: db-latency }
spec:
action: delay mode: all selector: { namespaces: ["prod"], labelSelectors: {"app":"payments"} }
delay: { latency: "120ms", jitter: "30ms", correlation: "25" }
direction: to target:
selector: { namespaces: ["prod"], labelSelectors: {"role":"db"} }
mode: all duration: "5m"가설: 수영장/타임 아웃/캐시는 영향을 줄입니다. p95 지불은 SLO로 유지됩니다.
6. 디스크 충전 4 개
yaml apiVersion: chaos-mesh. org/v1alpha1 kind: IOChaos metadata: { name: disk-fill-logs }
spec:
action: fill mode: one selector: { labelSelectors: {"app":"ingest"} }
volumePath: /var/log size: "2Gi"
duration: "10m"가설: 경로가 열화되기 전에 로그/할당량/경고의 회전이 작동합니다.
7) K8 외부 실험
7. 1 독성 프록시 (로컬/통합)
bash toxiproxy-cli create psp --listen 127. 0. 0. 1:9999 --upstream psp. prod:443 toxiproxy-cli toxic add psp -t latency -a latency=200 -a jitter=50 toxiproxy-cli toxic add psp -t timeout -a timeout=10007. 2 개의 특허 저장소 (주변/메쉬)
yaml fault:
delay: { fixed_delay: 0. 3s, percentage: { numerator: 10, denominator: HUNDRED } }
abort: { http_status: 503, percentage: { numerator: 1, denominator: HUNDRED } }7. 3 AWS FIS (예: 아이디어)
실험은 자동 스케일링 그룹에서 N% EC2를 "킬" 하고, EBS 대기 시간을 인위적으로 높이고, 하나의 AZ에서 NAT-GW를 비활성화합니다.
CloudWatch SLO 지표에 대한 내장 정지 기준.
8) 혼돈 중 관찰 가능성 지표
SLO/SLI: 좋은 요청의 일부, p95/p99, 연소율.
중요 경로 (속도, 오류, 지속 시간) 에 대한 RED 모델.
수영장: p95 연결 대기, 활용.
DB: 지연 복제품, 잠금 장치, 드리프트 p95 요청.
네트워크: 재송신, RTT, dscp/ecn 동작.
비즈니스 SLI: 거래 성공 (예금/수표),% 수익률/오류.
추적: 선택적 흔적 (예제), 릴리스 주석의 상관 관계.
9) SLO/오류 예산과의 통합
실수 예산 내에서 실험을 계획하십시오. 혼돈은 분기 별 목표를 "파괴" 해서는 안됩니다.
자동 킬 스위치로 번 레이트 경고.
보고: "얼마나 많은 예산이 소실되었는지", "편차가 정상 상태"
10) 게임 일 (운동)
시나리오: 간단한 전설 (예: "지역-동쪽 손실"), 주입 단계, SLO 목표, 역할, 시간.
등급: RTO/RPO 실제, 통신 품질, 런북 정확성.
복고풍: 소유자 및 마감일의 개선 사항 목록, 문서/대시 보드 업데이트.
11) 자동화 및 CI/CD
연기 혼돈: 각 릴리스에 대한 짧은 준비 테스트 (예: 경로 당 1 포드 킬 + 200ms 지연).
Nightly/Weekly: 보고서가있는 더 무거운 시나리오 (5-15 분).
프로모션 게이트: 카나리아에서 p95/오류> 임계 값 인 경우-자동 롤백.
실험 카탈로그 (YAML + 런북 + SLO- 임계 값) 가있는 리포지토리.
12) 반 패턴
"난간이없는 음식 깨기": 정지 기준, 통화 중 → 실제 사고의 위험.
프로세스 대신 일회성 조치.
정상 상태가없는 혼돈: 성공/실패로 간주되는 것이 명확하지 않습니다.
지연을 주입 할 때 과도한 배상 → 자체 DDoS.
비즈니스 SLI 무시: 결제/주문이 실패하면 "Technarian" 성공.
사후 분석 및 개선 소유자 부족.
13) 구현 점검표 (0-45 일)
0-10 일
정상 상태 SLI (사용자 + 비즈니스) 를 정의하십시오.
도구를 선택하십시오 (Chaos Mesh/Litmus/Toxiproxy/FIS).
난간 설명: 폭발 반경, 정지 기준, 창, 역할.
11-25 일
첫 번째 실험 실행: 포드 킬, 임계 업스트림 당 100-200ms 지연, 패킷의 1% 감소.
연소율 경보를 설정하고 킬 스위치를 정지 기준과 연관시킵니다.
첫 경기 일을 보내고 복고풍을 수집하고 수정하십시오.
26-45 일
AZ 레벨/종속성 스크립트 (외부 PSP, DB-lag) 를 추가합니다.
무대에서 야간 혼돈을 자동화하십시오. "계절" 시나리오 (피크) 를 준비하십시오.
관리/SRE에 대한 실험 카탈로그 및 정기 보고서.
14) 성숙도 지표
중요 경로의 80% 이상이 설명 된 실험과 정상 상태 지표를 가지고 있습니다.
p99/오류율 임계 값을 초과하면 자동 킬 스위치가 트리거됩니다.
분기 별-게임 데이 레벨 AZ/지역; 월 1 회 이상-종속성 목표 시나리오.
개선 사이클 후에 MTTR이 감소하고 "릴리스 표시 사건" 상관 관계가 감소합니다.
실제 실패에서 "예기치 않은" 하락의 비율은 0이되는 경향이 있습니다.
대시 보드는 "탄력성" 을 KPI (연소율, 복구 시간, 성공적인 DR 동작의 비율) 로 표시합니다.
15) 가드 레일 및 정지 트리거의 예
중지: 'http _ req _ 실패> 1%' 3 분 ', p99> 1000 ms' 3 창, 예금 _ 성공 <99. 5%`.
폭발 반경의 감소: 매니페스트의 자동 롤백, GSLB 중량의 반환, 결함 주사 비활성화.
명령 중지: 원인을 기록한 단일 버튼/스크립트
16) 문화와 과정
혼돈은 "극단적" 이 아니라 SRE 리듬의 일부입니다.
투명한보고, 취약성 인식, 시정 조치.
통화 중 교육, 고객/파트너와의 통신 시뮬레이션.
SLA/SLO 및 예산과의 연결: 혼돈은 신뢰성을 약화시키지 않고 향상시켜야합니다.
17) 결론
카오스 엔지니어링은 "나인에 대한 희망" 을 입증 가능한 지속 가능성으로 바꿉니다. 정상 상태, 난간 배치, 소형 및 통제, SLO 및 비즈니스 SLI 관찰, 기록 및 자동화 개선. 그런 다음 실제 실패는 예측 가능한 RTO, 보호 된 오류 예산 및 공황없이 행동하려는 팀의 의지와 같은 통제 된 이벤트가됩니다.