Istio 관찰 가능성 완벽 가이드

Istio 서비스 메시의 관찰 가능성을 위한 핵심 도구들을 다룹니다. Kiali 대시보드부터 Jaeger 분산 추적, Prometheus 메트릭, Grafana 연동까지 실무에서 바로 활용할 수 있는 모니터링 전략을 배웁니다.

---

목차

1. Kiali_대시보드
2. 서비스_그래프
3. Jaeger_분산_추적
4. Prometheus_메트릭
5. Grafana_연동
6. 트래픽_시각화

---

1. Kiali 대시보드

어느 날 김개발 씨는 마이크로서비스 운영 중 장애 알림을 받았습니다. "어디서 문제가 생긴 거지?" 수십 개의 서비스 중 어디가 문제인지 찾기가 막막했습니다.

바로 이때 박시니어 씨가 브라우저 하나를 열어 보여줬습니다.

Kiali 대시보드는 Istio 서비스 메시의 전체 상황을 한눈에 볼 수 있는 웹 기반 관리 콘솔입니다. 마치 교통 관제센터의 전광판처럼 모든 서비스의 상태와 트래픽 흐름을 실시간으로 보여줍니다.

이것을 활용하면 복잡한 마이크로서비스 환경에서도 문제를 빠르게 찾아낼 수 있습니다.

다음 코드를 살펴봅시다.

# Kiali 설치 및 실행
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/kiali.yaml

# Kiali 대시보드 접속
kubectl port-forward svc/kiali -n istio-system 20001:20001

# 브라우저에서 접속: http://localhost:20001

# 서비스 헬스 체크 확인
# Graph 탭에서 네임스페이스 선택 후 Display 옵션 설정
# - Traffic Animation: 활성화
# - Security: mTLS 상태 표시
# - Service Nodes: 서비스별 응답 시간 표시

김개발 씨는 입사 6개월 차 백엔드 개발자입니다. 회사에서 마이크로서비스 아키텍처로 전환한 후, 서비스가 20개가 넘어가면서 모니터링이 점점 복잡해졌습니다.

각 서비스의 로그를 일일이 확인하는 것만으로도 하루 일과의 절반을 소비하고 있었습니다. 어느 날 새벽, 장애 알림이 울렸습니다.

"결제 서비스 응답 없음." 김개발 씨는 급하게 노트북을 켰지만 어디서부터 확인해야 할지 막막했습니다. 결제 서비스가 직접 문제인지, 아니면 연결된 다른 서비스가 문제인지 알 수 없었습니다.

다음 날 아침, 박시니어 씨가 김개발 씨를 불렀습니다. "어젯밤 고생했죠?

이거 한번 보세요." 박시니어 씨가 브라우저를 열자 놀라운 화면이 나타났습니다. Kiali 대시보드의 등장 Kiali는 그리스어로 '망원경'을 의미합니다.

말 그대로 복잡한 서비스 메시를 한눈에 볼 수 있게 해주는 도구입니다. 쉽게 비유하자면, Kiali는 마치 공항의 관제탑과 같습니다.

수많은 비행기가 어디로 가고 있는지, 어느 비행기가 지연되고 있는지, 어떤 항로가 혼잡한지를 한눈에 보여줍니다. 이처럼 Kiali도 수많은 마이크로서비스의 상태와 트래픽을 실시간으로 시각화합니다.

Kiali가 없던 시절 Istio를 도입했지만 Kiali 같은 도구가 없던 시절에는 어땠을까요? 개발자들은 각 서비스의 로그를 터미널에서 직접 확인해야 했습니다.

"kubectl logs"를 수십 번 입력하고, 각 서비스가 어떻게 연결되어 있는지 머릿속으로 그려야 했습니다. 더 큰 문제는 서비스 간 통신 문제를 파악하는 것이었습니다.

A 서비스에서 B 서비스로 요청이 제대로 가고 있는지, 응답 시간은 얼마나 걸리는지 알아내려면 여러 도구를 조합해야 했습니다. Kiali의 핵심 기능 바로 이런 문제를 해결하기 위해 Kiali가 등장했습니다.

Kiali를 사용하면 서비스 그래프 시각화가 가능해집니다. 모든 서비스가 어떻게 연결되어 있는지 노드와 엣지로 표현됩니다.

또한 실시간 헬스 체크도 얻을 수 있습니다. 초록색은 정상, 노란색은 경고, 빨간색은 오류를 의미합니다.

무엇보다 트래픽 애니메이션이라는 큰 이점이 있습니다. 실제로 데이터가 어느 방향으로 흐르는지 움직이는 점으로 표현됩니다.

대시보드 설치 과정 위의 명령어를 한 줄씩 살펴보겠습니다. 먼저 첫 번째 줄에서는 Kiali 관련 Kubernetes 리소스를 배포합니다.

이 YAML 파일에는 Deployment, Service, ConfigMap 등이 모두 포함되어 있습니다. 다음으로 두 번째 줄에서는 포트 포워딩을 설정합니다.

Kiali는 기본적으로 클러스터 내부에서만 접근 가능하므로, 로컬 머신에서 접속하려면 포트 포워딩이 필요합니다. 마지막으로 브라우저에서 localhost:20001로 접속하면 Kiali 대시보드가 나타납니다.

실무 활용 사례 실제 현업에서는 어떻게 활용할까요? 예를 들어 온라인 쇼핑몰을 운영한다고 가정해봅시다.

주문 서비스, 결제 서비스, 재고 서비스, 배송 서비스가 있습니다. 어느 날 고객이 "결제가 안 돼요"라고 문의했습니다.

Kiali 대시보드를 열어보니 주문 서비스에서 결제 서비스로 가는 화살표가 빨간색입니다. 클릭해보니 "504 Gateway Timeout" 에러가 표시됩니다.

결제 서비스 자체는 정상인데, 연결된 외부 PG사 API가 응답하지 않는 것이 원인이었습니다. Kiali 덕분에 5분 만에 문제를 찾아냈습니다.

주의사항 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 Kiali를 프로덕션 환경에 그대로 노출시키는 것입니다.

기본 설치는 인증 없이 접속 가능하므로, 반드시 인증을 활성화하거나 접근 제어를 설정해야 합니다. 따라서 Ingress나 OAuth를 통한 인증을 구성하는 것이 올바른 방법입니다.

