AMQP

1. 개요

AMQP(Advanced Message Queuing Protocol)는 메시지 지향 미들웨어에 사용되는 오픈 표준 프로토콜이다. 2003년 JP모건 체이스의 John O'Hara에 의해 처음 제안되었으며, 2005년 여러 회사가 참여하는 워킹 그룹을 통해 개발이 시작되었다. AMQP 1.0은 2011년 OASIS 회원 섹션으로 재편된 워킹 그룹에 의해 발표되었고, 2012년 OASIS 표준으로 승인되었으며, 2014년 ISO 및 IEC 국제 표준으로 채택되었다. AMQP는 타입 시스템, 링크 프로토콜, 메시지 형식 및 메시징 기능을 정의하며, Apache Qpid, Microsoft Azure, IBM MQ, Solace PubSub+ 및 RabbitMQ 등 다양한 구현체가 존재한다. AMQP는 STOMP, XMPP, MQTT, OpenWire와 같은 다른 메시징 프로토콜과 비교되며, JMS와는 API와 프로토콜의 차이점이 있다.

2. 역사

AMQP는 2003년 런던 JP모간 체이스의 존 오하라가 처음 제안했다. 초기 설계는 2004년 중반부터 2006년 중반까지 JP모건 체이스에서 진행되었으며, C 브로커와 프로토콜 문서 개발은 iMatix Corporation이 담당했다.

2005년, JP모건 체이스는 시스코 시스템즈, IONA Technologies, iMatix, 레드햇, TWIST 등과 함께 워킹 그룹을 결성했다. 같은 해 아파치 큐피드와 RabbitMQ가 개발되었다. 이후 마이크로소프트와 StormMQ의 구현도 등장했다. 워킹 그룹은 23개 회사로 확장되었다.

iMatix의 피터 힌트젠스는 2008년에 AMQP의 문제점을 지적하고, 2010년에는 워킹 그룹 탈퇴를 선언하며 ZeroMQ 개발에 집중했다.

2011년 8월, AMQP 워킹 그룹은 OASIS로 재편성되었고, 2011년 10월 30일 AMQP 1.0이 발표되었다. AMQP 1.0은 2012년 10월 OASIS 표준, 2014년 4월에는 ISO/IEC 19464 국제 표준으로 승인되었다.

AMQP는 2006년 6월 0-8 버전을 시작으로 0-9, 0-10, 0-9-1 버전을 발표했지만, 이 초기 버전들은 1.0 버전과는 상당히 다르다. AMQP는 금융 서비스 산업에서 시작되었지만, 광범위한 미들웨어 문제에 일반적으로 적용할 수 있다.

2.1. AMQP의 기원

AMQP는 2003년 런던 JP모간 체이스의 존 오하라에 의해 처음 제안되었다. 초기 설계는 2004년 중반부터 2006년 중반까지 JP모건 체이스에서 진행되었으며, iMatix Corporation이 C 브로커와 프로토콜 문서 개발을 담당했다.

2.2. 워킹 그룹 결성 및 초기 개발

2005년, JP모건 체이스는 시스코 시스템즈, IONA Technologies, iMatix, 레드햇, TWIST 등 여러 회사와 함께 워킹 그룹을 결성하여 AMQP 개발을 본격화했다. 같은 해 JP모건 체이스는 레드햇과 협력하여 아파치 큐피드를 개발했는데, 처음에는 자바로, 곧이어 C++로도 개발되었다. 이와는 별도로, Rabbit Technologies는 Erlang 기반의 RabbitMQ를 개발했다. 이후 마이크로소프트와 StormMQ의 구현도 등장했다.

워킹 그룹은 뱅크 오브 아메리카, 바클레이즈, 시스코 시스템즈, 크레디트 스위스, 도이치 뵈르제, 골드만삭스, HCL 테크놀로지스 Ltd, 프로그레스 소프트웨어, IIT 소프트웨어, INETCO Systems Limited, 인포매티카 (29 West 포함), JP모건 체이스, 마이크로소프트, my-Channels, 노벨, 레드햇, 소프트웨어 AG, 솔라스 시스템즈, StormMQ, Tervela Inc., TWIST Process Innovations ltd, VMware (Rabbit Technologies 인수) 및 WSO2를 포함하여 23개 회사로 확장되었다.

2.3. iMatix의 비판과 ZeroMQ

iMatix의 CEO이자 수석 소프트웨어 디자이너였던 피터 힌트젠스는 2008년에 "AMQP의 문제점 (그리고 해결 방법)"이라는 기사를 작성하여 워킹 그룹에 배포했다. 이 기사에서 힌트젠스는 AMQP의 문제점을 지적하고, AMQP 사양을 수정하는 방법을 제안했다. 당시 iMatix는 이미 ZeroMQ 작업을 시작한 상태였다. 2010년, 힌트젠스는 iMatix가 AMQP 워킹 그룹에서 탈퇴하고, 훨씬 더 간단하고 빠른 ZeroMQ를 선호하여 AMQP/1.0을 지원할 계획이 없다고 발표했다.

