본문으로 건너뛰기
Kreath Archive
TechProjectsBooksAbout
TechProjectsBooksAbout
TechProjectsBooksAbout
© 2026 Kreath. All rights reserved.
홈TechProjectsBooksAbout
//
  1. 홈
  2. 테크
  3. 8장: 서비스 메시 관측 가능성 - 분산 추적, 메트릭, 로그 통합
2026년 5월 1일·인프라·

8장: 서비스 메시 관측 가능성 - 분산 추적, 메트릭, 로그 통합

서비스 메시가 제공하는 관측 가능성의 세 기둥을 분석합니다. 분산 추적, 골든 시그널 메트릭, 액세스 로그, 그리고 Kiali/Grafana 연동까지.

11분528자7개 섹션
kubernetesinfrastructureobservabilitysecurityperformance
공유
service-mesh8 / 10
12345678910
이전7장: mTLS와 제로 트러스트 네트워킹다음9장: 사이드카 없는 서비스 메시 - Ambient Mesh와 eBPF

서비스 메시의 가장 즉각적인 가치 중 하나가 관측 가능성(Observability)입니다. 프록시가 모든 트래픽을 중계하므로, 애플리케이션 코드를 수정하지 않고도 서비스 간 통신의 메트릭, 트레이스, 로그를 자동으로 수집할 수 있습니다. 이 장에서는 서비스 메시의 관측 가능성 기능을 체계적으로 살펴보겠습니다.

관측 가능성의 세 기둥

서비스 메시는 관측 가능성의 세 가지 핵심 데이터를 자동 생성합니다.

1. 메트릭 (Metrics)

서비스 간 트래픽의 수치적 측정값입니다. 서비스 메시는 기본적으로 골든 시그널(Golden Signals) 메트릭을 수집합니다.

골든 시그널설명Istio 메트릭 예시
지연 시간 (Latency)요청 처리에 걸린 시간istio_request_duration_milliseconds
트래픽 (Traffic)시스템이 처리하는 요청량istio_requests_total
에러 (Errors)실패한 요청의 비율istio_requests_total{response_code="5xx"}
포화도 (Saturation)리소스 사용률연결 풀, 큐 깊이
Istio 메트릭 예시:

# 서비스 간 요청 수 (레이블별)
istio_requests_total{
  source_workload="frontend",
  destination_workload="reviews",
  response_code="200",
  request_protocol="http"
} 15234

# 요청 지연 시간 히스토그램
istio_request_duration_milliseconds_bucket{
  source_workload="frontend",
  destination_workload="reviews",
  le="100"    # 100ms 이하
} 14500

이 메트릭들은 Prometheus가 수집하고, Grafana 대시보드에서 시각화합니다.

2. 분산 추적 (Distributed Tracing)

하나의 사용자 요청이 여러 서비스를 거치는 전체 경로를 추적합니다.

사용자 요청의 추적 경로:

[Trace ID: abc123]
├── [Span] frontend (12ms)
│   ├── [Span] reviews (8ms)
│   │   └── [Span] ratings (3ms)
│   └── [Span] details (5ms)
└── 전체 소요: 25ms

서비스 메시 프록시는 요청에 추적 헤더를 자동으로 주입합니다. 다만, 서비스 내부에서 다른 서비스를 호출할 때 이 헤더를 **전파(propagation)**해야 합니다.

Warning

서비스 메시가 추적 헤더를 자동 생성하지만, 애플리케이션이 수신한 헤더를 하위 호출에 전파해야 트레이스가 연결됩니다. 다음 헤더들을 전파하세요: x-request-id, x-b3-traceid, x-b3-spanid, x-b3-parentspanid, x-b3-sampled, traceparent, tracestate.

Istio에서 분산 추적을 활성화하고 Jaeger로 수집하는 설정입니다.

Istio 추적 설정 (MeshConfig)
yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
    defaultConfig:
      tracing:
        sampling: 100  # 샘플링 비율 (프로덕션에서는 1~10% 권장)
        zipkin:
          address: jaeger-collector.observability:9411

3. 액세스 로그 (Access Logs)

각 요청의 상세 정보를 텍스트 로그로 기록합니다.

Envoy 액세스 로그 활성화
yaml
apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: mesh-default
  namespace: istio-system
spec:
  accessLogging:
    - providers:
        - name: envoy

Envoy 액세스 로그의 기본 형식:

[2026-05-01T10:23:45.123Z] "GET /api/reviews HTTP/1.1" 200 - via_upstream
  0 1234 12 8 "-"
  "Mozilla/5.0" "abc-123-trace-id"
  "reviews.production.svc.cluster.local:8080"
  "10.0.1.15:8080"
  inbound|8080||reviews.production.svc.cluster.local
  10.0.1.15:15006 10.0.1.15:8080 10.0.0.20:54321
  outbound|8080||reviews.production.svc.cluster.local

Prometheus + Grafana 연동