정리 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨가 보여준 Kiali 대시보드를 본 김개발 씨는 감탄했습니다.

"와, 이렇게 쉽게 볼 수 있었군요!" Kiali를 제대로 활용하면 복잡한 마이크로서비스 환경에서도 빠르게 문제를 찾고 해결할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - Graph 탭의 Display 옵션에서 "Response Time"을 활성화하면 병목 구간을 쉽게 찾을 수 있습니다

• Versioned App Graph를 선택하면 카나리 배포나 A/B 테스트 상황을 명확히 볼 수 있습니다
• Workload 탭에서 각 파드의 리소스 사용량과 재시작 횟수를 확인할 수 있습니다

---

2. 서비스 그래프

김개발 씨는 Kiali 대시보드를 열었지만 처음에는 화면이 너무 복잡해 보였습니다. 수많은 동그라미와 화살표가 얽혀 있었습니다.

"이게 뭘 의미하는 거죠?" 박시니어 씨가 웃으며 하나씩 설명해주기 시작했습니다.

서비스 그래프는 마이크로서비스 간의 관계와 트래픽 흐름을 시각적으로 표현한 네트워크 다이어그램입니다. 마치 지하철 노선도처럼 각 서비스가 어떻게 연결되어 있고, 어느 방향으로 데이터가 흐르는지 보여줍니다.

이것을 활용하면 서비스 의존성과 호출 패턴을 직관적으로 이해할 수 있습니다.

다음 코드를 살펴봅시다.

# Kiali에서 서비스 그래프 보기
# Graph 메뉴 선택 후 다음 옵션 설정

# 1. 네임스페이스 선택
# Namespace: default, production 등 원하는 네임스페이스 선택

# 2. 그래프 타입 선택
# - Workload graph: 파드 단위로 표시
# - App graph: 애플리케이션 단위로 표시
# - Versioned app graph: 버전별로 구분
# - Service graph: 서비스 단위로 표시 (권장)

# 3. Display 옵션 설정
# ✓ Traffic Animation - 실시간 트래픽 흐름 애니메이션
# ✓ Security - mTLS 암호화 상태 표시
# ✓ Virtual Services - Istio 라우팅 규칙 표시
# ✓ Missing Sidecars - Envoy 프록시 누락 경고

김개발 씨가 처음 본 서비스 그래프는 마치 복잡한 미로 같았습니다. 동그라미가 20개도 넘고, 화살표는 사방으로 뻗어 있었습니다.

"이걸 어떻게 이해하죠?" 박시니어 씨가 마우스를 움직이며 설명했습니다. "하나씩 보면 어렵지 않아요.

이 동그라미 하나하나가 서비스고, 화살표가 호출 방향이에요." 그래프 언어 배우기 서비스 그래프를 이해하는 것은 새로운 언어를 배우는 것과 같습니다. 쉽게 비유하자면, 서비스 그래프는 마치 인체의 혈관도와 같습니다.

심장에서 출발한 혈액이 동맥을 타고 각 장기로 흐르고, 다시 정맥을 통해 돌아옵니다. 건강한 혈관은 파란색, 문제가 있는 곳은 빨간색으로 표시됩니다.

이처럼 서비스 그래프도 데이터의 흐름과 각 지점의 건강 상태를 색상으로 표현합니다. 그래프가 없던 시절 서비스 그래프 같은 시각화 도구가 없던 시절에는 어땠을까요?

개발자들은 아키텍처 문서를 PDF로 보거나, 화이트보드에 그려진 다이어그램을 사진으로 찍어 공유했습니다. 문제는 이런 문서가 코드와 동기화되지 않는다는 것이었습니다.

누군가 새 서비스를 추가하거나 의존성을 변경해도 문서는 업데이트되지 않았습니다. 3개월 후 문서를 보면 실제 시스템과 전혀 다른 그림이 그려져 있었습니다.

실시간 자동 업데이트 바로 이런 문제를 해결하기 위해 서비스 그래프가 등장했습니다. 서비스 그래프를 사용하면 자동 디스커버리가 가능해집니다.

새로운 서비스가 배포되면 자동으로 그래프에 나타납니다. 또한 실시간 업데이트도 얻을 수 있습니다.

트래픽 패턴이 변경되면 즉시 화면에 반영됩니다. 무엇보다 인터랙티브 탐색이라는 큰 이점이 있습니다.

노드를 클릭하면 상세 정보를 볼 수 있고, 필터링도 가능합니다. 그래프 읽는 법 위의 옵션 설정을 하나씩 살펴보겠습니다.

먼저 그래프 타입 선택이 중요합니다. Workload graph는 가장 상세하지만 복잡할 수 있습니다.

Service graph는 추상화 수준이 적절해서 전체 흐름을 파악하기 좋습니다. Versioned app graph는 카나리 배포처럼 여러 버전이 동시에 실행될 때 유용합니다.

다음으로 Traffic Animation을 켜면 마법 같은 일이 일어납니다. 작은 점들이 화살표를 따라 움직입니다.

트래픽이 많을수록 점이 빠르게 이동합니다. 실제로 데이터가 흐르는 모습을 눈으로 확인할 수 있어서 직관적입니다.

색상 코드 이해하기 서비스 그래프의 색상은 명확한 의미를 가집니다. 초록색 노드는 건강한 상태입니다.

에러율이 낮고 응답 시간도 정상입니다. 노란색 노드는 경고 상태입니다.

에러율이 조금 높거나 응답이 느려지고 있습니다. 빨간색 노드는 심각한 문제가 있습니다.

에러율이 높거나 서비스가 응답하지 않습니다. 화살표도 마찬가지입니다.

초록색 화살표는 정상적인 통신입니다. 빨간색 화살표는 해당 경로에서 많은 에러가 발생하고 있습니다.

이 화살표를 클릭하면 HTTP 상태 코드별 분포를 볼 수 있습니다. 실무 활용 사례 실제 현업에서는 어떻게 활용할까요?

김개발 씨의 회사는 마이크로서비스가 30개입니다. 어느 날 모니터링 시스템에서 전체 응답 시간이 느려졌다는 알림이 왔습니다.

김개발 씨는 Kiali를 열고 서비스 그래프를 확인했습니다. 그래프를 보니 대부분의 서비스는 초록색인데, "product-catalog" 서비스만 노란색이었습니다.

