[Service Mesh] 7. Logging

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

---

이번시간에는 서비스 메시 내부 어플리케이션에서 발생하는 로그를 Istio에서 어떻게 처리하는지에 대해 알아보겠습니다. Kubernetes Cluster에 배포된 어플리케이션의 상태를 추적하고 확인하기 위해서는 로그 데이터를 수집하고 이를 분석하는 과정이 필요합니다. 이 때 발생하는 로그의 종류로는 시스템 로그나 어플리케이션에서 발생하는 로그, 어플리케이션에 엑세스하는 로그와 같이 다양하게 존재합니다.

이 중 엑세스 로그는 서비스 메시 아키텍쳐에 배포되는 어플리케이션이 모든 통신이  Envoy Sidecar를 통해 이루어지고, 이는 Istio에서 관리되기 때문에 요청 및 엑세스 과정을 추적할 수 있습니다. Service Metric 수집과 동일하게 Mixer가 존재했던 Istio 1.8 버전 이전의 경우에는 Adapter를 통해 Logging Backend로 데이터를 전송할 수 있습니다. 이와 달리 Mixer가 Deprecated 된 Istio 1.8 버전 이후에는 WASM을 통해 Envoy 내부에서 이런 과정들이 이루어지게 됩니다. 이번 글에서는 두가지 방법에 대해서 간단하게 알아보도록 하겠습니다.

---

EFK Stack

이 글을 참고하면 로그를 수집 및 전송하기 위한 Fluentd, 저장을 위한 Elasticsearch, 조회를 위한 Kibana를 배포할 수 있는 manifest가 존재합니다. 이를 통해 EFK Stack을 Kubernetes Cluster에 배포할 수 있습니다. 설정과 관련된 부분은 따로 다루지 않겠습니다.

---

Logging (with Mixer)

Metric을 수집했던 것과 같이 Istio 1.8 이전 버전에서는 Mixer를 활용하여 Access Logging을 처리하였습니다. 어플리케이션의 엑세스 로그를 수집해야하는 상황을 가정했을 때 해당하는 로그 데이터를 수집하여 로깅 백엔드로 전송하기 위한 Adapter가 필요합니다.  

Adapter를 구성하기 위한 Handler, Instance, Rule 역할에 대한 설명은 이전 글에서 확인하실 수 있습니다. 

# Configuration for logentry instances
apiVersion: config.istio.io/v1alpha2
kind: instance
metadata:
  name: newlog
  namespace: istio-system
spec:
  compiledTemplate: logentry
  params:
    severity: '"info"'
    timestamp: request.time
    variables:
      source: source.labels["app"] | source.workload.name | "unknown"
      user: source.user | "unknown"
      destination: destination.labels["app"] | destination.workload.name | "unknown"
      responseCode: response.code | 0
      responseSize: response.size | 0
      latency: response.duration | "0ms"
    monitored_resource_type: '"UNSPECIFIED"'
---
# Configuration for a Fluentd handler
apiVersion: config.istio.io/v1alpha2
kind: handler
metadata:
  name: handler
  namespace: istio-system
spec:
  compiledAdapter: fluentd
  params:
    address: "fluentd-es.logging:24224"
---
# Rule to send logentry instances to the Fluentd handler
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: newlogtofluentd
  namespace: istio-system
spec:
  match: "true" # match for all requests
  actions:
   - handler: handler
     instances:
     - newlog
---

• timestamp 필드에 대입되는 request.time은 envoy에서 제공됩니다. 
• Instance의 Variable에 선언되는 데이터의 종류는 이 글에서 확인할 수 있습니다.
• Handler의 compiledAdapter는 Fluentd Adapter를 의미하고, address에서 구동 중인 fluentd Daemon에 데이터를 전송합니다.

위의 Adapter를 통해 어플리케이션 접근 로그를 Fluentd Daemon에 전송할 수 있습니다.

---

