Message Queue

Message Queue

프로세스 또는 프로그램 간에 데이터를 교환할 때 사용하는 통신 방법 중에 하나로,

메시지 지향 미들웨어(Message Oriented Middleware:MOM)를 구현한 시스템

 

 

 

메시지 지향 미들웨어 (MOM)

응용 소프트웨어 간의 데이터(비동기 메시지) 통신을 위한 소프트웨어

• 메시지 : 요청, 응답, 오류 메시지 혹은 단순한 정보 등의 작은 데이터

메시지 지향 미들웨어는 메시지를 전달하는 과정에서 보관하거나 라우팅 및 변환할 수 있다는 장점을 가진다.

• 메시지의 백업을 유지함으로써 지속성을 제공하기 때문에 송수신 측은 동시에 네트워크 연결을 유지할 필요가 없다
• 하나의 메시지를 여러 수신자에게 배포가 가능하다
• 송수신 측의 요구에 따라 메시지를 변환할 수 있다

=> 메시지 큐는 메시지를 임시로 저장하는 간단한 버퍼다 !

메시지를 전송 및 수신하기 위해 중간에 메시지 큐를 놓는다.

메시지 큐를 이용하는 방식을 일대일 통신이라고 부른다.

 

메시지 큐의 특징

• 비동기(Asynchronous) : 데이터를 수신자에게 바로 보내지 않고 큐에 넣고 관리하기 때문에 나중에 처리 가능하다.
• 낮은 결합도(Decoupling) : 생산자 서비스와 소비자 서비스가 독립적으로 행동하게 됨으로써 서비스 간 결합도가 낮아진다.
• 탄력성(Resilience) : 일부가 실패하더라도 전체에 영향을 주지 않는다.
• 용장성(Redundancy) : 실패할 경우 재실행이 가능하다
• 보장성(Guarantees) : 메시지 큐는 큐에 보관되는 모든 메시지가 결국 소비자 서비스에게 전달된다는 일반적인 보장을 제공한다.
• 확장성(Scalable) : 생산자 서비스 혹은 소비자 서비스를 원하는 대로 확장할 수 있기 때문에 확장성이 좋다.

 

메시지 큐를 사용하는 경우

일반적인 클라이언트-서버 구조에서는 사용자가 요청을 하면 서버는 그에 대한 처리를 한 후 클라이언트에게 응답을 한다.

그러므로 간단한 서버 구조에서는 굳이 메시지 큐를 사용할 필요가 없다.

사용자가 응답을 기다려야 하는 HTTP 요청을 바로 처리하지 않고 중간에 메시지 큐를 두는 경우는 바람직하지 않다.

 

메시지 큐는 어플리케이션의 부가적인 기능에 사용하는 것이 적합하다.

 

대용량 데이터를 처리하기 위한 배치 작업이나, 채팅 서비스, 비동기 데이터를 처리할 때 활용된다.

예를 들어 1만 개의 요청이 발생했을 때 모든 요청을 서버로 보내는 것이 아니라 메시지 큐에 보내고, 서버 측에서는 처리하는데 이상 없을 정도의 요청들만 메시지 큐에서 가져와서 처리해준다면 서버의 부담을 줄일 수 있다.

• 다른 곳의 API로부터 데이터 송수신 가능
• 다양한 애플리케이션에서 비동기 통신 가능
• 이메일 발송 및 문서 업로드 가능
• 많은 양의 프로세스들을 처리 가능

 

 

대표적인 메시지 큐

RabbitMQ, ActiveMQ, Kafka

 

RabbitMQ

• AMQP(Advanced Message Queuing Protocol) 프로토콜을 구현해 놓은 오픈소스 메세지 브로커
  • AMQP : 메시지 지향 미들웨어를 위한 개방형 표준 응용 계층 프로토콜
