안녕하세요. 오늘은 Spring Cloud Sleuth와 Zipkin을 이용한 분산 시스템 Tracing을 하는 방법에 대해서 실습해보도록 하겠습니다.
Zipkin
Zipkin은 분산 트레이싱 시스템입니다. Zipkin은 시간 데이터를 모아 시간 지연 문제등을 해결할 수 있습니다. 로그 파일에 Tracing ID가 있다면 해당 ID를 통해 바로 이동할 수 있으며, 그렇지 않다면 서비스, Tag 등의 쿼리 기반으로 처리할 수 있습니다.
아래는 Zipkin의 UI화면입니다.
Tracing을 해보기 위해서 Zipkin을 설치해보도록하겠습니다.
혹시 Zipkin에 대해 아키텍처적으로 궁금하신 분들은 https://zipkin.io/ 공식사이트를 방문하셔서 확인하시면 될 것같습니다.
설치 & 실행
https://zipkin.io/pages/quickstart
설치하는 방법은 위에 자세하게 나와있습니다.
저는 jar 파일을 다운로드 받아 바로 실행하는 방법으로 진행하겠습니다. 먼저 조건은 JDK 8버전 이상이 설치되어있어야 합니다. 그리고 저는 macOS 10.14.6를 사용하고 있습니다.
먼저 새로운 설치하고자하는 directory를 만듭니다. 그리고 아래 명령어를 실행합니다.
curl -sSL https://zipkin.io/quickstart.sh | bash -s
해당 명령어를 실행하면 최신 zipkin.jar 파일을 받아옵니다. 받아온 최신 jar 파일을 실행해보겠습니다.
java -jar zipkin.jar
위 명령어를 실행하면 아래와 같은 로그와 zipkin이 실행됩니다.
oo
oooo
oooooo
oooooooo
oooooooooo
oooooooooooo
ooooooo ooooooo
oooooo ooooooo
oooooo ooooooo
oooooo o o oooooo
oooooo oo oo oooooo
ooooooo oooo oooo ooooooo
oooooo ooooo ooooo ooooooo
oooooo oooooo oooooo ooooooo
oooooooo oo oo oooooooo
ooooooooooooo oo oo ooooooooooooo
oooooooooooo oooooooooooo
oooooooo oooooooo
oooo oooo
________ ____ _ _____ _ _
|__ /_ _| _ \| |/ /_ _| \ | |
/ / | || |_) | ' / | || \| |
/ /_ | || __/| . \ | || |\ |
|____|___|_| |_|\_\___|_| \_|
:: version 2.19.1 :: commit 1f15b35 ::
...[중략]...
2019-12-04 17:09:03.217 INFO 12887 --- [oss-http-*:9411] c.l.a.s.Server : Serving HTTP at /0:0:0:0:0:0:0:0:9411 - http://127.0.0.1:9411/
2019-12-04 17:09:03.218 INFO 12887 --- [ main] c.l.a.s.ArmeriaAutoConfiguration : Armeria server started at ports: {/0:0:0:0:0:0:0:0:9411=ServerPort(/0:0:0:0:0:0:0:0:9411, [http])}
2019-12-04 17:09:03.235 INFO 12887 --- [ main] z.s.ZipkinServer : Started ZipkinServer in 2.064 seconds (JVM running for 8.148)
로그를 보건대 9411 port로 zipkin이 실행되었다고 되어있습니다. 그러면 바로 한번 접속해보도록 하겠습니다.http://localhost:9411 로접속해봅시다.
간단히 설치 및 실행을 해보았습니다. zipkin을 설치해보았으니 이제 Sleuth를 설치해보겠습니다.
Sleuth
Spring Cloud Sleuth는 TracingID와 SpanID를 부여합니다. TracingID와 SpanID가 뭔지 모르시는 분들은 제가 저번 포스터에 자세하게 써두었으니 확인해주시면 됩니다.
간단하게 말하면 TracingID는 transaction을 추적하기 위한 마이크로서비스간의 공통된 UUID이며 SpanID는 각각 마이크로서비스에서 부여되는 UUID입니다.
그럼 바로 구현해보도록 하겠습니다.
구현
의존성 주입
Spring CLoud Sleuth를 사용하기 위해 가장먼저 외부 의존성을 주입해주도록 하겠습니다.
implementation("org.springframework.cloud:spring-cloud-starter-sleuth:2.1.4.RELEASE")
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-sleuth-zipkin</artifactId>
<version>2.1.4.RELEASE</version>
</dependency>
별도로 설정해줄 건 없습니다. 그럼 바로 Controller를 구현하러 가보도록 하겠습니다.
Controller 구현
Controller를 구현해 보도록하겠습니다. Controller 소스는 아래와 같습니다.
@Slf4j
@RestController
@RequestMapping
public class OrderController {
@GetMapping(value="/zipkin")
public String zipkinService1()
{
log.info("Inside zipkinService 1..");
return "Hello?";
}
}
보시면 그냥 일반 Controller입니다. 혹시 @Slf4j가 안되신다면 lombok을 설치하시면 됩니다. lombok없이 확인하고 싶으시면 OrderController의 맴버변수로 private final Log log = LogFactory.getLog(OrderController.class);
를 추가해서 사용해 주시면 됩니다.
바로 실행해볼까요? 로그를 한번 보도록하겠습니다.
2019-12-04 17:45:13.045 INFO [demo-order,,,] 13793 --- [ main] trationDelegate$BeanPostProcessorChecker : Bean 'org.springframework.hateoas.config.HateoasConfiguration' of type [org.springframework.hateoas.config.HateoasConfiguration$$EnhancerBySpringCGLIB$$a7638fb1] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
출력되는 로그 한줄을 가져왔습니다. 여기서 특이점이 생겨있음을 알 수 있습니다. 바로 [demo-order,,,] 바로 이 부분입니다. 모든 로그에 저렇게 찍혀있는게 보이실껍니다. sleuth가 찍어주는 부분인데 내용은 조금있다 설명드리고 아까 만든 controller를 호출해보도록 하겠습니다.
2019-12-04 17:48:04.718 INFO [dkargo-order,5de772c409f727e933fc0d958149413e,33fc0d958149413e,true] 13793 --- [nio-8081-exec-1] c.d.p.order.controller.OrderController : Inside zipkinService 1..
[demo-order,5de772c409f727e933fc0d958149413e,33fc0d958149413e,false] log를 찍어두었던 부분에 이런식으로 찍히는걸 보실 수 있습니다.
각각 뜻하는 바는 아래와 같습니다.
- demo-order[project 이름]
- 5de772c409f727e933fc0d958149413e[TraceId]
- 33fc0d958149413e[SpanId]
- false[exportable]
exportable은 zipkin이나 다른 곳으로 결과값을 전송하는지 유무입니다. 지금은 단독으로 사용하기 때문에 exportable이 false이지만 zipkin과 연동할때는 true로 변경되게 됩니다.
TraceId와 SpanId는 마이크로서비스로의 요청에 따라 전파되게 됩니다. 전파되는 방법은 http Request Headers를 통해 전파되게 됩니다. 아래는 sleuth 공식문서의 한 부분입니다.
마무리
오늘은 이렇게 Tracing의 요소에 대해서 알아보았습니다. 원래 이번 포스팅에서 zipkin과 sleuth의 연동까지 하고싶었지만 생각보다 길어져 다음 포스팅으로 넘기도록 하겠습니다.
감사합니다!
참조
'infra > 로깅과 트레이싱' 카테고리의 다른 글
[MSA] Elastic Stack을 이용한 중앙 집중형 로깅_실제 운영 환경 (0) | 2019.12.18 |
---|---|
[MSA] Filebeat와 Logstash의 비교 (4) | 2019.12.13 |
[MSA] Elastic Stack을 이용한 중앙 집중형 로깅_1 (0) | 2019.12.09 |
[MSA] Spring Cloud Sleuth와 Zipkin을 이용한 분산 시스템 Tracing_2 (0) | 2019.12.07 |
[MSA] MSA의 로깅과 트레이싱 (2) | 2019.12.04 |
댓글