[용어정리] Message Queue(메시지큐)

Message Queue를 알기 전 알고 가야하는 개념들

---

동기 vs 비동기 : bbo-blog.tistory.com/46 

 

MOM (Message Oriented Middleware : 메시지 지향 미들웨어) 

• 응용 소프트웨어 간의 데이터 통신을 위한 소프트웨어이며, 일반적으로 비동기 메시지 전달에 기초한 것

 

 

 

MOM의 장점 

• 지속성 : 많은 메시지 지향 미들웨어는 전송되는 메시지의 백업을 유지한다.  송신 측과 수신 측 동시에 네트워크에 연결되어 있을 필요는 없다.
• 라우팅 : 미들웨어 계층 자신이 직접 메시지 라우팅이 가능하다. 하나의 메시지를 여러 수신자에게 배포 할 수 있다.
• 변환 : 메시지 지향 미들웨어는 수신자가 수신 메시지는 보낸 사람이 보낸 메시지 그 자체일 필요는 없다. 지능형 시스템에서는 송신 측과 수신 측의 요구에 따라 메시지의 변환이 가능하다. 라우팅 및 브로드캐스트/멀티캐스트와 함께 사용하면 응용 프로그램이 메시지를 자신의 형식으로 발송하고 여러 개의 수신 응용 프로그램 고유의 형식으로 변환된 메시지를 받을 수 있다.

 

MOM의 단점

 

• 아키텍처에 외부 구성 요소인 메시지 전송 에이전트를 필요로 한다는 점. 일반적으로 새로운 요소를 추가하면 시스템 성능이 저하되고, 신뢰성도 떨어진다.
• 시스템 전체로 볼 때 관리가 어렵고 비용도 더 들어가게 된다.

 

 

MOM의 표준

 

[ JMS VS AMQP ]

• AMQP는 ISO 응용 계층의 MOM 표준이다.
• JMS는 MOM을 자바에서 지원하는 표준 API이다. (JMS와 AMQP는 다른 개념)
• JMS는 다른 자바 애플리케이션들끼리 통신이 가능하지만 다른 MOM의 통신은 불가능 하다. (AMQP, SMTP 등)
• ActiveMQ의 JMS라이브러리를 사용한 자바 애플리케이션들끼리 통신이 가능하지만 다른 자바 애플리케이션(ActiveMQ를 사용안함)의 JMS와는 통신할 수 없다.
• AMQP는 프로토콜만 맞다면 다른 AMQP를 사용한 애플리케이션끼리 통신이 가능하다. SMTP와도 통신이 가능함.
• JMS 라이브러리는 AMQP를 지원하지 않음.

 

 

 

Message Queue란?

---

Message Queue의 개념

• 프로세스(프로그램) 간 데이터를 교환할 때 사용하는 통신 방법 중 하나
• MOM (Message Oriented Middleware : 메시지 지향 미들웨어) 의 구현을 의미
• brocker라고 불리기도 함

 

Message Queue의 장점

• 비동기 : Queue에 넣기 때문에 나중에 처리 가능
• 비동조 : Application과 분리 할 수 있다
• 탄력성 : 일부가 실패해도 전체는 영향을 받지 않는다
• 과잉 : 실패할 경우 재실행 가능
• 확장성 : 다수의 프로세스들이 큐에 메시지를 보낼 수 있다.

 

Message Queue의 단점

• 즉각적인 서비스가 불가능

 

Message Queue의 사용 분야

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

 

 

Message Queue의 종류

---

MQ별 Producer 성능

MQ별 Consumer 성능

 

Spring Intergration

•  Spring Integration 은 스프링 프레임웍의 기능에 Enterprise Integration Pattern 을 지원하는 확장 기능을 제공한다. 스프링 기반 어플리케이션 내에 가벼운 메시징 기반 서비스를 제공하고 선언적 어뎁터를 사용해 외부 시스템과의 통합을 쉽게 해준다. 이런 어뎁터들은 리모팅, 메시징, 스케쥴링과 같이 스프링이 제공하는 기능들을 추상화하고 있다.
• Spring Integration 은 스프링 프레임웍의 기본 기능에 Messages, Message Channel, EndPoint 라는 3가지 핵심 컴포넌트를 추가로 제공해 준다.

 

장점)

•  스프링 기반이기 때문에, 스프링에 쉽게 적용 가능
• TaskExcutor를 이용한 단순한 구조

단점)

