[Distributed Tracing] Zipkin 과 Spring Cloud Sleuth 에 대해서

 

본 글은 마이크로서비스의 분산 추적 시리즈로 이론과 실습이 함께 포함된 시리즈입니다. 아래 목차에 표시된 글을 모두 참고하면 좋습니다.

 

목차

 

• Distributed Tracing, 분산 추적이란?
• Spring Cloud Sleuth 와 Zipkin
• Sleuth 로 Http 환경의 분산 추적 실습
• Sleuth 로 Messaging 환경의 분산 추적 실습

 

실습에 대한 소스코드를 확인하시고 싶다면 실습 github에서 확인하실 수 있습니다.

 

---

Zipkin 에 대해서

 

Zipkin 은 트위터에서 개발하고 사용한 Distributed Tracing Tool 이다

 

 

Zipkin 에서는 지난 시간 에서도 이야기하였던 Dapper 를 이용하여 분산 환경에서 메시지를 추적한다.

 

Zipkin 에서는 Tracer 와 함께해야 한다.

 

Tracer 는 각 노드에 포함되어있는 애플리케이션 라이브러리 혹은 Sidecar 로 해당 노드에서 발생한 메시지를 Timing Data 와 같은 Metadata 를 포함시켜 Zipkin 으로 전송해준다.

 

그럼 Zipkin 에 포함된 Collector 에 의해서 해당 데이터들이 모이게 되고 정제된다.

 

그런 뒤 Zipkin 의 UI Dashboard 에서 확인할 수 있게 한다

 

Trace 와 Span

 

Zipkin 에서는 분산 환경의 메시지들을 Trace 와 Span 을 통해서 구분하고 상관관계를 규정한다

 

 

Span in Zipkin

 

Span은 Timing Data 와 같은 메타 데이터를 포함하는 정보이다.

 

Span 에 포함된 데이터는 계속해서 Zipkin Collector 로 전송되어야 하기 때문에 가능한 작게 유지되어야 한다.

 

Span 은 서로 연결되어있는데, SpanId 와 ParentSpanId 를 통해서 논리적으로 연결되어있다

 

Trace in Zipkin

 

Trace 는 Span 들의 세트로 하나의 TraceId 를 각각의 Span 들이 공유하는 방식이다

 

이러한 Span 과 Trace 데이터가 Zipkin 에 전송되면 다음과 같은 json 으로 Zipkin

 

  [
    {
      "traceId": "5982fe77008310cc80f1da5e10147517",
      "name": "get",
      "id": "bd7a977555f6b982",
      "localEndpoint": {
        "serviceName": "zipkin-query",
      },
      "annotations": [
        {
          "timestamp": 1458702548467000,
        },
        {
          "timestamp": 1458702548853000,
        }
      ]
    },
    {
      "traceId": "5982fe77008310cc80f1da5e10147517",
      "name": "get-traces",
      "id": "ebf33e1a81dc6f71",
      "parentId": "bd7a977555f6b982",
      "localEndpoint": {
        "serviceName": "zipkin-query",
      },
      "tags": {
        // 생략
      }
    }
  ]

 

Zipkin 의 아키텍처

 

 

Zipkin 은 크게 3가지의 파트로 나뉜다.

 

1. Reporter
2. Collector
3. Storage & UI

 

Reporter

 

• 마이크로서비스 노드에 포함되며 메시지가 발생할 때마다 해당 메시지의 Metadata 를 Zipkin Collector 로 비동기적으로 전송한다
• Metadata 에는 Timing Data, TraceId, SpanId 와 같은 정보들이 포함된다

 

Collector

 

• 마이크로서비스 컴포넌트는 zipkin daemon 으로 데이터를 전송하는데 이 데이터를 받는 모듈을 컬렉터라고 부른다.

 

Storage & UI

 

• 카산드라가 기본적인 Storage Infrastructure 로 사용된다.
• Plug & Play 방식이기 때문에 Cassandra 이외에도 Elastic Search & MySQL 을 연동할 수 있다

 

Zipkin 실행하기

 

zipkin 을 시작하는 방법은 여러가지 방법이 있겠지만 나는 docker 를 이용해보려 한다.

 