이 서비스에 연결된 화살표들도 모두 느린 응답을 보여주고 있었습니다. 노드를 클릭해보니 평균 응답 시간이 2초였습니다.

평소 200ms였던 것에 비하면 10배나 느려진 것입니다. 더 깊이 파고들어가 보니, product-catalog가 호출하는 "database-service"가 문제였습니다.

데이터베이스 연결 풀이 고갈되어 있었습니다. 연결 풀 크기를 늘리자 모든 노드가 다시 초록색으로 돌아왔습니다.

그래프 덕분에 15분 만에 원인을 찾았습니다. 주의사항 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 모든 네임스페이스를 동시에 표시하는 것입니다. 네임스페이스가 많으면 그래프가 너무 복잡해져서 오히려 파악이 어렵습니다.

따라서 관심 있는 네임스페이스만 선택해서 보는 것이 올바른 방법입니다. 또 다른 실수는 그래프의 색상만 보고 판단하는 것입니다.

노란색이라고 반드시 문제가 있는 것은 아닙니다. 일시적인 트래픽 증가일 수 있습니다.

클릭해서 메트릭을 확인하고 판단해야 합니다. 정리 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 이제 그래프가 친숙해졌습니다. "아, 이제 이해했어요!" 서비스 그래프를 제대로 활용하면 복잡한 시스템의 구조를 한눈에 파악하고, 문제가 발생한 지점을 빠르게 찾을 수 있습니다.

여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 그래프에서 특정 서비스만 하이라이트하려면 해당 노드를 더블클릭하세요

• "Find/Hide" 기능으로 특정 패턴의 노드만 필터링할 수 있습니다
• 그래프를 PNG로 저장해서 장애 보고서에 첨부하면 상황 설명이 쉬워집니다

---

3. Jaeger 분산 추적

박시니어 씨가 김개발 씨에게 물었습니다. "서비스 그래프로 어디가 느린지는 알았죠?

그런데 왜 느린지는 어떻게 알 수 있을까요?" 김개발 씨는 고개를 갸웃거렸습니다. 바로 그때 박시니어 씨가 새로운 도구를 열어 보여줬습니다.

Jaeger 분산 추적은 하나의 요청이 여러 마이크로서비스를 거치는 전체 여정을 추적하는 시스템입니다. 마치 택배의 배송 추적처럼 각 단계에서 얼마나 시간이 걸렸는지, 어디서 지연이 발생했는지 상세히 보여줍니다.

이것을 활용하면 복잡한 서비스 체인에서 병목 지점을 정확히 찾아낼 수 있습니다.

다음 코드를 살펴봅시다.

# Jaeger 설치
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/jaeger.yaml

# Jaeger UI 접속
kubectl port-forward svc/tracing -n istio-system 16686:16686

# 브라우저: http://localhost:16686

# Istio에서 샘플링 비율 설정 (100% 추적)
kubectl -n istio-system edit configmap istio

# 다음 라인 추가
# meshConfig:
#   defaultConfig:
#     tracing:
#       sampling: 100.0

# 특정 요청 추적 예제
# Service 선택 → Operation 선택 → Find Traces
# Timeline 뷰에서 각 스팬(span)의 소요 시간 확인

김개발 씨는 서비스 그래프에서 느린 서비스를 찾았습니다. 하지만 왜 느린지는 알 수 없었습니다.

그 서비스 안에서 데이터베이스 쿼리가 느린 건지, 외부 API 호출이 느린 건지, 아니면 비즈니스 로직 자체가 느린 건지 구분할 수 없었습니다. 박시니어 씨가 말했습니다.

"이럴 때 필요한 게 분산 추적이에요. 하나의 요청을 처음부터 끝까지 따라가면서 모든 단계를 기록하는 거죠." 택배 추적의 원리 분산 추적이란 정확히 무엇일까요?

쉽게 비유하자면, 분산 추적은 마치 택배 추적 시스템과 같습니다. 여러분이 온라인 쇼핑몰에서 물건을 주문하면 택배 번호를 받습니다.

이 번호로 추적하면 "상품 준비 중 → 집화 완료 → 간선 상차 → 지점 도착 → 배송 출발 → 배송 완료" 같은 단계를 볼 수 있습니다. 각 단계마다 시간도 기록되어 있어서 어디서 오래 걸렸는지 알 수 있습니다.

이처럼 Jaeger도 하나의 HTTP 요청에 고유 ID를 부여하고, 모든 서비스를 거치는 과정을 추적합니다. 로그만으로는 부족했던 시절 Jaeger 같은 분산 추적 도구가 없던 시절에는 어땠을까요?

개발자들은 각 서비스의 로그에 직접 타임스탬프를 찍어야 했습니다. "A 서비스 진입: 14:32:15.123", "B 서비스 호출: 14:32:15.456" 같은 식이었습니다.

문제는 이 로그들이 서로 다른 파일에 흩어져 있다는 것이었습니다. 하나의 요청을 추적하려면 여러 서버의 로그를 시간 순으로 맞춰가며 읽어야 했습니다.

더 큰 문제는 요청 ID를 수동으로 전파해야 한다는 것이었습니다. 개발자가 직접 헤더에 ID를 넣고 전달하는 코드를 작성해야 했습니다.

자동 추적의 힘 바로 이런 문제를 해결하기 위해 Jaeger가 등장했습니다. Jaeger를 사용하면 자동 계측이 가능해집니다.

Istio의 Envoy 프록시가 자동으로 추적 데이터를 수집합니다. 또한 통합 뷰도 얻을 수 있습니다.

하나의 UI에서 모든 서비스의 추적 데이터를 볼 수 있습니다. 무엇보다 상세한 타임라인이라는 큰 이점이 있습니다.

각 작업이 언제 시작되고 끝났는지 마이크로초 단위로 기록됩니다. Span과 Trace 이해하기 Jaeger의 핵심 개념을 이해해야 합니다.

Trace는 하나의 요청이 시작부터 끝까지 거치는 전체 여정입니다. 예를 들어 사용자가 "상품 상세 보기" 버튼을 클릭하면 하나의 Trace가 시작됩니다.

Span은 Trace 안의 각 단계입니다. "API Gateway → Product Service"는 하나의 Span, "Product Service → Database"는 또 다른 Span입니다.

