RabbitMQ, Apache Kafka, AWS SQS 비교

메시지 저장 및 전달 방식

---

RabbitMQ는 메시지를 큐에 안전하게 저장하고 전달하며, Kafka는 영속적으로 메시지를 저장하고 여러 소비자에게 전달하고, SQS는 안전하게 메시지를 큐에 저장하고 전달한다.

 

RabbitMQ

메시지를 큐에 저장하고, 이를 소비자에게 전달한다. RabbitMQ는 메시지를 저장하는 역할을 중요하게 여긴다. 따라서 일시적인 네트워크 문제 또는 소비자가 메시지를 처리하지 못할 경우에도 안전하게 메시지를 보관한다.

Kafka

Kafka는 메시지를 영속적으로 저장하고, 이를 여러 소비자 그룹에게 동시에 전달할 수 있다. 메시지는 토픽에 기록되며, 이를 구독하는 모든 소비자에게 전달된다. 또한, Kafka는 일반적으로 디스크에 메시지를 저장하여 데이터의 장기 보존이 가능하다.

SQS

SQS는 메시지를 보관하고, 메시지를 처리할 수 있는 소비자가 나타나면 해당 메시지를 전달한다. SQS는 메시지의 저장을 담당하므로, 네트워크 문제 또는 소비자가 메시지를 처리하지 못할 경우에도 안전하게 메시지를 보관한다.
SQS는 두 가지 유형의 큐를 제공하는데 Standard Queue는 최소 한 번의 전송 보장을 제공하며, FIFO Queue는 메시지 순서를 보장한다.

 

메시지 전달 보증 수준

---

RabbitMQ와 SQS는 두가지 보증 수준을 제공하며 Kafka는 At Least Once 만 제공한다.

RabbitMQ

메시지 전달 보증 수준을 조절할 수 있다. 메시지의 전달이 보장되어야 하는 경우에는 'at least once' 또는 'exactly once'와 같은 설정이 가능하다.

Kafka

Kafka는 'at least once' 전달 보증을 가지고 있다. 이는 메시지의 복제와 리더-팔로워 모델을 통해 구현된다.

SQS

SQS는 Standard Queue(At Least Once)와 FIFO Queue(Exactly Once)를 제공한다. 사용자는 필요에 따라 Standard Queue 또는 FIFO Queue 중 하나를 선택하여 메시지 전달 보증 수준을 조절할 수 있다.

At Least Once (최소 한 번)
메시지 브로커가 메시지를 적어도 한 번은 소비자에게 전달함을 보증한다. 이는 메시지가 소비자에게 정확히 한 번만 전달되는 것을 보장하지는 않는다. 메시지가 성공적으로 소비자에게 전달되지 않으면 메시지가 다시 전송될 수 있다. 이는 일부 중복 전송의 가능성을 내포하고 있지만, 메시지 손실의 위험을 줄일 수 있다.
Exactly Once (정확히 한 번)
메시지 브로커가 메시지를 정확히 한 번만 소비자에게 전달함을 보증한다. 이는 중복 전송이나 메시지 손실이 없음을 의미한다. 정확히 한 번의 전송을 보장하기 위해서는 추가적인 처리와 상태 추적이 필요하다. 이러한 처리는 일반적으로 메시지에 대한 고유 식별자와 소비자의 처리 상태를 추적하여 구현된다.

대부분의 분산 메시지 시스템은 'at least once'를 제공하며, 'exactly once'는 더 복잡한 처리가 필요하므로 구현이 어려울 수 있다. 따라서 대부분의 경우, 'at least once' 수준이 충분하며, 중복된 메시지를 처리할 수 있는 방법을 고려하여 시스템을 설계하는 것이 중요하다.

 

프로토콜

---

RabbitMQ는 AMQP 프로토콜을 사용하여 메시지 중심의 미들웨어를 구현하고, Kafka는 자체 바이너리 프로토콜을 사용하여 대용량 데이터 스트리밍을 지원하며, Amazon SQS는 HTTP/HTTPS 기반의 프로토콜을 사용하여 탄력적인 큐 서비스를 제공한다.

RabbitMQ

RabbitMQ는 AMQP(Advanced Message Queuing Protocol)라는 표준 메시지 프로토콜을 사용한다. AMQP는 메시지 지향 미들웨어(Message Oriented Middleware) 시스템을 지원하기 위한 개방형 표준 프로토콜로, 여러 플랫폼 및 언어 간의 통신을 위한 표준을 제공한다.
AMQP의 특징

• 메시지 전달을 중심으로 하는 프로토콜
• 메시지를 저장하고 소비자에게 전달하기 위한 큐를 지원
• 메시지 발행자(Publisher)와 메시지 구독자(Subscriber) 간의 통신을 지원
• 메시지 전달 보증을 설정할 수 있으며, 'at least once', 'exactly once' 등의 옵션을 제공

Kafka