Logging (with WASM)

  이번에는 Mixer가 Deprecated 된 이후 WASM을 통해 어떻게 위의 기능을 수행할 수 있는지 알아보겠습니다. 먼저 WASM Plugin을 개발하기 이전에 Fluentd Adapter가 하는 역할을 한 번 짚어보겠습니다. Fleuntd Adapter는 수신한 Envoy Attribute를 통해 로그 데이터를 생성하고, 이를 fluentd Daemon에 보내는 역할을 담당합니다. 따라서 WASM Plugin에서 수행할 작업은 Log Data를 생성하여 이를 Fluentd Daemon에 전송하는 작업이어야 합니다. 예제가 있었던 metric과는 다르게 logging에 대한 예시는 없기 때문에 proxy-wasm-go-sdk의 메서드들을 찾아보며 진행해보겠습니다.

진행하며 가장 어려웠던 점은 Custom Log Metric을 어떻게 생성하는지에 대한 부분입니다. logentry variable 필드에서 정의했던 source.labels, response.code와 같은 데이터들을 어떻게 얻을 수 있는지에 대해서 문서를 확인해보면 위에서 사용된 데이터들을 미리 키워드로 정의해놓고 이를 Attribute Vocabulary라고 하며 Envoy나 Mixer의 Adapter에서 생성된다고 명시되어 있습니다. 또한, Istio Deployment는 이런 Attribute Vocabulary를 생성하는 agent가 존재한다고 나와있습니다. 하지만 Telemetry V2는 K8S Metadata에 접근하기 위한 Mixer가 사라졌기 때문에 metadata에 대한 처리를 Envoy Proxy 자체적으로 수행해야 합니다.

이를 위해 먼저 알아야 하는 점은 어떤 Envoy Attribute가 존재하고, 이를 WASM Plugin에서 어떻게 사용할 수 있는지에 대한 부분입니다. 저는 이거를 찾는데 애를 먹어 Stackoverflow에 질문까지 했는데 다행히 금방 도움을 받을 수 있었습니다.

Thanks to Jakub...

위의 내용을 보면 Envoy에서 사용할 수 있는 데이터의 목록은 Attributes 문서에서 확인할 수 있고, 이 글의 마지막 부분의 Path Expressions 부분을 보면 WASM ABI에서 어떻게 값을 얻을 수 있는지 나타나 있습니다. 또한, proxy-wasm-go-sdk의 PR을 보면 2020년 9월에 get_property 기능이 추가된 것을 확인할 수 있습니다.

---

WASM Plugin

먼저 get_property 함수를 확인해보겠습니다. 

func GetProperty(path []string) ([]byte, error) {
	var ret *byte
	var retSize int
	raw := SerializePropertyPath(path)

	err := types.StatusToError(rawhostcall.ProxyGetProperty(&raw[0], len(raw), &ret, &retSize))
	if err != nil {
		return nil, err
	}

	return RawBytePtrToByteSlice(ret, retSize), nil

}

 

Parameter로 받는 path에 Envoy Attributes의 경로는 입력하는 방식으로 값을 얻어올 수 있습니다.

---

이를 통해서 간단하게 Http 요청으로부터 값을 받아오거나 connections에 관한 정보 등을 데이터를 받아오는 코드는 다음과 같습니다.

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)
}

type httpLogRootContext struct {
	proxywasm.DefaultRootContext
	contextID uint32
}

func newRootContext(contextID uint32) proxywasm.RootContext {
	return &httpLogRootContext{contextID: contextID}
}

// override
func (ctx *httpLogRootContext) OnVMStart(vmConfigurationSize int) bool {
	path := []string{"cluster_name"}
	result, err := proxywasm.GetProperty(path)
	if err != nil {
		proxywasm.LogCritical("failed to get property in envoy.")
	} else {
		proxywasm.LogInfo("Node Info  : " + string(result))
	}
	return true
}

type logHttpContext struct {
	proxywasm.DefaultHttpContext
}

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

