메시지 큐 비교하기 (RabbitMQ, Kafka, SQS, Redis Pub/Sub)

회사에서 메시지 큐(Message Queue)를 도입해야 할 기회가 생겨 팀원과 함께 고민했다.

 

처음에는 가볍게 RabbitMQ, AWS SQS, Kafka, Redis Pub/Sub을 비교하며 선택했지만,

각 메시지 큐의 특징과 차이점을 좀 더 깊이 이해하고 정리하고 싶었다. (개발 방향이 바뀌어 도입을 하진 않았다 😅)

 

이 글에서는 메시지 큐의 주요 기능과 차이점을 정리해보겠다.

 

메시지 큐 선택 기준

1. 한 메시지는 하나의 작업 서버에서만 처리해야 한다.
   • 중복 처리를 방지해야 함
2. 여러 작업 서버가 동시에 병렬적으로 처리할 수 있어야 한다.
   • 다수의 Consumer가 동시에 작업을 수행 가능해야 함
3. 빠른 성능이 중요하다.
   • 낮은 지연 시간 (Low Latency)
   • 높은 처리량 (High Throughput)

이제 이 조건에 맞춰 주요 메시지 큐들을 비교해보자.

 

---

1️⃣ RabbitMQ

메시징 모델:

•  브로커 기반 (AMQP)

특징:

• AMQP(Advanced Message Queuing Protocol) 기반 메시지 브로커
• Exchange를 통해 다양한 라우팅 가능
  RabbitMQ에서는 Producer가 직접 Queue에 메시지를 넣는 것이 아니라, Exchange(교환기)라는 중간 매개체를 거친다.
  
  Exchange는 메시지를 어떤 큐(Queue)로 보낼지 결정하는 역할을 한다.
  Exchange를 거침으로써 메시지 라우팅을 유연하게 관리할 수 있다.
  하나의 메시지를 여러 큐에 동시에 전달할 수도 있고, 하나의 큐에만 전달할 수도 있다.

https://seventhstate.io/what-is-rabbitmq/

 

• 메시지 보장 가능 (At-least-once, Exactly-once 설정 가능)
• Push 방식으로 메시지 전달
  • 메시지가 큐에 들어오면 RabbitMQ가 자동으로 Consumer에게 전달 (Push 방식)
  • Consumer가 ACK를 보내야만 메시지가 삭제됨
• 하나의 Queue를 여러 Consumer가 바라볼 수 있음
  • Round-Robin 방식으로 메시지를 분배하여 여러 Consumer가 병렬 처리 가능
• 확장성 제약이 있음
  • 하나의 Queue가 특정 노드에서만 관리되므로 트래픽이 집중되면 병목이 발생할 수 있다.
• 메시지 순서 보장이 어려울 수 있음
  • 여러 Consumer가 같은 Queue를 바라볼 경우, 메시지 처리 속도에 따라 순서가 달라질 수 있다.
  • 특정 Consumer가 느리다면 후순위 메시지가 먼저 처리될 가능성이 있다.

2️⃣ AWS SQS

메시징 모델:

• Fully Managed Queue

특징:

• AWS에서 운영하는 관리형 큐 서비스
• FIFO 지원 (메시지 순서 보장을 보장할 수 있다.)
• Pull 방식
• Visibility Timeout을 활용해 중복 처리를 방지한다.
  Consumer가 메시지를 가져가면 해당 메시지는 일정 시간 동안 다른 Consumer에게 보이지 않는다. (기본 30초)
  한 Consumer가 메시지를 가져가면 일정 시간 동안 다른 Consumer는 가져갈 수 없다.
  
  Consumer가 이 시간 내에 메시지를 삭제하지 않으면, 메시지는 다시 큐로 돌아가고 다른 Consumer가 가져갈 수 있다.

https://aws.plainenglish.io/everything-you-should-know-about-aws-sqs-visibility-timeout-6b1ab74dd54a

 

 

• 확장성이 높다.
  • 트래픽 증가 시 자동으로 조정되며, 무제한 확장 가능하다.

 

3️⃣ Kafka

메시징 모델:

