알람 시스템을 만들기 어떤 시스템을 적용해야 하는지 고민하고 있어요. 분산 환경에서 알림을 보내고, 유연함을 얻기 위해 느슨한 결합을 하고 싶어 Message Queue를 공부하게 되었어요. Message Queue는 무엇인지 알아보고 언제 왜 사용하는지 알아보려 해요.
💬 Message Queue란?
Message Queue에 대해 알아보기 전에 각각의 단어 부터 알아보자면,
- Message: 둘 이상의 관계에서 주고받을 수 있는 데이터(일반적으로 binary data)
- Queue: FIFO 특성으로 순서를 보장하며 많은 요청에 대한 일종의 디펜스 매커니즘
컴퓨팅 시스템에서 Queue
Queue를 사용하는 컴퓨팅 시스템을 생각해보면, 대부분의 시스템 간 상호작용이 일어나는 곳에서는 항상 Queue를 사용해요. 만약 Queue를 사용하지 않는다고 가정해봐요. 들어오는 요청을 바로바로 처리해야 하는데, 처리를 담당하는 유한한 자원보다 더많은 요청이 들어온다면, 요청을 처리하지 못하고 버리게 되는 것이죠.
그래서 위에서 Queue는 많은 요청에 대한 일종의 디펜스 매커니즘이라고 정리했어요.
Message Queue
Message Queue는 어플리케이션 간 데이터를 교환할때 사용하는 통신 방법이에요. Message Queue로 메시지를 전송하는 Producer와 Message Queue에서 Message를 받아 처리하는 Consumer가 존재해요. 대부분 시스템에서의 큐들은 시스템이 다운되면 가지고 있는 정보를 잃어버리지만, Message Queue는 큐에 저장되는 메세지를 잃어버리지 않는다는 특징이 있어 안정성이 매우 뛰어난 시스템이에요.
Message Queue는 소비를 위한 Message의 수용, 저장, 생성을 포함한 생명 주기를 관리하기 때문에 안정성을 보장하고 있어요.
⚙️ Message Queue의 구조와 동작 원리
Message Queue 구조
기본적으로 Message Queue는 Producer가 Message를 Message Queue에 넣고 Consumer는 Message를 소비하는 간단한 구조에요.
Message Queue는 소비를 위한 Message의 수용, 저장, 생성을 포함한 생명 주기를 관리하기 때문에 안정성을 보장하고 있어요. 그렇다면 어떻게 생명 주기를 관리할까요?
Message Queue는 메시지를 처리하지 않고 Consumer의 처리가 완료될 때 까지 보존해요. Consumer는Message를 처리한 후 accept를 보내줘요. 만약 지정된 처리 시간(TTL)을 경과하거나 명시적으로 rejected를 Message Queue에 응답할 경우, 해당 Message는 Message Queue 내부에 따로 존재하는 Dead-letter-Queue에 저장되어 이후 처리까지 보관될 거에요.
(모든 Queue 및 topic 구독에는 자체 dead-letter-subqueue이 있어요)
⠿ Message 전달 패턴
메시지 전달 패턴은 메시지 큐에서 메시지가 소비자에게 전달되는 방식을 나타내요. 가장 일반적인 패턴은 두 가지 있어요.
Point-to-Point (P2P)
P2P 패턴은 특정 메시지가 특정 소비자에게 직접 전달되는 방식으로 메시지는 큐에 쌓이고, 각각의 메시지는 오직 하나의 소비자에게만 전달하는 방식이에요.
- 동작 원리
- 프로듀서(Producer)는 메시지를 큐에 전송합니다.
- 큐(Queue)에는 메시지들이 저장되며, 각 메시지는 고유한 식별자를 가지고 있습니다.
- 컨슈머(Consumer)는 큐에서 메시지를 가져와 처리합니다. 한 번에 하나의 메시지만 처리하게 됩니다.
- 메시지는 한 번 소비되면 다른 컨슈머에게 전달되지 않습니다.
- 활용 사례
- 주문 처리 시스템: 각 주문은 한 번에 하나의 주문 서비스에 의해 처리됩니다.
- 작업 큐: 특정 작업을 한 번에 하나의 작업자가 처리합니다.
Publish-Subscribe (Pub/Sub)
Pub/Sub 패턴은 메시지를 특정 소비자에게 직접 전달하는 것이 아니라, 특정 주제에 관심 있는 모든 소비자에게 메시지를 전송하는 방식이에요.
동작 원리
- 발행자(Publisher)
- 메시지를 특정 주제에 발행합니다.
- 발행된 메시지는 큐에 저장되지 않고, 주제에 관심 있는 모든 구독자에게 직접 전달됩니다.
- 주제(Topic)
- 메시지는 주제에 속하며, 구독자들은 특정 주제에 대한 구독을 등록합니다.
- 구독자(Subscriber)
- 특정 주제에 대해 구독을 등록하면, 해당 주제에 새로운 메시지가 발행될 때마다 해당 구독자에게 전달됩니다.
- 여러 구독자가 하나의 주제에 동시에 구독할 수 있습니다.
활용 사례
- 이벤트 기반 아키텍처: 분산 시스템에서 각 구성 요소 간의 통신을 효율적으로 관리하는 데 사용됩니다.
✨ Message Queue Benefit
- 통신의 자유로움: 메시지 큐를 통해 다른 언어나 플랫폼 간에 데이터를 전달할 수 있어 제약 없는 통신이 가능하다.
- 비동기성의 성능 향상: 동기 통신 대비 비동기 통신은 성능을 높일 수 있어, 작업을 기다리지 않고 절차를 수행할 수 있다.
- 고가용성 (HA): 일부 메시징 시스템이 다운되어도 시스템은 성능 저하가 있을 수 있지만 정상적인 동작은 보장된다.
- 작업 재시도의 용이성: worker가 다운되어도 메시지는 큐에 남아 있어, worker가 다시 가동되면 이전에 실패한 작업을 이어서 처리할 수 있다. 이로써 데이터 정합성은 유지되며, 실시간성이 떨어져도 안정성을 유지한다.
- 느슨한 결합으로 인한 유연성과 확장성: pub은 메시징 발행에만 관심을 가지고, sub은 메시지 처리에만 관심을 가지므로 느슨한 결합을 통해 시스템이 유연하게 확장 가능하다.
마무리
첫번째 참고자료의 마지막에 이러한 문구가 있어요.
Event Streaming is not “mordern” and Queues are not “traditional”
저는 이렇게 정리했어요.
기술이라는 것은 단지 문제를 해결하기 위해 사용할 수단이다.
글의 맥락 상 작성하지 않았지만 공부 했던 좋은 주제도 있어요.
- Differences between a message queue and an event stream
다음 블로그에는 Message Queue로 사용 되고 있는 기술들을 비교해보며 제 프로젝트에 맞는 기술을 채택하는 과정을 작성할게요.
감사합니다.
참고자료
What is a Message Queue and when and why would I use it
https://www.youtube.com/watch?v=TdgXzpjMPQU
https://www.youtube.com/watch?v=oUJbuFMyBDk
What is a message queue?
