[Istio] 관측가능성 (Observability - Visualize )

xgro·2025년 5월 2일

Istio

목록 보기

8/17

📌 Notice

Istio Hands-on Study (=Istio)
직접 실습을 통해 Isito를 배포 및 설정하는 내용을 정리한 블로그입니다.

CloudNetaStudy 그룹에서 스터디를 진행하고 있습니다.

Gasida님께 다시한번 🙇 감사드립니다.

EKS 관련 이전 스터디 내용은 아래 링크를 통해 확인할 수 있습니다.

[AEWS] AWS EKS 스터디

[PKOS] KOPS를 이용한 AWS에 쿠버네티스 배포

[DOIK] Database Operator In Kubernetes study

[KANS3] Kubernetes Advanced Networking Study

📌 Overview

서비스 메시의 운영과 관측을 효과적으로 수행하기 위해서는 수집된 데이터를 시각적으로 해석할 수 있는 도구들이 필수적입니다.

이번 블로그에서는 Istio가 수집한 메트릭과 트레이싱 정보를 기반으로,
다음과 같은 세 가지 대표적인 시각화 도구를 실습을 통해 다뤄봅니다:

Grafana: Prometheus와 연동해 메트릭을 대시보드 형태로 시각화
Jaeger: 분산 트랜잭션의 흐름을 추적하고 병목 지점을 확인
Kiali: 서비스 메시 내의 호출 관계와 상태를 네트워크 그래프로 표현

앞서 구축한 Istio 환경 위에 이 도구들을 연동하여, 관측 가능성을 실제로 어떻게 구현하는지를 단계별로 알아봅니다.

이를 통해 단순히 수집된 데이터를 보는 것을 넘어서, 서비스 간 관계, 성능 병목, 장애 원인을 직관적으로 파악할 수 있는 기반을 마련하게 됩니다.

📌 Istio 관측 도구로 메시 데이터 시각화하기

이번 블로그는 앞서 정리한 챕터 7장의 내용인 [Istio] 관측가능성 (Observability)
의 환경을 그대로 사용합니다.

👉 Step 01. Grafana로 Istio 서비스 및 컨트롤 플레인 메트릭 시각화

Istio에서 수집한 서비스 및 컨트롤 플레인 메트릭을 Grafana를 통해 시각적으로 확인합니다.

기본적으로 Prometheus에서 수집한 시계열 데이터를 Grafana 대시보드를 통해 실시간으로 시각화하며, 이를 통해 운영 중인 서비스의 상태를 명확히 파악할 수 있습니다.

✅ 이스티오의 Grafana 대시보드 설정하기

Grafana에 접속하여 Istio 관련 대시보드를 구성합니다.
웹 브라우저에서 다음 주소로 접속하고 로그인합니다. 기본 계정은 admin / prom-operator입니다.

# Grafana 접속 : admin / prom-operator
open http://127.0.0.1:30002
open http://127.0.0.1:30002/dashboards

# 데이터 발생을 위한 반복 호출
while true; do curl -s http://webapp.istioinaction.io:30000/api/catalog ; date "+%Y-%m-%d %H:%M:%S" ; sleep 1; echo; done

대시보드는 책에서 제공하는 JSON 파일을 ConfigMap으로 생성한 뒤, Grafana에서 인식할 수 있도록 레이블을 지정해 구성합니다.

cd ch8

kubectl -n prometheus create cm istio-dashboards \
--from-file=pilot-dashboard.json=dashboards/pilot-dashboard.json \
--from-file=istio-workload-dashboard.json=dashboards/istio-workload-dashboard.json \
--from-file=istio-service-dashboard.json=dashboards/istio-service-dashboard.json \
--from-file=istio-performance-dashboard.json=dashboards/istio-performance-dashboard.json \
--from-file=istio-mesh-dashboard.json=dashboards/istio-mesh-dashboard.json \
--from-file=istio-extension-dashboard.json=dashboards/istio-extension-dashboard.json

# 생성 확인
cd ..
kubectl describe cm -n prometheus istio-dashboards

# Grafana가 configmap을 자동 인식하도록 label 지정
kubectl label -n prometheus cm istio-dashboards grafana_dashboard=1

