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일 보관으로 장기간 보관시 별도의 저장소 이용해야함
구조
Message Queue
메세지가 적재되는 공간
큐 자료 구조 형태로 메세지를 다루는 구조, 나아가 MOM의 구현체의 개념인 메세지 전송 구조를 가진 미들웨어
Message Broker 내부에 메세지가 적재되는 공간
Topic
메세지들의 그룹
Message Broker와 Message Queue의 개념은 서로 모호하게 사용하는 경우가 많다.
대표적인 메세지 브로커
RabbitMQ
전통적인 메세지 브로커
개념
메세지 브로커 방식
브로커 중심적인 방식으로, 지정된 수신인에게 메세지를 확인, 라우팅, 저장 및 배달하는 역할을 수행하며 보장되는 메세지 전달에 초점을 맞춤
AMQP(Advanced Message Queuing Protocol)를 구현하는 오픈 소스 메세지 브로커 소프트웨어
특징
쉽고 빠르게 작은 서비스의 메세지 브로커를 구축하기 좋으며 메세지 전달 보장이 필수적
단, 메세지 처리 순서와 영속성은 보장되지 않음
안정성으로 유명하며 금융 서비스, 전자 상거래 및 IoT 와 같은 다양한 산업에 사용
이벤트 스트리밍 플랫폼
개념
이벤트 스트리밍 플랫폼
메세지 브로커와 이벤트 스트리밍 플랫폼 모두 이벤트를 수신하고, 이것을 소비자에게 전달하는 같은 목적을 두지만 작동방식에 차이가 있음
이벤트 스트리밍 플랫폼은 메세지 브로커와 다르게 topic이라는 것이 event streamer에 저장 됨
topic: kafka에서 메세지를 저장하는 단위
분산 스트리밍 플랫폼
실시간 데이터 스트림의 높은 처리량, 내결함성 및 확장 가능한 메시징 및 처리를 위해 설계 됨
대량의 이벤트를 처리하고 대기 시간이 짧은 메시징 서비스를 제공
특징
높은 처리량을 감당할 수 있으며 스케일 아웃이 중요한 경우 사용
영속성, 메세지 처리 순서가 보장되나 전달 보장은 필수적이지 않음
로그 및 이벤트의 중앙 스토리지 시스템 역할에 적합
메세지 브로커와 이벤트 브로커
RabbitMQ, Kafka 둘 다 Pulibsh/Subscribe 기반의 메세지 큐 서비스이나 Kafka는 이벤트 브로커이고, RabbitMQ는 메세지 브로커이다.
이벤트 브로커이벤트 브로커는 메세지 브로커의 기능을 포함하는 더 큰 범위의 개념이기에 이벤트 브로커가 메세지 브로커 역할을 수행할 수도 있다.
publisher가 생산한 이벤트를 저장하고, consumer가 해당 이벤트를 사용하더라도 이벤트가 저장된다는 특징으로 이후에 다시 재사용 할 수 있는 장점을 가지고 있다.
메세지 브로커중간 다리 역할을 수행하는 broker로 publisher가 생산한 메세지를 큐에 저장하고, consumer가 데이터를 가져가면 즉시 혹은 짧은 시간 내에 큐에서 데이터를 삭제한다.
Ref
대용량 데이터 처리를 위한 Message Broker Message Broker - 왜 사용하는 것일까 ? [Tech] RabbitMQ와 Kafka의 차이? 메세지 브로커와 이벤트 스트리밍 플랫폼
Last updated
