[Toss Slash 23] 분산 추적 체계 & 로그 중심으로 Observability 확보하기

분산 추적 체계 & 로그 중심으로 Observability 확보하기

세션 링크

 

많은 기업들이 기업 소프트웨어 경쟁력을 향상시키기 위해 애플리케이션을 현대화하기 위해 많은 투자를 하고있다.

현대 소프트웨어 개발에서 필수로 채택되어야 하는 것들로 여겨지는 MSA와 같은 기술은 장점만 있을까?

이러한 기술들이 가상화 및 추상화를 기반으로하고 있어 문제 발생시 추적하기 더 힘들어지고 있다.

 

동적으로 변경되는 인프라,

단일 요청을 처리함에도 여러 개의 네트워크 홉을 통과해야 하는 구조,

높은 카디널리티를 가진 지표 등은 기존의 모니터링 기반의 문제 탐색을 어렵게 한다.

그래서 겪어보지 못한 새로운 현상에 대한 가시성을 제공하고, 원인에 대한 질문을 답할 수 있는 시스템이 필요하다.

이를 Observability 라고 한다.

로그

로그는 MSA의 도입으로 점차 중요해지고 있다. 그렇다면 로그를 잘 남긴다는 것은 무엇일까.

 

• API 메서드 정보 표기
• 로그에 요청당 식별자를 생성하여 큰 흐름에서의 요청이 처리된 당시의 시스템 상황을 이해할 수 있음
• 로그를 JSON 형식으로 정형화함, 로그에 항목이 추가되거나 순서가 변경되어도 파싱하기 쉽고, 3th party 연계가 쉬움
• MSA에서는 기술적으로 여러개의 로그일 수 있지만, 비즈니스 적으로하는 하나의 요청으로 해석되는 것이 좋다.
  • 요청 별 Trace ID를 함께 전달하여, 분산된 호출 흐름을 추적할 수 있게 한다. -> 분산 추적

토스 페이먼츠의 분산 추적

Global Trace ID

비즈니스 관점에서 하나의 요청이 아닌 사용자 시나리오 전체를 이해해야 하는 상황을 맞이한다.

그래서 서비스 화면 전환 단계 전체를 엮어줄 수 있는 GlobalTrace ID를 정의한다.

 

추적 문맥 전파 항목 추가

• API를 호출한 Client 버전
• API를 호출한 Service 명
• API를 호출한 Service 버전
• API 처리와 관련된 고객사
• API 처리와 관련된 원천사

이러한 정보들 외에도 많은 정보를 함께 전파하고 있다.

요청을 받는 서비스들이 요청이 처리되는 당시 문맥을 더 잘 이해할 수 있다.

EX) 결제 실패가 자주 발생하는 것 같다. ➡️ A 금융사 관련 API 처리율이 높다. 금융사에 확인 요청을 했다.

(높은 레벨의 로그 파싱이 가능할 것 같다.)

 

추적 범위 확장

분산 추적의 범위를 MSA에만 국한하지 않는다.

시스템에 대한 전체적인 가시성을 확보하기 위해 CDN, 방화벽, LB, Istio Gateway, Istio Sidecar, 각 서비스 서버, DB에 이르기까지 Trace ID로 추적이 가능하게 해야한다.

하지만 DB나 TCP 서버는 HTTP 헤더를 넣을 수 없다.

 

DB의 경우 쿼리 주석 부분에 추적 문맥을 포함시키면 Trace ID를 전파하는 것이 가능하다.

모든 로그는 Trace ID로 추적할 수 있기 때문에 문제가 되는 쿼리, 문제가 되는 API 요청, 문제를 발생시킨 쿼리가 생성되는 메서드를 추적 가능하다.

 

TCP 프로토콜에서는 어떻게 할까?

먼저 L7 LB를 살펴보자

L7 LB는 서버의 실제 클라이언트 IP를 알아내기 위해 X-Forwarded-For 헤더를 통해 해결하고 있다.

 

L4 LB는 이러한 헤더를 추가하지 못하기 때문에 Proxy Protocol 이라는 규격을 이해할 수 있다면 클라이언트 IP 정보를 보존하며 통신을 수행할 수 있다.

 

이 아이디어를 통해 TCP 본문에 추적 문맥 정보를 심고, 서버가 규칙에 맞게 파싱하게 된다면 TCP 서버 간 추잭 문맥 전파가 가능하다.

 

Trace ID 생성은 클라이언트로 부터

프론트엔드 로직은 서버와 통신을 시작하기 전부터 로직이 실행될 수 있고 경우에 따라 서버와의 통신 이전에 사용자와의 인터랙션이 발생할수 있기 때문에 문제가 발생한 당시의 문맥을 이해하기 위해서는 Trace ID가 필요하다.

그래서 클라이언트에서 Trace ID를 생성해 웹 성능 지표, 크래시 발생 정보, 서버 통신 이력 등을 수집한다.

 

다양한 서비스 분석 시스템과 연계

에러 추적 Sentry, tag를 통해 추가적인 정보를 인덱싱, Trace ID로 검색하기 용이

APM Pinpoint, pinpoint transaction id를 MDC(Mapped Diagnostic Context)에 pTx Id라는 키로 노출하고 있으며, 이것을 로그에 함께 포함시켜 Pinpoint에서 함께 검색하도록 하고 있다.