👨‍👧‍👦 분산 추척, Zipkin

💼 Microservicer의 분산 추적 ( 추적정보 Tracing )

MSA 환경에서 하나의 요청이 여러 개의 서비스를 호출 할 수 있다는 것을 알 수 있다. 그렇다면 우리가 문제가 발생했을때마다 일일히 모든 서비스를 찾아본다는게 쉽지 않다. 때문에 우리는 요청 정보의 실행 정보와 어떤 과정을 거쳐 어느 서비스로 이동되고 있는지 알아야할 필요성을 느꼈다. 그것이 분산 추적이다.

 

💼 Zipkin

우리가 분산 추적을 하여 추적을 하면 정보가 남는데 그것을 트레이싱이라고 한다 그렇다면 트레이싱을 어디에 저장을 할 수 있는 서비스가 필요하다 그때 사용하는 것이 바로 Zipkin이다.

• Twitter에서 사용하는 분산 환경의 Timing 데이터 수집, 추적 시스템 (오픈 소스)
• Google Drapper 에서 발전하게 되었으며 분산환경에서의 시스템 병목 현상 파악
• Collector, Query Service, Database WebUI로 구성되어 있다
• span
  • 하나의 요청에 사용되는 작업의 단위
  • 64bit unique ID
• Trace
  • 트리 구조로 이뤄진 Span 셋
  • 하나의 요청에 대한 같은 Trace ID 발급
• 예를 들어 사용자의 요청이 한번 이루어지면 TraceId가 만들어지고 그러한 TraceId를 가지고 사용자가 요청한 과정에 사용된 서비스로 진행이 될때마다 spanId가 1씩 늘어나듯이 관리가 된다.

 

• zipkin의 구성
  • Zipkin Client Library
  • 정보 수집을 담당하고, 수집한 것들을 Collector 모듈로 전송한다
  • Zipkin Server
  • Collector ▶ Storage ▶ API ▶ WebUI 로 구성되어 있다
  • storage에는 in-memory와 ES방식이 존재하는데 규모가 커지면 ES를 사용하는것이 좋다

 

💼 Spring cloud Sleuth

Zipkin과 함께 사용하기 위해 분산 처리를 도와주는 유용한 Spring 에서 지원하는 Sleuth라는것이 있다. 

앞서 추적을 위한 ID가 필요하다고 말했었는데 이를 Sleuth가 도와준다. 또한 Sleuth는 추적된 Tracing 기록을 자동으로 Zipkin에 삽입해준다.

• 대략적인 그림으로 보면 이런 느낌이다

💼 zipkin의 설치 

• 간단하다 밑의 내용을 cloud가 있는 폴더내부에 작성하여 설치하고 켜주면 되고 완성되면 사진 같은 화면을 볼 수 있다.

curl -sSL https://zipkin.io/quickstart.sh | bash -s
java -jar zipkin.jar

👿 Sleuth의 Deprecated

실습을 진행하기 전에 Sleuth가 Deprecated되었다는 사실을 알았다. Sleuth를 보면 SpringBoot 3버전 이후로 부터 사용할 수 없다고 하는데 안타깝게도 나도 3을 넘어버렸다. 때문에 우리는 Zipkin과 sleuth의 기능이 합쳐진 brave를 사용할 예정이다.

 

💼 실습을 통한 분산 추적

추가하기에 앞서 이건 User 와 Order 모두 동시에 넣어주어야 한다.

♬ 라이브러리 추가

• 브레이브는 분산 추적을 위한 오픈소스 라이브러리이다.
• io.micrometer:micrometer-observation
  • 마이크로미터에서 관창을 수행하는데 사용된다.
  • 어플리케이션의 성능 지표를 측정하고 모니터링 할 수 있다.
• io.micrometer:micrometer-tracing-bridge-brave
  • 마이크로미터와 브레이브 사이의 트레이싱 브릿지를 제공한다
  • 해당 브릿지는 마이크로미터를 사용해서 수집된 메트릭과 브레이브를 사용해서 데이터를 통합
• io.zipkin.reporter2:zipkin-reporter-brave
  • 브레이브와 zipkin의 통합을 의미한다
  • zipkin reporter는 추적데이터를 zipkin 서버로 보낸다.
• io.github.openfeign
  • TraceID가 FeignClient로 인해 새로운 요청으로 잡혀 변환되는 것을 막아준다.

 

---

 

♬ yml 파일 내용 추가

• management.tracing
  • sampling.probability= 추적 데이터를 수집할 때 사용할 샘플링 확률을 정한다. 1.0으로 설정되면 모든 작업이 추적된다.
  • propagation
    • consume : B3 = B3 포맷으로 받은 추적 데이터를 사용한다
    • produce : B3_MULTI = B3_MULTI 포맷으로 추적 데이터를 생성한다.
• zipkin
  • tracing
    • enpoint : http://localhost:9411/api/v2/spans
    • Zipkin 서버를 연결한다.
• logging.pattern.level : %5p [${spring.application.name:},%X{traceId:-},%X{spanId:-}]' 
  • 로그 레벨을 생성하여 TraceId 와 SpanID를 디버그 레벨에서 볼 수 있다.

 

---

 

♬ ServiceImpl

• 별로 달라진 것은 없다 그냥 log를 추가해주었다. 

 

---

 

♬ 요청

• 주문 요청

• 그리고 Zipkin을 통해 TraceID로 검색하면 어떤 요청이 되었는지 확인 할 수 있다

• 사용자 정보 요청을 하면 다른 서비스이지만 같은 요청에서 전달되었기 때문에 ID가 같은 것을 확인 할 수 있다.

• 이것을 zipkin을 통해 검색을 진행하면 과정을 한눈에 알아볼 수 있다

 

---

 

♬ 오류가 발생한 요청

• 우리는 try-catch 를 이용해서 억지로 오류를 발생 시킬 것이다. 
• 이후 주문을 하고 사용자의 정보를 가져오는 로직에서 오류가 발생한다.

• 이런식으로 사용자는 정상적으로 전달하지만 order가 문제가 되기 때문에 TraceId도 spanID도 안보이는 것을 확인 할 수 있다.
• zipkin에서도 붉은 색의 ! 가 발생한 것을 확인 할 수 있다. 문제가 있다는 뜻이다.

 

이렇게 마이크로 서비스는 여러개의 유기적인 서비스가 호출되기 때문에 어떤 요청으로 인해 어떤 서비스가 문제가 발생했다면 쉽게 알기 쉽지 않지만 zipkin을 사용하여 한눈에 확인 할 수 있다.
참고로 현 상태에서 각각의 마이크로 서비스가 가지고 있는 메모리 상태라던가 호출된 횟수까지 나타나게 하려면 추가적으로 모니터링 기능이 필요해진다. 이는 다음 글에서 확인해보자