서비스 메시의 패러다임 전환인 사이드카 없는 아키텍처를 분석합니다. Istio Ambient Mesh와 Cilium eBPF의 비교, 마이그레이션 전략, 그리고 미래 전망까지.
서비스 메시의 가장 큰 변화가 진행 중입니다. 2022~2024년 "서비스 메시 피로감"이라 불리던 시기를 거쳐, 사이드카 없는 아키텍처가 서비스 메시의 새로운 기본값으로 자리 잡고 있습니다. 이 장에서는 사이드카 모델의 한계를 정리하고, Istio Ambient Mesh와 Cilium eBPF라는 두 가지 해법을 비교 분석하겠습니다.
사이드카 모델의 가장 큰 문제는 리소스 소비입니다.
1000개 Pod 클러스터에서의 사이드카 비용:
Envoy 사이드카 x 1000 =
메모리: 50MB x 1000 = 50GB
CPU: 0.1코어 x 1000 = 100코어
비용 환산 (AWS m5.xlarge 기준):
메모리 50GB → ~4대 추가 노드
CPU 100코어 → ~25대 추가 노드
월 비용: 약 $3,000~5,000 추가
GPU 워크로드가 많은 AI/ML 클러스터에서는 이 오버헤드가 더욱 심각합니다. GPU 노드는 일반 노드보다 비싸므로, 사이드카의 CPU/메모리 오버헤드가 비용에 미치는 영향이 큽니다.
사이드카 주입 문제: 사이드카 자동 주입은 Pod 생성 시 Admission Webhook으로 처리됩니다. 이 Webhook이 실패하면 Pod 생성이 차단되거나, 사이드카 없이 배포되어 mTLS가 깨집니다.
버전 관리: 1000개 Pod의 Envoy 사이드카 버전을 일괄 업데이트하려면 모든 Pod를 재시작해야 합니다. 롤링 업데이트 중 구버전과 신버전이 혼재하는 상황도 관리해야 합니다.
시작 순서 문제: 사이드카가 준비되기 전에 애플리케이션이 네트워크 요청을 시도하면 실패합니다. holdApplicationUntilProxyStarts 같은 설정으로 우회하지만, Pod 시작 시간이 늘어납니다.
네트워크 문제가 발생했을 때 원인이 애플리케이션인지, 사이드카 프록시인지, 프록시 설정인지 구분하기 어렵습니다. 프록시 로그, 애플리케이션 로그, Kubernetes 이벤트를 모두 확인해야 합니다.
Ambient Mesh의 핵심은 기능의 계층 분리입니다.
┌────────────────────────────────────────────────┐
│ L7 계층 (선택적) │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ Waypoint Proxy (Envoy) │ │
│ │ - HTTP 라우팅, 재시도, 타임아웃 │ │
│ │ - L7 인가 정책 │ │
│ │ - HTTP 메트릭, 트레이싱 │ │
│ │ - 네임스페이스/서비스 단위 배포 │ │
│ └──────────────────────────────────────────┘ │
│ │
├─────────────────────── + ──────────────────────┤
│ L4 계층 (항상 활성) │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ ztunnel (Rust, DaemonSet) │ │
│ │ - mTLS 암호화/복호화 │ │
│ │ - TCP 레벨 라우팅 │ │
│ │ - L4 인가 정책 │ │
│ │ - TCP 메트릭 │ │
│ │ - HBONE 터널링 │ │
│ └──────────────────────────────────────────┘ │
└────────────────────────────────────────────────┘
Ambient Mesh는 ztunnel 간 통신에 HBONE(HTTP-Based Overlay Network Encapsulation) 프로토콜을 사용합니다. HTTP/2 CONNECT 메서드를 통해 TCP 트래픽을 터널링합니다.
HBONE 통신 흐름:
[Pod A] → (평문) → [ztunnel-node1]
│
HTTP/2 CONNECT + mTLS
│
[ztunnel-node2] → (평문) → [Pod B]
HBONE의 장점은 HTTP/2 기반이므로 기존 로드 밸런서와 방화벽을 통과하기 쉽다는 것입니다.
네임스페이스 단위로 Ambient 모드를 활성화합니다.
# L4만 필요한 네임스페이스 (mTLS + TCP 정책)
kubectl label namespace payments istio.io/dataplane-mode=ambient
# L7도 필요한 네임스페이스 (Waypoint 추가)
kubectl label namespace payments istio.io/dataplane-mode=ambient
istioctl waypoint apply -n payments --enroll-namespace점진적 마이그레이션이 가능합니다. 같은 메시 내에서 사이드카 모드와 Ambient 모드를 혼용할 수 있습니다.
혼합 모드:
[네임스페이스 A] → 사이드카 모드 (기존)
[네임스페이스 B] → Ambient 모드 (신규)
두 모드의 서비스 간 mTLS 통신이 자동으로 작동합니다.
2026년 3월 KubeCon Europe에서 발표된 Ambient Multicluster Beta는 사이드카 없는 멀티클러스터 메시를 구현합니다. 클러스터 간 ztunnel이 HBONE 터널로 연결되어, 멀티클러스터 서비스 디스커버리와 mTLS를 제공합니다.
Cilium의 eBPF 프로그램은 리눅스 커널의 여러 지점에 연결됩니다.
패킷 처리 경로:
수신(Ingress):
NIC → [XDP eBPF] → [TC ingress eBPF] → Pod
빠른 필터링 정책 적용, 라우팅
송신(Egress):
Pod → [TC egress eBPF] → [TC ingress eBPF] → 대상 Pod
서비스 LB, NAT 정책 적용
XDP(eXpress Data Path): 네트워크 인터페이스 드라이버에서 직접 패킷을 처리합니다. DDoS 방어 같은 빠른 필터링에 사용됩니다.
TC(Traffic Control): 커널 네트워크 스택의 TC 계층에서 패킷을 처리합니다. 서비스 로드 밸런싱, 네트워크 정책, NAT 등 대부분의 기능이 여기서 실행됩니다.
L7 기능이 필요한 경우, Cilium은 트래픽을 노드당 공유 Envoy 프록시로 리디렉트합니다.
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: l7-policy
spec:
endpointSelector:
matchLabels:
app: reviews
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "8080"
rules:
http:
- method: "GET"
path: "/api/.*"이 정책이 적용되면 Cilium Agent가 자동으로 해당 트래픽을 Envoy 프록시로 리디렉트합니다.
학술 벤치마크(2025년 10월)에 따르면, 대규모 클러스터에서 두 접근 방식의 성능 차이가 나타납니다.
| 벤치마크 항목 | Istio Ambient | Cilium | 비고 |
|---|---|---|---|
| L4 mTLS 오버헤드 | 8% | ~5% (WireGuard) | Cilium은 커널 암호화 |
| L7 처리 (HTTP) | Waypoint 경유 | 공유 Envoy 경유 | 유사한 성능 |
| QPS/코어 (50K pods) | 기준값 대비 +56% | 기준값 대비 +40% | Ambient가 대규모에서 유리 |
| Pod 시작 시간 영향 | 없음 | 없음 | 둘 다 사이드카 없음 |
| 커널 요구사항 | 없음 | 5.4+ (권장 5.10+) | Cilium은 커널 의존 |
| 기능 | Istio Ambient | Cilium |
|---|---|---|
| mTLS 방식 | ztunnel (L4) | WireGuard 또는 ztunnel (beta) |
| HTTP 라우팅 | Waypoint Proxy (풀 Envoy) | 공유 Envoy (제한적) |
| 카나리 배포 | VirtualService/Gateway API | 제한적 |
| 폴트 인젝션 | 지원 | 미지원 |
| 트래픽 미러링 | 지원 | 미지원 |
| 네트워크 정책 | AuthorizationPolicy | CiliumNetworkPolicy + K8s 표준 |
| CNI 역할 | 별도 CNI 필요 | 자체 CNI 포함 |
| 관측 도구 | Kiali, Prometheus | Hubble, Prometheus |
의사결정 트리:
Q1. L7 트래픽 관리가 핵심 요구사항인가?
├── Yes → Istio Ambient
│ (카나리, 미러링, 폴트 인젝션 등)
│
└── No → Q2. 이미 Cilium을 CNI로 사용 중인가?
├── Yes → Cilium Service Mesh
│ (추가 컴포넌트 없이 기능 추가)
│
└── No → Q3. 가장 중요한 것은?
├── 최고의 L3/L4 성능 → Cilium
├── 풍부한 L7 기능 → Istio Ambient
└── 단순한 운영 → Cilium (CNI 통합)
기존 Istio 사이드카 모드에서 Ambient 모드로 마이그레이션하는 전략입니다.
단계별 마이그레이션:
1. Ambient 컴포넌트 설치
- ztunnel DaemonSet 배포
- Istio CNI 에이전트 배포
- 기존 사이드카 서비스에 영향 없음
2. 테스트 네임스페이스 전환
- 비프로덕션 네임스페이스를 Ambient로 전환
- 사이드카 레이블 제거, Ambient 레이블 추가
- Pod 재시작
- 기능 검증
3. 프로덕션 네임스페이스 순차 전환
- 중요도 낮은 서비스부터 전환
- 각 전환 후 모니터링 기간 (1~2주)
- L7 기능이 필요한 서비스에 Waypoint 배포
4. 사이드카 인젝션 비활성화
- 모든 네임스페이스 전환 완료 후
- sidecar-injector 제거
- 사이드카 관련 리소스 정리
2026년 서비스 메시의 중요한 발전 방향은 AI 워크로드 지원입니다.
Istio 커뮤니티에서 개발 중인 Gateway API Inference Extension은 AI 추론 서비스에 특화된 라우팅을 제공합니다.
apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferencePool
metadata:
name: llm-pool
spec:
targetPortNumber: 8080
selector:
matchLabels:
app: llm-server
---
apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceModel
metadata:
name: chat-model
spec:
modelName: claude-3
poolRef:
name: llm-pool
criticality: Critical이 확장은 모델별 트래픽 라우팅, GPU 인지 로드 밸런싱, 추론 큐 관리 등 AI 서비스에 특화된 기능을 제공합니다.
다음 장에서는 서비스 메시 도입부터 운영까지의 실전 프로젝트를 진행하겠습니다.
이 글이 도움이 되셨나요?
서비스 메시가 제공하는 관측 가능성의 세 기둥을 분석합니다. 분산 추적, 골든 시그널 메트릭, 액세스 로그, 그리고 Kiali/Grafana 연동까지.
실전 마이크로서비스 환경에서 서비스 메시를 도입하는 전체 과정을 다룹니다. 기술 선택, 설치, 보안 설정, 트래픽 관리, 관측 가능성, 운영 자동화까지.
서비스 메시의 보안 기반인 mTLS의 작동 원리, SPIFFE 워크로드 아이덴티티, 인증서 관리, 그리고 제로 트러스트 아키텍처 구현 전략을 다룹니다.