[MQ] RabbitMQ, Kafka, ActiveMQ 비교 (3)

📌 AMQP : Advanced Message Queue Protocol

메시지 지향 미들웨어(MOM)을 위한 개방형 표준 응용 계층 프로토콜

• AMQP는 일반적인 메세지 큐와 비슷하지만, Exchange와 Binding이라는 개념이 있어서 더 유연하게 처리할 수 있다.
• Exchange라는 라우터가 메세지의 경로를 결정하고, Binding이 그 경로를 설정해준다.

▪️AMQP의 주요 개념

• Producer (생산자): 메세지를 만들어서 Exchange에 Publish한다.
• Consumer (소비자): 메세지를 Queue에서 꺼내서 처리한다.
• Exchange (교환기): Producer가 보낸 메세지를 어떤 Queue로 보낼지 결정하는 라우터다.
• Queue (큐): Consumer가 메세지를 소비하기 전까지 메세지가 보관되는 장소다.
• Binding (바인딩): Exchange와 Queue를 연결하는 규칙이다.
  즉, 특정 Exchange가 특정 Queue에 메세지를 보낼 수 있도록 관계를 설정한다.

▪️메세지 흐름

1️⃣ Producer는 메세지를 만들고, 그 메세지를 Exchange에 Publish한다.

 

2️⃣ Exchange는 라우팅 규칙에 따라 메세지를 Queue로 보낸다.

이때 메세지가 어떤 Queue로 가는지는 Binding 규칙에 따라 결정된다.

 

3️⃣ Consumer는 Queue에서 메세지를 꺼내서 처리한다.

 

▪️AMQP의 특징

• AMQP는 Exchange를 통해 메세지 라우팅을 세밀하게 제어할 수 있어서, 메세지 큐 시스템보다 더 유연한 라우팅을 제공한다.
• Binding을 사용하면 메세지가 어떤 큐로 갈지를 동적으로 설정할 수 있다.

---

📌 RabbitMQ

RabbitMQ는 AMQP 프로토콜을 구현한 오픈소스 메세지 브로커

• Broker 중심적으로 동작
• 관리 UI 제공
• 거의 모든 언어와 운영체제 지원
• 데이터 처리보다는 관리적 측면이나 다양한 기능 구현을 위한 서비스 구축에 사용

▪️처리 구조

1️⃣ Producer가 메세지를 Broker로 보낸다.

2️⃣ Broker 안에 있는 Exchange는 전달된 메세지를 Binding 규칙에 맞게 Queue에 분배한다.

3️⃣ 메세지를 보관하고 있는 Queue를 구독하는 Consumer가 메세지를 꺼내어 처리한다.

 

 

메시지 라우팅: 다양한 라우팅 기능을 제공(Direct, Topic, Fanout 등).

성능: 일반적으로 높은 메시지 처리 속도와 안정성 제공, 하지만 Kafka보다는 낮을 수 있음.

 

---

📌 JMS : Java Message Service

Java MOM 표준 API로서, 메시지 큐 및 Publish-Subscribe 패턴과 같은 메시지 기반 통신을 추상화하고 표준화한 API

• Java 에서 채택한 대표적인 MOM 시스템, 일반적인 메세지 큐 구조와 비슷하다.
• ActiveMQ가 JMS를 기반으로 통신을 제어한다.

---

📌 ActiveMQ

Apache에서 제공하는 메시지 브로커로 JMS를 기반으로 동작한다.
RabbitMQ와 더불어 현재 대표적인 메시지 브로커로 사용되고 있다.

• Message Broker : 목적지에 안전하게 메시지를 건네주는 중개자 역할
• Destination : 목적지에 배달될 2가지 메시지 모델인 Queue, Topic
• Queue : 메시지가 전달되는 통로 (경합 있음)
• Topic : Queue와 비슷한 역할, 여러 Consumer에게 메시지를 건네줄 수 있음 (경합 없음)

처리 모델

• Queue 모델 : 메시지를 받는 Consumer가 다수일 때 연결된 순서로 메시지 제공
• Topic 모델 : 메시지를 받는 Consumer가 다수일 때 메시지는 모두에게 제공
• AMQP 기반의 RabbitMQ 을 사용하는 프로세스와의 통신은 불가능하다.

⇒ AMQP는 프로토콜, JMS는 API이다. JMS는 메시지 형식이 아닌 브로커와 통신하는 방법을 정의하고, 자바 애플리케이션에만 국한되어 있다. AMQP는 브로커와 통신하는 방법에 대해서 논하지 않지만, 메시지가 유선을 통해 큐에 어떻게 넣고 꺼내지는지에 대해 정의한다.

⇒ 서로 다른 두 가지 애플리케이션이 소통할 때, 둘 다 자바면 JMS를 통해서 통신할 수 있지만 하나가 파이썬이라면 JMS는 사용할 수 없다.

 

---

📌 Kafka

이벤트 스트리밍

Kafka 는 세 가지 주요 기능을 결합하여 end-to-end 이벤트 스트리밍을 구현

• 이벤트 스트림을 지속적으로 발행(publish), 구독(subscribe)
• 이벤트 스트림을 원하는 만큼 내구성 있고 안정적으로 저장(store)

kafka 등장 배경

지금은 Apache에서 관리되고 있지만 Linked in에서 처음 등장

Linked in은 기존의 end-to-end 통신 방식 아키텍쳐에 대해 문제점을 느꼈음

 

