Istio Kiali 사용법 알아봅시다.

 

1탄 Istio Kiali 사용법 알아봅시다.

2탄 Jaeger Tracing: 초보자를 위한 친절한 가이드

Service Mesh 란?

서비스 메시는 기존의 모놀리식 워크로드를 현대화하고 서비스 간의 통신을 제어하고 관리할 수 있도록 하는 데 특화된
마이크로서비스를 위한 인프라 계층입니다.

기존의 서비스 아키텍처의 호출이 직접 호출 방식이었다면, 서비스 메시에서의 호출은 자체 인프라 계층의 Proxy를 통해 이뤄지게 됩니다. 서비스 메시를 구성하는 개별 proxy는 서비스 내부가 아니라 각 서비스와 함께 실행되므로 'sidecar'라고도 합니다. 각 서비스에서 분리된 이러한 sidecar proxy들이 모여서 Mesh Network를 형성합니다.

 

MSA 환경에서 요구되면서 이를 구현하기 위한 수단으로 서비스 메시 구성을 돕는 도구들이 떠오르기 시작했으며,

istio는 쿠버네티스 기반의 운영 환경을 가지고 있으며, 기존 VM이나 물리서버 단위에서는 MSA에 비해 관리 포인트가

많지 않았다.

100대의 물리 서버에 애플리케이션을 설치했다면 100대의 서버를 모니터링 했지만, 한 서버당 마이크로서비스 20개로

쪼개졌다면 모니터링 대상이 2000개로 늘어나면서 MSA 단위에서 서비스간 연계나 문제 발생시 장애포인트를
찾기가 쉽지 않다.

Service Mesh 왜 필요한가?

 

컨테이너 오케스트레이터 지금 많이 쓰고 있는 Kubernetes가 이미 존재합니다.

하지만 또 다른 인프라스트럭처 계층이 필요한 이유는 일반적으로 마이크로서비스든가 컨테이너 메인 스트림을 통해 컨테이너 오케스트레이터는 클러스터에 필요한 많은 것들을 제공합니다.

주로 인프라 수준의 스케줄링, 헬스 체크에 중점을 두지만 충족시키지 못하는 요구 사항은 마이크로서비스가 구현하도록 남겨둡니다. 서비스메시는 컨테이너 오케스트레이터 위에 별도의 계층으로 배포해 서비스 간 통신을 안전하고 빠르며 안정적으로 만드는 전용 인프라 계층입니다. 

 

kiail, jaeger, prometheus 

 

Data plane 구성요소는 istio의 Proxy를 담당하는 Envoy가 있습니다. Envoy를 통해 서비스에 대한 모든 인바운드 아웃바운드 트래픽을 중재합니다. 이를 통해서 모니터링 시스템(kiail, jaeger, prometheus)으로 전송해 전체 메시의 행동에 대한 정보를 제공할 수 있습니다.

Kiali는 Istio를 통해 서비스매쉬를 구성하시고 이를 모니터링할 수 있는 툴입니다.

아래와 같이 실제 데모로 구축한 fo / bo 어플리케이션의 request per second 값이나 보안통신이 되고있는지 등

여러 내역들에 대해서 서비스매쉬가 그래프로 그려지면서 한눈에 쉽게 확인 할 수 있습니다.

 

 

조금 더 살펴보면 해당 응답들에 대한 비율도 살펴볼 수 있습니다.

 

위의 그림에서 우측 부분을 좀더 확대해 본 형태입니다.만약 실시간으로 트래픽에서 다른 400, 500 Error가 발생한다면,

그래프의 색깔이 변경되면서 한눈에 들어오게 됩니다.

또한 Application단을 클릭하여 해당 파드의 로그도 바로 체크를 할 수 있습니다.External-DNS의 파드 로그를 아래와 같이 대시보드에서 실시간으로 체크하는 모습을 보실 수 있습니다.

 

 

또한 설정에 따라서는 Kiali 대시보드에서 istio destination rule이나 virtual service에서 설정하듯 네트워크 라우팅에 대한 제어를 넣어줄 수 있습니다.

 

 

저는 서비스 매쉬에 대한 트래픽 모니터링을 위해서만 사용하고 있지만 jaeger까지 사용하여 통합한다면,

zipkin과 같은 내역 또한 kiali 대시보드에서도 보실 수 있습니다.

 

https://nsm-dev-kiali.nsmall.com/kiali/console/graph/namespaces/

 

□ Service Mesh로 얻는 이점

- 개발자들이 서비스 간의 안정적인 연동에 집중하는 대신 비즈니스 가치를 추구하는 일에 좀 더 집중할 수 있습니다.

- Jaeger를 통한 요청의 분산 추적은 서비스와 함께 가시적인 인프라 계층을 제공하므로 문제를 손쉽게 인식하고 진단

  할 수 있습니다.

- 서비스 메시는 장애가 발생한 서비스로부터 요청을 재 라우팅 할 수 있기 때문에 다운 타임 발생시  
 어플리케이션 복구 능력이 향상됩니다.

- 성능 매트릭을 통해 런타임 환경에서 커뮤니케이션을 최적화하는 방법을 제안할 수 있습니다.

 

□ istio란

MicroService Architecture의 분산 네트워크 환경 즉, Kubernetes에서 각 app들의 네트워크 연결을 쉽게 설정할 수 있도록 지원하는 기술이며, 서비스에 대한 연결, 보안, 제어 및 모니터링을 할 수 있습니다. 또한, 동적 서비스 발견, 로드 밸런싱, TLS 처리, HTTP/2 및 gRPC 프록싱, 서킷 브레이커, 헬스 체크, 백분율 기반 트래픽 분할을 통한 단계적 출시, 결함 주입 및 풍부한 메트릭 등의 Envoy 기능을 활용합니다.

 

□ istio 구조

모든 컴포넌트가 istiod 라는 하나의 프로세스로 합쳐지고 Control plane에 Mixer가 없어지고 Pilot이 Mixer의 기능까지도 함께 수행되는것으로 바뀌었습니다. Control plane은 트래픽 동작을 제어하는 높은 수준의 라우팅 규칙을 Envoy Proxy전용 구성으로 변환하고 런타임에 사이드카로 전파합니다.