마이크로서비스가 늘어나면 서비스끼리 호출하는 망이 복잡해집니다. "이 호출을 재시도할까", "트래픽의 10%만 새 버전으로 보낼까", "서비스 간 통신을 암호화할까" 같은 요구가 모든 서비스 코드에 흩어집니다. 서비스 메시는 이런 통신 관련 로직을 애플리케이션 밖으로 빼내 인프라 계층에서 처리하고, Istio는 그 대표적인 구현입니다.
서비스 메시가 푸는 문제
핵심 아이디어는 각 Pod 옆에 사이드카 프록시(Envoy)를 붙이는 것입니다. 서비스가 보내고 받는 모든 트래픽이 이 프록시를 거치므로, 재시도·타임아웃·암호화·트래픽 분배 같은 일을 애플리케이션 코드를 고치지 않고 프록시 수준에서 처리할 수 있습니다.
| 관심사 | 메시 없이 | 서비스 메시 |
|---|---|---|
| 재시도·타임아웃 | 각 서비스 코드에 구현 | 프록시가 처리 |
| 서비스 간 암호화(mTLS) | 직접 인증서 관리 | 메시가 자동 |
| 카나리·트래픽 분배 | 배포 도구로 수동 | 라우팅 규칙으로 선언 |
| 호출 추적·메트릭 | 서비스마다 계측 | 프록시가 자동 수집 |
데이터 플레인과 컨트롤 플레인
Istio는 두 부분으로 나뉩니다. 데이터 플레인은 실제 트래픽을 나르는 사이드카 프록시들이고, 컨트롤 플레인(istiod)은 그 프록시들에게 "이렇게 라우팅해라"는 설정을 내려보내는 두뇌입니다. 우리가 작성하는 규칙은 컨트롤 플레인으로 들어가고, 그것이 각 프록시에 반영됩니다.
트래픽 분배는 VirtualService로 선언합니다.
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 90
- destination:
host: reviews
subset: v2
weight: 10
이 규칙 하나로 트래픽의 90%는 v1, 10%는 v2로 흘러갑니다. 애플리케이션은 전혀 바뀌지 않습니다 — 카나리 배포가 설정만으로 됩니다.
사이드카와 라우팅 확인하기
사이드카가 제대로 주입됐는지, 프록시 설정이 어떤지 직접 볼 수 있습니다.
kubectl get pods -n shop # READY 2/2 면 사이드카 주입됨
istioctl proxy-status
istioctl proxy-config routes <pod-name> -n shop
READY 2/2는 컨테이너 1개 + 사이드카 1개가 함께 떠 있다는 뜻입니다.
요점 정리
- 서비스 메시는 통신 로직(재시도·암호화·라우팅)을 앱 밖 인프라 계층으로 옮긴다.
- Istio는 각 Pod에 Envoy 사이드카를 붙여 모든 트래픽을 프록시로 통과시킨다.
- 컨트롤 플레인(istiod)이 규칙을 만들고 데이터 플레인 프록시에 배포한다.
VirtualService로 코드 수정 없이 카나리·트래픽 분배를 선언할 수 있다.
Istio를 클러스터에 설치하고 사이드카 주입과 트래픽 라우팅을 직접 다뤄 보는 실습은 쿠버네티스 트랙에서 할 수 있습니다 — 회원가입 없이 무료로.