istio(이스티오)와 서비스 메시, 프록시

쿠버네이티스와 밀접하게 연관된 istio에 대해 정리 한번 해야겠다 생각만하다가 

이제 서야 정리한다. 

 

일단 istio를 설명하기 전에 

서비스 메시라는것을 우선 알아야 한다. 

 

서비스 메시

애플리케이션 트래픽을 관리, 추적 및 보안성을 강화하기 위해 플랫폼 레이어에 구성되는 네트워크 제어 방법

대표하는 기능은 크게 3가지 

1. 애플리케이션 트래픽 관리 (Traffic Management)

2. 관찰 가능성(observability)

3. 보안

1. 애플리케이션 트래픽 관리

- 트래픽 관리를 위한 라우팅은 더 나은 배포 전략을 가능하게 한다.

- 트래픽 라우팅 규칙을 사용하면 서비스 간의 트래픽 흐름 및 API 호출을 쉽게 제어한다

- 서킷 브레이커, 타임아웃 및 재시도와 같은 구성을 단순화한다

- A/B 테스트, 카나리 배포 및 퍼센트 기반 트래픽 분할 같은 중요한 작업을 쉽게 설정할수 있다. 

 

2. 관찰 가능성(observability)

- 관찰 가능성은 데이터를 기반으로 시스템의 현재 상태를 측정하는 기능

- 서비스 동작의 관찰 가능성의 기초 자료로 활용

- 운영자가 분석을 통해 애플리케이션의 문제를 해결하고 유지 관리하고 최적화

 

3. 보안

- TLS 암호화, 인증, 인가 및 감사(audit) 도구를 제공하여 서비스와 데이터를 보호

- 모든 서비스 간의 통신의 환경은 안전하지 않다(Zero Trust)고 가정

- 애플리케이션 간에 mTLS를 활성화하여 보안을 단순화

 

istio는 이런 서비스 메시의 장점을 가지고 있다. 

istio 를 접하기 전에 Spring 에 Eureka 와 비슷하다고 생각했는데 

이 두개의 아키텍처는 서로 다르다. 

 

Mesh-Agnostic Code(istio/envoy) 

• Mesh-Agnostic Code는 비즈니스 로직에는 Mesh에 관한 코드가 일절 불필요한 형태

Mesh-Aware Code(Eureka)

• Mesh-Aware Code는 서비스 코드 작성 시 Mesh를 이해하고서 부분적으로 수정을 가해야하는 수준

 

Eureka 는 Mesh를 이해하고 수정을 해야하지만 

istio는 비즈니스 로직에 일정 Mesh 에 대한 코드가 필요없다 

 

 

서비스 메시 데이터 플레인, 컨트롤 플레인 두 개 컴포넌트로 구성된다. 

 

데이터 플레인

애플리케이션 사이에 있는 프록시 네트워크로 구성

 

데이터 플레인에 위치한 
프록시는 haproxy 및 NGINX와 마찬가지로 L7 TCP 프록시이다. 

 

L7 프록시란 무엇인가....................! 

L7 프록시가 뭔지 알기 위해서는 osi 7 layer 라는 대학교때 많이 들어본

이 개념부터 시작해야 한다.

 

osi 7 layer 는 네트워크에서 통신이 일어나는 그 일련의 과정들을 7단계로 나눈것이다.

이걸 자주 보고 아무리 봐도.. 외워지지 않는 그녀석 

A-Penguin-Said-That-Nobody-Drinks-Pepsi

이렇게 외우면 쉽다고 하는데 기억 날리가 없다. 

 

7계층 – 응용 계층(Application)

- 사용자와 직접적으로 상호작용한다

- 구글 크롬(Google Chrome), 파이어폭스(Firefox)

 

4계층 – 전송 계층(Transport)

전송 계층은 최종 시스템 및 호스트 간의 데이터 전송 조율을 담당

전송 제어 프로토콜(TCP), 기기의 IP 주소가 여기서 작동

 

보통 우리(?)가 아는 로드밸런싱은 IP와 Port를 구분으로 로드밸런싱을 한다

이 말은 무슨 뜻이냐면 OSI 7계층 중 Layer4의 정보인 IP와 Port를 사용한다.

이 정보를 사용하기 때문에 이름이 L4 스위치이다.

 