2.4. OASIS 표준화

2011년 8월, AMQP 워킹 그룹은 OASIS로 재편성되었다. 2011년 10월 30일, AMQP 1.0이 발표되었다. AMQP 1.0은 2012년 10월 31일 OASIS 표준으로 승인되었고, 2014년 4월에는 ISO/IEC 19464 국제 표준으로 승인되었다.

2.5. 이전 버전

AMQP는 2006년 6월에 0-8 버전을, 같은 해 12월에 0-9 버전을, 2008년 2월에 0-10 버전을, 2008년 11월에 0-9-1 버전을 발표했다. 이 초기 버전들은 2011년에 발표된 1.0 버전과는 상당히 다르다.

3. AMQP 1.0의 특징

AMQP는 메시징 애플리케이션과 통신 패턴을 효율적으로 지원하기 위해 설계된 이진 애플리케이션 계층 프로토콜이다. AMQP는 다음과 같은 특징을 제공한다.

* 흐름 제어: AMQP는 흐름 제어를 제공한다.
* 메시지 지향 통신: 메시지 지향 통신을 제공하며, 다음과 같은 메시지 전달 보장을 제공한다.
* 최대 1회 전달: 각 메시지가 한 번 또는 전혀 전달되지 않음
* 최소 1회 전달: 각 메시지가 확실히 전달되지만 여러 번 전달될 수 있음
* 정확히 1회 전달: 메시지가 항상 확실히 도착하고 한 번만 전달됨
* 인증 및 암호화: SASL 및/또는 TLS 기반의 인증 및/또는 암호화를 제공한다.
* 기본 전송 계층 프로토콜: TCP와 같은 기본 신뢰성 있는 전송 계층 프로토콜을 가정한다.

AMQP 명세는 다음의 여러 계층으로 정의된다.

* 타입 시스템
* 프로세스 간 메시지 전송을 위한 대칭적이고 비동기적인 프로토콜
* 표준화되고 확장 가능한 메시지 형식
* 표준화되었지만 확장 가능한 일련의 '메시징 기능'

3.1. 타입 시스템

AMQP는 널리 사용되는 다양한 유형의 상호 운용 가능한 표현을 허용하는 자기 설명형 인코딩 방식을 정의한다. 또한 주석을 사용하여 형식화된 데이터에 추가적인 의미를 부여할 수 있다. 예를 들어 특정 문자열 값은 URL로 이해될 수 있도록 주석이 달릴 수 있다. 마찬가지로 '이름', '주소' 등을 위한 키-값 쌍을 포함하는 맵 값은 '고객' 유형의 표현으로 주석이 달릴 수 있다.

3.2. 링크 프로토콜

링크 프로토콜은 AMQP의 핵심이다.

새로운 링크를 시작하려면 attach 프레임 본문이 전송되고, 링크를 해제하려면 detach 프레임 본문이 전송된다. 링크는 메시지를 수신하거나 전송하기 위해 설정될 수 있다.

메시지는 설정된 링크를 통해 transfer 프레임을 사용하여 전송된다. 링크의 메시지는 한 방향으로만 흐른다.

전송은 flow 프레임을 사용하여 관리되는 신용 기반 흐름 제어 방식의 적용을 받는다. 이를 통해 프로세스는 너무 많은 양의 메시지에 압도당하지 않도록 보호하거나, 단순히 구독 링크가 원하는 때에 메시지를 가져올 수 있도록 한다.

각 전송된 메시지는 결국 정산되어야 한다. 정산은 송신자와 수신자가 전송 상태에 동의하여 신뢰성 보장을 제공하도록 한다. 전송(또는 전송 세트)에 대한 상태 및 정산 변경 사항은 disposition 프레임을 사용하여 피어 간에 전달된다. 이 방식으로 다양한 신뢰성 보장(최대 1회, 최소 1회, 정확히 1회)을 적용할 수 있다.

3.3. 메시지 형식

AMQP 메시지는 메시지를 보내는 애플리케이션에 의해 생성되는 변경 불가능한 베어 메시지로 정의된다. 이 메시지는 하나 이상의 프로세스 간에 전송될 때 변경되지 않는 것으로 간주된다.

애플리케이션에서 보낸 메시지가 변경되지 않도록 보장함으로써 종단간 메시지 서명 및/또는 암호화가 가능하며, 무결성 검사 (예: 해시 또는 다이제스트)가 유효하게 유지된다. 메시지는 전송 중에 중개자에 의해 주석이 추가될 수 있지만, 이러한 주석은 변경 불가능한 베어 메시지와는 구별된다. 주석은 베어 메시지 전이나 후에 추가될 수 있다.

헤더는 메시지에 대해 요청하거나 표시할 수 있는 표준 배달 관련 주석 집합이며, 생존 시간, 지속성, 우선 순위 등을 포함한다.

베어 메시지 자체는 다음으로 구성된다.

