(MessageQueue (MQ))란? 왜사용하게 되었을까?

 

MessageQueue 란? 왜사용하게 되었을까?

먼저, MessageQueue 미사용/사용 웹 서비스 구조의 예시를 보자.
 

• 어플리케이션과 데이터베이스의 동기적 직접통신 구조

'

: 어플리케이션과 DB가 강하게 결합되어 있어 어플리케이션의 요청&응답 과정에서 
DB 서버로의 요청&응답 모두 완료되어야 응답이 가능하다.

따라서 다음과같은 문제가 발생할 수 있다.

1. DB의 응답 시간이 길어진다면 어플리케이션 또한 그만큼 응답시간이 길어진다.
2. DB 장애시 어플리케이션이 동작하지 못한다.
3. 어플리케이션 입장에서 감당할 수있는 요청 수가 DB에서는 감당 불가능하다면,
성능저하나 장애가 발생할 수 있다. 

 

 

• MQ를 통한 어플리케이션과 데이터베이스의 통신

 

 

: 어플리케이션은 큐에 요청을 쌓고, DB는 큐의 요청을 꺼내 처리한다.

1. 어플리케이션은 큐에 요청을 보내고, DB의 응답을 기다리지 않고 응답을 보낼 수 있다.
2. DB 장애 발생시에도 어플리케이션은 독립적으로 동작이 가능하다.
3. 어플리케이션과 DB 사이의 통신을 처리량에 따라 제어할 수 있다.

---

관련개념

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

- 분산 시스템 간 메시지를 주고 받는 기능을 지원하는 소프트웨어나 하드웨어 인프라

Broker: 브로커

- 송신자(sender)와 수신자(receiver) 사이에서 메세지의 전달을 중재하는 컴퓨터 프로그램 모듈
소프트웨어 예시.

- RabbitMQ,  AWS SQS, Apache ActiveMQ , Apache Kafka, IBM MQ

보내는 쪽	Sender	Producer	Publisher
받는 쪽	Recevier	Consumer	Subscriber

 

프로토콜

AMQP(Advanced Message Queuing Protocol)
- 이기종 플램폼간의 상호 메세지 교환 가능.
구현 소프트웨어 예시. (RabbitMQ)

• Subscribe to have messages delivered to them ("push API"): this is the recommended option
• Polling ("pull API"): this way is highly inefficient and should be avoided in most case
  ( push / pull 방식 모두 구현 가능. 하지만 push 권장 )
  https://www.rabbitmq.com/tutorials/amqp-concepts.html

JMS(Java Messaging System)
- 자바 플랫폼간의 상호 메세지 교환 가능. 이기종 플랫폼간은 제한적.
구현 소프트웨어 예시. (Active MQ)

ActiveMq does not select the consumer because JMS is basically a pull system from receiver perspective; the broker does not push. (Consumer에서 pull 하는 방식으로 메세지 처리)

두 프로토콜에 대한 비교 포스팅 참조
:https://m.blog.naver.com/PostView.nhn?blogId=willygwu2003&logNo=130171452288&proxyReferer=https:%2F%2Fwww.google.com%2F

 

---

도입하게 된 이유

자사 서비스 개발중에 도입하게 된 예로는
주문 - 결제 프로세스에서 기존에는 주문이 일어난 후 주문 완료시 결제 프로세스로 넘어가는 구조였다.

그런데 주문 과정에서 외부업체와 연동이 필요한 주문건의 경우에는 주문 완료까지의 시간이 길어
결제 프로세스로 넘어가는데 계속 기다려야하는 문제가 있었다.
따라서, MQ를 도입하여 주문 요청을 MQ에 보낸 후 결제프로세스로 넘어가도록 하고
주문 처리는 MQ에서 꺼내 별도로 진행하도록 수정하였다.

그 결과 주문 후 결제프로세스로 넘어가는 시간이 획기적으로 단축되었다.