Service Mesh
Service Mesh는 서비스 간 통신에서 반복되는 재시도, 타임아웃, 인증, 트레이싱 같은 공통 관심사를 애플리케이션 코드 밖의 프록시 계층으로 옮기는 구조입니다. 각 서비스는 자기 비즈니스 로직에 집중하고, 실제 네트워크 호출은 옆에 붙은 프록시가 대신 조정합니다. 그래서 메시의 핵심은 또 다른 비즈니스 계층을 만드는 것이 아니라, east-west 트래픽 제어를 인프라 레이어로 승격시키는 데 있습니다.
▶아키텍처 다이어그램
🔗 관계 다이어그램점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
서비스 수가 늘면 모든 서비스가 HTTP 클라이언트 설정, 재시도 정책, 타임아웃, 인증서 갱신, 트레이스 헤더 전파를 제각각 구현하게 됩니다. 어떤 팀은 재시도를 세 번 하고, 어떤 팀은 타임아웃이 없고, 어떤 언어 런타임은 추적 헤더를 빠뜨립니다. 같은 문제를 푸는 코드가 서비스마다 다르게 쌓이기 시작하면 장애 분석과 정책 변경이 매우 어려워집니다. 공통 통신 문제를 서비스 코드 안에 두는 것이 병목이 되는 시점이 옵니다.
마이크로서비스가 소수일 때는 공통 라이브러리로도 어느 정도 버틸 수 있었습니다. 하지만 팀과 언어 스택이 다양해지고, 서비스 수가 빠르게 늘면서 라이브러리 버전 차이와 구현 편차가 커졌습니다. 동시에 mTLS, 세밀한 트래픽 제어, 분산 추적 같은 운영 요구가 보편화됐고, 이를 애플리케이션마다 구현하는 비용이 너무 커졌습니다. 이 배경에서 통신 정책을 서비스 코드 밖에서 통일하려는 시도가 Service Mesh 형태로 자리 잡았습니다.
각 서비스 앞에는 사이드카 프록시나 노드 프록시가 붙고, 서비스는 실제 원격 호출 대신 로컬 프록시에 요청을 보냅니다. 프록시는 서비스 이름을 해석하고, 정책에 따라 재시도나 타임아웃을 적용하고, mTLS로 통신을 암호화하며, 트레이싱 메타데이터를 남깁니다. 제어면은 이 프록시들에게 라우팅 규칙, 인증서, 트래픽 분할 정책을 배포합니다. 결과적으로 서비스 코드는 상대 서비스의 세세한 네트워크 운영보다 비즈니스 처리에 집중하게 됩니다.
API Gateway가 외부에서 들어오는 north-south 트래픽의 입구를 다룬다면, Service Mesh는 서비스 사이의 east-west 트래픽을 다룹니다. Service Discovery가 현재 살아 있는 서비스 위치를 알려주는 메커니즘이라면, Mesh는 그 위치로 어떻게 호출할지를 제어합니다. 서비스가 몇 개 안 되고 언어도 단순한 환경에서는 메시가 오히려 운영 복잡도를 더할 수 있습니다. 공통 통신 정책의 비용이 실제로 문제일 때 도입해야 의미가 있습니다.
서비스 수가 많고 팀별 구현 편차가 운영 문제로 이어지거나, mTLS와 카나리 배포, 세밀한 재시도 정책을 일관되게 적용해야 하는 환경에 적합합니다. 특히 플랫폼 팀이 공통 통신 정책을 중앙에서 관리하려 할 때 힘을 발휘합니다. 반대로 호출 수가 적고 서비스 구성이 단순한 제품에서는 프록시 레이어가 늘어나는 비용만 커질 수 있으므로, 운영 성숙도와 서비스 수를 함께 보고 판단해야 합니다.