Service Mesh vs Api Gateway

IaC/Service Mesh

Service Mesh vs Api Gateway

Somaz 2023. 3. 8. 18:42

728x90

Overview

https://www.xenonstack.com/insights/service-mesh-vs-api-gateway

오늘은 Service Mesh와 Api Gateway에 대해 공부한 후 둘의 차이점을 알아보려고 한다.

Service Mesh란?

https://www.wallarm.com/what/api-gateway-vs-service-mesh

개요

Service Mesh는 분산 애플리케이션에서 서비스 간의 통신을 관리하기 위한 인프라스트럭처이다.

마이크로서비스 아키텍처에서는 여러 개의 작은 서비스로 구성된 애플리케이션을 구축하게 되는데, 이러한 작은 서비스들은 서로 통신하면서 애플리케이션을 구성한. 이때, 서비스 간의 통신은 네트워크 상에서 발생하기 때문에 이를 관리하기 위한 인프라스트럭처가 필요하다.

Service Mesh는 이러한 서비스 간의 통신을 추상화하여 관리한다. 즉, 서비스 간의 통신을 위한 네트워크 인프라를 쉽게 관리할 수 있도록 도와준다. Service Mesh는 분산 추적, 보안, 로깅, 부하 분산 등의 기능을 제공하며, 이러한 기능들은 서비스 간의 통신을 안전하고 효율적으로 처리할 수 있도록 도와준다.

Service Mesh를 구현하는 방법에는 여러가지가 있지만, 일반적으로는 사이드카 패턴(Sidecar Pattern)을 사용한다. 사이드카 패턴은 각 서비스 인스턴스에 사이드카 컨테이너를 배치하여, 이를 통해 서비스 간의 통신을 관리한다. 이때, 사이드카 컨테이너는 Service Mesh 솔루션에서 제공하는 프록시나 에이전트로 구성된다.

주요기능

Service Mesh의 주요 기능은 다음과 같다.

분산 추적: 서비스 간의 통신을 추적하고 분석하여, 문제 발생 시 신속한 대응이 가능하다.
보안: 트래픽 암호화, 인증, 인가, 접근 제어 등의 기능을 제공하여, 보안성을 향상시킨다.
로깅: 서비스 간의 통신 내역을 기록하여, 문제 해결에 도움을 준다.
부하 분산: 트래픽을 여러 서비스 인스턴스로 분산시켜, 안정적인 서비스 제공을 가능하게 한다.

주요 Service Mesh 솔루션으로는 Istio, Linkerd, Consul 등이 있다. 이러한 솔루션을 사용하면, Service Mesh를 쉽게 구현하고 운영할 수 있다.

사이드카 패턴(Sidecar Pattern)이란?

https://learn.microsoft.com/ko-kr/azure/architecture/patterns/sidecar

사이드카 패턴은 마이크로서비스 아키텍처에서 서비스 간 통신과 관련된 로직을 별도의 컨테이너인 사이드카 컨테이너에 넣고, 서비스 컨테이너와 함께 배치하여 서비스 간 통신을 간편하게 처리하는 디자인 패턴이다.

사이드카 패턴에서는 각 서비스는 자신의 비즈니스 로직을 처리하는 메인 컨테이너와, 네트워크 통신과 관련된 로직을 처리하는 사이드카 컨테이너로 구성된다. 이렇게 분리된 사이드카 컨테이너는 각 서비스 컨테이너와 함께 동일한 Pod(Pod는 Kubernetes에서 하나 이상의 컨테이너를 포함하는 가장 작은 배포 단위)에 배치되어 통신을 담당한다.

사이드카 컨테이너는 각 서비스 컨테이너와 함께 라우팅, 로드 밸런싱, 인증, 인가, 모니터링 등의 기능을 수행한다. 이를 통해 각 서비스 컨테이너는 자신의 비즈니스 로직에 집중할 수 있으며, 네트워크와 관련된 로직은 사이드카 컨테이너가 처리하므로, 서비스 간 통신이 간단하고 안정적으로 이루어진다.

사이드카 패턴은 Kubernetes와 같은 컨테이너 오케스트레이션 플랫폼에서 활용다. Kubernetes에서는 각 Pod에 여러 개의 컨테이너를 배치할 수 있고, 이 중 하나를 사이드카 컨테이너로 지정하여 사용할 수 있습니다. 이를 통해 각 서비스의 배포 및 관리를 간편하게 처리할 수 있다.

