Zipkin 분산 추적과 이벤트 기반 아키텍처 학습

오늘 학습한 개념

• Zipkin을 활용한 분산 추적

• 이벤트 기반 아키텍처

• 메시지 큐 활용 방식

  ---

Zipkin 분산 추적과 요청 흐름 분석

MSA에서는 하나의 요청이 여러 서비스를 거쳐 처리된다.

예를 들어 주문 요청이 들어오면 주문 서비스, 상품 서비스, 사용자 서비스 등이 함께 동작할 수 있다.

이때 문제가 발생하면 단일 애플리케이션보다 원인을 찾기 어렵다.

그래서 분산 추적을 사용해 어떤 서비스를 거쳤는지, 각 단계에서 시간이 얼마나 걸렸는지 확인한다.

Zipkin은 이런 요청 흐름을 Trace와 Span 단위로 수집하고 시각화해 주는 도구이다.

• Trace: 하나의 요청 전체 흐름

• Span: 요청 흐름 안에서 개별 작업 단위

• Zipkin의 역할: 서비스 간 호출 관계와 지연 구간을 시각적으로 확인하게 해줌

이를 통해 어느 서비스에서 병목이 발생했는지, 어떤 호출이 실패했는지 빠르게 파악할 수 있다.

이벤트 기반 아키텍처와 메시지 큐

이벤트 기반 아키텍처는 서비스들이 직접 서로를 강하게 호출하기보다, 이벤트를 발행하고 필요한 서비스가 이를 구독하는 방식으로 동작한다.

예를 들어 주문이 생성되면 주문 서비스가 “주문 생성됨” 이벤트를 발행하고, 알림 서비스나 재고 서비스가 이 이벤트를 받아 각자의 작업을 수행할 수 있다.

이때 메시지 큐는 이벤트를 중간에서 안전하게 전달하는 역할을 한다.

메시지 큐를 사용하면 다음과 같은 장점이 있다.

• 서비스 간 결합도를 낮출 수 있다.

• 한 서비스가 잠시 장애가 나도 메시지를 나중에 처리할 수 있다.

• 비동기 처리로 응답 속도를 개선할 수 있다.

• 트래픽이 몰릴 때 요청을 완충할 수 있다.

  ---

느낀 점

분산 추적에서는 Trace와 Span의 차이를 이해하는 것이 중요하다고 느꼈다.

또 이벤트 기반 아키텍처에서는 단순히 메시지를 주고받는 것이 아니라, 서비스 간 의존성을 줄이고 장애 전파를 완화하는 목적이 핵심이라는 점을 다시 확인했다.

회고

처음에는 Zipkin과 메시지 큐가 서로 별개의 개념처럼 느껴졌지만, 둘 다 MSA에서 운영 안정성을 높이기 위한 도구라는 공통점이 있었다.

Zipkin은 ‘문제가 어디서 발생했는지 추적하는 도구’에 가깝고, 메시지 큐는 ‘서비스들이 느슨하게 협력하도록 도와주는 구조’에 가깝다.

앞으로 프로젝트에서 서비스 간 호출이 많아질수록 단순히 기능 구현만 하는 것이 아니라, 요청 흐름을 추적할 수 있는지, 서비스 간 결합도가 너무 높지는 않은지를 함께 고려해야겠다고 느꼈다.

QnA

Q 왜 메시지 큐가 비동기 처리인지

• 동기 처리는 보통 이렇게 동작
  • 주문 서비스가 결제 서비스에 요청 → 결제 완료될 때까지 기다림 → 다음 처리

  즉, 상대 서비스의 처리가 끝날 때까지 기다려야 함

• 반면 메시지 큐를 쓰면 흐름이 달라짐
  • 주문 서비스가 ‘결제 요청 메시지’를 큐에 넣음 → 주문 서비스는 일단 자기 일을 마침 → 결제 서비스가 나중에 큐에서 꺼내 처리

  핵심은 요청한 쪽이 상대방의 처리가 끝날 때까지 기다리지 않는 것

⇒ 따라서 메시지 큐 기반 처리는 비동기 처리라고 볼 수 있음

비유하면, 친구에게 직접 전화해서 답을 들을 때까지 기다리는 건 동기 처리이고, 메신저를 보내두고 나는 다른 일을 하는 건 비동기 처리

Q 트래픽 완충의 의미

트래픽이 갑자기 몰리면 서비스가 한 번에 처리할 수 있는 양을 넘을 수 있음

예를 들어 결제 서비스가 1초에 100건만 처리할 수 있는데, 갑자기 1초에 1,000건이 들어오면 바로 장애가 잘 수 있음

메시지 큐가 있으면 요청을 바로 결제 서비스에 몰아넣지 않고, 큐에 일단 쌓아둘 수 있음

• 요청 1,000건 도착 → 큐에 저장 → 결제 서비스가 처리 가능한 속도로 하나씩 꺼내 처리

이렇게 큐가 중간에서 충격을 흡수해 주기 때문에 ‘완충한다’고 표현함

마트 계산대 앞에 줄을 세우는 것과 비슷함. 손님이 한 번에 몰려도 계산원이 감당 가능한 속도로 한 명씩 처리하는 구조

• 비동기 처리: 요청한 서비스가 결과를 끝까지 기다리지 않고 메시지만 남긴 뒤 다음 일을 할 수 있음

• 트래픽 완충: 갑자기 몰린 요청을 큐에 쌓아두고, 소비자가 처리 가능한 속도로 나눠 처리함