서비스 메시(Service Mesh)란? + API Gateway와 차이점

서비스 메시란?

Mesh란 그물,망사라는 뜻을 가지고 있으며, Service Mesh는 Serivce들이 그물처럼 엮여있는것을 뜻합니다.

MicroService Architecture를 적용한 시스템의 내부 통신이 그물(Mesh) 네트워크의 형태를 띄는 것에 빗대어 Service Mesh로 명명됩니다.

 

애플리케이션 계층이 아닌 인프라 플랫폼 계층에 특정 모듈을 삽입하여 애플리케이션에 대한 라우팅, 보안 및 안정성 기능을 추가하는 도구입니다.

 

서비스 메시는 쿠버네티스와 같은 컨테이너 오케스트레이션 환경에서 일반적으로 애플리케이션 코드(사이드 카 라고 불리는 패턴)와 함께 배치된 확장 가능한 네트워크 프록시 모듈로 구현됩니다.

https://daddyprogrammer.org/post/13700/service-mesh/

그림을보면 MicroService와 SideCar로 구성되어 있고, SideCar를 통해 그물처럼 통신합니다.

대게 Service Mesh의 구현체로는 istio, linkerd, conduit 등이 있습니다.

 

Kubernetes기반의 서비스를 구성하거나 오픈소스를 적용하다보면 대게 istio로 구성되는 경우가 많습니다.

 

사이드 카 패턴이란?

애플리케이션 컨테이너와 독립적으로 동작하는 별도의 컨테이너를 붙이는 패턴입니다.

오토바이에 연결된 사이트와 유사하기 때문에 사이드 카 패턴이라고 불립니다.

애플리케이션 컨테이너와 독립적으로 동작하기 때문에 사이드카 장애 시 애플리케이션이 영향을 받지 않고, 사이드카 적용/변경/제거 등의 경우에 애플리케이션은 수정이 필요가 없습니다.

https://azderica.github.io/00-design-pattern-sidecar/

 

쿠버네티스 생태계가 점차 컨테이너 오케스트레이션 시장의 표준이 되어 가며 많은 개발자들이 서비스 메시의 가치를 인식하고 있는 상황입니다.

 

서비스 메시를 사용하는 이유는?

서비스 메시 없이 동작하는 마이크로 서비스는 서비스 간 커뮤니케이션을 통제하는 로직으로 코딩해야 하기 때문에 개발자들이 비즈니스 로직에 집중하지 못하게 됩니다.

 

또한 서비스 간 커뮤니케이션을 통제하는 로직이 각 서비스 내부에 숨겨져 있기 때문에 커뮤니케이션 장애를 진단하기 더 어려워집니다.

 

수십 개의 Microservice가 분리되어 있고 서비스 간의 통신도 매우 복잡하여 새로운 장애 지점이 계속 나타나게 된다면 서비스 메시 없이는 문제가 발생한 지점을 찾아내기가 어려울 것입니다.

 

그러면 서비스 메시로 얻는 이점은?

서비스 메시가 서비스 간 커뮤니케이션의 모든 부분을 성능 메트릭으로 캡처할 수 있습니다.

• 개발자 들은 비즈니스 로직에 집중할 수 있습니다.
• 문제를 손쉽게 인식하고 진단할 수 있습니다.
• 장애가 발생한 서비스로부터 요청을 재 라우팅 할 수 있기 때문에 애플리케이션 복구 능력이 향상됩니다.
• 성능 메트릭을 통해 런타임 호나경에서 커뮤니케이션을 최적화하는 방법을 제안할 수 있습니다.

 

 

그런데 API를 포함하여 애플리케이션의 효율을 극대화함에 있어 API Gateway라는 관리 솔루션이 존재합니다.

기본적으로 API 게이트웨이는 외부에서 들어오는 트래픽에 대한 제어를 담당합니다.

반면에 서비스 메시는 서비스 내부의 통신에 대한 제어를 담당합니다.

 

API Gateway와 서비스 메시는 하고자 하는 일은 명확하게 다릅니다.

하지만 트래픽 제어, 라우팅, 메트릭 수집, 보안/정책 적용 등 기능이 중복되기 때문이며 서비스 메시가 자체로 Ingress Gateway 같은 것을 가지고 있기 때문에 많은 분들은 이 둘을 혼란스럽습니다. 

 

