메세지 큐

*메세지 큐(Message Queue)

 메시지 큐는 시스템이 처리할 일을 차례대로 넣어놓고 시스템이 하나씩 작업을 가져가 처리하도 다음 작업을 또 가져올 수 있는 Store-and-Forward 방식의 시스템이다. 이런 의미에서 보면 job scheduler와 유사한 역할을 한다.

 

 

 

 

 

*pub/sub 구조

 Pub/Sub 모델은 비동기 메시징 방식이다. 이메일 발신에서 사용하는  To:, CC:처럼 특정 수신자를 정하는 것이 아니라, Publlish 하는 Topic(토픽)을 Subscriber(구독자) 신청한 모든 수신자에게 메시지를 보내는 방식이다. 수신자는 송신자의 IP 주소나, 특별한 정보를 알 필요가 없이 원하는 주제만 사전에 구독 신청을 하면 된다. 따라 송수신자는 loosely coupled로 엮여있고 높은 확장성을 제공한다. 메시지 큐의 대다수의 구현체는 Pub/Sub 구조를 가지고 있다.

 

* 메세지 브로커(Message Broker)

 Publisher(송신자)로부터 전달받은 메시지를 Subscriber(수신자)로 전달해주는 중간 역할이며 응용 소프트웨어 간에 메시지를 교환할 수 있게 한다. 이 때 메시지가 적재되는 공간을 Message Queue(메세지 큐)라고 하며 메시지의 그룹을 Topic(토픽)이라고 한다.

 

cache server를 redis에 별도로 저장하듯이, 메세지 큐 또한 별도의 서버를 둘 수 있다.(kafka, rabbitMQ)

 

queue들이 모두 동일하지 않으므로 해당 queue들을 구분하기 위해서 exchange로 나누어서 저장하고 전송하도록 방법을 다르게 한다.

 

 

*주의점

 주의해야 하는건, DB를 사용하는 경우 Query를 이용하여 원하는 데이터만 필터링하여 조회할 수 있지만, 메시지 브로커를 이용하면 Queue에 적재된 그대로 사용하기 때문에 불가능하다. 따라서, 적재할 때 필터링된 데이터를 적재하던가 적재된 데이터를 Logstash를 이용하여 필터링해서 사용해야 한다. 또한, 메시지 큐에 적재된 메시지는 주로 7일을 보관하기 때문에 장기간 보관해야하는 경우 별도의 저장소에 저장해야한다.

 

 

*참고

- [Tech.] Message Broker란?

https://heodolf.tistory.com/49