> For the complete documentation index, see [llms.txt](https://jmxx219.gitbook.io/cs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jmxx219.gitbook.io/cs/database/message-broker.md). # Message Broker
## MOM (Message Oriented Middleware) `메세지 지향 미들웨어` > 미들웨어\ > 분산 컴퓨팅 환경에서 애플리케이션 간의 통신과 데이터 관리 입력/출력 기능 등을 지원하는 소프트웨어 계층\ > 데이터 베이스 미들웨어(JDBC), 원격 프로시저 호출(RPC, JSON-RPC), 웹 미들웨어 (Apache Tomcat, Microsoft IIS), 메세지 지향 미들웨어(MOM) 등이 있음 **개념** * 어플리케이션들의 메세지를 중간에서 관리해주는 시스템 * MOM의 개념을 가진 프로토콜을 기반으로 다양한 구현체 등장 * 프로토콜 * JMS(Java Messaging System): Java지원 표준 API * AMQP(Advanced Message Queue Protocol): 미들워어 브로커 간 메세지 교환을 위한 응용계층 표준 프로토콜 * 구현체 (메세지 큐) * 메세지를 임시로 저장하는 버퍼 역할 * ActiveMQ * RabbitMQ * Apache Kafka * Amazon SQS
**특징** * 낮은 종속성과 결속성 * 클라이언트 시스템간에 메세지 통신을 중간에서 관리해줌으로써 클라이언트 시스템간의 종속성 및 결속성을 낮춰줌 * 송신자는 수신자의 주소를 몰라도 메세지를 보낼 수 있음 * 높은 안정성 * 주고 받는 메세지를 데이터베이스에 기록하여 백업 가능 * 라우팅 규칙을 활용해 하나의 메세지로도 특정 여러 클라이언트가 받을 수 있도록 지원
**단점** * 메세지 전체를 관리하는 시스템 따로 필요 * 이에따른 도입, 운영 비용의 고려 * 전체적인 시스템 구조가 복잡해질 수 있음 * 송수신자가 직접 통신하는 것이 아닌 다수의 서버가 MOM을 이용하므로 구조가 전체적으로 복잡해지고 이에 대한 오버헤드 발생 가능 \
## 메세지 브로커 (Message Broker) **개념** * 대용량 데이터 처리를 위한 미들웨어 * MQ에 라우팅, 변환, 모니터링 및 관리, 메시징 패턴 (Pub/Sub, Point-to-point) 등의 기능을 추가적으로 제공 * 메세지를 생산하는 Publisher(송신자)와 저장된 메세지를 사용하는 Subscriber/Consumer(수신자) 사이에서 메세지를 전달하는 역할 * 이를 통해 응용 소프트웨어 간에 메세지를 교환할 수 있도록 함
**특징** * Publish/Subscribe(Consumer) Pattern * 송신자가 보낸 메세지를 메세지 큐에 적재하고, 이를 수신자가 받아서 사용하는 구조 * 실시간 데이터 처리 성능이 뛰어남 * 일반적인 방법 (A서버: 데이터를 DB에 적재, B서버: DB에서 데이터 조회)에선 실시간으로 데이터가 쌓이는 테이블을 조회하기 어려움 * 메세지 브로커 사용시, B서버에서 별도의 조회과정이 필요 없이 메세지 큐에 적재되는 메세지를 감시하다가 적재되면 바로 가져다 사용 가능 * 비동기 방식 * 메세지 큐, 토픽과 같은 데이터 구조를 통해 메세지를 임시로 저장해두었다가 적절한 수신자에게 보내줌 * 비동기적으로 메세지를 처리가 가능하기 때문에 대용량 트래픽이 몰리는 경우에도 실제 처리는 일어나지 않고 메세지 큐에 적재만 해두고 Consumer가 처리 가능한 시점에 처리할 수 있기 때문에 부하가 줄 수 줄어듬 * Point to point * MSA 환경에서 메세지 큐를 활용해서 각 필요한 서비스에 메세지를 전달하고, 각 서비스는 메세지를 받아서 처리하는 방식으로 사용 \
**사용 이유** * 서비스(어플리케이션)간의 의존성 제거 * 서버 수가 유동적이여도 정상적으로 동작 * 송수신측 모두 메세지 브로커의 주소만 알고있다면 메세지를 보내고 받는데 문제 없음 * 수신 측 서버에 문제가 생겨도 정상 동작 * 메세지 큐는 메세지를 유지하고 있으므로 수신 측 서버가 문제가 정상적으로 돌아오면 유지했던 메세지 받을 수 있음 * 메세지 버퍼링 * 수신 측에서 원하는 시점에 메세지를 가져갈 수 있도록 지원 * 다양하고 유연한 통신
**장점** * 안정적인 비동기 방식으로 메세지를 교환하여 분산된 시스템/어플리케이션 간의 통신을 도움 * 생산자와 소비자간 중개자 역할을 하여 두 시스템이 완전히 독립적으로 작동할 수 있도록 도움 * 컴포넌트간 느슨한 결합을 도움
**단점** * 쿼리를 이용해 원하는 데이터만 필터링 조회 불가능 * 큐에 적재된 내용을 그대로 사용하기 때문 * 따라서 데이터 필터링을 위해 Logstash를 이용 혹은 적재시 필터링된 데이터를 적재해야 함 * 메세지 큐에 적재된 메세지는 주로 7일 보관으로 장기간 보관시 별도의 저장소 이용해야함
**구조** ![](https://blog.kakaocdn.net/dn/dQxBQa/btrXn9s2Dd8/EkMk51Cq55lPacOkVKFvTk/img.png)
* Message Queue * 메세지가 적재되는 공간 * 큐 자료 구조 형태로 메세지를 다루는 구조, 나아가 MOM의 구현체의 개념인 메세지 전송 구조를 가진 미들웨어 * Message Broker 내부에 메세지가 적재되는 공간 * Topic * 메세지들의 그룹 > Message Broker와 Message Queue의 개념은 서로 모호하게 사용하는 경우가 많다. \
## 대표적인 메세지 브로커 ### RabbitMQ `전통적인 메세지 브로커` ![](https://blog.kakaocdn.net/dn/c4Eogu/btrpqzkhgNy/Emd2u4563mtbdKwg1vFHgK/img.png)
**개념** * 메세지 브로커 방식 * 브로커 중심적인 방식으로, 지정된 수신인에게 메세지를 확인, 라우팅, 저장 및 배달하는 역할을 수행하며 보장되는 메세지 전달에 초점을 맞춤 * AMQP(Advanced Message Queuing Protocol)를 구현하는 오픈 소스 메세지 브로커 소프트웨어
**특징** * 쉽고 빠르게 작은 서비스의 메세지 브로커를 구축하기 좋으며 메세지 전달 보장이 필수적 * 단, 메세지 처리 순서와 영속성은 보장되지 않음 * 안정성으로 유명하며 금융 서비스, 전자 상거래 및 IoT 와 같은 다양한 산업에 사용
### [Apache Kafka](/cs/database/kafka.md) `이벤트 스트리밍 플랫폼` ![](https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2\&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FcT3ZHK%2FbtsjKS2wNFK%2F1fvU75fL6z9MNsjRhwrcRK%2Fimg.png)
**개념** * 이벤트 스트리밍 플랫폼 * 메세지 브로커와 이벤트 스트리밍 플랫폼 모두 이벤트를 수신하고, 이것을 소비자에게 전달하는 같은 목적을 두지만 작동방식에 차이가 있음 * 이벤트 스트리밍 플랫폼은 메세지 브로커와 다르게 topic이라는 것이 event streamer에 저장 됨 * `topic` : kafka에서 메세지를 저장하는 단위 * 분산 스트리밍 플랫폼 * 실시간 데이터 스트림의 높은 처리량, 내결함성 및 확장 가능한 메시징 및 처리를 위해 설계 됨 * 대량의 이벤트를 처리하고 대기 시간이 짧은 메시징 서비스를 제공
**특징** * 높은 처리량을 감당할 수 있으며 스케일 아웃이 중요한 경우 사용 * 영속성, 메세지 처리 순서가 보장되나 전달 보장은 필수적이지 않음 * 로그 및 이벤트의 중앙 스토리지 시스템 역할에 적합 \
### 메세지 브로커와 이벤트 브로커 * RabbitMQ, Kafka 둘 다 Pulibsh/Subscribe 기반의 메세지 큐 서비스이나 Kafka는 이벤트 브로커이고, RabbitMQ는 메세지 브로커이다. * `이벤트 브로커` * 이벤트 브로커는 메세지 브로커의 기능을 포함하는 더 큰 범위의 개념이기에 이벤트 브로커가 메세지 브로커 역할을 수행할 수도 있다. * publisher가 생산한 이벤트를 저장하고, consumer가 해당 이벤트를 사용하더라도 이벤트가 저장된다는 특징으로 이후에 다시 재사용 할 수 있는 장점을 가지고 있다. * `메세지 브로커` * 중간 다리 역할을 수행하는 broker로 publisher가 생산한 메세지를 큐에 저장하고, consumer가 데이터를 가져가면 즉시 혹은 짧은 시간 내에 큐에서 데이터를 삭제한다. \
## Ref [대용량 데이터 처리를 위한 Message Broker](https://louis-devlog.tistory.com/36)\ [Message Broker - 왜 사용하는 것일까 ?](https://binux.tistory.com/74)\ [\[Tech\] RabbitMQ와 Kafka의 차이? 메세지 브로커와 이벤트 스트리밍 플랫폼](https://programming-workspace.tistory.com/69)