0. 이 글을 쓰는 이유
AMQP에 대해 잘 몰라서 RabbitMQ의 AMQP0-9-1 문서를 보며 개념을 알아가기 위함
https://www.rabbitmq.com/tutorials/amqp-concepts.html
AMQP 0-9-1 Model Explained — RabbitMQ
AMQP 0-9-1 Model Explained This guide provides an overview of the AMQP 0-9-1 protocol, one of the protocols supported by RabbitMQ. AMQP 0-9-1 (Advanced Message Queuing Protocol) is a messaging protocol that enables conforming client applications to communi
www.rabbitmq.com
https://www.rabbitmq.com/protocols.html
Which protocols does RabbitMQ support? — RabbitMQ
Which protocols does RabbitMQ support? RabbitMQ supports several messaging protocols, directly and through the use of plugins. This page describes the supported protocols and helps differentiate between them. RabbitMQ was originally developed to support AM
www.rabbitmq.com
https://www.rabbitmq.com/confirms.html
Consumer Acknowledgements and Publisher Confirms — RabbitMQ
Consumer Acknowledgements and Publisher Confirms This guide covers two related features related to data safety, consumer Acknowledgements and publisher confirms: and more. Acknowledgements on both consumer and publisher side are important for data safety i
www.rabbitmq.com
https://aws.amazon.com/ko/what-is/dead-letter-queue/
DLQ(Dead Letter Queue)란 무엇인가요? - DLQ(Dead Letter Queue) 설명 - AWS
DLQ(Dead Letter Queue)는 소프트웨어 시스템에서 오류로 인해 처리할 수 없는 메시지를 임시로 저장하는 특수한 유형의 메시지 대기열입니다. 메시지 대기열은 분산 시스템에서 비동기 통신을 지원
aws.amazon.com
1. AMQP란
Advanced Message Queuing Protocol의 약자로 Message Queue의 프로토콜이라고 생각하면 편할 것 같다. 대표적으로 RabbitMQ와 Kafka가 존재한다.
2. Broker
Message Broker는 publisher(pub으로도 줄여서 말하며 producer, 공급자도 같은 의미다)로부터 메시지를 전달받고 consumer(sub, subscriber, 구독자)에게 routing(전달)한다. 즉 Publisher와 Consumer의 중간 역할이다.
각각은 network protocol이기 때문에 서로 다른 시스템에 존재할 수 있다.
3. AMQP 0-9-1 모델 요약
AMQP 0-9-1 모델은 다음과 같은 세계관을 가진다.
- Message는 우체국이나 우편함에 비유되는 Exchange에 게시된다.
- Exchange는 Binding이라는 규칙을 사용해 복제된 Message를 Queue(대기열)에 집어넣는다.
- Broker는 Message를 Queue(대기열)을 Subscribe(구독한) Consumer에게 전달하거나 직접 대기열(Queue)에서 message를 fetch/pull한다.
이 그림에서 가운데 흰 박스가 Broker이며 참고한 문서 기준 RabbitMQ다.
Message를 Publish할 때 Publisher(pub, producer, 공급자)는 message의 속성(META-DATA)을 정의해야 한다. 이 meta-data중 일부는 broker가 사용할 수 있지만 나머지는 broker에게 불투명하며(비공개로) message를 수신하는(subscriber) application에서만 사용할 수 있다.
네트워크는 불안정하고 어플리케이션이 메시지를 처리하는데 실패할 수 있어서 AMQP 0-9-1모델에는 Message Acknowlegements(메시지 승인)이라는 개념이 있다.
메시지 승인(Message Acknowledgements)
Message가 Consumer(소비자)에게 전달되었을 때 Consumer(소비자)는 자동/수동(Application 개발자가 Message를 선택하면)으로 Broker에게 전달받은 사실을 알린다. 일반적으로 AMQP에서는 Message를 Consumer(subscriber)에게 전달하면 그 즉시 Message에 대해 삭제를 표시한다.
Message Acknowledgements기능을 사용 중인 경우 Broker는 해당 Message(혹은 Message Group)에 대한 알림을 수신할 때만 Queue에서 Message를 완전히 제거한다.
Message를 라우팅 할 수 없는 특정 상황에서는 Message가 Publisher(pub, Producer, 공급자)에게 반송되거나 삭제되거나 Broker가 확장 기능을 구현하는 경우 소위 ‘Dead Letter Queue’라는 공간에 배치된다.
결국 Dead Letter Queue는 소프트웨어 시스템에서 오류로 인해 처리할 수 없는 메시지를 임시로 저장하는 메시지 대기열이다.
Publisher(pub, Producer, 공급자)는 특정 파라미터들을 사용하여 Message를 publish함으로써 이러한 상황을 다루게 된다.
Queue, exchange, binding을 통틀어 AMQP 엔티티라고 한다.
