[Tech.] Message Broker란?

 

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

 

  예를들어 설명해보자. DW, AS라는 두 개의 서버가 있다. DW는 실시간으로 데이터를 수집하고 관리하는 서버이고, AS는 이 데이터를 가공하여 사용하는 서버이다. AS에서 DW에 있는 데이터를 사용하기위해서 어떻게 해야할까?

 

  가장 일반적인 방법은 DW에서 Oracle, MySQL과 같은 RDB에 적재하고, AS에서는 이 DB에서 조회해서 쓰는 것이다. 그러나, 실시간으로 처리하기 위해서는 최신의 데이터만 빠르게 조회를 해야하는데, 실시간으로 데이터가 계속 쌓이는 TABLE을 빠르게 조회하는 것은 힘들다. 조회 성능을 높이기위해 테이블에 INDEX를 걸면 INSERT 속도가 느려지므로 실시간 처리에는 적합하지않다.

 

  메시지 브로커를 사용하는 방법은 어떨까? DW에서는 수집한 데이터를 바로 메세지 큐에 Publish(출판, 적재)하고 AS는 메시지를 Subscribe(구독, 소비)하여 바로 사용하게 된다. 메시지 브로커를 사용하면 AS에서는 별도의 조회과정이 필요없이, 메세지 큐에 적재되는 메시지를 감시하고 있다가 메시지가 적재되면 바로 가져다가 사용할 수 있다.

 

  이처럼 메시지 브로커는 송신자가 보낸 메시지를 메시지 큐에 적재하고 이를 수신자가 받아서 사용하는 구조이다. 이러한 구조를 Pulibsh/Subscribe(pub/sub) Pattern이라고 하며, Producer/Consumer Pattern 이라고도 한다.

 

  메시지 브로커는 대표적으로 Apache Kafka, Redis, RabbitMQ, Celery 등이 있다. 

 

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