[Service Mesh] 6. Service Monitoring in Istio

Service Mesh 알아보기

1. [Service Mesh] 1. Service Mesh란?
2. [Service Mehs] 2. Envoy Proxy
3. [Service Mesh] 3. Istio?
4. [Service Mesh] 4. Istio Traffic Management (1) - Virtual Service & Destination Rule
5. [Service Mesh] 5. Istio Traffic Managerment (2) - Gateway & Service Entry
6. [Service Mesh] 6. Service Monitoring in Istio
7. [Service Mesh] 7. Logging

---

이번 글에서는 서비스 메시 아키텍쳐에서 어플리케이션 메트릭을 어떻게 수집하는지에 대해서 알아보겠습니다. 어플리케이션이 정상적으로 동작하고 있는지 확인하기 위해서는 이를 측정할 수 있는 메트릭을 수집해야 합니다. 또한, 고가용성을 목표로 한다면 장애가 발생한 후 복구하는 것도 중요하지만 장애에 대해 미리 요청 수, 응답 시간, 응답 상태와 같은 어플리케이션 메트릭과 CPU 및 메모리 사용률과 같은 시스템 메트릭의 임계값을 정해놓고 장애 상황을 예방하는 과정도 필요합니다. 이러한 과정을 모니터링이라고 하며 전체 모니터링 과정은 보통 메트릭 수집 => 메트릭 분석 => 알람  프로세스로 나누어집니다.

Istio를 도입함에 있어 많은 장점들이 존재하지만 그 중 집중해볼 점은 향상된 관측성과 관련된 내용입니다. Istio 서비스 메시 아키텍쳐는 모든 서비스간 통신이 Envoy Proxy를 통해 이루어지고 이를 통해 Istio Control Plane은 로그 및 메트릭 데이터를 얻을 수 있게 됩니다. 그럼 지금부터 Istio에서 이러한 프로세스를 어떻게 수행하는지 알아보겠습니다.

---

Istio Mixer (Deprecated)

1.8버전 이전의 Istio 에서는 서비스 메시에 관련된 메트릭을 모아 엔드포인트로 노출하는 Prometheus Adapter가 Mixer에 내장되어 있습니다. Mixer는 각 Envoy Proxy와 연결을 맺고 있으며 이를 통해 Service Metric을 수집하여 endpoint로 노출하게 됩니다.  추가로 Envoy Proxy Level에서의 메트릭도 수집할 수 있는데, 이는 Proxy Container에서 직접 endpoint를 노출하여 Prometheus가 이를 수집하는 방식으로 동작합니다.

Mixer가 어떤 방식으로 동작하게 되는지 관련된 내용은 alice_k106님의 블로그에 정리되어 있어 이를 참고하여 간단하게 정리해보겠습니다.  

출처 : https://istio.io/v1.7/docs/reference/config/policy-and-telemetry/mixer-overview/

이전 글에서 설명했던 것처럼 Adapter는 Mixer에 전송된 Envoy Attribute를 가공하여 적절한 인프라 백엔드에 전송하는 기능을 담당합니다. 이 때 Envoy Attribute를 어떻게 처리할 지는 Configuration Model을 통해 정의됩니다. Configuration Model은 다음과 같은 3가지 요소를 정의합니다.

• Instance
  Mixer가 수신한 Attribute를 어떻게 처리할 것인지에 대한 정의를 의미합니다. 이 데이터 템플릿을 Handler에게 넘겨주게 됩니다.
• Handler
  Instance의 데이터를 Adapter 입력에 어떻게 매핑할 것인지를 정의하는 부분입니다. 예를 들면 CloudWatch Adapter에 보내기 위해 Json Payload를 정의하는 부분이 됩니다.
• Rule
  Instance와 Handler를 매핑해 Adapter에 실제로 데이터를 전송하며, 매핑하기 원하는 조건(ex. TCP인 경우)을 정의할 수 있습니다.

---

Custom Metric (with Mixer)

기본적으로 제공되는 메트릭 이외에도 위에서 언급한 Configuration Model을 통해 사용자 정의 메트릭 또한 노출시킬 수 있습니다. Istio로 시작하는 서비스 메시 책에 나와있는 예제를 통해 간단하게 사용자 정의 메트릭을 노출시키는 방법을 알아보겠습니다.

먼저 Envoy Attribute를 어떻게 처리할지 정의한 Instance는 다음과 같습니다.

