Advisory Topic을 통해 알 수 있는 브로커의 내부 상태 정보들은?

Advisory Topic을 통해 알 수 있는 브로커의 내부 상태 정보들은?

엔터프라이즈 환경에서 ActiveMQ와 같은 메시지 브로커를 운영하다 보면, 브로커 내부에서 어떤 일이 벌어지고 있는지 실시간으로 모니터링하고 애플리케이션 차원에서 동적으로 대응해야 하는 순간이 옵니다. 일반적으로 JMX(Java Management Extensions)를 통해 모니터링 시스템을 구축하지만, 외부 모니터링 툴 없이 메시징 애플리케이션 자체가 브로커의 상태 변화를 '메시지' 형태로 직접 수신하여 반응할 수 있게 해주는 강력한 기능이 있습니다. 바로 Advisory Topic(어드바이저리 토픽)입니다.

Advisory Topic은 브로커 내부의 관리 이벤트(클라이언트 접속, 큐 생성, 메시지 폐기 등)를 표준 JMS 메시지로 변환하여 특정한 시스템 토픽(ActiveMQ.Advisory.>)으로 발행하는 메커니즘입니다.

이 가이드에서는 Advisory Topic을 구독함으로써 파악할 수 있는 핵심 내부 상태 정보들과 그 활용법, 그리고 아키텍처 적용 시 주의사항을 상세히 파헤칩니다.

1. 연결 및 라이프사이클 정보 (Connection & Lifecycle)

브로커에 어떤 클라이언트가 언제 접속하고 언제 연결을 끊었는지 실시간으로 파악하는 것은 보안 및 세션 관리의 핵심입니다.

• 관련 토픽: ActiveMQ.Advisory.Connection
• 제공 정보: 새로운 클라이언트의 TCP 연결 생성 및 종료 이벤트.
• 메시지 페이로드: 연결된 클라이언트의 ConnectionInfo (클라이언트 ID, IP 주소 등) 또는 RemoveInfo 객체가 포함됩니다.
• 실무 활용: 인프라 관리자는 이 토픽을 구독하여 인가되지 않은 IP나 비정상적인 클라이언트 ID가 브로커에 접근을 시도할 때 즉각적인 알림(Alert)을 발생시키는 보안 감시 파이프라인을 구축할 수 있습니다.

2. 목적지 상태 정보 (Destination Events)

동적으로 큐(Queue)와 토픽(Topic)이 생성되고 소멸되는 환경에서는 목적지의 생명주기를 추적해야 합니다.

• 관련 토픽: * ActiveMQ.Advisory.Queue (큐 생성/소멸)
• ActiveMQ.Advisory.Topic (토픽 생성/소멸)

• 제공 정보: 브로커 메모리 상에 새로운 물리적 목적지가 생성되거나, 사용되지 않아 삭제될 때의 이벤트.
• 실무 활용: MSA 환경에서 새로운 마이크로서비스가 배포되며 자신만의 전용 임시 큐(Temporary Queue)를 생성할 때, 메인 라우터 시스템이 이를 자동으로 감지하고 라우팅 테이블을 동적으로 갱신하는 '디스커버리(Discovery)' 패턴을 구현하는 데 사용됩니다.

3. 생산자와 소비자의 동적 증감 추적 (Producers & Consumers)

특정 큐나 토픽에 몇 명의 컨슈머(Consumer)가 붙어 있는지, 프로듀서(Producer)가 활성화되어 있는지는 오토 스케일링(Auto-scaling)의 핵심 지표입니다.

• 관련 토픽:
• ActiveMQ.Advisory.Consumer.Queue.<QueueName>
• ActiveMQ.Advisory.Producer.Queue.<QueueName>

• 제공 정보: 특정 목적지에 새로운 생산자나 소비자가 구독을 시작(Subscribe)하거나 종료(Close)할 때 발생하는 이벤트. ConsumerCount 및 ProducerCount 값이 헤더에 포함됩니다.
• 실무 활용: 결제 처리 큐(payment.queue)를 주시하다가, 해당 큐에 연결된 활성 컨슈머의 수가 0이 되는 순간(모든 워커 노드 다운) 관리자에게 치명적 장애 알림(Critical Alert)을 보내거나, 쿠버네티스(Kubernetes) HPA(Horizontal Pod Autoscaler)에 메트릭을 트리거하여 새로운 워커 파드를 강제로 기동시키는 자동 복구 시스템을 만들 수 있습니다.