사이드카 패턴은 Service Mesh와 API Gateway 두 가지 모두에서 사용할 수 있다.

Service Mesh에서는 사이드카 패턴을 사용하여 각 서비스 인스턴스에 대한 트래픽 관리 및 모니터링을 수행할 수 있다.

예를 들어, Istio Service Mesh에서는 Envoy 사이드카를 사용하여 서비스 간의 통신을 제어하고 모니터링할 수 있다.

API Gateway에서는 사이드카 패턴을 사용하여 인바운드 및 아웃바운드 요청을 처리하고 보안 및 인증과 같은 추가 기능을 제공할 수 있다. 예를 들어, AWS API Gateway에서는 Lambda 함수와 함께 사용하여 서버리스 아키텍처를 구축하고, 사이드카를 사용하여 API Gateway 인스턴스 간의 트래픽을 관리할 수 있다.

어댑터 컨테이너(Adapter Container)란?

https://www.usenix.org/conference/hotcloud16/workshop-program/presentation/burns

어댑터 컨테이너(Adapter Container)는 어댑터 패턴을 이용하여 서로 다른 프로토콜, 데이터 포맷 등을 갖는 시스템 간의 연동을 지원하는 솔루션이다.

어댑터 컨테이너는 다양한 종류의 어댑터를 포함하고 있어서, 서로 다른 시스템 간의 통합을 위한 인터페이스를 제공하며, 시스템 간의 데이터 변환, 라우팅, 프로토콜 변환 등의 작업을 수행한다.

어댑터 컨테이너는 보통 ESB(Enterprise Service Bus)와 유사한 기능을 제공하지만, 더 가벼운 구조를 가지고 있어서 속도와 확장성이 더 뛰어나다. 또한, 마이크로서비스 아키텍처에서는 어댑터 컨테이너를 사용하여 각 마이크로서비스 간의 통합을 지원할 수 있다.

어댑터 컨테이너는 일반적으로 어댑터를 구현하는 라이브러리와 함께 제공되며, 이를 이용하여 필요한 어댑터를 개발할 수 있다. 예를 들어, Apache Camel은 다양한 어댑터와 라우팅 기능을 제공하는 어댑터 컨테이너이다.

어댑터 컨테이너는 Service Mesh와 API Gateway 둘 다 사용 가능하다.

Service Mesh에서는 어댑터 컨테이너를 사용하여 각 서비스 인스턴스의 로깅, 추적, 모니터링 및 보안과 같은 부가 기능을 제공할 수 있다. 예를 들어, Istio Service Mesh에서는 Mixer 어댑터를 사용하여 서비스 인스턴스 간의 통신을 모니터링하고 보안 기능을 적용할 수 있다.

API Gateway에서는 어댑터 컨테이너를 사용하여 다양한 프로토콜 및 데이터 형식을 처리하고, 인증 및 보안, 라우팅 등의 추가 기능을 제공할 수 있다. 예를 들어, Kong API Gateway는 다양한 어댑터를 지원하여 다양한 프로토콜 및 데이터 형식을 처리하고, OAuth 및 JWT와 같은 인증 및 보안 기능을 제공할 수 있다.

따라서 어댑터 컨테이너는 Service Mesh와 API Gateway에서 모두 사용 가능하며, 각각의 환경에 맞게 적절한 어댑터를 구현하여 사용할 수 있다.

Api Gateway란?

개요

API Gateway는 마이크로서비스 아키텍처에서 여러 개의 서비스를 하나의 API로 노출시키는 역할을 하는 서비스이다. 클라이언트는 API Gateway에 HTTP 요청을 보내면, API Gateway는 내부의 여러 서비스를 호출하고, 그 결과를 적절히 변환하여 클라이언트에게 전달한다.

주요기능

API Gateway는 주요 기능은 다음과 같다.

인증과 인가: 클라이언트의 요청을 검증하고, 사용자 인증과 권한 검사를 수행한다. 이를 통해 보안적인 측면에서 안전한 API를 제공할 수 있다.
로드 밸런싱: 여러 개의 서비스를 처리할 때, 요청을 분산하여 각각의 서비스에 고르게 전달한다. 이를 통해 각 서비스의 부하를 분산시킬 수 있고, 가용성을 향상시킬 수 있다.
캐싱: 반복적인 요청에 대해 빠른 응답을 제공하기 위해, API Gateway는 캐시를 활용하여 서비스의 부하를 줄인다.
로깅과 모니터링: API Gateway는 클라이언트의 요청 및 서비스의 응답 등을 기록하고 모니터링할 수 있다. 이를 통해 문제 발생 시 즉각적으로 대응할 수 있다.
API 관리: API Gateway는 API를 관리하고 버전을 관리할 수 있다. 새로운 버전의 API를 배포하거나, 이전 버전의 API를 제거할 수 있다.