• 신뢰성, 안정성과 성능을 충족할 수 있도록 다양한 기능을 제공
• 메시지 큐가 도착하기 전에 라우팅 되며 플러그인을 통해 더 복잡한 라우팅도 가능
• 로컬 네트워크에 있는 여러 RabbitMQ 서버를 논리적으로 클러스터링 할 수 있고 논리적인 브로커도 가능하다.
• 관리 UI가 있어서 편하게 관리 가능하다.
• 거의 모든 언어와 운영체제를 지원한다.

사용하는 케이스

• 요청을 많은 사용자에게 전달할 때
• 요청에 대한 처리시간이 길 때
• 많은 작업이 요청되어 처리를 해야할 때

해당하는 요청을 다른 API에게 위임하고 빠른 응답을 할 때 많이 사용한다. MQ를 사용하면 애플리케이션간에 결합도를 낮출 수 있다는 장점도 가진다.

 

ActiveMQ

• Java로 만든 오픈소스 메시지 브로커
• JMS를 통해 다양한 언어와 프로토콜 지원(Java, C, C++, C#, Ruby, Perl, Python, PHP 클라이언트 지원)
• Message Groups, Virtual Destinations, Wildcards와 Composite Destinations 지원
• JMS 1.1과 J2EE 1.4를 완벽하게 지원하며, transient, persistent, transactional, 그리고 XA 메시징 지원
• Spring 지원으로 ActiveMQ는 Spring 애플리케이션에 매우 쉽게 임베딩 될 수 있으며, Spring의 XML 설정 메커니즘에 의해 쉽게 설정 가능
• 고성능의 클러스터링, 클라이언트-서버, Peer 기반 통신을 지원을 위한 설계가 되어 있음
• REST API를 통해 웹 기반 메시징 API를 지원

 

AMQP vs JMS

• AMQP는 ISO 응용 계층의 MOM 표준이며, JMS는 MOM을 Java에서 지원하는 표준 API이다.
• JMS는 다른 Java 애플리케이션끼리 통신이 가능하지만, 다른 MOM의 통신은 불가능(AMQP, SMTP 등)
• AMQP는 프로토콜만 맞다면 다른 AMQP를 사용한 애플리케이션끼리 통신이 가능
• JMS 라이브러리엔 AMQP를 지원하지 않는다.

 

Kafka

• 대용량의 실시간 로그 처리에 특화되어 설계된 메시징 시스템
• 분산 시스템을 기본으로 설계되었기 때문에, 기존 메시징 시스템에 비해 분산 및 복제 구성을 손쉽게 할 수 있다.
• AMQP 프로토콜이나 JMS API를 사용하지 않고 단순한 메시지 헤더를 지닌 TCP기반의 프로토콜을 사용하여 프로토콜에 의한 오버헤드를 감소시킨다.
• 파일 시스템에 메시지를 저장하기 때문에 별도의 설정을 하지 않아도 데이터의 영속성(durability)이 보장된다..
• 메시지를 pull 방식으로 가져오므로, 메시지를 쌓아두었다가 주기적으로 처리하는 batch consumer의 구현이 가능하다.
• 다수의 메시지를 batch형태로 broker에게 한 번에 전달할 수 있어 TCP/IP 라운드트립 횟수를 줄일 수 있다.

 

RabbitMQ vs ActiveMQ vs Kafka ?

일반적으로 RabbitMQ, ActiveMQ는 신뢰성 있는 메시지 브로커가 필요한 경우 사용하고,

Kafka는 처리량이 많은 분산 메시징 시스템에 사용된다.

 

RabbitMQ : 빠르고 쉽게 구성 할 수 있으며 직관적.

• AMQT 프로토콜을 구현해놓은 프로그램, 신뢰성, 유연한 라우팅, UI의 편리성

ActiveMQ : 효율적이고 사용하기 쉬운 오픈 소스.

• 자바로 만든 오픈소스 메시지 브로커
• 다양한 언어와 프로토콜을 지원

Kafka : 확장성, 고성능 및 높은 처리량.

• 대용량 실시간 로그 처리에 특화, 단순한 메시지 헤더를 지닌 TCP 기반의 프로토콜 사용으로 오버헤드 감소