Istio

기본적으로 마이크로 서비스를 하게 되면 여러가지 문제가 발생하게 되는데, 각 서비스들에서 장애가 생기면 어디서, 어떤이유로 문제가 발생했는지 찾아 내기 어렵다.
이런 문제를 해결하기위한 방법으로 마이크로 서비스 아키텍쳐 패턴들이 있고, 해결하기 위한 방법으로 istio가 사용되기도 한다.

서비스 메시가 필요한 이유?

• 마이크로서비스 네트워킹 문제를 해결하기 위한 분산 시스템

서비스 메시 구축 목표?

• 모든 서비스 트래픽을 능동적으로 모니터링하는 통합 플랫폼 확보
• 내결함성, 버시스 보안, 애플리케이션 모니터링 문제 해결
• 네트워킹, 모니터링, 추적, 로깅이 동작
• 네트워킹은 라우팅, 로드 밸런싱, 인증, 권한 부여, 상태 관찰

서비스 매쉬

• 서비스간 호출시 프록시가 없는 상황
  

• 서비스간 호출시 프록시가 있는 상황
  

프록시가 있는경우 서비스로 들어오거나 나가는 트래픽을 네트워크 단에서 모두 통제가 가능하게 되고, 트래픽에 대한 통제를 통해서 마이크로 서비스의 여러가지 문제를 해결할 수 있다.

그러나...이런 프록시들도 많아진다면??
서비스 수에 따라 프록시 수도 증가하기 때문에, 이 프록시에 대한 설정을 하기가 어려워진다.

그리고 설정 정보는 어떻게 관리하는게 좋을까?

• 중앙 집중화된 컨트롤러가 통제하는 구조가 좋을것 같다.

여기서...
Istio는 Envoy proxy를 사용한다.
먼저 istio에 사용되는 envory proxy를 살펴보자. Envoy 프록시는 Lyft사에서 개발되었으면 오픈소스로 공개되어 있다.
주요 특징

• HTTP, TCP, gRPC 프로토콜을 지원
• TLS client certification 지원
• HTTP L7 라우팅 지원을 통한 URL 기반 라우팅, 버퍼링, 서버간 부하 분산량 조절등
• HTTP2 지원
• Auto retry, circuit breaker, 부하량 제한등 다양한 로드밸런싱 기능 제공
• 다양한 통계 추적 기능 제공 및 Zipkin 통합을 통한 MSA 서비스간의 분산 트렌젝션 성능 측정 제공함으로써 서비스에 대한 다양한 가시성 (visibility)을 제공
• Dynamic configuration 지원을 통해서, 중앙 레파지토리에 설정 정보를 동적으로 읽어와서 서버 재시작없이 라우팅 설정 변경이 가능함
• MongoDB 및 AWS Dynamo 에 대한 L7 라우팅 기능 제공

Envoy 아키텍처

• 포트 리스너, 필터(리스터 필터, 네트워크 필터, http 필터)로 구성
  

이를 위해 2가지 구성요소가 있음

데이타 플레인(Data Plane)

