메세지 브로커 개요

정의

---

 

- 메시지 브로커(message broker), 인터페이스 엔진(interface engine)은 송신자의 메시지 프로토콜 형식으로부터의 메시지를 수신자의 메시지 프로토콜 형식으로 변환하는 중간 컴퓨터 프로그램 모듈이다.

- 메시지 브로커들은 응용 소프트웨어가 이전에 정의해둔 메시지를 교환할 수 있는 전기통신의 요소 또는 컴퓨터 네트워크이다.

- 메시지 브로커들은 메시지 지향 미들웨어(MOM)의 빌딩 블록이지만 일반적으로 MOM과 원격 프로시저 호출(RPC) 등의 전통적인 미들웨어를 대체하지는 않는다

 

 

 

 

 

 

특징

---

 

 

- 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를 사용하는 경우 Query를 이용하여 원하는 데이터만 필터링하여 조회할 수 있지만, 메시지 브로커를 이용하면 Queue에 적재된 그대로 사용하기 때문에 불가능하다. 따라서,

적재할 때 필터링된 데이터를 적재하던가 적재된 데이터를 Logstash를 이용하여 필터링해서 사용해야 한다.

또한, 메시지 큐에 적재된 메시지는 주로 7일을 보관하기 때문에 장기간 보관해야하는 경우 별도의 저장소에 저장해야한다.

 

 

 

용어 정리

---

 

 

• MOM (Message Oriented Middleware): 메시지 미들웨어의 이론, 개념, 설계도를 의미
• Message Queue:'애플리케이션 간의 메시지 큐를 통한 단순한 형태의 통신 솔루션'.메시지 전송을 위해 메시지 큐, 메시지 전송 구조를 가진 미들웨어로 볼 수 있습니다.
• Message Broker: 메시지 브로커는 메시지 큐에서 더 확장된 기능을 가지고 있다고 봅니다. 더 광범위한 전송, 메시지 내용을 통한 라우팅 및 추가/고급 기능 등을 지원하고, 구현체 별로 어떤 방식을 통해 메시지를 전달하고, 내부 구조를 어떻게 구현했는가에 따라 동작하는 방식, 목적, 성능이 달라집니다.

 

---

 

MOM (Message Oriented Middleware)

 

 

Message Broker에 대해 알아가기전에 MOM. 즉, 메시지 지향 미들웨어부터 알아봅시다.

 

이름에서부터 역할을 알 수 있듯, 어플리케이션들의 메시지를 중간에서 관리해주는 시스템입니다.

• 여러 클라이언트 시스템간에 메시지 통신을 중간에서 관리해줌으로써 클라이언트 시스템간의 종속성 및 결속성을 낮춰줍니다. 메시지를 보내는 이는 받는 이의 주소를 몰라도 보낼 수 있게 됩니다.
• 주고 받는 메시지를 데이터베이스 등에 기록하는 등 백업 할 수 있기에 안정성을 높여줍니다.
• 라우팅 규칙을 활용하여 하나의 메시지로도 특정 여러 클라이언트가 받을 수 있도록 지원합니다.

 

 

물론, 단점도 존재합니다.

• 메시지 전체를 관리하는 시스템이 따로 필요합니다. 중앙에서 메시지를 관리할 수 있는 주체가 필요하기 때문에 이에 대한 도입 비용, 운영 비용 등 고려해야합니다.
• 당연히 전체적인 시스템 구조가 복잡해질 수 있습니다. 송수신자가 직접 통신하는게 아니므로 다수의 서버가 MOM을 활용하게 되면 구조가 전체적으로 복잡해지고, 이에 대한 오버헤드가 발생할 수 있습니다.

 

앞에서 말했듯 MOM은 이론, 개념, 설계적인 방향성을 제시하고 있다고 보면 됩니다. 직접적인 구현체는 아닙니다.

MOM 시스템을 두고 여러 계층에서의 표준 및 프로토콜이 등장하게 됩니다.

• MOM을 Java에서 지원하는 표준 API인 JMS (Java Messaging System)
• 미들웨어 브로커 간 메시지 교환을 위한 메시지 지향 미들웨어 Application layer 표준 프로토콜인 AMQP(Advanced Message Queue Protocol)

 

 

또한 이러한 MOM의 개념과 표준 및 프로토콜을 활용하여 다양한 구현체들이 등장하였습니다. 메시징 미들웨어(브로커)라는 것에는 다름이 없으나 내부적으로 동작하는 방식, 프로토콜, 제공하는 기능, 성능 등 차이점이 존재합니다.

• ActiveMQ: https://activemq.apache.org/
• RabbitMQ: https://www.rabbitmq.com/
• ZeroMQ: https://zeromq.org/
• Apache Kafka: https://kafka.apache.org/
• Amazon SQS: https://aws.amazon.com/ko/sqs/
• 등등

---

 

---

메시지 브로커의 단점

 

Bottleneck point(병목현상 지점)이 될 수 있습니다.

• 많은 고객 수로 인해 서버들이 확장(Scale-out)하는 상황에서 만약 메시지 브로커는 기존 수 그대로 남아있다면, 늘어난 고객 수 및 서버 수의 요청을 같은 수의 메시지 브로커로 감당하는 것이므로 당연히도 병목현상이 발생할 수 있습니다. 메시지 큐에 메시지가 쌓이면서 요청을 처리하는 속도가 느려질 수 있습니다.
• 하지만 최근 많은 메시지 브로커들이 확장이 가능한 구조로 설계되어 이러한 문제는 적어지고 있습니다. 서버 수의 증가에 따라 메시지 브로커의 수도 확장해나감으로서 문제를 해결할 수 있습니다.

메시지 브로커도 죽을 수 있습니다.

• 메시지 브로커가 죽게되면 송신 및 수신 측의 커뮤니케이션이 불가능한 상태가 되므로 SPOF(Single Point Of Failure)가 될 수 있습니다.
• 이러한 메시지 브로커의 문제를 이해해 서버 구조를 설계해야하며, 다행히도 요즘 메시지 브로커는 고가용성이 보장되도록 설계되었습니다.

메시지 브로커를 운영해야합니다.

• 일반 서버와 별개로 메시지 브로커(서버)를 운영해야합니다. 정상적으로 동작하는지 확인하거나, 알람 기능을 추가해 생성해야 한다거나, 버전을 꾸준히 업데이트 해줘야한다거나, 버전 업그레이드로 인한 문제가 발생하진 않는지 확인하는 등 여러 이슈들을 확인하고 해결해나가야 합니다.
• 운영비용이 증가

 

참조

https://ko.wikipedia.org/wiki/%EB%A9%94%EC%8B%9C%EC%A7%80_%EB%B8%8C%EB%A1%9C%EC%BB%A4

메시지 브로커 - 위키백과, 우리 모두의 백과사전

https://heodolf.tistory.com/49

[Tech.] Message Broker란?

https://binux.tistory.com/74

Message Broker - 왜 사용하는 것일까 ?