'priorityBackup' 옵션을 사용한 주 브로커 선호도 설정법은?

'priorityBackup' 옵션을 사용한 주 브로커 선호도 설정법은?

엔터프라이즈 인프라 환경에서 메시지 브로커(ActiveMQ 등)의 고가용성(HA)을 설계할 때, 마스터 서버가 죽었을 때 백업 서버로 넘어가는 '페일오버(Failover)' 메커니즘은 매우 익숙한 개념입니다. 클라이언트는 연결이 끊어지면 설정된 URI 목록을 따라 대기 중인 슬레이브 브로커를 찾아가 성공적으로 서비스를 재개합니다.

하지만 인프라 엔지니어들이 종종 간과하는 더 중요한 문제는 장애 상황이 종료된 이후, 즉 '원래의 마스터 서버가 복구되었을 때' 발생합니다. 한 번 백업 서버로 넘어간 클라이언트들은 원래의 주력 서버가 다시 살아나도 스스로 돌아오지 않고 백업 서버에 계속 머무르는 끈질긴 성향을 보입니다.

이러한 '단방향 페일오버'의 한계를 극복하고, 인프라의 토폴로지를 원래의 최적화된 상태로 강제 복귀(Fail-back)시키기 위해 클라이언트 단에서 제공되는 강력한 제어 스위치가 바로 priorityBackup 옵션입니다. 본 가이드에서는 이 옵션이 시스템 내부에서 작동하는 원리와, 다중 데이터센터 및 비대칭 하드웨어 환경에서 아키텍처를 최적화하는 구체적인 설정법을 상세히 해부합니다.

---

1. 단방향 페일오버의 함정과 'Fail-back'의 부재

기본적인 Failover Transport 설정만 적용된 환경에서, 클라이언트는 현재 연결된 브로커가 정상적으로 응답하는 한 절대 먼저 연결을 끊지 않습니다.

[운영 환경의 재앙 시나리오]
마스터 브로커는 고성능 베어메탈 서버에 있고, 슬레이브 브로커는 비용 절감을 위해 사양이 낮은 가상 머신(VM)에 배치되어 있다고 가정해 보겠습니다.
마스터 서버가 OS 패치로 인해 5분간 재부팅됩니다. 수백 대의 클라이언트 애플리케이션은 즉시 슬레이브(VM) 브로커로 페일오버하여 트래픽을 쏟아냅니다. 5분 뒤 마스터 서버가 쌩쌩한 상태로 복구되어 올라옵니다.

하지만 클라이언트들은 이미 슬레이브와 잘 통신하고 있으므로 굳이 마스터로 돌아갈 이유를 느끼지 못합니다. 결국 사양이 낮은 슬레이브 서버가 전체 트래픽을 감당하다가 CPU와 메모리가 고갈되어 뻗어버리고, 그제야 클라이언트들은 다시 마스터로 튕겨 나가는 아찔한 2차 장애(Cascading Failure)를 겪게 됩니다. 이처럼 인프라의 불균형을 방치하는 것은 대규모 트래픽 환경에서 매우 치명적입니다.

---

2. 'priorityBackup' 옵션의 동작 원리: 능동적 감시와 강제 복귀

이러한 문제를 해결하기 위해 클라이언트 연결 URI에 priorityBackup=true를 부여하면, 클라이언트 애플리케이션의 내부 네트워크 동작 패러다임이 완전히 바뀝니다.

A. 백그라운드 감시 스레드 가동
클라이언트가 현재 슬레이브(비우선순위) 브로커에 연결되어 서비스를 처리하고 있을 때, 클라이언트 라이브러리는 백그라운드에 데몬 스레드를 하나 조용히 생성합니다. 이 스레드의 유일한 임무는 설정된 '우선순위 브로커(Priority URI)'의 포트가 다시 열렸는지 주기적으로 핑(Ping)을 때리며 감시하는 것입니다.

B. 즉각적인 세션 탈취 및 재연결 (Fail-back)
마스터 서버가 재기동을 마치고 네트워크 포트(61616)를 다시 개방하는 순간, 백그라운드 감시 스레드가 이를 즉각 알아차립니다. 클라이언트는 현재 잘 통신하고 있던 슬레이브 브로커와의 TCP 세션을 가차 없이 끊어버리고, 원래의 최우선 목적지인 마스터 브로커로 네트워크 파이프라인을 재연결합니다. 시스템 운영자의 수동 개입 없이, 트래픽이 원래의 튼튼한 인프라 경로로 우아하게 자동 복귀(Auto Fail-back)하는 것입니다.

---

3. 핵심 파라미터 및 접속 URI 튜닝 가이드

이 기능을 프로덕션 환경에 적용하려면 URI 문자열에 명확한 선호도 조건을 명시해야 합니다.

[기본적인 설정 예시]

