Portfolio

개념

Service Mesh는 Kubernetes 클러스터 내 서비스 간(서버↔서버) 통신을 처리하는 인프라 레이어다. 각 서비스 Pod 옆에 사이드카 프록시(Envoy)를 붙여서, 서비스가 서로 직접 통신하는 대신 프록시를 통해 통신하게 한다. 인증(mTLS), 트래픽 제어, 관측성을 애플리케이션 코드 수정 없이 인프라 레벨에서 처리한다.

API Gateway나 Ingress가 외부 → 내부 진입점이라면, Service Mesh는 내부 서비스 간 통신을 담당한다.

[외부 클라이언트]
      ↓
[Ingress Controller]     ← 외부 → 내부 진입점
      ↓
[서비스 A] ←→ [서비스 B]  ← Service Mesh가 처리하는 영역

왜 필요한가

서비스가 많아지면 각 서비스가 직접 해결해야 하는 문제들이 생긴다.

서비스 간 통신을 암호화(mTLS)하려면 각 서비스마다 인증서 관리 코드가 필요
재시도, 타임아웃, 서킷브레이커를 각 서비스마다 중복 구현
어떤 서비스가 어떤 서비스를 얼마나 호출하는지 관측이 어려움

Service Mesh는 이 공통 관심사를 사이드카로 빼내서 서비스 코드를 얇게 유지한다.

구조

Data Plane / Control Plane

Control Plane (Istiod 등)
  → 정책·인증서·설정 배포

Data Plane (각 Pod의 Envoy 사이드카)
  → 실제 트래픽 처리

Control Plane이 인증서 발급·교체, 트래픽 정책을 중앙 관리하고, 각 사이드카는 그 설정에 따라 트래픽을 처리한다.

사이드카 주입

Kubernetes가 Pod 생성 시 자동으로 Envoy 컨테이너를 주입한다(Admission Webhook). 애플리케이션 Dockerfile이나 코드는 건드리지 않는다.

mTLS 자동 처리

Service Mesh의 핵심 기능이다. 서비스 간 모든 통신을 **상호 TLS(mTLS)**로 암호화한다.

서비스 A [Envoy] ←── mTLS ──→ [Envoy] 서비스 B

각 서비스에 고유한 인증서가 발급됨
인증서 교체도 자동 (수명이 짧은 인증서를 자주 교체)
"이 트래픽이 정말 서비스 A에서 왔나"를 암호학적으로 검증

mTLS가 있으면 Token Exchange 없이도 서비스 간 신뢰를 구현할 수 있다. 헤더를 조작해도 인증서가 없으면 통신 자체가 불가능하다.

SPIFFE / 워크로드 ID

**SPIFFE(Secure Production Identity Framework For Everyone)**는 워크로드(서비스, Pod)에 ID를 부여하는 표준이다.

SPIFFE ID 형식: spiffe://<trust-domain>/<workload-identifier>
예: spiffe://datco.kr/ns/prod/sa/hr-service

Istio는 내부적으로 SPIFFE를 사용해 각 Pod에 X.509 인증서를 발급한다. 서비스가 "나는 hr-service다"를 암호학적으로 증명할 수 있다. SPIRE는 SPIFFE의 참조 구현체로, K8s 외 환경에서도 워크로드 ID를 제공한다.

ext-authz 패턴

Envoy의 external authorization 필터. 사이드카나 Ingress의 Envoy가 각 요청을 외부 인증 서비스로 위임해 허용/거부를 판단받는다.

요청 → Envoy 사이드카
         ↓ gRPC
     ext-authz 서비스 (인증·인가 판단)
         ↓ OK / DENIED
     백엔드 서비스 또는 거부

인증 로직을 애플리케이션과 분리할 수 있다. BFF 세션 검증, OPA 정책 평가 등을 ext-authz로 연결하는 패턴이 많다.

Istio vs Linkerd

	Istio	Linkerd
사이드카	Envoy (C++)	linkerd-proxy (Rust)
기능	풍부 (트래픽 관리, ext-authz, 멀티클러스터)	핵심만 (mTLS, 관측성)
운영 복잡도	높음	낮음
성능	상대적으로 무거움	가벼움
채택률	더 높음	더 낮음

기능이 많이 필요하면 Istio, 단순하게 mTLS와 관측성만 원하면 Linkerd.

언제 쓰나

도입 전에 복잡도 비용을 따져야 한다.

도입이 합리적인 경우

서비스 수가 많고(10개+) 서비스 간 통신 보안이 필요
여러 팀이 각자 서비스를 운영하고 중앙 정책 적용이 필요
카나리 배포, 서킷브레이커 같은 고급 트래픽 제어가 필요

과한 경우

서비스 수가 적음 (3~5개)
팀 규모가 작아 Service Mesh 운영 인력이 없음
K8s를 막 도입한 단계

CNCF 2024 기준 Service Mesh 도입률은 약 40% 수준이다. K8s를 쓴다고 해서 반드시 Service Mesh가 필요한 것은 아니다.

개념