SpringBoot MSA 로깅: Zipkin을 사용한 분산 추적에서 예외상황을 다루는 방법

이번 포스트에서는 저번 포스트에서 설명하지 못했던 서버 간 통신에서 예외가 발생했을 때는 Zipkin 추적을 어떻게 할지 설명한다.

 

1. Zipkin 예외처리를 위해 @SqsListener 메서드 분석하기

---

1-1. 레시피 서버의 @SqsListener 메서드를 다시 한번 확인해 보자

• 이전 포스트부터 기록해둔 SqsListener 코드에는 이미 try-catch-finally가 되어있는데 이건 추적에 대한 예외처리가 완료된 상황의 코드다. 이렇게 포스트를 작성한 이유는 모든 동작에 이상이 없는 것을 확인하고 블로그에 글을 작성했더니 예외처리가 된 채로 코드를 캡처해서 글을 작성하게 되어버렸다.

레시피 서버의 sqs리스너 코드

 

1-2. Zipkin추적의 예외처리가 적용될 try-resource문법

sqsListener 내부의 zipkin span 추적 코드

여기서 중요한 부분은 catch문이다. 만약 코드를 catch문 없이 finally만 작성한다면 예외가 발생해도 Zipkin에 예외로그를 따로 남기지 않은 채로 처리가 된다. (에러가 발생했는지 알기가 어렵다.)

 

 

2. catch문의 유무에 따른 Zipkin의 예외처리 검증

---

2-1. catch문이 작성되어있지 않은 상황에 예외 발생시키기

• 예외가 발생한 상황을 만들기 위해 코드로 throw Exception()을 작성해서 가짜 예외를 일부로 발생시켰다.

zipkin 추적코드에 catch를 적지 않았다.

 

새로운 요청이 발생했을때 Zipkin이 추적한 요청의 결과는 아래와 같다. 지금 분명히 내가 일부로 예외를 발생시켰는데 Zipkin의  추적 로그에는 도대체 어느 요청에서 예외가 발생해서 추적이 멈춘 것인지 알 수가 없는 상황이다. 그냥 결과 화면만 보면 추적이 잘 된으로 보이기도 한다.

물론 Zipkin을 사용할 줄 알고 모든 추적과정을 알고 있다면 맨 마지막 요청에서 오류가 발생해서 더 이상 추적이 진행되지 않고 멈추었다는 것을 알 수 있겠지만 이런 식으로 감으로 추적하려고 Zipkin을 사용하는 것은 아니기에 예외처리가 꼭 필요했다.

catch문이 없을때 zipkin의 추적

 

2-2. catch문을 작성하고 예외 발생시키기

일부로 예외를 발생시킨다.

 

catch문을 작성하고 나서 다시 Zipkin의 추적을 살펴봤더니 이제는 추적 결과에 요청 도중 예외가 발생해서 추적이 멈췄던 부분이 ! 표시로 나와있어서 어디에서 요청이 실패했는지 바로 알 수 있었다. 또한 이번에는 이 추적이 예외가 발생해서 멈춘 것이라는 것을 육안으로 바로 확실하게 알 수 있었다.

Zipkin 추적에 에러표시가 나온다.

 

 

이렇게 내가 Zipkin에서 예외처리를 적용해 본 것을 설명했다. 사실 Zipkin을 통해 분산 추적을 하는 것도 중요하지만 더 중요한 것은 예외상황에 대한 추적이라고 생각한다. 결국 Zipkin을 사용하는 이유도 예외가 발생했을 때 조금 더 편하게 예외가 발생한 상황을 확인할 수 있게 하기 위해서이기 위해서이기 때문이다.

 

 

 

다음 포스트에서 이어지는 내용은 ALB헬스 체크를 설정해보는 내용입니다!

Zipkin 로그 최적화: AWS ALB 헬스 체크 설정과 로그 추적 간소화

이 포스트는 Team chillwave에서 사이드 프로젝트 중 적용했던 부분을 다시 공부하며 기록한 것입니다.
시간이 괜찮다면 팀원 '평양냉면7'님의 블로그도 한번 봐주세요 :)

하다보니 재미있는 개발