메시지 큐(Message Queue, MQ)란?

https://blog.naver.com/PostView.nhn?blogId=dktmrorl&logNo=222117711303&categoryNo=0&parentCategoryNo=0&viewDate=&currentPage=1&postListTopCurrentPage=1&from=postView 

[IT정보] 메시지 큐(Message Queue, MQ) 개념

메시지 큐(Message Queue, MQ)란?

메시지 큐(MessageQueue: MQ)는 프로세스 또는 프로그램 인스턴스가 데이터를 서로 교환할때 사용하는 통신 방법입니다. 더 큰 개념으로는 메시지 지향 미들웨어(Meesage Oriented Middleware: MOM)를 구현한 시스템을 의미합니다. 여기서 MOM은 비동기 메시지를 사용하는 응용 프로그램 간의 데이터 송수신을 말합니다.

​

MQ는 별도의 공정 작업을 연기할 수 있는 유연성을 제공하여 SOA(Service-Oriendted Architecture)의 개발에 도움을 줄 수 있습니다.

​

서로 다른 프로세스나 프로그램 사이에 메시지를 교환할 때 AMQP(Advanced Message Queuing Protocol)를 이용합니다. AMQP는 ISO 응용 계층 프로토콜의 MOM 표준입니다.

​

그리고 AMQP는 JMS(Java Message Service)와 비교되는데, JMS는 MOM을 자바(Java)에서 지원하는 표준 API입니다. JMS는 다른 Java Application 간에 통신은 가능하지만 다른 MOM(AMQP, SMTP 등)끼리는 통신할 수 없습니다.

​

그에 반해 AMQP는 프로토콜(Protocol)만 일치한다면 다른 AMQP를 사용한 애플리케이션(Application)과도 통신이 가능합니다. AMQP를 이용하면 다른 벤더 사이에 메시지를 전송하는 것이 가능한데, JMS(Java Message Service)가 API를 제공하는 것과 달리 AMQP는 wire-protocol을 제공하는데 이는 octet stream을 이용해서 다른 네트워크 사이에 데이터를 전송할 수 있는 포맷으로 이를 사용하게 됩니다.

메시지 큐의 장점

▶ 비동기(Asynchronous): 큐(Queue)에 넣기 때문에 나중에 처리할 수 있습니다.

▶ 비동조(Decoupling): 애플리케이션(Application)과 분리할 수 있습니다.

▶ 탄력성(Resilience): 일부가 실패 시 전체에 영향을 받지 않습니다.

▶ 과잉(Redundancy): 실패할 경우 재실행이 가능합니다.

▶ 보증(Guarantees): 작업이 처리된걸 확인할 수 있습니다.

▶ 확장성(Scalable): 다수의 프로세스들이 큐에 메시지를 보낼 수 있습니다.

​

메시지 큐잉(Message Queueing)은 대용량 데이터를 처리하기 위한 배치 작업이나, 채팅 서비스, 비동기 데이터를 처리할 때 사용합니다.

​

프로세스 단위로 처리하는 웹 요청이나 일반적인 프로그램을 만들어서 사용하는데, 사용자가 많아지거나, 데이터가 많아지면, 요청에 대한 응답을 기다리는 수가 증가하다가, 나중에는 대기 시간이 지연되어서, 서비스가 정상적으로 되지 못하는 상황이 오기 때문에, 기존에 분산되어 있던 데이터 처리를 한 곳에 집중하면서, 메시지 브로커를 두어서 필요한 프로그램에 작업을 분산시키는 방법을 하는 것이 그 목적입니다.

메시지 큐 사용처

메시지 큐는 다음과 같이 다양한 곳에 사용이 가능합니다.

​

▶ 다른 곳의 API로 부터 데이터 송수신이 가능합니다.

▶ 다양한 애플리케이션에서 비동기 통신이 가능합니다.

▶ 이메일 발송 및 문서 업로드가 가능합니다.

▶ 많은 양의 프로세스들을 처리할 수 있습니다.