Span은 부모-자식 관계를 가집니다. Product Service Span 아래에 Database Span이 있는 식입니다.

위의 코드에서 샘플링 비율을 100으로 설정한 것을 주목하세요. 기본값은 1입니다.

즉, 100개 요청 중 1개만 추적한다는 뜻입니다. 개발 환경에서는 100으로 설정해서 모든 요청을 추적하는 것이 좋습니다.

프로덕션에서는 성능을 고려해서 1-10 정도로 낮춥니다. 타임라인 읽는 법 Jaeger UI의 타임라인은 가로 막대 그래프입니다.

맨 위에 있는 가장 긴 막대가 전체 요청 시간입니다. 그 아래 들여쓰기된 막대들이 하위 Span들입니다.

막대의 길이가 소요 시간입니다. 파란색은 정상, 빨간색은 에러를 의미합니다.

예를 들어 전체 요청이 1초인데, "Database Query" Span이 900ms라면? 데이터베이스가 병목이라는 것을 바로 알 수 있습니다.

나머지 모든 서비스는 합쳐서 100ms밖에 안 걸렸으니까요. 실무 활용 사례 실제 현업에서는 어떻게 활용할까요?

김개발 씨의 회사에서 "주문 완료까지 5초나 걸린다"는 불만이 접수되었습니다. 김개발 씨는 Jaeger를 열고 "checkout" 서비스의 Trace를 검색했습니다.

타임라인을 보니 흥미로운 패턴이 보였습니다. "Inventory Service"를 호출하는 Span이 10개나 있었습니다.

각각 200ms씩 걸려서 총 2초를 소비하고 있었습니다. 코드를 확인해보니 장바구니 상품 10개를 하나씩 순차적으로 조회하고 있었습니다.

김개발 씨는 코드를 수정해서 10개를 한 번에 조회하도록 변경했습니다. 배치 API를 만들어서 한 번의 호출로 모든 상품 정보를 가져오게 했습니다.

다시 Jaeger로 확인해보니 전체 시간이 1.5초로 줄어들었습니다. Inventory Service Span도 1개만 나타났고, 시간은 300ms였습니다.

주의사항 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 프로덕션 환경에서 샘플링을 100%로 설정하는 것입니다.

모든 요청을 추적하면 Jaeger 저장소가 금방 가득 차고, 성능 오버헤드도 발생합니다. 따라서 프로덕션에서는 1-5% 정도의 샘플링 비율을 사용하는 것이 올바른 방법입니다.

또 다른 실수는 Jaeger만 믿는 것입니다. Jaeger는 "어디서" 느린지는 알려주지만 "왜" 느린지는 알려주지 않습니다.

느린 Span을 찾았다면, 해당 서비스의 상세 메트릭이나 로그를 추가로 확인해야 합니다. 정리 다시 김개발 씨의 이야기로 돌아가 봅시다.

Jaeger 덕분에 김개발 씨는 복잡한 성능 문제를 해결했습니다. "이제 어디가 느린지 정확히 알 수 있어요!" Jaeger를 제대로 활용하면 마이크로서비스의 성능 병목을 정확히 찾아내고, 최적화 포인트를 명확히 할 수 있습니다.

여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - Jaeger에서 에러가 발생한 Trace만 필터링하려면 "Tags" 필드에 "error=true"를 입력하세요

• 느린 요청만 보려면 "Min Duration"을 설정하세요 (예: 1s)
• Trace를 JSON으로 다운로드해서 팀과 공유하거나 이슈 트래커에 첨부할 수 있습니다

---

4. Prometheus 메트릭

김개발 씨가 물었습니다. "Jaeger로 개별 요청은 추적할 수 있는데, 전체적인 추세는 어떻게 보나요?

오늘 하루 평균 응답 시간이 어땠는지 알고 싶어요." 박시니어 씨가 고개를 끄덕이며 또 다른 도구를 열었습니다.

Prometheus 메트릭은 시스템의 모든 수치 데이터를 시계열로 수집하고 저장하는 모니터링 시스템입니다. 마치 건강검진 기록처럼 CPU 사용률, 메모리, 요청 횟수, 에러율 등을 지속적으로 측정하고 기록합니다.

이것을 활용하면 시스템의 전체적인 상태와 추세를 파악할 수 있습니다.

다음 코드를 살펴봅시다.

# Prometheus 설치
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/prometheus.yaml

# Prometheus UI 접속
kubectl port-forward svc/prometheus -n istio-system 9090:9090

# 브라우저: http://localhost:9090

# 유용한 PromQL 쿼리 예제

# 1. 서비스별 초당 요청 수 (RPS)
rate(istio_requests_total[5m])

# 2. 에러율 (5분 평균)
sum(rate(istio_requests_total{response_code=~"5.."}[5m]))
/ sum(rate(istio_requests_total[5m]))

# 3. 서비스별 P95 응답 시간
histogram_quantile(0.95,
  sum(rate(istio_request_duration_milliseconds_bucket[5m]))
  by (le, destination_service))

김개발 씨는 Jaeger로 느린 요청을 찾아내는 법을 배웠습니다. 하지만 한 가지 문제가 있었습니다.

Jaeger는 개별 요청의 상세한 추적에는 좋지만, "지난 1시간 동안 평균 응답 시간이 어땠는지" 같은 전체적인 그림을 보기는 어려웠습니다. 박시니어 씨가 설명했습니다.

"개별 요청 추적은 Jaeger, 전체 메트릭은 Prometheus라고 생각하면 돼요. 둘은 서로 보완 관계죠." 건강검진 기록부 Prometheus 메트릭이란 정확히 무엇일까요?

쉽게 비유하자면, Prometheus는 마치 종합 건강검진 기록부와 같습니다. 매년 건강검진을 받으면 혈압, 혈당, 콜레스테롤 수치가 기록됩니다.

3년 치 기록을 나란히 놓으면 건강 상태의 추세를 볼 수 있습니다. "작년보다 콜레스테롤이 올랐네", "혈압은 계속 정상이네" 같은 판단이 가능합니다.

이처럼 Prometheus도 시스템의 각종 수치를 지속적으로 측정하고 시간순으로 저장합니다. 로그만으로는 한계가 있던 시절 Prometheus 같은 메트릭 시스템이 없던 시절에는 어땠을까요?