Grafana 오퍼레이터는 위 ConfigMap을 자동으로 마운트하여 대시보드를 로딩합니다. 아래와 같이 로그를 통해 확인할 수 있습니다.

kubectl stern -n prometheus prom-grafana
# 로그 예시
prom-grafana-d7f5cb646-555zp grafana-sc-dashboard [...] File in configmap pilot-dashboard.json ADDED

✅ 컨트롤 플레인 메트릭 보기

Grafana 대시보드에서 Istio Control Plane 대시보드를 선택하면, CPU·메모리·고루틴 외에도 오류, 설정 동기화 문제, 데이터플레인 커넥션 수 등의 다양한 메트릭을 확인할 수 있습니다.
특정 그래프를 클릭하여 Explore 탭에서 원본 쿼리를 확인할 수도 있습니다.

예시 쿼리:

sum(irate(pilot_xds_pushes{type="rds"}[1m]))

해당 메트릭은 Prometheus에서도 직접 확인할 수 있습니다:
http://127.0.0.1:30001/graph?g0.expr=pilot_xds_pushes&g0.tab=1&g0.stacked=0&g0.range_input=15m

✅ 데이터 플레인 메트릭 보기

Grafana에서 Istio Service 대시보드를 선택하면, 실제 서비스(webapp 등)의 트래픽 및 응답 관련 메트릭을 확인할 수 있습니다.

표준 Istio 메트릭을 기반으로 대시보드가 구성되어 있으며, 필요에 따라 커스텀 메트릭이나 Envoy 내부 메트릭을 추가할 수도 있습니다.

엔보이 관련 세부 설정은 7장에서 참고할 수 있습니다.

👉 Step 02. 분산 트레이싱 개념 이해하기

마이크로서비스 환경에서는 요청 하나가 여러 서비스를 거쳐 처리됩니다. 이때 어디서 문제가 발생했는지를 추적하기 위해 분산 트레이싱이 필요합니다.

이번 과정에서는 분산 트레이싱의 필요성과 기본 개념을 설명합니다.

마이크로서비스에서의 요청 흐름 추적의 중요성

마이크로서비스로 구성된 시스템은 하나의 요청을 처리하기 위해 여러 서비스가 연쇄적으로 호출되는 구조입니다.

이러한 시스템에서는 요청 경로 중 어디에서 문제가 발생했는지를 파악하는 것이 매우 중요합니다.

빠른 진단과 복구를 위해 전체 요청의 흐름을 시각적으로 파악할 수 있는 메커니즘이 필요하며, 그것이 바로 분산 트레이싱(distributed tracing)입니다.

모놀리스와의 디버깅 방식 차이

모놀리스 구조에서는 런타임 프로파일러나 메모리 분석 도구 등을 사용해 하나의 프로세스 안에서 문제를 추적할 수 있습니다.

하지만 마이크로서비스 아키텍처에서는 서비스 간 경계가 존재하므로, 요청이 어느 서비스에서 얼마나 지연되었는지를 추적하려면 전혀 다른 접근 방식이 필요합니다.

Google Dapper와 트레이싱 개념의 기원

분산 트레이싱의 개념은 구글의 Dapper 논문에서 소개되었습니다.

이 논문에서는 요청이 여러 서비스에 걸쳐 처리될 때, 상관관계 ID(correlation ID)와 트레이스 ID(trace ID)를 통해 호출 관계를 추적하는 방법을 제안했습니다.

Istio가 트레이스 메타데이터를 처리하는 방식

Istio의 데이터 플레인은 요청이 서비스 메시를 통과할 때 이러한 트레이스 메타데이터를 자동으로 주입할 수 있습니다.

예를 들어 x-request-id 같은 HTTP 헤더가 대표적인 트레이스 헤더입니다.

Istio는 신뢰할 수 없는 외부에서 온 헤더는 제거하고, 메시 내부에서 생성한 메타데이터만 유지함으로써 신뢰성과 일관성을 보장합니다.

OpenTelemetry와 OpenTracing의 역할

