istio와 envoy 란

이 글은 2020년에 제 소유의 네이버 블로그에 있던 글을 리호스팅한 글입니다.

개요

Microservice 아키텍처를 구성하는 각각의 Microservice들은 Microservice들 간 통신을 위해 각 서비스를 식별(Discovery)하고, 경로를 파악(Routing)하며, 로드 발란싱(Load Balancing)을 하고 전체 서비스의 장애 전파를 차단(Circuit Break)하는 역할이 한데, 이러한 기능을 통합해 하나의 계층으로 만든 것이 Service Mesh이다.
Service Mesh는 그 구성방식에 따라 3가지 종류가 있다. (이전 포스팅의 Service Mesh 부분 참조)

Microservice Architecture 컴포넌트

이 포스팅에서는 3가지 타입의 Service Mesh 중 플랫폼에서 관리자가 임의로 그 기능을 설정(사이드카 인젝션으로 제어)해 제어하는 Mesh-Agnostic Code 방식의 Service Mesh 방법인 istio와 envoy proxy에 대해 알아본다.

istio

istio는 IBM, Redhat, VMware, Google등이 참여해 개발한 Service Mesh(서비스 매쉬) 구현을 위한 오픈소스 솔루션이다. istio는 마이크로서비스 간의 모든 네트워크 통신을 담당 할 수 있는 프록시인 Envoy를 사이드카 패턴으로 마이크로 서비스들에 배포한 다음, 프록시들의 설정 값 저장 및 관리/감독을 수행하고, 프록시들에 설정 값을 전달하는 컨트롤러 역할을 수행한다.

isto 아키텍처

isto는 Data Plan과 Control Plan으로 나뉘어 있으며 각 아키텍처는 아래의 그림과 같다.

istio Architecture( https://istio.io/latest/docs/ops/deployment/architecture/ )

Data Plane

Data Plane은 Microservice와 Proxy(e.g. Envoy)로 결합된 서비스들로 구성되어 있으며 Microservice에 배포되어 서비스로 들어오고 나가는 모든 트래픽을 통제한다. Data Plane의 Envoy Proxy를 통해서 서비스를 호출할 경우에는 호출하는 서비스의 IP주소는 파일럿(Pilot)에 저장된 앤드포인트 정보를 활용하게 된다.
<Envoy Proxy>
Envoy Proxy는 C++로 개발된 고성능 프록시 사이드카로서 service mesh의 모든 서비스에 대한 inbound/outbound 트래픽을 처리한다. Envoy Proxy는 다음과 같은 기능을 담당하고 있다.

• TCP, HTTP1, HTTP2, gRPC protocol 지원
• TLS client certification
• L7 라우팅 지원 및 URL 기반, 버퍼링, 서버간 부하 분산량 조절
• Auto retry / Circuit Breaker 지원 / 다양한 로드밸런싱 기능 제공
• Zipkin을 통한 분산 트랜잭션 성능 측정 제공
• Dynamic configuration 지원, 중앙 레지스트리에 설정 및 설정 정보를 동적으로 읽어옴
• MongoDB에 대한 L7 라우팅 기능

Envoy는 동일한 Kubernetes pod의 Application 서비스에 사이드카로 배치되며 이를 통해 Istio는 트래픽 동작에 대한 데이터를 attribute으로 추출 할 수 있고 Mixer에서 정책을 관리하는데 사용할 수 있으며, 모니터링 시스템(Prometheus, Grafana 등)에 보내져 전체 mesh의 동작에 대한 정보를 관리할 수 있다.

Control Plane

Control Plan은 Data Plan을 컨트롤하는 부분으로써 Mixer, pilot, citadel, galley(istio-1.4.0까지는 4개의 영역으로 되어 있었으나 istio-1.5.0부터는 istiod하나로 통합)로 구성되어 있습니다.
Mixer

• Mixer는 서비스 매쉬 엑세스 컨트롤 및 정책 관리 수행. Envoy와 다른 서비스에서 모니터링 지표 수집(서비스 응답시간, 평균 처리량 등)

Pilot

• Envoy 설정 관리를 수행하는 모듈. Envoy가 호출하는 서비스의 주소를 얻을 수 있는 서비스 디스커버리(Service Discovery) 기능을 제공
• 서비스 트래픽 라우팅 기능 제공(서비스에서 서비스로 호출하는 경로를 컨트롤)
• 서비스 안정성을 위해 서비스 간 호출 시 재시도(retry), 서킷브레이커(circuit breaker), timeout 등의 기능 제공

Citadel

• 보안 관련 기능을 수행하는 모듈. 사용자 인증(Authentication), 인가(Authorization)을 통한 서비스/앤드유저 간 인증 강화
• TLS(SSL)을 이용한 통신 암호화 및 인증서(Certifiation) 관리

Galley(갤리)

• istio의 구성 및 설정 검증
• 배포 관리 수행

* istiod(istio-1.5.0의 Control Plane): istio-1.5.0이상 부터 제공되는 Control Plane의 통합 서비스(Mixer, Citadel, Pilot, Galley)로써 istiod는 서비스 디스커버리, 설정 관리, 인증관리 역할을 수행한다.

Mesh-Agnostic Code(istio/envoy) vs Mesh-Aware Code(Eureka) 아키텍처 비교

Serivce Mesh를 구성하는 가장 많이 사용되는 두가지 방법인 Proxy를 Side Car형식으로 이용하는 Mesh-Agnostic Code(istio/envoy) 방식과 Spring Cloud Eureka와 같이 프로그램 코드로 Service Mesh를 구성하는 Mesh-Aware Code 방식이 아키텍처적으로 어떻게 다른지 아래 그림을 보고 비교 할 수 있다.

Mesh-Agnostic Code(istio/envoy) 기반 MSA Service Mesh 구성

vs

Mesh-Aware Code(Eureka) 기반 Service Mesh 구현

위 원본은 아래의 링크에서 참조하실 수 있다.

How to set up JHipster microservices with Istio service mesh on Kubernetes

끝