서비스 메쉬(Service Mesh) 란?
Istio는 서비스 메쉬(Service Mesh)를 구현할 수 있는 오픈소스이다.
서비스 메쉬(Service Mesh)란 API 등을 사용하여 마이크로 서비스 간 통신을 안전하고, 빠르고, 신뢰할 수 있게 만들기 위해 설계된 전용 인프라 계층이다. 서비스 메쉬는 보통 Application 서비스에 경량화 프록시(Proxy)를 사이드카(sidecar) 방식으로 배치하여 서비스 간 통신을 제어하며, Service Discovery, Load Balancing, Dynamic Request Routing, Circuit Breacking, Retry and Timeout, TLS, Distributed Tracing, Metric 수집, Access Control, A/B Testing기능 등을 지원한다.
그렇다면 서비스 메쉬는 왜 필요할까? 시스템의 규모에 따라 다르지만, MSA 시스템에서 수십개의 마이크로 서비스가 동작할 수 있고 그보다 많은 인스턴스들이 동작할 수 있기 때문에 관리하기가 매우 복잡하다. 또한 인스턴스가 수행되는 네트워크 간의 레이턴시, 신뢰성, 안전성 등을 보장할 수도 없다. 이러한 문제점들은 어플리케이션 계층에서 해결할 수도 있지만(예를 들면 Hystrix, Resilience4j 등을 활용한 Circuit Breaker 기능 추가), 그렇게 되면 Application 언어 및 런타임에 종속성이 생기고, 기능 변경 등을 할 때마다 비용이 발생한다.
그렇기 때문에 마이크로 서비스 운영할 때에는 별도의 소스 수정이 필요없이 인프라 레벨에서 안정적으로 관리할 수 있는 서비스 메쉬가 필요하다.
Istio 란?
Istio는 서비스 매쉬(Service Mesh)를 구현할 수 있는 오픈소스 솔루션이다.
Istio를 사용하면 서비스 코드 변경 없이 로드밸런싱, 서비스 간 인증, 모니터링 등을 적용하여 마이크로 서비스를 쉽게 관리할 수 있다.
마이크로 서비스 간의 모든 네트워크 통신을 담당할 수 있는 프록시인 Envoy를 사이드카 패턴으로 마이크로 서비스들에 배포한 다음, 프록시들의 설정값 저장 및 관리/감독을 수행하고, 프록시들에 설정값을 전달하는 컨트롤러 역할을 수행한다.
각각의 마이크로 서비스에 사이드카 패턴으로 배포된 Envoy 프록시를 데이타 플레인(Data Plane)이라고 하고, 데이타 플레인을 컨트롤 하는 부분은 컨트롤 플레인(Control Plane)이라고 한다.
※ 쿠버네티스 환경에서 Istio를 도입하면 복잡성을 줄이고 어플리케이션들의 네트워크 연결을 쉽게 설정할 수 있도록 지원하는 기술
Istio 구조
Istio 구성요소
Data Plane : MicroService와 함께 Envoy를 'sidecar' 형식으로 배포하여 Envoy를 통해 돌아다니는 트래픽을 통제
Control Plane : Envoy Proxy의 Tarffic들을 관리하고 설정
위의 구조에서 보면 크게는 Data plane과 Control Plane으로 볼 수 있다. 그 아래에 이 전에는 구분되어 있던 Pilot, Citadel, Galley 영역이 istiod로 통합되어 있는 것을 확인 할 수 있는데 각 기능은 아래와 같다.
Pilot : Envoy 설정 관리를 수행하는 모듈이다. Envoy가 호출하는 서비스의 주소를 얻을 수 있는 서비스 디스커버리 기능, 서비스에서 서비스로 호출하는 경로를 컨트롤하는 서비스 트래픽 라우팅 기능 제공. 서비스 안정성을 위해 서비스 간 호출 시 재시도와 서킷브레이커 및 타임아웃 등의 기능을 제공한다. 또한 Pilot 에서 Envoy의 설정을 추상화시켜두어 Istio는 하나의 설정으로 Kubernetes, consol, nomad 등의 다양한 환경에서 사용 할 수 있게 된다.
Citadel : 보안 관련 기능을 수행하는 모듈이다. 내장된 인증 방식을 이용하여 서비스와 서비스, 엔드포인트유저와 엔드포인트유저 사이의 인증을 강화하거나, 서비스에 접근 가능한 권한을 제어 할 수 있게 된다.
Galley : Istio의 구성 관리 서비스를 제공한다.
Envoy : L7 Proxy로 Nginx나 HA Proxy를 많이 사용하는데, 서비스 메시(istio) 구성에서는 Envoy를 L7 Proxy 용도로 많이 사용한다. Envoy를 독립적으로 설치할 수 있는데, Envoy를 Istio가 매핑해서 관리하는 방식이기 때문이다.
Envoy 기능
Dynamic Service Discovery, Load Balancing, TLS Termination, Circuit Breaker, Timeout 등의 기능을 지원
Envoy 모듈
DownStream : Ingress 트래픽
UpStream : Egress 트래픽(Envoy 입장에서는 Service쪽이 Egress)
Cluster : Envoy가 요청을 리다이렉트 해줄 백 단의 서비스 엔드포인트 집합
Listener : IP/Port 바인딩을 담당하고 새로운 TCP 연결/UDP 데이터그램 연결을 수락
router : Listener를 거쳐 받아들인 DownStream 요청을 어디로 보낼지 정의
filter : 요청을 처리하기 위한 일련의 파이프라인.
filter chain : 필터의 집합
Istio 주요 기능
트래픽 관리(Traffic Management)
Istio의 간편한 규칙(Rule) 설정과 트래픽 라우팅(Traffic Routing) 기능을 통해 서비스 간의 트래픽 흐름과 API 호출을 제어할 수 있다. 또한 서킷 브레이커(Circuit Breaker), 타임아웃(Timeout), 재시도(Retry) 기능과 같은 서비스 레벨의 속성 구성을 단순화하고, 백분율 기반으로 트래픽을 분할하여 A/B Test, Canary Rollout, 단계적(Staged) Rollout 과 같은 작업을 쉽게 설정할 수 있다.
트래픽에 대한 더 나은 가시성과 독창적인 장애 복구 기능을 통해 문제가 발생하기 전에 문제를 찾고, 서비스 호출을 더욱 안정적으로 만들고, 어떤 상황에서든 네트워크를 더욱 안정적으로 만들 수 있다(트래픽 관리 개념 가이드)
보안(Security)
Istio의 보안기능을 통해 개발자는 어플리케이션 레벨의 보안에 보다 더 집중할 수 있다. Istio는 기본적인 보안 통신 채널을 제공하며, 대규모 서비스 통신의 인증(Authentication), 권한부여(Authorization), 암호화(Encryption) 등을 관리한다. Istio를 사용하면 기본적으로 서비스 통신은 보호되기 때문에, 다양한 프로토콜이나 런타임에서 어플리케이션 변경을 거의 하지 않고 일관된 정책을 시행할 수 있다. Istio는 플랫폼에 독립적이지만 쿠버네티스 네트워크 정책과 함께 사용하면 파드(pod)간 혹은 서비스(Service)간 통신을 보호하는 기능 등의 다양한 이점이 있다(보안 개념 가이드)
관찰 가능성(Observability)
Istio의 강력한 트레이싱(Tracing), 모니터링(Monitoring), 로깅(Logging) 기능으로 서비스 매쉬에 배포된 서비스들에 대해 더욱 자세히 파악할 수 있다. Istio의 모니터링 기능을 통해 서비스 성능이 업스트림/다운스트림에 어떤 영향을 끼치는지 파악할 수 있다. 또한 맞춤형 대쉬보드를 통해 모든 서비스 성능 대한 가시성 확인 및 성능이 다른 프로세스들에 미치는 영향 등을 확인 할 수 있다.
플랫폼 지원(Platform support )
Istio는 플랫폼에 독립적이며 클라우드, On-Premise, Kubernetes, Mesos 등을 포함한 다양한 환경에서 실행되도록 설계되었다. Istio는 Kubernetes에 배포하거나 Consul을 사용하여 Nomad에 배포할 수 있다.
통합과 사용자정의(Integration and Customization)
Istio의 구성 요소들은 확장 및 커스터마이징을 통해서 ACL, 로깅, 모니터링, 할당량, 감사 등를 위한 기존 솔루션들과 통합될 수 있다.
[참고]
- https://twofootdog.tistory.com/78
- https://velog.io/@beryl/Istio-%EA%B0%9C%EB%85%90
- https://isn-t.tistory.com/43#Modules%--in%--Envoy
- https://well-made-codestory.tistory.com/29
'Kubernetes' 카테고리의 다른 글
[Kubernetes] taint&toleraton, cordon&drain (0) | 2023.01.27 |
---|---|
[Kubernetes] Pod Scheduling (1) | 2023.01.26 |
[Kubernetes] Secret (0) | 2022.12.21 |
[Kubernetes] ConfigMap (0) | 2022.12.20 |
[Kubernetes] kubernetes Canary Deployment (0) | 2022.12.17 |