Complex — Pod Failure + Network Delay 복합 장애 주입
목적: Pod Failure와 Network Delay를 동시에 주입했을 때의 복합 영향을 관찰하고, 개별 실험 결과와 비교해 장애 상호작용을 분석한다.
1. 개요
Chaos Mesh Workflow를 사용해 Pod Failure와 Network Delay를 동시에 주입하고, k6로 동일한 부하를 주며 서비스 영향을 관찰했다. 이 실험은 단일 관찰 실험으로, 개선 전/후 비교 없이 복합 장애 상황에서의 지표 변화를 기록하는 것이 목적이다.
이 실험은 알림 체계 구축 이전에 수행되었다. 다섯 시나리오를 먼저 알림 없이 관찰한 뒤 그 결과를 바탕으로 알림을 설계했는데, 개별 시나리오와 달리 복합 장애는 알림 구축 후 재실험을 수행하지 않았다.
2. 실험 환경
•
대상 서비스: podinfo (http://podinfo.chaos-lab.local)
•
부하 도구: k6 (Rate 15 req/s, Duration 6m, 2분 baseline → 2분 chaos 주입 → 2분 안정화)
•
장애 주입: Chaos Mesh Workflow (Pod Failure + Network Delay 동시 주입)
apiVersion: chaos-mesh.org/v1alpha1
kind: Workflow
metadata:
name: complex-pod-failure-network-delay
namespace: chaos-mesh
spec:
entry: entry
templates:
- name: entry
templateType: Parallel
children:
- pod-failure
- network-delay
- name: pod-failure
templateType: PodChaos
deadline: 2m
podChaos:
action: pod-failure
mode: one
selector:
namespaces:
- podinfo
labelSelectors:
app.kubernetes.io/name: podinfo
- name: network-delay
templateType: NetworkChaos
deadline: 2m
networkChaos:
action: delay
mode: all
selector:
namespaces:
- podinfo
labelSelectors:
app.kubernetes.io/name: podinfo
delay:
latency: "300ms"
jitter: "50ms"
correlation: "100"
YAML
복사
Parallel 템플릿으로 두 장애를 동시에 2분간 주입했다. Pod Failure는 mode: one으로 Pod 하나에 failure 상태를 주입하고, Network Delay는 mode: all로 모든 Pod에 300ms(±50ms) 지연을 주입했다.
•
모니터링: Prometheus + Grafana
3. 실험 결과
k6 결과
지표 | 값 |
총 요청 수 | 5,384 건 |
실패율 | 0.46% (25건) |
p50 latency | 6.67ms |
p90 latency | 328.36ms |
p95 latency | 347.47ms |
p99 latency | 521.57ms |
max latency | 922ms |
checks 통과율 | 99.77% |
Grafana 대시보드
대시보드의 "실행 중인 Chaos 실험 수" 패널에 2가 표시되어 두 장애가 동시에 주입되었음을 확인할 수 있다. Pod Health 패널에서는 Pod 재시작이 관찰되었고, 같은 구간에 p99 latency가 최대 약 2초까지 치솟는 스파이크가 발생했다. HPA replica는 3을 유지했으며 5xx 에러는 발생하지 않았다.
4. 개별 실험과의 비교
복합 장애의 영향을 이해하기 위해 동일 조건의 개별 실험 결과와 비교했다.
지표 | Baseline | Pod Failure | Network Delay | Complex |
실패율 | 0.28% | 0.46% | 0.46% | 0.46% |
p50 latency | 1.98ms | 2.37ms | 3.30ms | 6.67ms |
p95 latency | 21.66ms | 41.61ms | 350.33ms | 347.47ms |
p99 latency | 65.61ms | 153.25ms | 381.86ms | 521.57ms |
max latency | 337ms | 606ms | 1,028ms | 922ms |
checks 통과율 | 99.83% | 99.77% | 99.76% | 99.77% |
실패율과 checks rate는 Complex에서도 Pod Failure, Network Delay 단독 실험과 거의 동일한 수준을 유지했다. 반면 p50이 6.67ms로 개별 실험들보다 높게 나타났는데, Network Delay(300ms 고정 지연)가 mode: all로 모든 Pod에 적용되는 동시에 Pod Failure로 Ready Pod가 감소해 트래픽이 더 집중되면서 발생한 누적 효과로 해석할 수 있다. p99(521ms)는 Network Delay 단독(381ms)보다 높게 나타나 두 장애가 tail latency를 더 악화시켰음을 보여준다.
5. 결론 및 학습 내용
결론
복합 장애 상황에서 fail rate와 checks rate는 개별 장애와 비슷한 수준을 유지했지만, latency는 개별 실험들의 단순 합산보다 더 크게 악화되었다. 이는 두 장애가 독립적으로 작용하는 것이 아니라 상호작용했기 때문으로 볼 수 있다. Network Delay가 모든 Pod에 지연을 주입한 상태에서 Pod Failure까지 겹치면, 유효한 Pod로의 트래픽이 집중되면서 지연의 영향이 더 크게 나타날 수 있다.
학습 내용
•
복합 장애는 개별 장애의 영향을 단순히 더한 것보다 더 심각한 결과로 이어질 수 있다. 이번 실험에서 p99가 Network Delay 단독(381ms)보다 Complex(521ms)에서 더 높게 나타난 것이 그 예다. 단일 장애 시나리오에서 허용 가능한 수준의 degradation이라도, 복합 장애 상황에서는 임계치를 초과할 수 있다.
•
mode: all Network Delay와 mode: one Pod Failure의 조합은 비대칭적인 압력을 만든다. 모든 Pod에 지연이 걸린 상태에서 일부 Pod가 비정상 상태가 되면, 정상 Pod로 트래픽이 집중되면서 지연 효과가 증폭되는 구조가 된다. 이 상호작용은 각 장애를 개별적으로 테스트하는 것만으로는 발견하기 어렵다.
•
이 실험은 알림 체계 구축 이전에 수행되어 복합 장애 상황에서의 alert 동작을 확인하지 못했다. 이후 구축된 alert(PodinfoPodRestarted, PodinfoNotEnoughReadyPods, PodinfoIngressHighLatency) 기준으로 모두 감지 대상에 해당하기 때문에, 복합 장애 상황에서 두 가지 이상의 alert가 동시에 Firing되었을 것이다. 여러 alert가 동시에 Firing되는 패턴이 단일 장애와 구분되는 신호가 되는지, 그리고 각 alert의 for 설정 차이가 수신 순서에 그대로 반영되는지가 다음 과제로 남았다.