CS Insights

분산 추적(Distributed Tracing) 시스템의 W3C Trace Context 규격과 X-B3-TraceId 전파 메커니즘

분산 추적(Distributed Tracing) 시스템의 W3C Trace Context 규격과 X-B3-TraceId 전파 메커니즘
MSA(마이크로서비스) 아키텍처로 전면 개편된 사내 이커머스 시스템에서, 특정 유저가 '결제 버튼'을 눌렀을 때 응답이 5초나 걸리는 간헐적 장애가 터졌습니다. 하지만 주문, 재고, 포인트, 결제 게이트웨이 등 50개의 컨테이너 로그를 아무리 뒤져봐도 도대체 어느 서버에서 병목이 났는지 그 인과 관계를 추적하는 것은 건초더미에서 바늘 찾기였습니다. 로그는 쏟아지는데 '맥락'이 날아가 버린 분산 시스템의 저주였습니다. 이 가시성(Observability) 제로의 악몽을 끝내기 위해 사내에 OpenTelemetry 스펙 기반의 분산 추적(Distributed Tracing) 인프라를 구축했습니다. 해결책의 코어 논리는 의외로 단순합니다. 클라이언트가 최초로 API 게이트웨이를 찌르면, 게이트웨이는 전 세계에 단 하나뿐인 고유한 Trace ID(예: X-B3-TraceId 헤더)를 만들어 HTTP 요청 헤더에 강제로 쑤셔 넣습니다. 이후 이 요청이 A 서버에서 B 서버로, 다시 RPC를 통해 C 서버의 데이터베이스로 흘러갈 때마다 이 동일한 Trace ID 꼬리표를 절대 떨어뜨리지 않고 다음 함수로 패스(Context Propagation) 시키는 것입니다. 각 서버 구간은 자신의 작업 구간(Span)의 시작 시간과 끝나는 시간을 백그라운드 UDP 패킷으로 중앙 수집기(Jaeger 등)에 쏘아 보냅니다. 일주일 뒤, 또다시 5초 응답 지연 장애가 발생했고 이번에는 중앙 대시보드에 접속해 그 단일 Trace ID를 검색했습니다. 화면에는 50개의 마이크로서비스를 관통하는 폭포수(Waterfall) 차트가 그려졌고, 결제 서버 콜은 0.1초 만에 끝났지만 '사은품 추천 외부 배너 API'를 호출하는 서드파티 구간에서 타임아웃 4.9초를 허비하고 있다는 사실을 단 10초 만에 시각적으로 적발할 수 있었습니다. 시스템 인프라 아키텍트는 단순 코드 최적화를 넘어, 이렇게 장애 구간 스스로 빛을 발하며 고장 난 위치를 외치게 만드는 통합 가시성 레이어를 깔아두는 관제탑 설계자임을 깨달았습니다.

Related Posts