003-network delay

Tag

Experiments

Network Delay — 네트워크 지연 주입 및 관측성 개선

목적: 모든 podinfo Pod에 네트워크 지연을 주입했을 때의 서비스 영향을 관찰하고, 기존 대시보드의 관측성 공백을 보완해 검증한다.

1. 개요

Chaos Mesh의 NetworkChaos(action: delay, mode: all)로 podinfo의 모든 Pod에 동시에 네트워크 지연을 주입하고, k6로 동일한 부하를 주며 서비스 영향을 관찰했다. 이 실험은 다음 두 단계로 진행했다.

단계	내용
1차 (개선 전)	Network Delay 주입, 기존 Latency Percentiles 패널로 관찰
2차 (개선 후)	App Latency / Ingress Latency 패널 분리 추가, PodinfoIngressHighLatency alert 구축 후 재실험

mode: all로 모든 Pod에 동시에 지연을 주입했기 때문에, retry나 HPA로 우회할 수 있는 경로가 거의 없는 시나리오다. 따라서 이번 개선의 목적은 latency 자체를 줄이는 것이 아니라, 기존 application-side latency 지표만으로는 보이지 않던 지연을 Ingress-side latency 지표로 보완해 관측성을 높이는 것이다.

2. 실험 환경

•

대상 서비스: podinfo (http://podinfo.chaos-lab.local)

•

부하 도구: k6 (Rate 15 req/s, Duration 6m)

•

장애 주입: Chaos Mesh (NetworkChaos)

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: podinfo-network-delay
  namespace: chaos-mesh
spec:
  action: delay
  mode: all
  selector:
    namespaces:
      - podinfo
    labelSelectors:
      app.kubernetes.io/name: podinfo
  delay:
    latency: "300ms"
    correlation: "100"
    jitter: "50ms"
  duration: "2m"
YAML
복사

mode: all로 podinfo 레이블을 가진 모든 Pod에 2분간 300ms(±50ms jitter) 지연을 주입했다. 일부 Pod만 지연시키는 것이 아니라 전체 Pod에 동일하게 적용했기 때문에, 정상 Pod로 우회하는 retry나 추가 replica를 늘리는 HPA 방식으로는 지연을 회피할 수 없는 조건이다.

•

모니터링: Prometheus + Grafana + Alertmanager(Discord 연동)

3. 1차 실험 (개선 전)

결과

지표	값
총 요청 수	5,385 건
실패율	0.46% (25건)
p50 latency	3.30ms
p90 latency	343.45ms
p95 latency	350.33ms
p99 latency	381.86ms
max latency	1,028ms
checks 통과율	99.76%

Grafana 대시보드

1차 — Overview / Pod Health / Traffic & Latency

k6 측정 기준으로는 p95가 350ms까지 상승해 지연 주입이 명확하게 관측되었다. p50(3.30ms)은 baseline 수준을 유지한 반면 p90 이상부터 급격히 상승한 것은, 6분 테스트 구간 중 실제로 지연이 적용된 chaos 주입 구간(2분)이 전체의 약 1/3에 해당하기 때문이다. 지연이 없는 구간의 요청이 다수를 차지해 p50에는 거의 반영되지 않지만, 상위 percentile에서는 지연이 적용된 구간의 요청들이 누적되어 나타난다.

하지만 당시 대시보드의 "Latency Percentiles" 패널은 애플리케이션 내부에서 측정한 latency를 기준으로 하고 있어, k6가 클라이언트 관점에서 측정한 e2e latency와 측정 지점이 달랐다. 그 결과 k6 summary 상으로는 분명한 지연이 있었음에도, 같은 시간대의 Grafana 대시보드만으로는 지연의 정도를 직관적으로 파악하기 어려웠다.

4. 관측성 개선 — Ingress Latency 패널 및 Alert 추가

k6의 e2e latency와 애플리케이션 내부 latency 사이의 측정 지점 차이를 보완하기 위해, NGINX Ingress Controller의 request duration histogram인 nginx_ingress_controller_request_duration_seconds_bucket을 기준으로 한 패널과 alert를 추가했다.

•

기존 "Latency Percentiles" 패널은 "App Latency"로 이름을 변경했다.

•

Ingress 단에서 측정한 latency를 별도로 보여주는 "Ingress Latency" 패널을 신규로 추가했다.

•

Ingress 기준 p95 latency가 200ms를 1분 이상 초과하면 Discord로 알리는 alert를 구축했다.

- alert: PodinfoIngressHighLatency
  expr: |
    histogram_quantile(
      0.95,
      sum by (le) (
        rate(nginx_ingress_controller_request_duration_seconds_bucket{host="podinfo.chaos-lab.local"}[2m])
      )
    ) > 0.2
  for: 1m
  labels:
    severity: warning
    service: podinfo
    namespace: podinfo
  annotations:
    summary: "podinfo ingress latency is high"
    description: "podinfo ingress p95 latency is above 200ms for more than 1 minute. Check Network Delay, ingress-to-upstream network path, or upstream response latency."
YAML
복사

알람 동작 확인

Network Delay 주입과 함께 PodinfoIngressHighLatency alert가 정상적으로 Firing 되었고, 장애 종료 후 Resolved로 전환되는 것을 확인했다.

2차 실험(k6 기록 기준 chaos 주입 시각 11:47:55 UTC, baseline 2분 + chaos 2분 구성을 역산)을 기준으로 Discord 알림 수신 시각을 비교하면 다음과 같다.

Alert	Discord 수신 시각 (UTC)	Discord 수신 기준 MTTD
PodinfoIngressHighLatency	11:49:41.341	약 1분 46초

PodinfoIngressHighLatency는 for: 1m으로 설정되어 있어, p95 latency가 200ms를 초과하는 상태가 1분간 지속된 후에야 Firing된다. 이 alert rule 자체의 for 대기시간이 측정된 MTTD의 상당 부분을 차지하므로, 더 빠른 감지가 필요하다면 for 값을 줄이는 트레이드오프(false positive 위험 증가)를 검토할 수 있다.

5. 2차 실험 (개선 후 — 대시보드/Alert 동작 검증)

결과

지표	1차 (개선 전)	2차 (개선 후)	비교
실패율	0.46% (25건)	0.48% (26건)	유사
p50 latency	3.30ms	4.66ms	유사
p90 latency	343.45ms	335.69ms	유사
p95 latency	350.33ms	338.93ms	유사
p99 latency	381.86ms	414.66ms	유사
max latency	1,028ms	920ms	유사
checks 통과율	99.76%	99.76%	동일

이번 2차 실험의 목적은 latency 개선 여부를 비교하는 것이 아니라, 새로 추가한 App/Ingress Latency 패널과 PodinfoIngressHighLatency alert가 의도대로 동작하는지 검증하는 것이었다. 실제로 1차와 2차의 k6 지표는 거의 동일한 수준으로 나타났으며, 이는 같은 chaos 조건(전체 Pod 대상 300ms 지연)을 그대로 재현했기 때문이다.

Grafana 대시보드

2차 — Overview / Pod Health / Traffic & Latency

2차 대시보드에서는 "App Latency"와 "Ingress Latency" 패널이 분리되어 있고, Ingress Latency 패널에서 chaos 주입 구간에 p95/p99가 함께 급증하는 모습이 명확하게 관측되었다. App Latency 패널에서도 같은 구간에 일부 변화가 보이지만, Ingress Latency 패널이 chaos 주입 구간과 더 뚜렷하게 일치해 지연 발생 시점을 식별하기에 더 적합했다. 같은 구간에 PodinfoIngressHighLatency alert가 Discord로 정상 수신되었다.

6. 결론 및 학습 내용

결론

Network Delay는 mode: all로 전체 Pod에 동일하게 적용되는 장애이기 때문에, retry나 HPA 같은 기존의 복구 메커니즘으로는 지연 자체를 줄일 수 없는 유형이다. 이번 실험에서 1차와 2차의 latency 지표가 거의 동일하게 나타난 것도 이를 뒷받침한다. 이 실험에서 실질적으로 달성한 것은 latency 감소가 아니라, k6에서는 분명히 보이던 지연이 기존 Grafana 대시보드에서는 보이지 않던 관측성 공백을 발견하고, Ingress 메트릭 기반 패널과 alert로 그 공백을 메운 것이다. alert 구축 후에는 장애 발생 후 약 1분 46초 만에 Discord로 알림이 수신되는 것을 실측으로 확인했으며, 이 수치의 상당 부분은 alert rule의 for: 1m 설정에서 기인한다.

학습 내용

•

동일한 "latency"라는 이름의 지표도 측정 지점에 따라 다른 값을 가질 수 있다. k6는 클라이언트가 응답을 받기까지의 전체 시간(e2e)을 측정하지만, 애플리케이션 내부 latency 메트릭은 요청이 애플리케이션 코드에 도달한 이후의 처리 시간만을 측정한다. 이번에 NetworkChaos로 주입한 지연은 애플리케이션 내부 처리 시간보다 Ingress가 upstream Pod의 응답을 기다리는 구간에서 더 뚜렷하게 관찰되었다. 따라서 애플리케이션 내부 지표만으로는 Network Delay의 영향을 충분히 설명하기 어렵고, Ingress-side latency를 함께 확인해야 한다.

•

이런 측정 지점의 간극을 메우려면 클라이언트와 애플리케이션 사이에 위치한 중간 지점(Ingress Controller, 서비스 메시 사이드카 등)의 메트릭을 추가로 확보해야 한다. 이번에는 NGINX Ingress Controller가 노출하는 request duration histogram을 활용했는데, 별도의 계측 코드 추가 없이 기존 인프라 구성요소의 메트릭만으로 관측성 공백을 메울 수 있었다는 점이 의미가 있다.

•

alert의 임계값(p95 > 200ms, 1분 지속)은 이번 실험에서 주입한 300ms 지연을 기준으로 설정한 값이다. 실제 운영 환경에 적용하려면 SLO 목표치와 정상 상태에서의 baseline latency를 함께 고려해 임계값을 재조정해야 한다.

부록. Alertmanager 규칙

항목	내용
알람명	PodinfoIngressHighLatency
조건	Ingress 기준 p95 latency > 200ms
메트릭	nginx_ingress_controller_request_duration_seconds_bucket
for	1m
심각도	warning