Ingress란?

외부로부터 서버 내부로 유입되는 네트워크 트래픽을 의미합니다.

서비스 메시와 API Gateway 무엇이 다른가요?

- 적용되는 위치

API Gateway는 중앙 집중식 제어 영역으로 외부에서 들어오는 트래픽에 대한 제어를 담당합니다.

(외부망과 내부망 사이)

 

서비스 메시는 애플리케이션 기능을 인프라 계층에 의해 관리되는 마이크로 서비스로 분리하는 방법입니다.

서비스 메시는 서비스 내부의 통신에 대한 제어를 담당합니다.

(내부망 Kubernetes 클러스터)

 

- 아키텍처

API Gateway가 중앙집중형 아키텍처여서 SPOF(Single Point of Failure)을 생성한다면 서비스 메시는 분산형 아키텍처를 취하기 때문에 SPOF를 생성하지 않고 확장이 용이합니다.

 

- 패턴

API Gateway는 일반적으로 Gateway proxy pattern을 사용합니다.

Consumuer(호출자)는 구현 내용을 알 필요 없이 Gateway를 호출하는 방법만 알면 Gateway가 알아서 수행하는 방식입니다.

 

Service Mesh는 일반적으로 Sidecar proxy pattern을 사용합니다.

Consumuer(호출자)의 코드에는 Provider(공급자)의 주소를 찾는 방법, failover와 관련된 코드 등의 내용이 들어가게 됩니다. 다만 호출자의 코드는 애플리케이션 코드에 내장되는 것이 아니라 sidecar 형태로 별도로 관리됩니다.

 

 

API게이트웨이와 서비스 메시를 함께 사용하면 서비스 메시 아키텍처의 중재자 역할을 할 수 있습니다.

따라서 보안과 속도가 좋아집니다.

주요 항목	서비스 메시	API Gateway
목적	내부 엔터프라이즈 시스템 및 마이크로 서비스 내의 이식성을 개선하도록 설계	내부/외부 및 심지어 데이터베이스 엑세스 위한 API 호출까지도 라우팅 할 수 있도록 설계
동작방법	내부 엔터프라이즈 서비스 범위 내에서 운영	회사 외부에 있는 애플리케이션에서의 연계를 위한 라우팅을 지원
API 역할	API는 규모에 맞는 서비스 메시를 보호하는 데 사용	API 게이트웨이는 API를 관리하고 보호하는 데 사용
디지털 트랜스포메이션	마이크로 서비스를 관리하여 제공 시간을 단축하지만 보안 문제가 발생할 수 있음	특히 서비스 메시와 함께 사용할 경우 출시 시간을 단축하고 보안을 보장
복잡성	엔드포인트가 비즈니스에 따라 확장됨에 따라 복잡성 가중	엔드포인트를 쉽게 관리하고 API를 확장하여 서비스 메시를 관리
기술 성숙도	신기술	성숙한 기술
보안	수동 프로세스에 의한 보안 정책 적용	자동화된 보안 정책 및 기능

 

위의 표를 보면 서비스 메시의 단점들을 API Gateway가 보완해주는 것 같습니다.

그리고 API Gateway 입장에서는 서비스 메시는 디테일을 관리하는 것 같습니다.

 

그러면 둘 다 필요한가요?

API Gateway와 서비스 메시는 기능면에서 유사한 부분들이 존재합니다.

하지만 이들의 역할을 상당히 다르고 상호보완적인 부분들이 있습니다.

 

최근 MSA에서 API Gateway는 노출되는 부분(External)에 위치하여 내부 서비스를 보호 및 제어하는 역할을 하고, Service Mesh는 내부 서비스(Internal)에 위치하여 서비스를 관리하는 구조로 많이 사용되고 있습니다.

 

 

출처

https://velog.io/@tedigom/MSA-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-4Service-Mesh-f8k317qn1b

https://ideatec.co.kr/APIGateway_view/?idx=9144841&bmode=view 

https://yjiwony.tistory.com/24

https://daddyprogrammer.org/post/13700/service-mesh/

https://blog.christianposta.com/microservices/do-i-need-an-api-gateway-if-i-have-a-service-mesh/

https://courage1.tistory.com/37

https://medium.com/dtevangelist/service-mesh-%EB%9E%80-8dfafb56fc07