엔지니어링

Elastic Observability를 사용한 Istio 모니터링

Istio는 개발자와 운영자가 분산 마이크로서비스 환경에서 서비스를 제어하고, 보호하고, 함께 연결하는 데 사용할 수 있는 오픈 소스 서비스 메시입니다. Istio는 팀이 사용하기에 강력한 도구일 뿐만 아니라 관리자가 상태를 파악하는 데도 중요한 역할을 합니다. 이 블로그 게시물에서는 Elastic Observability를 활용하여 Istio 및 관련 마이크로서비스를 모니터링하는 방법을 살펴보겠습니다.

다음은 Istio 설명서에서 발췌한 내용입니다.

Istio를 사용하면 서비스 코드를 전혀 또는 거의 변경하지 않고도 배포된 서비스의 네트워크를 손쉽게 생성하고 로드 밸런싱, 서비스 간 인증, 모니터링 등의 기능을 활용할 수 있습니다. Istio를 사용하려면 먼저 마이크로서비스 간 모든 네트워크 통신을 가로채는 특수 사이드카 프록시를 환경 전반에 걸쳐 배포하여 Istio 지원을 서비스에 추가합니다. 그리고 다음과 같은 컨트롤 플레인 기능을 사용하여 Istio를 구성 및 관리하면 됩니다.

  • HTTP, gPRC, WebSocket, TCP 트래픽을 자동으로 로드 밸런싱
  • 풍부한 라우팅 규칙, 재시도, 장애 조치, 오류 주입을 통해 트래픽 동작을 세부적으로 제어
  • 액세스 제어, 속도 제한 및 할당량을 지원하는 플러그형 정책 계층 및 구성 API
  • 클러스터 수신 및 송신을 비롯하여 클러스터 내의 모든 트래픽에 대한 자동 메트릭, 로그 및 추적
  • 강력한 자격 증명 기반 인증 및 권한 부여를 통해 클러스터 내 서비스 간 통신을 안전하게 보호

버전 1.5 이전에 Istio는 마이크로서비스 아키텍처로 구축되었으며 관련 컨트롤 플레인 및 관리 구성 요소는 Pilot, Mixer, GalleyCitadel과 같은 여러 마이크로서비스로 구성되어 있었습니다.

Metricbeat는 이러한 마이크로서비스에 대한 모니터링을 지원했습니다. 하지만 버전 1.5부터는 Istio가 아키텍처를 모놀리식 접근 방식으로 변경했고 현재 컨트롤 플레인에는 istiod라는 단일 애플리케이션이 함께 제공됩니다. Istiod에는 Pilot, Galley 및 Citadel이 포함되어 있으며, Envoy 프록시에서 트래픽 메트릭을 수집하는 Mixer의 기능은 Istio 프록시에서 직접 제공합니다. 현재 Istio의 아키텍처는 다음과 같은 형태입니다.

Istio 아키텍처

Elastic으로 모니터링 솔루션 구성

Istio Metricbeat 모듈에서 1.5 이전 버전을 이미 지원하고 있지만, 이 블로그에서는 최신 버전에 초점을 맞춰 Kubernetes에서 실행되는 Istio를 살펴보겠습니다.

컨트롤 플레인 메트릭

위의 Istio 아키텍처 그림에서 볼 수 있듯이, 컨트롤 플레인 메트릭을 수집할 수 있는 리소스는 하나뿐입니다. Istiod는 Prometheus 메트릭을 수집할 수 있도록 Prometheus 내보내기를 제공합니다.

Prometheus 엔드포인트의 메트릭을 사용하려면 이러한 메트릭을 적절하게 수집하고, 필터링하고, 그에 따라 저장할 수 있는 메트릭 세트가 필요합니다. 이를 위해서는 Prometheus 모듈을 기반으로, 메트릭 필터링과 같은 강력한 옵션을 활용하고 히스토그램 및 유형을 사용하는 경량 메트릭 세트를 생성하면 됩니다.

그러면 새로운 경량 메트릭 세트의 정의를 살펴보겠습니다.

input: 
  module: prometheus 
  metricset: collector 
  defaults: 
    metrics_path: /metrics 
    metrics_filters: 
      include: ["citadel_*", "galley_*", "pilot_*"] 
      exclude: ["^up$"] 
    use_types: true 
    rate_counters: true

이렇게 하면 수집기 메트릭 세트에서 메트릭을 스크랩할 경로를 정의하고, 필요 없는 메트릭을 필터링하고, 데이터가 Elasticsearch에 적절하게 저장되도록 속도와 유형을 활성화하여 사용자가 메트릭을 최대한 활용하도록 할 수 있습니다.

Kubernetes 클러스터에 Metricbeat를 배포할 때 다음과 같이 메트릭 세트를 구성합니다.

