나도 드디어 MQ를 사용한 프로젝트를 할 일이 생겼다..!
그렇다면 MQ에 대해서 공부를 해야겠지? ㄱㄱ
메세지 큐를 사용하는 이유
기존의 동기식 통신 방식은 사용자로부터 받은 요청을 전부 처리할 때까지 Blocking 상태에 빠지게 된다.
요청이 전부 처리되어야 사용자에게 응답을 주고 다시 요청을 받을 수 있다.
하지만 메세지 큐 사용 시 요청을 큐에 넣기만 하면 다음 사용자의 요청을 받아들일 수 있게 된다.
activeMQ
JMS(Java Message Service) 클라이언트와 함께 자바로 작성된
오픈 소스 메시지 브로커하나 이상의 클라이언트나 서버로부터 통신을 조성시키는 엔터프라이즈 기능들을 제공
자바 및 기타 여러 언어 간 클라이언트 지원
- 위키피디아 -
JMS
자바 기반의 MOM API 표준이며 둘 이상의 클라이언트 간의 메세지를 보낸다.
자바 플랫폼, 엔터프라이즈 에디션 기반이며, 메시지 생성, 송수신, 읽기를 한다.
ActiveMQ의 JMS 라이브러리를 사용한 자바 어플리케이션간 통신 가능.
비동기, 신뢰성을 가지며 다른 분산 어플리케이션 컴포넌트 간의 통신을 허용한다.
핵심 : Message Broker, Destination
- Message Broker : 목적지에 메세지를 건내주는 중개자
- Destination : 목적지에 배달될 메세지 모델
- QUEUE : 메세지를 받기 위해 Consumer간 경쟁, 연결된 순서대로 메세지 제공
- Topic : Pub/Sub 모델, 구독자 모두에게 메세지 제공
JMS 메세지 구조
헤더, 등록 정보, 본문 3가지 부분으로 구성
헤더
- JMS 메세지 필수 값, 메세지 경로 지정 및 식별에 사용되는 값 포함
헤더 값 설정 방법
- 메세지 생성 또는 전달 프로세스 중 JMS 공급자에 의해 자동 생성
- 메세지 생성자를 작성할 때 지정된 설정을 통해 생성자 클라이언트에 의해
- 메세지 단위의 메세지에서 생성자 클라이언트에 의해
[공식문서]( Message Queue Developer's Guide for Java Clients )
등록 정보
- 등록 정보 이름, 등록 정보 값의 쌍으로 지정
- 데이터를 작성한 프로세스에 대한 정보, 데이터가 작성된 시간, 데이터 각 부분의 구조 포함 가능
본문 유형
| 유형 | 설명 |
|---|---|
| StreamMessage | 본문이 Java 프리미티브 값의 스트림을 포함하는 메시지. 이 메시지는 순차적으로 채워지고 읽혀집니다. |
| MapMessage | 본문에 일련의 이름-값 쌍을 포함하는 메시지. 항목 순서는 정의되지 않습니다. |
| TextMessage | 본문에 Java 문자열을 포함하는 메시지. 예를 들어, XML 메시지 |
| ObjectMessage | 본문에 일련화된 Java 객체를 포함하는 메시지 |
| BytesMessage | 본문에 해석되지 않은 바이트의 스트림이 포함된 메시지 |
JMS API 구현 순서
ConnectionFactory-> Connection-> Session-> MessageProducer-> send번외 - AMQP
- AMQP는
ISO 응용 계층의 MOM 표준으로, 기존 JMS에서 자바 어플리케이션 간의 통신만 가능했다면 여기서는 프로토콜만 일치한다면 다른 AMQP를 사용하더라도 통신이 가능하다.
Kafka, Rabbit MQ, Active MQ는 대표적인 메세지 지향 미들웨어 MOM(Message-oriented middleware)이며, 일반적으로 비동기 메시지 전달을 하기 위해 사용한다.
메세지 지향 미들웨어 MOM(Message-oriented
MOM은 비동기 메세지를 사용하는 다른 응용 프로그램 사이에서 데이터 송수신을 의미한다.
이때 MOM을 구현한 시스템인 Message Que를 이용한다.
메세지 큐의 장점
- 비동기(Asynchronous) : 큐에 데이터를 넣어놓음으로써 필요시 꺼내 쓸 수 있다.
- 비동조(Decoupling) : 어플리케이션과 분리할 수 있다.
- 탄력성(Resilience) : 일부가 실패해도 전체에 영향을 주지 않는다.
- 과잉(Redundancy) : 실패하더라도 재실행이 가능하다.
- 보증(Guarantees) : 작업이 처리되었는지 확인이 가능하다.
- 확장성(Scalable) : 다수의 프로세스들이 큐에 메세지를 보낼 수 있다.
어느 경우에 사용해야 할까?
- 대용량 데이터 처리를 위한 배치 작업
- 비동기 데이터 처리
- 채팅
어느 MQ를 사용해야 잘 썼다고 소문이 날까?
대표적인 MQ 들을 간단하게 비교해보자.
-
RabbitMQ의 경우 번외에서 언급한
AMQP프로토콜을 구현해 놓은 오픈소스이다. -
ActiveMQ는
JMS로 구현한 하나 이상의 클라이언트와 서버 간의 커뮤니케이션을 증진시키는 기능을 제공한다. -
Kafka는 대용량 실시간 로그 처리에 특화되어 설계된 메시징 시스템이다. TPS가 매우 우수하다.
하지만, 특화된 시스템이기 때문에 범용 메세지 시스템에서 제공하는 다양한 기능들은 제공되지 않는다.
> 왜 Kafka가 아닌 ActiveMQ를 사용했는지에 대해 이해할 수 있게 되었다.
특화된 Kafka
기존의 메세징 시스템은 broker가 consumer에게 메세지를 push 해준다.
하지만, Kafka는 Consumer가 broker로부터 직접 메세지를 가지고는 pull 방식으로 동작한다.
- Consumer가 자신의 처리능력만큼 broker로부터 가져오기 때문에 최적의 성능을 낼 수 있다.
- pull 방식으로 가져오기 때문에, 메세지를 쌓아두었다가, 주기적으로 가져오도록 batch consumer를 구현할 수 있다.
- 큐의 기능적인 면에서는 기존의 ActiveMQ, RabbitMQ에 비해서는 부족하지만, 대용량 메세지 전송 성능이 가장 우수하다.
- 특히, 분산 환경에서 복사본을 다른 노드에 저장함으로써 장애 대응성 면에서도 강점을 가진다.
결론
TPS가 높은 고성능 어플리케이션의 경우에는 Kafka를 사용하고,
그렇지 않은 자바 어플리케이션의 경우 다양한 기능이 있는 ActiveMQ를, AMQP 프로토콜 통신이 필요한 경우 RabbitMQ를 활용하는 것이 좋을 것 같다.
※ 장비의 스펙에 따라 TPS는 달라질 수 있으니 하드웨어 적 성능도 고려해야 한다.
참고
https://docs.oracle.com/cd/E19435-01/819-2222/concepts.html
위키백과
'ActiveMQ' 카테고리의 다른 글
| [ActiveMQ] Producer.send 파헤치기 (0) | 2020.10.24 |
|---|
댓글