Skip to main content

Service Mesh — Istio & Linkerd

마이크로서비스 간 통신을 인프라 레이어에서 관리


1. Service Mesh란

1.1 왜 필요한가

마이크로서비스가 많아지면 서비스 간 통신에서 발생하는 문제들:

  • 서비스 디스커버리, 로드밸런싱
  • 재시도, 서킷 브레이커, 타임아웃
  • mTLS (서비스 간 암호화)
  • 관찰성 (어떤 서비스가 어떤 서비스를 호출하는가)

이 로직을 **앱 코드에서 분리하여 인프라 레이어(Sidecar Proxy)**로 이동.

1.2 Sidecar 패턴

flowchart LR
subgraph PodA["Pod A"]
AppA["App A"] <--> ProxyA["Envoy<br/>(Sidecar)"]
end
subgraph PodB["Pod B"]
ProxyB["Envoy<br/>(Sidecar)"] <--> AppB["App B"]
end

ProxyA <-->|"mTLS"| ProxyB

모든 네트워크 트래픽이 Envoy Proxy를 경유. 앱은 localhost로 통신하면 되고, 나머지는 프록시가 처리.


2. Istio

2.1 아키텍처

flowchart TB
subgraph ControlPlane_Istio["Control Plane"]
Istiod["istiod<br/>(Pilot + Citadel + Galley)"]
end

subgraph DataPlane_Istio["Data Plane"]
subgraph Pod1_Istio["Pod 1"]
App1_Istio["App"] <--> Envoy1["Envoy"]
end
subgraph Pod2_Istio["Pod 2"]
App2_Istio["App"] <--> Envoy2["Envoy"]
end
end

Istiod -->|"설정 배포<br/>(xDS API)"| Envoy1 & Envoy2
Envoy1 <-->|"mTLS"| Envoy2
컴포넌트역할
istiodService Mesh 두뇌. 설정 배포, 인증서 발급, 서비스 디스커버리
Envoy고성능 L7 프록시. 각 Pod에 Sidecar로 자동 주입

2.2 트래픽 관리

카나리 배포:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: web
spec:
hosts:
- web
http:
- route:
- destination:
host: web
subset: v1
weight: 90 # 90% → v1
- destination:
host: web
subset: v2
weight: 10 # 10% → v2 (카나리)
기능설명
가중치 라우팅트래픽 비율로 카나리 배포
헤더 기반 라우팅특정 헤더 → 특정 버전 (A/B 테스트)
서킷 브레이커연속 실패 시 호출 차단
재시도/타임아웃자동 재시도, 타임아웃 설정
장애 주입의도적 지연/오류 (카오스 엔지니어링)

2.3 mTLS

서비스 간 통신을 자동으로 TLS 암호화. 인증서 발급/갱신/교체를 istiod가 자동 관리.

2.4 관찰성

도구역할
Kiali서비스 메시 토폴로지 시각화
Jaeger/Zipkin분산 트레이싱
Prometheus/Grafana메트릭

3. Linkerd

IstioLinkerd
프록시Envoy (C++)linkerd2-proxy (Rust)
복잡도높음 (기능 많음)✅ 낮음 (간결)
리소스많음✅ 적음
기능매우 풍부핵심에 집중
mTLS
트래픽 관리✅ (풍부)기본적
추천대규모, 복잡한 요구소~중규모, 빠른 도입

4. Service Mesh가 필요한 상황

상황필요?
서비스 3~5개❌ 오버킬
서비스 10개+⚠️ 검토
서비스 수십 개+
mTLS 필수 (금융/규제)
카나리/A/B 배포 필요
분산 트레이싱 필요
팀 역량 부족❌ 먼저 기본 익히기

다음 글

→ #14 Operator Pattern & CRD