• Envoy 프록시들의 설정에 따라 통신을 하는 부분
• 데이타 플레인은 envoy를 서비스 옆에 붙여서 사이드카 형식으로 배포를 해서, 서비스로 들어오고 나가는 트래픽을 envoy를 통해서 통제하게 된다.
• envoy는 서비스에서 서비스로 호출할때 상대편 서비스의 IP 주소를 알아야 하는데, 이를 서비스 디스커버리 (Service discovery : 참고 http://bcho.tistory.com/1252?category=431297 )

컨트롤 플레인(Control Plane)

• Envoy 프록시들에 설정값(정책, 구성, 보안...)을 전달을 하는 부분
• 컨트롤 플레인은 데이타 플레인에 배포된 envoy를 컨트롤 하는 부분으로, 파일럿 (Pilot), 갤리 (Galley), 시타델(Citadel) 3개의 모듈로 구성
• 파일럿 (Pilot)
  • envoy에 대한 설정 관리를 하는 역할을 한다.
  • 서비스들에 대한 엔드포인트 정보는 컨트롤 플레인의 파일럿(Pilot)이라는 컴포넌트에 저장되어 있고, envoy는 이 데이타를 참고하여 엔드포인트(EndPoint)를 알 수 있다.
  • Istio에 유용한 기능중의 하나가 트래픽의 경로를 컨트롤 하는 기능인데, 서비스에서 서비스로 호출하는 경로를 컨트롤 할 수 있다.
  • 비스의 안정성을 제공하기 위해서 서비스간에 호출이 발생할때 재시도(retry), 장애 전파를 막기 위한 써킷 브레이커 (Circuit breaker), Timeout 등의 기능을 제공한다.
• 시타델(Citadel)
  • 시타델은 보안에 관련된 기능을 담당하는 모듈이다. 서비스를 사용하기 위한 사용자 인증 (Authentication)과 인가 (Authorization)을 담당한다.
  • 또한 Istio는 통신을 TLS(SSL)을 이용하여 암호화할 수 있는데, TLS 암호화나 또는 사용자 인증에 필요한 인증서(Certification)을 관리하는 역할을 한다.
• 갤리(Galley)
  • Istio Configuration의 유효성 검사

기능

• 트래픽 통제
  • 트래픽 분할은 서로 다른 버전의 서비스를 배포해놓고, 버전별로 트래픽의 양을 조절할 수 있는 기능이다. 예를 들어 새 버전의 서비스를 배포할때, 기존 버전으로 95%의 트래픽을 보내고, 새 버전으로 5%의 트래픽만 보내서 테스트하는 것이 가능하다. (카날리 테스트)
    
• 서비스간 안정성 제공
  • 헬스체크 및 서비스 디스커버리
    파일럿은 대상 서비스가 여러개의 인스턴스로 구성이 되어 있으면 이를 로드 밸런싱하고, 이 서비스들에 대해서 주기적으로 상태 체크를 하고, 만약에 장애가 난 서비스가 있으면 자동으로 서비스에서 제거한다.
  • Retry,Timeout,Circuit breaker

• 보안

  • 기본적으로 envoy를 통해서 통신하는 모든 트래픽을 자동으로 TLS를 이용해서 암호화한다.
  • 암호화를 위해서 인증서를 사용하는데, 이 인증서는 시타델(Citadel)에 저장되어 있는 인증서를 다운 받아서, 이 인증서를 이용하여 암호화된 TLS 통신을 한다

• 서비스 인증과 인가

  • 서비스간 인증
    서비스간 인증은 인증서를 이용하여 양방향 TLS (Mutual TLS) 인증을 이용하여, 서비스가 서로를 식별하고 인증한다.
  • 서비스와 사용자간 인증
    서비스간 인증뿐 아니라, 엔드 유저 즉 사용자 클라이언트를 인증할 수 있는 기능인데, JWT 토큰을 이용해서 서비스에 접근할 수 있는 클라이언트를 인증할 수 있다.
  • 인가를 통한 권한 통제 (Authorization)
    인증뿐만 아니라, 서비스에 대한 접근 권한을 통제 (Authorization)이 가능하다. 기본적으로 역할 기반의 권한 인증 (RBAC : Role based authorization control)을 지원

컴포넌트

• Envoy 필터 : Envoy 프록시 관련 필터를 정의
• Gateway : 서비스 메시의 입구에서 특정 포트로 외부에서의 연결을 수신한 다음 메시 내부에 트래픽을 분산시키는 로드 밸런서
• Virtual Service : 서비스가 다른 호스트를 호출할때 사용되는 일련의 트래픽 규칙을 정의
• Destination Rule : 로드 밸런싱, 연결 풀 크기 등과 같은 기본 구성
• Service Entries : 서비스의 주소, 프로토콜, 포트 등과 같은 기본 세부 사항 구성, 서비스 메시 외부에 서비스가 있을때 유용함
• Policy : 서비스에 관한 트래픽 속도 제한, 헤더 다시 쓰기, 블랙리스트 작성, 서비스 엑세스 화이트리스트 같은 규칙을 정의

https://m.blog.naver.com/horajjan/221937844747

모니터링
마이크로 서비스에서 문제점중의 하나는 서비스가 많아 지면서 어떤 서비스가 어떤 서비스를 부르는지 의존성을 알기가 어렵고, 각 서비스를 개별적으로 모니터링 하기가 어렵다는 문제가 있다. Istio는 네트워크 트래픽을 모니터링함으로써, 서비스간에 호출 관계가 어떻게 되고, 서비스의 응답 시간, 처리량등의 다양한 지표를 수집하여 모니터링할 수 있다.

• Grafana : 서비스의 Metric정보를 Graph로 보여줌
• Kiali : 서비스간 관계 및 트래픽 애니메이션, 처리량, 정상 응답 등를 보여줌
• Zipkin,Jaeger : 데이터 Tracing 정보를 보여줌

https://journes.tistory.com/60