apiVersion: config.istio.io/v1alpha2
kind: instance
metadata:
  name: requestdouble
  namespace: istio-system
spec:
  compiledTemplate: metric
  params:
    value: "2"
    dimensions:
      source: source.workload.name | "unknown"
      destination: destination.workload.name | "unknown"

compiledTemplate은 Envoy Attribute를 처리해서 만들어 낼 데이터 템플릿을 의미합니다. params 필드의 dimensions 필드에는 데이터에 담길 실제 정보를 정의하고, value 필드에 실제 메트릭 값을 입력합니다.

다음으로 Instance의 데이터를 어떻게 매핑할지 정의한 Handler를 정의해보겠습니다.

apiVersion: config.istio.io/v1alpha2
kind: handler
metadata:
  name: doublehandler
  namespace: istio-system
spec:
  compiledAdapter: prometheus
  params:
    metrics:
    - name: doublerequest-count
      instance_name: requestdouble.instance.istio-system
      kind: COUNTER
      label_names:
      - source
      - destination

먼저 해당 데이터를 Prometheus Adapter에 보낼 것이기 때문에 compiledAdapter: prometheus로 정의합니다. 그리고 metrics 필드에서는 prometheus에 저장될 메트릭 정보에 대해 정의합니다. name은 prometheus의 메트릭 이름을, instance_name은 매핑될 instance의 이름을, kind는 prometheus의 데이터 타입을, label_name은 prometheus 메트릭의 label 이름을 의미합니다.

마지막으로 Instance와 Handler를 매핑하기 위한 Rule은 다음과 같습니다.

apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: requestdouble-prometheus
  namespace: istio-system
spec:
  actions:
  - handler: doublehandler
    instances: [ requestdouble ]
  match: match(destination.service.name, "webservice")

match 조건을 만족할 때 actions에 정의된 handler와  instance를 매핑하게 됩니다.

위의 메니페스트를 정의하면 이름이 webservice인 서비스에 대해 instance와 handler의 설정이 적용되고, Prometheus Adapter에 메트릭이 전달되어 최종적으로 endpoint로 노출됩니다. 

---

Web Assembly (After Istio 1.8)

조금 많이 돌아온 것 같기도 하지만 이번글에서 다루고자 하는 부분은 Mixer가 Deprecated된 1.8 버전이후 WebAssembly(WASM)를 통해 어떻게 이를 수행하는지 알아보고자 합니다. Mixer를 통한 방법도 높은 확장성을 갖추고 있지만 위에서 언급한 것처럼 service level 메트릭을 수집하기 위해 Mixer는 각 Envoy Proxy와 연결을 맺고 있어야 하고 이로 인해 많은 리소스 사용과 같은 성능상 이슈가 존재합니다. 성능 개선을 위해 Istio에서는 Envoy Proxy 쪽에 WebAssembly Extension을 붙히는 방법을 채택하였습니다. (Istio 문서에 따르면 개선된 방법이 지연시간을 50~90% 감소시켰으며, CPU 사용량도 50% 정도 감소한 성능 개선을 보여준다고 합니다.)

이전 버전의 Envoy는 확장에 있어 높은 러닝커브를 가지고 있었습니다. Extension을 C++로 작성해야 했으며, Extension을 추가한 Envoy를 다시 빌드해야 하는 문제가 존재하였습니다. 이런 확장성 문제를 해결하기 위해 Istio 커뮤니티는 Envoy를 위한 WASM 런타임을 구현하였고, 개발자는 custom 코드를 작성하고 WASM 익스텐션으로 컴파일 후 Envoy가 이를 실행하도록 설정하는 방식으로 유연하게 확장할 수 있게 되었습니다.

