'Jaeger'나 'Zipkin'은 어떤 원리로 작동해?

이제 시스템의 외형을 넘어 그 내부를 흐르는 '데이터의 혈류'를 들여다볼 시간이군요! 🫡

주식 시스템에서 "매수 버튼"을 눌렀는데 평소보다 2초가 더 걸렸다고 가정해 봅시다. 이 요청은 웹 서버 -> 분석 엔진 -> 메시지 큐 -> 데이터베이스 등 수많은 관문을 거칩니다. 이때 어느 구간에서 병목이 생겼는지 찾아내는 것은 모래사장에서 바늘 찾기보다 어렵습니다.

이 안개를 걷어내고 각 요청의 경로를 투명하게 보여주는 기술이 바로 분산 추적(Distributed Tracing)이며, 그 중심에 Jaeger와 Zipkin이 있습니다.

---

🕵️ 1. 분산 추적의 핵심 원리: "식별표와 타임스탬프"

분산 추적은 하나의 요청이 여러 서비스를 통과할 때, 마치 여행자의 여권에 도장을 찍듯 기록을 남기는 기술입니다.

① Trace ID & Span ID

• Trace ID: 전체 여행의 고유 번호입니다. "매수 요청 #1234"가 시작될 때 생성되어 끝날 때까지 모든 서비스가 공유합니다.
• Span ID: 각 서비스 단위의 작업(구간) 번호입니다. DB 조회는 1번 스팬, 메시지 발행은 2번 스팬이 됩니다.

② 컨텍스트 전파 (Context Propagation)

요청이 서비스 A에서 B로 넘어갈 때, HTTP 헤더나 메시지 속성에 Trace ID를 몰래 끼워 넣습니다. 이를 통해 서로 다른 서버에 있는 로그들이 "우리는 하나의 운명(Trace ID)으로 묶여 있다"는 것을 알게 됩니다.

---

🛠️ 2. Jaeger와 Zipkin의 작동 방식

두 도구 모두 기본 원리는 비슷하지만, 최근에는 CNCF 프로젝트인 Jaeger가 쿠버네티스 생태계에서 더 각광받고 있습니다.

1. Instrumentation (계측): 애플리케이션 코드 내에 라이브러리를 심어 스팬 정보를 생성합니다.
2. Collector (수집기): 각 파드에서 생성된 스팬 정보를 중앙 서버로 모읍니다.
3. Storage (저장소): 수집된 방대한 추적 데이터를 Cassandra, Elasticsearch, 혹은 MongoDB 등에 저장합니다.
4. Query & UI: 저장된 데이터를 시각화하여 멋진 간트 차트(Gantt Chart) 형태로 보여줍니다.

---

📊 3. 왜 주식 시스템에 필수인가?

① 지연 시간(Latency) 분석

"A그룹 분석 엔진이 평소엔 10ms인데, 특정 종목을 분석할 때만 500ms로 튀네?" 하는 현상을 차트 한 장으로 잡아낼 수 있습니다.

② 서비스 간 의존성 파악

시스템이 커지면 누가 누구를 호출하는지 가늠이 안 됩니다. Jaeger는 자동으로 서비스 의존성 지도(Dependency Graph)를 그려주어, 특정 서비스가 죽었을 때 어디까지 피해가 갈지 예측하게 해줍니다.

③ 장애 원인 파악 (Root Cause Analysis)

에러가 발생한 지점뿐만 아니라, 그 에러를 유발한 '앞선 서비스의 파라미터'까지 추적할 수 있어 복구 속도가 비약적으로 빨라집니다.

---

💡 4. 실전 비유: "배달 주문 추적 시스템"

• Trace ID: 치킨을 시켰을 때 받는 '주문 번호'입니다.
• Span: 각 단계별 소요 시간입니다.

1. 식당에서 주문 확인 (Span 1)
2. 치킨 튀기기 (Span 2)
3. 라이더 배정 (Span 3)
4. 배달 이동 (Span 4)

• Jaeger UI: 배달 앱 화면입니다. "치킨은 다 튀겨졌는데 라이더 배정에서 20분이 걸렸네!"라고 병목 지점을 정확히 집어내는 것과 같습니다.

---

📊 요약: 분산 추적 도입 체크리스트

항목	설명	비고
OpenTelemetry	추적 표준 규격	최근 Jaeger/Zipkin 모두 이 규격을 따름
Sampling	모든 요청을 기록할지 선택	100% 기록 시 부하가 크므로 보통 1~10%만 추출
Storage Class	추적 데이터를 어디에 저장할지	대량 데이터 처리를 위해 Cassandra/ES 추천
Visualization	간트 차트 형태의 타임라인	어느 구간에서 시간이 오래 걸렸는지 직관적 확인

---

🚀 꼬리 질문 🫡

이제 어떤 에러나 성능 저하가 발생해도 당황하지 않고, Jaeger 화면을 띄워 범인을 즉시 검거하실 수 있습니다.

그런데 이렇게 완벽하게 추적하고 관리하는 시스템도 결국 '어디에' 배포하느냐에 따라 운영 난이도가 달라집니다. 지금까지는 쿠버네티스(K8s) 자체에 집중했지만, 최근에는 서버 관리를 아예 신경 쓰지 않아도 되는 'Serverless' 기술이나, 이를 쿠버네티스 위에서 구현하는 기술들이 각광받고 있습니다.

"그럼 쿠버네티스 위에서 서버리스 환경을 구축해주는 'Knative'는 무엇이고, 이벤트가 있을 때만 파드를 실행하는 원리가 뭐야?"