서비스 메시가 제공하는 관측 가능성의 세 기둥을 분석합니다. 분산 추적, 골든 시그널 메트릭, 액세스 로그, 그리고 Kiali/Grafana 연동까지.
서비스 메시의 가장 즉각적인 가치 중 하나가 관측 가능성(Observability)입니다. 프록시가 모든 트래픽을 중계하므로, 애플리케이션 코드를 수정하지 않고도 서비스 간 통신의 메트릭, 트레이스, 로그를 자동으로 수집할 수 있습니다. 이 장에서는 서비스 메시의 관측 가능성 기능을 체계적으로 살펴보겠습니다.
서비스 메시는 관측 가능성의 세 가지 핵심 데이터를 자동 생성합니다.
서비스 간 트래픽의 수치적 측정값입니다. 서비스 메시는 기본적으로 골든 시그널(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 대시보드에서 시각화합니다.
하나의 사용자 요청이 여러 서비스를 거치는 전체 경로를 추적합니다.
사용자 요청의 추적 경로:
[Trace ID: abc123]
├── [Span] frontend (12ms)
│ ├── [Span] reviews (8ms)
│ │ └── [Span] ratings (3ms)
│ └── [Span] details (5ms)
└── 전체 소요: 25ms
서비스 메시 프록시는 요청에 추적 헤더를 자동으로 주입합니다. 다만, 서비스 내부에서 다른 서비스를 호출할 때 이 헤더를 **전파(propagation)**해야 합니다.
서비스 메시가 추적 헤더를 자동 생성하지만, 애플리케이션이 수신한 헤더를 하위 호출에 전파해야 트레이스가 연결됩니다. 다음 헤더들을 전파하세요: x-request-id, x-b3-traceid, x-b3-spanid, x-b3-parentspanid, x-b3-sampled, traceparent, tracestate.
Istio에서 분산 추적을 활성화하고 Jaeger로 수집하는 설정입니다.
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
meshConfig:
enableTracing: true
defaultConfig:
tracing:
sampling: 100 # 샘플링 비율 (프로덕션에서는 1~10% 권장)
zipkin:
address: jaeger-collector.observability:9411각 요청의 상세 정보를 텍스트 로그로 기록합니다.
apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
name: mesh-default
namespace: istio-system
spec:
accessLogging:
- providers:
- name: envoyEnvoy 액세스 로그의 기본 형식:
[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
Istio는 Envoy 프록시에서 Prometheus 호환 메트릭을 노출합니다. Prometheus가 이를 스크레이핑합니다.
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프로덕션 환경에서 모니터링해야 할 핵심 메트릭입니다.
서비스 수준 메트릭:
# 서비스별 성공률 (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]))메시 수준 메트릭:
# 메시 전체 에러율
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는 Istio의 공식 관측 가능성 UI입니다. 서비스 메시의 토폴로지, 트래픽 흐름, 설정 검증을 시각적으로 제공합니다.
서비스 그래프: 서비스 간 통신 토폴로지를 실시간으로 시각화합니다. 각 엣지에 요청량, 에러율, 지연 시간이 표시됩니다.
Kiali 서비스 그래프 예시:
[frontend] ──(95%, 200 RPS)──→ [reviews]
│ │
│ (99%, 180 RPS)
│ ▼
└──(98%, 150 RPS)──→ [details] [ratings]
설정 검증: VirtualService, DestinationRule 등 Istio CRD의 설정 오류를 자동으로 감지합니다. 존재하지 않는 서비스 참조, 잘못된 라벨 셀렉터 등을 경고합니다.
트래픽 시뮬레이션: UI에서 트래픽 라우팅 규칙을 시각적으로 확인하고, 가중치 변경의 영향을 미리 볼 수 있습니다.
# Kiali 설치 (Istio 애드온)
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.25/samples/addons/kiali.yaml
# 대시보드 접근
istioctl dashboard kialiCilium 환경에서는 Hubble이 eBPF 기반의 네트워크 관측 가능성을 제공합니다.
Hubble은 커널 수준에서 수집한 네트워크 플로우를 Prometheus 메트릭으로 변환합니다.
# Cilium Helm values
hubble:
enabled: true
metrics:
enabled:
- dns
- drop
- tcp
- flow
- icmp
- httpV2:exemplars=true;labelsContext=source_ip,destination_ip명령줄에서 실시간 네트워크 플로우를 관찰할 수 있습니다.
# 특정 네임스페이스의 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관측 가능성 데이터를 기반으로 한 알림 설계 예시입니다.
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] │
│ 자동 메트릭 + 트레이스 + 로그 생성 │
└───────────────────────────────────────────────┘
OpenTelemetry Collector를 중간에 배치하면 메트릭, 트레이스, 로그의 수집 경로를 통합하고, 백엔드 스토리지를 자유롭게 교체할 수 있습니다. Istio는 OpenTelemetry 내보내기를 네이티브로 지원합니다.
다음 장에서는 사이드카 없는 서비스 메시의 현재와 미래를 종합적으로 분석하겠습니다.
이 글이 도움이 되셨나요?
서비스 메시의 패러다임 전환인 사이드카 없는 아키텍처를 분석합니다. Istio Ambient Mesh와 Cilium eBPF의 비교, 마이그레이션 전략, 그리고 미래 전망까지.
서비스 메시의 보안 기반인 mTLS의 작동 원리, SPIFFE 워크로드 아이덴티티, 인증서 관리, 그리고 제로 트러스트 아키텍처 구현 전략을 다룹니다.
실전 마이크로서비스 환경에서 서비스 메시를 도입하는 전체 과정을 다룹니다. 기술 선택, 설치, 보안 설정, 트래픽 관리, 관측 가능성, 운영 자동화까지.