Spring boot 채팅 구현 #3 AMQP 개념 정리

 

 

이 포스팅을 작성하기 위해, RabbitMQ 공식 사이트를 참조하였습니다.

 

https://www.rabbitmq.com/tutorials/amqp-concepts.html

AMQP 0-9-1 Model Explained — RabbitMQ

 

 

AMQP

 

AMQP, Advanced Message Queuing Protocol은

 

클라이언트와 메세지 미들웨어 브로커 사이에서의 인터페이스를 정의한 메세지 프로토콜이라고 할 수 있습니다.

 

가장 기본적인 원리는,

 

Message Broker가 Producer로부터 메세지를 받아서, Consumer에게 라우팅하는 것입니다.

 

더 구체적인 과정은 아래 그림을 보면서 이해해보겠습니다.

 

 

 

"Hello, world" 라는 메세지를 전달하고 싶다고 해보겠습니다.

 

1. Publisher(=Producer) 가 해당 메세지를 Exchange로 Publish합니다.

 

2. Exchange는 메세지를 카피해서 Queue에게 전달합니다.

 

3. Queue를 구독하고 있는 Consumer는 해당 메세지를 전달 받습니다. 또는 해당 메세지를 fetch/pull도 가능합니다.

 

 

그럼 여기서 등장하는 Exchange, Queue는 무엇일까요?

 

간단하게 설명하자면, Exchange는 우편함과 같은 것이고,

 

Queue는 Exchange로부터 메세지를 받아서 Consumer로부터 소비되는 저장소라고 보면 되겠습니다.

 

좀 더 구체적으로 알아보겠습니다.

 

 

Exchange

 

Exchange는 메세지를 받아서 0개~N개의 큐로 메세지를 라우팅합니다.

 

그리고 라우팅 알고리즘은 Exchange Type과 Binding을 기반으로 이루어집니다.

 

 

 

Exchange Type

 

Exchange Type은 총 4가지가 있습니다.

 

 

Direct Exchange

 

* Default Exchange

 

라우팅 키를 아무것도 지정하지 않았을 경우(Empty String), 디폴트로 Direct Exchange가 됩니다.

 

그리고 우리가 선언한 queue의 이름과 같이 라우팅 키는 바인딩됩니다.

 

 

 

Direct Exchange는 위의 그림과 같습니다.

 

라우팅 키를 기반으로 큐에 메세지가 전달되며, 유니캐스트에 적합하고 멀티캐스트에도 사용 가능합니다.

 

*유니캐스트: 네트워크의 한 지점에서 다른 지점으로의 일대일 전송 방식

 

*멀티캐스트:  데이터 전송이 대상 컴퓨터 그룹으로 동시에 전달되는 그룹 통신

 

 

작동 과정

 

1. 큐가 라우팅 키를 가지고 Exchange에 바인딩

 

2. 메세지가 라우팅 키를 가지고 Exchange로 전송

 

3. Exchange는 라우팅 키가 일치하는 큐를 찾고 메세지를 큐로 전달

 

이때, 라우팅 키가 일치하는 모든 큐에 전송되므로, 멀티캐스트가 가능하다는 것입니다.

 

 

Fanout Exchange

 

Fanout Exchange는 라우팅 키를 무시하고, Exchange에 바운딩된 모든 큐로 메세지를 전송하는 방식입니다.

 

브로드캐스트에 적합합니다.

 

*브로드캐스트: 메시지를 모든 수신자에게 동시에 전송하는 방식

 

 

 

 

Topic Exchange

 

Topic Exchange는 라우팅 키와 패턴을 기반으로 하나, 또는 다수의 큐로 라우팅됩니다.

 

멀티캐스트에 적합합니다.

 

Topic Exchange의 라우팅 룰은 다음의 그림을 보면서 이해해보겠습니다.

 

 

 

 

패턴은 두 가지가 존재합니다.

 

* : 한 단어를 대체한다는 의미입니다.

 

# : 0개 이상의 단어를 대체한다는 의미입니다.

 

그리고 각각은 . 으로 구분합니다.

 

위의 그림을 보면,

 

Q1은 *.orange.* 의 라우팅 키로 바인딩되어 있습니다.

 

Q2는 *.*.rabbit 과 lazy.# 의 두 가지의 라우팅 키로 바인딩되어 있습니다.

 

자 이제, 예시를 들겠습니다.

 

메세지는 세 단어(두 개의 .)으로 구성된 라우팅 키와 함께 전송된다고 가정하겠습니다.

 

 

Example

 

quick.orange.rabbit => 두 큐에 모두 전달

 

lazy.orange.elephant => 두 큐에 모두 전달

 

quick.orange.fox => Q1에만 전달

 

lazy.brown.fox => Q2에만 전달

 

lazy.pink.rabbit => Q2의 두 개의 라우팅 키에 일치하지만, 한 번만 전달

 

quick.brown.fox => 어디에도 바인딩되지 않으므로 폐기

 

quick.orange.new.rabbit => 바인딩되지 않으므로 폐기

 

lazy.orange.new.rabbit => 단어가 4개이지만 Q2의 lazy.#와 바인딩되므로 전달

 

 

 

처음에는 이해가 잘 안 되실 수도 있지만, 예시를 보시면 이해하실 수 있을 것입니다.

 

이 때, 라우팅 키에 #만 바인딩한다면, 모든 라우팅 키를 수신한다는 의미가 되므로,

 

Fanout Exchange와 동일하게 됩니다.

 

 

Headers Exchange

 

Headers Exchange는 라우팅 키를 무시합니다. 대신에 Headers의 속성을 통해서 라우팅하는 방식입니다.

 

즉, Header의 key, value가 바인딩된 큐의 key, value와 일치하면 라우팅됩니다.

 

이때 x-match라는 규칙이 존재합니다.

 

x-match="all" 일 경우, 헤더의 key, value와 모두 바인딩되어야지 라우팅됩니다.

 

x-match="any" 일 경우, 헤더의 key, value와 하나라도 바인딩되면 라우팅됩니다.

 

 

---

 

여기까지 오셨다면, 이런 의문이 들 수도 있습니다.

 

그렇다면 큐에 저장된 메세지는 언제 소멸될까요?

 

Consumer에게 메세지를 전달하였을 때?

 

하지만, 네트워크 통신의 문제로 인해, 메세지가 항상 전달된다는 보장을 할 수 없습니다.

 

그래서 Message Acknowledgements가 존재합니다.

 

 

Message Acknowledgements

 

두 가지 모드가 존재합니다.

 

 

1. 브로커가 애플리케이션에게 메세지를 전달한 시점

 

하지만, 이 방식은 네트워크 통신의 문제가 발생하며 메세지가 소실될 수 있다는 문제가 있습니다.

 

 

2. 애플리케이션이 Acknowledgement를 send back한 시점

 

- 애플리케이션이 메세지를 전달받은 시점

 

- 데이터 저장소에 영구화한 시점

 

- 모든 데이터 랜더링 프로세스가 끝난 시점(예. 웹페이지를 성공적으로 fetching한 경우)

 

위와 같은 케이스에 맞춰서 애플리케이션이 Acknowledgement를 send back하면,

 

브로커는 큐에 저장된 메세지를 완전히 소멸하게 됩니다.

 

 

---

 

 

AMQP 프로토콜을 사용하기 위한 필수적인 개념은 여기까지이며,

 

더 깊은 이해를 위해서는 메세지 브로커 SW에 맞게 공부하면 될 것으로 보입니다.