Istio 메트릭 수집

Istio는 Envoy 프록시에서 Prometheus 호환 메트릭을 노출합니다. Prometheus가 이를 스크레이핑합니다.

Prometheus 스크레이핑 설정
yaml
scrape_configs:
  - job_name: 'envoy-stats'
    metrics_path: /stats/prometheus
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true

핵심 대시보드 메트릭

프로덕션 환경에서 모니터링해야 할 핵심 메트릭입니다.

서비스 수준 메트릭:

promql
# 서비스별 성공률 (SLI)
sum(rate(istio_requests_total{
  response_code!~"5.*",
  destination_service="reviews.production.svc.cluster.local"
}[5m])) /
sum(rate(istio_requests_total{
  destination_service="reviews.production.svc.cluster.local"
}[5m]))
 
# P99 지연 시간
histogram_quantile(0.99,
  sum(rate(istio_request_duration_milliseconds_bucket{
    destination_service="reviews.production.svc.cluster.local"
  }[5m])) by (le)
)
 
# 초당 요청 수 (RPS)
sum(rate(istio_requests_total{
  destination_service="reviews.production.svc.cluster.local"
}[5m]))

메시 수준 메트릭:

promql
# 메시 전체 에러율
sum(rate(istio_requests_total{response_code=~"5.*"}[5m])) /
sum(rate(istio_requests_total[5m]))
 
# mTLS 적용 비율
sum(rate(istio_requests_total{
  connection_security_policy="mutual_tls"
}[5m])) /
sum(rate(istio_requests_total[5m]))

Kiali: 서비스 메시 시각화

Kiali는 Istio의 공식 관측 가능성 UI입니다. 서비스 메시의 토폴로지, 트래픽 흐름, 설정 검증을 시각적으로 제공합니다.

핵심 기능

서비스 그래프: 서비스 간 통신 토폴로지를 실시간으로 시각화합니다. 각 엣지에 요청량, 에러율, 지연 시간이 표시됩니다.

Kiali 서비스 그래프 예시:

  [frontend] ──(95%, 200 RPS)──→ [reviews]
      │                               │
      │                          (99%, 180 RPS)
      │                               ▼
      └──(98%, 150 RPS)──→ [details] [ratings]

설정 검증: VirtualService, DestinationRule 등 Istio CRD의 설정 오류를 자동으로 감지합니다. 존재하지 않는 서비스 참조, 잘못된 라벨 셀렉터 등을 경고합니다.

트래픽 시뮬레이션: UI에서 트래픽 라우팅 규칙을 시각적으로 확인하고, 가중치 변경의 영향을 미리 볼 수 있습니다.

bash
# Kiali 설치 (Istio 애드온)
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.25/samples/addons/kiali.yaml
 
# 대시보드 접근
istioctl dashboard kiali

Cilium Hubble의 관측 가능성

Cilium 환경에서는 Hubble이 eBPF 기반의 네트워크 관측 가능성을 제공합니다.

Hubble 메트릭

Hubble은 커널 수준에서 수집한 네트워크 플로우를 Prometheus 메트릭으로 변환합니다.

Hubble 메트릭 설정
yaml
# Cilium Helm values
hubble:
  enabled: true
  metrics:
    enabled:
      - dns
      - drop
      - tcp
      - flow
      - icmp
      - httpV2:exemplars=true;labelsContext=source_ip,destination_ip

Hubble CLI

명령줄에서 실시간 네트워크 플로우를 관찰할 수 있습니다.

bash
# 특정 네임스페이스의 HTTP 트래픽 관찰
hubble observe --namespace production --protocol http
 
# 거부된 트래픽만 필터링
hubble observe --verdict DROPPED
 
# 특정 서비스 간 트래픽
hubble observe --from-label app=frontend --to-label app=reviews
 
# JSON 출력 (로그 수집 시스템 연동)
hubble observe --output json --namespace production

알림 설계

관측 가능성 데이터를 기반으로 한 알림 설계 예시입니다.

SLO 기반 알림

Prometheus 알림 규칙
yaml
groups:
  - name: service-mesh-slo
    rules:
      # 서비스 에러율이 SLO 위반 (5분간 99.9% 미만)
      - alert: ServiceErrorBudgetBurn
        expr: |
          (
            1 - (
              sum(rate(istio_requests_total{
                response_code!~"5.*",
                destination_service=~".+\\.production\\.svc\\.cluster\\.local"
              }[5m])) by (destination_service)
              /
              sum(rate(istio_requests_total{
                destination_service=~".+\\.production\\.svc\\.cluster\\.local"
              }[5m])) by (destination_service)
            )
          ) > 0.001
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.destination_service }} 에러율 SLO 위반"
 
      # P99 지연 시간 임계치 초과
      - alert: ServiceLatencyHigh
        expr: |
          histogram_quantile(0.99,
            sum(rate(istio_request_duration_milliseconds_bucket{
              destination_service=~".+\\.production\\.svc\\.cluster\\.local"
            }[5m])) by (le, destination_service)
          ) > 500
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.destination_service }} P99 지연 500ms 초과"
 
      # mTLS 비율 저하 감지
      - alert: MtlsCoverageDropped
        expr: |
          sum(rate(istio_requests_total{
            connection_security_policy="mutual_tls"
          }[5m]))
          /
          sum(rate(istio_requests_total[5m]))
          < 0.99
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "mTLS 적용 비율이 99% 미만으로 하락"

