Service Mesh란?

1. Service Mesh란?

https://istio.io/latest/about/service-mesh/

 

Service Mesh는 마이크로서비스 간 통신이 매시 형태인 것에서 착안된, 마이크로서비스 간의 통신을 나타내는 개념입니다. 이는 여러 서비스 간의 통신을 관리하는 것을 도와줍니다. 

 

소프트웨어를 작은 단위로 나누어 개발하는 방식인 마이크로서비스에서는 각각의 서비스들이 서로 통신하여 기능을 수행하기 때문에 이러한 분산된 통신을 관리해 줄 도구가 필요해집니다. 

 

Service Mesh는 서로 다른 기능 간의 통신이 원활할 수 있도록 통신을 관리해 주고, 데이터를 안전하게 전송하고 저장할 수 있도록 해줍니다. 또한 서비스들의 동작을 계속해서 모니터링하여 이슈가 발생할 경우 알려줍니다. 

 

일반적으로, Service Mesh는 Kubernetes와 같은 컨테이너 오케스트레이션 환경 내에서 사이드카 형태의 프록시를 배치합니다. 그리고 이러한 프록시를 통해 트래픽 모니터링이나 트래픽 컨트롤을 수행합니다.

 

사이드카 형태의 프록시를 통해서 Service Mesh는 기존의 애플리케이션 코드를 수정하지 않고도 서비스 간 통신을 모니터링할 수 있고, 필요한 경우 로깅하여 시스템의 상태를 파악하고 문제를 진단할 수 있게 됩니다. 

 

이러한 Service Mesh를 구현하는 오픈 소스 소프트웨어로는 이스티오(Istio), 링커드(Linkerd), Kuma 등이 있습니다. 그중 이스티오를 사용하여 이러한 Service Mesh를 구현하는 경우가 가장 많으며 아래에서 좀 더 자세히 설명하도록 하겠습니다. 

 

추가적으로 사이드카 형태에 대해 간단히 알아보고 넘어가겠습니다. 

 

사이드카 형태란?

https://kubebyexample.com/learning-paths/istio/intro

애플리케이션 컨테이너와 독립적으로 동작하는 또 하나의 컨테이너를 붙이는 패턴을 의미합니다. 즉, 메인 컨테이너 외 보조적인 기능을 추가하는 서브 컨테이너를 포함하는 패턴이 바로 사이드카 형태입니다. 
애플리케이션 컨테이너(메인 컨테이너)와 독립적으로 동작하므로 사이드카 컨테이너에 장애가 발생하더라도 애플리케이션 컨테이너는 영향을 받지 않습니다. 
또한 사이드카 컨테이너를 생성하고, 업데이트하고, 제거해야 하는 경우에도 기존 애플리케이션 컨테이너에 대한 코드는 수정을 할 필요가 없습니다. 

 

Service Mesh를 구성하는 개별 프록시들은 마이크로서비스 내에서 실행되는 것이 아니라 마이크로서비스의 옆에서, 즉 사이드카 형태로 함께 실행됩니다. 

 

2. Service Mesh를 사용하는 이유는? 

마이크로 서비스는 여러 작은 서비스들로 구성되어 있기 때문에 서비스 간의 통신이 복잡합니다. 따라서 각 서비스 간의 통신을 추상화하여 더 쉽게 관리할 수 있도록 하기 위해 Service Mesh를 사용합니다.

 

통신을 추상화한다는 것이 정확히 무슨 뜻일까요?

추상화라는 의미 자체는 복잡한 세부 사항들 중 핵심적인 개념 또는 기능을 간추려 내는 것을 의미합니다. 

 

마이크로 서비스는 Service Mesh를 이용하여 각 서비스 간 통신을 추상화 함으로써 개별 서비스 내에 통신 관련 로직을 직접 구현하지 않게 됩니다. 또한 같은 맥락으로 서비스는 다른 서비스의 구체적인 세부 정보를 알 필요가 없어집니다. Service Mesh를 통해 통신하기 때문에 다른 서비스를 신경 쓰지 않고 자신의 로직에만 집중할 수 있게 됩니다. 

이 외에도 통신 보안이나 모니터링과 같은 기능을 Service Mesh가 제공하기 때문에 개발자가 이에 대해 직접 구현할 필요가 없어집니다.

 

