[배달 중계 서비스#6] Zipkin과 OpenTracing

OpenTracing을 적용하는 이유

모놀리식 아키텍처 서버와는 다르게, MSA 아키텍처 구조의 서버는 요청으로 인해 생기는 작업을 하나의 쓰레드가 담당하지 않는 경우가 빈번하다.
이로 인해 로그 또한 각 서비스로 분산되기 마련이다.
이렇게 분산 된 로그는 OpenTracing의 도움 없이는 추적하기가 굉장히 어렵다.
트레이싱 기술을 적용하면 traceId를 통해 검색과 식별을 할 수 있고, 각 서비스들의 호출 순서를 타임라인과 함께 볼 수 있어 에러가 발생한 구간도 식별이 가능하다.

더 자세한 내용은 아래의 글에서 확인할 수 있다.
https://engineering.linecorp.com/ko/blog/line-ads-msa-opentracing-zipkin

LINE 광고 플랫폼의 MSA 환경에서 Zipkin을 활용해 로그 트레이싱하기

 

---

Spring Boot 버전에 따른 차이

Spring Boot 2.x 까지는 자체적으로 프레임워크가 트레이싱 기술을 가지고 있지 않았다.
때문에 Spring Cloud Sleuth 의존성을 추가해 Spring Boot가 트레이싱 기술을 사용하고,
Spring Cloud Sleuth는 Sprign Boot를 의존하는 상호 의존적인 관계를 유지해야 했다.

Spring Boot 3.x 에서는 이러한 문제를 개선하고자 Spring Boot에서 자체적으로 트레이싱 기능을 사용할 수 있도록 Micrometer에 트레이싱 기능을 추가했다.
때문에 MSA 구조에서 OpenTracing을 적용하기 전에, Spring Boot 버전을 확인해야 한다.

더 자세한 내용은 아래의 글에서 확인할 수 있다.
https://techblog.lycorp.co.jp/ko/how-to-migrate-to-spring-boot-3

실전! Spring Boot 3 마이그레이션

 

 

Spring 2.x Gradle 의존성

implementation "org.springframework.cloud:spring-cloud-starter-sleuth"  
implementation "org.springframework.cloud:spring-cloud-sleuth-zipkin"

 

Spring 3.x Gradle 의존성

implementation 'io.zipkin.reporter2:zipkin-reporter-brave'  
implementation 'org.springframework.boot:spring-boot-starter-actuator'  
implementation 'io.micrometer:micrometer-tracing-bridge-brave'

---

Spring Boot 3.x에서 Zipkin 적용하기

현재 진행 중인 배달 중계 서비스는 Spring Boot 3.3.1 이므로, brave + zipkin으로 OpenTracing을 적용했다.

yml 파일은 다음과 같이 작성했다.

management:  
  endpoints:  
    web:  
      exposure:  
        include: "*"  
  tracing:  
    sampling:  
      probability: 1  
    propagation:  
      consume: B3  
      produce: B3  
  zipkin:  
    tracing:  
      endpoint: http://localhost:9411/api/v2/spans  

logging:  
  pattern:  
    level: "%5p [${spring.application.name:},%X{traceId:-},%X{spanId:-}]"  
  level:  
    io.micrometer.tracing: DEBUG  
    brave: DEBUG  
    org.springframework.web: DEBUG

 

probability: 1 같은 경우는 발생하는 모든 로그를 수집하겠다는 의미인데, 이는 보통 개발 과정에서 로그 추적을 편하게 하기 위해 사용하는 수치이다.
실제 운영 과정에서는 0.03과 같이 낮은 수준으로 수정하지 않으면 어마어마한 부하가 발생한다.

 

propagartion 밑의 두 항목은 어떤 방식으로 Tracing을 전파하기 위한 표준이다.
consume 은 외부에서 현재 서비스로 도착한 요청의 추적 문맥을 해석하는 방식을 설정하며,
produce 는 현재 서비스에서 외부로 추적 문맥을 전파하는 방식을 설정한다.

설정에는 B3, B3-multi, W3C 세 종류가 존재한다.
B3 : 트레이싱 정보를 HTTP 헤더에 포함시킨다.
B3-multi : B3를 확장하여 트레이싱 정보를 각각 개별적인 HTTP 헤더에 나누어 전송한다.
W3C : HTTP 헤더로 트레이스 컨텍스트 정보를 전파한다.
Zipkin을 사용한다면 주로 B3, B3-multi를 사용하며, W3C는 보다 넓은 범위의 표준을 목표로 한다.
환경과 요구 사항에 맞게 선택하여 사용하도록 하자.

 

endpoint는 Zipkin 서버를 실행한 host:port에 /api/v2/spans 를 붙이면 된다.

 

위와 같이 시각화 된 정보로 로그를 추적하고 문제를 진단할 수 있다.