4. 메시지 흐름 및 브로커 장애 감지 (Message Flow & Exceptions)

브로커 운영 중 가장 민감하게 반응해야 하는 비정상적인 데이터 흐름과 리소스 고갈 징후를 실시간으로 포착합니다.

• 관련 토픽:
• ActiveMQ.Advisory.MessageDLQ.Queue.<QueueName>: 메시지가 최대 재시도 횟수를 초과하여 DLQ(Dead Letter Queue)로 이동했을 때 발행됩니다. 배치 시스템이 주기적으로 DLQ를 긁어가는 대신, 실시간으로 독성 메시지(Poison Pill) 발생을 감지할 수 있습니다.
• ActiveMQ.Advisory.SlowConsumer.Queue.<QueueName>: 브로커가 특정 컨슈머의 처리 속도가 너무 느리다고 판단했을 때(Slow Consumer 감지) 발행됩니다. 시스템 병목의 주범을 즉각적으로 색출할 수 있습니다.
• ActiveMQ.Advisory.Full / ActiveMQ.Advisory.MessageDiscarded: 큐의 메모리 한계(memoryLimit)가 가득 차서 메시지 유입이 차단되거나, 폐기 정책(Eviction Policy)에 의해 메시지가 버려졌을 때 경고를 발송합니다.

5. Advisory Topic 설정 및 아키텍처 최적화 주의사항

이처럼 유용한 Advisory Topic은 ActiveMQ에서 기본적으로 활성화(advisorySupport="true")되어 있습니다. 하지만 실무 프로덕션 환경에서는 반드시 성능과의 트레이드오프(Trade-off)를 엄격하게 통제해야 합니다.

A. 심각한 성능 저하의 주범: 메시지 전달 관련 Advisory
브로커는 설정에 따라 "메시지가 큐에 들어올 때", "메시지가 컨슈머에게 전달될 때", "메시지가 소비 완료(ACK)되었을 때"조차도 Advisory 메시지를 생성할 수 있습니다.
만약 초당 10,000건의 비즈니스 메시지가 흐르는 시스템에서 advisoryForConsumed="true"를 켜둔다면, 브로커는 내부적으로 10,000건의 관리용 메시지를 추가로 생성하고 라우팅해야 하므로 성능이 극심하게 저하됩니다.

B. 브로커 설정(XML)을 통한 세밀한 통제
따라서 activemq.xml 파일에서 불필요한 Advisory는 모두 끄고, 시스템 관리에 반드시 필요한 이벤트(DLQ, Slow Consumer, Connection 등)만 선별적으로 활성화하는 튜닝이 필수적입니다.

<broker xmlns="http://activemq.apache.org/schema/core" 
        advisorySupport="true"> <destinationPolicy>
        <policyMap>
            <policyEntries>
                <policyEntry queue=">">
                    <policyEntry advisoryForConsumed="false" 
                                 advisoryForDelivery="false" 
                                 advisoryForDiscardingMessages="true" 
                                 advisoryForSlowConsumers="true" />
                </policyEntry>
            </policyEntries>
        </policyMap>
    </destinationPolicy>
</broker>

C. 권한 및 보안 통제
Advisory Topic도 결국 브로커 내부의 또 다른 토픽일 뿐입니다. 인가되지 않은 일반 클라이언트 애플리케이션이 ActiveMQ.Advisory.> 경로를 와일드카드로 구독하게 되면 브로커 전체의 메타데이터와 시스템 구성도가 유출되는 보안 취약점이 발생합니다. 브로커의 인가(Authorization) 플러그인을 통해 오직 '관리자(Admin)' 롤(Role)을 가진 전용 모니터링 애플리케이션만 해당 토픽에 접근할 수 있도록 격리해야 합니다.

6. 요약

Advisory Topic은 JMX 폴링(Polling) 방식의 한계를 넘어, 이벤트 기반(Event-Driven)의 브로커 모니터링 아키텍처를 완성하는 핵심 기능입니다. 단순히 지표를 확인하는 것을 넘어 "컨슈머가 0이 되면 노드를 늘린다"와 같은 자가 치유(Self-Healing) 인프라를 구축할 때 확실한 트리거 역할을 수행합니다. 비즈니스 요건에 맞춰 필요한 어드바이저리 이벤트만 정교하게 튜닝하여 시스템의 투명성과 성능을 확보하시기 바랍니다.