• 확장성 부족(로드밸런싱, 클러스터링 불가능)
• 시스템 에러시, 데이터 유실
• 모니터링 도구 없음

 

ActiveMQ

• 아파치 ActiveMQ는 풀 자바 메시지 서비스(JMS) 클라이언트와 함께 자바로 만든 오픈소스 메시지 브로커이다. 
• 이 시스템은 엔터프라이즈 기능(하나 이상의 클라이언트와 서버간의 커뮤니케이션을 증진시키는 기능)을 제공한다.
• JMS 1.1을 통해 자바 뿐만 아니라 다른 "교차언어"를 사용하는 클라이언트를 지원하고 커뮤니케이션은 컴퓨터 클러스터링 및 가상메모리, 캐쉬 그리고 저널 지속성을 제외한 어떤 데이터베이스를 JMS 지속성 제공자로 이용할 수 있는지 등의 특징들을 통해 운영된다.

 

• 다양한 언어 환경의 클라이언트들과 프로토콜을 지원하여, 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 Destinations를 지원.
• JMS 1.1과 J2EE 1.4를 완벽하게 지원하며, transient, persistent, transactional, 그리고 XA 메시징을 지원.
• Spring 지원으로 ActiveMQ는 Spring 애플리케이션에 매우 쉽게 임베딩될 수 있으며, Spring의 XML 설정 메커니즘에 의해 쉽게 설정됩니다.
• Geronimo, JBoss 4, GlassFish, 그리고 WebLogic과 같은 인기있는 J2EE 서버들과 함께 테스트 가능.
• Inbound와 Outbound 메시징을 위한 JCA 1.5 Resource Adapter를 포함하여 ActiveMQ가 J2EE 1.4 호환 서버에 자동 배치.
• In-VM, TCP, SSL, NIO, UDP, Multicast, JGroups, 그리고 JXTA Transport들과 같은 플러그인 가능한 전송 프로토콜들을 지원.
• 고성능의 저널을 사용할 때에 JDBC를 사용하여 매우 빠른 Persistnece를 지원.
• 고성능의 클러스터링, 클라이언트-서버, Peer 기반 통신을 지원을 위한 설계가 되어 있다.
• REST API를 통해 웹기반 메시징 API를 지원.
• 웹브라우저가 메시징 도구가 될 수 있도록, Ajax를 통해 순수한 DHTML을 사용한 웹스트리밍 지원.
• In-memory JMS Provider로 사용될 수 있으며, 이는 JMS를 사용한 단위 테스트에 적합한 솔루션을 제공.
• STOMP, AMQP, MQTT, Openwire, SSL, and WebSockets

 

 

 

ZeroMQ

• 메시징 라이브러리.
• ZeroMQ는 iMatix에서 만들어졌으며, LGPL 오픈소스 소프트웨어이다.
• 많은 수고를 들이지 않고도 복잡한 커뮤니케이션 시스템을 설계할 수 있도록 해준다.
• ZeroMQ(oMQ, zmq)는 임베디드 네트워킹 라이브러리 이지만, 동시성 프레임워크와 같은 역할을 한다.
• ZeroMQ는 in-process, inter-process, TCP, and multicast 처럼 다양한 방식으로 메시지를 전송하는 소켓을 제공한다. fanout, pub-sub, tsak distribution, and request-reply와 같은 패턴으로 N-to-N 소켓을 연결할 수 있다.
• 클러스터 구조에서 충분한 속도를 제공.
• 비동기 I/O 모델은 비동기 메시지 처리를 제공하는 확장 멀티 코어 애플리케이션을 제공하고 language API를 제공하며 대부분의 운영 체제에서 실행된다.

 

• 퍼포먼스 - API가 간단, 비동기 send 호출을 불면 메시지를 별도의 스레드 큐에 넣고 필요한 모든 일은 해준다. 비동기 특성이라 메시지 처리에 시간 낭비 하지 않고 이벤트 중심의 프레임워크에 최적이다.
• 단순성 - 단순한 와이어 프로토콜은 다양한 전송 프로토콜이 사용되는 요즘에 적합하다. 메시지를 BLOB(Binary Large Object)으로 보기에 메시지 인코딩 방식을 상관하지 않는다. 
• 확장성 - JeroMQ 소켓들은 다양한 기능을 제공한다.

 

Kafka

