1. 개요
마이크로서비스 아키텍처 분산 서비스를 모니터링하기 위한 Sleuth와 Zipkin에 대해 알아보자.
2. Sleuth란?
- 클라이언트의 호출은 여러 서비스를 거쳐 처리되므로 전체적인 로그 추적이 어렵다.
- 따라서 전 구간을 추적하기 위한 Global ID가 필요하다.
- Sleuth는 이러한 ID (Trace ID, Span ID)를 생성하고, 이를 Zipkin에 전달한다.
pom.xml 파일에 삽입은 다음과 같다.
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-sleuth</artifactId> <version>1.3.5.RELEASE</version></dependency>3. Span ID
작업의 기본 단위로, 각 서비스를 호출하면 새로운 Span ID가 생성된다. 이 ID는 유일한 64bit ID로 구분한다.
이는 Description, Key-value annotation, Process ID 등의 추가 정보를 가진다.
Trace에서 가장 처음 만들어지는 Span을 Root Span이라 부른다.
N개의 Span ID는 하나의 Trace ID를 구성한다.
4. Trace ID
전체적인 트랜잭션 flow를 나타내는 것으로 최초 호출 시 인입 서비스에서 생성한다.
동일 Trace ID를 갖는 Span을 묶어 Tree 형태로 구성한다.
역시 유일한 64bit ID로 구분한다.
5. Zipkin이란?
트위터에서 사용한다고 한다. (검색결과라 신뢰도는 모르겠음) 그리고 기본적인 아키텍처는 Google Drapper에서 발전했다고 한다. (역시 검색결과이다)
Collector, Query Service, Database, WebUI로 구성된다.
설정 방법은 다음과 같다.
- 추적 대상 서비스에 Sleuth와 Zipkin 라이브러리 추가
- Zipkin 서버 구성
- 서비스에서 Zipkin 서버 연결을 위한 설정(Properties) 추가
- 서비스에서 Zipkin 서버에 trace 정보를 전송하기 위한 샘플링 전략 수립