Role: 개인 프로젝트
Period: 2026.03 ~ 2026.06
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를 베이스라인으로 채택
001-baseline001-baseline
001-baseline001-baseline3. 각 장애에서 무엇이 관찰되었는가
시나리오 | 시스템 반응 | 대응 | 핵심 결과 |
Pod Failure | replica 분산·재시작 정책으로 흡수, latency에 흔적 거의 없음 | kube-state-metrics 기반 알림 2종 | MTTD 46초~1분 16초 실측 |
Network Delay | 전 Pod 지연. k6에는 보이지만 내부 지표에는 안 보이는 관측 공백 발견 | Ingress latency 패널 + p95 알림 | MTTD 약 1분 46초 |
Network Loss | 일부 Pod 패킷 손실 → 실패율 상승 | Ingress retry 2회 반복 튜닝 | tries 2·timeout 2 채택 |
CPU Stress | HPA scale-out으로 흡수, max replica 도달 | 알림 3종 분리 구성 | MTTD 2분 9초~3분 9초 |
Complex (Pod Failure + Delay) | 실패율은 단독 수준 유지, tail latency는 악화 | 단일 관찰 — 알림 구축 전 수행 | p99 약 37% 증가(381ms → 521ms) |
4. 무엇을 발견했는가
4.1. 보이지 않는 장애를 어떻게 감지했는가 — Pod Failure
replica 3 중 하나를 강제 종료했을 때, 예상은 지표 어딘가에 흔적이 남는 것이었습니다. 결과는 달랐습니다. readiness probe가 비정상 Pod를 라우팅에서 제외하고 남은 replica가 트래픽을 흡수하면서, latency는 baseline과 구분되지 않았고 실패율도 의미 있게 오르지 않았습니다.
[이미지 1] pod-failure 주입 dashboard
복원력 관점에서는 성공이지만, 운영 관점에서는 문제였습니다. 대시보드 상으로 Ready Pod 수가 줄어드는 것을 확인할 수 있지만, 요청 지연·실패율 기반 알림만 있는 시스템에서는 이 대시보드를 지속적으로 확인하지 않는 이상 장애를 모른 채 지나간다는 뜻이기 때문입니다. 그래서 트래픽이 아니라 상태를 보는 알림을 설계했습니다. kube-state-metrics 기반으로 컨테이너 재시작 발생과 Ready Pod 부족을 분리했는데, 전자는 원인 조사, 후자는 가용량 확보로 운영자의 대응이 다르기 때문에 이와 같이 설계했습니다.
동일 조건 재실험에서 두 알림 모두 Discord로 수신되었고, chaos 주입 시각과 메시지 timestamp를 대조해 MTTD 46초~1분 16초를 실측했습니다. 이 수치의 구성(알림 룰의 for 대기, scrape 주기, 전달 지연)까지 분해해 확인했습니다. 이러한 알림 체계의 설계를 통해 감지 시간을 줄였다기보다, 정의되지 않던 감지 시간을 측정 가능한 지표로 만든 것이 성과였습니다.
[이미지 2] 디스코드 알림 수신
4.2. retry의 비용을 어떻게 측정했는가 — Network Loss
일부 Pod에 패킷 손실을 주입하자 실패율이 눈에 띄게 상승했습니다. 대응으로 NGINX Ingress에 retry를 적용했는데, 첫 설정(tries 3, timeout 3)은 실패율을 낮추는 데 성공했지만 p99가 오히려 악화되었습니다. 실패할 요청이 여러 번의 재시도를 거치며 응답 시간이 오히려 길어진 것이 이유였습니다. 따라서 두 번째 설정(tries 2, timeout 2)에서 실패율 개선을 유지하면서 tail latency 악화를 줄인 균형점을 찾아 최종 채택했습니다.
...
nginx.ingress.kubernetes.io/proxy-next-upstream-tries: "2"
nginx.ingress.kubernetes.io/proxy-next-upstream-timeout: "2"
YAML
복사
[이미지 3] retry 설정별 실패율•p99 비교 그래프
구성 | 실패율 | p99 |
개선 전 (retry 없음) | 0.78% | 870.26ms |
1차 — tries 3 · timeout 3 | 0.46% | 1,002.57ms (악화) |
2차 — tries 2 · timeout 2 (채택) | 0.56% | 872.13ms (개선 전 수준 회복) |
이 실험으로 확인한 것은 단순히 retry를 높이는 것만으로 실패율과 tail latency를 동시에 개선할 수 없다는 점, 그리고 적정값은 SLO가 무엇을 우선하느냐에 따라 달라진다는 점입니다. 비멱등 요청(POST)에 대한 retry 정책 분리는 과제로 남겼습니다.
4.3. 복합 장애에서 무엇이 달랐는가 — Complex
Pod Failure와 Network Delay를 동시에 주입했습니다. 실패율은 단독 장애 수준을 유지했지만, p99는 단독 Network Delay의 p99 381ms보다 약 37% 증가한 521ms를 기록했습니다. 각 장애를 개별로 견디는 시스템이라도 장애가 겹치면 tail latency에서 영향이 증폭될 수 있으며, 이런 상호작용은 장애를 하나씩 테스트하는 것만으로는 발견할 수 없습니다.
4.4. 그 외의 발견
Network Delay — 측정 지점의 간극k6(사용자 관점)에는 명확히 보이는 지연이 애플리케이션 내부 지표에는 잡히지 않았습니다. 지연이 애플리케이션 바깥(네트워크 경로)에서 발생했기 때문입니다. 사용자가 겪는 지연과 애플리케이션이 아는 지연 사이의 공백을 Ingress 레벨 latency 패널과 p95 알림을 추가하는 것으로 보완했습니다.
[이미지 4] Ingress Latency 패널 (Grafana Dashboard)
CPU Stress부하는 HPA scale-out으로 흡수되었지만, CPU 사용률 상승·HPA 한계 도달·CFS Throttling은 각각 원인과 대응이 달라 세 개의 알림으로 분리 구성했습니다. 재실험에서 셋 모두 수신을 확인했고, HPA cooldown으로 인해 Resolved 통지가 지연되는 동작까지 관찰했습니다.
5. 무엇이 남았는가
이번 PoC는 감지 체계 검증까지였습니다. 복구 자체를 개선하는 실험이 다음 단계로 남아 있습니다.
•
PodDisruptionBudget을 설정한 상태에서의 노드 drain 시나리오
•
readiness/liveness probe 파라미터가 복구 시간에 주는 영향 비교
•
비멱등 요청(POST)에 대한 retry 정책 분리 검증
6. 어떤 결과를 만들었는가
영역 | 결과 |
감지 체계 | 알림 6종 설계, 유형별 MTTD 46초~3분 9초 실측 |
복원력 검증 | Pod Failure·CPU Stress는 replica 분산과 HPA로 흡수됨을 확인 |
네트워크 | Ingress retry의 실패율-tail latency 트레이드오프 실측, tries 2·timeout 2 채택 |
복합 장애 | p99 악화(381ms → 521ms) — 개별 장애의 단순 합산이 아님을 확인 |
문서화 | 장애 시나리오 결과 문서, 트러블슈팅, CNI 선정 기술 검토 |
상세 기록:Chaos LabChaos Lab
Chaos LabChaos Lab