개발자들은 애플리케이션 로그를 파싱해서 수치를 뽑아냈습니다. "grep ERROR"로 에러 개수를 세고, "grep response_time"으로 응답 시간을 찾았습니다.

문제는 로그가 텍스트라는 것이었습니다. 수백만 줄의 로그에서 평균값을 계산하려면 별도의 스크립트를 작성해야 했습니다.

더 큰 문제는 로그는 과거 기록만 남는다는 것이었습니다. 실시간으로 "지금 이 순간 CPU 사용률"을 알기 어려웠습니다.

시계열 데이터의 힘 바로 이런 문제를 해결하기 위해 Prometheus가 등장했습니다. Prometheus를 사용하면 실시간 수집이 가능해집니다.

매 15초마다 모든 서비스의 메트릭을 수집합니다. 또한 효율적인 저장도 얻을 수 있습니다.

시계열 데이터베이스를 사용해서 대용량 데이터를 압축 저장합니다. 무엇보다 강력한 쿼리 언어라는 큰 이점이 있습니다.

PromQL을 사용해서 복잡한 계산을 간단히 표현할 수 있습니다. Istio가 자동 생성하는 메트릭 Istio와 Prometheus를 함께 사용하면 자동으로 많은 메트릭이 생성됩니다.

istio_requests_total은 가장 기본적인 메트릭입니다. 서비스별, HTTP 상태 코드별로 요청 횟수를 셉니다.

이 메트릭으로 "지난 5분간 404 에러가 몇 번 발생했는지" 같은 질문에 답할 수 있습니다. istio_request_duration_milliseconds는 응답 시간을 측정합니다.

단순 평균이 아니라 히스토그램으로 저장됩니다. 덕분에 P50, P95, P99 같은 백분위수를 계산할 수 있습니다.

istio_tcp_connections_opened_total은 TCP 연결 수를 추적합니다. 데이터베이스처럼 HTTP가 아닌 TCP 통신에서 유용합니다.

PromQL 쿼리 해석 위의 코드에 있는 PromQL 쿼리를 하나씩 살펴보겠습니다. 첫 번째 쿼리는 rate 함수를 사용합니다.

rate는 초당 증가율을 계산합니다. istio_requests_total은 누적 카운터입니다.

계속 증가하기만 합니다. rate를 쓰면 "지난 5분간 평균 초당 요청 수"를 알 수 있습니다.

이것이 바로 RPS(Requests Per Second)입니다. 두 번째 쿼리는 에러율을 계산합니다.

분자는 5xx 에러의 초당 발생 수이고, 분모는 전체 요청의 초당 수입니다. 나누면 에러율이 나옵니다.

0.01이면 1%, 0.05면 5%입니다. 세 번째 쿼리는 histogram_quantile 함수를 사용합니다.

0.95는 P95를 의미합니다. 즉, 100개 요청 중 95번째로 느린 요청의 응답 시간입니다.

P95가 중요한 이유는 평균은 이상치에 영향을 많이 받기 때문입니다. 대부분 빠르지만 가끔 아주 느린 요청이 있으면 평균이 왜곡됩니다.

실무 활용 사례 실제 현업에서는 어떻게 활용할까요? 김개발 씨의 팀은 새로운 기능을 배포했습니다.

배포 후 Prometheus로 메트릭을 지켜봤습니다. 처음 10분은 정상이었습니다.

RPS도 평소와 비슷하고, P95 응답 시간도 200ms 정도였습니다. 그런데 30분이 지나자 이상한 패턴이 보였습니다.

P95 응답 시간이 200ms에서 500ms로 늘어났습니다. 평균은 여전히 150ms였습니다.

이것은 대부분의 요청은 빠르지만, 일부 요청이 매우 느려졌다는 의미입니다. 김개발 씨는 Jaeger로 느린 요청을 추적했습니다.

새로 추가한 캐시 로직에서 캐시 미스가 발생할 때 느려지고 있었습니다. 캐시 미스율이 20%였는데, 이 경우에만 데이터베이스를 조회해서 느렸습니다.

캐시 용량을 늘리자 P95가 다시 200ms로 돌아왔습니다. 이처럼 Prometheus로 전체 추세를 보고, Jaeger로 개별 케이스를 분석하는 것이 효과적입니다.

알림 규칙 설정 Prometheus의 진짜 힘은 알림 기능입니다. 특정 조건이 충족되면 자동으로 알림을 보낼 수 있습니다.

예를 들어 "에러율이 5분간 1%를 넘으면 알림"이나 "P95 응답 시간이 1초를 넘으면 알림" 같은 규칙을 설정합니다. AlertManager와 연동하면 슬랙이나 이메일로 알림을 받을 수 있습니다.

주의사항 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 너무 많은 메트릭을 수집하는 것입니다.

Prometheus는 기본적으로 모든 메트릭을 메모리에 보관합니다. 불필요한 레이블을 많이 추가하면 카디널리티가 폭발해서 메모리가 부족해질 수 있습니다.

따라서 꼭 필요한 메트릭과 레이블만 수집하는 것이 올바른 방법입니다. 또 다른 실수는 PromQL을 너무 복잡하게 작성하는 것입니다.

쿼리가 복잡하면 실행 시간도 오래 걸리고, 나중에 이해하기도 어렵습니다. 가능하면 단순하게 유지하세요.

정리 다시 김개발 씨의 이야기로 돌아가 봅시다. Prometheus 덕분에 김개발 씨는 시스템의 건강 상태를 숫자로 파악할 수 있게 되었습니다.

"이제 데이터로 말할 수 있어요!" Prometheus를 제대로 활용하면 감이 아닌 데이터를 기반으로 시스템을 운영하고, 문제가 생기기 전에 미리 감지할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - Prometheus UI의 Graph 탭에서 쿼리 결과를 시각화할 수 있습니다

• 복잡한 쿼리는 Recording Rule로 미리 계산해두면 실행 속도가 빨라집니다
• /metrics 엔드포인트를 직접 브라우저로 열어보면 어떤 메트릭이 수집되는지 확인할 수 있습니다

---

5. Grafana 연동

