아르테미스의 'Cluster Connection'과 'Bridge'의 결정적 차이는?

아르테미스의 'Cluster Connection'과 'Bridge'의 결정적 차이는?

메시지 브로커를 단일 노드로 운영하다 보면, 트래픽이 폭발적으로 증가하거나 시스템의 고가용성(HA)을 확보하기 위해 필연적으로 여러 대의 브로커를 엮는 분산 아키텍처를 설계하게 됩니다. ActiveMQ Artemis에서 여러 브로커 간에 메시지를 전달하고 네트워크를 구성하는 핵심 메커니즘은 크게 'Cluster Connection(클러스터 연결)'과 'Core Bridge(코어 브릿지)' 두 가지로 나뉩니다.

두 기능 모두 "A 브로커의 메시지를 B 브로커로 넘긴다"는 결과적인 현상은 같아 보이지만, 그 탄생 목적과 내부 라우팅 동작 원리, 그리고 적용해야 하는 인프라 환경은 완전히 다릅니다. 본 가이드에서는 이 두 아키텍처의 결정적 차이와 실무 설계 기준을 상세히 해부합니다.

---

1. Cluster Connection: 거대한 하나의 유기체 (Symmetric Scaling)

클러스터 연결의 핵심 철학은 여러 대의 물리적인 브로커를 묶어 마치 '하나의 거대한 논리적 브로커'처럼 동작하게 만드는 것입니다. 주로 동일한 데이터센터(IDC)나 지연 시간이 극도로 짧은 근거리 통신망(LAN) 환경에서 시스템의 전체 처리 용량을 늘리기(Scale-out) 위해 사용됩니다.

A. 토폴로지 자동 인지와 상태 공유
클러스터로 묶인 브로커들은 서로의 존재를 지속적으로 확인하며, 각 노드에 어떤 큐(Queue)가 생성되어 있고 어떤 컨슈머(Consumer)가 접속해 있는지 실시간으로 내부 메타데이터를 교환합니다. 새로운 브로커 노드가 추가되면 네트워크 멀티캐스트(UDP)나 정적 리스트를 통해 스스로 망을 재구성하는 유연성을 가집니다.

B. 수요 기반의 지능적 부하 분산 (Demand-Forwarding)
클러스터 연결의 가장 강력한 무기는 지능적인 부하 분산입니다. A 브로커에 메시지가 쏟아지는데 A에 접속한 애플리케이션의 처리 속도가 느리다면, 브로커는 클러스터 내의 다른 브로커(B, C)들을 탐색합니다. 만약 B 브로커에 놀고 있는(유휴 상태의) 컨슈머가 있다면, A 브로커는 트래픽을 B 브로커로 알아서 분산시켜 줍니다. 반대로 B 브로커 쪽에 컨슈머가 단 한 대도 없다면, 네트워크 낭비를 막기 위해 메시지를 절대 넘기지 않습니다.

C. 제약 사항: 동일한 주소 공간 강제
클러스터 내부에서 메시지가 이동하려면 대상 큐의 이름(Address)이 모든 브로커 간에 완벽하게 동일해야 합니다. A 브로커의 'order.queue'로 들어온 메시지는 B 브로커의 'order.queue'로만 분산될 수 있으며, 이름을 변경하여 라우팅하는 것은 불가능합니다.

---

2. Core Bridge: 독립된 개체 간의 명시적 택배 배달 (Asymmetric Forwarding)

코어 브릿지의 철학은 클러스터처럼 브로커들을 동기화하는 것이 아닙니다. 브릿지는 완벽하게 남남인 두 브로커 사이, 혹은 대륙을 가로지르는 물리적으로 격리된 네트워크 환경(WAN)에서 메시지를 안전하게 '퍼 나르는(Store and Forward)' 전용 파이프라인 역할을 수행합니다.

A. 수동적이고 명시적인 라우팅 룰
브릿지는 스스로 목적지를 탐색하지 않습니다. 인프라 엔지니어가 직접 "A 브로커의 특정 주소로 들어온 메시지를, B 브로커의 특정 주소로 넘겨라"라고 명시적인 규칙을 하드코딩해야 동작합니다.