JMS vs AMQP

▶ AMQP는 ISO 응용 계층의 MOM 표준입니다.

▶ JMS는 MOM을 자바에서 지원하는 표준 API입니다. (JMS와 AMQP는 다른 개념입니다)

▶ JMS는 다른 자바 애플리케이션들끼리 통신이 가능하지만 다른 MOM의 통신은 불가능 합니다. (AMQP, SMTP 등)

▶ ActiveMQ의 JMS라이브러리를 사용한 자바 애플리케이션들끼리 통신이 가능하긴 합니다. 하지만 다른 자바 애플리케이션(ActiveMQ를 사용안함)의 JMS와는 통신할 수 없습니다.

▶ AMQP는 프로토콜만 맞다면 다른 AMQP를 사용한 애플리케이션끼리 통신이 가능합니다. SMTP와도 통신이 가능합니다.

▶ JMS 라이브러리는 AMQP를 지원하지는 않습니다.

오픈 소스 메시지 큐 종류

대표적인 메시지 큐 시스템은 다음과 같이 4가지 종류가 있습니다.

​

1. RabbitMQ

2. ActiveMQ

3. ZeroMQ

4. Kafka

​

위의 4가지 시스템은 공통적으로 모두 비동기 통신을 제공하고 보낸 사람과 받는 사람을 분리합니다. 하지만 업무에 따라서 다른 목적을 가지고 있습니다.

1. RabbitMQ

RabbitMQ는 AMQT 프로토콜을 구현해 놓은 프로그램으로써 빠르고 쉽게 구성할 수 있으며 직관적입니다.

​

▶ 신뢰성, 안정성과 성능을 충족할 수 있도록 다양한 기능을 제공합니다.

▶ 유연한 라우팅: Message Queue가 도착하기 전에 라우팅 되며 플러그인을 통해 더 복잡한 라우팅도 가능합니다.

▶ 클러스터링: 로컬네트워크에 있는 여러 RabbitMQ 서버를 논리적으로 클러스터링할 수 있고 논리적인 브로커도 가능합니다.

▶ 관리 UI가 있어 편하게 관리 가능합니다.

▶ 거의 모든 언어와 운영체제를 지원합니다.

▶ 오픈소스로 상업적 지원이 가능합니다.

2. ActiveMQ

ActiveMQ는 자바로 만든 오픈소스 메시지 브로커입니다. JMS 1.1을 통해 자바 뿐만 아니라 다른 언어를 사용하는 클라이언트를 지원합니다.

​

