마이크로서비스 아키텍처에서 서비스 간 통신이 왜 어려운지, 그리고 서비스 메시가 어떤 문제를 해결하기 위해 등장했는지 살펴봅니다.
마이크로서비스 아키텍처가 대세가 된 지 이미 오래입니다. 하나의 거대한 모놀리스를 수십, 수백 개의 작은 서비스로 분해하면 각 팀이 독립적으로 개발하고 배포할 수 있다는 장점이 있습니다. 하지만 서비스가 늘어날수록 서비스 간 통신이라는 새로운 차원의 복잡성이 등장합니다.
이 장에서는 마이크로서비스 통신이 직면하는 근본적인 과제들을 정리하고, 이를 해결하기 위해 서비스 메시(Service Mesh)라는 인프라 계층이 왜 필요해졌는지 살펴보겠습니다.
분산 컴퓨팅의 8가지 오류(Fallacies of Distributed Computing) 중 첫 번째가 "네트워크는 신뢰할 수 있다"는 가정입니다. 모놀리스에서는 함수 호출이 실패할 가능성이 거의 없지만, 마이크로서비스 간 HTTP/gRPC 호출은 언제든 실패할 수 있습니다.
모놀리스: OrderService.createOrder() → 항상 성공 (프로세스 내 호출)
마이크로서비스: OrderService → HTTP → PaymentService → 네트워크 지연, 타임아웃, 패킷 손실 가능
이 문제를 해결하려면 모든 서비스에 재시도(retry), 타임아웃(timeout), 서킷 브레이커(circuit breaker) 로직을 구현해야 합니다.
서비스 인스턴스는 Kubernetes 환경에서 수시로 생성되고 사라집니다. 호출자는 대상 서비스의 현재 IP 주소를 어떻게 알 수 있을까요? DNS 기반 디스커버리, 로드 밸런서, 서비스 레지스트리 등 다양한 해법이 있지만, 각각 고유한 한계를 가지고 있습니다.
모놀리스 내부에서는 모든 코드가 같은 프로세스에서 실행되므로 신뢰 문제가 없습니다. 하지만 마이크로서비스 환경에서는 네트워크를 통해 통신하기 때문에 다음과 같은 보안 과제가 생깁니다.
10개의 서비스가 체인으로 연결된 요청에서 지연이 발생했을 때, 어느 구간이 병목인지 파악하려면 분산 추적(distributed tracing), 메트릭 수집, 로그 상관관계 분석이 필수입니다. 각 서비스에 이러한 계측(instrumentation) 코드를 일일이 삽입하는 것은 상당한 부담입니다.
초기에는 이 문제들을 애플리케이션 라이브러리로 해결하려 했습니다. Netflix OSS 스택이 대표적인 사례입니다.
Netflix OSS (2012~2016)
├── Eureka → 서비스 디스커버리
├── Ribbon → 클라이언트 사이드 로드 밸런싱
├── Hystrix → 서킷 브레이커
├── Zuul → API 게이트웨이
└── Zipkin → 분산 추적
이 접근 방식은 작동하지만, 근본적인 한계가 있습니다.
언어 종속성: Java 라이브러리이므로 Python, Go, Node.js 서비스에서는 사용할 수 없습니다. 폴리글랏(polyglot) 환경에서는 각 언어별로 동일한 기능을 재구현해야 합니다.
업데이트의 어려움: 라이브러리 버전을 올리려면 수백 개의 서비스를 모두 재빌드하고 재배포해야 합니다. 보안 패치 하나를 적용하는 데 몇 주가 걸릴 수 있습니다.
일관성 부재: 팀마다 라이브러리 설정이 다르면 재시도 횟수, 타임아웃 값, 서킷 브레이커 임계치가 제각각이 됩니다.
비즈니스 로직과의 결합: 네트워크 통신 처리 코드가 비즈니스 로직과 섞이면서 코드가 복잡해지고 유지보수가 어려워집니다.
서비스 메시는 이러한 한계를 극복하기 위해 네트워크 통신 기능을 애플리케이션 코드에서 분리하여 인프라 계층으로 내린 아키텍처 패턴입니다.
서비스 메시의 핵심 아이디어는 단순합니다. 각 서비스 옆에 **프록시(proxy)**를 배치하여 모든 인바운드/아웃바운드 트래픽을 가로채고 처리하게 합니다. 애플리케이션은 순수한 비즈니스 로직에만 집중하면 됩니다.
전통적 방식:
[서비스 A] ---(직접 호출)--→ [서비스 B]
↑ 재시도, 타임아웃, mTLS, 메트릭 코드가 서비스 내부에 존재
서비스 메시:
[서비스 A] → [프록시 A] ---(메시 통신)--→ [프록시 B] → [서비스 B]
↑ 비즈니스 로직만 ↑ 재시도, mTLS, 관측 등 인프라 기능 처리
서비스 메시는 크게 네 가지 핵심 기능을 제공합니다.
트래픽 관리: 로드 밸런싱, 라우팅 규칙, 카나리 배포, A/B 테스트, 서킷 브레이커, 재시도, 타임아웃을 인프라 수준에서 처리합니다.
보안: 서비스 간 통신을 mTLS(mutual TLS)로 자동 암호화하고, 서비스 아이덴티티 기반 인증과 인가 정책을 적용합니다.
관측 가능성: 모든 서비스 간 트래픽의 메트릭(지연 시간, 에러율, 처리량), 분산 추적, 액세스 로그를 애플리케이션 코드 변경 없이 자동 수집합니다.
회복 탄력성: 장애 전파를 방지하는 서킷 브레이커, 지능적 재시도, 아웃라이어 감지(outlier detection)를 제공합니다.
서비스 메시는 2016년 Linkerd가 처음 "서비스 메시"라는 용어를 사용한 이후 빠르게 진화했습니다.
가장 보편적인 구현 방식은 사이드카 패턴입니다. 각 서비스 Pod에 Envoy 같은 프록시를 사이드카 컨테이너로 주입합니다.
# Kubernetes Pod 내부 구조
apiVersion: v1
kind: Pod
spec:
containers:
- name: my-app # 비즈니스 로직
image: my-service:v1
- name: envoy-proxy # 사이드카 프록시 (자동 주입)
image: envoy:latestIstio(2017)가 이 방식을 대중화했고, 수년간 서비스 메시의 표준 아키텍처로 자리 잡았습니다. 하지만 사이드카 방식에는 명확한 단점이 있습니다.
사이드카의 한계를 극복하기 위해 두 가지 새로운 접근 방식이 등장했습니다.
Istio Ambient Mesh: 사이드카 대신 노드당 하나의 경량 프록시(ztunnel)를 배치하여 L4 기능(mTLS, TCP 라우팅)을 처리하고, L7 기능(HTTP 라우팅, 인가)이 필요한 서비스에만 선택적으로 웨이포인트 프록시(waypoint proxy)를 배포합니다. 2024년 11월에 GA(General Availability)에 도달했습니다.
Cilium Service Mesh: 리눅스 커널의 eBPF 기술을 활용하여 네트워킹, 보안, 관측 가능성을 커널 수준에서 처리합니다. 프록시 없이 L3/L4 기능을 수행하고, L7 기능이 필요한 경우에만 노드당 공유 Envoy를 사용합니다.
2026년 현재, 서비스 메시 생태계는 세 가지 주요 프로젝트를 중심으로 정리되고 있습니다.
| 프로젝트 | 핵심 접근 | CNCF 상태 | 최신 버전 |
|---|---|---|---|
| Istio | Ambient(사이드카 없음) + 레거시 사이드카 | Graduated | 1.25+ |
| Cilium | eBPF 커널 레벨 + 노드당 Envoy | Graduated | 1.16+ |
| Linkerd | Rust 마이크로 사이드카 | Graduated | 2.16+ |
각 프로젝트는 서로 다른 철학과 아키텍처를 가지고 있으며, 이 시리즈에서 하나씩 깊이 있게 다루겠습니다.
Consul(HashiCorp)도 서비스 메시 기능을 제공하지만, 주로 멀티 플랫폼(VM, 베어 메탈, Kubernetes 혼합) 환경에서의 서비스 디스커버리에 강점이 있습니다. 순수 Kubernetes 환경에서는 위 세 프로젝트가 사실상 표준입니다.
모든 조직에 서비스 메시가 필요한 것은 아닙니다. 다음 조건에 해당하는 경우 서비스 메시 도입을 고려해야 합니다.
도입을 고려해야 하는 경우:
아직 이른 경우:
이 시리즈는 서비스 메시의 원리부터 실전 운영까지 체계적으로 다룹니다.
다음 장에서는 서비스 메시의 두 핵심 구성요소인 데이터 플레인과 컨트롤 플레인의 아키텍처를 깊이 있게 살펴보겠습니다.
이 글이 도움이 되셨나요?
서비스 메시의 핵심 구성요소인 데이터 플레인과 컨트롤 플레인의 역할, Envoy 프록시의 내부 구조, 그리고 다양한 배포 모델을 분석합니다.
Istio의 내부 아키텍처, Ambient 모드와 사이드카 모드의 비교, 설치와 기본 설정까지 Istio의 핵심을 깊이 있게 분석합니다.
Istio의 트래픽 관리 기능을 실전 시나리오로 살펴봅니다. 가중치 기반 라우팅, 카나리 배포, 서킷 브레이커, 폴트 인젝션, 트래픽 미러링까지.