김개발 씨는 Prometheus로 메트릭을 조회할 수 있게 되었지만, 매번 PromQL을 입력하는 게 번거로웠습니다. "이걸 멋진 대시보드로 만들 수는 없나요?" 박시니어 씨가 웃으며 답했습니다.

"당연하죠. Grafana가 있잖아요."

Grafana 연동은 Prometheus에서 수집한 메트릭을 아름다운 대시보드로 시각화하는 것입니다. 마치 자동차 계기판처럼 속도계, 연료 게이지, RPM 등을 한 화면에 배치해서 한눈에 상태를 파악할 수 있게 합니다.

이것을 활용하면 복잡한 쿼리 없이도 시스템 상태를 직관적으로 모니터링할 수 있습니다.

다음 코드를 살펴봅시다.

# Grafana 설치
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/grafana.yaml

# Grafana UI 접속
kubectl port-forward svc/grafana -n istio-system 3000:3000

# 브라우저: http://localhost:3000
# 기본 계정: admin / admin

# Data Source 추가 (자동 설정되어 있음)
# Configuration > Data Sources > Prometheus
# URL: http://prometheus.istio-system:9090

# Istio 공식 대시보드 import
# Dashboard > Import > Enter ID: 7645
# 또는 11829 (Istio Control Plane Dashboard)

# 커스텀 패널 추가 예제 (JSON)
# {
#   "targets": [{
#     "expr": "rate(istio_requests_total{destination_service=\"my-service\"}[5m])",
#     "legendFormat": "{{response_code}}"
#   }]
# }

김개발 씨는 Prometheus PromQL을 배웠지만, 매번 쿼리를 입력하는 것이 불편했습니다. 게다가 여러 메트릭을 동시에 보려면 브라우저 탭을 여러 개 열어야 했습니다.

"더 편한 방법은 없을까요?" 박시니어 씨가 Grafana를 열어 보여주었습니다. 화면 하나에 그래프, 게이지, 테이블이 깔끔하게 정리되어 있었습니다.

"이게 바로 대시보드의 힘이에요." 자동차 계기판의 원리 Grafana 대시보드란 정확히 무엇일까요? 쉽게 비유하자면, Grafana는 마치 자동차의 계기판과 같습니다.

운전자는 계기판을 보면서 현재 속도, 남은 연료, 엔진 회전수를 한눈에 파악합니다. 중요한 정보가 바로 눈앞에 있어서 별도로 계산하거나 찾을 필요가 없습니다.

연료가 부족하면 경고등이 들어오고, 과속하면 숫자가 빨간색으로 바뀝니다. 이처럼 Grafana도 중요한 메트릭을 시각적으로 배치하고, 임계값을 넘으면 색상으로 경고합니다.

텍스트 기반 모니터링의 한계 Grafana 같은 시각화 도구가 없던 시절에는 어땠을까요? 개발자들은 터미널에서 PromQL을 직접 실행하고 결과를 텍스트로 봤습니다.

"현재 RPS: 1234.56"처럼 숫자만 나타났습니다. 추세를 보려면 같은 쿼리를 1분마다 반복 실행하고 숫자를 비교해야 했습니다.

더 큰 문제는 여러 팀원이 같은 정보를 공유하기 어렵다는 것이었습니다. 각자 자기 컴퓨터에서 쿼리를 실행해야 했습니다.

공유 가능한 실시간 대시보드 바로 이런 문제를 해결하기 위해 Grafana가 등장했습니다. Grafana를 사용하면 직관적인 시각화가 가능해집니다.

숫자가 아니라 그래프, 게이지, 히트맵으로 표현됩니다. 또한 실시간 업데이트도 얻을 수 있습니다.

5초마다 자동으로 새로고침되어 최신 상태를 보여줍니다. 무엇보다 URL 공유라는 큰 이점이 있습니다.

대시보드 URL을 슬랙에 올리면 모두가 같은 화면을 볼 수 있습니다. Istio 공식 대시보드 Istio는 미리 만들어진 Grafana 대시보드를 제공합니다.

대시보드 7645는 가장 유명한 Istio 대시보드입니다. 서비스 메시의 전체 상황을 한눈에 보여줍니다.

글로벌 RPS, 성공률, P50/P90/P99 응답 시간이 상단에 표시됩니다. 서비스별로 필터링할 수도 있습니다.

대시보드 11829는 Istio Control Plane을 모니터링합니다. istiod의 CPU와 메모리 사용량, Pilot의 푸시 횟수, 컨피그 동기화 상태 등을 보여줍니다.

컨트롤 플레인에 문제가 있을 때 유용합니다. 이 대시보드들은 Grafana 커뮤니티에 공유되어 있어서 ID만 입력하면 바로 import할 수 있습니다.

직접 만들 필요가 없습니다. 커스텀 패널 만들기 위의 JSON 코드는 커스텀 패널을 만드는 예제입니다.

targets는 데이터를 가져올 PromQL 쿼리입니다. 여러 개를 추가할 수 있습니다.

expr에 PromQL을 작성하고, legendFormat에 범례 이름을 지정합니다. 중괄호 안의 레이블 값을 참조할 수 있습니다.

예를 들어 response_code별로 라인을 나누려면 legendFormat을 "{{response_code}}"로 설정합니다. 그러면 "200", "404", "500" 같은 범례가 자동 생성됩니다.

패널 타입 선택 Grafana는 다양한 패널 타입을 제공합니다. Time series는 시간에 따른 변화를 보여주는 선 그래프입니다.

RPS나 응답 시간 추세를 볼 때 좋습니다. Gauge는 현재 값을 바늘이나 바로 표현합니다.

CPU 사용률처럼 0-100 범위의 값에 적합합니다. Stat은 큰 숫자로 현재 값을 강조합니다.

"현재 에러율: 0.5%" 같은 중요 지표를 표시할 때 사용합니다. Table은 여러 서비스를 비교할 때 유용합니다.

서비스 이름, RPS, P95, 에러율을 행으로 나열할 수 있습니다. 실무 활용 사례 실제 현업에서는 어떻게 활용할까요?

김개발 씨의 팀은 매주 월요일 아침 회의에서 지난주 운영 리뷰를 합니다. 예전에는 각자 로그를 분석해서 엑셀로 정리했습니다.

준비하는 데만 1시간씩 걸렸습니다. Grafana를 도입한 후에는 달라졌습니다.