OpenTelemetry는 메트릭, 로그, 트레이스를 수집하기 위한 API, SDK, 도구들의 집합입니다.
→ https://opentelemetry.io/
OpenTracing은 그 중 트레이싱에 특화된 사양이며, 서비스 간 요청 흐름을 추적하기 위한 스팬(span) 생성 및 전파 방법을 정의합니다.
→ https://opentracing.io/

분산 트레이싱은 어느 정도 애플리케이션 개발자의 협조를 필요로 합니다.
예를 들어,

요청을 받을 때 트레이스 헤더를 읽어들이고,

외부로 요청을 보낼 때 해당 헤더를 함께 전달하며,

내부적으로 스팬(span)을 생성하고 타이밍 정보 등을 기록해야 합니다.

즉, 개발자가 직접 요청에 주석(annotation)을 붙이고, 관련 ID들을 전달해야 하는 부담이 있습니다.

Istio가 주는 이점

Istio를 사용하면 이러한 부담을 줄일 수 있습니다.
사이드카 프록시가 요청을 가로채 트레이스 헤더를 자동으로 주입하거나 전파할 수 있기 때문에,
코드를 수정하지 않고도 기본적인 분산 트레이싱을 구현할 수 있습니다.

✅ 분산 트레이싱은 어떻게 작동하는가?

OpenTracing 기반의 분산 트레이싱은 기본적으로 애플리케이션이 요청 처리 중 스팬(Span)을 생성하고, 이를 트레이싱 엔진과 공유한 뒤, 다음 호출 대상 서비스로 트레이스 콘텍스트(trace context)를 전파하는 방식으로 작동합니다.

스팬은 하나의 서비스나 구성 요소 내에서 수행된 작업의 단위를 나타내며, 다음과 같은 정보를 포함합니다:

작업의 시작 시각과 종료 시각

작업 이름

태그

로그

이러한 스팬은 요청 흐름의 각 구간에서 생성되며, 전체 요청을 구성하는 단위가 됩니다.

트레이스(Trace)란?

여러 개의 스팬은 트레이스 컨텍스트를 통해 서로 연결되어 하나의 트레이스(Trace)를 구성합니다.
트레이스는 서비스 간 호출의 인과 관계, 순서, 지연 시간 등을 나타내는 구조입니다.

트레이스는 다음과 같은 식별자를 포함합니다:

Trace ID: 전체 요청을 식별하는 고유한 값

Span ID: 해당 작업(스팬)을 식별하는 고유한 값

서비스 간 호출이 발생할 때 이 정보를 헤더에 담아 다음 서비스로 전파해야 전체 트레이스를 재구성할 수 있습니다.

Istio와 스팬 전파

Istio는 다음과 같은 Zipkin 호환 트레이싱 헤더를 사용해 트레이스를 전파합니다:

x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context

사이드카 프록시는 요청을 수신할 때 이 헤더가 없으면 새로운 트레이스를 시작하고,
기존 트레이스가 있다면 이어서 후속 스팬을 생성합니다.
그리고 이 트레이스 헤더를 다음 서비스로 전파해 전체 호출 흐름을 연결합니다.

애플리케이션의 책임: 헤더 전파

Istio가 분산 트레이싱을 지원하더라도, 요청 흐름 전체를 연결하기 위해서는 애플리케이션이 트레이싱 헤더를 다음 호출에도 포함시켜야 합니다.

그렇지 않으면, 서비스 간 연결 고리가 끊어져 일부 스팬이 트레이스에 포함되지 않습니다.

애플리케이션이 트레이스 헤더를 전파하지 않으면 요청의 스팬 전부가 손실됩니다.
Istio는 어떤 요청이 어떤 결과인지 서비스 간 호출 관계를 알 수 없기 때문에, 헤더 전파는 반드시 애플리케이션이 책임져야 합니다.

오픈트레이싱 구현체 예시

대표적인 분산 트레이싱 시스템들은 다음과 같습니다:

Jaeger
Zipkin
Lightstep
Instana

Istio는 이러한 트레이싱 백엔드에 직접 스팬 데이터를 전달할 수 있으므로, 별도의 언어 전용 라이브러리 없이도 트레이싱을 구현할 수 있습니다.

✅ 분산 트레이싱 시스템 설치하기

