💡 참고 자료
What Is a Message Broker? | IBM
Message Broker - 왜 사용하는 것일까 ?
Pub/Sub vs. PTP: Understanding Messaging Patterns in Event-Driven Architecture - CODE REVIEW
이번 주차에는, RabbitMQ에 대한 세부적인 특징들을 알아보려고 하였으나, 세부 특징을 아는 것 보다 Message Queue의 아키텍쳐를 이해하고, 각 구성 요소들이 어떤 역할을 하는지 먼저 알아보고 RabbitMQ 세부 특징으로 진행하겠습니다.
Message Queue 의 아키텍쳐 개념인 MOM부터 시작하여, Message Broker가 뭐고, Messaging Pattern에 대해 알아보면서 추후 심화될 개념을 이해해 봅시다.
✏️ Message Oriented Middleware (MOM)
메시지 큐의 이론과 개념, 아키텍쳐 그 자체를 의미합니다. 그러니까, 메시지를 전달하고 수집하는 미들웨어의 개념이라고 이름 그대로 받아들이면 될 것 같습니다.
MOM이 ‘구현체’가 아니라 개념이라는 사실에 집중해주세요
장점
지난시간에 스터디했듯, High Availability, Asynchronous한 요청 처리로 유연하게 시스템 구성 요소를 확장할 수 있게 도와주는 친구가 MOM 개념 덕분입니다.
단점
- 관리 비용의 증가
하지만 MOM의 단점은, 메시지 전체를 관리하는 구현체(RabbitMQ..) 를 결국 관리해야 한다는 점입니다. 이에 따라, 시스템 관리 비용이 늘어날 수 밖에 없습니다. - SPOF(Single Point Of Failure)
Message Queue가 죽어버리면 이를 사용하는 서비스는 장애가 발생합니다. 하지만 MOM을 통해 구현한 여러 Message Queue 소프트웨어들은 High Availability를 고려하여 만들어져서 이러한 확률이 거의 없다고는 합니다.
✏️ Message Broker
MOM 아키텍쳐만으로는 Message Queue의 역할을 충분히 해낼 수 없습니다. Message Broker가 MOM에서 동작하면서 진정한 Message Queue의 역할을 수행할 수 있을 만큼 Message Broker의 역할은 매우 중요합니다.
Message Broker는 다음과 같은 역할을 Rough하게 수행합니다.
- Validation
- Store
- Route
- Deliver
Message Broker가 있기 때문에, Asynchronous하게 요청을 처리할 수 있는 것이고, Queue의 Message들을 저장하고, 지정된 경로로 전달하면서 MQ의 완연한 역할을 수행합니다.
Message Broker Models
Message Broker의 Model은 두가지가 있습니다. 보통 이를 Messaging Pattern이라고 부르기도 합니다.
- Publish / Subscribe (이하 pub/sub)
- Point To Point (이하 PTP)
(1) pub/sub
pub/sub 은 Topic 을 이용합니다. pub/sub 모델의 flow는 다음과 같습니다.
- 메시지를 만들어내는 Producer가 message를
publish합니다. - publish한 message를 Topic에게 전달합니다.
- 메시지를 가져오는 Consumer들이 가져가고 싶은 message의 Topic을
subscribe합니다. (이 때, 다수의 Consumer들이 하나의 Message를 subscribe한다는 점을 집중합시다)
이를 통해 Single Message를 Multiple Consumer들에게 전달할 수 있습니다. (1:n) (m:n)
그렇다면 하나의 Message가 여러 consumer에게 전달되면서, 다양한 비즈니스 로직을 전개할 수 있을 것입니다.
(2) PTP
PTP는 하나의 Consumer에게만 message를 전달합니다. (1:1)
그렇다면 어떠한 Message Broker를 선택해야할까?
- 결제, 정산 시스템의 경우에는 어떠한 Message Broker를?
PTP입니다. 반드시 하나의 Consumer에 의해 처리되어야 하는 로직입니다. 결제 정산만큼 Atomic이 중요한 로직이 없으므로, 하나의 Consumer에게 의해 메시지가 소비되면서 트랜잭션이 유지되어야 합니다.
✏️ MessageQueue를 대체할 수 있는 다른 소프트웨어는 없을까?
REST APIs 의 한계
REST API를 활용하기엔 Synchronous 문제가 생길 수 있습니다.
저번에 Nest.js에서 async await 비동기 처리를 해주므로, “Message Queue가 Asynchronous한 요청을 처리할 수 있기 때문에 사용하는 것만은 아니다.” 라는 이야기가 나왔는데, 반은 맞고 반은 틀리다고 생각합니다.
자바스크립트 동작 원리: Event loop와 Job Queue
JS진영의 async await 비동기 처리 방식이, Message Queue의 Aynchronous 처리를 대신할 순 있어도, 엄연히 시스템의 부하를 일으킵니다. 정확히 말하면, await의 비동기 처리 함수의 Request가 서버로부터 Response되지 않으면, 계속해서 Job Queue에 해당 함수의 태스크가 끝없이 적재가 될것이고, 한계가 넘어가면 시스템에 장애가 생길 수 있습니다.
정리하면, 어쨌든! REST API 방식으로 하는 것은 Synchronous한 요청을 처리하는 것이 목적이기 때문에, Message Queue를 대체할 수 없습니다.
Event Streaming Platform (AWS Lambda)
다른 대체할만한 후보로 Lambda와 같은 이벤트 기반의 서버입니다. 충분히 Event Streaming Platform을 사용하여 pub/sub 의 역할을 비슷하게 수행하며, scalable하게 메시지를 처리할 수 있습니다. 또한, request stream들의 순서 또한 관리가 가능하고, 특정 시간동안 메시지를 저장할 수 있기도 합니다.
하지만, 문제가 되는 부분은 메시지의 전달을 완벽히 보장할 수 없습니다. 철저히 ‘이벤트 trigger’ 기반으로 해당 서버가 실행됩니다. 따라서, 메시지가 제대로 처리 되지 않았을 경우에, resend 하는 역할을 수행하는 것의 기능이 부족합니다.
