오늘의 기술 토픽

Service Mesh

이번 브리핑은 특정 밋업 발표가 아니라 Service Mesh라는 주제를 중심으로 정리한 기술 브리프이다. 마이크로서비스 환경에서 서비스 간 통신을 관리하기 위해 등장한 Service Mesh 개념과 대표 구현체인 Istio, 그리고 최근 주목받는 eBPF 기반 접근(Cilium)까지 함께 다룬다. 사이드카 방식의 한계와 이를 극복하려는 ambient mesh 같은 최신 흐름도 짚는다.

🔑 핵심 요점

  • Service Mesh는 마이크로서비스 간 통신을 애플리케이션 코드 밖에서 처리해주는 인프라 레이어이다.
  • 트래픽 라우팅, 재시도, mTLS 암호화, 관찰성(observability) 같은 기능을 일관되게 적용할 수 있다.
  • Istio는 가장 널리 쓰이는 Service Mesh 구현체로 Envoy 프록시를 사이드카로 배치하는 방식이 전통적이다.
  • 사이드카 방식은 리소스 오버헤드와 운영 복잡도가 크다는 지적이 꾸준히 있어왔다.
  • Cilium 같은 eBPF 기반 도구는 커널 레벨에서 네트워킹을 처리해 사이드카 없이도 mesh 기능을 제공하려는 시도이다.
  • Istio도 ambient mesh라는 사이드카리스(sidecarless) 아키텍처를 도입하며 경량화 방향으로 진화 중이다.

🛠 핵심 기술 쉽게 이해하기

Istio

Istio는 쿠버네티스 위에서 동작하는 대표적인 Service Mesh 플랫폼으로, 각 서비스 옆에 Envoy 프록시를 배치해 서비스 간 통신을 제어한다. 트래픽 관리, 보안, 모니터링 기능을 애플리케이션 코드 수정 없이 적용할 수 있게 해준다.

왜 필요한가 — 마이크로서비스가 늘어날수록 서비스 간 통신 정책(재시도, 타임아웃, mTLS 등)을 개별 서비스마다 구현하기 어려워지는 문제를 해결하기 위해 사용한다.

발표에서는 — 가장 널리 알려진 Service Mesh 구현체로 소개되며, 전통적인 사이드카 방식과 최근의 ambient mesh 방식을 비교하는 축으로 다뤄졌다.

Envoy

Envoy는 고성능 L7 프록시로, Istio를 비롯한 여러 Service Mesh와 API 게이트웨이의 데이터 플레인으로 널리 쓰인다.

왜 필요한가 — 서비스 간 통신에서 로드 밸런싱, 재시도, 회로 차단(circuit breaking) 등을 프록시 레벨에서 처리하기 위해 필요하다.

발표에서는 — Istio의 사이드카 프록시로서 동작 원리를 설명하는 맥락에서 언급되었다.

Cilium

Cilium은 eBPF 기술을 기반으로 쿠버네티스 네트워킹과 보안을 커널 레벨에서 처리하는 CNI(Container Network Interface) 플러그인이다. 최근에는 Service Mesh 기능까지 확장하고 있다.

왜 필요한가 — 사이드카 프록시 없이도 네트워크 정책, 로드 밸런싱, 관찰성을 제공해 오버헤드를 줄이려는 목적으로 쓰인다.

발표에서는 — 사이드카 방식의 대안으로서 eBPF 기반 접근을 대표하는 사례로 소개되었다.

Linkerd

Linkerd는 Istio보다 가볍고 단순한 것을 지향하는 Service Mesh 구현체로, Rust로 작성된 경량 프록시를 사용한다.

왜 필요한가 — Istio의 복잡한 설정과 운영 부담 없이 기본적인 mTLS와 트래픽 관찰 기능만 빠르게 도입하고 싶은 경우에 쓰인다.

발표에서는 — Service Mesh 생태계의 대안 구현체로서 비교 대상으로 짧게 언급되었다.

🧭 추구 방향과 흐름

  • 사이드카에서 사이드카리스(sidecarless)로 — 전통적인 Service Mesh는 파드마다 사이드카 프록시를 붙이는 방식이었지만, 리소스 사용량과 운영 복잡도 문제로 사이드카 없는 아키텍처가 주목받고 있다. Istio의 ambient mesh와 Cilium의 eBPF 기반 접근이 이 흐름을 대표한다.
  • 커널 레벨(eBPF) 네트워킹으로의 이동 — 애플리케이션 레이어 프록시 대신 리눅스 커널의 eBPF를 활용해 네트워킹과 보안을 처리하는 방식이 늘고 있다. Cilium이 이 방향의 대표 사례로, 성능과 자원 효율을 동시에 잡으려는 시도로 볼 수 있다.
  • 제로 트러스트 보안의 기본 구성 요소화 — Service Mesh의 mTLS 기반 서비스 간 암호화 통신이 제로 트러스트 아키텍처의 핵심 구성 요소로 자리잡고 있다. 코드 변경 없이 전 서비스에 암호화를 강제할 수 있다는 점이 강조된다.

🚀 바로 활용하기

  1. 로컬 쿠버네티스 클러스터(minikube, kind 등)에 Istio를 설치하고 공식 Getting Started 가이드의 예제 애플리케이션(Bookinfo)을 따라 실습해본다.
  2. Istio와 Cilium의 아키텍처 문서를 비교해 사이드카 방식과 eBPF 방식의 차이를 정리해본다.
  3. 간단한 마이크로서비스 2-3개를 배포하고 Service Mesh 없이/있이 트래픽 재시도와 mTLS 동작을 비교해본다.
  4. Envoy 프록시의 기본 설정 문서를 읽고 Istio 내부에서 프록시가 어떻게 구성되는지 살펴본다.

🔗 참고 자료

  • Istio 공식 문서 — Istio의 아키텍처와 ambient mesh, Getting Started 가이드를 확인할 수 있다.
  • Cilium 공식 사이트 — eBPF 기반 네트워킹/Service Mesh 접근 방식에 대한 공식 설명을 담고 있다.
  • Envoy Proxy 공식 사이트 — Istio 데이터 플레인으로 쓰이는 Envoy의 상세 문서를 제공한다.
  • Linkerd 공식 사이트 — 경량 Service Mesh 대안 구현체에 대한 공식 정보를 제공한다.
  • CNCF 공식 사이트 — Service Mesh 관련 프로젝트들의 상위 재단으로 생태계 전반의 맥락을 파악할 수 있다.