장애 한 건을 서비스 여러 곳에서 추적하는 방법

고객이 ‘주문 버튼을 눌렀는데 오래 걸렸다’고 말하면 API 서버 로그만으로 원인을 찾기 어렵습니다. 요청은 인증, 주문, 재고, 결제, 알림 서비스를 지나갈 수 있습니다. 같은 요청을 서비스 전체에서 연결할 추적 식별자가 필요합니다.

요청의 시작에서 식별자를 만든다

입구에서 추적 ID를 생성하거나 신뢰할 수 있는 상위 시스템의 추적 문맥을 받습니다. 각 서비스 호출과 비동기 메시지에 같은 문맥을 전파해 한 업무의 경로를 연결합니다. 추적 ID를 사용자가 보낸 값 그대로 신뢰하면 다른 요청의 로그를 섞거나 관측 시스템을 오염시킬 수 있습니다. 외부에서 들어온 추적 문맥은 형식과 신뢰 경계를 확인하고 필요하면 새 내부 추적을 시작합니다.

구간별 시간을 분리한다

전체 5초가 API 계산 때문인지 DB 대기인지 외부 결제 응답인지 스팬별로 봅니다. 서비스 이름, 작업 이름, 시작·종료 시각, 오류 상태를 일관되게 남겨야 병목을 찾을 수 있습니다.

비동기 경계도 이어 준다

요청이 큐에 들어간 뒤 워커가 처리하면 HTTP 요청은 끝났어도 업무는 계속됩니다. 메시지 메타데이터에 추적 문맥을 넣고 소비 단계에서 새 스팬으로 연결합니다.

민감정보를 태그로 넣지 않는다

고객 이름, 토큰, 주문 본문을 추적 속성에 무분별하게 넣으면 관측 시스템이 개인정보 저장소가 됩니다. 추적에 필요한 식별자는 접근이 통제된 내부 ID와 결과 코드로 제한합니다.

샘플링과 장애 보존을 구분한다

모든 요청의 상세 스팬을 영구 저장하면 비용이 큽니다. 평상시에는 샘플링하되 오류와 느린 요청을 분석할 수 있는 보존 정책을 마련하고 로그·메트릭과 같은 ID로 연결합니다.

현장에 적용할 때의 순서

1. 요청 입구에서 추적 문맥 생성
2. 서비스·큐 경계마다 문맥 전파
3. 스팬·로그·메트릭을 동일 ID로 연결

주의할 실패: 서비스별 로그 시각만으로 한 요청을 추정

관찰할 지표: 느린 요청 원인 식별 시간·누락 스팬 비율

적용 전 체크리스트

• 서비스와 큐 경계에 추적 문맥을 전파한다
• 스팬별 대기·오류 시간을 분리한다
• 추적 속성에서 민감값을 제외한다

참고 자료

OpenTelemetry — Traces. 스팬과 추적 문맥의 개념은 OpenTelemetry 공식 문서를 참고했습니다. 샘플링·민감정보 정책은 운영 환경에 맞춘 적용 제안입니다.

이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.

#분산추적 #TraceID #OpenTelemetry #관측성 #마이크로서비스 #장애분석 #API성능 #로그 #비동기 #SaaS운영