[Distributed Tracing] 마이크로서비스의 분산 추적이란 무엇인가

[Distributed Tracing] 마이크로서비스의 분산 추적이란 무엇인가

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

 

목차

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

 

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

 

---

분산 추적이 왜 필요한가?

 

이전의 웹 서비스는 3-tier 아키텍처와 2-tier 아키텍처가 주를 이루었었다.

 

 

하지만 마이크로서비스 아키텍처가 세상에 나오고 이를 시도하고 성공하는 기업의 사례가 늘어남에 따라서 마이크로서비스 환경에 대한 관심도도 그에 걸맞게 증가하고 있다.

 

마이크로서비스 아키텍처와 별개로 시스템 아키텍처 내에서 발생하는 issue 들을 탐지하는 것은 꽤나 중요한 일이었다.

 

그래서 다양한 APM (Application Performance Management) 도구들을 사용하는 기업들이 많이 등장한다.

 

하지만 마이크로서비스로 인해서 n 계층의 아키텍처에서는 컴포넌트의 Topology가 복잡해짐에 따라서 issue 를 탐지하는 것 조차 쉽지 않은 일이 되어버렸다.

 

즉, 마이크로서비스 환경에서의 분산된 애플리케이션 메시지를 추적하는 것이 어렵다.

 

하지만 분산 추적에 대해서 학습하게 된다면 n-tier 의 아키텍처에서도 쉽게 분산 추적이 가능하다.

 

Distributed Tracing

 

Distributed Tracing, 분산 추적은 어떻게 할까?

 

마이크로서비스를 node 로 구분하고 각각의 node 1과 node 2 에서 서로 통신을 한다고 가정해보자.

 

그럼 node 1 에서부터 추적이 시작되고 추적 트리, distributed tracing tree가 생겨난다.

 

 

그리고 node 1 에서 다른 node 로 요청을 보낼 경우 해당 추적 트리에 자식 node 가 append 되는 형태로 tracing tree 를 완성시키는 방법이다.

 

이러한 Tracing Data 는 일반적으로 Timing Data 가 함께 포함되는데, Timing 데이터를 통해서 토폴로지간의 Latency 를 탐지할 수 있게 되는 것이다.

 

즉, 개발자는 각각의 요청들에 대해서 얼마나 시간이 걸렸고, 어떤 문제가 발생했는지 더욱 빠르고 효과적으로 파악할 수 있게 된다.

 

이 때, 이를 실현할 수 있는 방법은 여러가지가 있지만 가장 유명한 Dapper 에 대해서 알아보자

 

Google's Dapper

 

분산 추적 환경에서 앞서 설명하기로는 추적 트리를 이용해서 마이크로서비스 노드간의 상관관계를 분석한다고 했다.

 

그럼 이 상관관계를 어떻게 규정할까?

 

구글은 이 Dapper 를 이용해 상관관계를 아주 간단한 생각으로 해결했다.

 

Dapper 가 궁금하다면 Google Dapper 의 Paper 에서 확인할 수 있다

 

HTTP 요청이 존재하는 상황이라고 가정한다면, HTTP Header 에 메타 데이터를 추가하는 방법으로 해결하였다.

 

HTTP Header 에는 분산 환경에 대한 기본적인 정보와 각각 요청의 상관관계를 분석할 수 있도록 하는 최소한의 정보를 추가한다.

 

Node 1 에서 요청이 시작되었으면 시작 : Node 1, 시간, Endpoint 와 같은 데이터를 헤더에 추가하고 Node 2로 전달한다

그리고 Node 2 에서도 Node 2 의 정보를 추가하고 다음 노드로 넘간다.

 

 

위를 본다면 TxId 는 1로 모두 고정이 되어있다.

 

그렇다면 TxId 가 1로 명시된 모든 메시지는 하나의 트랜잭션에 포함시킨다.

그리고 해당 메시지의 고유한 Id 격인 SpanId 는 트랜잭션 내의 순서를 파악할 수 있도록 도움을 준다.

 

SpanId 와 ParentId 를 통해서 연결 리스트와 비슷한 형태로 메시지를 연결시키는 것이다.

 

이런 방식을 통해서 헤더에 포함되어있는 메타데이터의 정보로 각각 메시지간의 상관관계를 분석하여 추적할 수 있도록 한다.

 

분산 추적을 할 수 있도록 도와주는 것들

 

Distributed Tracing 을 할 수 있도록 도와주는 소프트웨어들이 꽤나 많이 존재한다.

 

우선 Naver 에서 2012년도부터 개발하고 2015년도 오픈소스로 공개한 Pinpoint 나 유명한 Zipkin, Jaeger 등등

 

• Pinpoint
  • 네이버에서 오픈소스로 개발하고 사용되었다.
  • Dapper 방식을 이용한다
• Zipkin
  • 오픈 소스 APM 으로 트위터에서 개발되고 사용되었다.
  • Google 의 Dapper 방식을 이용한다
• Jaeger
  • 역시 오픈 소스 APM 으로 우버에서 개발되고 CNCF 에 종속되었다.
  • Zipkin 과 같이 Dapper 방식을 이용한다
• DataDog
  • 기업용 APM 툴로 인프라에 대한 모니터링을 제공한다
  • 분산 추적 이외에도 인프라 전체에 대한 모니터링이 가능한 장점이 있다.

 

이외에도 여러 도구들이 존재한다 이와 관련해서는 Latest top 11 distributed tracing tools 를 참고할 수 있다

 

이 중에서도 우리는 Zipkin 을 이용해서 분산 추적을 실습할 것이다.

 

 

Spring 진영에서 Zipkin 과 쉽게 연동할 수 있도록 Spring Cloud Sleuth 를 제공하는데, 다음 시간부터 알아보고 실습해보자