기존의 end-to-end 통신 방식의 문제점

1. 시스템 복잡도(Complexity)의 증가
   통합된 전송 영역이 없어 데이터 흐름을 파악하기 어렵고, 시스템 관리가 어려움
   특정 부분에서 장애 발생 시 조치 시간 증가 (연결 되어있는 애플리케이션들을 모두 확인해야 했기 때문)
   HW 교체 혹은 SW 업그레이드 시 관리 포인트가 늘어나고, 작업시간의 증가(연결되어 있는 애플리케이션에 Side Effect 가 없는지 확인 필요)
2. 데이터 파이프라인 관리의 어려움
   각 애플리케이션과 데이터 시스템 간 별도의 파이프라인이 존재하고,
   파이프라인마다 데이터 포맷과 처리 방식이 다름
   새로운 파이프라인 확장이 어려워지면서, 확장성 및 유연성이 떨어짐
   데이터 불일치 가능성이 존재했기 때문에 신뢰도 감소

이를 개선하고자 설정한 목표

• 기존 end-to-end 통신 방식에서 벗어나 통합/중앙화된 전송 영역을 설계하자.
• 메세지를 생성하는 Producer 와 Consumer 을 분리하자.
• 대용량 메세지 처리와 더불어 빠른 처리량을 이루자.
• 확장(Scale-out) 이 용이하도록 설계하자.

 

주요 개념 정리

• Event: Producer와 Consumer가 Kafka를 통해 주고받는 데이터 단위, 즉 메시지.
• Kafka Cluster: 여러 Kafka Broker의 집합으로, 클러스터에서 하나의 Broker가 실패해도 다른 Broker가 계속 동작.
• Broker: Kafka 서버를 지칭. 메시지를 저장하고 관리하는 역할을 수행. 여러 개의 Broker가 동시에 운영될 수 있음.
• Producer: 메시지를 발행하는 Kafka 클라이언트. 일정량을 모아서 전송하는 Batch 처리가 가능. Acks 설정을 통해 효율성을 높일 수 있음.
• Consumer: 메시지를 구독하고 소비하는 Kafka 클라이언트. 여러 Topic을 동시에 처리할 수 있음. Batch 처리 가능.
• Topic: 메시지를 구분하는 단위로, 폴더처럼 기능. Consumer는 자신이 구독한 Topic의 메시지만 처리함. 하나 이상의 Partition으로 구성.
• Partition: 메시지를 저장하는 물리적 단위. 메시지는 여러 Broker에 분산되어 저장됨. 분산된 Topic이 Partition. 병렬 처리를 통해 높은 성능을 제공. 각 메시지에는 고유한 Offset이 있음.
• Offset : Partition 내 각 메세지의 저장된 상대적 위치. Partition 의 메세지 파일은 영속성을 유지하며 일정시간 뒤 삭제됨 ➡️ 소비한 메세지를 다시 소비 가능

---

📌 비교

특성	RabbitMQ	Kafka	ActiveMQ
메시징 모델	큐 기반 (AMQP)	로그 기반 (스트리밍)	큐 및 토픽 기반 (JMS)
내구성	메시지 저장 가능	디스크에 로그 저장, 높은 내구성	메시지 저장 가능
성능	중간 수준 (고속 처리 가능)	매우 높은 처리량 (대규모 데이터 스트리밍)	중간 수준
확장성	중간 수준	높은 확장성 (분산 아키텍처)	중간 수준
사용 사례	작업 큐, 비동기 처리	실시간 데이터 스트리밍, 로그 분석	Java 환경, 전통적인 메시징 시스템
프로토콜	AMQP, MQTT, STOMP 등	고유 프로토콜	JMS, AMQP, STOMP 등
장점	다양한 라우팅 기능, 안정성 높음	높은 처리량과 내구성, 실시간 분석 가능	다양한 프로토콜과 Java 호환성
단점	고속 처리에 한계가 있을 수 있음	설정과 관리가 복잡, 큐 기반 처리와 차이	성능이 Kafka에 비해 낮을 수 있음

 

결론

• RabbitMQ는 복잡한 메시징 라우팅과 안정성이 필요한 시스템에 적합하며, 작업 큐나 분산 시스템에서 많이 사용
  정확한 요청-응답이 필요한 Application을 쓸 때 또는 트래픽은 작지만 장시간 실행되고 안정적인 백그라운드 작업이 필요한 경우 사용
• Kafka는 대규모 데이터 스트리밍과 높은 처리량을 요구하는 시스템에 적합. 실시간 로그 분석이나 이벤트 기반 재처리 필요 시스템에서 유리.
• ActiveMQ는 JMS와 다양한 프로토콜을 지원하며, Java 기반 시스템과의 호환성이 뛰어나고, 다양한 메시징 모델을 제공.

 

✅ 고속 처리와 데규모 데이터 스트리밍까지는 필요 없음

✅ 안정적이고 비동기 처리가 가능한 라우팅 기능이 필요한 상황

✅ 트래픽은 많지 않지만 장시간 실행되고 안정적인 백그라운드 작업이 필요

✅ 나중에 확장성을 위해 Java 환경이 아닌 상황에서도 대응 되도록 초기에 마련

 

따라서 메일 서버와 API 서버를 연동하기 위해 도입할 MQ로는 RabbitMQ가 적절해보인다!