분산 트레이싱 시스템인 Jaeger를 Istio와 연동하기 위해 설치하는 실습입니다.

Jaeger는 일반적으로 DB나 Collector 설정 등 복잡한 구성이 필요하지만, 실습에서는 간단히 실행 가능한 All-in-One 배포 샘플을 사용합니다.

이 샘플은 Zipkin 호환 서비스도 자동으로 포함되어 있어 Istio와 바로 연결됩니다.

실습 환경 구성: All-in-One Jaeger 설치

Istio의 samples/addons 디렉터리에는 예제용 Jaeger YAML 파일이 포함되어 있습니다.
이 파일을 그대로 사용해 설치를 진행합니다.

# myk8s-control-plane 진입 후 설치 진행
docker exec -it myk8s-control-plane bash
-----------------------------------

# 설치 파일 확인
pwd
ls istio-$ISTIOV/samples/addons

# Jaeger 배포 파일 확인
cat istio-$ISTIOV/samples/addons/jaeger.yaml

# 설치 실행
kubectl apply -f istio-$ISTIOV/samples/addons/jaeger.yaml
# 출력 예시:
# deployment.apps/jaeger created
# service/tracing created
# service/zipkin created
# service/jaeger-collector created

# 컨테이너 빠져나오기
exit
-----------------------------------

Jaeger는 Zipkin과 호환되며, Istio는 이 Zipkin 엔드포인트로 트레이스를 전송합니다.
설치가 완료되면 관련 리소스를 아래 명령어로 확인할 수 있습니다:

kubectl get deploy,pod,svc,ep -n istio-system

Jaeger 대시보드 노출: NodePort 수정

기본 서비스 포트는 ClusterIP이므로, NodePort 방식으로 변경해 외부에서 접근 가능하도록 설정합니다:

# 기존 서비스 상태 확인
kubectl describe svc -n istio-system tracing
# 예시 출력:
# Port:          http-query  80/TCP
# TargetPort:    16686/TCP
# NodePort:      http-query  31345/TCP

# NodePort 30004로 변경
kubectl patch svc -n istio-system tracing -p '{
  "spec": {
    "type": "NodePort",
    "ports": [
      {
        "port": 80,
        "targetPort": 16686,
        "nodePort": 30004
      }
    ]
  }
}'

예거 UI 접속

설정이 완료되면 아래 주소를 통해 Jaeger UI에 접속할 수 있습니다:

open http://127.0.0.1:30004

📌 참고: Jaeger는 Zipkin 형식의 트레이싱 데이터를 수신할 수 있으므로, Istio의 기본 Zipkin 설정으로도 동작합니다.
https://www.jaegertracing.io/docs/1.22/operator/#production-strategy

필요하다면 운영 환경에서 사용할 수 있는 Jaeger Operator 방식의 구성도 공식 문서를 참고해 확장할 수 있습니다.

✅ 분산 트레이싱을 수행하도록 이스티오 설정하기

Istio는 분산 트레이싱 설정을 메시 전체, 네임스페이스, 워크로드 단위로 세분화하여 구성할 수 있습니다.
이번 실습에서는 메시 전역 설정과 워크로드 단위 설정을 다룹니다.

Istio 1.12부터 도입된 Telemetry API

Istio 1.12부터는 기존 설정보다 세분화된 Telemetry API가 도입되어, 로깅, 메트릭, 트레이싱을 명시적으로 제어할 수 있습니다.
다만 이 실습에서는 기존 IstioOperator와 애노테이션 설정을 기준으로 설명합니다.

방법 1: Istio 설치 시 트레이싱 설정 포함하기

설치 시 IstioOperator 리소스를 활용하여 트레이싱 백엔드를 지정할 수 있습니다.
Istio는 다음과 같은 백엔드를 지원합니다:

Zipkin
Jaeger (Zipkin 호환)
Datadog
Stackdriver
Lightstep 등

예를 들어, Zipkin 주소를 설정하여 Jaeger 연동을 구성합니다:

# IstioOperator 리소스 작성 예시
cat << EOF > install-istio-tracing-zipkin.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
spec:
  meshConfig:
    defaultConfig:
      tracing:
        sampling: 100
        zipkin:
          address: zipkin.istio-system:9411
