사용자 요청이 여러 서비스와 DB를 거치며 느려집니다. 분산 추적으로 어느 구간의 실행이나 대기가 원인인지 어떻게 찾나요?

여러 서비스와 DB를 거친 요청의 총 시간이 길다는 사실만으로 원인 서비스를 고를 수 없습니다. 병렬 하위 호출 시간은 합이 아니라 가장 늦은 가지에 지배될 수 있고, ‘DB 조회 800ms’ 안에 연결 풀 대기 750ms와 실제 쿼리 50ms가 섞여 있을 수 있습니다. 저는 요청의 호출·큐 대기·자원 획득·실제 실행·응답 조합을 별도 구간으로 기록하고, 사용자 응답을 결정하는 경로를 우선 분석하겠습니다. 요청 문맥을 여러 경계에 연결하는 방법을 분산 추적이라고 합니다.

span의 경계를 실제 대기에 맞춥니다

trace 하나는 상위 요청을 나타내는 root span과 서비스·DB·메시지 처리 구간의 child span으로 구성합니다. HTTP 호출 span만 만들면 큐에 발행한 시점과 소비 시작 사이 대기를 놓칠 수 있으므로 producer enqueue, queue wait, consumer processing을 나누겠습니다. DB span도 connection acquire, query execution, result decode를 구분해야 SQL 튜닝과 풀 용량 조정을 혼동하지 않습니다. 병렬 호출은 시간선으로 겹침을 보여 주고, 어떤 하위 결과가 필수인지와 전체 deadline을 함께 표시해야 지연이 실제 응답에 미친 영향을 알 수 있습니다.

오류·긴 지연 요청을 보존하는 샘플링을 사용하되 모든 요청과 모든 입력을 저장하지는 않겠습니다. 사용자 ID·토큰·원문 payload를 span attribute로 넣으면 비용과 개인정보 노출이 커지므로 템플릿화한 route, 상태 분류, 안전한 내부 상관 ID를 사용합니다. trace ID를 구조화 로그와 연결하면 trace가 보여 주는 경계 전후의 상세 원인을 로그에서 찾을 수 있습니다. 시계가 완전히 같지 않아도 각 서비스의 span 부모·자식 관계와 duration을 과해석하지 않고, 서버 시각 오차가 큰 경우 수집기 보정과 이벤트 순서를 함께 확인합니다.

trace를 지표·프로파일과 교차 검증합니다

느린 trace에서 가장 긴 span을 곧바로 계산 병목으로 취급하지 않고, 대기 내부의 큐 길이·풀 대기·락 보유·하위 서비스 지연과 대조합니다. CPU가 높으면 CPU/off-CPU 프로파일로 함수와 대기를 확인하고, CPU가 낮으면 연결·락·외부 RPC를 확인합니다. sampling으로 전체 분포가 왜곡될 수 있으므로 p95·p99 지표와 오류율로 가설을 검증합니다. 추적의 성공 기준은 호출 그림이 예쁜 것이 아니라 어느 대기 예산을 줄이면 실제 사용자 지연이 줄어드는지 설명할 수 있는 것입니다.

추적은 서비스 호출만 이어 붙이는 것이 아니라 대기 예산을 분해하는 계측입니다. DB span을 connection acquire 750ms와 query 50ms로 나누면 SQL 튜닝과 풀 용량 조정을 구별할 수 있습니다. 메시지는 enqueue, queue wait, consumer processing을 나누고, 재시도에는 attempt와 원인 관계를 남깁니다. 배치 소비자는 여러 producer와 연결될 수 있어 하나의 parent만 강제로 정하면 인과관계를 잃을 수 있습니다.

RED는 요청률(Request rate), 오류율(Errors), 지속 시간(Duration)을 보는 서비스 지표입니다. trace에서 발견한 병목은 RED의 전체 분포와 p95·p99로 재확인하고, CPU가 원인이면 on-CPU profile, 대기면 off-CPU·block profile과 pool·락 지표를 대조하겠습니다. 사용자 ID·토큰·payload를 태그로 넣지 않고 안전한 상관 ID와 정규화 route를 사용하며, sampling이 빠른 요청만 보존하지 않도록 오류·긴 지연 우선 정책을 둡니다.

RED는 요청률, 오류율, 지속 시간으로 서비스의 전체 상태를 보는 세 지표입니다. trace는 그 집계 안에서 특정 요청이 어느 경계를 통과하며 기다렸는지 설명합니다. 따라서 RED로 이상을 발견하고 trace로 원인을 좁힌 뒤 프로파일·풀·락 지표로 검증하는 순서를 유지하겠습니다.