서비스 메시란 무엇인가?
마이크로서비스의 수가 늘어날수록, 서비스 간 통신을 관리하는 것이 점점 어려워진다. 각 서비스마다 Retry 로직을 구현하고, mTLS 인증서를 관리하고, Circuit Breaker 설정을 넣는다면? 100개의 서비스가 있다면 100군데에 중복 코드가 생긴다.
서비스 메시는 이 문제를 애플리케이션 코드 바깥으로 꺼내는 방식으로 해결한다. 각 서비스 옆에 Sidecar Proxy를 붙이고, 모든 네트워크 트래픽이 이 Proxy를 거치도록 한다. 개발자는 비즈니스 로직에만 집중하고, Retry, Timeout, Circuit Breaker, mTLS, 트레이싱 같은 공통 네트워크 관심사는 서비스 메시가 처리한다.
서비스 메시 = 서비스 간 통신(East-West 트래픽)을 전담하는 인프라 계층
서비스 메시가 필요한 이유
서비스 수가 적을 때는 문제가 보이지 않는다. 하지만 수십 개 이상의 서비스가 서로 얽히기 시작하면 다음 문제들이 현실로 다가온다.
기존 방식의 문제 (Before)
- 서비스마다 Retry/Timeout/Circuit Breaker 코드를 직접 구현해야 함
- 서비스 간 암호화(mTLS)를 각 서비스가 직접 구현하고 인증서를 관리해야 함
- 장애 발생 시 어느 서비스에서 문제가 생겼는지 추적이 어려움
- A/B 테스트, Canary 배포처럼 트래픽을 세밀하게 제어하려면 코드를 수정해야 함
서비스 메시 도입 후 (After)
- mTLS 자동 적용. 인증서 발급과 갱신을 서비스 메시의 Control Plane이 담당
- Retry, Timeout, Circuit Breaker, Rate Limit을 YAML 정책으로 선언적 설정
- 모든 서비스 간 트래픽의 메트릭, 로그, 트레이스를 자동 수집
- 트래픽 비율(90%/10% 등)을 YAML로 선언하여 Canary, Blue-Green 배포 지원
서비스 메시 구성 요소
Data Plane (데이터 플레인)
각 Pod/서비스 옆에 붙는 Sidecar Proxy (주로 Envoy)가 Data Plane을 구성한다. 실제 패킷이 오가는 구간이다. 모든 서비스 통신은 App → Sidecar → (네트워크) → Sidecar → App 경로로 흐른다. App은 자신이 Sidecar를 통해 통신하고 있다는 사실을 모른다.
Control Plane (컨트롤 플레인)
Istio, Linkerd, Consul 등이 Control Plane 역할을 한다. Sidecar Proxy들에게 설정과 정책을 배포하고, 인증서를 발급하며, 라우팅 규칙과 Telemetry 설정을 관리한다.
Ingress / Egress Gateway
- Ingress Gateway: 외부 → Mesh 내부로 들어오는 트래픽의 관문. TLS 종단, 인증/인가 처리.
- Egress Gateway: Mesh 내부 → 외부 서비스로 나가는 트래픽의 관문. 외부 API 호출을 정책으로 제어하고 모니터링.
CA & mTLS
서비스 메시는 자체 인증 기관(CA) 을 운영하여 각 서비스에 인증서를 자동 발급한다. 서비스 간 통신 시 이 인증서로 상호 TLS(mTLS) 인증을 수행한다. 즉, 클라이언트와 서버 양쪽이 서로의 신원을 검증한다. 이것이 Zero Trust 네트워크의 기반이 된다.
서비스 메시 트래픽 흐름 (End-to-End)
클라우드 네이티브 네트워킹 핵심 개념
트래픽 방향에 따른 분류
| 방향 | 설명 | 주요 컴포넌트 | 설계 집중 포인트 |
|---|---|---|---|
| North-South | 외부 ↔ 클러스터 내부 | Cloud LB, Ingress Controller, API Gateway, WAF | 보안, 인증, API 관리 |
| East-West | 서비스 ↔ 서비스 내부 | K8s Service, DNS, Service Mesh, CNI | 디스커버리, 로드밸런싱, mTLS |
대부분의 트래픽은 East-West, 즉 서비스들끼리의 내부 통신이다. 서비스 메시가 특히 중요한 이유가 여기에 있다.
L4 vs L7 라우팅
- L4 (TCP/UDP): IP와 포트 기반. 패킷 내용을 모른 채 IP:Port로만 전달. 빠르지만 세밀한 제어 불가.
- L7 (HTTP/gRPC): URL, 헤더, 쿠키, 메서드 등 애플리케이션 레벨 정보 기반. Header 값에 따라 다른 버전으로 라우팅하거나, 특정 경로만 허용하는 세밀한 정책 적용 가능.
서비스 메시는 L7 수준에서 트래픽을 인식하기 때문에 Canary 배포, A/B 테스트, 서킷 브레이커 같은 고급 트래픽 제어가 가능하다.
Kubernetes 네트워크 기본 원칙
Kubernetes의 네트워크 모델은 다음 세 가지 원칙을 따른다.
- Pod는 고유한 IP를 가진다 (IP-per-Pod): 모든 Pod는 고유한 IP를 가지며, Pod ↔ Pod 간 통신 시 NAT 없이 직접 IP로 통신한다.
- 모든 Pod는 다른 모든 Pod와 통신 가능하다: 기본 상태에서 Pod 간에 방화벽이 없다. NetworkPolicy로 필요한 경우에만 차단한다.
- Node와 Pod 간에도 직접 통신 가능하다.
이 모델을 실제로 구현하는 것이 CNI(Container Network Interface) 플러그인이다.
Pod IP의 문제와 Service의 역할
Pod IP는 스케일링, 재시작, 재배치 시마다 바뀐다. 따라서 특정 Pod IP를 직접 호출하는 것은 불안정하다. Kubernetes의 Service 리소스가 안정적인 가상 IP(ClusterIP)를 제공하고, 이 IP로 들어오는 트래픽을 뒤에 있는 Pod들에게 로드밸런싱해준다.
CNI 플러그인 비교
CNI는 Pod 생성/삭제 시 IP 할당, 라우팅 설정, 가상 네트워크를 구성한다.
| CNI | 기반 기술 | 특징 |
|---|---|---|
| Calico | L3 (BGP 라우팅) | 성능 우수, NetworkPolicy 지원 강점, 대규모 운영에 적합 |
| Flannel | L2 (VXLAN Overlay) | 단순하고 가볍지만 NetworkPolicy 미지원 |
| Cilium | eBPF | 고성능 데이터 플레인, L7 가시성, 차세대 CNI |
| Amazon VPC CNI | AWS VPC | EKS에서 Pod에 VPC IP 직접 할당, AWS 서비스와 자연스러운 통합 |
Kubernetes Service 타입
| 타입 | 접근 범위 | 주요 용도 |
|---|---|---|
| ClusterIP | 클러스터 내부 | 서비스 ↔ 서비스 통신 (기본값) |
| NodePort | 각 Node의 특정 포트 | 외부 접근이 필요하나 단순한 경우 |
| LoadBalancer | 외부 (클라우드 LB) | 외부에 공개하는 서비스 |
DNS 기반 서비스 접근: http://payment-service.default.svc.cluster.local
Ingress & API Gateway
- Ingress: HTTP(S) L7 라우팅. Host, Path 기반으로 여러 서비스를 하나의 도메인으로 노출.
- 예:
/api/orders→ order-service,/api/payments→ payment-service
- 예:
- Ingress Controller: NGINX, HAProxy, Traefik, Istio Gateway 등
- API Gateway: Ingress + 인증/인가, Rate Limiting, API Key 관리, 메트릭 수집 등 고급 기능
네트워크 보안: Zero Trust
전통적인 네트워크 보안은 "내부 네트워크는 안전하다"는 가정을 전제로 했다. 방화벽으로 외부를 차단하면 내부에서의 통신은 신뢰했다. 하지만 클라우드 네이티브 환경에서 이 가정은 위험하다. 내부 서비스가 침해되거나 잘못 설정될 경우 내부 네트워크에서 자유롭게 이동할 수 있기 때문이다.
Zero Trust 원칙: "Trust Nothing by Default"
- mTLS: 서비스 간 모든 통신을 암호화하고 양방향 인증
- NetworkPolicy: Pod 수준의 L3/L4 방화벽 규칙으로 필요한 통신만 허용
- API 인증/인가: 내부 서비스 간 통신에도 JWT, OAuth2, OIDC 등으로 신원 검증
- WAF / Rate Limiting: 외부에서 들어오는 악의적 요청 차단
- 설계 원칙: "IP 기반 신뢰" 대신 "ID/Certificate/JWT 기반 신원 인증"
Zero Trust를 완전히 구현하면, 어느 서비스가 어느 서비스를 어떤 방법으로 호출할 수 있는지가 모두 코드(YAML/Manifest)로 명시된다. 네트워크 보안이 인프라 팀의 암묵적 지식이 아니라 감사 가능한(Auditable) 코드가 된다.
요약: 서비스 메시는 마이크로서비스 환경에서 서비스 간 통신의 복잡성을 코드 밖으로 꺼내어 인프라 레이어에서 통합 관리하는 패턴이다. Retry, mTLS, 트레이싱, Canary 배포 같은 공통 관심사가 모든 서비스에 일관되게 적용된다. 이를 제대로 활용하려면 클라우드 네이티브 네트워킹의 기본(CNI, Service, Ingress, Zero Trust)을 함께 이해해야 한다.
