Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

Contents

Service mesh

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

  • Service Discovery
  • 로드밸런싱
  • 암호화
  • 인증 및 권한 부여
  • 서킷브레이커 패턴(circuit breaker pattern)
  • Observability
  • Traceability

Proxy와 다른 점

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

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

서비스 메쉬 아키텍처

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

 Service Mesh

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

데이터 플레인

서비스 메시에서 사이드카 프록시는 아래의 일들을 수행한다.
  • Health checking : 업스트림 서비스 인스턴스가 작업 수행이 가능한지를 체크한다.
  • 라우팅 : GET /music/342 REST API를 호출 했을때, 이 요청을 어떤 업스트림 서비스 인스턴스로 보내야 하는지를 결정한다.
  • 로드밸런싱 : 요청을 여러 인스턴스 중 하나로 보내야 한다. 요청이 실패하면, 다른 작동하는 인스턴스로 전송한다.
  • 인증/권한 : 다양한 메커니즘을 이용해서 수신 요청이 인증되었는지 권한을 가지고 있는지 확인한다.
  • 서비스 디스커버리 : 모든 업스트림/백엔드 서비스를 확인하고 이들이 사용 가능한지를 테스트 한다.
  • Observability : 개발자와 운영자가 요청의 흐름을 추적 할 수 있도록 통계, 로깅, 분산추적 데이터를 생성한다.
이들 모든 항목은 데이터 플레인에서 책임진다.

컨트롤 플레인

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

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

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

 사람이 하는 컨트롤 플레인

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

 자동화된 컨트롤 플레인

  • 여전히 사람(엔지니어)은 필요하다. 엔지니어는 전체 시스템을 높은 레벨에서 조망하고 설계한다.
  • Control plane UI : 엔지니어는 UI를 이용해서 시스템을 제어한다. UI는 웹 포털, CLI 혹은 다른 유형의 인터페이스일 수 있다. 엔지니어는 UI를 이용해서 배포를 제어(블루/그린, 트래픽 전환 등), 인증 및 권한 부여하고 랑우팅 테이블 명세서를 작성한다. 기타 전역 설정들과 시간초과, 재시도 횟수, 서킷 브레이크와 같은 로드 밸런서를 설정한다.
  • Worlload scheduler : 서비스는 kubernetes나 Nomad 등의 인프라 위에서 실행된다. 스케쥴러는 서비스가 사이드 카 프록시와 함께 실행되도록 부트 스트랩하는 일을 한다.
  • Service discovery : 스케쥴러가 서비스 인스턴스를 시작 하거나 중지하면 이 정보를 service discovery 시스템에 보고해서, 올바르게 서비스를 찾을 수 있도록 한다.
  • Sicecar proxy configuration API : 사이드카 프록시는 운영자의 개입 없이 시스템 구성요소들의 작동상태를 동적으로 가져온다. 결과적으로 실행중인 모든 서비스 인스턴스와 사이드카 프록시가 전체 시스템에 제대로 녹아들 수 있도록 한다. Envoy의 범용 데이터 플레인 API는 이러한 작동방식을 잘 보여준다.
컨트롤 플레인은 데이터 플레인에 의해서 실행될 정책을 설정하는 것으로 정의 할 수 있다.

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

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

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

정리

  • Kubernetes, istio 기반으로 마이크로서비스 구축해봐야겠다.