[Cilium Study] 6주차 - Sidecar를 넘어, eBPF로 구현하는 서비스 메시

지난 5주차 스터디에서는 BGP와 ClusterMesh를 통해 클러스터의 경계를 넘어 외부 네트워크, 그리고 다른 클러스터와 통신하는 방법을 다루었습니다. 클러스터의 '남-북(North-South)' 트래픽과 클러스터 간 통신을 마스터한 셈이죠. 이제 우리의 시선은 다시 클러스터 내부로, 마이크로서비스 간의 복잡하고 동적인 '동-서(East-West)' 트래픽으로 향합니다. 바로 서비스 메시(Service Mesh) 의 영역입니다.

이번 포스팅에서는 서비스 메시의 기본 개념부터 시작하여, 기존의 Sidecar 모델이 가졌던 한계와 이를 eBPF로 극복하는 Cilium의 혁신적인 접근법을 심층적으로 분석합니다. 또한, Ingress의 차세대 표준인 Gateway API와 강력한 워크로드 신원 증명 프레임워크인 SPIFFE까지, Cilium이 제공하는 차세대 서비스 메시의 구성 요소들을 자세히 살펴보겠습니다.

이미지 출처: https://cilium.io/blog/2019/08/20/cilium-16/

1. 서비스 메시(Service Mesh)란 무엇인가?

마이크로서비스 아키텍처(MSA)는 애플리케이션을 작고 독립적인 서비스 단위로 분리하여 개발과 배포의 민첩성을 높였습니다. 하지만 이는 곧 서비스 간의 네트워크 통신이 폭발적으로 증가함을 의미했고, 다음과 같은 새로운 운영상의 과제들을 낳았습니다.

• 관측 가능성(Observability): 수많은 서비스 중 어디에서 병목이나 에러가 발생하는지 추적하기 어렵습니다. 특정 사용자 요청이 여러 서비스를 거칠 때, 어느 구간에서 지연이 발생하는지, 어떤 서비스의 실패가 연쇄적인 장애를 유발하는지 파악하기가 매우 힘들어집니다.
• 트래픽 관리(Traffic Management): A/B 테스팅, 카나리 배포, 서킷 브레이킹과 같은 정교한 트래픽 제어를 어떻게 구현할 것인가? 예를 들어, 신규 버전의 서비스에 전체 트래픽의 1%만 보내거나, 특정 HTTP 헤더를 가진 요청만 신규 버전으로 라우팅하는 등의 고급 전략을 애플리케이션 코드 수정 없이 적용하기 어렵습니다.
• 보안(Security): 모든 서비스 간 통신을 어떻게 안전하게 암호화하고, 허가된 서비스끼리만 통신하도록 제어할 것인가? 제로 트러스트(Zero Trust) 보안 모델을 구현하기 위해 서비스 간 상호 TLS(mTLS) 인증을 적용하고 관리하는 것은 매우 복잡한 작업입니다.

이러한 공통의 관심사들을 각 애플리케이션 개발팀이 개별적으로 구현하는 것은 비효율적입니다. 서비스 메시는 바로 이 문제들을 해결하기 위해 등장한 전용 인프라 계층입니다. 애플리케이션 코드 변경 없이, 서비스 간의 모든 네트워크 통신을 가로채어 신뢰성, 보안, 관측 가능성을 제공하는 것이 핵심입니다.

전통적인 접근: 사이드카(Sidecar) 패턴

Istio, Linkerd와 같은 1세대 서비스 메시들은 이 기능을 사이드카 패턴으로 구현했습니다. 각 애플리케이션 파드에 Envoy와 같은 고성능 프록시 컨테이너를 '사이드카'로 함께 주입하는 방식입니다.

• 동작 방식: 파드가 시작될 때, 초기화 컨테이너(init container)가 파드 내부의 iptables 규칙을 수정하여 모든 네트워크 트래픽이 이 사이드카 프록시를 거치도록 강제합니다. 이 프록시가 트래픽 라우팅, mTLS 암호화, 메트릭 수집과 같은 서비스 메시의 모든 기능을 대신 처리하며, 중앙의 컨트롤 플레인으로부터 정책을 받아 동적으로 적용합니다.
• 한계점: 이 방식은 애플리케이션에 투명성을 제공했지만, 모든 파드마다 프록시를 띄워야 하므로 상당한 리소스 오버헤드를 유발했습니다. 또한, App -> Sidecar -> Node로 이어지는 과정에서 패킷이 커널의 TCP/IP 스택을 여러 번 거치게 되어 네트워크 지연 시간(Latency)이 증가하는 문제도 있었습니다.

2. Cilium의 새로운 접근: Sidecar-less 서비스 메시

Cilium은 eBPF를 활용하여 사이드카 모델의 근본적인 한계를 극복하는 Sidecar-less 서비스 메시라는 새로운 패러다임을 제시합니다.

• 동작 방식: 파드마다 프록시를 두는 대신, 노드(Node)당 하나의 Envoy 프록시만 데몬셋으로 배포합니다. 그리고 eBPF를 사용하여 파드의 소켓(Socket) 레벨에서 나가는 트래픽을 가로채, 커널의 복잡한 네트워크 스택을 건너뛰고 바로 이 노드-로컬 Envoy 프록시로 전달합니다. 애플리케이션이 connect()나 send() 같은 시스템 콜을 호출하는 순간, eBPF가 이를 감지하여 패킷의 경로를 효율적으로 변경하는 것입니다.
• 핵심 기술 (TPROXY): 이 투명한 리다이렉션은 커널의 TPROXY 기능을 통해 이루어집니다. 일반적인 NAT(REDIRECT)와 달리, TPROXY는 패킷의 원본 출발지/목적지 IP와 포트 정보를 그대로 유지한 채 트래픽을 프록시로 전달할 수 있게 해줍니다. 덕분에 Envoy 프록시는 자신이 실제 목적지인 것처럼 트래픽을 처리하면서도, 클라이언트의 원본 IP를 유실하지 않아 완전한 투명성을 보장합니다.
• 장점: 리소스 사용량이 획기적으로 줄어들고, 커널 스택을 우회하여 네트워크 지연 시간이 단축됩니다. 또한, 모든 파드를 재시작하지 않고도 서비스 메시 기능을 전체 클러스터에 적용하거나 업그레이드할 수 있어 운영 편의성이 크게 향상됩니다.

