[GKE] Service Mesh Architecture과 Istio

Anthos Service Mesh가 어떤 도움이 되나요?

Anthos Service Mesh를 사용하면 Anthos가 테스트하고 지원하는 Istio 배포판으로 Google의 전적인 지원을 통해 Google Cloud 또는 VMware용 Anthos 클러스터에서 서비스 메시를 만들고 배포할 수 있습니다. 또한 Anthos Service Mesh를 Google Kubernetes Engine(GKE)에서 사용하기 위한 권장 설정이 지정되어 있는 구성 프로필과 VMware용 Anthos 클러스터를 위해 설계된 다른 프로필을 제공합니다

 

메시의 GKE 클러스터 내 HTTP 트래픽의 서비스 측정항목 및 로그는 Google Cloud에 자동으로 수집됩니다.

서비스 메쉬

애플리케이션의 다양한 부분들이 서로 데이터를 공유하는 방식을 제어 하는 방법입니다.

애플리케이션에 구축된 전용인프라 계층으로 이루어져 있습니다. 이러한 인프라 계층은 서로 다른 애플리케이션 부분이 얼마나 원활하게 상호작용 하는지를 기록할 수 있으므로 더욱 손쉽게 커뮤니케이션을 최적화하고 애플리케이션 확장에 따른 다운 타임을 방지할 수 있습니다.

하나의 비즈니스를 이룬 다양한 애플리케이션들은 각각 특정한 비즈니스 기능을 수행하는 서비스 네트워크로 분류됩니다. 기능을 실행하기 위해 서비스는 여러 개의 다른 서비스들로부터 데이터를 요청해야 할 수 있습니다. 하지만 하나의 애플리케이션이 일부 서비스에 요청을 과도하게 한다면 서비스 에러가 나올수 있습니다. 이러한 경우 한 서비스에서 다음 서비스로 요청을 전송하여 모든 구성 요소의 작동 방식을 최적화하는 서비스 메쉬를 도입힙니다.

작동 방법

아키텍처 내의 애플리케이션에는 요청이 들어오면 User의 요청에서부터 요청을 처리하기 위한 엔드포인트까지 전달되는 방식으로 지정하는 규칙이 필요합니다. 하지만 서비스 메쉬에는 이러한 규칙이 필요없이 서비스와 서비스의 통신을 제어하는 로직을 가지고 인프라 계층을 추상화 합니다.

이를 위해 서비스 메쉬는 네트워크 프록시의 배열로서 애플리케이션에 구축됩니다.

서비스 메쉬에서는 요청이 자체 인프라 계층의 프록시를 통해 마이크로서비스 간에 라우팅됩니다. 이러한 이유로 서비스 메쉬를 구성하는 개별 프록시는 서비스 내부가 아니라 각 서비스와 함께 실행되므로 sidercar라고 합니다.

각 서비스에서 분리된 이러한 sidercar 프록시 들이 모여 메쉬 네트워크를 형성합니다.

sidercar 프록시는 마이크로서비스와 같이 위치하며 프록시 역할도 동시하게 하게됩니다. 이러한 sidercar들이 모여 메쉬네트워크를 형성합니다.

Mesh Network 보완

메쉬 프록시로 다른 서비스에 대한 라우팅 서비스를 제공할수있고 트래픽을 네트워크단에서 통제할 수 있게 되었습니다. 하지만 다양한 기능을 수행하기에는 기존 TCP 기반의 proxy로는 제한이 있습니다

그래서 service mesh의 통신은 sidercar로 배치된 경량화되고 L7 계층기반의 proxy를 사용하게 됩니다.

프록시를 사용해서 트래픽을 통제할 수 있지만 서비스가 거대해짐에 따라 프록시 수도 증가하게 됩니다. 이러한 점을 보완하기 위해 각 프록시에 대한 설정정보를 중앙집중화된 컨트롤러가 통제할 수 있게 설계되었습니다.

• Data Plane : 프록시들로 이루어져 트래픽을 설정값에 따라 컨트롤하는 부분
• Control Plane: 프록시들에 설정값을 전달하고 관리하는 컨트롤러 역할

이러한 점을 이용하여 Istio를 보겠습니다.

Istio [Deprecated]

Data Plane의 메인 프록시로 Envoy proxy를 사용하며 이를 컨트롤 해주는 Control Plane의 오픈소스 솔류션 Istio입니다.

Istio를 사용하면 서비스 코드 변경없이 로드밸렁싱, 서비스 간 인증, 모니터링 등을 적용하여 마이크로 서비스를 쉽게 관리할 수 있습니다.

마이크로 서비스 간의 모든 네트워크 통신을 담당할 수 있는 프록시인 Envoy를 사이드카 패턴으로 마이크로 서비스들에 배포한 다음, 프록시들의 설정값 저장 및 관리/감독을 수행하고, 프록시들에 설정값을 전달하는 컨트롤러 역할을 수행합니다.

Istio로 구성된 서비스 메쉬

Istio 구성요소

Data Plane

Envoy Proxy 세트로 구성되어있으며 사이트카 방식으로 각각의 마이크로 서비스에 배포되어 서비스로 들어오고 나가는 모든 트래픽을 통제하게 됩니다. Envoy를 통해서 서비스를 호출할 때 호출하는 서비스의 IP 주소는 파일럿Pilot에 저장된 엔드포인트 정보를 활용하게 됩니다.

Control Plane

Data Plane인 Envoy를 컨트롤하는 부분입니다.

구성 모듈

• Istio 1.4 버전 이하

이름설명

Mixer	서비스 메쉬 액세스 컨트롤 및 정책 관리 수행. Envoy와 다른 서비스에서 모니터링 지표 수집
Pilot	Envoy 설정 관리를 수행하는 모듈. Envoy가 호출하는 서비스의 주소를 얻을 수 있는 Service Discovery 기능을 제공합니다. 서비스 안정성을 위해 서비스 간 호출시 재시고, circuit Breaker, timeout 등의 기능 제공
Citadel	보안 관련 기능을 수행하는 모듈. Authentication,Authorication을 통한 서비스/엔드유저 간 인증강화 TLS를 이용한 통신 암호화 및 Certification 관리
Galley	Istio의 구성 및 설정 검증. 배포 관리 수행

• Istio 1.5 이상

통합 컨트롤 플레인인 istiod는 Service Discovery, Configuration Management,Certificate Management 등을 수행 합니다.

- 트래픽 동작을 제어하는 라우팅 규칙을 Envoy 전용 설정으로 변환하고, 마이크로 서비스에 사이트카 방식으로 Envoy를 배포
- Envoy 설정 변경(Istio의 Traffic Management API 활용)을 통한 서비스 메시 트래픽 세부 제어
- 내장된 identity나 자격증관리(Credential Management)를 통해 강력한 서비스 간 인증 및 사용자 인증 기능을 지원
- 인증기관(Certificate Authority. CA) 의 역할 수행. 데이터 플레인에서 안정한 mTLS통신을 허용하는 인증서를 생성

👀 참고 문서

❕ Red Hat Docs - what is a service mesh

❕ GRU - Service Mesh Architecture & Istio를 알아보자

❕ 두발로걷는개의 발자국 - Istio란 무엇인가?