failover:(tcp://master-node:61616,tcp://slave-node:61616)?randomize=false&priorityBackup=true

• randomize=false와의 결합: 이전 가이드에서 다루었듯, 페일오버 주소 목록을 순차적으로 접근하게 만드는 설정입니다. priorityBackup=true를 선언하고 별도의 타겟을 지정하지 않으면, 브로커 목록의 '가장 첫 번째 주소(master-node)'를 자동으로 최우선 주 브로커로 간주합니다.

[명시적인 우선순위 지정: priorityURIs]
클러스터 노드가 3개 이상이거나 그룹핑이 필요할 때는, priorityURIs 파라미터를 사용하여 어떤 브로커들이 우선순위(Primary)인지 정확히 하드코딩하는 것이 아키텍처적으로 훨씬 안전합니다.

failover:(tcp://node1:61616,tcp://node2:61616,tcp://node3:61616)?priorityBackup=true&priorityURIs=tcp://node1:61616,tcp://node2:61616

위와 같이 설정하면 node1과 node2는 주력 그룹이 되고, node3는 최후의 백업 그룹이 됩니다. 클라이언트가 node3에 붙어 있더라도, node1이나 node2 중 하나라도 살아나면 즉시 그쪽으로 트래픽을 돌립니다.

---

4. 인프라 아키텍처 적용 시나리오 (Best Practices)

이 기능이 가장 강력한 위력을 발휘하는 엔터프라이즈 환경은 크게 두 가지로 요약됩니다.

A. 다중 데이터센터(Active-Standby DR) 환경의 트래픽 비용 통제
서울 데이터센터(Primary)와 부산 데이터센터(DR)가 전용선으로 연결되어 있습니다. 서울의 클라이언트는 당연히 서울 브로커를 써야 응답 시간(RTT)이 짧고 전용선 대역폭 비용이 발생하지 않습니다.
서울 센터에 일시적인 장애가 발생하여 클라이언트가 부산 브로커로 페일오버되었습니다. 서울 센터가 복구되었을 때, priorityBackup이 켜져 있지 않으면 수백 대의 서울 애플리케이션들이 영원히 부산까지 왕복 통신을 하며 막대한 전용선 트래픽 비용과 지연 시간을 유발하게 됩니다. 이 옵션은 DR 체제에서 원래의 지역(Local) 데이터센터로 트래픽을 즉각 수거해 오는 필수 라우팅 밸브입니다.

B. 클라우드와 온프레미스의 하이브리드(Hybrid) 아키텍처
마스터 브로커는 사내 IDC의 강력한 랙 서버에 두고, 백업 브로커는 AWS의 퍼블릭 클라우드 인스턴스에 두는 하이브리드 구성을 채택하는 경우가 있습니다. 클라우드 브로커는 트래픽이 인바운드/아웃바운드 될 때마다 종량제 네트워크 과금이 발생합니다. 주력 랙 서버가 고쳐졌을 때 즉시 온프레미스로 연결을 되돌리지 않으면 엄청난 클라우드 과금 폭탄을 맞게 됩니다. 이를 방어하는 경제적인 스위치 역할도 겸합니다.

---

5. 운영 시 주의사항 (재연결 폭풍 방어)

priorityBackup은 매우 훌륭한 기능이지만, 대규모 환경에서는 양날의 검이 될 수 있습니다.

마스터 서버가 막 재기동을 마치고 포트를 열었을 때, 슬레이브에 대기하던 수천 대의 클라이언트 애플리케이션이 "마스터가 살아났다!"며 0.1초 만에 동시에 TCP 커넥션을 맺고 몰려드는 '재연결 폭풍(Reconnection Storm)'이 발생할 수 있습니다. 이는 이제 막 부팅된 마스터 브로커의 CPU를 순식간에 100%로 치솟게 만들어 다시 서버를 죽여버리는 원인이 됩니다.

따라서 클라이언트 수가 많은 환경에서는 이 옵션을 도입할 때 브로커 서버 단의 연결 스로틀링(Throttling)을 함께 설정하거나, 클라이언트 애플리케이션들을 그룹 단위로 나누어 재기동 시점에 시차를 두는 등 인프라의 체력을 고려한 정교한 배포 전략이 병행되어야 합니다.

결론적으로 'priorityBackup'은 고가용성 인프라에서 "일단 서비스만 살려둔다"는 1차원적인 목표를 넘어, "인프라 자원을 원래 설계된 가장 효율적인 형태로 유지한다"는 한 차원 높은 시스템 제어 메커니즘입니다. 네트워크 비용과 서버 스펙의 불균형이 존재하는 환경이라면, 클라이언트 설정의 이 작은 문자열 하나가 전체 인프라의 TCO(총소유비용)를 방어하는 핵심 방어선이 될 것입니다.