3. Ingress를 넘어 Gateway API로

서비스 메시는 클러스터 내부 통신뿐만 아니라, 외부 트래픽이 클러스터로 들어오는 관문, 즉 인그레스(Ingress) 와도 밀접한 관련이 있습니다. Cilium은 표준 쿠버네티스 Ingress를 완벽하게 지원하며, 한 걸음 더 나아가 그 차세대 표준인 Gateway API를 핵심 기능으로 채택했습니다.

Gateway API는 기존 Ingress가 가진 표현력의 한계와 역할 불분명성을 해결하기 위해 등장했습니다.

• 역할 지향(Role-Oriented) 아키텍처:

• GatewayClass: 클러스터 관리자가 "우리 회사에서는 Cilium을 Gateway 구현체로 사용한다"고 정의하는 템플릿입니다.
• Gateway: 인프라 운영자가 "80번, 443번 포트를 사용하는 my-gateway라는 LoadBalancer를 생성하겠다"고 선언하는 관문입니다.
• HTTPRoute: 애플리케이션 개발자가 "my-gateway로 들어오는 /foo 경로는 foo-service로 보내달라"고 라우팅 규칙을 정의합니다.
  이처럼 역할이 명확히 분리되어, 각 팀은 자신의 책임 영역에 맞는 리소스만 관리하면 되므로 협업이 용이해지고 실수를 줄일 수 있습니다.

• 표현력과 확장성: Ingress가 HTTP(S)에 국한되었던 것과 달리, Gateway API는 TCP, UDP, gRPC, TLS 라우팅을 표준 리소스로 지원합니다. 또한, 헤더 기반 라우팅, 트래픽 가중치 분산, 트래픽 미러링과 같은 고급 기능들을 어노테이션이 아닌 정식 API 필드로 정의하여 표준화된 방식으로 사용할 수 있습니다.

Cilium은 Gateway API를 네이티브로 구현하여, eBPF 기반의 고성능 데이터 플레인 위에서 이러한 정교한 L7 트래픽 관리 기능을 완벽하게 제공합니다.

4. 신뢰의 기반, 상호 인증(mTLS)과 SPIFFE

동적인 마이크로서비스 환경에서는 IP 주소가 더 이상 신뢰할 수 있는 식별자가 아닙니다. 따라서 서비스 간 통신을 보호하기 위해서는 IP 주소가 아닌, 암호학적으로 검증 가능한 워크로드 신원(Workload Identity) 이 필요합니다.

SPIFFE(Secure Production Identity Framework for Everyone) 는 이러한 강력한 신원을 모든 워크로드에 보편적으로 제공하기 위한 오픈소스 표준입니다.

• 핵심 개념:

• SPIFFE ID: spiffe://trust-domain/ns/default/sa/myapp과 같은 URI 형식의 고유한 워크로드 식별자입니다. 여기서 trust-domain은 신뢰의 루트(예: cluster.local)를, path는 네임스페이스와 서비스 어카운트 등을 조합하여 해당 워크로드를 고유하게 식별합니다.
• SVID (SPIFFE Verifiable Identity Document): 이 SPIFFE ID가 담겨있는 검증 가능한 문서로, 일반적으로 X.509 인증서 형태로 제공됩니다.

• 신원 발급 과정: 파드가 생성되면, 쿠버네티스는 해당 파드의 서비스 어카운트(Service Account) 정보를 담은 JWT 토큰을 주입합니다. 워크로드는 이 토큰을 증거로 SPIFFE 런타임 환경(예: SPIRE)에 자신의 신원을 증명하고, 해당 신원이 담긴 SVID(인증서)를 발급받습니다. 이 과정은 주기적으로 자동 갱신되어 신원의 유효성을 보장합니다.

Cilium은 이 SPIFFE 표준을 채택하여 클러스터 내 모든 서비스에 대한 상호 TLS(mTLS) 인증을 자동화합니다. 두 서비스가 통신을 시작할 때, 각자는 자신의 SVID를 상대방에게 제시하여 신원을 증명하고, 이 과정을 통과해야만 암호화된 통신 채널이 수립됩니다. 이 모든 과정이 애플리케이션에 투명하게, 인프라 레벨에서 자동으로 처리됩니다.

결론

이번 스터디를 통해 우리는 Cilium이 단순한 CNI를 넘어, eBPF라는 강력한 무기를 통해 어떻게 차세대 서비스 메시로 진화하고 있는지를 확인했습니다. 리소스 효율성과 성능을 극대화한 Sidecar-less 아키텍처, Ingress의 한계를 뛰어넘는 Gateway API 지원, 그리고 SPIFFE 기반의 강력한 mTLS 보안까지, Cilium은 현대적인 마이크로서비스 환경이 요구하는 복잡한 과제들을 하나의 통합된 솔루션으로 해결하고 있습니다.

Cilium과 함께라면, 더 이상 서비스 메시 도입을 위해 복잡한 사이드카 주입이나 별도의 솔루션을 고민할 필요 없이, 네트워킹 스택의 가장 낮은 레벨에서부터 가장 높은 애플리케이션 레벨까지 일관되고 효율적으로 관리할 수 있게 될 것입니다.