EOF

# 적용
docker exec -it myk8s-control-plane bash
-----------------------------------
istioctl install -y -f install-istio-tracing-zipkin.yaml
exit
-----------------------------------

적용 후 설정을 확인합니다:

kubectl describe cm -n istio-system istio

방법 2: ConfigMap으로 설정 변경 (실습에서는 생략)

Istio 설치 이후 istio ConfigMap을 직접 편집하여 defaultConfig.tracing 값을 수정할 수도 있습니다:

kubectl edit cm -n istio-system istio

방법 3: 워크로드별 트레이싱 설정 (Pod 애노테이션 방식)

특정 워크로드에만 트레이싱 설정을 적용하고 싶다면, Deployment 리소스에 다음과 같은 애노테이션을 추가합니다:

template:
  metadata:
    annotations:
      proxy.istio.io/config: |
        tracing:
          zipkin:
            address: zipkin.istio-system:9411

기본 트레이싱 헤더 자동 주입 테스트

Istio가 Zipkin 헤더를 자동으로 주입하고 전파하는지 확인하기 위해,
외부 서비스(http://httpbin.org)에 트래픽을 라우팅하고 헤더를 확인합니다.

# VirtualService, Gateway, ServiceEntry 배포
kubectl apply -n istioinaction -f ch8/tracing/thin-httpbin-virtualservice.yaml

# 도메인 임시 등록
echo "127.0.0.1 httpbin.istioinaction.io" | sudo tee -a /etc/hosts

헤더 확인 요청을 보냅니다:

curl -s http://httpbin.istioinaction.io:30000/headers | jq

예상 응답 결과 (일부):

{
  "headers": {
    "X-B3-Sampled": "1",
    "X-B3-Spanid": "3726f7dcb215ac12",
    "X-B3-Traceid": "9a4a7076cf8b5f633726f7dcb215ac12"
  }
}

이 결과는 Istio 프록시가 요청에 자동으로 Zipkin 헤더를 주입했음을 의미합니다.
이러한 헤더는 Jaeger 등 백엔드 트레이싱 시스템으로 전달되어 스팬 생성에 사용됩니다.

이제 트레이싱 헤더 전파가 잘 이루어졌는지 Jaeger UI에서 확인할 수 있습니다.
다음 Step에서는 분산 트레이싱 데이터를 어떻게 시각화하는지 확인해보겠습니다.

✅ 분산 트레이싱 데이터 보기 (Jaeger UI)

분산 트레이싱이 정상적으로 설정되었다면, Istio 프록시가 생성한 스팬(Span) 정보는 Jaeger와 같은 분산 트레이싱 시스템으로 전송됩니다.

이제 Jaeger UI를 통해 트레이스를 조회하고, 서비스 간 요청 흐름을 시각적으로 확인할 수 있습니다.

Jaeger UI에서 트레이스 확인하기

브라우저에서 다음 주소로 접속합니다:
http://127.0.0.1:30004
Service 드롭다운에서 istio-ingressgateway를 선택합니다.
좌측 하단의 Find Traces 버튼을 클릭하면 수집된 트레이스 목록이 표시됩니다.

트레이스가 보이지 않을 경우: 트래픽 유도

Jaeger에 트레이스가 보이지 않는다면, 트래픽이 충분히 발생하지 않은 것입니다.
아래와 같이 curl 명령어로 요청을 반복 실행하여 스팬을 생성합니다:

# httpbin 라우팅 확인용 트래픽
curl -s http://httpbin.istioinaction.io:30000/headers | jq
curl -s http://httpbin.istioinaction.io:30000/headers | jq
...

# webapp 서비스 트래픽
curl -s http://webapp.istioinaction.io:30000/api/catalog | jq
curl -s http://webapp.istioinaction.io:30000/api/catalog | jq
...

트래픽을 유도한 후 다시 Jaeger UI의 Find Traces를 눌러 확인하면 트레이스가 생성되어 있을 것입니다.

특정 트레이스를 클릭하면 트레이스를 구성하는 스팬과 같이 좀 더 세부적인 정보를 볼 수 있다.

트레이스가 정확히 연결되기 위한 헤더 전파 요건

Istio는 분산 트레이싱용 헤더를 자동 주입하지만, 애플리케이션이 이 헤더를 다음 호출로 전파하지 않으면 트레이스 연결이 끊어집니다.
정확한 트레이스 구성을 위해 다음과 같은 헤더를 반드시 포함시켜야 합니다:

x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context

⚠️ 이 헤더들은 프록시가 자동으로 외부 호출에 추가해줄 수 없기 때문에,
애플리케이션 코드가 수신한 헤더를 저장했다가 이후 호출 시 직접 삽입해야 합니다.

이제 트레이스 흐름이 제대로 이어지고 있는지 Jaeger UI에서 구조적으로 확인할 수 있습니다.

✅ 트레이스 샘플링, 강제 트레이스, 커스텀 태그

분산 트레이싱은 매우 유용하지만, 모든 요청을 추적하면 성능에 부담이 생길 수 있습니다.

따라서 샘플링 비율을 조정하거나, 특정 요청만 강제 트레이싱하고, 필요한 경우에만 태그를 추가하는 설정이 중요합니다.

🔧 메시의 트레이스 샘플링 비율 조정

기본적으로 데모 환경은 100% 샘플링으로 설정되어 있습니다.
운영 환경에서는 수집 비율을 줄여야 합니다.

# MeshConfig 수정
KUBE_EDITOR="nano" kubectl edit -n istio-system cm istio

# 아래와 같이 수정
sampling: 10  # 기존 100에서 10으로 변경

변경 적용 후, 다음 명령어로 Istio Ingress Gateway를 재시작합니다.

kubectl rollout restart deploy -n istio-system istio-ingressgateway

또는 워크로드별로 설정할 수 있습니다:

# Deployment 애노테이션 방식
proxy.istio.io/config: |
  tracing:
    sampling: 10
    zipkin:
      address: zipkin.istio-system:9411

변경 후 트래픽을 보내고 Jaeger에서 수집된 트레이스 수를 확인합니다.

⚡ 클라이언트에서 트레이싱 강제하기

일부 요청에 대해서만 트레이싱을 강제로 수행하려면, x-envoy-force-trace: true 헤더를 추가합니다.

curl -s -H "x-envoy-force-trace: true" http://webapp.istioinaction.io:30000/api/catalog -v

이렇게 하면 샘플링 설정과 무관하게 해당 요청과 하위 호출에 대한 트레이스가 무조건 수집됩니다.

이 기능은 운영 중 문제 상황을 특정할 때 유용하며, API Gateway나 진단 도구에 통합될 수 있습니다.

🏷 트레이스에 태그 커스터마이징하기

스팬에 키-값 형태의 태그를 추가하여 트레이스 검색과 필터링을 개선할 수 있습니다.

proxy.istio.io/config: |
  tracing:
    sampling: 100
    customTags:
      custom_tag:
        literal:
          value: "Test Tag"
    zipkin:
      address: zipkin.istio-system:9411

적용:

kubectl apply -n istioinaction -f ch8/webapp-deployment-zipkin-tag.yaml

태그는 분석, 필터링, 알림 조건 정의 등에 활용됩니다.

⚙️ 백엔드 트레이싱 엔진 커스터마이징

기본 Zipkin 포맷 외에, Jaeger의 다양한 옵션(예: /zipkin/api/v1/spans 엔드포인트 등)을 사용하려면 부트스트랩 설정을 오버라이드해야 합니다.

# configmap 정의
cat ch8/istio-custom-bootstrap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio-custom-zipkin
data:
  custom_bootstrap.json: |
    {
      "tracing": {
        "http": {
          "name": "envoy.tracers.zipkin",
          "typedConfig": {
            "@type": "type.googleapis.com/envoy.config.trace.v3.ZipkinConfig",
            "collectorCluster": "zipkin",
            "collectorEndpoint": "/zipkin/api/v1/spans",
            "traceId128bit": "true",
            "collectorEndpointVersion": "HTTP_JSON"
          }
        }
      }
    }

적용 후, Deployment 애노테이션으로 설정을 덮어씁니다.

sidecar.istio.io/bootstrapOverride: "istio-custom-zipkin"

적용:

kubectl apply -n istioinaction -f ch8/webapp-deployment-custom-boot.yaml

설정 확인:

istioctl pc bootstrap -n istioinaction deploy/webapp -o json | jq .bootstrap.tracing

⚠️ 설정을 잘못 지정하면 Span 수집이 누락되므로, collectorEndpoint 경로를 정확히 맞춰야 합니다.

# 설정 원복
kubectl apply -n istioinaction -f services/webapp/kubernetes/webapp.yaml

이 절에서는 성능을 고려한 분산 트레이싱 설정 최적화와 고급 활용 기법(강제 트레이싱, 태그, 부트스트랩 설정)을 다루었습니다.

👉 Step 03. Visualization with Kiali

키알리(Kiali)는 이스티오 서비스 메시의 상태를 시각화하는 데 특화된 대시보드로, 실시간 메트릭을 바탕으로 서비스 간의 통신 관계를 방향 그래프(directed graph) 형태로 제공합니다.

Kiali는 오픈소스 이스티오 프로젝트에 통합되어 제공되며, 실시간으로 메시 상태를 시각화하는 도구입니다.
Prometheus 및 기반 플랫폼으로부터 메트릭을 가져와, 메시 내 서비스 간 통신 상황을 시각적 그래프로 표현합니다.
이 그래프를 통해 서비스 간 호출 관계, 지연, 오류 발생 등을 한눈에 파악할 수 있으며, 인터랙티브하게 문제 영역을 추적할 수 있습니다.

Kiali의 특징은 다음과 같습니다:

실시간으로 갱신되는 통계 기반의 방향 그래프 제공

각 서비스의 통신 흐름, 성공률, 오류 비율 등을 시각적으로 표시

네임스페이스, 애플리케이션, 워크로드 단위의 상세 정보 탐색 가능

🆚 Kiali vs Grafana

항목	Kiali	Grafana
초점	서비스 간 네트워크 관계 시각화	시계열 기반 대시보드 및 알림
갱신	실시간 갱신 그래프	수동 또는 주기적 리프레시
용도	메시 호출 흐름 파악, 트래픽 이상 탐지	메트릭 모니터링, 리소스 상태 추적
상호작용성	클릭 기반 탐색 기능, 문제 영역 드릴다운	주로 시각화 및 필터 기반 탐색

Kiali는 클러스터 내 서비스 간 관계와 네트워크 동작을 실시간으로 파악하려는 상황에 가장 적합하며, Grafana는 메트릭 수치의 이상 탐지와 리소스 모니터링에 더 효과적입니다.

✅ Installing Kiali

🔧 키알리 오퍼레이터 설치

Istio는 기본적으로 샘플 버전의 Kiali를 제공하지만, 운영 환경에서는 Helm 기반 Kiali Operator 설치를 권장합니다.
설치 가이드: Kiali Installation Guide

# Helm 저장소 등록 및 업데이트
helm repo add kiali https://kiali.org/helm-charts
helm repo update 

# Kiali Operator 설치 (예시 버전: 1.63.2)
helm install --namespace kiali-operator --create-namespace \
  --version 1.63.2 kiali-operator kiali/kiali-operator

# 설치 확인
kubectl get pod -n kiali-operator

🚀 Kiali 인스턴스 배포

istio-system 네임스페이스에 배포
Prometheus 및 Jaeger와 연동되도록 설정

apiVersion: kiali.io/v1alpha1
kind: Kiali
metadata:
  namespace: istio-system
  name: kiali
spec:
  istio_namespace: "istio-system"
  istio_component_namespaces:
    prometheus: prometheus
  auth:
    strategy: anonymous
  deployment:
    accessible_namespaces:
      - '**'
  external_services:
    prometheus:
      url: "http://prom-kube-prometheus-stack-prometheus.prometheus:9090"
    tracing:
      enabled: true
      in_cluster_url: "http://tracing.istio-system:16685/jaeger"
      use_grpc: true

# 배포
kubectl apply -f ch8/kiali.yaml

# 서비스 확인
kubectl get deploy,svc -n istio-system kiali

# NodePort 설정 (예: 30003)
kubectl patch svc -n istio-system kiali \
  -p '{"spec": {"type": "NodePort", "ports": [{"port": 20001, "targetPort": 20001, "nodePort": 30003}]}}'

# 접속
open http://127.0.0.1:30003

⚠️ Prometheus, Jaeger 모두 기본 보안은 없으며 리버스 프록시를 권장
Kiali는 TLS 및 기본 인증을 통한 Prometheus 연결을 지원함

🔁 트래픽 유도 테스트

while true; do \
  curl -s http://webapp.istioinaction.io:30000/api/catalog ; \
  date "+%Y-%m-%d %H:%M:%S" ; sleep 1; echo; \
done

🧭 Kiali 대시보드 주요 기능

Overview: 네임스페이스 및 애플리케이션 수 요약

Graph: 서비스 메시 트래픽 흐름을 시각화
- HTTP/TCP 흐름, 트래픽 수치, 카나리 릴리스 흐름
- 네트워크 오류 빠른 식별

Workloads → Traces: Jaeger 연동 트레이스 확인

🧩 Traces, Metrics, Logs의 연관성

Workloads 메뉴 구성:

메뉴	설명
Overview	파드 및 적용된 Istio 설정, 상·하위 그래프
Traffic	수신/송신 성공률
Logs	애플리케이션 로그, Envoy 로그, 트레이스 연결
Traces	Jaeger 트레이스 목록
Envoy	클러스터, 리스너, 라우트 설정 등 Envoy 구성

📌 Workload vs. Application

항목	정의
Workload	Pod 집합(예: 동일 ReplicaSet)
Application	여러 Workload와 관련 서비스의 집합

🔎 운영에 도움되는 Kiali의 기능

존재하지 않는 Gateway를 참조하는 VirtualService 식별
없는 서비스로 라우팅되는 설정 탐지
동일 호스트에 여러 VirtualService 중복 경고
정의되지 않은 서비스 subset 사용 확인

📌 Conclusion

이번 장에서는 Istio가 제공하는 관측성(Observability) 구성 요소 중 분산 트레이싱 시스템을 중심으로, 요청 흐름에 대한 인사이트를 어떻게 확보할 수 있는지를 실습과 함께 심도 있게 다뤘습니다.

Kiali를 연동함으로써 Trace, Metric, Log의 상관관계를 단일 UI에서 확인하고, 트래픽 흐름을 시각적으로 추적할 수 있었습니다.

Kiali는 단순한 대시보드가 아니라, 잘못된 VirtualService나 존재하지 않는 대상 라우팅 등 메시 구성 오류까지 알려주는 운영 중심 도구로 활용될 수 있습니다.

무엇보다 중요한 점은, 이 모든 트레이싱 기능이 애플리케이션 코드 변경 없이 수행 가능하다는 점입니다.

운영자는 Istio 설정만으로 마이크로서비스 환경에서 발생하는 요청 흐름을 추적하고, 성능 문제를 빠르게 진단할 수 있는 기반을 확보할 수 있습니다.

결론적으로 이번 장을 통해 다음과 같은 인사이트를 얻을 수 있었습니다:

분산 트레이싱은 요청 흐름을 시각적으로 추적하고, 병목과 오류를 분석하는 가장 효과적인 도구이다.

Istio는 서비스 메시 구조 내에서 트레이스 메타데이터의 자동 전파 및 수집을 기본 기능으로 내장하고 있으며, 확장성 또한 뛰어나다.

Kiali는 Trace, Metric, Log를 엮어 운영 시점의 문제를 빠르게 식별할 수 있는 시각화 도구로써 실무에 꼭 필요한 구성 요소다.

xgro

안녕하세요! DevOps 엔지니어 이재찬입니다. 블로그에 대한 피드백은 언제나 환영합니다! 기술, 개발, 운영에 관한 다양한 주제로 함께 나누며, 더 나은 협업과 효율적인 개발 환경을 만드는 과정에 대해 인사이트를 나누고 싶습니다. 함께 여행하는 기분으로, 즐겁게 읽어주시면 감사하겠습니다! 🚀