'Static Replication'과 'Dynamic Replication'의 설정 차이는?

'Static Replication'과 'Dynamic Replication'의 설정 차이는?

엔터프라이즈 환경에서 메시지 브로커의 고가용성(HA)을 보장하기 위해 Primary-Backup 구조의 데이터 복제(Replication) 아키텍처를 설계할 때, 인프라 엔지니어가 가장 먼저 결정해야 하는 핵심 사안이 있습니다. 바로 클러스터를 구성하는 브로커 노드들이 "서로의 존재를 어떻게 알아내고 네트워크를 연결할 것인가?"에 대한 탐색(Discovery) 전략입니다.

이 탐색 및 연결 전략은 크게 구성 파일에 IP를 고정하는 'Static Replication (정적 복제)'과, 네트워크 브로드캐스팅을 통해 스스로 노드를 찾아내는 'Dynamic Replication (동적 복제)' 두 가지로 나뉩니다.

이 두 가지 방식은 단순히 설정 파일의 문법 차이를 넘어, 시스템의 확장성(Scalability), 보안성, 그리고 클라우드 환경(AWS, GCP 등)에서의 동작 여부를 결정짓는 치명적인 아키텍처적 차이를 만들어냅니다. 본 가이드에서는 이 두 전략의 동작 원리와 설정(broker.xml)의 근본적인 차이점, 그리고 인프라 환경에 따른 최적의 선택 기준을 상세히 해부합니다.

---

1. Static Replication (정적 복제): 철저한 통제와 명시적 연결

Static Replication은 이름 그대로 브로커가 통신해야 할 대상 백업(Backup) 노드나 클러스터 멤버의 IP 주소와 포트 번호를 설정 파일에 하드코딩(Hardcoding)하여 명시적으로 고정하는 방식입니다.

A. 동작 원리
Primary 브로커가 기동될 때, 오직 설정 파일에 적힌 지정된 IP 주소로만 TCP 커넥션을 시도합니다. 주변 네트워크에 다른 브로커가 새로 생겨나든 말든 전혀 관심을 두지 않으며, 오로지 관리자가 맺어준 노드하고만 데이터를 복제합니다.

B. 핵심 설정 요소 (broker.xml)
Static 방식을 구성할 때는 브로드캐스트 관련 설정이 일절 들어가지 않으며, 오직 <connector>와 이를 묶는 정적 클러스터 설정만 존재합니다.

• <connector> 정의: 연결하고자 하는 상대방 브로커의 물리적인 IP와 포트를 정의합니다.
• <cluster-connection> 내의 static-connectors: 클러스터 연결 블록 안에 <static-connectors> 태그를 열고, 앞서 정의한 상대방의 커넥터 이름을 직접 나열합니다.

C. 아키텍처적 장단점

• 장점 (결정론적이고 안전함): 통신 대상이 명확하므로 네트워크 디버깅이 매우 쉽습니다. 또한, 인가되지 않은 외부 브로커가 악의적으로 클러스터에 합류하여 데이터를 훔쳐 가는 것을 원천적으로 차단할 수 있습니다.
• 단점 (경직성): 트래픽이 폭주하여 새로운 브로커 노드를 스케일 아웃(Scale-out)으로 추가해야 할 때, 기존에 구동 중인 모든 브로커의 설정 파일을 수정하고 재시작해야만 새로운 노드를 인식할 수 있다는 치명적인 운영상 불편함이 있습니다.

---

2. Dynamic Replication (동적 복제): 유연성과 자동 확장

Dynamic Replication은 개별 노드의 IP를 설정 파일에 일일이 적지 않고, 네트워크의 멀티캐스트(Multicast)나 UDP 브로드캐스트(Broadcast) 기술을 활용하여 같은 그룹에 속한 브로커들을 자동으로 찾아내어(Auto-Discovery) 복제 클러스터를 형성하는 방식입니다.

A. 동작 원리
브로커가 기동되면, 특정 멀티캐스트 주소(예: 231.7.7.7)로 "나는 A 브로커이고, 내 접속 포트는 61616이다"라는 핑(Ping)을 주기적으로 외칩니다(Broadcast). 동시에 다른 브로커들이 외치는 소리도 귀 기울여 듣습니다(Discovery). 이 소리를 듣고 서로의 존재를 파악한 브로커들은 백그라운드에서 동적으로 TCP 세션을 맺고 복제 파이프라인을 구축합니다.

B. 핵심 설정 요소 (broker.xml)
상대방의 IP 대신, 소리를 외치고 듣기 위한 '주파수(멀티캐스트 주소)'를 설정하는 것이 핵심입니다.

