[6주차] Control Plane 성능 조정 : Control Plane 모니터링

---

📊 Istio Control Plane 모니터링:
성능 최적화의 첫걸음

• Istio의 Control Plane은 서비스 메시의 핵심으로, 성능을 유지하려면 지속적인 모니터링이 필수입니다.
• istiod는 다양한 메트릭을 제공해 리소스 사용량, 트래픽 부하, 오류율 등을 추적할 수 있게 해줍니다.

---

🔍 Control Plane 모니터링이란?

• istiod는 Control Plane의 성능을 평가할 수 있는 다양한 메트릭을 노출합니다.
  이 메트릭은 리소스 사용량, 트래픽 부하, 오류 발생 빈도 등을 측정해 Control Plane이 제대로 작동하는지, 어디서 문제가 발생할 가능성이 있는지 알려줍니다.
• 실습환경준비

$ kubectl -n istioinaction apply -f services/catalog/kubernetes/catalog.yaml
kubectl -n istioinaction apply -f ch11/catalog-virtualservice.yaml
kubectl -n istioinaction apply -f ch11/catalog-gateway.yaml
serviceaccount/catalog created
service/catalog created
deployment.apps/catalog created
virtualservice.networking.istio.io/catalog created
gateway.networking.istio.io/catalog-gateway created

• 메트릭을 확인하려면 다음 명령어를 사용해 istiod의 메트릭 엔드포인트를 쿼리할 수 있습니다:

$ kubectl exec -it -n istio-system deploy/istiod -- curl localhost:15014/metrics
# HELP citadel_server_csr_count The number of CSRs received by Citadel server.
# TYPE citadel_server_csr_count counter
citadel_server_csr_count 3
...

• 이 메트릭은 Grafana 대시보드를 통해 시각화되어 성능 분석을 더 쉽게 만듭니다.

Control Plane은 메트릭을 통해 성능을 모니터링하며,
Grafana 대시보드로 이를 시각화할 수 있습니다.

---

🌟 Four Golden Signals로 성능 분석하기

