Artemis의 'Core Bridge'가 가진 고성능 전송 메커니즘은?

Artemis의 'Core Bridge'가 가진 고성능 전송 메커니즘은?

대규모 분산 시스템 환경에서는 여러 데이터센터나 리전(Region)에 흩어진 메시지 브로커들을 하나로 묶어 데이터를 라우팅해야 하는 요구사항이 필연적으로 발생합니다. 이때 브로커 간의 메시지 전달을 담당하는 연결 고리가 필요한데, ActiveMQ Artemis는 이를 위해 'Core Bridge(코어 브릿지)'라는 독자적이고 강력한 기능을 제공합니다.

과거 레거시 환경에서 주로 사용되던 표준 JMS Bridge와 비교했을 때, Artemis의 Core Bridge는 압도적인 처리량(Throughput)과 낮은 지연 시간(Latency)을 자랑합니다. 이 가이드에서는 Core Bridge가 어떻게 인프라의 병목을 제거하고 고성능 메시지 전송을 달성하는지, 그 내부 아키텍처와 핵심 메커니즘을 상세히 해부합니다.

---

1. JMS API의 오버헤드를 제거한 'Native Core API' 통신

JMS Bridge는 이름 그대로 자바 표준 메시징 스펙인 JMS API를 사용하여 두 브로커를 연결합니다. 즉, 브로커 내부에서 자체적으로 JMS Consumer를 띄워 메시지를 읽고, 이를 다시 JMS Producer를 통해 타겟 브로커로 전송하는 방식입니다. 이 과정에서 메시지의 포맷 변환, JMS 헤더 매핑, 트랜잭션 처리 등 무거운 오버헤드가 발생합니다.

반면, Core Bridge는 Artemis 브로커의 심장부인 'Core API' 레벨에서 직접 통신합니다.
브로커 메모리에 적재된 내부 ServerMessage 객체를 굳이 표준 JMS 메시지로 변환(Translation)하지 않고, 원시 바이트(Raw Byte) 상태 그대로 타겟 브로커로 전송합니다. 페이로드 파싱이나 헤더 변환 과정을 완전히 생략하기 때문에 CPU 리소스 소모가 극단적으로 줄어들고 라우팅 속도가 극대화됩니다.

---

2. 비동기 파이프라이닝 (Asynchronous Pipelining)과 윈도우 제어

Core Bridge의 고성능을 뒷받침하는 또 다른 기둥은 Netty NIO 기반의 비동기 전송 방식입니다.

일반적인 동기식(Synchronous) 전송에서는 메시지를 하나 보낸 후 타겟 브로커로부터 '잘 받았다'는 수신 확인(ACK) 패킷이 돌아올 때까지 네트워크 파이프라인이 대기(Block) 상태에 빠집니다. 이는 네트워크의 왕복 지연 시간(RTT)만큼 전송 속도를 갉아먹는 주요 원인입니다.

• Confirmation Window Size: Core Bridge는 전송 확인을 개별 메시지 단위가 아닌 '바이트(Byte) 묶음' 단위로 비동기 처리합니다. 설정된 confirmation-window-size (예: 1MB) 한도 내에서는 타겟 브로커의 응답을 기다리지 않고 수천 개의 메시지를 네트워크 소켓에 연속적으로 스트리밍(Streaming)해 버립니다.
• 타겟 브로커는 데이터를 수신하는 대로 백그라운드에서 비동기적으로 응답을 돌려주며, 소스 브로커는 이 응답을 받을 때마다 윈도우 크기를 다시 회복시킵니다. 네트워크 대역폭을 100% 한계치까지 활용할 수 있는 완벽한 파이프라이닝이 완성되는 것입니다.

---

3. 중복 감지 캐시(Duplicate Detection)를 통한 성능 손실 없는 정합성 보장

브로커 간 네트워크는 언제든 끊어질 수 있습니다. 네트워크가 단절되었다가 복구되는 시점에, 소스 브로커는 자신이 보냈던 메시지가 타겟 브로커에 정상적으로 도착했는지(ACK 유실인지 실제 메시지 유실인지) 확신할 수 없으므로 안전을 위해 메시지를 재전송합니다. 이때 타겟 브로커 큐에 데이터가 중복으로 쌓이는 치명적인 문제가 발생할 수 있습니다.

이를 막기 위해 과거에는 무거운 분산 트랜잭션(XA)을 사용했지만, Core Bridge는 '중복 감지 캐시(Duplicate ID Cache)'라는 매우 가볍고 영리한 메커니즘을 사용합니다.

1. 소스 브로커의 Core Bridge가 메시지를 전송할 때, 자동으로 헤더에 고유한 _AMQ_BRIDGE_MSG_ID_ 속성을 부여합니다.
2. 타겟 브로커는 수신한 메시지의 이 ID를 메모리의 고속 캐시 구조에 저장해 둡니다.
3. 네트워크 복구 후 소스 브로커가 메시지를 재전송했을 때, 타겟 브로커는 캐시를 조회하여 이미 존재하는 ID라면 해당 메시지를 큐에 넣지 않고 조용히 폐기(Discard)합니다.

이 기능을 통해 무거운 분산 트랜잭션 연산 없이도 '정확히 한 번(Exactly-Once)' 전송에 준하는 데이터 정합성을 고속으로 보장할 수 있습니다.

---

4. Core Bridge 구성 및 핵심 튜닝 속성 (broker.xml)

실제 프로덕션 환경에서 Core Bridge를 구성하는 broker.xml의 핵심 설정 블록은 다음과 같습니다.

<core xmlns="urn:activemq:core">
   ...
   <bridges>
      <bridge name="high-speed-bridge-to-seoul">
         <queue-name>local.bridge.queue</queue-name>

         <forwarding-address>seoul.global.topic</forwarding-address>

         <static-connectors>
            <connector-ref>seoul-connector</connector-ref>
         </static-connectors>

         <confirmation-window-size>10485760</confirmation-window-size> <reconnect-attempts>-1</reconnect-attempts>

         <filter string="priority = 'HIGH'"/>
      </bridge>
   </bridges>
</core>

---

5. 아키텍처 설계 시의 필터 최적화 전략 (Best Practice)

Core Bridge 설정 시 반드시 기억해야 할 성능 최적화 포인트는 '필터(Filter)의 위치'입니다.

위 설정 예시처럼 <filter> 속성을 통해 특정 조건의 메시지만 타겟 브로커로 라우팅할 수 있습니다. 만약 브로커 A에 쌓인 10만 개의 메시지 중 1천 개만 브로커 B가 필요로 한다고 가정해 보겠습니다.

이 필터링 연산을 브로커 B(타겟)에 맡기면 안 됩니다. 브로커 A의 Core Bridge 단에서 필터를 적용해야, 애초에 불필요한 9만 9천 개의 메시지가 WAN(원거리 통신망) 네트워크를 타고 넘어가는 것을 원천 차단할 수 있습니다. 브릿지 레벨에서의 사전 필터링은 클라우드 간 데이터 전송 비용(Egress Cost)을 극적으로 낮추고 양쪽 브로커의 I/O 부하를 제거하는 가장 훌륭한 아키텍처 습관입니다.

---

요약하자면, Artemis의 Core Bridge는 페이로드 변환 오버헤드 제거, 비동기 파이프라이닝, 그리고 고속 중복 감지 메커니즘을 하나로 결합하여 시스템 간 초고속 데이터 스트리밍을 실현합니다. 멀티 리전이나 대규모 데이터 파이프라인을 설계하실 때 이 기능을 적극적으로 도입해 보시기를 권장합니다.