Stack: kubeadm · Chaos Mesh · k6 · Prometheus · Grafana · Alertmanager · NGINX Ingress
Period: 2026.03 ~ 2026.06
Team: 개인 프로젝트
1. 무엇을 검증하려 했는가
이전 프로젝트(COME2US)에서 관측 체계를 구축했지만, 알림이 없어 이상 상황을 사람이 대시보드를 보고 있어야만 발견할 수 있다는 한계를 회고로 남겼습니다. 이 프로젝트는 그 공백을 직접 메우기 위한 실험입니다. 의도적으로 장애를 주입했을 때 시스템이 스스로 얼마나 회복하는지, 그 장애를 알림이 제때 감지하는지를 검증했습니다.
2. 실험을 어떻게 설계했는가
•
환경: 로컬 VM에 kubeadm으로 직접 구축한 3노드 클러스터(마스터 1, 워커 2). 대상 워크로드는 podinfo(replica 3, HPA 구성)
•
프로토콜: 정상(기준 구간) → 카오스 주입 → 안정화 관찰의 3구간 구성
기본은 6분(2-2-2분)이며, CPU Stress는 HPA의 scale-out과 cooldown까지 관찰하기 위해 주입을 5분으로 확장(총 10분)
•
진행 순서: 다섯 시나리오를 먼저 알림 없이 수행해 각 장애가 지표에 남기는 신호를 관찰하고, 그 관찰을 근거로 알림 체계를 설계한 뒤 동일 조건으로 재실험해 alert 동작과 MTTD를 검증했습니다(복합 장애는 1차 관찰만 수행)
•
베이스라인 선정: 20 RPS로 두 차례 측정한 결과가 HPA 스케일링 경계에 걸려 서로 달랐고, 실행마다 결과가 달라지는 조건은 비교 기준이 될 수 없다고 판단해 15 RPS를 베이스라인으로 채택
3. 각 장애에서 무엇이 관찰되었는가
시나리오 | 시스템 반응 | 대응 | 핵심 결과 | 관련 문서 |
Pod Failure | replica 분산·재시작 정책으로 흡수, latency에 흔적 거의 없음 | kube-state-metrics 기반 알림 2종 (재시작 / Ready 부족) | MTTD 46초~1분 16초 실측 | |
Network Delay | 전 Pod 지연 — 복구 메커니즘으로 줄일 수 없는 유형. k6에는 보이지만 내부 지표에는 안 보이는 관측 공백 발견 | Ingress latency 패널 + p95 알림 | MTTD 약 1분 46초 | |
Network Loss | 일부 Pod 패킷 손실 → 실패율 상승 | Ingress retry 2회 반복 튜닝 | tries 2·timeout 2 채택 (실패율-p99 균형) | |
CPU Stress | HPA scale-out으로 흡수, max replica 도달 | 알림 3종 (CPU 사용률 / HPA 한계 / CFS Throttling) | MTTD 2분 9초~3분 9초, cooldown으로 Resolved 지연 관찰 | |
Complex (Pod Failure + Delay) | 실패율은 단독 수준 유지, tail latency는 단독보다 악화 | 단일 관찰 실험 — 알림 구축 전 수행 (개별 실험과 4열 비교) | p99 521ms — Delay 단독(381ms) 대비 악화, 복합 장애는 단순 합산이 아님 |
4. 무엇을 배웠는가
•
장애 유형마다 필요한 감지 레이어가 다릅니다. Pod 장애는 latency 지표에 흔적을 남기지 않아 상태 메트릭(kube-state-metrics)이 필요했고, 네트워크 지연은 애플리케이션 내부 지표에 잡히지 않아 Ingress 메트릭이 필요했습니다. 단일 지표 기반 알림으로는 감지 공백이 생깁니다.
•
retry는 실패율과 tail latency를 동시에 개선할 수 없는 트레이드오프를 가지며, 적정값은 SLO가 무엇을 우선하느냐에 따라 달라집니다.
•
복합 장애는 개별 장애의 단순 합산이 아닙니다. 두 장애를 동시에 주입하자 실패율은 단독 수준을 유지했지만 p99는 단독 최악값보다 악화되었고(521ms vs 381ms), 이런 상호작용은 장애를 하나씩 테스트하는 것만으로는 발견할 수 없습니다.
•
알림이 없던 상태에서 감지 시간은 "정의되지 않는 값"이었습니다. 이번 구축으로 감지 시간이 처음으로 측정 가능한 지표(46초~3분 9초)가 되었고, 이 수치의 구성(for 설정, scrape 주기, 전달 지연)까지 분해해 확인했습니다.
5. 다음 실험
이번 실험은 감지 체계 검증까지를 범위로 했습니다. 복구 자체를 개선하는 실험이 다음 단계로 남아 있습니다.
•
PodDisruptionBudget을 설정한 상태에서의 노드 drain 시나리오
•
readiness/liveness probe 파라미터가 복구 시간에 주는 영향 비교
•
비멱등 요청(POST)에 대한 retry 정책 분리 검증
6. 부록
Table