서비스 메시(Istio) — 있을 때와 없을 때
재시도·mTLS·메트릭·서킷 브레이커라는 통신 관심사가 '각 서비스의 코드'에서 '사이드카 프록시'로 옮겨 가는 것과, YAML만으로 90:10 카나리 분할이 되는 것을 비교 실행한다.
1 / 7마이크로서비스 20개가 서로를 부릅니다. 재시도·타임아웃·암호화·메트릭 — 이 통신 관심사를 누가 맡을까요? 메시가 없다면, 전부 각 서비스의 코드입니다.
주문 서비스
비즈니스 로직재시도·타임아웃mTLS 암호화메트릭·추적서킷 브레이커
결제 서비스
비즈니스 로직재시도·타임아웃mTLS 암호화메트릭·추적서킷 브레이커
통신 관심사 4종의 자리: 각 서비스의 코드 (언어별 중복)
서비스 간 암호화: 각자 구현
단계 목록 · 키보드 ←/→ 이동, Space 재생
서비스 메시는 '통신 관심사(재시도·암호화·관측·트래픽 제어)를 코드에서 뽑아 인프라 층(사이드카)으로 내리는 것'이다 — 언어와 무관해지고, 정책이 YAML 한 장으로 전 서비스에 걸린다.
왜 헷갈리는가
"메시 = 마이크로서비스 필수품"도, "그냥 프록시 아닌가"도 과녁을 빗나간다. 본질은 횡단 관심사의 소유권 이동이다 — 서비스 20개 × 언어 3종에 재시도 정책을 일관되게 거는 문제를 코드로 풀 것인가, 인프라로 풀 것인가.
애니메이션이 보여주는 것
메시 없는 세상: 재시도·타임아웃·mTLS·메트릭이 서비스마다 코드로 들어간다. Java·Go·Python 구현이 미묘하게 다르고, 정책 변경 = 전 서비스 재배포다.
메시를 깔면 각 파드에 사이드카(Envoy)가 서고 모든 출입 트래픽이 그를 지난다. 관심사 4종이 통째로 프록시의 일이 되고, istiod가 인증서를 발급·회전하며 서비스 간 mTLS가 자동으로 걸린다. 카나리 장면이 보여주듯 트래픽의 90:10 분할도 배포가 아니라 라우팅 규칙(YAML)이다.
구성 요소와 대가
Istio 기준으로 데이터 플레인과 컨트롤 플레인이 나뉜다.
- 데이터 플레인: 파드마다 Envoy 사이드카 — 실제 트래픽이 지나는 곳. 요청당 홉 2개 추가(수 ms), 파드당 메모리 수십 MB.
- 컨트롤 플레인: istiod — 정책·인증서·서비스 발견을 사이드카들에 배포. 죽어도 데이터 플레인은 마지막 설정으로 계속 돈다.
- 관측성: 모든 호출이 프록시를 지나므로 호출 그래프·지연 백분위·오류율이 코드 수정 0으로 수집된다(Kiali·Jaeger·Prometheus).
- 대가: 부품 하나(업그레이드·디버깅 대상)가 늘고, 문제 시 '앱이냐 프록시냐' 층이 하나 더 생긴다. 최근의 ambient 모드는 사이드카를 노드 공유 프록시로 바꿔 이 비용을 줄이려는 시도다.
- 판단 기준: 서비스 몇 개·단일 언어면 라이브러리(resilience4j 등)로 충분. 서비스·팀·언어가 늘어 정책 일관성이 무너질 때, 규제로 전 구간 암호화가 필요할 때 메시가 값을 한다.
기억할 것
- 메시의 본질 = 통신 관심사의 소유권을 코드에서 인프라로 이동.
- 사이드카가 데이터 플레인, istiod가 컨트롤 플레인 — 정책은 YAML로 전파된다.
- mTLS·재시도·카나리·관측이 코드 수정 0으로 걸리는 것이 값어치.
- 대가는 홉·메모리·운영 복잡도 — 작은 시스템엔 라이브러리가 정답이다.