브로커 간 연결 시 'Duplex' 옵션의 장단점은?

브로커 간 연결 시 'Duplex' 옵션의 장단점은?

대규모 분산 시스템이나 여러 지역(Region)에 걸친 엔터프라이즈 환경에서는 단일 메시지 브로커의 물리적 한계를 극복하기 위해 여러 대의 브로커를 그물망처럼 묶는 'Network of Brokers (NoB)' 아키텍처를 구성하게 됩니다.

이때 브로커와 브로커 사이를 연결하여 메시지를 전달해 주는 핵심 컴포넌트가 네트워크 커넥터(Network Connector)입니다. 그리고 이 커넥터 설정을 다루다 보면 반드시 마주치게 되는 마법의 옵션이 하나 있습니다. 바로 양방향 통신을 제어하는 duplex 옵션입니다.

편리해 보이는 이 옵션을 무심코 켰다가는 대규모 트래픽 환경에서 심각한 병목 현상을 겪을 수 있습니다. 이 가이드에서는 브로커 간 연결 시 duplex="true" 옵션이 가져다주는 강력한 장점과, 그 이면에 숨겨진 치명적인 성능적 단점을 아키텍처 관점에서 상세히 해부합니다.

---

1. Network of Brokers와 단방향 통신의 기본 원리

ActiveMQ와 같은 메시지 브로커에서 별도의 옵션 없이 <networkConnector>를 선언하면, 이 연결은 철저하게 단방향(Unidirectional)으로만 동작합니다.

• 브로커 A의 설정 파일에 브로커 B로 향하는 커넥터를 정의했다면, 브로커 A는 브로커 B로 메시지를 보낼(Forwarding) 수만 있습니다.
• 만약 브로커 B에 연결된 컨슈머(Consumer)가 브로커 A에 있는 큐의 메시지를 가져오거나, 브로커 B 측에서 발생한 메시지를 브로커 A로 보내야 한다면, 브로커 B의 설정 파일에도 브로커 A로 향하는 커넥터를 별도로 뚫어주어야 합니다. (즉, 양방향 통신을 위해 2개의 독립적인 TCP 연결이 필요합니다.)

이러한 상호 연결 방식은 성능상으로는 가장 완벽하지만, 네트워크 인프라 환경에 따라 구축 자체가 불가능한 상황을 발생시킵니다.

---

2. Duplex(양방향) 옵션의 등장과 동작 메커니즘

duplex="true" 옵션은 앞서 언급한 단방향 연결의 한계를 극복하기 위해 고안되었습니다.

브로커 A에서 브로커 B로 향하는 네트워크 커넥터에 이 옵션을 켜면, 브로커 A가 브로커 B로 TCP 접속을 맺는 바로 그 순간, 브로커 B 내부적으로도 브로커 A로 향하는 가상의(Virtual) 네트워크 커넥터가 자동으로 생성됩니다.

결과적으로 단 하나의 물리적인 TCP 소켓(Socket) 연결을 통해 양쪽 브로커가 서로 메시지를 주고받는 양방향(Bidirectional) 스트리밍이 가능해집니다.

<networkConnectors>
    <networkConnector name="linkToBrokerB" 
                      uri="static:(tcp://brokerB:61616)" 
                      duplex="true" />
</networkConnectors>

---

3. Duplex 옵션 도입 시의 강력한 장점 (Pros)

이 옵션은 인프라 구성의 제약을 우회하고 관리의 편의성을 극대화하는 데 압도적인 장점을 제공합니다.

A. 방화벽(Firewall) 및 NAT(네트워크 주소 변환) 환경의 완벽한 우회

Duplex 옵션이 존재하는 가장 큰 이유입니다.
예를 들어 브로커 A는 외부 인터넷망이나 지점(Branch) 사무실의 사설망(NAT 환경)에 있고, 브로커 B는 본사의 철저한 보안이 적용된 DMZ(비무장지대) 내부망에 있다고 가정해 봅시다.
보안 정책상 브로커 A(외부)가 브로커 B(내부)의 특정 포트로 접속하는 것은 방화벽에서 인바운드(Inbound) 허용 처리를 하면 가능합니다. 하지만 반대로 브로커 B(내부)가 브로커 A(외부 사설망)를 찾아가서 선제적으로 접속(Outbound)을 맺는 것은 네트워크 토폴로지상 불가능합니다.
이때 브로커 A에서 duplex="true"로 연결을 먼저 시도하기만 하면, 방화벽을 뚫고 맺어진 단일 연결을 통해 본사(브로커 B)의 메시지도 지점(브로커 A)으로 자유롭게 내려보낼 수 있게 됩니다. Hub & Spoke 아키텍처 구축의 핵심 해결책입니다.

