Message Queue 자세히 알아보기 (vs REST API, Lambda)
💡 참고 자료
What Is a Message Broker? | IBM
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 하는 역할을 수행하는 것의 기능이 부족합니다.