Skip to content

[RabbitMQ] AMQP 0-9-1 Model

2012/04/28
tags: ,

RabbitMQ는 AMQP 0-9-1 Model을 베이스로 만들어 졌으며 이에 AMQP 0-9-1에 대해 알아 보겠습니다.

What is AMQP?

AMQP(Advanced Message Queuing Protocol)는 클라이언트 어플리케이션이 메세지 미들웨어 브로커와 메시지를 주고 받을 수 있는 네트워크 프로토콜입니다.

Brokers and Their Role

메시지 브로커는 producers로 부터 메시지를 받아 consumers에게 라우트 해주는 역할을 합니다.

AMQP 0-9-1 Model in Brief

메세지는 producers로 부터 발행이 되어 exchanges(우체통이나 우체국에 해당함)에게 보내지게 됩니다. Exchanges는 메시지를 bindings이라 불리는 룰에 의해 큐에 분배합니다. 그리고 AMQP 브로커가 큐를 구독하는 consumers에게 메시지를 전달하거나, 브로커의 요청에 의해 consumers가 큐로부터 메시지를 가져갑니다.

Publish path from publisher to consumer via                              exchange and queue

메시지를 발행할때, producers는 다양한 메세지 속성을 정의할 수 있습니다. 이중 일부 메타데이터는 브로커에서 사용되며, 나머지는 메시지를 받는 어플리케이션에서 사용됩니다.

네트워크는 불안정하고 어플리케이션 또한 메시지 처리에 실패할수 있기 때문에 AMQP 모델에서는 메시지 acknowledgements 라는 개념이 있습니다. 이는 메시지가 consumer에게 전달되었을때 브로커에게 자동으로 수신 노티를 보내거나, 어플리케이션 개발자가 정의한 순간에 노티를 보내는 것입니다. 그리고 브로커는 메시지에 대한 노티 받은 후에만 큐에서 메시지를 완전히 삭제하게 됩니다.

또한 어떤 특정 상황에 의해 메시지가 라우트 될 수 없다면, 메시지는 producers에 리턴되거나 또는 버려지거나, “dead letter queue(배달 못한 메시지를 저장하는 큐)” 에 들어가게 됩니다. 이를 위해 producers가 메시지를 발행할때 특정 파라미터를 이용해서 브로커가 어떻게 처리해야 할지를 정의해 줍니다.

Exchanges and Exchange Types

exchanges는 메시지가 보내지는 AMQP 객체 입니다. exchanges는 메시지를 받아 큐들에게 라우트 합니다. 라우트 알고리즘은 exchange type에 의해 결정되며 bindings라고도 부릅니다.

Name Default pre-declared names
Direct exchange (Empty string) and amq.direct
Fanout exchange amq.fanout
Topic exchange amq.topic
Headers exchange amq.match (and amq.headers in RabbitMQ)

exchange type외에 exchanges는 아래와 같이 몇가지 중요한 속성에 의해 정의됩니다.

  • Name
  • Durability (exchanges survive broker restart)
  • Auto-delete (exchange is deleted when all queues have finished using it)
  • Arguments (these are broker-dependent)

Durable exchange는 브로커가 재시작하여도 살아있지만, transient exchange는 사라지기 때문에 브로커가 재시작된 후에 다시 정의되어야 합니다.

Default Exchange

기본 exchange는 이름이 없는 direct exchange입니다. 이것은 간단한 어플리케이션들을 위한 중요한 속성이 있습니다. 모든 큐들은 생성되면서 자동으로 큐와 동일한 이름의 라우팅 키로 기본 exchange와 연결이 됩니다.

예를들어, 만약 “search-indexing-online”이라는 이름의 큐를 만든다면, AMQP 브로커는 “search-indexing-online”라는 라우팅 키로 기본 exchange와 그 큐를 연결할 것입니다. 그래서, 메시지를 기본 exchange에 “search-indexing-online” 라우팅키로 발행하면 “search-indexing-online” 큐에 전달될 것입니다.

Direct Exchange

direct exchange는 메시지의 라우팅 키를 바탕으로 큐에 메시지를 전달합니다. direct exchange는 unicast(한 사람의 특정 수신자에게만 데이터 패킷을 전송하는 방식) 라우팅에 적합합니다. 물론, multicast 라우팅에도 쓰일수 있습니다.

동작방법은 다음과 같습니다.

> 큐는 K라는 라우팅키로 exchange에 바인딩 되어 있습니다.

> R이라는 라우팅키를 가지는 새로운 메시지가 direct exchange에 전송된다면, exchange는 K=R이 같은 큐에 그 메시지를 전송합니다.

direct exchange는 보통 여러 workers간에 tasks 분리에 많이 사용됩니다.

exchange delivering messages to  queues based on routing key

Fanout Exchange