docker run --rm -d -p 9411:9411 openzipkin/zipkin

 

을 통해서 zipkin 을 실행하고 9411 포트로 접근하면 다음과 같은 웹 대시보드가 나타나게 된다

 

 

Spring Cloud Sleuth

 

Zipkin 과 함께 사용되는 Tracer 는 많은 것들이 존재한다.

 

공식적으로 Zipkin 이 개발하고 운영하는 Zipkin Supported 과 Open Source 로 운영되는 Zipkin Community Supported 가 있다.

 

• Zipkin Supported
  • brave
  • zipkin-js
  • zipkin-go
• Zipkin Cummunity Supported
  • spring cloud sleuth
  • tapper
  • appmetrics-zipkin
  • htrace

 

이 중에서도 우리는 Zipkin 의 Brave B3-Propagation 의 Java 구현체인 Spring Cloud Sleuth 에 대해서 알아볼 것이다.

 

Spring Cloud Sleuth 는 분산 추적을 위한 Spring Boot 기반의 auth-configuration 을 제공한다.

 

대표적인 Sleuth 의 기능에 대해 이야기해보자면 다음과 같다

 

• Header Propagation 을 이용하여 Trace 정보를 기록한다.
• TraceId, SpanId 를 자동으로 생성해준다.
• Http 을 통해서 Tracing 정보를 Zipkin 으로 전송한다
• Trace 에 대한 정보들을 토대로 Log Integration 을 제공한다

 

Spring Cloud Sleuth 에서 Tracer 와 Span

 

Sleuth 에는 2가지의 핵심 인터페이스가 존재한다.

 

1. Tracer
2. Span

 

Tracer 는 Root Span 을 생성할 수 있도록 도와준다.

 

Span 은 하나의 작업 단위로 특정 노드에서 발생하는 일련의 과정 (start & end) 가 Span 이 된다.

 

Span 의 Lifecycle

 

• start
  • Span 이 생성, 시작되었음을 의미하고 start timestamp 가 기록된다.
• end
  • span 이 종료되었음을 의미하고, Span 의 Life state 가 end 상태여야만 Zipkin Collector 로 전송이 된다.

 

보통 Span 을 사용하기 위해서는 Tracer 를 autowired 하여 사용할 수 있다.

 

public class A {

  @Autowired
  private Tracing tracing;

  public void doSomething() {
    Tracing current = tracing.current():
    // ...
  }
}

 

위의 내용들은 이후에 있을 실습에서 조금 더 자세히 알아보는 것으로 하자

 

Zipkin 으로 Reporting 하기

 

Spring Cloud Sleuth 에서 Span 이 닫히게 되면 Zipkin 서버로 Reporting 을 한다.

 

이떄, Sleuth 를 사용한다면 Reporting 하는 로직을 우리가 구성하지 않아도 된다.

 

RestTemplate, KafkaTemplate, KafkaListener, RedisTemplate 를 Bean 으로 등록한다면 BeanPostProcessor 를 통해서 Sleuth 가 Reporting 을 수행하기 때문이다.

 

이 다음 시간에 있을 Sleuth 실습에서 볼 수 있지만 Sleuth 를 사용하지 않는 node-express 환경에서는 이를 직접 구현해서 Reporting 한다

 

 

Sleuth 를 사용할 경우 Zipkin 으로 Report 하는 과정은 AsyncRepoter 에 의해 Asynchronous 하게 동작하기 때문에 본 Transaction 과는 무관하게 동작한다.

 

이 말은 Reporting Span 정보가 유실될 수 있다는 말이므로 유실에 대한 대비도 필요하다

 

Log Integration

 

Sleuth 를 사용한다면 쉽게 Log Integration 이 가능하다

 

Sleuth 를 추가하게 된다면 다음과 같은 형식으로 로그가 찍히게 된다.

 

 

즉,

 

[service-name], [trace-id], [span-id]

 

형태로 찍히게 되는데, 이 말은 TraceId 로 로그를 구분할 수 있게 된다는 것이다.

 

이 특성을 이용해서 추후 Kibana 와 같은 곳에서도 로그를 쉽게 관리할 수 있게 된다.