Service Mesh 소개

클라우드 개발 환경에서 종종 Service Mesh란 키워드를 들으신 적이 있을 수 있습니다. Service Mesh라고 하면 네트워크와 관련된 것 같은 느낌이 있는데요.

이름에 담긴 느낌처럼, Service Mesh의 간략한 정의는 ‘애플리케이션의 서비스 간 모든 통신을 처리하는 소프트웨어 계층’이라고 할 수 있습니다.

그렇다면 Service Mesh를 도입해서 서비스 간 모든 통신을 처리하고 관리해야 할 이유는 무엇일까요? 이는 아래와 같이 정리할 수 있습니다.

가시성
- MSA 환경에서 서비스 간에 주고받는 트래픽에 대한 로그를 얻을 수 있으므로, 애플리케이션 외부에서 일어나는 이벤트의 가시성을 확보 가능
트래픽 관리
- 서비스 간에 주고받는 트래픽을 독립된 레이어에서 제어 가능
보안성
- 상호 TLS(mTLS) 설정으로 서비스간 통신에서 검증이 가능
- 별도의 Policy를 적용하여 서비스간 통신 가능 여부를 제어할 수 있고, 이를 코드로 관리 가능

그렇다면 Service Mesh는 어떻게 동작할까요? Service Mesh의 두 구성 요소인 데이터 플레인(Data Plane)과 컨트롤 플레인(Control Plane)으로 나눠서 알아보겠습니다.

데이터 플레인
- Service Mesh의 데이터 처리 역할 수행
- 각 서비스에 Service Mesh를 위한 별도의 네트워크 프록시가 Sidecar로 추가되며, 해당 프록시는 서비스로 들어오고 나가는 모든 트래픽이 거치는 중간 게이트 역할
- 서비스 간의 통신이 발생할 때 동작 과정
  - Sidecar로 추가되었던 네트워크 프록시가 요청을 받음
  - 받은 요청을 별도의 네트워크 연결로 캡슐화
  - 출발 프록시와 도착 프록시 간의 안전하고 암호화된 채널 설정
- 이외에도 로드 밸런싱, Circuit Breaker, 트래픽 라우팅과 같은 역할도 수행
컨트롤 플레인
- Service Mesh의 중앙 관리 및 구성 계층 역할 수행
- 서비스 간의 라우팅 규칙, 로드 밸런싱 정책, 보안 설정 등이 가능한 영역
- 이외에도 Mesh 내 모든 서비스를 추적하는 레지스트리, Telemetry 데이터의 수집 및 집계 역할도 수행

지금까지 알아본 Service Mesh는 어떻게 적용할 수 있을까요? 대표적인 Service Mesh 솔루션으로 Istio가 있습니다.

Istio는 Kubernetes와 함께 작동하도록 설계되어 있어 호환성이 높으며, 이때 Istio의 네트워크 프록시가 Kubernetes의 Pod 내 Sidecar 컨테이너로 추가되는 방식으로 Service Mesh를 구현합니다.

Istio와 관련된 더욱 자세한 글은 여기서 확인해보세요.

Guide to DevOps