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 와 같은 다양한 산업에 사용

Apache Kafka

이벤트 스트리밍 플랫폼

개념

• 이벤트 스트리밍 플랫폼

  • 메세지 브로커와 이벤트 스트리밍 플랫폼 모두 이벤트를 수신하고, 이것을 소비자에게 전달하는 같은 목적을 두지만 작동방식에 차이가 있음

  • 이벤트 스트리밍 플랫폼은 메세지 브로커와 다르게 topic이라는 것이 event streamer에 저장 됨

    • topic : kafka에서 메세지를 저장하는 단위

• 분산 스트리밍 플랫폼

  • 실시간 데이터 스트림의 높은 처리량, 내결함성 및 확장 가능한 메시징 및 처리를 위해 설계 됨

• 대량의 이벤트를 처리하고 대기 시간이 짧은 메시징 서비스를 제공

특징

• 높은 처리량을 감당할 수 있으며 스케일 아웃이 중요한 경우 사용

• 영속성, 메세지 처리 순서가 보장되나 전달 보장은 필수적이지 않음

• 로그 및 이벤트의 중앙 스토리지 시스템 역할에 적합

메세지 브로커와 이벤트 브로커

• RabbitMQ, Kafka 둘 다 Pulibsh/Subscribe 기반의 메세지 큐 서비스이나 Kafka는 이벤트 브로커이고, RabbitMQ는 메세지 브로커이다.

• 이벤트 브로커

  • 이벤트 브로커는 메세지 브로커의 기능을 포함하는 더 큰 범위의 개념이기에 이벤트 브로커가 메세지 브로커 역할을 수행할 수도 있다.

  • publisher가 생산한 이벤트를 저장하고, consumer가 해당 이벤트를 사용하더라도 이벤트가 저장된다는 특징으로 이후에 다시 재사용 할 수 있는 장점을 가지고 있다.

• 메세지 브로커

  • 중간 다리 역할을 수행하는 broker로 publisher가 생산한 메세지를 큐에 저장하고, consumer가 데이터를 가져가면 즉시 혹은 짧은 시간 내에 큐에서 데이터를 삭제한다.

Ref

대용량 데이터 처리를 위한 Message Broker Message Broker - 왜 사용하는 것일까 ? [Tech] RabbitMQ와 Kafka의 차이? 메세지 브로커와 이벤트 스트리밍 플랫폼