• Google의 Site Reliability Engineering 책(https://sre.google/sre-book/table-of-contents)에서 정의한 Four Golden Signals는 서비스 성능을 외부 관점에서 평가하는 네 가지 핵심 메트릭입니다.
  이는 Latency, Saturation, Traffic, Errors로 구성되며, 서비스가 SLO(Service-Level Objectives)를 충족하지 못할 때 원인을 파악하는 데 유용합니다. Istio Control Plane에 이를 어떻게 적용하는지 살펴보겠습니다.

1️⃣ Latency: Data Plane 업데이트 속도

• Latency는 서비스의 응답 속도를 나타내며, Control Plane에서는 Data Plane에 업데이트를 배포하는 데 걸리는 시간을 측정합니다. Latency가 증가하면 성능이 저하된 것이며, 이는 사용자 경험에 영향을 줄 수 있습니다.

주요 메트릭

• pilot_proxy_convergence_time: 푸시 요청이 큐에 들어간 순간부터 워크로드에 배포될 때까지의 전체 시간을 측정합니다.
• pilot_proxy_queue_time: 푸시 요청이 큐에서 대기하는 시간. 이 시간이 길다면 istiod의 동시 처리 능력을 늘리기 위해 수직 확장(Vertical Scaling)이 필요할 수 있습니다.
• pilot_xds_push_time: Envoy 설정을 워크로드에 푸시하는 데 걸리는 시간. 이 시간이 길다면 네트워크 대역폭이 과부하 상태일 가능성이 높습니다.

📊 그림으로 이해하기: Latency 메트릭

• 이 메트릭은 Istio Control Plane Dashboard의 Pilot Push Information 섹션에서 Proxy Push Time 그래프로 확인할 수 있습니다.

📊 Grafana 대시보드 예시

• (99.9%의 푸시가 100ms 미만으로 완료되는 이상적인 상태)

권장 임계값

• Warning: Latency가 1초를 초과하고 10초 이상 지속될 때
• Critical: Latency가 2초를 초과하고 10초 이상 지속될 때
• Latency가 증가하면 성능 저하의 신호이지만, 원인을 파악하려면 다른 신호(Saturation, Traffic, Errors)를 함께 분석해야 합니다.

• Grafana 대시보드에 pilot_proxy_queue_time과 pilot_xds_push_time 메트릭을 추가해 Latency를 더 자세히 모니터링하세요.
• Proxy Queue Time : PromQL - pilot_proxy_queue_time

histogram_quantile(0.5, sum(rate(pilot_proxy_queue_time_bucket[1m])) by (le))
histogram_quantile(0.9, sum(rate(pilot_proxy_queue_time_bucket[1m])) by (le))
histogram_quantile(0.99, sum(rate(pilot_proxy_queue_time_bucket[1m])) by (le))
histogram_quantile(0.999, sum(rate(pilot_proxy_queue_time_bucket[1m])) by (le))

• XDS Push Time : PromQL - pilot_xds_push_time_bucket

histogram_quantile(0.5, sum(rate(pilot_xds_push_time_bucket[1m])) by (le))
histogram_quantile(0.9, sum(rate(pilot_xds_push_time_bucket[1m])) by (le))
histogram_quantile(0.99, sum(rate(pilot_xds_push_time_bucket[1m])) by (le))
histogram_quantile(0.999, sum(rate(pilot_xds_push_time_bucket[1m])) by (le))

Latency는 Data Plane 업데이트 속도를 측정하며,
pilot_proxy_convergence_time을 통해 성능 저하를 감지할 수 있습니다.

---

2️⃣ Saturation: Control Plane의 리소스 사용량

• Saturation은 리소스 사용률을 나타내며, 90% 이상일 경우 시스템이 포화 상태이거나 곧 포화될 가능성이 높습니다.
  포화 상태에서는 푸시 요청이 큐에 오래 대기하며 업데이트가 지연됩니다.
  istiod는 CPU 집약적인 작업을 수행하므로 CPU가 가장 먼저 포화되는 경우가 많습니다.

주요 메트릭

• container_cpu_usage_seconds_total: Kubernetes 컨테이너에서 보고한 CPU 사용량.
• process_cpu_seconds_total: istiod 자체에서 보고한 CPU 사용량.

📊 Grafana 대시보드 예시

 

• CPU 사용량은 대개 유휴 상태에서 낮다가, 서비스 배포 시 Envoy 설정 생성/푸시로 인해 급등합니다. 포화 상태가 지속되면 리소스 증설이나 최적화가 필요합니다.

Saturation은 리소스 사용률을 나타내며,
CPU 포화는 푸시 지연의 주요 원인입니다.

---

3️⃣ Traffic: Control Plane의 부하

• Traffic은 시스템이 처리하는 부하를 측정합니다. Control Plane은 Incoming Traffic(설정 변경 이벤트)과 Outgoing Traffic(Data Plane으로의 푸시)을 모두 처리하므로, 두 방향의 트래픽을 모두 모니터링해야 성능 병목현상의 원인을 파악할 수 있습니다.

Incoming Traffic 메트릭

• pilot_inbound_updates: istiod 인스턴스당 수신한 설정 업데이트 수.
• pilot_push_triggers: 푸시를 유발한 이벤트 수(서비스, 엔드포인트, 또는 Gateway/VirtualService 같은 Istio 커스텀 리소스).
• pilot_services: istiod가 인식하는 서비스 수. 서비스가 많을수록 이벤트 처리에 더 많은 리소스가 필요합니다.

Outgoing Traffic 메트릭

• pilot_xds_pushes: listener, route, cluster, endpoint 업데이트 등 모든 푸시 유형을 측정. Istio Control Plane Dashboard의 Pilot Pushes 그래프로 확인 가능.
• pilot_xds: istiod 인스턴스당 관리하는 워크로드 연결 수. ADS Monitoring 그래프로 확인.
• envoy_cluster_upstream_cx_tx_bytes_total: 네트워크를 통해 전송된 설정 데이터 크기.

📊 Grafana 대시보드 예시

• Pilot Pushes 그래프는 푸시 빈도를 보여줍니다. XDS Active Connections 그래프는 제어 평면에서 관리하는 엔드포인트를 보여줍니다.

• Incoming Traffic이 포화를 유발하면 이벤트 배칭(Batching)을 늘리거나 수평 확장(Scale-Up)이 필요합니다.
  Outgoing Traffic이 문제라면 Sidecar 리소스를 정의해 설정 크기와 푸시 빈도를 줄일 수 있습니다.

Traffic은 Incoming/Outgoing 부하를 측정하며,
병목현상 원인에 따라 다른 최적화 전략을 적용할 수 있습니다.

4️⃣ Errors: Control Plane의 오류율

• Errors는 istiod의 실패율을 나타내며, 포화 상태나 성능 저하 시 자주 발생합니다.
  주요 오류 메트릭은 Istio Control Plane Dashboard의 Pilot Errors 섹션에서 시각화됩니다.

주요 메트릭

메트릭	설명
pilot_total_xds_rejects	설정 푸시 거부 횟수
pilot_xds_’cds/lds/rds/cds’_reject	pilot_total_xds_rejects 메트릭의 부분집합. 어느 API 푸시가 거부됐는지 수사망을 좁히는 데 유용함
pilot_xds_write_timeout	push를 시작할 때 발생한 오류와 타임아웃의 합계
pilot_xds_push_context_errors	엔보이 설정을 생성하는 동안 발생한 이스티오 파일럿 오류 횟수. 주로 이스티오 파일럿의 버그와 관련

• 오류가 증가하면 시스템이 포화 상태이거나 설정 오류가 있을 가능성이 높습니다. 이를 해결하려면 Saturation과 Traffic 메트릭을 함께 분석해야 합니다.

Errors는 포화나 성능 저하를 나타내며,
Pilot Errors 그래프로 모니터링할 수 있습니다.

---

📌 핵심 요약

• Control Plane은 istiod의 메트릭을 통해 성능을 모니터링하며, Grafana 대시보드로 시각화됩니다.
• Four Golden Signals(Latency, Saturation, Traffic, Errors)를 통해 성능 병목현상을 파악합니다.
• Latency: pilot_proxy_convergence_time으로 Data Plane 업데이트 속도를 측정하며, 1~2초 초과 시 경고를 설정합니다.
• Saturation: CPU 사용량(container_cpu_usage_seconds_total)을 모니터링해 포화 상태를 감지합니다.
• Traffic: Incoming(pilot_inbound_updates)과 Outgoing(pilot_xds_pushes) 트래픽을 분석해 부하 원인을 파악합니다.
• Errors: Pilot Errors 그래프로 오류율을 추적하며, 포화 시 증가합니다.

---