Spring

[Spring]비동기 메시지 큐 (Kafka & RabbitMQ)

코딩로봇 2025. 6. 20. 17:07

이번 프로젝트에서 모의 투자 서비스의 성능을 크게 좌우하는 핵심 기능은 "주문 체결"이다.

기존에는 스케줄러 기반의 주기적 체결 방식으로 구현되어 있었지만, 실시간 가격 변화에 즉시 반응하지 못해 성능과 트래픽 측면에서 한계가 있었다.

이를 개선하기 위해, 실시간 체결 시스템에 적합한 메시지 브로커를 도입하고자 하였고, 그 선택의 타당성을 확인하기 위해 먼저 메시지 브로커 개념을 이해하고, Kafka와 RabbitMQ를 비교 분석하였다.

💡 "메시지 브로커(Message Broker)는 분산 시스템 간 데이터를 안정적으로 주고받기 위한 미들웨어로, 발신자(Producer)와 수신자(Consumer) 사이에서 메시지를 큐에 저장하고 비동기로 전달하는 역할을 한다.

 

 

✅ 메시지 브로커 이해

    • 메시지 큐(MQ)는 생산자가 보낸 메시지를 큐에 저장해 두었다가 소비자가 가져가 처리하는 구조로 동작한다.
    • 이 방식은 직접적인 통신이 아닌 큐를 통한 중개 방식으로 다음과 같은 장점이 있다:

 

📌메시지 큐의 장점

  • 비동기 처리: 메시지를 즉시 처리하지 않아도 된다.
  • 낮은 결합도: 생산자와 소비자가 서로를 몰라도 된다.
  • 확장성 및 탄력성: 장애에도 메시지를 보존하며 확장에 유리함

 

✅ Kafka 란?

  • Kafka 는 LinkedIn에서 개발한 분산 메시징 시스템으로, pub-sub(발행/구독) 모델 기반의 로그 중심 구조를 가진다. 

 

 

 

📌 Kafka 기본 동작 구조

  • Producer 는 메시지를 특정 Topic으로 전송
  • consumer 는 원하는 Topic을 구독하여 메시지를 가져감
  • Topic은 병렬 처리를 위해 여러 Partition으로 분산 저장
  • Broker는 메시지를 저장하고 제공하는 Kafka 서버이며,
  • Zookeeper는 클러스터의 상태 및 리더 선출 등을 담당하는 관리자 역할

위의 그림을 보면서 이해하면 쉽지만,Topic 이라는 단어는 좀 생소하기 때문에 따로 한번 정리를 봐도 좋을 것 같다.

 

❓ Topic 이란?

  • Kafka 에서 하나의 메시지는 Topic으로 분류되며, 하나의 Topic은 다수 개의 Partition으로 나뉜다. 이 구조는 병렬 처리와 데이터 분산을 가능하게 만든다.

즉,

  • Topic: 메시지의 논리적인 분류 단위
  • Partition: 메시지의 실제 저장 단위, 병렬 소비를 가능하게 함

 

📌Kafka 만의 주요 특징

  1. 메시지를 파일 시스템에 저장하여 영속성 보장
  2. Consumer가 Broker에서 직접 가져가는 Pull 방식
  3. Producer 중심적인 구조로 파티셔닝 최적화
  4. Consumer가 메시지의 읽은 위치를 직접 기억하여 재처리 가능
  5. 대규모 로그 처리와 이벤트 스트리밍에 강점

 

✅RabbitMQ 란?

  • RabbitMQ는 AMQP 프로토콜 기반의 메시지 브로커로, Exchange를 통해 메시지를 큐로 라우팅하는 구조다.
💡 AMQP란?
  Client와 Middleware broker간의 메시지를 주고받기 위한 프로토콜

 

 

 

※ 참고: RabbitMQ는 기본적으로 메시지 브로커(Message Broker)이지만, Exchange 및 Queue 구조를 활용해 이벤트 라우팅도 가능하므로, 이벤트 기반 트리거 시스템에서도 널리 사용된다.

