🔧
DevOps
Zipkin
분산 추적 수집 및 조회 시스템
상세 설명
Zipkin은 Twitter에서 개발한 오픈소스 분산 추적 시스템입니다. Google의 Dapper 논문에서 영감을 받아 2012년에 시작되었으며, 마이크로서비스 환경에서 요청이 여러 서비스를 거치는 경로를 시각화하고 지연 시간을 분석합니다.
핵심 개념으로 Trace(전체 요청 흐름), Span(개별 작업 단위), Annotation(타임스탬프 이벤트)이 있습니다. 각 Span은 traceId로 연결되어 하나의 요청이 10개 서비스를 거쳐도 전체 흐름을 추적할 수 있습니다.
아키텍처는 Collector(데이터 수집), Storage(Cassandra, Elasticsearch, MySQL 지원), Query Service(검색 API), Web UI(시각화)로 구성됩니다. 각 서비스에서 instrumentation 라이브러리가 자동으로 Span을 생성하고 Collector로 전송합니다.
실무에서는 Spring Cloud Sleuth, OpenTelemetry와 연동하여 자동 계측합니다. P99 지연 시간 분석, 서비스 간 의존성 맵 생성, 특정 요청의 병목 지점 찾기에 필수적이며, 장애 발생 시 어느 서비스에서 문제가 생겼는지 5분 내 파악 가능합니다.
코드 예제
# docker-compose.yml - Zipkin 서버 실행
version: '3'
services:
zipkin:
image: openzipkin/zipkin:latest
ports:
- "9411:9411"
environment:
- STORAGE_TYPE=elasticsearch
- ES_HOSTS=elasticsearch:9200
depends_on:
- elasticsearch
elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch:7.17.0
environment:
- discovery.type=single-node
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
ports:
- "9200:9200"
---
# Spring Boot application.yml 설정
spring:
application:
name: order-service
zipkin:
base-url: http://zipkin:9411
sender:
type: web
sleuth:
sampler:
probability: 1.0 # 개발: 100%, 운영: 0.1(10%)
---
# OpenTelemetry Java Agent 사용 시
# java -javaagent:opentelemetry-javaagent.jar \
# -Dotel.exporter.zipkin.endpoint=http://zipkin:9411/api/v2/spans \
# -Dotel.service.name=payment-service \
# -jar app.jar실무에서 이렇게 말해요
시니어: "결제 API 응답이 느리다는 CS가 있는데, Zipkin에서 traceId 찾아볼 수 있어요?"
주니어: "네, 해당 시간대 검색해보니 inventory-service에서 3초 지연이 있었네요. DB 쿼리 튜닝이 필요해 보여요."
면접관: "Zipkin과 Jaeger의 차이점을 알고 계신가요?"
지원자: "둘 다 분산 추적 도구지만, Jaeger는 CNCF 프로젝트로 Kubernetes 친화적이고 적응형 샘플링을 지원합니다. Zipkin은 더 가볍고 다양한 언어 지원이 풍부해서 레거시 시스템과 통합에 유리합니다."
리뷰어: "sampler.probability가 1.0인데, 운영에서는 오버헤드 문제 없을까요?"
개발자: "운영 환경용 설정 파일에서는 0.1로 낮춰놨습니다. 프로파일별로 분리되어 있어요."
주의사항
- 운영 환경에서 100% 샘플링은 성능 저하 유발 - 5-10% 샘플링 권장
- Trace 데이터 저장소 용량 계획 필수 - 일주일 보관에 수백GB 필요
- 비동기 메시지 큐 추적 시 traceId 전파 명시적으로 구현 필요
- 에러 발생 요청은 100% 샘플링 - 정상 요청만 낮은 비율 적용