'Conduit Subscriptions' 옵션이 클러스터 중복 수신을 막는 원리는?

'Conduit Subscriptions' 옵션이 클러스터 중복 수신을 막는 원리는?

엔터프라이즈 환경에서 단일 메시지 브로커의 한계를 극복하기 위해 여러 대의 브로커를 묶는 'Network of Brokers (NoB)' 아키텍처를 구성하게 됩니다. 하지만 브로커 간에 네트워크 커넥터(Network Connector)를 연결하고 나면, 토픽(Topic) 환경에서는 예상치 못한 네트워크 트래픽 폭주가, 큐(Queue) 환경에서는 로드 밸런싱 불균형 문제가 발생하곤 합니다.

이 문제의 중심에는 바로 conduitSubscriptions 옵션이 있습니다. 이 가이드에서는 해당 옵션이 브로커 간 메시지 전달을 어떻게 최적화하는지, 그리고 목적지 타입(Queue vs Topic)에 따라 왜 설정을 다르게 적용해야만 하는지 상세히 분석합니다.

---

1. Conduit(도관)의 개념과 기본 동작 원리

'Conduit'은 액체나 가스가 흐르는 도관, 즉 파이프를 의미합니다. ActiveMQ 네트워크 커넥터 설정에서 conduitSubscriptions="true" (기본값)로 지정되어 있으면, 브로커는 원격 브로커에 연결된 '여러 개의 동일한 구독(Subscription)'들을 단일 '파이프(Conduit)' 하나로 논리적으로 묶어서 취급합니다.

이 개념이 인프라 아키텍처에서 어떤 차이를 만들어내는지 구체적인 상황을 통해 알아보겠습니다.

---

2. 토픽(Topic) 환경에서의 네트워크 최적화 (Conduit 활성화)

Publish/Subscribe 패턴인 토픽 환경에서 이 옵션은 네트워크 대역폭을 보호하는 가장 핵심적인 방어선입니다.

• 문제 상황 (Conduit 비활성화 시):
  브로커 A에 생산자가 있고, 네트워크로 연결된 브로커 B에 동일한 토픽을 구독하는 컨슈머가 10명 접속해 있다고 가정해 봅시다. 만약 Conduit 기능이 false라면, 브로커 A는 브로커 B 너머에 10개의 개별 구독자가 있다고 각각 인식합니다. 생산자가 메시지를 1개 발행하면, 브로커 A는 네트워크를 통해 동일한 메시지의 복사본 10개를 브로커 B로 전송합니다. 이는 심각한 네트워크 대역폭 낭비입니다.
• 해결 및 원리 (Conduit 활성화 시):
  conduitSubscriptions="true"일 때, 브로커 A는 브로커 B의 컨슈머 10명을 '하나의 파이프(대표 구독자)'로 묶어서 인식합니다. 따라서 브로커 A는 원본 메시지를 네트워크를 통해 딱 1번만 브로커 B로 전송합니다. 메시지를 단 1번 수신한 브로커 B가 자신의 내부 메모리에서 이를 10개로 복제하여 로컬 컨슈머들에게 나누어 줍니다. 결과적으로 브로커 간 구간의 트래픽이 1/10로 줄어드는 엄청난 최적화가 달성됩니다.

---

3. 큐(Queue) 환경에서의 로드 밸런싱 붕괴 (Conduit 비활성화)

토픽에서는 완벽했던 이 옵션이, 작업자에게 메시지를 고르게 분배해야 하는 큐(Queue) 환경에서는 최악의 안티 패턴(Anti-Pattern)으로 돌변합니다.

• 문제 상황 (Conduit 활성화 시):
  브로커 A에 메인 큐가 있고 메시지 100개가 쌓여 있습니다. 워커 노드 확장을 위해 브로커 B에는 컨슈머 9명, 브로커 C에는 컨슈머 1명이 접속해 있습니다. 상식적으로는 브로커 B로 90개, 브로커 C로 10개의 메시지가 가야 가장 효율적인 로드 밸런싱이 됩니다.
  하지만 conduitSubscriptions="true" 상태라면, 브로커 A는 브로커 B의 워커 9명을 단 1개의 파이프로 묶어버립니다. 결국 브로커 A의 라우팅 엔진은 브로커 B(파이프 1개)와 브로커 C(파이프 1개)가 완전히 동일한 가중치를 가진 것으로 착각하게 됩니다.
  결과적으로 브로커 A는 B와 C에 각각 50개씩 메시지를 분배합니다. 브로커 B의 워커 9명은 50개를 순식간에 처리하고 유휴 상태로 놀게 되며, 브로커 C의 워커 1명은 50개의 메시지에 혼자 짓눌려 전체 시스템의 심각한 병목(Bottleneck) 구간이 됩니다.
• 해결 및 원리 (Conduit 비활성화 시):
  큐 통신 환경에서는 반드시 conduitSubscriptions="false"로 설정해야 합니다. 이렇게 해야 브로커 A가 원격 브로커들에 붙어 있는 실제 컨슈머의 머리수(Weight)를 정확히 파악하고, 그 비율(9:1)에 맞게 메시지를 차등 분배하여 완벽한 분산 처리를 이뤄낼 수 있습니다.

---

4. 아키텍처 설계 및 설정 모범 사례

결론적으로 성능과 로드 밸런싱을 모두 잡으려면 "토픽은 true, 큐는 false"가 정답입니다.

하지만 ActiveMQ의 단일 네트워크 커넥터에는 하나의 Conduit 설정만 적용할 수 있습니다. 따라서 실무 프로덕션 환경에서는 큐 트래픽용 커넥터와 토픽 트래픽용 커넥터를 물리적으로 분리하여 설정하는 것이 가장 견고하고 안전한 아키텍처입니다.

<networkConnectors>
    <networkConnector name="queue-connector" 
                      uri="static:(tcp://brokerB:61616)" 
                      conduitSubscriptions="false">
        <excludedDestinations>
            <topic physicalName=">" />
        </excludedDestinations>
    </networkConnector>

    <networkConnector name="topic-connector" 
                      uri="static:(tcp://brokerB:61616)" 
                      conduitSubscriptions="true">
        <excludedDestinations>
            <queue physicalName=">" />
        </excludedDestinations>
    </networkConnector>
</networkConnectors>

---

5. 요약

conduitSubscriptions 옵션은 분산 환경의 네트워크 I/O 효율과 로드 밸런싱 성능을 결정짓는 핵심 통제 장치입니다. 브로커 클러스터를 구축할 때 비즈니스 도메인의 메시징 패턴(Pub/Sub 방식인지 P2P 작업 분배 방식인지)을 정확히 파악하고, 이에 맞게 커넥터를 분리 설계하여 장애 없는 고성능 데이터 파이프라인을 완성하시기 바랍니다.