fanout exchange는 메시지들을 라운팅키는 무시하고 바인드된 모든 큐에 라우트 합니다. 만약 N개의 큐가 fanout exchange에 바운드 되었다면, exchange는 새로운 메시지를 n개의 큐 모두에게 복사본을 전달합니다. 메시지를 브로드캐스트하는데 좋습니다.

사용 예:

> 스포츠 뉴스 사이트에서 이를 이용해 모바일 클라이언트들에게 near real-time으로 점수를 업데이트 할 수 있습니다.

> 분산 시스템에서 다양한 상태나 설정 업데이트를 브로드캐스트할 수 있습니다.

exchange delivering messages to three queues

Topic Exchange

Topic Exchange 는 메시지를 이미 exchange에 등록된 큐 중에서 라우팅키나 라우팅키의 패턴이 매칭되는 경우 전달 합니다. topic exchange는 보통 multicast 라우팅에 많이 쓰입니다.

Topic exchange는 많은 consumers/applications가 어떤 타입의 메시지들을 받아야 하는지가 문제가 될때 사용됩니다.

사용예 :

> 특정 위치를 기반으로 데이터를 분산시킬때

> 주식 가격 업데이트

> 카테고리나 태깅에 의한 특정 뉴스 업데이트

Headers Exchange

headers exchange는 라우팅키 대신 메시지 헤더에 여러 속성들에 의해 라우팅되기 위해 디자인 되었습니다. 큐는 headers exchange에 한개 이상의 헤더 속성과 매칭해서 바인딩 할수 있습니다. 그리고 브로커는 메시지를 큐에 전달하기 위해 한가지 속성을 개발자로부터 더 요구하게 됩니다. 그 속성은 “x-match” 이며 둘(“any”와 “all”) 값 중 하나를 가질 수 있습니다.”any” 일 경우 헤더 값의 한개만 매칭되어도 만족하게 되지만, “all”일 경우 모든 값이 모두 매치되어야 합니다.

 

Queues

AMQP 모델의 Queues는 다른 Message queueing 시스템의 Queues와 많이 비슷합니다. 메시지를 저장하고 그 메시지는 어플리케이션에 의해 소비됩니다. Queues는 다음과 같은 속성들을 가집니다.

  • Name
  • Durable (the queue will survive a broker restart)
  • Exclusive (used by only one connection and the queue will be deleted when that connection closes)
  • Auto-delete (queue is deleted when last consumer unsubscribes)
  • Arguments (some brokers use it to implement additional features like message TTL)
Queue는 미리 선언을 한 후에 사용할 수 있습니다. 선언을 하면 큐를 생성하는 것이며, 이때 만약 같은 이름과 속성을 가진 큐가 생성되어 있는 경우 아무런 영향이 없지만, 다른 속성을 가지고 생성할 경우 406( PRECONDITION_FAILED) 에러가 나게 됩니다.

Queue Names

어플리케이션에서 직접 지정하거나 브로커에게 생성을 요청해서 전달받을 수 있습니다. 큐 이름은 최대 255bytes의 UTF-8 문자입니다. 브로커가 생성해주는 이름은 유일한 이름이 됩니다.

“amq”로 시작하는 큐 이름은 브로커가 사용하도록 미리 선언되어 있기 때문에, 만약 시도시에는 403(ACCESS_REFUSED) 에러가 발생합니다.

Queue Durability

Durable queues는 디스크에 저장되어 브로커가 재시작해도 살아있습니다. 하지만 모든 상황에서 Durable queues가 필요하지는 않을것 입니다. 그리고 Durable queues와는 오직 Durable exchanges만 연결될수 있습니다.

주의할 점은 Durable queues에 저장된 메시지라 하더라도 Persistent messages가 아닌 경우, 브로커가 재시작된 후에 복구 되지 않습니다.

Bindings

Bindings는 Exchanges가 큐에게 메시지를 전달하기 위한 룰 입니다. Bindings는 Exchange types에 따라 사용되어 지는 routing key 속성을 가지고 있을 수 있습니다.

routing key의 목적은 Exchange에 발생된 특정 메시지가 연결된 큐중에 어떤 큐에 전달될지를 선택할때 사용됩니다. 다른 말로 하면, filter라고 할수 있습니다.

Consumers

AMQP 0-9-1 모델에서 Consumers가 큐의 메시지를 소비(consume)하는 방법은 다음 두가지가 있습니다.

 

  • Have messages delivered to them (“push API”)
  • Fetch messages as needed (“pull API”)

“push API”를 사용하기 위해서는 어플리케이션은 메시지를 받기위한 특정 큐에 등록해야하고 이를 구독(Subscribe)라고 합니다. 큐마다 한개 이상의 Consumers가 등록될수 있고 또는 Exclusive Consumer로 등록 할수도 있습니다.

각각의 Consumer는 Consumer tag라는 식별자가 있습니다. 이것을 이용해 메시지의 구독을 취소(unsubscribe)할 수 있습니다.

 

No comments yet

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

%d 블로거가 이것을 좋아합니다: