마이크로서비스 아키텍처(MSA)에서는 하나의 사용자 요청이 여러 서비스를 연쇄적으로 호출하며 처리된다.
예를 들어 사용자가 주문을 하면, 주문 서비스가 호출되고 이어서 결제 서비스, 재고 서비스, 알림 서비스 등 수 개의 마이크로서비스가 함께 동작한다.
이런 구조에서는 장애나 지연이 발생했을 때 "어디서 문제가 생겼는지"를 빠르게 파악하는 것이 매우 중요하다.
이를 가능하게 해주는 기술이 바로 분산 추적(Distributed Tracing)이며, Spring Cloud에서 가장 널리 사용되는 조합이 Sleuth + Zipkin이다.

✅ 분산 추적이란?
분산 추적은 하나의 요청(Request)이 여러 서비스 간을 오갈 때 그 흐름을 고유한 Trace ID로 추적하는 기술이다.
각 서비스에서 처리 시간을 기록하고, 전체 흐름을 타임라인으로 시각화해 지연 지점, 장애 발생 지점을 확인할 수 있다.
🔍 왜 필요한가?
- 서비스 호출 간 병목 구간 파악
- 예기치 못한 응답 지연 원인 분석
- 로그 상호 연관성 확보 (같은 요청임을 파악 가능)
- 대규모 서비스 구조에서 운영자와 개발자의 관찰력 향상
🧩 Spring Cloud Sleuth란?
Spring Cloud Sleuth는 Spring Boot 기반 애플리케이션에서 자동으로 Trace ID와 Span ID를 생성하고 전파해주는 분산 추적 도구이다.
| 용어 | 설명 |
| Trace ID | 하나의 요청 전체를 식별하는 고유 ID |
| Span ID | 하나의 작업 단위 (Service or Method) 식별 ID |
Sleuth는 모든 로그에 Trace ID/Span ID를 자동으로 붙여주기 때문에, 로그만으로도 추적이 가능하다.
🔧 예시 로그
[7b0f2e4b9f1a1a16, 7b0f2e4b9f1a1a16] INFO 12345 --- [nio-8080-exec-1] o.s.web.RestController : 처리 시작
🛰️ Zipkin이란?
Zipkin은 분산 추적 데이터를 시각화하고 저장하는 서버이다.
Sleuth가 생성한 Trace 정보를 Zipkin에 전송하면, Zipkin은 이를 웹 대시보드에서 타임라인 형태로 시각화해준다.
✅ Zipkin 주요 기능
- 요청 흐름을 서비스 간 호출 순서대로 시각화
- 지연 시간, 에러 발생 구간 파악
- REST 기반 API 제공
- Spring Cloud Sleuth와 기본 연동 가능
🛠️ Sleuth + Zipkin 적용 방법
1. 의존성 추가 (Gradle)
implementation 'org.springframework.cloud:spring-cloud-starter-sleuth'
implementation 'org.springframework.cloud:spring-cloud-starter-zipkin'
2. application.yml 설정
spring:
zipkin:
base-url: http://localhost:9411
enabled: true
sleuth:
sampler:
probability: 1.0
- probability는 1.0으로 설정하면 100% 추적하며, 운영환경에서는 0.1(10%) 정도 추천
- Zipkin 서버는 기본적으로 9411 포트를 사용한다
3. Zipkin 서버 실행 (Docker)
docker run -d -p 9411:9411 openzipkin/zipkin
4. 로그 + UI 확인
- 로그에 Trace ID가 포함되어 전체 흐름 추적 가능
- Zipkin 대시보드 접속: http://localhost:9411
- 요청 흐름 확인: 서비스 호출 간 시간 소요, 실패 지점 파악
🔄 Sleuth와 Kafka 연동 시 고려사항
- Kafka 메시지 기반 통신에서도 Trace 정보를 전파하려면 Headers에 Trace ID/Span ID를 포함해야 한다.
- Micrometer Tracing 또는 Brave를 통해 Kafka의 수동 트레이싱도 가능하다.
- 메시지 컨슈머에서도 TraceContextExtractor를 활용하면 전체 트랜잭션 연결이 가능하다.
🧠 실무 적용 팁
- 각 서비스는 Sleuth가 자동으로 Trace ID를 부여하기 때문에 별도 로직 없이 로그만 보면 연관 요청을 파악할 수 있다.
- Zipkin 서버는 내부 네트워크에서 운영하거나 ELK Stack과 연계해 로그 기반 추적을 보완하는 방식도 좋다.
- 퍼포먼스 부담이 크지 않아 개발 환경에서도 쉽게 도입 가능하다.
- Spring Cloud Gateway와 함께 사용하면 API Gateway → 서비스 → DB까지 전체 흐름 추적이 가능하다.
✅ 결론
분산 추적은 마이크로서비스 구조의 투명성과 관찰 가능성(observability)을 확보하는 가장 효과적인 방법이다.
Sleuth는 로그에 추적 정보를 남기고, Zipkin은 이를 시각화하여 분석 가능하게 해준다.
특히 MSA 구조에서는 서비스 수가 많아 장애 원인 파악이 어려워지기 때문에, 분산 추적은 필수 인프라 구성요소이다.
📌 참고한 공식 문서
'MSA' 카테고리의 다른 글
| [MSA] 실무에서 자주 겪는 성능 이슈와 해결법 (4) | 2025.07.24 |
|---|---|
| [MSA] 마이크로서비스 간 트랜잭션: Saga와 Eventual Consistency (5) | 2025.07.24 |
| [MSA] 계약 테스트와 통합 테스트 전략 비교 (3) | 2025.07.24 |
| [MSA] Prometheus, Grafana로 모니터링 체계 구축하기 (0) | 2025.07.24 |
| [MSA] MSA에서 CI/CD와 무중단 배포 전략 (3) | 2025.07.24 |
| [MSA] JWT와 OAuth2로 인증 처리하는 방법 (2) | 2025.07.24 |
| [MSA] Kafka vs RabbitMQ: 메시지 기반 아키텍처 완전정복 (2) | 2025.07.23 |
| [MSA] Spring Cloud Config와 Vault로 설정 통합 관리 (0) | 2025.07.23 |