📌 RabbitMQ 기본 동작 구조

  • Producer : 메시지를 Exchange로 전송
  • Exchange: 메시지를 특정 규칙에 따라 큐로 라우팅
  • Queue: 라우팅된 메시지를 버퍼링하고 소비자에게 전달
  • Consumer: 큐에서 메시지를 받아 처리

 

여기서 Kafka 와의 차이가 들어난다 .

바로 Queue로 들어가기 전, Exchange라는 단계를 거친다는 점이다.

RabbitMQ에서 메시지는 곧바로 Queue에 들어가지 않고, Exchange가 메시지를 규칙에 따라 Queue에 넣는 역할을 수행한다.

 

📌 RabbitMQ의 주요 특징

  1. Broker가 직접 Consumer에게 메시지를 전달하는 Push 방식
  2. Exchange 타입에 따라 다양한 라우팅 전략 (Direct, Fanout, Topic 등)
  3. Spring AMQP 등 다양한 라이브러리와 높은 호환성
  4. UI 제공 및 운영 도구가 풍부해 관리 용이
  5. 실시간 이벤트 기반 시스템에 적합
  6. Broker 중심 설계로 메시지 전달의 신뢰성 보장

 

 

모의투자 어플에서 중요한 로직인 체결 시스템에선 어떤 것이 더 적합할지 비교를 위해 특징을 정리해보았다.

 

✅ Kafka vs RabbitMQ 비교

 

  kafka RabbitMQ
유형 이벤트 브로커 (Event Broker) 메시지 브로커 (Message Broker)
모델 Pub/Sub 기반 (로그 중심) AMQP 기반 (브로커 중심)
메시지 전달 방식 Pull (Consumer가 가져감) Push (Broker가 전달)
처리량 초고속 대용량 중간 (지연 적고 빠름)
실시간성 낮음 (로그 기반 지연 허용) 높음 (즉시 전달)
메시지 저장 디스크 영속 저장 기본 휘발성, 옵션으로 지속 저장 가능
관리 도구 CLI 중심, 설정 복잡 UI 제공, 운영 용이
적합한 분야 로그 수집, 대규모 스트림 처리 이벤트 기반 트리거, 주문/결제 등 실시간 처리

 

 

📌 어떤 상황에서 어떤 메시지 브로커가 적합할까?

  • Kafka가 적합한 경우
    • 수백만 건 이상의 로그 또는 이벤트 데이터를 빠르게 수집하고 분석해야 하는 경우
    • 대규모 분산 시스템에서 데이터 파이프라인, 스트림 처리, 로그 수집이 주목적인 서비스
    • 메시지의 순서 보장, 장기 보관, 재처리 기능이 중요한 경우
    • 대량 데이터를 파티셔닝하여 병렬로 소비할 필요가 있는 경우
  • RabbitMQ가 적합한 경우
    • 주문, 결제, 알림과 같이 즉시 반응해야 하는 이벤트 트리거 기반의 시스템
    • 다양한 라우팅 방식이 필요한 경우 (특정 조건에 따라 큐를 다르게 설정해야 하는 시나리오)
    • 운영 UI가 필요하고, 관리 편의성과 빠른 배포가 중요한 경우
    • 메시지 소비 순서를 엄격하게 보장하지 않아도 되는 환경에서 단순하면서 신뢰성 높은 전달이 필요한 경우

 

✅ 결론

Kafka와 RabbitMQ는 각각의 강점이 분명하며, 사용 목적에 따라 선택 기준이 달라진다.

대용량 로그 수집이나 데이터 파이프라인처럼 처리량과 확장성이 중요한 경우 Kafka가 유리하지만, 낮은 지연 시간과 정밀한 라우팅, 실시간 트리거 반응이 중요한 서비스에서는 RabbitMQ가 더 적합하다.