마이크로서비스 프로젝트를 진행하고 있는데 하나의 request 안에서 일어나는 마이크로 서비스간의 트랜잭션 모니터링에 대한 필요성이 생겼다.

항상 로깅작업은 프로젝트를 만들면서 언제나 생략하고 직접적인 기능 구현만 하기에 바빴지만 이번 기회에 학습해보고자 한다.

MSA에서의 로그와 추적

마이크로서비스는 여러개의 서비스가 분산되어있기 때문에 각 서비스들의 로그를 한곳에 모아 이들의 관계를 분석하고 한눈에 서비스의 로그들을 볼 수 있어야 한다.

모놀리식 아키텍쳐와 달리 마이크로 서비스는 하나의 호출이 gateway로 들어오면 내부 로직에 따라서 여러 마이크로서비를 거친 후에 응답을 하게되는 경우가 빈번하다. 이런 경우에 어떤 서비스를 순서대로 거치는지, 그 과정에서 어떤 서비스에서 문제가 생기는 것인지를 파악할 수 있어야 한다.

트렌젝션이 여러 컴포넌트의 조합을 통해서 발생하기 때문에 전통적인 APM (Application Performance Monitoring) 도구를 이용해서 추적하기가 어려워 분산 로그 추적 시스템이 생겨났다고 한다. 그중에서도 대표적인 오픈소스인 zipkin을 사용해보려고 한다.

---

ZIPKIN 구성 요소

각각의 마이크로서버에 zipkin client를 붙이고 발생한 로그를 zipkin server로 보내 저장한다.
이때 서버 기본 storage는 in-memory이지만 mysql, elasticsearch, cassandra등이 있다.

Trace와 Span

Trace와 Span은 분산 시스템 추적에서 핵심적인 개념이다. 대부분의 시스템들은 Google의 Dapper 스타일의 추적 방식을 사용하는 것으로 알고 있다.

Trace

• 클라이언트에서 서버에 요청한 하나의 request라고 생각하면 된다.
• Trace는 Span의 집합으로 구성된다.

Span

• RPC추적을 위한 기본 단위이다. RPC가 도착했을 때 처리한 작업을 나타내며 추적에 필요한 데이터가 들어있다.
• 해당 Trace에 대한 응답을 보내주기 위해 msa 내부에서 이뤄지는 서비스간의 호출이라고 생각하면 쉬울 것 같다.
• Span은 Trace ID를 가지고 있다.

이렇게 분류를 하게 되면 하나의 클라이언트 호출(Trace)마다 어떤 span, 즉 어떤 서비스 호출이 일어났는지를 추적할수가 있다. 위의 그림을 천천히 따라가보면 이해가 될 것이다.

그리고 추적한 로그들을 zipkin 대쉬보드에서는 아래와 같이 시각화하여 보여준다.

---

참고

네이버에서 만든 분산아키텍처 로깅 라이브러리: NAVER D2

node에서 실험적으로 제공하고 있는 Async Hooks. 라이프사이클 추적이 가능하다: Logging in microservices

가장 대표적인 분산 아키텍처 오픈소스 Zipkin
Zipkin을 이용한 MSA 환경에서 분산 트렌젝션의 추적 #1
마이크로서비스 분산 모니터링