- module: istio 
  metricsets: ['istiod'] 
  period: 10s 
  hosts: ['istiod.istio-system:15014']

여기서 istiod는 Istiod Pod를 노출하는 Kubernetes 서비스의 이름이며, istio-system은 배포된 곳의 네임스페이스입니다.

모두 완료되었습니다. 이제 istiod 메트릭 세트가 있으므로 istiod에서 메트릭을 수집할 수 있습니다. 이 메트릭 세트에는 사전 구축된 대시보드가 함께 제공되어 서비스 메시의 컨트롤 플레인에 대한 개요를 제공하며, 자체 사용자 정의 대시보드에서 사용할 수 있는 몇 가지 시각화도 제공합니다.

개요 대시보드

데이터 플레인 메트릭

Istiod 메트릭 세트를 사용하여 컨트롤 플레인의 메트릭을 수집하게 되었으니, 이번에는 데이터 플레인의 메트릭을 수집하여 모니터링을 확장해 보겠습니다. 데이터 플레인 메트릭은 Istio에서 관리하는 서비스 간 트래픽에 대한 매우 유용한 개요를 제공합니다.

앞에서 언급했듯이 이러한 데이터 플레인 메트릭을 수집하고 제공하는 역할을 담당했던 마이크로서비스가 Mixer였습니다. 그러나 버전 1.5부터는 Istio 프록시가 Prometheus 내보내기를 사용하여 이러한 메트릭을 직접 수집하고 노출합니다.

방법은 간단합니다. Istiod에서 했던 작업과 비슷하게 다음과 같이 또 다른 경량 메트릭 세트를 지정하여 추가 메트릭을 수집하도록 하면 됩니다.

input: 
  module: prometheus 
  metricset: collector 
  defaults: 
    metrics_path: /stats/prometheus 
    metrics_filters: 
      include: ["istio_*"] 
      exclude: ["^up$"] 
    use_types: true 
    rate_counters: true

이전과 마찬가지로, metrics_path를 설정합니다. 또한 원하는 메트릭만 유지하고 유형을 사용하여 이를 저장합니다. 

하지만 한 가지 놓친 부분이 있습니다. IP 주소를 모르기 때문에 이러한 프록시 컨테이너에 접근하는 방법을 모릅니다. Metricbeat를 배포하기 전에 이러한 컨테이너의 IP 주소를 알았다 하더라도 Metricbeat가 시작된 이후에 배포되는 서비스의 데이터는 수집할 수 없습니다. 자동으로 이러한 컨테이너를 식별하고 컨테이너가 시작되는 대로 메트릭을 수집할 수 있는 방법이 필요합니다. 바로 Metricbeat의 자동 검색 기능이 필요합니다. 즉, 이러한 컨테이너를 식별하도록 자동 검색 조건을 정의하면, 새로운 Istio 프록시 사이드카 컨테이너가 발견될 때마다 Metricbeat가 자동으로 프록시 메트릭 세트를 활성화하고 데이터를 수집하기 시작합니다.

다음은 자동 검색 구성의 예입니다.

metricbeat.autodiscover: 
  providers: 
    - type: kubernetes 
      node: ${NODE_NAME} 
      templates: 
        - condition: 
            contains: 
              kubernetes.annotations.prometheus.io/path: "/stats/prometheus" 
          config: 
            - module: istio 
              metricsets: ["proxy"] 
              hosts: "${data.host}:15090"

이제 클러스터에서 실행되는 모든 Istio 사이드카 컨테이너에서 메트릭을 수집하고 있으며 새로운 컨테이너를 즉시 식별할 수 있습니다. 다음은 사전 구축된 대시보드와 함께 제공되는 Istio 모듈의 프록시 메트릭 세트입니다.

트래픽 대시보드

Kibana의 그래프 분석을 활용하여 데이터와 서비스 간 상관관계를 살펴볼 수도 있습니다. 예를 들어 아래 그래프를 보면 서비스가 서로 어떻게 연결되어 있으며 http 상태 코드와 얼마나 밀접한 관계가 있는지 알 수 있습니다. 500 상태 코드와 밀접한 관계가 있는 서비스는 조사가 필요한 문제가 있음을 시사합니다.

서비스 메시 그래프

Istio 모니터링 시작

Istio 서비스 메시 모니터링을 시작하려면 Metricbeat 7.11을 다운로드하고 Elasticsearch 및 Kibana를 사용하여 효율적으로 메트릭을 탐색해 보세요. 클러스터를 배포하는 가장 빠른 방법은 Elasticsearch Service 무료 평가판을 시작하는 것입니다. 질문이 있으시면 언제든지 토론 포럼에 글을 남겨주세요. 최선을 다해 도와드리겠습니다.