API Gateway는 마이크로서비스 아키텍처에서 필수적인 서비스로, 다양한 기능과 유연성을 제공하여 애플리케이션을 효율적으로 관리하고 운영할 수 있다.

엠버서더 패턴(Ambassador Pattern)이란?

https://learn.microsoft.com/ko-kr/azure/architecture/patterns/ambassador

Ambassador 패턴은 마이크로서비스 아키텍처에서 클라이언트와 서비스 간의 통신을 처리하는 디자인 패턴이다. 클라이언트가 서비스를 호출하면, 호출된 요청을 서비스의 API에 맞게 변환해주는 역할을 수행하는 서비스 프록시 역할을 담당하는 컴포넌트를 말한다.

이 패턴에서는 API Gateway와 같은 프록시 서버가 존재하며, 클라이언트는 프록시 서버를 통해 마이크로서비스에 접근한다. 이를 통해 클라이언트는 개별 서비스의 IP 주소나 포트 등을 알 필요 없이, 단일 엔드포인트를 통해 마이크로서비스에 접근할 수 있다. 또한, 프록시 서버는 API 요청을 필터링하고 인증, 인가, 로드 밸런싱 등의 역할을 수행할 수 있다.

Ambassador 패턴은 기존의 서비스를 수정하지 않고도 프록시 서버를 추가함으로써, 서비스 간 통신에 대한 유연성과 확장성을 제공한다. 또한, API Gateway를 중심으로 구성됨으로써, 각 마이크로서비스는 자신만의 API를 유지할 수 있으며, 인프라스트럭처와 분리됨으로써 개발 생산성을 높일 수 있다.

마찬가지로 Ambassador 패턴은 Service Mesh와 API Gateway 모두에서 사용 가능하다.

Service Mesh에서는 Envoy 같은 Sidecar 프록시에 대해 Ambassador 역할을 부여하여 각 마이크로서비스에 대한 단일 진입점(Single Entry Point)을 제공한다.

API Gateway에서는 대부분의 경우 Ambassador 패턴을 적용하여, 클라이언트의 요청을 전달하고 서비스에서 반환된 응답을 받아 클라이언트에게 전달한다. 이 경우, API Gateway의 기능으로는 로드 밸런싱, 인증, 인가, API 버전 관리, 캐싱, 로깅 등이 포함된다.

따라서, Service Mesh와 API Gateway 모두에서 Ambassador 패턴을 활용하여 각각의 아키텍처에서 마이크로서비스 간 통신을 보다 효율적으로 처리할 수 있다.

Service Mesh와 Api Gateway의 차이점

개요

API Gateway와 Service Mesh는 모두 분산 애플리케이션에서 서비스 간의 통신을 관리하기 위한 도구이다.

하지만 둘은 목적과 구현 방법에서 차이가 있다.

차이점

API Gateway는 클라이언트와 백엔드 서비스 간의 통신을 중개하는 서버이다.

클라이언트는 API Gateway를 통해 백엔드 서비스에 요청을 보내며, API Gateway는 해당 요청을 수신하여 필요한 인증, 인가, 로깅 등의 처리를 수행한 뒤에 백엔드 서비스에 전달한다.

API Gateway는 단일 진입점(Single Entry Point)을 제공하여 클라이언트와 백엔드 서비스 간의 통신을 간소화하고, 보안과 모니터링을 향상시킬 수 있다.

반면에, Service Mesh는 분산 애플리케이션 내부의 서비스 간의 통신을 관리한다. 각 서비스 인스턴스에 사이드카 컨테이너를 배치하여, 이를 통해 서비스 간의 통신을 중개한다. Service Mesh는 분산 추적, 보안, 로깅, 부하 분산 등의 기능을 제공하여 서비스 간의 통신을 안전하고 효율적으로 처리할 수 있도록 도와준다.

따라서, API Gateway는 클라이언트와 백엔드 서비스 간의 통신을 중개하는 서버로서, 외부에서 액세스하는 서비스를 관리하고 보호하는데 사용되며, Service Mesh는 분산 애플리케이션 내부의 서비스 간의 통신을 관리하여, 분산 애플리케이션을 보호하고 안정적으로 운영하는데 사용된다.