RabbitMQ 기본 개념 정리 (+ RabbitMQ vs Kafka vs ActiveMQ)

 

 

이전 회사에서는 메세지 브로커(Message Broker)의 역할로서 Kafka와 ActiveMQ를 주로 사용하였습니다. 새로운 회사에서는 Kafka와 RabbitMQ를 사용하게 되어 관련 내용을 정리해보려고 합니다. 어떤 점이 다르고, 왜 RabbitMQ를 사용하는 것일까요?

 

 

 

로고가 꽤 귀엽습니다

 

 

MSA 아키텍처 관점에서 메세지 브로커는 왜 필요할까요?

쉽게 이야기 해서 A 서비스와 B 서비스 간의 직접 호출을 하지 않고, 중간에 메세지 큐를 두고 비동기적인 통신을 하기 위해서 입니다. 이 이야기는 이전에 작성한 이벤트 드리븐 방식(EDA)의 아키텍처에 대한 이야기와 이어집니다. 메세지 브로커는 해당 아키텍처를 구현하기 위한 하나의 도구 라고 이해하면 좋을 것 같습니다. 

 

https://minchoi0912.tistory.com/130

MSA와 이벤트 드리븐 아키텍처(Event-Driven Architecture, EDA) 간단하게 알아보기

 

 

간단히 이야기 하면 MSA 아키텍처에서의 서비스 간의 호출이 HTTP 동기 방식으로 연결하게 되면 전체 서비스 자체의 장애가 발생 할 수 있기 때문에 서비스 간 결합도를 낮추고, 트래픽 버퍼 역할, 장애 격리, 확장성 역할을 위해서 메세지 브로커를 사용하게 됩니다. 

 

 

RabbitMQ란?

AMQP 프로토콜을 구현한 오픈 소스 메세지 브로커 소프트웨어 입니다. 여기서 AMQP(Advanced Message Queing Protocol)이란 메세징에서 신뢰성, 보안, 트랜잭션 등을 표준화한 메세징 프로토콜을 이야기합니다. 클라이언트가 메세해당 프로토콜을 통해서 RabbitMQ 서버는 Java, Python, Node.js 등 여러 언어에서 사용 할 수 있습니다. 

 

핵심 구성 요소

kafka와 비슷한 메세지 브로커이다 보니 비슷한 구성 요소들도 있고 RabbitMQ만의 개념도 존재 하는 것으로 보입니다. 

 

✅ Producer (메시지 생산자)

• 메세지 생성 및 전송하는 역할
• 직접 메세지 저장소(`Queue`)에 전달하는 것이 아닌 메세지 라우터(`Exchange`)로 전달함

✅ ⭐ Exchange (메세지 라우터)

• RabbitMQ가 가지고 있는 특징
• Producer가 Queue에 메세지를 보내기 전 지나가는 라우팅 역할을 하는 
• `Binding` 규칙, 타입에 따라서 Queue를 연결함 

타입	설명
Direct	특정 라우팅 키와 일치하는 큐에만 전달
Fanout	연결된 모든 큐에 브로드캐스트
Topic	와일드카드 패턴(예: order.*)으로 라우팅
Headers	메시지 헤더 기반 라우팅

✅ Queue (메세지 저장소)

• 메세지 저장 공간으로 순서대로 저장됨 (FIFO 구조)

✅ Consumer (메시지 소비자)

• `Queue`에 쌓인 메세지를 가져가 처리하는 역할
• 여러 `Consumer`가 하나의 `Queue`를 구독하여 부하 분산 처리를 할 수 있음. 

 

RabbitMQ vs Kafka vs ActiveMQ

3개의 메세지 브로커들은 모두 메세지를 전달한다는 공통적인 개념을 가지지만 서로 다른 특징을 가집니다. 자신의 아키텍처에 맞는 도구를 선택해서 사용하면 되겠습니다. 아래는 3가지 도구를 간략하게 비교한 표입니다.

 

	RabbitMQ	Kafka	ActiveMQ
메세지 보관	소비 후 삭제	일정 기간 유지	소비 후 삭제
순서 보장	Queue 단위	Topic 내부 Partition 단위	Queue 단위
특징	이벤트 라우팅 브로커 (이벤트 허브)	데이터 스트리밍 플랫폼  (데이터 스트림, 빅데이터)	Java 전통 메세징 시스템 (JMS 표준)
단점	데이터 보존 부적합, 대용량 스트리밍 한계	복잡한 운영 난이도	java 진영에서만 사용 가능

 

한줄로 요약해보자면 아래와 같이 사용 할 수 있겠습니다. 

 

RabbitMQ: 복잡한 이벤트 라우팅이 필요한 경우 

ActiveMQ: 이벤트 라우팅이 필요하고 Java 환경인 경우

Kafka: 대용량의 이벤트 처리가 필요한 경우

 

실무에서도 비교적 처리량이 적고 이벤트 라우팅 역할이 필요한 경우에 RabbitMQ를 사용하고 있습니다. 

 

RabbitMQ in Python

 

다음은 간단하게 Python에서 사용하는 RabbitMQ에 대해서 알아보겠습니다.

가장 기본적으로는 RabbitMQ Python 클라이언트로는 `pika` 라이브러리를 활용합니다.

 

FastAPI와 함께 사용할 때는 다음과 같은 구조를 가지는 경우가 많습니다.

API를 통해 이벤트를 발행 시키고, 별도의 Consumer 워커가 처리하는 경우가 많습니다.

[Client]
↓
[FastAPI]
↓ (이벤트 발행)
[RabbitMQ]
↓
[Worker (Python Consumer)]

 

그렇다면 메세지 재시도 처리는 어떻게 될까요?

RabbitMQ는 메세지에 대한 처리가 성공되었을 때는 `ack` 처리를 하고, 실패한 경우에는 `nack` 처리를 하게 됩니다. 

`nack`처리가 된 메세지를 반환 받게 되었을 때 RabbitMQ가 해당 메세지에 대한 처리가 성공 할 때 까지 과정을 무한 반복 할 수 있기 때문에 실패된 메세지에 대한 재시도를 처리를 해주는 것이 필요합니다. 

 

`DLX`(Dead Letter Exchange)라고 하는 exchange(라우팅 역할)에 설정을 통해 실패한 메세지를 어느 Queue에 저장되게 할지 정하게 되고, 이 때 Queue를 `DLQ`(Dead Letter Queue)라고 표현합니다.

 

 

 

 

간단하게 RabbitMQ에 대해서 알아봤습니다. MSA 구조에서 메세지 브로커를 사용하게 되는 것은 필연적인 일인 것 같은데요! 특징에 맞춰서 잘 사용 할 수 있도록 해봅시다. 화이팅..

 

 

 

 

참고:

ChatGPT와의 대화

https://velog.io/@devcube2/RabbitMQ-%EB%A9%94%EC%8B%9C%EC%A7%80-%EC%9E%AC%EC%B2%98%EB%A6%AC

RabbitMQ 메시지 재처리

https://e-ello.tistory.com/10

DLQ(SpringBoot + RabbitMQ 메시지 실패 처리)