• 분산 로그 기반 (Event Streaming)

특징:

• Pull 방식
• Partition을 활용한 수평 확장 가능하다.
  • 여러 Consumer가 병렬로 메시지를 처리하려면 여러 개의 Partition이 필요하다.
    
  • 하나의 Partition만 사용하면 병렬 처리가 불가능하며, 하나의 Consumer만 메시지를 소비할 수 있다.

• 메시지 보장 가능 (At-least-once, Exactly-once 지원)
  • Consumer Group을 사용하면 한 메시지를 하나의 서버에서만 처리 가능하다.
  • 하지만 여러 Partition을 사용할 경우, 글로벌 메시지 순서는 보장되지 않는다.
• 높은 처리량 지원
  • 초당 수백만 개의 메시지를 처리할 수 있는 고성능 메시징 시스템이다.

4️⃣ Redis Pub/Sub

메시징 모델:

• Publish-Subscribe

특징:

• 메모리 기반 메시징 시스템으로 빠른 속도 제공
• Push 방식
• Queue가 아닌 Publish-Subscribe 모델
  • 메시지를 저장하지 않으며, 구독 중인 Consumer만 메시지를 받을 수 있다.
  • Consumer가 구독하지 않은 상태에서 메시지가 발행되면 메시지가 유실된다.
• 중복 처리 가능성
  • 여러 Consumer가 동일한 메시지를 동시에 받을 수 있다. (브로드캐스트 방식)
  • 한 메시지를 하나의 서버에서만 처리해야 하는 경우 적합하지 않다.
• 지연 시간이 거의 없다.
  • 네트워크 레이턴시 외에는 거의 즉시 메시지를 전달 가능

 

---

👀 조건에 맞는 메시지 큐 확인

조건 1: 한 메시지는 하나의 작업 서버에서만 처리해야 한다.

메시지 큐	적합 여부	설명
RabbitMQ	✅	Work Queue 모델을 사용하면 한 메시지를 하나의 Consumer만 처리
AWS SQS	✅	Visibility Timeout을 활용해 중복 처리를 방지
Kafka (Multiple Partitions)	✅	Consumer Group을 사용하면 한 메시지를 하나의 서버에서만 처리 가능
Kafka (1 Partition)	✅	Partition이 1개일 경우 병렬 처리는 불가능하지만, 메시지 독점 처리는 가능
Redis Pub/Sub	❌	브로드캐스트 방식이라 하나의 메시지가 모든 구독자에게 전파됨

조건 2: 여러 작업 서버가 동시에 병렬적으로 처리 가능해야 한다.

메시지 큐	적합 여부	설명
RabbitMQ	✅	여러 Consumer가 하나의 Queue를 공유하며, Round-Robin 방식으로 메시지를 분배
AWS SQS	✅	여러 Consumer가 동일한 Queue에서 메시지를 가져가 병렬 처리 가능
Kafka (Multiple Partitions)	✅	Partition을 여러 개로 나누면 여러 Consumer가 각 Partition을 처리하여 병렬 처리 가능 (단, 서버 개수만큼 Partition을 나눠야 함.)
Kafka (1 Partition)	❌	하나의 Partition만 사용하면 병렬 처리가 불가능하며, 하나의 Consumer만 메시지를 소비 가능
Redis Pub/Sub	⚠️	모든 Consumer가 같은 메시지를 받으므로, 중복 메시지 발생 가능

조건 3: 빠른 성능이 중요하다.

Redis Pub/Sub > Kafka > RabbitMQ > AWS SQS

라고 함

 

---

 

위와 같이 각 상황에 맞는 적합한 방식을 택하면 좋을 것 같다!

 

나는 Kafka만 써봤던 상태라, 기술 블로그들 보면서 큰 특징들로만 이해하고 정리해보았다. 다음엔 메시지큐별로 정리해보는 시간이 있으면 한층 더 깊이 있게 이해할 수 있을 것 같다 👍

 

 

---

🔗 참고

 

What Is RabbitMQ? An Intro To The Message Queuing Tech

Everything You Should Know About AWS SQS Visibility Timeout