Kafka는 자체 프로토콜을 사용한다. Kafka 프로토콜은 바이너리 프로토콜로, 주로 TCP를 통해 통신한다.
 
Kafka 프로토콜의 특징

• 데이터를 로그 형태로 저장하고 처리하는 아키텍처를 기반으로 한 프로토콜
• 데이터를 토픽으로 구분하고, 각 토픽은 여러 파티션으로 나누어져 저장
• 메시지 발행자(Producer)가 데이터를 토픽으로 전송하고, 메시지 소비자(Consumer)가 해당 토픽에서 데이터를 읽는다
• Kafka는 여러 브로커를 사용하여 데이터를 분산 저장하고 처리할 수 있다
• Kafka는 'at least once' 메시지 전달 보증을 제공

Amazon SQS

Amazon SQS는 여러 프로토콜을 지원하며, HTTP/HTTPS 및 Amazon SQS Long Polling 프로토콜을 통해 메시지를 전송한다. 기본적으로는 HTTP를 사용하며, HTTPS를 통해 보안을 제공한다.
 
Amazon SQS 프로토콜의 특징

• HTTP/HTTPS를 사용하여 메시지를 전송
• 단일 메시지 크기는 최대 256 KB
• Long Polling을 통해 효율적인 메시지 수신 가능
• 다양한 통신 패턴 지원 (FIFO 큐, Standard 큐 등)
• 단일 메시지 전송의 원자성을 보장
• 다양한 통신 패턴을 지원하며, 큐 간에 메시지를 안전하게 전송

 

확장성 및 처리량

---

확장성 및 처리량 측면에서 RabbitMQ는 많고 작은 메시지를 처리하는 데 적합하며, Kafka는 대용량 데이터 스트림 처리에 특히 효과적이다. SQS는 대규모 분산 시스템에서 비동기 통신과 탄력적인 큐 서비스로 주로 활용된다.

RabbitMQ 

RabbitMQ는 주로 작업 큐, 이벤트 기반 아키텍처, RPC와 같은 메시지 중심의 시스템에 적합하며, 상대적으로 작은 크기의 메시지 및 작은 규모의 데이터를 처리하는 데 효과적이다. 큐 당 수백만 개의 메시지를 처리할 수 있지만, 대용량 데이터나 큰 파일과 같은 대용량 데이터 처리에는 적합하지 않을 수 있다.

Kafka

Kafka는 대용량 데이터 스트리밍을 처리하는 데 특히 효과적이며, 수십 테라바이트 이상의 데이터를 다룰 수 있다. 대규모 로그 처리, 실시간 분석, 이벤트 소싱 등에 적합하다.

SQS

SQS는 일반적으로 작은 크기의 메시지를 처리하며, 큐에 메시지를 전송할 때 메시지의 크기를 최대 256 KB까지로 제한한다. 크기 제한이 있지만, 비동기 통신과 탄력적인 큐 서비스로 주로 활용되며 대규모 분산 시스템에서 사용된다.

 

사용 사례

---

RabbitMQ

작은 규모의 메시징 애플리케이션, 이벤트 기반 시스템, 작업 큐 등에 적합하다

Kafka

대규모 데이터 스트리밍, 로깅, 이벤트 소싱(Event Sourcing), 메트릭 수집 및 분석과 같은 대용량 데이터 처리에 적합하다.

SQS

SQS는 서로 다른 컴포넌트 간의 비동기 통신 및 탄력적인 큐 서비스로 사용되며, 대규모 분산 시스템에서 활용된다.

 

정리

---

kafka는 pub/sub 방식 / RabbitMQ는 메시지 브로커 방식

kafka의 pub/sub방식은 생산자 중심적인 설계로 구성.
생성자가 원하는 각 메시지를 게시할 수 있도록 하는 메시지 배포 패턴으로 진행
RabbitMQ의 메시지브로커방식은 브로커 중심적인 설계로 구성.
지정된 수신인에게 메시지를 확인, 라우팅, 저장 및 배달하는 역할을 수행하며 보장되는 메시지 전달에 초점
 

전달된 메시지에 대한 휘발성

RabbitMQ는 queue에 저장되어 있던 메시지에 대해 Event Consumer가져가게 되면 queue에서 해당 메시지를 삭제한다.
하지만, kafka는 생성자로부터 메시지가 들어오면 해당 메시지를 topic으로 분류하고 이를 event streamer에 저장한다. 그 후, 수신인이 특정 topic에 대한 메시지를 가져가더라도 event streamer는 해당 topic을 계속 유지하기 때문에 특정 상황이 발생하더라도 재생이 가능하다.
 

용도의 차이

kafka는 클러스터를 통해 병렬처리가 주요 차별점인 만큼 방대한 양의 데이터를 처리할 때, 장점이 부각된다.
RabbitMQ는 데이터 처리보단 Manage UI를 제공하는 만큼 관리적인 측면이나, 다양한 기능 구현을 위한 서비스를 구축할 때, 장점이 부각된다.