제가 지금 하고 있는 프로젝트에서는 메시지를 보내고 비동기로 관리하기 위해 RabbitMQ를 사용하고 있습니다. 그런데 RabbitMQ는 말로만 들어봤지 실제로 어떻게 동작을 하는지 그리고 이걸 왜 그렇게 많은 기업에서 요구하는지 알고 싶었습니다. 그래서 RabbitMQ를 조금 알아봤는데 RabbitMQ이전에 상위개념인 AMQP를 먼저 알아보고자 이렇게 정리해 보고자 합니다.
AMQP는 메시지 지향 미들웨어 (MOM)을 위한 표준 응용 계층 프로토콜입니다. 풀어서 이야기하면 메시지 통신을 위한 규약이라고 보면 되겠습니다. 서로다른 특히 플랫폼에 종속적인 제품들 사이에서 채팅해야 하는 경우가 있습니다. 이럴 때 메시지 교환을 위해 메시지 포맷을 변환 목적으로 메시지 Bridge를 사용하거나 서로 다른 두 시스템을 통합할 필요가 있었습니다.
그래서, 서로 다른 시스템 간의 최대한 효율적으로 메시지를 교환하기 위해 AMQP 프로토콜이 등장했습니다. 이러한 규약 기반으로 만들어진 구현체 중에 하나가 RabbitMQ입니다.
출처 : https://www.wallarm.com/what/what-is-amqp
구성요소 | 설명 |
---|---|
Exchange(교환기) | 메시지를 수신하고 이를 라우팅 규칙에 따라 적절한 큐에 전달하는 역할을 합니다. |
Binding(바인딩) | 교환기와 큐를 연결하여 라우팅 규칙을 정의하는 설정입니다. |
Queue(큐) | 메시지를 저장하는 버퍼 역할을 하며, 소비자(Consumer)가 메시지를 읽을 때 까지 대기합니다. |
Message(메시지) | 전달되는 데이터의 기본단위로 HTTP와 비슷하게 헤더/본문으로 구성됩니다. |
AMQP는 메시지를 적절한 Queue에게 바인딩하기위해 다양한 타입의 Exchange속성이 존재합니다.
설명에 앞서 라우팅 키, 바인딩 키를 언급하는데 라우팅 키를 설정하는 주체는 Publisher고 바인딩 키를 설정하는 주체는 Consumer입니다.
여기서 (라우팅 키 = 바인딩 키) 의미를 가집니다.
Publisher가 메시지를 보낼 때 보내야할 Exchange의 명칭과 라우팅 키를 함께 보내면 Exchange에서는 라우팅 키와 바인딩 키가 일치하는 Queue에 메시지를 보내는 방식입니다.
다음과 같은 AMQP 구조가 있으면 Publisher가 Exchange E1과 라우팅 키 success를 보내면 먼저 Exchange E1으로 연결되고 라우팅 키 success와 일치하는 Q1 Queue로 메시지를 전달합니다.
Publisher가 특정 Exchange에 라우팅 키와 상관없이 Exchange에 연결된 모든 Queue에게 메시지를 보내는 방식입니다. 이 Exchange 방식은 알림 시스템 등에 사용됩니다.
Publisher에서 보내는 라우팅 키의 패턴에 따라 메시지를 라우팅 하는 방식입니다. 만약 라우팅 키의 구분을 "/" 으로 지정하고 바인딩 시 와일드 카드로 "*","#"을 지정하여 사용할 수 있습니다.
위의 예시처럼 라우팅 키 요청을 check.* 로 설정하면 바운딩에서 check와 관계된 바인딩에만 메시지를 송신합니다.
메시지의 헤더 정보를 기반으로 라우팅을 하는 Exchange입니다. 다른 Exchange와 다르게 라우팅 키를 사용하지 않고 메시지 자체의 헤더와 바인딩 된 Queue의 헤더 조건과 일치할 때 Queue로 전달됩니다. 특정 헤더를 가진 메시지만 큐에 전달하도록 만들 수 있습니다.
AMQP의 계층 구조는 OSI 7 Layer 구조와 비슷한 부분이 있어서 OSI 7 Layer 구조를 알고있으면 이해가 쉬울거라고 생각합니다.
계층이름 | 특징 |
---|---|
프레임 계층(Frame) | 네트워크에서 교환되는 패킷의 전송을 담당 |
전송 계층(Transport) | 연결과 흐름 제어를 관리하며 안정적인 데이터 전송을 보장 |
세션 계층(Session) | 여러 개의 세션을 연결 위에서 관리하며, 각 세션마다 독립적인 흐름 제어 가능 |
애플리케이션 계층(Application) | 메시지 큐, 교환기, 바인딩 등 메시징의 주요 개념을 관리하고 정의 |
AMQP는 프레임 기반 프로토콜 입니다. 프레임은 AMQP의 전송 단위이며, 각 프레임에는 특정 작업에 대한 명령 혹은 데이터가 포함됩니다.
프레임 이름 | 특징 |
---|---|
메서드 프레임(Method) | Exchange 생성, Queue 선어, 메세지 퍼블리싱 등의 AMQP 명령을 표현 |
헤더 프레임(Header) | 메세지의 속성 정보 |
바디 프레임(Body) | 메세지의 실제 데이터 |
(Heartbeat) 프레임 | 심장 박동처럼 클라이언트와 서버간 연결 상태 유지를 위해 주기적으로 전송 |
1. 연결 및 채널 생성
Publisher가 메시지 브로커에 연결을 요청하고 연결이 수립되면 여러개의 채널을 생성할 수 있습니다.
2. Exchange 및 Queue 선언
이때 Publisher는 Exchange 선언 후 라우팅 규칙을 정하고 Queue 선언시에는 Exchange와 Queue사이의 바인딩 규칙을 설정합니다.
3. 메시지 전송
Publisher는 특정 Exchange에 메시지를 전송합니다. 메시지에 라우팅 키가 포함할 수 있으며 Exchange는 라우팅 규칙에 따라 특정 Queue에 메시지를 전달합니다.
4. 메시지 소비
Queue에서 Consumer에게 메시지를 전달합니다. Consumer가 메시지를 성공적으로 전달받으면 확인 응답(ACK) 혹은 부정 응답(NACK)을 보냅니다.
요즘 많은 소프트웨어가 확장 목적으로 마이크로서비스 아키텍처를 도입하게 되었습니다, 확장성은 좋아졌으나 모듈 간 안정적이고 효율적인 통신이 필요하게 되었고 이때 AMQP는 데이터의 손실이나 중복 없이 전달해야 하는 경우 그리고 라우팅이 복잡한 시스템에 적합한데 이러한 구조를 가진 소프트웨어는 대부분 비교적 최근에 나오는 소프트웨어들이고 그래서 기업들이 많이 요구하는 거 같다고 생각합니다.
https://velog.io/@holicme7/표준-메세징-프로토콜-정리-AMQP-STOMP-MQTT
https://jeongchul.tistory.com/812#AMQP%20%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-1
https://blog.naver.com/pjt3591oo/223363564670
(항상 감사합니다.)