▶ 다양한 언어와 프로토콜 지원합니다(Java, C, C++, C#, Ruby, Perl, Python, PHP클라이언트 지원).

▶ OpenWire를 통해 고성능의 Java, C, C++, C# 클라이언트 지원합니다.

▶ Stomp를 통해 C, Ruby, Perl, Python, PHP 클라이언트가 다른 인기있는 메시지 브로커들과 마찬가지로 ActiveMQ에 접근 가능합니다.

▶ Message Groups, Virtual Destinations, Wildcards와 Composite Destination를 지원합니다.

▶ JMS 1.1과 J2EE 1.4를 완벽하게 지원하며, transient, persistent, transactional, XA 메시징을 지원합니다.

▶ Spring 지원으로 ActiveMQ는 Spring Application에 매우 쉽게 임베딩될 수 있으며, Spring의 XML 설정 메커니즘에 의해 쉽게 설정 가능합니다.

▶ Geronimo, JBoss 4, GlassFish, WebLogic과 같은 인기있는 J2EE 서버들과 함께 테스트됩니다.

▶ 고성능의 저널을 사용할 때에 JDBC를 사용하여 매우 빠른 Persistence를 지원합니다.

▶ REST API를 통해 웹기반 메시징 API를 지원합니다.

▶ 웹 브라우저가 메시징 도구가 될 수 있도록, Ajax를 통해 순수한 DHTML을 사용한 웹 스트리밍 지원합니다.

▶ In-memory JMS Provider로 사용될 수 있으며, 이는 JMS를 사용한 단위 테스트에 적합한 솔루션을 제공합니다.

3. ZeroMQ

ZeroMQ는 메시징 라이브러리입니다. 많은 수고를 들이지 않고도 복잡한 커뮤니케이션 시스템을 설계할 수 있도록 해줍니다. ZeroMQ는 스스로 효율적으로 설명하기 위해 지금까지 많은 노력을 해왔습니다. 처음에는 '메세징 미들웨어'로 소개되었지만, 나중에는 '스테로이드를 맞은 TCP' 그리고 나중에는 '네트워크 스택의 새로운 레이어'라고 말합니다. ZeroMQ(oMQ, zmq)는 임베디드 네트워킹 라이브러리 이지만, 동시성 프레임워크와 같은 역할을 합니다.

​

ZeroMQ는 대부분의 AMQP들 보다 단위가 다를 정도로 빠릅니다. 그 이유는 다음과 같은 기술을 보유하기 있기때문에 가능한 것입니다.

​

▶ AMQP처럼 과도하게 복잡한 프로토콜이 없습니다.

▶ 신뢰성 있는 멀티캐스트나 Y-suite IPC 전송같은 효율적인 전송을 활용합니다.

▶ 지능적인 메시지 묶음을 활용합니다. 이것은 ZeroMQ로 하여금 프로토콜 오버헤드뿐만 아니라 시스템 호출을 줄여서 TCP/IP를 효율적으로 사용하게 합니다.

▶ 소켓 버퍼에 계속 '값을 채워' 주어야 하는 소켓 방식에 비교하면, 메시지를 보내는 방식이 단순합니다.

▶ 비동기 send 호출만 하면, 메시지를 별도의 스레드의 큐에 넣고 필요한 모든 작업을 해줍니다.

▶ 단순한 와이어 프로토콜을 지니고 있으므로, 다양한 전송 프로토콜이 사용되는 요즘에 적합합니다.

▶ 메세지를 BLOB(Binary Large Object)으로 보기에 메시지 인코딩 방식을 상관하지 않습니다. JSON, BSON, Protocol Buffers, Thrift 같은 바이너리 방식 메시지들도 괜찮습니다.

▶ ZeroMQ의 소켓은 복수의 접점을 가질 수 있으며, 그것들 간에 자동으로 메시지 부하 분산을 수행합니다.

▶ ZeroMQ는 하나의 소켓으로 복수의 소스에서 메시지들을 받아들이는 게이트 역할을 할 수도 있습니다.

4. Kafka

Kafka는 확장성과 고성능 및 높은 처리량을 내세운 제품이라고 보시면 됩니다. 특화된 시스템이기 때문에 범용 메시징 시스템에서 제공하는 다양한 기능들은 제공되지 않습니다. 분산 시스템을 기본으로 설계되었기 때문에 기존 메시징 시스템에 비해 분산 및 복제 구성을 손쉽게할 수 있습니다.

​

▶ 대용량 실시간 로그 처리에 특화되어 있습니다.

▶ AMQP 프로토콜이나 JSM API를 사용하지 않고 단순한 메시지 헤더를 지닌 TCP 기반 프로토콜 사용함으로써 오버헤드가 비교적 작습니다.

▶ 노드 장애에 대한 대응성을 가지고 있습니다.

▶ 프로듀서는 각 메시지를 배치로 브로커에게 전달하여 TCP/IP 라운드 트립을 줄였습니다.

▶ 메시지를 기본적으로 파일 시스템에 저장하여 별도의 설정을 하지 않아도 오류 발생 시 오류 지점부터 복구가 가능합니다(기존 메시징 시스템은 메시지를 메모리에 저장).

▶ 메시지를 파일시스템에 저장하기 때문에 메시지가 많이 쌓여도 기존 메시징 시스템에 비해 성능이 크게 감소하지 않습니다.

▶ window 단위의 데이터를 넣고 꺼낼 수 있습니다.