메뉴

문서정보

목차

Service mesh

서비스 메쉬(Service Mesh)는 마이크로서비스 아키텍처(MSA - Microservice Architecture)를 구성하는 애플리케이션들이 서로 데이터를 공유하는 방식을 제어하는 방법이다. 서비스 메쉬는 애플리케이션 계층이기 때문에 소프트웨어 설정으로 유연하게 데이터 공유하는 방식을 관리 할 수 있다. 이러한 유연함은 컨테이너화 된 임시 애플리케이션으로 구성되는 MSA 서비스에서 특히 중요한 요소다. 서비스 메쉬는 아래의 기능들을 포함한다.

Proxy와 다른 점

인터넷 서비스 아키텍처에서 Proxy는 사용자 PC의 요청을 서버로 전달하기 위해서 일반적으로 사용하고 있다.

 Proxy

 Proxy

  1. 사용자가 (웹 브라우저를 이용해서)웹 페이지를 요청한다. 요청은 도메인을 포함한 URL 형식으로 작성된다.
  2. 사용자의 요청은 Proxy 기능을 가지는 로드밸런서로 전달된다. 로드밸런서는 도메인 이름, URL 패스, 헤더 필드를 이용해서, 요청을 처리할 호스트로 보낸다. 사용자의 요청을 중계하기 때문에 Proxy 라고 부른다.
  3. 사용자의 요청은 Proxy를 거쳐서 서버로 전송되고 서버는 요청을 처리해서 클라이언트에 보낸다.
Proxy 서버는 애플리케이션과 분리된 상태에서 작동한다. 반면 서비스 메쉬는 각 서비스 인스턴스와 함께 프록시 인스턴스 형태로 실행이 된다. 서비스 인스턴스 옆에서 실행되기 때문에 사이트카(Sidecar)라고 부르기도 한다.

서비스 메쉬 아키텍처

서비스 메쉬 아키텍처를 살펴보자.

 Service Mesh

이 그림은 기본적인 서비스 메시의 개념을 보여준다. 여기에는 A, B, C 세 개의 인스턴스가 있다. 각 인스턴스는 사이드카 프록시와 함께 배치된다. 개별 서비스 인스턴스의 모든 네트워크 트래픽(HTTP, REST, gRPC 등)은 로컬 사이트카 프록시를 통해 적절한 대상으로 흐른다. 따라서 서비스 인스턴스는 다른 서비스 인스턴스를 인식할 필요 없이 "로컬 사이트카 프록시만 알고 있으면"된다. 실제 많은 분산 시스템들이 네트워크와 서비스를 추상화(분리)한다.

데이터 플레인

서비스 메시에서 사이드카 프록시는 아래의 일들을 수행한다. 이들 모든 항목은 데이터 플레인에서 책임진다.

컨트롤 플레인

사이드카 프록시를 이용한 데이터 플레인을 이용해서 서비스와 네트워크를 분리 할 수 있다. 서비스 개발자는 다른 서비스가 어디에 있는지 신경쓸 필요가 없다. 그러나 사이드카 프록시는 개발자를 대신해서 실제로 요청(GET /music/342와 같은)을 음악 서비스 인스턴스로 라우팅하는 방법을 알고 있어야 한다. 또한 로드밸런싱 알고리즘, 타임아웃, 서킷브레이크, 블루그린을 수행하기 위한 정보, 전체 시스템에 대한 인증권한 정보를 가지고 있어야 한다.

서비스 플레인이 위의 모든 작업을 책임진다. 컨트롤 플레인은 일련의 정책과 설정들을 이용해서 사이드카 프록시를 완전한 분산시스템으로 구성한다.

많은 기술자들이 데이터플 레인과 컨트롤 플레인의 분리된 개념을 혼동하는데, 데이터 플레인은 서비스 인스턴스와 직접 붙어있기 때문에 비교적 친숙하지만 컨트롤 플레인은 외부에 있기 때문이다. 개발자들이 만든 네트워크 애플리케이션은 스위치와 라우터와 같은 물리적 네트워크 장치를 통해서 서비스된다. 하지만 개발자들은 네트워크 장치가 어떻게 작동하는지 알 필요가 없다. 네트워크 엔지니어가 알아서 설정해주기 때문이다. 컨트롤 플레인이 하는 일이 바로 네트워크 엔지니어가 하는 일이다. 아래 그림은 사람이 개입하는 컨트롤 플레인을 묘사하고 있다.

 사람이 하는 컨트롤 플레인

여전히 위의 방식은 널리 사용하고 있다. 엔지니어가 스크립팅 도구를 사용해서 서비스 맞춤형 설정을 만들어서 모든 프록시를 배포한다. 지금의 컨트롤 플레인은 아래와 같이 완전히 자동화 한다.

 자동화된 컨트롤 플레인

컨트롤 플레인은 데이터 플레인에 의해서 실행될 정책을 설정하는 것으로 정의 할 수 있다.

컨트롤 플레인과 데이터 플레인 솔류션 들

Istio는 마이크로서비스간 데이터 공유를 제어하는 오픈소스 서비스 메시 플랫폼이다. 기본 프록시로 Envoy를 사용한다. 따라서 Envoy를 데이터 플레인으로 사용하고 Istio는 컨트롤 플레인으로 Envoy를 관리한다. 데이터 플레인과 컨트롤 플레인은 분리될 수 있으므로 Envoy외에도 Linkerd와 NGINX를 Istio에 통합하려는 시도를 하고 있다.

데이터 플레인 영역에서 자주 언급되는 솔류션은 Linkerd와 Envoy다. Envoy는 lift에서 개발한 오픈소스 서비스 프락시 서버로 클라우드 네이티브 환경을 목표로하고 있다.

정리