// override
func (ctx *logHttpContext) OnHttpRequestHeaders(numHeaders int, endOfStream bool) types.Action {
	pathMethod := []string{"request", "method"}
	methodResult, _ := proxywasm.GetProperty(pathMethod)
	proxywasm.LogInfo("Request Method  : " + string(methodResult))

	connectionPath := []string{"source", "address"}
	connectionResult, _ := proxywasm.GetProperty(connectionPath)
	proxywasm.LogInfo("Source Address :" + string(connectionResult))

	return types.ActionContinue
}

간단하게 코드를 살펴보면 OnVMStart 함수는 초기 실행 시 수행되고, OnHttpRequestHeaders 함수는 HTTP 요청이 들어왔을 때 수행이 됩니다.  이 때 사용할 Context를 main 함수에서 정의하는 방식으로 수행됩니다.

---

위 코드의 실행 결과는 다음과 같습니다.

//Start
starting main dispatch loop
wasm log my_root_id: failed to get property in envoy.

// HTTP Request In
wasm log: Request Method : GET
wasm log: Source Address :127.0.0.1:58181

실행 결과를 보면 OnVMStart에서 호출된 cluster_name에 대해 데이터를 가져오지 못한 것을 확인할 수 있습니다. 이와 관련해서 아직 sdk의 구조를 완벽하게 파악하지는 못했지만 제가 정리한 바는 

• 여러가지 Envoy Attribute를 테스트 한 결과 각 Attribute는 가져올 수 있는 시점이 존재하고 이 시점은 Context와 On--- Method로 구분됩니다.
• On---Method에서는 HttpHeader 및 Up/DownStream / Connection과 같은 다양한 이벤트 발생과 대응되며 이 때 수행할 행동을 지정할 수 있습니다.

위의 과정을 통해 Envoy Attribute에서 원하는 데이터를 얻어올 수 있습니다. 이 데이터를 Fleuntd Daemon에 보냄으로써 Mixer Adapter가 수행하는 기능을 Envoy Proxy 자체가 수행할 수 있습니다.

생성한 로그 데이터를 Fluentd Daemon에 전송하는 작업에 대해서도 진행했어야 하지만 TCP Socket을 사용하여 데이터를 전송하는 WASM ABI를 찾지 못해서 이 부분은 좀 더 찾아본 후 다음 글로 작성하도록 하겠습니다...

---

마치며

이번 시간에는 Mixer를 사용하여 Access Log를 수집하는 방법과 WASM를 사용하여 Custom Log를 수집하는 과정의 일부..(Envoy Attribute 에서 데이터 수집)를 진행했습니다. 물론 저는 WASM에 대해 잘 알지 못하기 때문에 제가 작성한 방법들이 실제로 사용되기는 힘들고 그저 동작하는 방식을 이해하기 위한 정도로만 생각하시면 될 것 같습니다. 

지금까지의 글을 통해 Service Mesh 아키텍쳐 및 Istio에 대해 알아보는 시간을 가져보았습니다. 공부를 하면서 느꼈던 부분은 아직 문서화가 덜 된 부분들도 있고, 버전에 따라 많은 부분들이 변하는 상황인지라 원하는 정보를 찾기 조금 어렵다는 생각이 들었습니다. 또한, 분명 인프라 레벨에서 처리하는 것에 대해 장점이 존재하지만, 이를 적용함으로써 기존의 Server - Client의 사이에 또 하나의 계층이 추가되기 때문에 관리해야할 포인트가 증가하게 된다는 점입니다. 모든 기술에 장점만 존재하지 않기에 Istio 및 envoy의 안정성에 대한 검증도 분명 필요하다는 생각이 들었습니다. 

지금까지 글을 읽어주셔서 감사합니다. 수정이 필요하거나 더 나은 의견이 있다면 언제든지 피드백 부탁드립니다 :)

---

참고자료

Envoy Attribute

Stackoverflow

Istio EFK Stack

Istio Mixer Overview