공용 대시보드 URL을 회의실 화면에 띄우면 끝입니다. 지난 7일간의 트래픽 추세, 주요 장애 시점, 서비스별 성능이 모두 그래프로 나타납니다.

어느 날 대시보드에서 흥미로운 패턴을 발견했습니다. 매일 새벽 3시에 응답 시간이 급증했습니다.

평소 100ms인데 새벽에는 500ms였습니다. 알고 보니 새벽 3시에 배치 작업이 실행되면서 데이터베이스 부하가 높아지는 것이었습니다.

배치 작업 시간을 새벽 2시로 옮기자 문제가 해결되었습니다. Grafana가 없었다면 발견하지 못했을 패턴이었습니다.

알림과 연동 Grafana의 강력한 기능 중 하나는 알림입니다. 각 패널에 Alert Rule을 설정할 수 있습니다.

예를 들어 "에러율이 1%를 5분간 초과하면 알림"이나 "P95가 1초를 넘으면 알림" 같은 규칙을 만듭니다. 알림은 슬랙, 이메일, PagerDuty 등으로 보낼 수 있습니다.

중요한 것은 임계값을 적절히 설정하는 것입니다. 너무 낮게 설정하면 false positive 알림이 쏟아집니다.

너무 높게 설정하면 실제 문제를 놓칠 수 있습니다. 팀의 SLA에 맞춰서 조정해야 합니다.

주의사항 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 대시보드에 너무 많은 패널을 추가하는 것입니다.

한 화면에 50개의 그래프가 있으면 오히려 집중하기 어렵습니다. 따라서 가장 중요한 메트릭 5-10개만 선별해서 배치하는 것이 올바른 방법입니다.

또 다른 실수는 Refresh 주기를 너무 짧게 설정하는 것입니다. 1초마다 새로고침하면 Prometheus에 부하가 갑니다.

보통 5-10초가 적당합니다. 정리 다시 김개발 씨의 이야기로 돌아가 봅시다.

Grafana 대시보드 덕분에 김개발 씨의 팀은 시스템 상태를 한눈에 파악하게 되었습니다. "이제 모니터링이 즐거워요!" Grafana를 제대로 활용하면 복잡한 메트릭을 누구나 이해할 수 있는 시각 자료로 만들고, 팀 전체가 같은 정보를 공유할 수 있습니다.

여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - Variables를 사용하면 드롭다운으로 네임스페이스나 서비스를 동적으로 선택할 수 있습니다

• Annotations를 추가하면 배포 시점이나 장애 시점을 그래프에 수직선으로 표시할 수 있습니다
• Snapshot 기능으로 현재 대시보드 상태를 캡처해서 URL로 공유할 수 있습니다

---

6. 트래픽 시각화

김개발 씨는 지금까지 배운 도구들을 모두 활용하고 있었습니다. 어느 날 팀장님이 물었습니다.

"우리 서비스의 트래픽 패턴을 한눈에 보여줄 수 있나요? 임원진에게 보고해야 해서요." 김개발 씨는 배운 것들을 조합해서 멋진 트래픽 시각화 대시보드를 만들기로 했습니다.

트래픽 시각화는 서비스 메시를 통과하는 모든 네트워크 통신을 그래픽으로 표현하는 것입니다. 마치 공항의 항공편 모니터처럼 어디서 어디로 얼마나 많은 데이터가 이동하는지 실시간으로 보여줍니다.

이것을 활용하면 트래픽 패턴을 파악하고 비정상적인 흐름을 빠르게 감지할 수 있습니다.

다음 코드를 살펴봅시다.

# Kiali에서 트래픽 애니메이션 활성화
# Graph > Display Options:
# ✓ Traffic Animation
# ✓ Traffic Distribution
# ✓ Traffic Rate

# Grafana에서 트래픽 히트맵 생성
# Panel > Visualization: Heatmap
# Query:
sum(rate(istio_request_bytes_sum[5m])) by (destination_service)

# 서비스 간 데이터 전송량 Top 5
topk(5,
  sum(rate(istio_request_bytes_sum[5m]))
  by (source_service, destination_service)
)

# 시간대별 트래픽 패턴 분석
sum(rate(istio_requests_total[1h])) by (hour)

# Prometheus에서 트래픽 메트릭 확인
# Request rate by source
sum(rate(istio_requests_total[5m])) by (source_app)

김개발 씨는 이제 Istio 관찰 가능성 도구들을 자유롭게 사용할 수 있게 되었습니다. Kiali로 서비스 상태를 보고, Jaeger로 느린 요청을 추적하고, Prometheus로 메트릭을 쿼리하고, Grafana로 대시보드를 만들었습니다.

하지만 팀장님의 요구사항은 조금 달랐습니다. "기술적인 상세보다는 비즈니스 관점에서 트래픽 흐름을 보고 싶어요.

어느 서비스가 가장 바쁜지, 어느 시간대에 사용자가 많은지 알고 싶습니다." 김개발 씨는 고민했습니다. "이미 있는 도구들을 어떻게 조합하면 될까?" 교통 관제 시스템의 원리 트래픽 시각화란 정확히 무엇일까요?

쉽게 비유하자면, 트래픽 시각화는 마치 교통 관제 시스템과 같습니다. 서울 교통 정보 센터에는 큰 화면에 지도가 표시됩니다.

도로마다 색깔이 다릅니다. 초록색은 원활, 노란색은 서행, 빨간색은 정체입니다.

실시간으로 자동차가 움직이는 애니메이션도 보입니다. 관제사는 이 화면을 보고 "강남대로가 정체네, 우회로를 안내해야겠다"고 판단합니다.

이처럼 트래픽 시각화도 서비스 메시의 데이터 흐름을 색상과 애니메이션으로 표현하여 직관적인 판단을 돕습니다. 숫자만으로는 패턴이 안 보이던 시절 트래픽 시각화 도구가 없던 시절에는 어땠을까요?

개발자들은 액세스 로그를 엑셀로 가져와서 피벗 테이블을 만들었습니다. "A 서비스 → B 서비스: 1,234건", "B 서비스 → C 서비스: 567건" 같은 표를 작성했습니다.

숫자는 정확했지만 직관적이지 않았습니다. 어느 경로가 병목인지 한눈에 들어오지 않았습니다.

