회사에서 사용했던 RabbitMQ와 MessageBroker에 대해서 간단하게 정리하고 사용하면서 장점이라고 생각됐던 부분에 대해서 정리하려고 한다.
MOM ???
message broker라고 검색하면 항상 같이 따라오는 내용이다.
이름 그대로 애플리케이션의 메시지를 중앙에서 관리해주는 소프트웨어나 하드웨어를 뜻한다.
애플리케이션끼리 직접 통신하지 않고 중앙 메시지 관리 시스템을 통하여 메시지를 주고 받으며 통신한다.
직접적인 구현체는 아니고 설계 패러다임? 이라고 생각하면 될듯 하다.
장점
- 비동기성
애플리케이션끼리 직접 통신하지 않기 때문에 A애플리케이션이 보낸 메시지는 MOM 메시지 큐에 쌓여 다른 애플리케이션의 영향을 받지 않아 비동기적으로 작업 수행이 가능하다. - 애플리케이션 의존성 제거
분산 시스템에서 다양한 애플리케이션이 존재하더라도 MOM을 통해서 통신하기 때문에 시스템간의 종속성이 줄어든다. - 라우팅
라우팅 규칙에 따라 멀티캐스트나 브로드 캐스팅은 지원한다.
Message Broker는 뭐고 Mesagge Queue는 뭐야??
RabbitMQ는 MQ가 들어갔으니 MessageQueue인가? Message Broker인가???
-
MessageQueue
Queue자료구조 사용하여 메시지를 보내기/받기 그리고 저장을 지원하는
프로세스 간 단순한 통신 솔루션으로 MOM 시스템의 일부이다. -
MessageBroker
메시지 브로커는 단순한 프로세스 간 통신을 지원하는 메시지 큐보다 더 확장되어 고급 라우팅 기능, 로드 밸런싱, 메시지 변환 기능, 메시지 형식 변환등 추가되어 메시지 큐를 관리하고 저정하는 시스템이라고 말해도 될듯 하다. (MOM의 구현체가 MessageBroker라고 생각하면 될듯하다.)
Publish-subscribe pattern
Message Broker는 대부분 Pub/Sub패턴을 사용한다.
- Publish
메시지를 발행하는 송신자 애플리케이션 - Subscribe
발행된 메시지를 받아서 작업을 수행하는 수신자 애플리케이션
뭔가 거창해 보이지만 메시지를 발행하여 보내는 송신자와 메시지를 수신하여 어떠한 작업을 수행하는 수신자로 나눠저 있는 패턴이다.
RabbitMQ
인기 있는 Message Broker중 하나이다.
RabbitMQ는 단순한 애플리케이션 부터 대규모 시스템까지 다양한 분산 소프트웨어 아키텍처를 만들기 위한 매우 강력하고 가벼운 도구이다.
기본적인 RabbitMQ의 기본 구성요소는 아래와 같다.
- Exchange: 송신자에게서 전달받은 메시지를 큐로 라우팅하는 컴포넌트 이다. 사용되는 라우팅 알고리즘은 Exchange Type과 Binding규칙에 따라 달라진다.
Exchange Type은 Direct, Fanout, Topic, Headers이 있다. - Binding: Binding은 메시지를 어떤 MessageQueue로 라우팅하는지 확인하는 규칙이다.
- Queue: Queue는 메시지가 최종적으로 전달되어 소비자에 의해 처리되기를 기다리는 장소이다. 큐는 메시지의 순서를 유지하며, 소비자가 메시지를 처리할 준비가 되었을 때까지 메시지를 저장한다.
- Message: 메시지는 데이터를 나타내는 항목으로, 메시지 큐를 통해 전달된다. 각 메시지는 일반적으로 페이로드와 함께 메타데이터(ex: 라우팅 키)를 포함한다.
ExchangeType에 대해서 추가 정리하자면
총 4가지가 있다.
- Direct: 특정 라우팅 키를 가진 메시지를 같은 라우팅 키를 가진 큐로 직접 전달한다.
- Fanout: Exchange에 도착한 메시지를 바인딩된 모든 큐에 복사하여 전달한다. 라우팅 키는 무시된다.
- Topic: 라우팅 키 패턴(와일드카드 포함)을 사용하여 메시지를 라우팅한다.
- Headers: 메시지 헤더에 기반한 복잡한 라우팅 규칙을 사용합니다. 라우팅 키는 사용되지 않습니다.
자세한 내용은 링크에!
AMQP
RabbitMQ의 장점은 대부분 AMQP스펙에서 비롯된다.
따로 정리하는게 좋을듯 하기도 하고 지식이 부족하여 나중에 추가 정리하도록 하겠습니다...
메시지 전달 보증
At most once - 도달 여부 상관없이 딱 한번만 던진다.
At leat once - 메시지가 최소 한번 전달된다. 네트워크 실패 등의 이유로 전달이 확인되지 않을 경우 재 전송된다.
(RabbitMQ의 전달 보증은 MQTT의 Qos와는 조금 다르다고 알고있다. 잘 정리된 자료를 확인했었는데 찾으면 링크를 추가하겠습니다.)
그외 다양한 기능들
- RabbitMQ는 기본적으로 metric/monitoring를 확인할 수 있는 UI플러그인을 제공한다.
- 다양한 서드파티 플러그인
RabbitMQ를 사용해 메시지를 데이터베이스에 직접 저장하는 서드파티 플러그인 등 다양한 서드파티 플러그인을 제공한다.
그래서 Message Broker 왜 써야하고 장점은 뭐야?
개인적인 사용 경험으로는 비동기처리 & 애플리케이션 간의 의존성 제거가 가장 큰 장점이라고 생각하고 도입했던 이유다.
비동기 처리 관점에서 Publisher는 메시지를 브로커에 던지고 Subscriber이 작업을 하든 말든 다시 본인의 일을 하면 된다.
만약 동기처리였다면 Publisher는 Subscriber이 작업을 처리할때까지 기다려야 했을것이다. 만약 Subscriber가 작업을 제대로 수행하지 못해 Publisher가 계속 기다려야 하는 상황이 온다면 병목현상이 일어나게 될것이다.
의존성 제거 관점에서 위와 비슷하다. Publisher는 Subscriber가 누군지, 살아있는지, 죽어있는지 아무런 관심이 없다.
마치며
간단하게 MessageBroker에 대해서 정리해봤습니다.
MessageBroker가 이러한 기술의 한계때문에 생기지 않았을까?? 라는 내용도 같이 정리하고 싶었지만 사실 잘 모르겠음...
참고한 내용