Overview (출처 : https://github.com/proxy-wasm/spec/blob/master/docs/WebAssembly-in-Envoy.md)

---

 Service Level Metric

WASM을 통해 기존에 Mixer에서 처리했던 Service Level의 메트릭은 metadata-exchange, stats 2가지 플러그인을 통해 Envoy Proxy에서 처리됩니다. 

Metadata Exchange Plugin

Service Level 메트릭을 수집하기 위해 Client / Server의 정보가 필요합니다. 하지만 여기에는 한가지 문제가 존재합니다. Service Mesh에서 Envoy Sidecae Proxy는 자기 자신 이외의 다른 Proxy의 정보를 알지 못하며, 이런 정보들은 Control Plane을 통해 얻을 수 있습니다. Control Plane의 컴포넌트인 Mixer를 사용하는 경우에는 문제가 되지 않았지만 Envoy Proxy에서 자체적으로 처리하는 경우, 이러한 정보를 얻을 수 얻기 위한 다른 방법이 필요합니다. 

이를 위해 도입한 방법은 다음과 같습니다.

• HTTP 기반 트래픽의 경우 HTTP header에 이와 관련된 필드(envoy.wasm.metadata_exchange.upstream/downstream)를 추가하여 보냄으로 해결하였습니다.
• TCP 기반 트래픽인 경우 ALPN 기반 터널링 및 접두사 기반 프로토콜을 사용합니다. 이는 서비스 메시 내부에서 client/server에 의한 우선순위를 부여함으로써 위의 문제를 해결할 수 있습니다. 하지만, 이 글에 따르면 Istio 내부의 Proxy 간에는 가능하지만 다른 Client와 Istio 내부 Proxy의 사이의 관계에서는 불가능하다는 한계점이 존재합니다.

Stats Plugin

Stats Plugin은 inbound / outbound 트래픽을 Envoy 내부에 기록하고 Prometheus가 수집 가능하도록 노출시키는 역할을 담당합니다. 기본적으로 노출되는 메트릭의 종류와 Label은 Istio 문서에서 확인하실 수 있습니다.

---

Custom Metric (with WASM)

이번에는 WASM을 통해 Custom Metric을 Expose 하는 방법에 대해서 알아보겠습니다. WASM Plugin을 개발할 수 있는 여러가지 언어들을 지원하고 있는데 Golang을 사용해서 진행해보겠습니다. 해당 과정은 proxy-wasm-go-sdk을 참고하여 진행하였습니다.

example/metrics 폴더의 내용을 살펴보면 custom metric을 수집하기 위한 로직을 작성한 main.go 파일과 이를 추가한 envoy의 설정파일이 존재합니다. main.go부터 살펴보겠습니다.

package main

import (
	"github.com/tetratelabs/proxy-wasm-go-sdk/proxywasm"
	"github.com/tetratelabs/proxy-wasm-go-sdk/proxywasm/types"
)

func main() {
	proxywasm.SetNewRootContext(newRootContext)
	proxywasm.SetNewHttpContext(newHttpContext)
}

var counter proxywasm.MetricCounter

const metricsName = "sphong_custom.request_counter"

type metricRootContext struct {
	// you must embed the default context so that you need not to reimplement all the methods by yourself
	proxywasm.DefaultRootContext
}

func newRootContext(uint32) proxywasm.RootContext {
	return &metricRootContext{}
}

// override
func (ctx *metricRootContext) OnVMStart(vmConfigurationSize int) bool {
	counter = proxywasm.DefineCounterMetric(metricsName)
	return true
}

type metricHttpContext struct {
	// you must embed the default context so that you need not to reimplement all the methods by yourself
	proxywasm.DefaultHttpContext
}

func newHttpContext(uint32, uint32) proxywasm.HttpContext {
	return &metricHttpContext{}
}

// override
func (ctx *metricHttpContext) OnHttpRequestHeaders(numHeaders int, endOfStream bool) types.Action {
	prev := counter.Get()
	proxywasm.LogInfof("previous value of %s: %d", metricsName, prev)
	counter.Increment(1)
	return types.ActionContinue
}

 

먼저 Metric을 위한 Root Context와 Http Context를 생성하는데 모든 메소드를 재구현하지 않기 위해서는 default context를 사용해야 합니다. 그리고 Metric 값을 저장할 counter 변수를 생성하고 OnVMStart 메서드에서 "sphong_custom.request_counter"라는 이름으로 초기화합니다. 마지막으로 OnHttpRequestHeaders 메서드에서 counter의 값을 증가시켜주는 방식으로 동작하게 됩니다.

---

Build

해당 코드를 빌드해야 하는데 공식적인 go 컴파일러가 지원하지 않기 때문에 TinyGo를 통해 빌드해야합니다. 저는 tinygo docker image를 통해 빌드를 수행하였습니다.

> docker run -it -w /tmp/proxy-wasm-go -v $(shell pwd):/tmp/proxy-wasm-go tinygo/tinygo:0.16.0 /bin/bash -c \
'find /tmp/proxy-wasm-go/examples/ -type f -name "main.go" | xargs -Ip tinygo build -o p.wasm -scheduler=none -target=wasi p'

---

Run

다음으로 local에 설치된 envoy에 추가한 WASM을 붙혀 수행하였습니다.

> envoy -c ./examples/${name}/envoy.yaml --concurrency 2 --log-format '%v'

여기서 보고 있는 envoy config 파일은 다음과 같습니다.

static_resources:
  listeners:
    - name: main
      address:
        socket_address:
          address: 0.0.0.0
          port_value: 18000
      filter_chains:
        - filters:
            - name: envoy.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: ingress_http
                codec_type: auto
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: local_service
                      domains:
                        - "*"
                      routes:
                        - match:
                            prefix: "/"
                          route:
                            cluster: web_service
                http_filters:
                  - name: envoy.filters.http.wasm
                    typed_config:
                      "@type": type.googleapis.com/udpa.type.v1.TypedStruct
                      type_url: type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm
                      value:
                        config:
                          name: "my_plugin"
                          root_id: "my_root_id"
                          vm_config:
                            vm_id: "my_vm_id"
                            runtime: "envoy.wasm.runtime.v8"
                            code:
                              local:
                                filename: "./examples/metrics/main.go.wasm"
                            allow_precompiled: true
                  - name: envoy.filters.http.router
                    typed_config: {}

    - name: staticreply
      address:
        socket_address:
          address: 127.0.0.1
          port_value: 8099
      filter_chains:
        - filters:
            - name: envoy.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: ingress_http
                codec_type: auto
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: local_service
                      domains:
                        - "*"
                      routes:
                        - match:
                            prefix: "/"
                          direct_response:
                            status: 200
                            body:
                              inline_string: "example body\n"
                http_filters:
                  - name: envoy.filters.http.router
                    typed_config: {}

  clusters:
    - name: web_service
      connect_timeout: 0.25s
      type: STATIC
      lb_policy: ROUND_ROBIN
      load_assignment:
        cluster_name: mock_service
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: 127.0.0.1
                      port_value: 8099

admin:
  access_log_path: "/dev/null"
  address:
    socket_address:
      address: 0.0.0.0
      port_value: 8001

설정 중 Custom Metric을 Plugin과 관련된 부분만 살펴보면 18000으로 http 요청이 들어오게 되면 위에서 빌드한 main.go.wasm을 플러그인으로 등록하여 사용하게 됩니다. 이 때 플러그인의 이름과 vm의 런타임과 같은 설정도 가능합니다.

---

Custom Metric Test

Envoy를 수행한 후 http://localhost:18000에 요청을 보내면 Custom Metric인 "sphong_custom.request_counter"가 1씩 증가함을 보여주는 로그를 남기고, localhost:8001/stats를 확인해보면 해당 Custom Metric의 값을 확인할 수 있습니다.

요청을 보냈을 때 로그

http://localhost:8001/stats

---

이번 글에서는 Istio에서 어떻게 모니터링을 지원하는지, Custom Metric을 추가하는 방법에 대해 Mixer를 사용하는 버전과 WASM을 사용하는 버전을 나누어 살펴보았습니다. WASM을 사용하는 부분은 아직 모르는 부분이 많아 기본적인 활용방법만 다뤄보았습니다. 물론 위에서 다룬 방법들은 Mesh 및 Service에 관련된 Metric을 얻을 수 있지만 Node나 K8S Cluster, Application Metric을 수집 및 저장하기 위해서는 통상적인 Exporter를 통해 Prometheus가 Scaraping하는 방법을 고려해야 합니다. 

다음 글에서는 Istio Service Mesh에서 Logging Architecture를 구성하는 방법에 대해서 알아보겠습니다.

참고자료

• github.com/proxy-wasm/spec/blob/master/docs/WebAssembly-in-Envoy.md
• banzaicloud.com/blog/istio-mixerless-telemetry/
• banzaicloud.com/blog/envoy-wasm-filter/
• github.com/tetratelabs/proxy-wasm-go-sdk
• istio.io/latest/docs/reference/config/metrics
• blog.naver.com/alice_k106
• Istio로 시작하는 서비스 메시 - 에이콘 출판사

글에서 사용된 모든 코드는 Github에 존재합니다.