실전 관측 가능성 아키텍처

프로덕션 환경의 관측 가능성 스택 구성 예시입니다.

서비스 메시 관측 가능성 스택

┌──────────────────────────────────────────────┐
│ 시각화 계층                                    │
│  ┌──────┐  ┌──────┐  ┌──────┐               │
│  │Kiali │  │Grafana│  │Jaeger│               │
│  └───┬──┘  └───┬──┘  └───┬──┘               │
│      │         │         │                    │
├──────┼─────────┼─────────┼────────────────────┤
│ 저장 계층      │         │                    │
│  ┌─────────────▼────┐ ┌──▼──────────────┐    │
│  │ Prometheus        │ │ Jaeger/Tempo    │    │
│  │ (메트릭 저장)     │ │ (트레이스 저장)  │    │
│  └──────────────────┘ └─────────────────┘    │
│                                               │
├───────────────────────────────────────────────┤
│ 수집 계층                                      │
│  ┌──────────────────────────────────────────┐ │
│  │ OTel Collector (선택)                     │ │
│  │ 메트릭/트레이스/로그 통합 수집             │ │
│  └──────────────────────────────────────────┘ │
│                                               │
├───────────────────────────────────────────────┤
│ 생성 계층                                      │
│  [Envoy/ztunnel 프록시 or eBPF]               │
│  자동 메트릭 + 트레이스 + 로그 생성            │
└───────────────────────────────────────────────┘
Tip

OpenTelemetry Collector를 중간에 배치하면 메트릭, 트레이스, 로그의 수집 경로를 통합하고, 백엔드 스토리지를 자유롭게 교체할 수 있습니다. Istio는 OpenTelemetry 내보내기를 네이티브로 지원합니다.

핵심 요약

  • 서비스 메시는 메트릭, 분산 추적, 액세스 로그를 애플리케이션 수정 없이 자동 수집합니다
  • 골든 시그널(지연, 트래픽, 에러, 포화도) 메트릭이 서비스 건강도의 핵심 지표입니다
  • 분산 추적은 프록시가 헤더를 주입하지만, 애플리케이션의 헤더 전파가 필수입니다
  • Kiali(Istio)와 Hubble(Cilium)이 각 메시의 핵심 시각화 도구입니다
  • SLO 기반 알림으로 에러 버짓 소진과 지연 시간 임계치를 모니터링합니다

다음 장에서는 사이드카 없는 서비스 메시의 현재와 미래를 종합적으로 분석하겠습니다.

이 글이 도움이 되셨나요?

관련 글

인프라

9장: 사이드카 없는 서비스 메시 - Ambient Mesh와 eBPF

서비스 메시의 패러다임 전환인 사이드카 없는 아키텍처를 분석합니다. Istio Ambient Mesh와 Cilium eBPF의 비교, 마이그레이션 전략, 그리고 미래 전망까지.

2026년 5월 3일·16분
인프라

7장: mTLS와 제로 트러스트 네트워킹

서비스 메시의 보안 기반인 mTLS의 작동 원리, SPIFFE 워크로드 아이덴티티, 인증서 관리, 그리고 제로 트러스트 아키텍처 구현 전략을 다룹니다.

2026년 4월 28일·15분
인프라

10장: 실전 프로젝트 - 서비스 메시 도입과 운영 전략

실전 마이크로서비스 환경에서 서비스 메시를 도입하는 전체 과정을 다룹니다. 기술 선택, 설치, 보안 설정, 트래픽 관리, 관측 가능성, 운영 자동화까지.

2026년 5월 7일·13분
이전 글7장: mTLS와 제로 트러스트 네트워킹
다음 글9장: 사이드카 없는 서비스 메시 - Ambient Mesh와 eBPF

댓글

목차

약 11분 남음
  • 관측 가능성의 세 기둥
    • 1. 메트릭 (Metrics)
    • 2. 분산 추적 (Distributed Tracing)
    • 3. 액세스 로그 (Access Logs)
  • Prometheus + Grafana 연동
    • Istio 메트릭 수집
    • 핵심 대시보드 메트릭
  • Kiali: 서비스 메시 시각화
    • 핵심 기능
  • Cilium Hubble의 관측 가능성
    • Hubble 메트릭
    • Hubble CLI
  • 알림 설계
    • SLO 기반 알림
  • 실전 관측 가능성 아키텍처
  • 핵심 요약