• <broadcast-group>: 내가 누구인지 네트워크에 주기적으로 방송하기 위한 설정입니다. 로컬 커넥터 정보와 멀티캐스트 주소/포트가 들어갑니다.
• <discovery-group>: 다른 브로커들의 방송을 수신하여 클러스터 멤버를 동적으로 업데이트하기 위한 설정입니다.
• <cluster-connection> 내의 discovery-group-ref: 정적 커넥터를 나열하는 대신, "이 디스커버리 그룹에서 찾아낸 노드들과 클러스터를 맺어라"라고 참조(Reference)만 걸어둡니다.

C. 아키텍처적 장단점

• 장점 (극단적인 탄력성): 설정 파일 수정 없이 브로커 인스턴스만 새로 띄우면 알아서 기존 클러스터에 합류하여 복제를 시작합니다. 컨테이너 기반의 오케스트레이션 환경에서 자동 스케일링을 구현할 때 압도적인 편리함을 제공합니다.
• 단점 (네트워크 제약과 보안): 가장 큰 약점은 퍼블릭 클라우드(AWS, Azure, GCP) 환경입니다. 대다수의 퍼블릭 클라우드는 네트워크 폭주를 막기 위해 VPC 내에서의 멀티캐스트/UDP 브로드캐스트 트래픽을 원천적으로 차단합니다. 따라서 일반적인 Dynamic 설정으로는 클라우드 환경에서 노드들이 서로를 절대 찾지 못합니다. (JGroups를 활용한 별도의 우회 설정이 필요합니다.)

---

3. 클라우드와 온프레미스를 가르는 인프라 선택 가이드 (Best Practices)

그렇다면 실제 엔터프라이즈 환경에서는 어떤 방식을 채택해야 할까요? 이는 시스템이 구동되는 물리적/논리적 인프라 환경에 따라 완벽하게 갈립니다.

1. AWS, Azure 등 퍼블릭 클라우드 환경 무조건 'Static'
클라우드 벤더사들은 멀티캐스트 트래픽을 라우팅하지 않습니다. 따라서 EC2 인스턴스 간에 Dynamic 복제를 시도하면 끝없는 통신 고립에 빠지게 됩니다. 클라우드 환경에서는 노드 수가 고정되어 있다면 반드시 Static Replication을 사용하여 명시적인 TCP 연결을 맺어야 합니다.
만약 클라우드에서 스케일 오토링이 필요하다면, 순수 UDP 기반의 동적 복제 대신 클라우드 벤더의 API를 호출하여 멤버를 동적으로 찾아내는 JGroups (예: AWS_PING, KUBE_PING) 플러그인을 브로커의 디스커버리 그룹으로 대체하여 사용해야 합니다.

2. 통제된 사내 온프레미스 (On-Premise) / 베어메탈 환경 'Dynamic' 고려
사내 IDC 센터의 L2/L3 스위치에서 멀티캐스트 라우팅을 완벽하게 지원하고 통제할 수 있다면, Dynamic Replication이 주는 운영의 이점이 훨씬 큽니다. 관리자는 IP 대장(List)을 관리할 필요 없이 신규 서버를 랙에 꽂고 브로커를 띄우기만 하면 즉시 HA 클러스터가 확장됩니다. 단, 보안을 위해 브로드캐스트 그룹에 반드시 인증 패스워드를 걸어 악의적인 노드의 합류를 막아야 합니다.

3. Docker Swarm / Kubernetes 환경의 혼합 접근
Kubernetes(K8s)와 같은 컨테이너 환경에서는 파드(Pod)의 IP가 수시로 변하므로 Static IP를 하드코딩하는 것은 불가능합니다. 이때는 K8s의 Headless Service(DNS 기반)를 활용하여 정적(Static) 연결의 도메인 이름을 동적으로 풀게 만들거나, K8s API 서버에 질의하여 엔드포인트를 찾아내는 JGroups 기반의 Dynamic Replication을 하이브리드 형태로 구성하는 것이 모범 사례입니다.

---

결론적으로 Static Replication과 Dynamic Replication은 설정 파일의 몇 줄을 바꾸는 문제가 아니라, 인프라의 네트워크 토폴로지와 보안 정책, 그리고 확장성 요구사항을 종합적으로 반영해야 하는 아키텍처적 결단입니다. 클라우드의 제약 사항과 사내 네트워크 장비의 지원 여부를 면밀히 분석하여 가장 견고하고 관리하기 쉬운 복제 파이프라인을 구축하시기 바랍니다.