서비스 메시는 이 모든 기능을 애플리케이션 코드 변경이나 의존성 추가를 거의(혹은 전혀) 하지 않고도 서비스 운영자에게 제공한다.
일부 기능에서는 애플리케이션 코드와 약간의 협업이 필요하지만, 크고 복잡한 라이브러리 의존성을 피할 수 있다.
서비스 메시를 사용하면 애플리케이션을 구축하는 데 어떤 애플리케이션 프레임워크나 프로그래밍 언어를 사용했든지 상관없이 이러한 기능들이 일관되고 정확하게 구현되므로, 서비스 팀이 변화를 구현해 전달할 때 빠르고 안전하며 자신감 있게 움직일 수 있게 된다.
1.2. Istio란 무엇인가?
Istio는 구글, IBM, 리프트가 개발한 서비스 메시를 구현하는 대표적인 오픈소스 플랫폼이며, 마이크로서비스 환경에서 통신과 관련된 복잡성을 줄여주는 도구 역할을 수행한다.
Istio 는 그리스어로 '돛'을 의미한다. (k8s 의 경우 항해 용어를 채택하므로, 이에 어울리도록 이스티오 또한 네이밍한 것이라는 이야기가 있다.)
서비스 메시 구조인 데이터 플레인(서비스 프록시), 컨트롤 플레인으로 구성된다.
데이터 플레인: Envoy 프록시를 기반으로 한 서비스 프록시로 구성된다.
서비스 프록시
애플리케이션 옆에 자리 잡고 있다.
애플리케이션 간의 중개자 역할을 하며, 컨트롤 플레인이 전달한 설정에 따라 네트워킹 동작에 영향을 준다.
컨트롤 플레인
최종 사용자/운영자용 API, 프록시용 설정 API, 보안 설정, 정책 선언 등을 제공하는 몇 가지 구성 요소로 이루어져 있다.
Istio는 MSA 또는 서비스 지향 아키텍처 SOA 를 염두에 뒸지만, 그 아키텍처들에만 국한되지는 않으며 설계 상 쿠버네티스, 오픈시프트는 물론 가상머신과 같은 기존 배포 환경 등에서도 사용 가능하다. (배포 플랫폼에 구애받지 않는 관점으로 구성되었다.)
Istio 구조
1.3. 왜 Istio인가?
Istio는 Envoy 프록시를 사용하여 네트워킹을 구현하여, 종속성에 영향을 받지 않는다.
Envoy는 구글 IBM 리프트(Lyft) 가 중심이 되어 개발하고 있는 오픈소스 소프트웨어이며, C++로 구현된 고성능 Proxy이다.
중앙에서 설정 관리가 잘 된다. 즉, 원격에서 동적인 설정 관리가 유연하며, 풍부한 API 가 지원된다.
Nginx Ingress 와 같은 경우 컨테이너 설정을 동적으로 바꿀 수 없다. (컨테이너,프로세스 등 재기동 필요)
애플리케이션 종속성에 영향을 받지 않으며 애플리케이션의 모든 트래픽을 프록시(L7)로 가로채서 제공한다.
Istio 의 Envoy 프록시를 통해 서비스간 네트워킹 이슈를 애플리케이션에서 인프라로 이동시킬 수 있다.
언어나 프레임워크에 명시적 의존성 없이도 재시도, 타임아웃, 서킷 브레이커, 클라이언트 측 로드 밸런싱, 서비스 디스커버리, 메트릭 수집 등의 네트워크 관심사에 대해 구현하였다.
서킷 브레이커, 시간 초과, 재시도, 서비스 디스커버리, 로드 밸런싱 등을 위해 언어별 복원력 라이브러리가 필요하지 않다. 또한, 메트릭 수집, 분산 트레이싱, 접근 제어도 처리한다.
초당 요청 수, 실패 횟수, 서킷 브레이커 이벤트와 같은 여러 애플리케이션 네트워킹 메트릭을 수집하여 관찰 가능성(Observability)를 제공한다.
Istio는 기본적으로 보안이 활성화되어 있어 아키텍처 요구 사항을 충족한다.
애플리케이션 네트워킹 양 끝단을 제어하므로 서비스 트래픽을 투명하게 암호화할 수 있다. (제로트러스트에 적합)
서비스가 mTLS를 바로 사용할 수 있도록 키 및 인증서 발급, 설치, 로테이션을 관리할 수 있다.
워크로드에 ID를 부여하고 이를 인증서에 포함시킬 수 있으며, ID를 사용해 강력한 접근 제어 정책을 구현할 수 있다.
Istio를 사용하면 할당량, 속도 제한, 조직 정책을 구현할 수 있다.
정책 강제 policy enforcement 를 사용하면, 어떤 서비스가 서로 상호작용할 수 있고 어떤 서비스가 상호작용할수 없는지에 대해 아주 세밀한 규칙을 만들 수 있다.
Istio로 Kubernetes 환경에서 다양한 워크로드를 효과적으로 관리할 수 있다.
2. Istio 핵심 기능 및 아키텍처
2.1. Istio의 주요 기능
트래픽 관리: Istio는 서비스 간 트래픽의 라우팅, 로드 밸런싱, 복원력을 제공한다. 운영자는 트래픽 흐름을 제어하고 카나리 릴리즈, 다크 런치, 단계적 롤아웃, A/B 스타일 테스트와 같은 세밀한 릴리즈 구현이 가능하다.
보안: Istio는 서비스 간 통신 암호화를 위한 상호 TLS(mTLS)를 제공하며, 인증 및 권한 부여를 통해 강력한 보안 환경을 구축한다. 키 및 인증서 발급과 로테이션을 자동으로 관리한다. 이스티오는 서비스가 mTLS를 바로 사용할 수 있도록 키 및 인증서 발급, 설치, 로테이션을 관리한다.
관측 가능성(Observability): Istio는 원격 측정, 로깅 및 모니터링 기능을 내장하여 서비스 상태를 시각적으로 확인하게 해준다. 메트릭과 분산 트레이싱 데이터를 수집하고 병목 현상이나 성능 문제를 분석할 수 있다.
2.2. Istio 아키텍처
Istio는 크게 데이터 플레인(Data Plane)과 컨트롤 플레인(Control Plane)으로 구성된다.
파일럿(Pilot): Traffic Management, and Service Discovery
Traffic Management: 프록시 라우팅 규칙 관리. istio의 각종 Traffic Management API(VirtualService, DestinationRule, Gateways, ServiceEntry, Sidecar)가 동작할 수 있도록 Envoy에 주입
Service Discovery: 서비스 디스커버리와 로드밸런싱 설정 제공. K8s 클러스터와 Istio 서비스 매시에 새로운 인스턴스가 Deploy 될 시 해당 정보를 반영한 새로운 Envoy 규칙을 각 Envoy Proxy에 전파
갤리(Galley): Configuration Management
Istio와 쿠버네티스(TLS 연결 및 파일럿에 필요한 설정)를 연결해 주며, 서비스 메시 구성 데이터를 검증하고 변환(VirtualService, DestinationRule 같이 K8s 리소스로 정의한 것들을 읽어서 검증하고, Envoy Proxy가 이해 가능한 형태로 변환)
시타델(Citadel): Certificate Generation
보안 기능을 담당하며, TLS 인증서 발급 및 관리를 통해 서비스 간 통신의 암호화 수행 (istio 워크로드 사이에 mTLS 통신을 세팅 하기 위해서 Certificate를 싸인하고 주입)
2.3. Envoy 프록시와 사이드카 패턴
Envoy는 Istio의 핵심 구성 요소로, 고성능 애플리케이션 L4/7 Proxy이다.
네트워크의 투명성을 목표, 다양한 필터체인 지원(L3/L4, HTTP L7), 동적 configuration API 제공, api 기반 hot reload 제공한다.
Envoy의 각 애플리케이션 인스턴스와 함께 배포되는 Sidecar 패턴은 다음과 같은 장점을 제공한다.
애플리케이션 코드 변경 없이 네트워크 기능 구현
추가 홉 없이 트래픽 처리
분산 트레이싱 스팬(span) 수집으로 병목 현상 분석 가능
Envoy는 리프트에서 SOA 인프라의 일부로 개발됐으며, 언어나 프레임워크에 명시적 의존성 없이도 재시도, 타임아웃, 서킷 브레이커, 클라이언트 측 로드 밸런싱, 서비스 디스커버리, 보안, 메트릭 수집 등의 네트워크 관심사를 구현할 수 있다.
엔보이를 사용하면 서비스 간에 어떤 일이 일어나고 있는지 자동으로 알 수 있게 되는데, 바로 여기서 예상치 못한 복잡성을 많이 발견하게 된다.
엔보이 프록시는 서비스 아키텍처에서 공통적인 서비스 간 신뢰성과 관찰 가능성 문제를 해결할 수 있는 기반이며, 이 기반을 토대로 이런 문제를 애플리케이션에서 인프라로 이동시킬수 있다.
Istio 구성요소와 envoy
컨트롤 플레인(istiod) - ADS 를 이용한 Configuration 동기화 - 데이터 플레인(istio-proxy → envoy)
