2. Service Mesh

Service Mesh란?

 

서비스 메시는 애플리케이션의 서비스 간 모든 통신을 처리하는 소프트웨어 계층입니다. 이 계층은 컨테이너화된 마이크로서비스로 구성됩니다. … 서비스 메시는 서비스 간 연결을 관리하기 위해 모니터링, 로깅, 추적, 트래픽 제어와 같은 새로운 기능을 제공합니다. 이러한 기능은 각 서비스의 코드와 독립적이므로 네트워크 경계를 넘어 여러 서비스 관리 시스템에서 작동할 수 있습니다. - aws

 

출처:  nginxstore , Service Mesh의 Control Plane은 Data Plane의 사이드카 프록시에 구성을 배포합니다.

 

 

여기서 key point 는

• 서비스 레벨에서의 모든 통신을 처리
• 모니터링, 로깅, 트래픽 제어
• 서비스의 코드와 독립적(종속성 완화)

로 볼 수 있다.

 

Why Use Service Mesh?

 

마이크로서비스 아키텍처를 사용하면 개발자는 전체 재배포 없이도 각 앱 서비스를 변경할 수 있습니다.

다른 아키텍처의 앱 개발과 달리 개별 마이크로서비스는 자체 도구와 코딩 언어를 선택할 수 있는 유연성을 갖춘 소규모 팀에 의해 구축됩니다.

기본적으로 마이크로서비스는 독립적으로 구축되고, 서로 통신하며, 애플리케이션 전체의 중단으로 확대되지 않고 개별적으로 실패할 수 있습니다.

 

출처:  RedHat  , 서비스 메쉬가 없는 마이크로서비스

 

서비스 간 통신은 마이크로서비스를 가능하게 합니다.

통신을 관리하는 논리는 서비스 메시 계층 없이 각 서비스에 코딩될 수 있습니다.

그러나 마이크로서비스간의 통신이 더욱 복잡해질수록 서비스 메시의 가치는 더욱 커집니다.

마이크로서비스 아키텍처에 구축된 클라우드 네이티브 앱의 경우 서비스 메시는 수많은 개별 서비스를 기능적 애플리케이션으로 구성하는 방법입니다.

그래서 등장한 것이 서비스 매쉬다.

서비스 매쉬는 공통 관심사를 애플리케이션으로부터 분리하고, 인프라 계층으로 옮겼다.

그럼으로 다음과 같은 특징을 가질 수 있게 되었다.

 

Traffic management

• 트래픽 라우팅은 ****서비스 간 트래픽 흐름과 API 호출을 쉽게 제어할 수 있습니다.
• 서비스 수준 속성의 구성을 단순화하고 A/B 테스트, 카나리아 배포, 백분율 기반 트래픽 분할을 통한 단계적 출시와 같은 중요한 작업을 쉽게 설정할 수 있도록 해줍니다.

 

Resilience

• 오류, 지연 및 네트워크 문제의 영향을 완화하는 회로 차단(circuit breaking), 재시도 및 시간 초과와 같은 기능을 제공하여 마이크로서비스 기반 애플리케이션의 전반적인 복원성을 높이는 데 도움이 됩니다.
• 복원력의 궁극적인 목표는 특정 마이크로서비스 인스턴스의 오류나 성능 저하로 인해 전체 분산 시스템의 가동 중지 시간을 초래하는 연쇄 오류가 발생하지 않도록 하는 것입니다.

 

Observability

• 서비스 메시는 4가지 주요 메트릭을 모두 수집하고, 그래픽 대시보드(ex) istio kiali)를 통해 보고 다른 도구에서 사용하기 위해 API를 통해 내보내는 등 메트릭에 액세스하는 기타 추가 방법을 지원합니다.

 

Security

• ****TLS(전송 계층 보안)를 사용하여 포드 간 통신을 보호함으로써 보안을 제공합니다.
  • TLS는 암호화를 사용하여 통신 중인 정보를 다른 사람이 모니터링하거나 변경할 수 없도록 보장합니다.
• 앱 외부와 내부에서 이루어진 요청을 승인 및 인증하고, 검증된 요청만 인스턴스에 전송함으로써 인증 및 권한 부여에 도움을 줍니다.

 

How it Works

 

서비스 매쉬는 크게 2가지 요소로 구성되어 있다.

 

출처:  istio , Istio Architecture

 

데이터 플레인은 서비스 간 통신 역할을 합니다.

서비스 메시는 프록시를 사용하여 모든 네트워크 트래픽을 가로채므로 설정한, 구성에 따라 광범위한 애플리케이션 인식이 가능합니다.

Envoy 프록시는 클러스터에서 시작하는 각 서비스와 함께 배포되거나, VM에서 실행되는 서비스와 함께 실행됩니다.

컨트롤 플레인은 서비스메쉬의 두뇌 역할입니다.

원하는 구성과 서비스를 프록시 서버를 동적으로 프로그래밍하여 규칙이나 환경 변화에 따라 업데이트합니다.

 

사이드카 패턴

 

출처:  msaschool , 사이드카 적용 모습

 

 

Sidecar 방식은 Envoy와 함께 Istio에서 사용하는 방식입니다.

 

Sidecar 배포에서 모든 응용 프로그램 컨테이너에 추가로 Sidecar 컨테이너가 배포됩니다. Sidecar는 응용 프로그램 컨테이너로 들어오거나 나가는 모든 네트워크 트래픽을 처리합니다. 이 방식은 라이브러리와 노드에이전트 방식과 큰 차이점을 가집니다.

 

예를 들어 모든 노드에서 새 에이전트를 실행할 필요 없이 Sidecar를 배포할 수 있으므로(노드 에이전트를 배포하기 위해 인프라 전반에 협업이 필요하지 않음) 동일한 Sidecar의 복사 본을 여러 개 실행합니다. 또한 Linkerd에서 마이크로서비스 그룹에 하나의 Service Mesh만을 사용하던 것과 달리 다른 Service Mesh와 같이 사용할 수 있습니다.

 

Sidecar 방식에서 GKE의 경우, POD 정의에 프록시가 정의됩니다. 일반적으로 1Container 당 1 Sidecar 방식으로 사용되며, 단일 호스트로의 proxy오류 가능성을 제한하며, 동일한 호스트의 단일 호스트에는 영향을 미치지 않습니다.

 

Data flow

   Incoming Request
          |
          v
[ Ingress controller ] 
          |          - cluster 내부로 들어오는 트레픽 제어
          v
     [ Gateway ]  
          |        - Gateway는 메쉬 외부로부터 들어오는 트래픽을 제어합니다.
          v
[ Virtual Service ] 
          |        - Virtual Service는 Gateway로부터 받은 트래픽을 어느 서비스로 라우팅할지 결정합니다.
          v
[ Destination Rule ] 
          |        - Destination Rule은 특정 'destination' 서비스에 대한 트래픽 행동을 세부적으로 정의합니다.
          v
     [ Service ]

• https://mangkyu.tistory.com/307
• https://istio.io/latest/about/service-mesh/
• https://www.msaschool.io/operation/architecture/architecture-two/
• https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh
• https://cloud.google.com/service-mesh/docs/overview?hl=ko
• https://nginxstore.com/blog/kubernetes/service-mesh-란-무엇인가/
• https://www.getambassador.io/blog/service-mesh
• https://www.tibco.com/glossary/what-is-a-service-mesh