MOM? Kafka? RabbitMQ? ActiveMQ? 개념

레거시 프로그램을 주로 개발하던 시점에서 MOM, Kafka 이런 단어들을 처음 듣고 굉장히 생소하였다.

나중엔 꼭 이러한 기술들을 써보리라는 굳은 의지를 갖고 조금씩 공부하려고 한다.

---

MOM (Message Oriented Middleware)

분산 환경에서 메시지를 통해 비동기적으로 통신하고 데이터를 교환하는 미들웨어 시스템

 

 

메시지 큐 (Message Queue)

비동기적인 방식으로 데이터를 주고받는 데 사용되는 중앙 집중형 컴퓨터 시스템(미들웨어, 브로커 ..) 이다.

 

이 시스템은 데이터를 메시지로 전송하고 받는 것을 중개하며, 발신자(Sender)와 수신자(Receiver) 간에 직접적인 통신 없이 데이터 교환을 할 수 있게 해 준다.

 

메시지 큐는 여러 애플리케이션, 서비스 또는 컴포넌트 간의 통합을 쉽게 할 수 있도록 도와주며, 시스템 간 결합도를 낮추고 확장성을 높이는데 도움이 된다.

 

개념 및 특징

• Producer(생산자)와 Consumer(소비자) : 데이터를 생성하고 소비하는 두 가지 주요 역할인 생성자와 소비자를 지원
• Message Broker : 메시지 큐는 중앙에서 데이터를 중개하는 브로커 역할을 수행한다. 생산자는 메시지를 브로커에게 보내며, 브로커는 해당 메시지를 큐에 저장하거나 전달한다. 소비자는 브로커에서 메시지를 가져와 처리한다.
• Queue : 메시지는 보통 큐에 저장된다. 소비자는 큐에서 메시지를 차례대로 처리한다. 큐는 FIFO 방식을 따른다.
• Topic : 모든 소비자가 동일한 메시지를 받는 것과 달리, 토픽은 특정 주제에 관련된 메시지를 구독하는 소비자들에게 메시지를 보낼 수 있는 기능을 제공한다.
• Pub/Sub 모델 : Publish/Subcribe 모델은 생산자가 메시지를 발행하고, 해당 토픽을 구독한 모든 소비자가 해당 메시지를 수신하는 방식이다. 이는 이벤트 기반 시스템에서 자주 사용된다.

 

 

메시지 큐의 예시

• 이메일 큐 : 사용자가 웹 애플리케이션을 통해 이메일을 보낼 때, 이메일 내용과 수신자 정보를 큐에 넣어 브로커를 통해 비동기적으로 처리할 수 있다.
• 주문 처리 큐 : 전자 상거래 사이트에서 주문이 들어올 때, 주문 정보를 큐에 넣어 백그라운드에서 주문 처리 작업을 수행할 수 있다.
• 로그 수집 큐 : 여러 서비스에서 생성되는 로그 정보를 큐에 저장하고, 중앙 로그 수집 시스템이 해당 로그를 가져와 분석 및 저장할 수 있다.
• 실시간 알림 큐 : 알림 메시지를 생성하고 해당 알림을 구독한 사용자에게 비동기적으로 전달하여 실시간으로 알림을 제공할 수 있다.
• 시스템 간 데이터 동기화 큐 : 여러 시스템 간 데이터 동기화를 위해 데이터 변경 사항을 큐에 넣어 다른 시스템에 전파하여 동기화할 수 있다.

메시지 큐를 사용하는 이유

1.  발신자와 수신자가 서로를 직접 알 필요가 없으므로 느슨한 결합 (Decoupling)을 만들어 낼 수 있다.
2.  발신자, 수신자가 서로에게 의존하지 않으므로 각자는 독립적으로 확장 (Scalable) 될 수 있다.
   N:1:M의 형태로 발신자, 수신자 사이에 메시지 큐가 메시지를 중개하기 때문이다.
3. 수신자 서비스가 장애상황이 발생하더라도 발행된 메시지는 메시지 큐에 남아있기에 결과적으로는 소비자 서비스에 
   전달된다는 보장성 (Guarantees)를 갖는다.
4. 발신자가 메시지 큐에 발행하고, 수신자가 메시지를 가져가는 방식이므로 비동기 통신 (Asynchronous)을 구현.

이러한 특성들로 인해서, 이미지 프로세싱과 같이 무거운 작업을 요청하거나, 이벤트 기반 아키텍처에서

이벤트가 발생했음을 알리기 위한 용도로 사용하기 적합하다.

---

MOM을 사용하는 대표적인 시스템

 

1. RabbitMQ 

• AMQP(Advanced Message Queuing Protocol)를 기반으로 동작하는 메시지 브로커
• AMQP는 메시지를 안정적으로 전송하고 라우팅 하는 프로토콜
• 유연한 라우팅 및 메시지 패턴을 지원하며, 많은 클라이언트 라이브러리 제공
• 다양한 기능을 지원하며, 큐의 메시지 상태 및 속성을 관리하기 용이
• 단일 브로커를 통한 메시지 전달에 중점을 둔 솔루션

 

2. ActiveMQ

• JMS (Java Message Service) 스펙을 따르는 오픈 소스 메시지 브로커
• Java 언어로 개발되었으며, 다양한 언어로 클라이언트를 개발할 수 있다.
• 다양한 전송 프로토콜을 지원하며, 확장성과 기능성이 중요한 요소인 경우에 사용.
• Spring Framework와의 통합이 강력하며, 높은 수준의 설정 및 관리 기능 제공.

 