다시 위에 써져 있던 프록시 설명을 보면 

L7 프록시라고 쓰여져 있다. 

데이터 플레인에 위치한 
프록시는 haproxy 및 NGINX와 마찬가지로 L7 TCP 프록시

 

L7 Load Balancing 

L7 Load Balancing 도 잠깐 보고 넘어가자면 

Layer 4(TCP와 UDP)를 넘어 Layer 7 프로토콜의 헤더를 분석하여 로드밸런싱

- Layer 7 프로토콜을 통해 사용자 정의 로드밸런싱을 진행한다. 

 

L7 프록시는 L7 레이어를 이용한 프록시다. 

서비스에서 사용하는 핵심 네트워크 프로토콜은 HTTP, HTTP/2, gRPC, Kafka, MongoDB등의

L7프로토콜이다. 

 

L4 프록시로는 다양한 요건을 처리하기 어렵고,

L7기능을 갖춘 프록시의 필요성이 부각되었다. 

 

이러한 이유로 istio는 L7프록시로 네트워크를 제어한다. 

istio를 사용하기 전과 후인데 특이점으로 

Envoy, Istio control plane이 포함되어있는걸 볼수 있다. 

Istio 는 엔보이(Envoy) 서비스를 이용하여 프록시를 구성한다. 

Envoy 가 Istio에서 제공하는 프록시다~~

프록시는 "포워드 프록시" 및 "리버스 프록시" 역할을 모두 수행한다. 

"포워드 프록시" 및 "리버스 프록시" 역할을 모두 수행하면 nginx를 사용해서 

사용하면 되지 왜 굳이 이런것을 사용할까 

왜 이걸 사용하는지 알려면 사이드 카를 알아야 한다. 

사이드카란 또 무엇인가.... 

 

Envoy는 동일한 Kubernetes pod의 Application 서비스에 사이드카로 배치된다.

쿠버네티스 환경에서 레플리카셋(ReplicaSet)이나 디플로이먼트(Deployment)로 배포한 경우 파드가 속한 노드는

지속해서 바뀔 수 있고, 이때 네트워크 정보도 모두 바뀌게 된다.

 

스테이트풀셋(StatefulSets)으로 배포한다면 괜찮지만

HPA(Horizontal Pod Autoscale)나 확장/가용성이 필요한 일반적인 애플리케이션의 배포 형태는

레플리카셋이나 디플로이먼트다.

 

네트워크가 추가되거나 필요한 인증 로직을 구현해서 넣을 곳이 마땅치 않다.

쿠버네티스 환경에서 기존의 리버스 프록시만으로 인증을 적용하는 것은 어렵기 때문에 

사이드카라는 패턴?..정책? 을 사용한다. 

 

Data plane 의 Envoy 를 조금 더 설명하자면

Envoy 는 Mixer에서 정책을 관리하는데 사용할 수 있다. 

모니터링 시스템(Prometheus, Grafana 등)에 보내져 전체 mesh의 동작에 대한 정보를 관리한다. 

 

좀 더 자세하게 살펴보면 Ingress Traffic을

서비스 메시 - 데이터 플레인 proxy 에서 처리하고 Egress traffic 도 처리한다. 

 

보면 Data Plane 말고 Control plane도 있는데 

Data Plane 과 Control plane이 Istio를 구성한다. 

 

컨트롤 플레인 

메시를 작동하는 사람을 위한 인터페이스를 제공하는데

서비스 검색(Discovery), TLS 인증서 발급, 메트릭 집계 등을 포함하고 필요한 컴포넌트들을 제공한다.

사용자가 전체적으로 데이터 플레인의 동작을 수정하고 검사할 수 있도록 API를 제공한다.

• TCP, HTTP1, HTTP2, gRPC protocol 지원
• TLS client certification
• L7 라우팅 지원 및 URL 기반, 버퍼링, 서버간 부하 분산량 조절
• Auto retry / Circuit Breaker 지원 / 다양한 로드밸런싱 기능 제공
• Zipkin을 통한 분산 트랜잭션 성능 측정 제공

 

Zipkin 이란

- OpenTracing Zipkin or Jaeger(예거)을 적용하고 MSA 환경에서 로그를 확인할수 있다