오늘의 기술 토픽

Service Mesh

이번 자료는 실제 밋업 발표가 아니라 Service Mesh라는 주제를 중심으로 정리한 기술 브리프입니다. 마이크로서비스 환경에서 서비스 간 통신을 어떻게 안전하고 관측 가능하게 관리할지에 초점을 맞추고, Istio, Envoy, Cilium 등 관련 기술이 어떤 역할을 하는지 정리했습니다. 최근에는 사이드카 방식의 무거움을 줄이려는 sidecar-less, eBPF 기반 접근으로 생태계가 이동하고 있습니다. 실습 진입 장벽을 낮추기 위한 학습 경로와 공식 문서 링크도 함께 제공합니다.

🔑 핵심 요점

  • Service Mesh는 마이크로서비스 간 통신을 애플리케이션 코드 밖에서 제어하는 인프라 계층이다.
  • 트래픽 라우팅, mTLS 암호화, 재시도/서킷브레이커, 관측성(observability)을 코드 수정 없이 제공하는 것이 핵심 가치다.
  • Istio는 Envoy를 데이터 플레인으로 사용하는 대표적인 Service Mesh 구현체다.
  • 전통적인 사이드카 프록시 방식은 리소스 오버헤드와 운영 복잡도라는 단점이 있다.
  • Cilium 같은 eBPF 기반 기술은 사이드카 없이 커널 레벨에서 네트워킹과 보안을 처리하는 방향으로 발전하고 있다.
  • Service Mesh 도입은 클러스터 규모와 팀의 운영 역량을 고려해 단계적으로 접근하는 것이 바람직하다.

🛠 핵심 기술 쉽게 이해하기

Service Mesh

여러 개의 작은 서비스(마이크로서비스)들이 서로 통신할 때 필요한 기능들, 예를 들어 트래픽 라우팅, 암호화, 재시도, 모니터링 등을 애플리케이션 코드와 분리해서 처리해주는 인프라 계층입니다. 보통 각 서비스 옆에 프록시(사이드카)를 붙여서 모든 네트워크 트래픽이 이 프록시를 거치도록 만듭니다.

왜 필요한가 — 서비스 개수가 많아질수록 통신 관련 로직(인증, 재시도, 로드밸런싱 등)을 각 서비스마다 중복 구현하기 어렵고, 장애 시 원인 파악도 힘들어지기 때문에 이를 표준화된 인프라 레이어로 분리하기 위해 사용합니다.

발표에서는 — 이번 브리프의 핵심 주제로, 나머지 기술들은 모두 Service Mesh를 구현하거나 대체하는 방식으로 소개됩니다.

Istio

가장 널리 쓰이는 오픈소스 Service Mesh 프로젝트로, Envoy 프록시를 각 서비스 옆에 배치하는 사이드카 방식을 사용합니다. 트래픽 관리, 보안(mTLS), 관측성 기능을 Kubernetes 위에서 선언적으로 설정할 수 있게 해줍니다.

왜 필요한가 — Kubernetes 환경에서 서비스 간 통신을 세밀하게 제어하고 싶을 때 업계 표준처럼 자리잡은 선택지입니다.

발표에서는 — Service Mesh의 대표 구현체로서, 사이드카 기반 아키텍처의 장단점을 설명하는 기준점으로 언급됩니다.

Envoy

Istio를 비롯한 여러 Service Mesh가 데이터 플레인(실제 트래픽 처리)으로 사용하는 고성능 L7 프록시입니다. 단독으로도 API 게이트웨이나 로드밸런서로 쓰일 수 있습니다.

왜 필요한가 — 동적 설정 변경, 상세한 트래픽 메트릭, 다양한 프로토콜 지원이 필요한 현대적인 프록시 요구사항을 충족하기 위해 사용됩니다.

발표에서는 — Istio 등 사이드카 기반 Mesh의 실질적인 트래픽 처리 엔진으로 소개됩니다.

Cilium

Linux 커널의 eBPF 기술을 활용해 Kubernetes 네트워킹, 보안 정책, 관측성을 제공하는 프로젝트입니다. 최근에는 사이드카 프록시 없이 Service Mesh 기능(예: mTLS, L7 정책)을 구현하는 방향으로 확장되고 있습니다.

왜 필요한가 — 사이드카 방식의 리소스 오버헤드와 복잡한 운영 부담을 줄이면서도 비슷한 수준의 트래픽 제어와 보안을 얻기 위해 사용합니다.

발표에서는 — 사이드카 없는(sidecar-less) 차세대 Service Mesh 접근 방식의 대표 사례로 다뤄집니다.

🧭 추구 방향과 흐름

  • Sidecar-less로의 이동 — 기존 사이드카 프록시 방식은 파드마다 프록시를 하나씩 띄우기 때문에 리소스 사용량과 운영 복잡도가 커지는 문제가 있습니다. Cilium 같은 eBPF 기반 기술은 커널 레벨에서 트래픽을 처리해 사이드카 없이도 Mesh 기능을 제공하는 방향으로 발전하고 있습니다.
  • 관측성과 보안의 통합 — Service Mesh는 트래픽 라우팅뿐 아니라 mTLS 기반 zero trust 보안과 메트릭/트레이싱 기반 관측성을 함께 제공하는 방향으로 확장되고 있습니다. 이는 플랫폼 팀이 개별 애플리케이션 팀에게 보안과 모니터링을 ‘기본 제공’하려는 흐름과 맞닿아 있습니다.
  • 점진적 도입과 운영 부담 관리 — Service Mesh는 강력하지만 학습 곡선과 운영 오버헤드가 있는 기술이므로, 전체 클러스터에 한 번에 적용하기보다 필요한 네임스페이스나 서비스부터 단계적으로 도입하는 접근이 권장됩니다.

🚀 바로 활용하기

  1. 로컬 환경(kind, minikube 등)에 Kubernetes 클러스터를 하나 띄우고 Istio 공식 Getting Started 가이드를 따라 sample 애플리케이션에 사이드카를 주입해본다.
  2. Istio 없이 순수 Cilium만으로 네트워크 정책과 mTLS를 설정해보며 eBPF 기반 접근 방식의 차이를 체감해본다.
  3. Envoy 공식 문서에서 프록시의 기본 개념(Listener, Cluster, Route)을 먼저 익힌 뒤 Istio 설정을 다시 살펴보면 이해가 쉬워진다.
  4. CNCF 랜드스케이프에서 Service Mesh 카테고리를 훑어보며 Istio 외에 어떤 대안들이 있는지 비교해본다.

🔗 참고 자료

  • Istio 공식 문서 — 가장 널리 쓰이는 Service Mesh 구현체의 개념과 설치 가이드를 확인할 수 있다.
  • Envoy Proxy 공식 사이트 — Istio 등 여러 Mesh가 사용하는 데이터 플레인 프록시의 기본 개념을 학습할 수 있다.
  • Cilium 공식 사이트 — eBPF 기반 sidecar-less 네트워킹/보안 접근 방식을 다룬다.
  • Kubernetes 공식 문서 — Service Mesh가 동작하는 기반 플랫폼인 Kubernetes의 개념을 이해하는 데 필요하다.
  • CNCF 공식 사이트 — Service Mesh를 포함한 클라우드 네이티브 생태계 전반의 프로젝트 지형을 살펴볼 수 있다.