분산 추적(Zipkin) & 이벤트 드리븐

1. 분산 추적(Zipkin)은 무엇일까?

어느 요청이 여러 서비스를 거치면 어디서 문제가 생기는지 원인을 찾아내기 어렵다.

이를 해결하기 위해 분산 추적의 Zipkin을 통해 트레이스 데이터를 수집하고 시각화해주어 어디서 문제가 발생했는지 파악할 수 있도록 도와준다. 

• 분산 추적은 분산 시스템에서 서비스 간의 요청 흐름을 추적하고 모니터링하는 방법
• 각 서비스의 호출 관계와 성능을 시각화하여 문제를 진단하고 해결할 수 있도록 도움.

1-2. 분산 추적 예시

서비스 호출 흐름 추적

• 예제 서비스 간의 호출 흐름을 추적하고, Zipkin 대시보드에서 시각화한다.
• 각 서비스 호출 시 트레이스와 스팬이 생성되고, Zipkin 서버로 전송된다.

성능 병목 진단

• Zipkin 대시보드를 통해 성능 병목이 발생하는 부분을 식별한다.
• 각 스팬의 소요 시간과 호출 관계를 분석하여 성능 문제를 진단하고 해결한다.

용어 정리

트레이스:  여러 스팬들의 집합이며, 이 스팬들이 어떤 인과관계(부모-자식 관계)를 가지고 연결되어 있는지를 보여줌

스팬: 작업 이름, 시작 시간, 종료 시간, 상태 코드, 스팬 ID, 부모 스팬 ID 등의 단일 작업

1-3. 구현

.yml 에 추가

management:
  zipkin:
    tracing:
      endpoint: "http://localhost:9411/api/v2/spans"
  tracing:
    sampling:
      probability: 1.0

 

2. 이벤트 드리븐

2-1. 기존 동기식(Request-Response)방식의 한계

[기존 방식: 동기식 체인 구조]

고객 ──> [주문 서비스] 
               │
               ├── (1) 결제 요청 ──> [결제 서비스] (대기...) ──> 완료 응답
               │
               ├── (2) 배송 요청 ──> [배송 서비스] (대기...) ──> 완료 응답
               │
               └── (3) 알림 요청 ──> [알림 서비스] (대기...) ──> 완료 응답

2-1-2. 발생하는 문제점

• 강한 결합도(Strong Coupling): 주문 서비스는 결제, 배송, 알림 서비스의 주소와 상태를 모두 알고 있어야 한다.
• 연쇄 장애(Cascading Failure): 만약 알림 서비스의 서버에 장애가 발생하여 응답을 주지 못하면, 주문 서비스까지 멈추거나 사용자에게 주문 실패 에러를 반환하게 된다.(하나의 장애가 다른 서비스에 영향을 준다)
• 응답 속도 저하(Latency): 각 서비스가 작업을 끝내고 응답을 줄 때까지 주문 서비스가 계속 기다려야하므로, 사용자가 겪는 최종 대기시간이 모든 서비스의 처리 시간을 더한 만큼 매우 길어질 수 있다.

2-2. 이벤트 드리븐(Event-Driven) 방식으로 전환

이벤트 드리븐 방식은 서비스 간에 직접 요청을 주고받지 않는다. 대신 시스템 내에 중요한 상태변화(주문 완료)가 발생하면, 이벤트를 메시지 브로커에게 전달한다.

[개선된 방식: 이벤트 기반 구조]

고객 ──> [주문 서비스] ── (이벤트 발행: "주문 완료!") ──> ┌──────────────────┐
                                                           │  메시지 브로커  │
                                                           │ (Kafka/RabbitMQ) │
                                                           └──────────────────┘
                                                             │      │      │
                                      ┌──────────────────────┘      │      └──────────────────────┐
                                      ▼                             ▼                             ▼
                              [결제 서비스]                 [배송 서비스]                 [알림 서비스]
                        ("주문 완료" 이벤트 수신 후   ("주문 완료" 이벤트 수신 후   ("주문 완료" 이벤트 수신 후
                           자신의 결제 로직 처리)        자신의 배송 로직 처리)        자신의 알림 로직 처리)

2-2-2. 이벤트 드리븐을 통해 개선되는 점

• 느슨한 결합(Loose Coupling): 주문 서비스는 이제 결제, 배송, 알림 서비스의 정보들을 각각 알필요가 없다. 단지 메시지 브로커에 이벤트만 전달만 하면된다.
• 장애 고립 및 탈력성(Fault Tolerance): 만약 하나의 서비스에 장애가 발생하여 중단되더라도, 메시지 브로커에 전달한 이벤트는 안전하게 남아있다. 따라서 시스템 전체가 마비되는 일이 사라진다.
• 압도적인 응답 속도(Asynchronous & High Performance): 주문 서비스는 메시지 브로커에 이벤트를 전달하자마자 응답을 받을 수 있다. 이들은 비동기방식으로 각자 알아서 처리하기 때문에 체감하는 서비스 속도가 매우 개선된다.