B. 설정의 중앙 집중화와 간소화

수십 대의 브로커가 얽혀 있는 클러스터에서 서로 통신하기 위해 각 서버의 XML 설정 파일을 모두 수정하고 재시작하는 것은 엄청난 운영 부담입니다. Duplex를 사용하면 중앙(Hub) 브로커의 설정은 전혀 건드리지 않은 채, 새롭게 추가되는 지점(Spoke) 브로커 측에만 한 줄의 커넥터 설정을 추가하여 양방향 파이프라인을 완성할 수 있습니다.

---

4. Duplex 옵션의 치명적인 단점과 성능 병목 (Cons)

편리함 이면에는 반드시 대가가 따릅니다. Duplex 옵션은 대규모 트래픽(초당 수만 건 이상의 메시지) 환경에서 시스템 전체의 Throughput을 심각하게 저하시키는 원인이 됩니다.

A. 단일 TCP 소켓의 대역폭 한계 및 경합(Contention)

단방향 커넥터 2개를 사용하면 Inbound 트래픽과 Outbound 트래픽이 서로 다른 물리적 TCP 소켓과 운영체제의 네트워크 버퍼를 독립적으로 사용하므로 최대 대역폭을 온전히 끌어쓸 수 있습니다.
그러나 Duplex 모드에서는 송신과 수신 메시지, 그리고 양방향의 ACK(수신 확인) 패킷들이 단 하나의 TCP 소켓을 공유하며 뒤엉켜 전송됩니다. 한쪽 방향으로 대용량 메시지가 쏟아지면, 반대쪽 방향으로 가야 할 가벼운 데이터나 제어 신호들까지 큐잉 지연(Queueing Delay)을 겪게 되어 네트워크 병목 현상이 기하급수적으로 악화됩니다.

B. 장애 격리(Fault Isolation) 및 트러블슈팅의 어려움

네트워크 단절이나 슬로우 클라이언트 현상이 발생했을 때, 단방향 구조에서는 어느 쪽 커넥터 스레드가 블로킹(Blocking)되었는지 명확히 파악하고 조치할 수 있습니다. 하지만 단일 소켓에 의존하는 Duplex 환경에서는 한 방향의 지연이 즉각적으로 반대 방향의 패킷 전송까지 마비시키기 때문에(Head-of-Line Blocking 현상), 장애의 근본 원인(Root Cause)이 브로커 A에 있는지 브로커 B에 있는지 식별하기가 매우 까다로워집니다.

---

5. 아키텍처 설계 시 모범 사례 (Best Practices)

그렇다면 엔터프라이즈 환경에서 이 옵션을 어떻게 다루어야 할까요? 아키텍처의 물리적 위치에 따라 명확히 구분하여 사용해야 합니다.

1. 내부망(LAN) 기반의 고성능 클러스터링: AWS의 동일한 VPC 내부나 온프레미스 데이터센터 내의 고속 네트워크 스위치로 묶인 브로커 간 통신이라면, 절대 Duplex 옵션을 사용해서는 안 됩니다. 방화벽 제약이 없다면 반드시 duplex="false" 상태에서 양쪽 브로커에 각각 단방향 커넥터를 생성하여 송수신 파이프라인을 분리해야 초고속 병렬 처리가 가능합니다.
2. 외부망(WAN) 및 DMZ 방화벽 통과: 본사와 수백 개의 매장 포스(POS)기를 연결하는 등, 물리적으로 방화벽이 가로막고 있거나 IP 접근 통제가 엄격한 비대칭 네트워크 환경에서는 성능의 일부 손해를 감수하더라도 Duplex 옵션을 켜는 것이 유일하고도 가장 안정적인 아키텍처 선택지가 됩니다.