• 대용량의 실시간 로그 처리에 특화되어 설계된 메시징 시스템으로써 기존 범용 메시징 시스템대비 TPS가 매우 우수하다. (단, 특화된 시스템이기 때문에 범용 메시징 시스템에서 제공하는 다양한 기능들은 제공되지 않음)
• 분산 시스템을 기본으로 설계되었기 때문에, 기존 메시징 시스템에 비해 분산 및 복제 구성을 쉽게 할 수 있다.
• AMQP 프로토콜이나 JMS API를 사용하지 않고 단순한 메시지 헤더를 지닌 TCP 기반의 프로토콜을 사용하여 프로토콜에 의한 오버헤드를 감소시킨다.
• Producer가 broker에게 다수의 메시지를 전송할 때 각 메시지를 개별적으로 전송해야하는 기존 메시징 시스템과는 달리, 다수의 메시지를 batch형태로 broker에게 한번에 전달할 수 있어 TCP/IP 라운드트립 횟수를 줄일 수 있다.
• 메시지를 기본적으로 메모리에 저장하는 기존 메시징 시스템과는 달리 메시지를 파일 시스템에 저장.
• 파일 시스템에 메시지를 저장하기 때문에 별도의 설정을 하지 않아도 데이터의 영속성(durabiility)이 보장.
• 기존 메시징 시스템에서는 처리되지 않고 남아있는 메시지의 수가 많을 수록 시스템의 성능이 크게 감소하였으나, Kafka에서는 메시지를 파일 시스템에 저장하기 때문에 메시지를 많이 쌓아두어도 성능이 크게 감소하지 않는다. 
• Consumer에 의해 처리된 메시지(acknowledged message)를 곧바로 삭제하는 기존 메시징 시스템과는 달리 처리된 메시지를 삭제하지 않고 파일 시스템에 그대로 두었다가 설정된 수명이 지나면 삭제하도록 처리.
• 처리된 메시지를 일정 기간동안 삭제하지 않기 때문에 메시지 처리 도중 문제가 발생하였거나 처리 로직이 변경되었을 경우 consumer가 메시지를 처음부터 다시 처리(rewind)하도록 할 수 있다.
• 기존의 메시징 시스템에서는 broker가 consumer에게 메시지를 push해 주는 방식인데 반해, Kafka는 consumer가 broker로부터 직접 메시지를 가지고 가는 pull 방식으로 동작. 따라서 consumer는 자신의 처리능력만큼의 메시지만 broker로부터 가져오기 때문에 최적의 성능을 낼 수 있다.
• 기존의 push 방식의 메시징 시스템에서는 broker가 직접 각 consumer가 어떤 메시지를 처리해야 하는지 계산하고 어떤 메시지를 처리 중인지 트랙킹하였다면, Kafka에서는 consumenr가 직접 필요한 메시지를 broker로 부터 pull하므로 broker의 consumer와 메시지 관리에 대한 부담이 경감된다.
• 메시지를 pull 방식으로 가져오므로, 메시지를 쌓아두었다가 주기적으로 처리하는 batch consumer의 구현 가능함.
• 큐의 기능은 기존의 JMS의 AMQP 기반의 RabbitMQ(데이터 기반 라우팅, 페데레이션 기능 등)등에 비해서는 많이 부족하지만 대용량 메세지를 지원할 수 있는 것이 가장 큰 특징. 특히 분산환경에서 용량 뿐 아니라, 복사본을 다른 노드에 저장함으로써 노드 장애에 대한 장애 대응성을 가지고 있기 때문에 용량에 강점이 있다.

 

Luxun

• Kafka와 전체적으로 유사한 구조.
• BigQueue라는 Memory mapped file 기반 시스템 사용. (성능상 우위를 내는 주요 요인)
• Communictaion layer로 Thrift RPC 사용

 

 

Amazon SQS

• 메시지크기 256KB 제한 (그 이상은 Amazon S3에 저장됨)
• FIFO 엄격하게 지켜지지 않음. (순서를 엄격하게 지키기 위해선 추가적인 정렬 필요)
• 메세지를 여러 서버에 충분히 중복해서 저장하여 안정성 보장. 메세지가 전달된 다음에 직접 삭제를 하지 않으면 일정 시간 뒤 중복해서 받는 것이 가능함.
• 강력한 보안 및 ACL 지원

 

 

RabbitMq

 

 

 

 

 

출처: https://12bme.tistory.com/176 [길은 가면, 뒤에 있다.]

출처: https://heowc.tistory.com/35 [허원철의 개발 블로그]