STOMP

STOMP는 Simple Text Orientated Messaging Protocol의 약자이다. 웹 소켓 위에서 사용되며 중개 서버를 통한 클라이언트간에 비동기적 메시지 전송을 위한 프로토콜이다. 텍스트 기반의 메시지 형식을 사용한다.

• subscribe 와 publish 를 기반으로 동작
  SUB : 하나의 채널을 클라이언트가 구독
  PUB : 하나의 채널을 구독 중인 모든 클라이언트에게 메시지를 발행

• STOMP 서버
  메시지가 전송될 수 있는 여러 목적지(채널)로 구성
  각 목적지는 형식이 정해져있지 않은 문자열
  메시지 전송 전략을 따로 정의하지 않고, 서버와 목적지 별로 달라질 수 있음

• STOMP 클라이언트
  생산자로서 SEND 프레임을 통해 서버에게 메시지를 보냄
  소비자로서 SUBSCRIBE 프레임을 사용해 특정 목적지에 메시지를 보내고, MESSAGE 로 프레임을 받음

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일을 보관하기 때문에 장기간 보관해야하는 경우 별도의 저장소에 저장해야한다.