요즘 사내에서 sidecar 없는 서비스 메시 이야기가 자주 나온다. 우리 팀도 작년 4분기에 Istio sidecar 모드를 운영하다가 메모리 footprint와 업그레이드 부담에 지쳐서 sidecarless 옵션을 진지하게 검토하기 시작했다. 후보는 두 개로 좁혀졌다. Istio Ambient Mode와 Cilium Service Mesh.
둘 다 sidecar를 없앤다는 큰 그림은 같은데 접근 방식이 꽤 다르다. 어느 쪽이 우리 팀에 맞는지 판단하기까지 두 달 정도 PoC를 돌렸고, 그 과정에서 알게 된 것들을 정리한다. 결론부터 말하면 우리는 아직 한쪽을 완전히 못 정했다. 그래서 이 글은 깔끔한 권고문이 아니다.
데이터 플레인이 어디서 도는가
가장 큰 차이는 트래픽이 처리되는 위치다.
Istio Ambient는 노드마다 ztunnel이라는 Rust로 짠 프록시를 DaemonSet으로 띄운다. L3/L4 처리, mTLS, 기본 인증/권한, 텔레메트리는 여기서 한다. L7이 필요하면 그때 waypoint proxy를 별도로 띄운다. waypoint는 Envoy 기반이고 namespace 단위 또는 service account 단위로 배치할 수 있다. 즉 데이터 플레인이 두 층(L4 ztunnel + 선택적 L7 waypoint)으로 쪼개져 있다.
Cilium Service Mesh는 좀 다르다. eBPF로 커널 레벨에서 L3/L4를 처리하고, WireGuard나 IPSec으로 암호화한다. L7이 필요하면 노드마다 떠 있는 Envoy를 활용한다. 즉 데이터 플레인이 커널(eBPF) + 노드 Envoy로 구성된다. CNI 자체가 메시 역할도 겸한다는 게 핵심이다.
이게 운영 관점에서 어떤 차이를 만드냐면, Cilium 쪽은 "CNI + 메시"가 한 묶음이라 덜 추상화된 느낌이고, Istio Ambient는 "CNI는 별도, 메시는 별도"로 책임이 분리된다. 우리 클러스터처럼 이미 AWS VPC CNI를 쓰고 있고 IRSA, ENI 트렁킹 등 AWS 통합에 의존도가 높으면 Cilium으로 갈아타는 비용이 만만치 않다. 반대로 처음부터 Cilium CNI로 시작한 클러스터라면 메시까지 한 번에 가져갈 수 있어서 매력적이다.
PoC에서 측정한 것들
12노드 EKS 클러스터(m6i.2xlarge)에 동일한 워크로드를 올리고 며칠씩 돌려봤다. 워크로드는 약 80개의 마이크로서비스, 평균 RPS 4500, 피크 1만 정도다.
기본 mTLS만 켠 상태에서 P50 latency는 두 옵션 모두 비슷했다. 0.5ms 정도 추가됐다. 차이가 벌어진 건 P99이었다. ztunnel 쪽이 P99에서 1.2~1.8ms 정도 추가됐고 Cilium은 0.7~1.0ms였다. 단, 여기서 L7 정책과 관측성을 모두 켜면 그림이 바뀐다. waypoint를 띄우고 Cilium에서 L7 policy를 활성화하면 둘 다 P99이 비슷하게 올라왔다. 이건 Istio가 공식 블로그에서 주장한 것과 비슷한 패턴이다. "기본 사양에서는 Cilium이 빠른데 L7 켜면 비슷해진다"는 그 주장.
CPU/메모리 footprint도 비슷했다. 노드당 ztunnel은 50~80MB 정도, Cilium agent는 200~400MB 수준이지만 Cilium은 CNI까지 다 하니까 단순 비교는 어렵다. sidecar 시절 워크로드당 100MB씩 곱하던 시절을 생각하면 둘 다 절약폭은 컸다.
운영 관점에서 부딪힌 것들
성능보다 운영 관점에서 더 갈렸다.
업그레이드. Istio Ambient는 ztunnel이 노드 단위라 노드 drain 없이도 in-place 업그레이드가 어느 정도 가능하다. 하지만 ztunnel과 waypoint 버전 호환성이 까다로워서 실제로는 단계별로 신중하게 가야 한다. Cilium은 CNI 자체를 업그레이드하는 거라 노드별 cilium-agent 재시작이 필요하고, 이때 짧지만 데이터 플레인 단절 구간이 생긴다. 둘 다 그렇게 가볍지는 않았다.
디버깅. 이게 의외로 큰 차이를 만들었다. sidecar 시절에는 kubectl exec -it <pod> -c istio-proxy로 envoy admin에 들어가면 됐다. Ambient 모드에서는 ztunnel이 노드에 떠 있어서 한 단계 더 들어가야 하고, waypoint는 또 별도 pod이라 트래픽이 어느 경로를 탔는지 파악하기가 까다롭다. 우리 팀에서는 처음 한 달 동안 "이 트래픽이 ztunnel만 거쳤는지, waypoint도 거쳤는지" 확인하느라 시간을 꽤 썼다. Cilium은 hubble로 통합 관측을 제공해서 그 면에서는 한결 깔끔했다. eBPF 출력을 읽는 방법만 익히면.
기존 자산 호환. 우리 팀은 sidecar 시절부터 작성한 VirtualService와 DestinationRule이 200개가 넘는다. Ambient는 이 자산을 거의 그대로 쓸 수 있다(L7은 waypoint로 옮기는 작업만 필요). Cilium 쪽은 CiliumNetworkPolicy/CiliumEnvoyConfig 형태로 다시 써야 해서 마이그레이션 비용이 컸다. Gateway API로 통일하면 좀 낫지만 아직 모든 기능이 매핑되지는 않았다.
멀티 클러스터. 우리는 리전 간 이중화 클러스터를 운영하는데, Istio는 멀티 클러스터 메시 구성이 훨씬 성숙해 있다. Cilium도 cluster-mesh가 있긴 하지만 정책 일관성이나 운영 도구 면에서 Istio가 한참 앞선다고 느꼈다.
우리가 결국 어떻게 하기로 했나
당장은 기존 sidecar 메시를 쓰는 클러스터부터 Istio Ambient로 옮기기로 했다. 마이그레이션 비용이 가장 적고, 우리 팀이 이미 Istio CRD를 잘 알고 있어서다. ztunnel만 우선 깔고 sidecar를 점진적으로 제거한 다음, L7이 필요한 namespace에만 waypoint를 추가하는 단계적 전환을 잡았다.
신규 클러스터에서는 Cilium CNI + Cilium Service Mesh를 PoC 중이다. 여기서는 처음부터 통합된 스택의 이점이 크다. 다만 우리 팀의 학습 곡선이 아직 가파르다. eBPF 출력을 능숙하게 읽는 사람이 두 명뿐인 게 솔직히 부담이다.
한 줄로 요약하자면, 기존 Istio 자산이 많고 운영팀이 Envoy를 잘 알면 Ambient, 처음부터 Cilium CNI를 쓰는 새 클러스터라면 Cilium Service Mesh가 자연스럽다. 둘 다 sidecar보다는 분명히 가볍지만, 운영 복잡도가 사라지는 게 아니라 다른 모양으로 변하는 거였다.
다음에는 Ambient 마이그레이션 중에 만난 ztunnel-CNI 충돌 이슈를 정리해 보려고 한다. 혹시 두 메시 모두 운영해 보신 분 있으면 어떤 점이 결정적이었는지 댓글로 공유해 주시면 좋겠다.
---
추가 리소스:
'IT > 기타' 카테고리의 다른 글
| Istio Ambient vs Sidecar, 6개월 검토 후 결론 (0) | 2026.04.27 |
|---|---|
| NodeLocal DNSCache 없이 버티다 conntrack에 발목 잡힌 새벽 (0) | 2026.04.26 |