Artemis의 'Address'와 'Queue' 관계 (1:N 매핑) 방식은?
전통적인 JMS(Java Message Service) 기반의 메시지 브로커(예: ActiveMQ "Classic")에서는 Point-to-Point 통신을 위한 'Queue'와 Publish/Subscribe 통신을 위한 'Topic'이 완전히 분리된 개념으로 존재했습니다. 하지만 차세대 메시징 시스템인 ActiveMQ Artemis는 이러한 물리적 구분을 없애고, 라우팅의 유연성을 극대화하기 위해 'Address(주소)'와 'Queue(큐)'를 분리하는 독창적인 아키텍처를 도입했습니다.
이 글에서는 Artemis의 핵심 라우팅 모델인 Address와 Queue의 1:N 매핑 구조와 동작 방식을 상세히 해부합니다.

1. Address와 Queue의 개념 분리
Artemis 환경에서 메시지가 생산자(Producer)로부터 소비자(Consumer)에게 전달되는 과정을 이해하려면 먼저 두 가지 핵심 컴포넌트의 역할을 명확히 구분해야 합니다.
- Address (주소): 메시지의 '논리적인 도착지'입니다. 생산자는 물리적인 저장소(Queue)의 존재를 모른 채, 오직 특정 Address로만 메시지를 전송합니다. 비유하자면 우편물의 '도로명 주소'와 같습니다.
- Queue (큐): 메시지가 소비자에 의해 처리되기 전까지 '물리적으로 저장되는 공간'입니다. 소비자는 Address가 아닌 특정 Queue에 연결하여 메시지를 꺼내갑니다. 우편물이 실제로 담기는 '우체통' 또는 '개인 사서함'에 해당합니다.
이러한 분리 덕분에 하나의 Address에 여러 개의 Queue를 바인딩(Binding)하는 1:N 매핑이 가능해집니다.
2. 라우팅 타입 (Routing Types): 메시지의 분기 규칙
하나의 Address에 도달한 메시지가 바인딩된 여러 Queue로 어떻게 분배될지를 결정하는 규칙이 바로 Routing Type입니다. Artemis는 크게 두 가지 라우팅 타입을 제공합니다.
A. Anycast (애니캐스트)
메시지가 Address에 바인딩된 Queue 중 단 하나의 Queue에만 전달되는 방식입니다.
- 동작 방식: Address에 여러 Queue가 연결되어 있더라도, 라우터는 내부적인 분배 규칙(기본적으로 Round-Robin)을 통해 단 하나의 Queue를 선택해 메시지를 전달합니다.
- 활용: 전통적인 JMS의 'Queue' 모델(Point-to-Point)을 구현할 때 사용합니다. 여러 소비자가 동일한 큐를 바라보고 메시지를 나누어 처리하는 작업 부하 분산(Load Balancing) 환경에 적합합니다.
B. Multicast (멀티캐스트)
메시지가 Address에 바인딩된 모든 Queue에 복사되어 전달되는 방식입니다.
- 동작 방식: 생산자가 메시지를 1개 발행하면, 브로커는 Address에 연결된 Queue의 개수만큼 메시지를 복제하여 각각의 Queue에 적재합니다.
- 활용: 전통적인 JMS의 'Topic' 모델(Pub/Sub)을 구현할 때 사용합니다. 하나의 이벤트(예: 회원가입 완료)를 여러 독립적인 시스템(환영 이메일 발송, 포인트 지급, 통계 서버 등)이 동시에 수신하여 각자의 비즈니스 로직을 처리해야 할 때 필수적입니다.
3. 1:N 매핑의 동작 시나리오 및 설정
Artemis의 broker.xml 설정 파일에서 이 관계를 어떻게 정의하는지 살펴보면 이해가 더욱 명확해집니다.
<addresses>
<address name="orders.address">
<multicast>
<queue name="billing.queue" />
<queue name="shipping.queue" />
<queue name="notification.queue" />
</multicast>
</address>
</addresses>
시나리오 분석:
- 주문 시스템(Producer)은 결제, 배송 등의 내부 마이크로서비스 구조를 알 필요 없이 오직
orders.address라는 목적지로 메시지를 전송합니다. - 이 Address는
multicast라우팅 타입으로 설정되어 있습니다. - 브로커는 수신된 단일 메시지를
billing.queue,shipping.queue,notification.queue3개의 물리적 큐로 안전하게 복사하여 저장합니다. - 각 도메인 시스템(Consumers)은 자신에게 할당된 개별 큐에 접속하여 독립적으로 메시지를 소비합니다. 만약 알림(Notification) 서버가 다운되어 메시지를 가져가지 못하더라도, 결제(Billing)와 배송(Shipping) 큐의 메시지 처리에는 전혀 지장을 주지 않습니다.
4. Address-Queue 분리 아키텍처의 이점
이러한 유연한 매핑 구조는 엔터프라이즈 환경에서 압도적인 장점을 제공합니다.
- 생산자와 소비자의 완벽한 디커플링 (Decoupling):
생산자 애플리케이션의 코드를 단 한 줄도 수정하지 않고도, 브로커의 설정만 변경하여 새로운 구독 시스템(Queue)을 손쉽게 추가할 수 있습니다. - 이기종 프로토콜의 통합 라우팅:
AMQP, MQTT, STOMP 등 다양한 프로토콜 클라이언트가 접속하더라도, 내부적으로는 모두 이 코어 모델로 매핑됩니다. 예컨대 MQTT 센서가 특정 Address로 발행한 데이터를 AMQP 기반의 분석 서버가 Queue를 통해 소비하는 크로스 프로토콜 아키텍처를 아주 자연스럽게 구축할 수 있습니다. - 메시지 유실 방지 및 장애 격리 (Fault Isolation):
기존 Topic 모델에서 구독자가 잠시 오프라인이 될 때 발생하던 메시지 증발 문제를 물리적인 Queue를 통해 해결합니다. 각 시스템은 각자의 데이터 저장 공간을 가지므로 전체 시스템의 안정성이 극대화됩니다.
5. 요약
ActiveMQ Artemis의 Address와 Queue 분리 모델은 논리적 목적지와 물리적 저장소를 분리함으로써 얻어지는 1:N 매핑의 유연성을 제공합니다. 이는 단일 브로커 내에서 복잡한 데이터 파이프라인과 다양한 라우팅 요구사항을 가장 직관적이고 안정적으로 구현할 수 있게 해주는 핵심 엔진입니다.
'1. 개발 > 1.8. ActiveMQ' 카테고리의 다른 글
| 브로커 내부의 'Routing Type' 결정 시점은? (0) | 2026.03.15 |
|---|---|
| Anycast 라우팅과 Multicast 라우팅의 차이는? (0) | 2026.03.14 |
| OpenWire 프로토콜의 바이너리 구조 특성은? (0) | 2026.03.14 |
| MQTT 프로토콜 사용 시 QoS 레벨(0, 1, 2)의 구현 방식은? (0) | 2026.03.14 |
| STOMP 프로토콜이 웹소켓(WebSocket)과 궁합이 좋은 이유는? (0) | 2026.03.14 |