또한 Service Mesh는 서비스들의 수가 증가하더라도 쉽게 확장할 수 있도록 구성되어 있습니다. (ex. 사이드카 패턴) 이뿐만 아니라 로드 밸런싱, 트래픽 제어, 오류 처리 등의 기능도 함께 제공하기 때문에 서비스들의 성능과 안정성을 향상하는 역할도 합니다. 

 

서비스 간 통신의 모든 부분을 모니터링할 수 있기 때문에 문제를 손쉽게 인식하고 진단할 수 있으며 장애가 발생한 서비스에 대한 요청을 다시 라우팅 할 수 있도록 해주기 때문에 애플리케이션 복구 능력 역시 향상됩니다.  

 

Service Mesh를 사용하지 않을 경우 서비스 간의 통신을 직접 구현하거나 관리해야 하기 때문에 복잡성이 증가할 수 있습니다. 각 서비스마다 다른 방식으로 통신을 관리하게 되면 유지 보수와 디버깅, 그리고 병목 현상과 같은 네트워크 이슈에 대한 트러블 슈팅이 어려워지게 됩니다. 

 

따라서, Service Mesh는 복잡한 마이크로 서비스 아키텍처에서 필수적인 도구라고 할 수 있습니다. 

 

3. Istio란? 

Istio란 (https://istio.io/latest/about/service-mesh/)

The Istio service mesh

Istio는 기존 분산 애플리케이션에 투명하게 layering 되는 오픈 소스 Service Mesh입니다.
마이크로 서비스들을 보호하고, 연결하고, 모니터링하는 균일하고 효율적인 방법을 제공합니다.
서비스 코드에 대한 최소한의 변경을 통해 또는 서비스 코드 변경 없이 로드 밸런싱, 서비스 간 인증 및 모니터링을 위한 경로(path)가 됩니다. 

 

Istio는 Control Plane과 Data Plane 이 두 가지 요소로 구성되어 있습니다. 

 

먼저 Istio의 Control Plane은 TLS 암호화, ID 기반 인증 및 권한 부여를 통해 클러스터에서 서비스 간 통신을 보호합니다. 

또한 HTTP, gRPC, WebSocket 및 TCP 트래픽에 대한 로드 밸런싱을 제공하고 다양한 라우팅 규칙, 재시도(retries), 장애조치(failover) 등을 통해 트래픽을 세밀하게 제어합니다. 

클러스터의 ingress 및 egress를 포함한 클러스터 내의 모든 트래픽에 대해 자동화된 메트릭, 로그 및 추적 기능도 제공합니다. 

 

Data Plane은 서비스 간 통신 자체를 나타냅니다.

Service Mesh는 전송되는 트래픽의 유형, 출처를 확인하기 위해 프록시를 사용하여 모든 네트워크 트래픽을 확인합니다.

 

정리하자면, 

Data Palne은 각 프록시들로 이루어져 config에 따라 트래픽을 관리하는 부분을 의미합니다. 

이 경우 서비스가 증가하게 되면 프록시 수도 증가하게 됩니다. 프록시가 증가하게 되면 당연히 관리 포인트도 증가하기 때문에 이 부분을 중앙에서 관리할 필요성이 생깁니다. 

config 값들을 저장하고 각 프록시들에게 이에 대해 전달하는 것이 Control Plane의 역할입니다.

 

Istio는 Envoy 프록시를 사용합니다. 

https://www.cncf.io/projects/

 

Envoy 프록시는 Lyft사에서 개발한 프록시로 MSA 내 각 서비스를 위해 설계된 고성능 분산 프록시입니다.

기존 L3, L4 기반의 프록시들로는 다양한 요건들을 처리하기 힘들기 때문에 MSA 환경에서는 L7 기능을 갖춘 프록시의 필요성이 대두되었습니다. 

Envoy 프록시는 L7 기반의 프록시로 HTTP, TCP, gRPC까지 다양한 프로토콜을 지원합니다. 

앞서 말한 Istio가 Service Mesh로서 제공하는 기능이 모두 Istio의 메인 프록시인 Envoy를 통해 제공된다고 보시면 됩니다.