서비스 메시 (Service Mesh)
쉽게 풀면
마이크로서비스 아키텍처에서는 수십, 수백 개의 서비스가 서로 네트워크로 대화를 주고받습니다. 이때 "이 요청을 어디로 보낼지", "실패하면 몇 번 재시도할지", "암호화는 어떻게 할지" 같은 로직을 서비스마다 각각 코드로 짜 넣으면 관리가 매우 힘들어집니다. 서비스 메시는 각 서비스 옆에 작은 대리인(사이드카 프록시)을 붙여서, 통신에 관한 모든 처리를 그 대리인이 대신하게 만드는 방식입니다. 개발자는 비즈니스 로직만 신경 쓰고, 통신 관련 규칙은 메시가 알아서 적용해 주는 셈입니다.
왜 중요한가
클라우드 네이티브 시스템이 마이크로서비스 단위로 잘게 쪼개질수록 서비스 간 통신 관리, 장애 격리, 보안, 관측 가능성(observability) 확보가 핵심 과제가 됩니다. 서비스 메시는 이런 문제를 애플리케이션 코드와 분리된 인프라 계층에서 표준화된 방식으로 해결하기 때문에, 분산시스템·클라우드 컴퓨팅 분야의 아키텍처 연구와 성능·보안 평가 연구에서 자주 다뤄집니다.
논문에서는 이렇게 쓰입니다
이 문장은 "서비스들 사이의 통신 흐름을 별도 계층에서 통제해서 한 서비스의 장애가 전체로 번지지 않도록 막는 방법을 제시한다"는 뜻입니다.
서비스 메시 구현체를 실제로 도입했을 때 통신 지연이 얼마나 늘어나는지 실험적으로 측정했다는, 시스템 성능 평가 연구의 전형적인 서술이다.
서비스 메시가 제공하는 상호 TLS 인증 기능을 통해 마이크로서비스 간 통신 보안을 강화했다는, 보안 연구 맥락의 서술이다.
조금 더 깊게 보면
서비스 메시는 대개 데이터 플레인(각 서비스 옆에 붙는 사이드카 프록시들)과 컨트롤 플레인(전체 정책을 설정·배포하는 관리 계층)으로 나뉘어 동작합니다. Istio, Linkerd 같은 구현체가 대표적이며, 트래픽 라우팅뿐 아니라 mTLS를 통한 서비스 간 인증, 분산 추적(distributed tracing)을 통한 요청 흐름 관찰 등도 함께 제공하는 경우가 많습니다. 최근에는 사이드카 프록시 없이 커널 수준에서 트래픽을 처리해 오버헤드를 줄이려는 접근(예: eBPF 기반 방식)도 연구되고 있습니다.
주의할 점
서비스 메시는 통신을 편리하게 관리해 주지만, 사이드카 프록시를 추가로 운영해야 하므로 시스템 복잡도와 지연 시간(latency)이 늘어날 수 있습니다. 서비스 개수가 적은 경우에는 오히려 API 게이트웨이 (API Gateway) 하나로 충분할 수 있어, 도입 전 시스템 규모를 고려해야 합니다.