3. Apache Kafka

• 대용량 실시간 로그 및 이벤트 스트리밍 플랫폼
• LinkedIn에서 개발한 Kafka는 분산 데이터 스트리밍을 지원하며, 높은 처리량과 내구성을 갖고 있다.
• 이벤트 스트림 처리에 중점을 두며, 데이터 파이프라인, 로그 수집, 실시간 분석 등에 사용된다.
• 주로 대규모 데이터 처리 및 스트리밍 처리에 사용되며, 데이터를 '토픽'으로 구성하고 파티션으로 분할하여 저장한다.

차이점

• RabbitMQ와 ActiveMQ는 메시지 큐와 메시지 브로커 역할게 중점을 둔다.
  Kafka는 데이터 스트림 처리와 이벤트 로그 기반 플랫폼이다.
• RabbitMQ와 ActiveMQ는 메시지를 큐에 저장하여 소비자가 메시지를 처리하는 패턴을 지원한다.
  kafka는 데이터를 토픽으로 스트림처럼 다루어 분산 처리 및 저장을 지원한다.
• RabbitMQ와 ActiveMQ는 AMQP 및 JMS와 같은 표준 프로토콜을 사용하며,
  클라이언트 라이브러리를 통한 다양한 언어 지원이 가능하다.
  Kafka는 Kafka 클라이언트 라이브러리를 통해 다양한 언어로 개발할 수 있다.
• RabbitMQ와 ActiveMQ는 메시지 큐와 관련된 다양한 기능을 제공한다.
  Kafka는 높은 처리량과 내구성을 제공하여 대규모 데이터 파이프라인 및 스트림 처리에 적합하다.
• RabbitMQ와 ActiveMQ는 브로커가 Consumer로 메시지를 Push 하는 방식이다.
  Kafka는 Consumer가 능동적으로 브로커로부터 메시지를 Pull 하는 방식이다.
• RabbitMQ와 ActiveMQ는 디스크에 메시지를 영구 저장하는 옵션도 지원하지만,
  기본적으로 Consume 된 메시지는 소실된다. 
  Kafka는 기본적으로 모든 메시지를 디스크에 영구저장한다.
  
• RabbitMQ와 ActiveMQ는  P2P와 Pub/Sub 모델을 함께 지원한다.
  Kafka는 Pub/Sub 모델만 지원한다.

 

메시지 큐는 크게 Point to Point와 Pub/Sub 모델로 구분할 수 있다.

Point to Point 모델은 발신자, 수신자 1:1 방식이다. 즉, 메시지 전송 대상이 한 대로 고정되어 있다.

Pub/Sub 모델은 발신자가 토픽이라고 불리는 공간에 메시지를 전송하면, 그 토픽을 구독하고 있는 수신자 모두
메시지를 수신하는 방식이다. 즉, 전송대상이 다수이다.

---

기본적으로 서버 간 데이터를 요청하고 응답받는 경우는 API 방식으로만 처리해 왔기에

MOM의 필요성에 의구심이 들었다. 그래서 조금 더 정리해 보았다.

 

API 방식

• 동기 통신 : API를 호출하는 즉시 응답을 받는다. 호출자는 응답이 돌아올 때까지 대기해야 한다.
• 블로킹 : 호출자는 요청을 보낸 후 응답이 돌아올 때까지 다른 작업을 수행하지 못한다.
• 데이터 무결성 : 데이터가 직접 주고받는 방식이므로 중간에 데이터가 유실되거나 손상될 우려가 있다.
• 의존성 : 호출자와 피호출자 간에 직접적인 의존성이 생긴다.
• 단방향 통신 : 보통 단방향 호출로 이루어지며, 응답이 필요한 경우 다른 호출을 해야 한다.
• RESTful API를 사용하여 HTTP 요청을 통해 데이터를 전송하고 응답받는다.
• SOAP 기반의 웹 서비스에서 클라이언트는 서비스의 메서드를 호출하고 결과를 받는다.

 

MOM 방식

• 비동기 통신 : 메시지 큐를 통해 비동기적으로 메시지를 보내고 받는다. 호출자가 응답을 기다리지 않아도 된다.
• 비블로킹 : 메시지를 보낸 후 다른 작업을 수행할 수 있다.
• 데이터 안정성 : MOM은 메시지를 안전하게 보관하고 처리할 수 있으며, 중간에 메시지가 손실되거나 손상되지
  않도록 보장된다.
• 느슨한 결함 : 메시지 큐를 통해 호출자와 피호출자 간에 느슨한 결합을 유지할 수 있다.
• 다양한 상황에 활용 : 다양한 상황에서 사용 가능하며, 비동기 처리, 이벤트 기반 통신, 분산 시스템 간의 데이터 교환등에 유용하다.

 

어느 것을 선택해야 할까?

• API 호출은 간단하고 직관적이며, 작은 규모의 시스템이나 간단한 요구사항에서는 효과적일 수 있다.
• MOM 방식은 복잡한 분산 시스템에서 유용하며, 비동기 처리, 이벤트 기반 통신, 복잡한 데이터 흐름 등을 다룰 때 특히 효과적이다.

작업의 복잡성, 응답성, 데이터 무결성 등을 고려하여 최적의 방식을 선택하는 것이 중요하다.