* 선택적 표준 속성 목록 (메시지 ID, 사용자 ID, 생성 시간, 회신 대상, 제목, 상관 관계 ID, 그룹 ID 등)
* 선택적 애플리케이션별 속성 목록 (확장 속성)
* AMQP가 애플리케이션 데이터라고 부르는 본문

속성은 주석과 마찬가지로 AMQP 유형 시스템에 지정된다. 애플리케이션 데이터는 어떤 형식이라도 될 수 있으며, 애플리케이션이 선택한 어떤 인코딩으로든 될 수 있다. 한 가지 옵션은 AMQP 유형 시스템을 사용하여 구조화된 자체 설명 데이터를 보내는 것이다.

3.4. 메시징 기능

AMQP는 큐나 토픽과 같은 분배 노드를 정의하여 메시지 송신자와 수신자 간의 만남 지점 역할을 수행한다.

AMQP가 제공하는 메시징 기능은 다음과 같다.

* 메시지 수신자가 메시지를 수락하거나 거부할 수 있는 전송 결과
* 이동 및 복사 분배 모드를 통한 경쟁 및 비경쟁 소비자 패턴 지원
* 임시 응답 큐와 같이 필요에 따라 노드를 생성하는 기능
* 필터를 통해 수신자가 관심 있는 메시지 집합을 구체화하는 기능

AMQP는 P2P 시스템뿐만 아니라, 메시징 중개자를 활용한 더 크고 풍부한 메시징 네트워크에서도 상호 운용성을 제공한다.

4. 구현체

AMQP 1.0 이전 버전 구현체로는 OW2 컨소시엄의 자바 오픈 소스 구현체인 조람(JORAM)과 여러 AMQP 버전에 대한 지원을 유지하고 있는 아파치 큐피드(Apache Qpid)가 있다.

AMQP 1.0 브로커 구현체는 다음과 같다.

* 아파치 큐피드(Apache Qpid): 아파치 재단(Apache Foundation)의 오픈 소스 프로젝트이다.
* 아파치 액티브MQ(Apache ActiveMQ): 아파치 재단(Apache Foundation)의 오픈 소스 프로젝트이다.
* 애저 이벤트 허브
* 애저 서비스 버스
* IBM MQ
* 솔라스 PubSub+: 하드웨어, 소프트웨어 및 클라우드에서 사용 가능한 멀티 프로토콜 브로커이다.
* 래빗MQ(RabbitMQ): VMware가 후원하는 오픈 소스 프로젝트로, 릴리스 4.0부터 AMQP 1.0을 지원한다.

4.1. AMQP 1.0 브로커 구현체

* 아파치 큐피드(Apache Qpid): 아파치 재단(Apache Foundation)의 오픈 소스 프로젝트이다.
* 아파치 액티브MQ(Apache ActiveMQ): 아파치 재단(Apache Foundation)의 오픈 소스 프로젝트이다.
* 애저 이벤트 허브
* 애저 서비스 버스
* IBM MQ
* 솔라스 PubSub+: 하드웨어, 소프트웨어 및 클라우드에서 사용 가능한 멀티 프로토콜 브로커이다.
* 래빗MQ(RabbitMQ): VMware가 후원하는 오픈 소스 프로젝트로, 릴리스 4.0부터 AMQP 1.0을 지원한다.

4.2. AMQP 1.0 이전 버전 브로커 구현체

* 조람(JORAM): OW2 컨소시엄의 자바 오픈 소스 구현체이다.
* 아파치 큐피드(Apache Qpid): 여러 AMQP 버전에 대한 지원을 유지하고 있다.

5. AMQP와 다른 프로토콜 비교

AMQP는 와이어 레벨 프로토콜 사양이다. 이론적으로 AMQP는 다양한 AMQP 호환 소프트웨어를 클라이언트와 서버 측에 배포할 수 있으므로 상호 운용성을 제공한다.

AMQP와 유사하거나 동일한 영역을 다루는 공개 프로토콜 사양은 다음과 같다.

* 스트리밍 텍스트 지향 메시징 프로토콜(STOMP): Codehaus에서 개발한 텍스트 기반 프로토콜이다. 'destination'과 같은 JMS와 유사한 의미 체계를 사용한다.
* 확장 가능 메시징 및 프레즌스 프로토콜(XMPP): 확장 가능 메시징 및 프레즌스 프로토콜.
* MQTT: 경량의 퍼블리시-서브스크라이브 프로토콜.
* OpenWire: ActiveMQ에서 사용된다.

자바 메시지 서비스(JMS)는 AMQP와 자주 비교된다. 그러나 JMS는 메시지 생산자와 소비자가 어떻게 구현되는지 정의하는 API 사양(Java EE 사양의 일부)이다. JMS는 구현 간의 상호 운용성을 보장하지 않으며, 사용 중인 JMS 호환 메시징 시스템은 클라이언트와 서버 모두에 배포해야 할 수 있다. 반면에 AMQP는 와이어 레벨 프로토콜 사양이므로, 이론적으로는 서로 다른 AMQP를 준수하는 소프트웨어를 클라이언트와 서버에 배포함으로써 상호 운용성을 확보할 수 있다.