더 큰 문제는 과거 데이터만 분석할 수 있다는 것이었습니다. "지금 이 순간" 트래픽이 어떻게 흐르는지는 알 수 없었습니다.

실시간 애니메이션의 힘 바로 이런 문제를 해결하기 위해 트래픽 시각화가 등장했습니다. 트래픽 시각화를 사용하면 실시간 흐름 파악이 가능해집니다.

점이 움직이는 속도와 개수로 트래픽량을 직관적으로 알 수 있습니다. 또한 병목 지점 발견도 얻을 수 있습니다.

특정 화살표가 빨간색이고 두꺼우면 그곳이 문제입니다. 무엇보다 비기술 팀원과의 소통이라는 큰 이점이 있습니다.

경영진도 색깔만 보고 상황을 이해할 수 있습니다. Kiali 트래픽 애니메이션 Kiali의 Traffic Animation은 가장 직관적인 시각화입니다.

그래프 화면에서 Display 옵션의 "Traffic Animation"을 활성화하면 마법이 시작됩니다. 작은 점들이 서비스 간 화살표를 따라 움직입니다.

초당 요청 수가 많을수록 점이 빠르게 움직입니다. "Traffic Distribution"을 추가로 켜면 화살표에 백분율이 표시됩니다.

예를 들어 A 서비스가 B와 C로 트래픽을 보낸다면 "B: 70%", "C: 30%" 같은 식입니다. 이것은 카나리 배포나 A/B 테스트를 모니터링할 때 특히 유용합니다.

"Traffic Rate"를 켜면 초당 요청 수가 숫자로 표시됩니다. "125.3 req/s" 같은 식입니다.

애니메이션과 숫자를 함께 보면 정확도와 직관성을 모두 얻을 수 있습니다. Grafana 히트맵 활용 위의 코드에 있는 히트맵 쿼리를 살펴보겠습니다.

Heatmap은 시간과 값의 조합을 색상으로 표현합니다. X축은 시간, Y축은 서비스, 색깔은 트래픽량입니다.

빨간색일수록 트래픽이 많습니다. 예를 들어 하루 24시간을 X축에 놓으면 어느 시간대에 트래픽이 집중되는지 보입니다.

오전 10시와 오후 3시에 빨간색이 짙다면 그때가 피크 타임입니다. topk 함수는 상위 K개만 선택합니다.

서비스가 30개인데 모두 표시하면 복잡합니다. Top 5만 보여주면 중요한 경로에 집중할 수 있습니다.

시간대별 패턴 분석 시간대별 트래픽 패턴을 분석하면 흥미로운 인사이트를 얻을 수 있습니다. 위의 쿼리는 1시간 단위로 트래픽을 집계합니다.

7일치 데이터를 그래프로 그리면 명확한 패턴이 보입니다. 평일 낮에는 높고, 밤에는 낮고, 주말에는 평일보다 적습니다.

이런 패턴을 알면 오토스케일링 정책을 최적화할 수 있습니다. 피크 타임 전에 미리 스케일 아웃하고, 한가한 시간에는 스케일 인해서 비용을 절감합니다.

실무 활용 사례 실제 현업에서는 어떻게 활용할까요? 김개발 씨는 팀장님께 보고할 자료를 준비했습니다.

Grafana에서 지난 한 달 트래픽 히트맵을 만들었습니다. 명확한 패턴이 보였습니다.

월요일 오전 10시가 가장 붉었습니다. 주말 동안 쌓인 데이터를 월요일 아침에 처리하기 때문이었습니다.

반대로 토요일 새벽은 파란색이었습니다. 거의 트래픽이 없었습니다.

팀장님은 이 자료를 보고 즉시 결정했습니다. "월요일 오전에는 서버를 2배로 늘리고, 주말 밤에는 절반으로 줄입시다." 이 변경으로 월 클라우드 비용이 20% 절감되었습니다.

또 다른 발견도 있었습니다. "search" 서비스로 가는 트래픽이 예상보다 많았습니다.

전체 트래픽의 40%를 차지했습니다. 알고 보니 프론트엔드에서 검색어를 입력할 때마다 API를 호출하고 있었습니다.

디바운싱을 적용해서 호출을 줄이자 검색 서비스 부하가 70% 감소했습니다. 이상 패턴 감지 트래픽 시각화는 이상 패턴을 감지하는 데도 유용합니다.

어느 날 김개발 씨는 Kiali를 열고 깜짝 놀랐습니다. 평소에 없던 화살표가 생겼습니다.

"frontend" 서비스에서 "database" 서비스로 직접 연결되는 화살표였습니다. 정상적이라면 "backend" 서비스를 거쳐야 합니다.

코드를 확인해보니 누군가 실수로 프론트엔드에서 데이터베이스를 직접 호출하는 코드를 배포한 것이었습니다. 보안상 큰 문제였습니다.

트래픽 시각화가 없었다면 발견하지 못했을 버그였습니다. 주의사항 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 애니메이션만 보고 판단하는 것입니다. 눈에 띄게 움직이는 점이 많다고 해서 반드시 문제는 아닙니다.

실제 숫자와 에러율을 확인해야 합니다. 따라서 애니메이션은 첫 번째 단서로만 사용하고, 메트릭으로 검증하는 것이 올바른 방법입니다.

또 다른 실수는 너무 많은 네임스페이스를 동시에 표시하는 것입니다. 그래프가 복잡해져서 오히려 패턴이 안 보입니다.

관심 있는 네임스페이스만 선택하세요. 정리 다시 김개발 씨의 이야기로 돌아가 봅시다.

트래픽 시각화 덕분에 김개발 씨는 팀장님께 훌륭한 보고를 할 수 있었습니다. "이제 데이터로 비즈니스 결정을 할 수 있어요!" 트래픽 시각화를 제대로 활용하면 복잡한 서비스 메시의 데이터 흐름을 누구나 이해할 수 있게 만들고, 숨어 있는 패턴과 문제를 발견할 수 있습니다.

여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - Kiali 그래프에서 "Replay" 기능을 사용하면 과거 특정 시점의 트래픽을 재생할 수 있습니다

• Grafana의 Time Range를 "Last 7 days"로 설정하고 주간 패턴을 분석해보세요
• 트래픽 시각화 화면을 스크린샷으로 저장해서 장애 사후 분석 보고서에 활용하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!