B. 유연한 주소 매핑 (Address Translation)
클러스터 연결에서는 불가능했던 '이름 변경'이 브릿지에서는 자유롭습니다. 예를 들어 지사 브로커의 'local.sales' 큐에 들어온 데이터를, 본사 브로커로 보낼 때는 'hq.global.sales'라는 전혀 다른 이름의 주소로 변환하여 밀어 넣을 수 있습니다. 이는 이기종 시스템이나 서로 다른 비즈니스 도메인을 통합할 때 압도적인 이점을 제공합니다.

C. 극한의 네트워크 단절 내성
인터넷 망이나 불안정한 전용선을 통과해야 하는 환경에서 브릿지는 진가를 발휘합니다. 두 브로커 간의 네트워크가 끊어지면, 브릿지는 메시지를 유실하지 않고 출발지 브로커의 디스크에 안전하게 쌓아둡니다. 이후 네트워크가 복구되는 즉시 쌓여있던 메시지들을 원격지로 다시 배달합니다. 대상 브로커에 컨슈머가 살아있든 죽어있든 상관없이, 철저하고 묵묵하게 메시지를 포워딩하는 '택배 기사'와 같습니다.

---

3. 아키텍처 설계 시 결정적 차이 비교

두 기술의 특성을 실무적인 관점에서 비교하면 다음과 같이 요약할 수 있습니다.

비교 항목	Cluster Connection	Core Bridge
시스템 결합도	강결합 (Tight Coupling): 하나의 시스템처럼 동작	느슨한 결합 (Loose Coupling): 완전히 독립적인 시스템
도입 목적	트래픽 부하 분산 및 스케일 아웃	원격지 데이터 동기화 및 시스템 통합
메시지 라우팅 기준	수요 기반 (Demand-based): 목적지에 대기 중인 컨슈머가 있을 때만 이동	룰 기반 (Rule-based): 컨슈머 유무와 상관없이 설정된 규칙에 따라 강제 이동
토폴로지 공유	브로커 간 큐/컨슈머 상태를 실시간 공유	서로의 내부 상태나 구조를 전혀 모름
주소(이름) 변경	불가능 (동일한 이름으로만 분산됨)	완벽하게 지원 (A 큐 -> B 토픽으로 매핑 가능)
최적 네트워크 환경	지연이 극도로 적은 동일 IDC / LAN 환경	지연이 크고 단절이 잦은 클라우드 / WAN 환경

---

4. 실무 적용을 위한 아키텍트의 가이드 (Best Practices)

어떤 기술을 선택해야 할지 고민된다면, 비즈니스의 '네트워크 물리 환경'과 '데이터의 목적' 두 가지만 고려하시면 됩니다.

클러스터 연결을 선택해야 하는 경우:
현재 운영 중인 서비스의 동시 접속자가 급증하여, 브로커 1대로는 도저히 CPU와 커넥션 풀을 감당할 수 없을 때 사용합니다. 동일한 서버 랙이나 같은 AWS VPC(Virtual Private Cloud) 내부에 브로커 3~4대를 띄우고 클러스터로 묶으십시오. 클라이언트 애플리케이션들은 아무 브로커에나 접속해도 마치 하나의 브로커와 통신하듯 자연스럽게 부하 분산의 혜택을 누릴 수 있습니다.

코어 브릿지를 선택해야 하는 경우:
데이터를 서울 데이터센터에서 뉴욕 데이터센터로 넘겨야 하거나, 사내 폐쇄망에 있는 브로커에서 외부 DMZ망에 있는 브로커로 특정 이벤트만 선별하여 쏘아 보내야 할 때 사용합니다. 이때는 브로커 간의 상태 동기화가 불필요하며 보안 정책(방화벽)도 중요하므로, 단방향 브릿지를 뚫어 필요한 큐의 데이터만 안전하게 우회시키는 브릿지 토폴로지가 정답입니다.

결론적으로 Cluster Connection은 인프라의 '크기'를 키우는 횡적 확장 기술이며, Core Bridge는 인프라의 '범위'를 물리적 한계 너머로 넓혀주는 연결 기술입니다. 두 기술의 경계를 명확히 이해하고 아키텍처에 맞게 조합한다면, 어떠한 트래픽 환경에서도 견고하고 유연한 메시징 파이프라인을 완성하실 수 있을 것입니다.