MSA에서 서비스 간 효과적인 통신을 책임지는 Service mesh 개념 읽어보기

 

사진: Unsplash 의 Growtika

 

 

Service mesh

최근 신규 서비스 설계를 하면서 Service mesh와 Istio에 대한 내용들을 보게 되었습니다.

 

직접 사용해 보거나 공부를 해본 적은 없고 간접적으로 이런 게 있다 정도로만 알고 있었는데요,

말 나온 김에 가볍게라도 리서치를 해봐야겠다 싶어서 포스팅을 작성합니다.

 

 

In software architecture, a service mesh is a dedicated infrastructure layer for facilitating service-to-service communications between services or microservices using a proxy.

- 출처 : 위키피디아

 

 

위키피디아에서는  Service mesh는  proxy를 사용하여 마이크로 서비스, 서비스들 사이의 통신을 원활하게 하는 기반 레이어라고 설명하고 있습니다.

 

일반적으로 Service mesh는 Microservice architecture에서의 서비스 간 통신을 원활하게 하기 위해 도입하는 레이어로 알려져 있습니다.

 

왜 이런 인프라레이어가 필요할까요?

 

필요성을 알기 위해 우리는 MSA에 대해 우선적으로 이해하고 넘어가야 합니다.

 

MSA에 대한 설명은 이전에 포스팅 한 글이 있으니 참고해 보시면 도움이 될 것 같습니다.

 

읽으면서 배우는 소프트웨어 - MSA(Micro Service Architecture)

 

 

Microservice architecture , MSA라고도 불리는 이 설계방식은 서비스 들이 독립적으로 수행하면서 API를 통해 서로 통신하는 구조를 가지고 있습니다. 

 

사실 통신은 API호출방식뿐만 아니라, Message centric architecture 등 다양한 방식으로 서비스 간 통신을 구현할 수 있을 것입니다.

 

Service mesh는 애플리케이션의 각 구성 요소(서비스) 간의 통신을 효과적으로 관리하고 제어하기 위한 목적으로 도입됩니다. MSA의 경우 단일 애플리케이션 내에 많은 서비스들이 통신하는 구조이다 보니, Service mesh의 채택이 필요하게 되었고 이렇게 도입된Service mesh는 여러 서비스가 존재하는 MSA 내에서 발생하는 통신, 보안, 모니터링 등의 관리를 목적으로 사용됩니다.

 

반응형

 

 

필요성

 

앞에서 언급했다시피 MSA를 채택하여 설계된 애플리케이션의 경우 내부 서비스 간 통신이 필수적입니다. 

어플리케이션의 원활한 동작을 위해서는 각 서비스 통신이 관리되어야 하며, 서비스의 확장 시 이런 관리가 어려워집니다.

 

Service Mesh는 애플리케이션 내 서비스 간 통신의 Observability 와 서비스 수준의 제어에 그 목적을 두고 있습니다.

 

 

장점

 

기본적으로 서비스메쉬는 어플리케이션 내에서 발생하는 서비스 간 통신을 처리하는 중앙 집중형 전용 인프라계층을 제공합니다. 따라서 서비스 메시를 도입하였을 때 장점은 다음과 같습니다.

 

1. 서비스 검색

 

자동화된 서비스 검색을 제공하며 서비스 endpoint 관리 운영의 부하를 줄여줍니다.

서비스 레지스트리를 사용하여 메시 내 서비스들을 동적으로 검색하고 추적이 가능합니다.

 

 

2. 로드밸런싱

 

서비스 메시는 RR(라운드로빈), 최소연결, 가중치 로드밸런싱 등의 알고리즘을 통해 여러 서비스 인스턴스에 부하를 분산합니다. 개인적으로 로드밸런싱은 MSA를 하는 경우 기본적으로 탑재해야 하는 부분이라 서비스 메시만의 장점이라고 보기는 어렵다고 생각합니다. ^^;

 

3. 카나리 배포

 

대부분의 사용자는 기존 안정적인 버전을 사용하면서 일부 사용자 또는 트래픽을 새 서비스 버전에 전달 가능합니다. 노출이 제한되므로 실제 환경에서 새 버전의 동작과 성능을 실험할 수 있습니다.

 

4. 모니터링

 

서비스 메시는 중앙집중화를 통해 포괄적인 모니터링 및 관찰성 기능을 제공하여 서비스 상태, 성능 및 행동에 대한 모니터링이 가능합니다.

 

 

단점

 

서비스 메시 도임에 따른 단점도 존재하는데요, 단점은 아래와 같습니다.

아래 내용 외에도 다른 단점들도 있으니 더 궁금하신 분들은 리서치 또는 직접 체험해 보시기 바랍니다.

 

1. 인스턴스 증가

 

사이드카 패턴을 구현하기 위해 추가 인스턴스가 필요합니다.

 

2. 지연

 

서비스 간 통신을 위해 네트워크 레이어 추가가 필요하며 이로 인한 지연이 발생합니다.

 

3. 러닝커브

 

신규기술 도입으로 인한 초반 러닝커브가 존재합니다.

 

 

Service mesh의 기본동작

 

서비스 메시는 서비스 간 통신을 제어하는 로직을 없애고 통신을 자체 인프라 계층으로 추상화합니다.

 

서비스 메시는 네트워크 프락시의 배열로서 애플리케이션에 구축되며, 여러 네트워크 프락시를 사용함으로써 서비스 간 통신을 라우팅 하고 추적합니다.

 

프락시는 네트워크와 마이크로 서비스 간의 중간 게이트웨이 역할을 수행합니다. 어플리케이션 내 서비스로 들어오고 나가는 트래픽은 해당 프로시 서버를 통해 라우팅되며, 프록시는 개별적으로 실행되지만 논리적 개념으로는 각 서비스 옆에 있기 때문에 사이드카 패턴을 적용하였다 볼 수 있습니다.

 

출처 : Redhat

 

Redhat에서 표현한 service mesh 그림이 전체적인 구조를 이해하는데 수월할 것으로 보여 가져와 봤습니다.

 

그림에서는 어플리케이션 내에서 동작하는 마이크로서비스들 옆에 Sidecar를 프록시로 구현하였으며, 각 프록시 간 라우팅을 통해 서비스 간 통신을 하고 있습니다.

 

상당히 추상적인 이미지이나, 앞의 설명을 읽어보고 본다면 이해하는데 큰 도움이 될 것입니다.

 

Istio

 

서비스 메시의 개념을 어느 정도 들어보신 분 들이라면

Istio를 바로 떠올리실 것입니다.

 

리서치를 하다 보면 Istio가 서비스 메시 그 자체라고 보아도 무방할 것 같다는 생각이 들었습니다.

출처: istio.io

 

서비스 메시의 개념은 Istio 가 어떻게 동작하는지를 이해하면 더 빠르게 이해할 수 있을 것입니다.

이번 포스팅에서 구구절절 설명한 내용과 위의 그림이 어느 정도 매칭이 되시는지요?

 

다음 포스팅에서는 Istio의 동작을 설명함으로써 서비스 메시의 개념에 대한 이해를 마무리 짓도록 하겠습니다.

 

 

읽어주셔서 감사합니다.