마이크로서비스 환경에서 서비스 수가 늘어날수록 서비스 간 통신 관리가 복잡해진다. 재시도 로직, 타임아웃, 암호화, 트래픽 라우팅을 각 서비스가 직접 구현하면 언어마다 중복 코드가 생기고 일관성을 유지하기 어렵다. Service Mesh는 이 문제를 애플리케이션 코드가 아닌 인프라 계층에서 해결한다.
Service Mesh는 서비스 간 네트워크 통신을 투명하게 가로채어 라우팅, 보안, 관찰 가능성(Observability)을 제공하는 인프라 레이어다. 각 서비스 옆에 Sidecar Proxy를 붙여 인바운드·아웃바운드 트래픽을 모두 프록시를 통해 처리한다.
Service Mesh — 서비스 간 통신을 전담하는 인프라 계층. 데이터 플레인(Data Plane)과 컨트롤 플레인(Control Plane)으로 나뉜다.
┌──────────────────────┐ ┌──────────────────────┐
│ Service A Pod │ │ Service B Pod │
│ ┌────────┐ │ │ ┌────────┐ │
│ │ App │◄────────►│ │ │ App │ │
│ └────┬───┘ │ │ └────┬───┘ │
│ │ │ │ │ │
│ ┌────▼───┐ │ │ ┌────▼───┐ │
│ │ Envoy │◄─────────┼─────►│ │ Envoy │ │
│ └────────┘ │ │ └────────┘ │
└──────────────────────┘ └──────────────────────┘
▲ ▲
└──────────┐ ┌──────────────┘
┌────▼──▼────┐
│ Control │
│ Plane │
└────────────┘
각 Pod에 Sidecar로 주입된 Envoy Proxy가 App 대신 네트워크 통신을 처리한다. App은 localhost로 Envoy와 통신하고, Envoy가 실제 목적지 서비스로 트래픽을 전달한다. Control Plane은 모든 Envoy에 라우팅 규칙, 정책, 인증서를 배포한다.
Envoy — Lyft가 개발한 고성능 C++ 프록시. Service Mesh의 Data Plane으로 가장 널리 쓰인다.
| 기능 | 설명 |
|---|---|
| mTLS | 서비스 간 상호 TLS 인증으로 암호화와 신원 검증을 동시에 처리 |
| Traffic Routing | 가중치 기반 라우팅, Canary 배포, A/B 테스트 지원 |
| Retry / Timeout | 코드 변경 없이 재시도 횟수와 타임아웃 설정 |
| Circuit Breaker | 장애 서비스로의 트래픽 차단으로 연쇄 장애 방지 |
| Observability | 요청별 메트릭, 분산 트레이싱, 로그를 자동으로 수집 |
mTLS(Mutual TLS) — 클라이언트와 서버 양측이 서로 인증서를 검증하는 TLS 방식. 단방향 TLS와 달리 양방향 신뢰를 보장한다.
Istio는 가장 널리 쓰이는 Service Mesh 구현체다. Control Plane 컴포넌트인 istiod가 Envoy 설정 배포, 인증서 발급, 정책 관리를 담당한다.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 90
- destination:
host: reviews
subset: v2
weight: 10
위 VirtualService 설정은 reviews 서비스 트래픽의 90%를 v1, 10%를 v2로 라우팅한다. App 코드는 전혀 수정하지 않는다.
장점
단점
서비스 수가 수십 개를 넘고 보안과 가시성 요구가 높아질 때 Service Mesh의 이점이 운영 비용을 상회한다. 소규모 시스템에서는 오히려 과도한 복잡성이 될 수 있으므로 도입 시점을 신중하게 판단해야 한다.