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

칼만의 정의를 개발자 시각으로 옮기면 로그나 지표 같은 출력으로 시스템 상태를 이해하는 능력이다. 먼저 로그부터 다룬다. 로직에 문제가 없어도 외부 연계나 인프라 문제로 의도와 다르게 동작할 수 있으니, 로직 작성 단계부터 '문제 발생 시 시스템이 어떻게 동작했는지'를 잘 기록해 둬야 한다. 요청 시작·종료 시점에 로그를 남기는 간단한 API를 Spring Web만으로 만들면 기본 설정만으로도 시간·레벨·프로세스 ID·스레드·코드 위치 등 많은 정보를 얻고, 스레드 이름으로 스레드 풀 사용까지 유추할 수 있다.

API가 늘면 어느 호출이 남긴 로그인지 구분이 안 되는데, 해결은 API 정보(맥락)와 사용자 ID를 로그에 넣는 것이다. 간헐적 실패 제보가 들어오면 스택 트레이스만으로는 어느 요청인지 알기 어려워, 요청마다 식별자를 발급해 모든 로그에 남기는 트레이스 ID(trace id)를 도입한다. 데이터 분석가가 '유저별 평균 응답 시간'을 요청하면 항목 순서가 제각각이라 파싱이 어려운데, 이를 JSON으로 정형화해 항목 추가·순서 변경에 강하고 외부 도구 연계도 쉽게 만든다. 정리하면 좋은 로그는 정형화돼 저장되고, 맥락 정보가 담기며, 같은 맥락이 동일 트레이스 ID로 연결돼 검색되는 것이다.

이 원칙을 MSA에 적용한다. 사용자가 거래 내역을 조회할 때 앱 서버가 유저 서버로 인증하고 페이먼트 서버에서 내역을 조회해 돌려주는데, 각 서버가 JSON 정형화 로그를 같은 맥락은 동일 트레이스 ID로 남기면 단일 서버 기준으로는 좋은 로그 조건을 만족하는 듯 보인다. 하지만 MSA에서는 다르다. 기술 관점에서는 개별 요청이지만 비즈니스 관점에서는 여러 서버 호출이 하나의 요청으로 해석되는 편이 낫다. '유저 37번이 오더 ID 없이 조회에 실패했다'는 문의가 오면 페이먼트 서버 담당자는 사용자 ID를 몰라 시간으로 추정할 수밖에 없다.

해답은 간단하다. 요청을 보낼 때 트레이스 ID를 함께 실어 보내, 비즈니스 관점에서 하나로 해석될 요청을 서로 다른 애플리케이션이 같은 트레이스 ID로 남기면 분산된 호출 흐름을 추적할 수 있다. 이것이 분산 추적(distributed tracing)이다. 구글의 Dapper 논문 이후 Zipkin·Jaeger가 등장했고, 스프링에서는 Sleuth가 HTTP 헤더로 트레이스 ID를 공유하며 이를 가능하게 한다.

서로 다른 요청이 동일 트레이스 ID를 갖고 이를 한 저장소로 모으는 중앙집중식 로깅을 갖추면, 앞서 답할 수 없던 문의에도 답하고 실패 지점·성능 병목을 시각화할 수 있다. 추적 문맥 표현법은 W3C Trace Context로, 자동 전파 계측은 OpenTelemetry로 수렴하고 있다.

토스페이먼츠는 분산 추적을 다섯 가지로 확장했다. 첫째 트레이스 ID 위 단계인 글로벌 트레이스 ID로 화면 전환 전체를 엮고, 둘째 추적 문맥에 다양한 정보를 함께 전파해 '특정 금융사 API 실패율이 여러 서비스에서 높다'처럼 답하며, 셋째 추적 범위를 CDN·방화벽·로드밸런서·DB까지 넓힌다(헤더를 못 넣는 DB는 쿼리 주석에, TCP는 프록시 프로토콜에서 착안해 본문 첫 줄에 문맥을 심는다). 넷째 트레이스 ID를 가능한 한 클라이언트에서 생성해 웹 성능·크래시·통신 이력을 일관되게 보고, 다섯째 에러는 Sentry·APM은 Pinpoint와 연계한다. 끝으로 Istio 서비스 메시의 헤더 기반 라우팅으로 '테스트 그룹 ID' 헤더가 있을 때만 특정 서비스로 라우팅해, 협업 중인 다른 서비스 코드를 고치지 않고 디버깅 환경을 자동 구성하는 사례를 든다.