메시징 시스템은 분산 환경에서 시스템 간 안정적이고 빠른 데이터 전송을 위해 필수적인 요소입니다. 특히 ActiveMQ는 오픈 소스 메시지 브로커로 다양한 프로토콜과 통합 환경을 지원하며, 기업용 애플리케이션에 널리 활용되고 있습니다. 그러나 사용자 증가나 시스템 확장 시 기본 설정만으로는 한계가 발생할 수 있으므로, 이중화 구성과 세밀한 튜닝이 필요합니다. 본 포스트에서는 ActiveMQ의 이중화 구현과 성능 튜닝을 위한 구체적인 설정 방법과 코드 예시를 통해 실무에 바로 적용 가능한 가이드를 제공합니다.

1. ActiveMQ 이중화 구성의 개념과 필요성

1.1 이중화 구성의 정의

이중화 구성은 장애 발생 시 자동으로 백업 서버로 전환하여 서비스 중단 없이 운영할 수 있도록 하는 방법입니다. ActiveMQ는 주 서버와 보조 서버 간 데이터를 실시간으로 동기화하는 다양한 방법을 제공하며, 이를 통해 장애 시 빠른 복구가 가능합니다.

1.2 이중화 구성의 주요 이점

  • 고가용성(HA): 단일 장애점(SPOF)을 제거하여 서비스 연속성을 보장합니다.

  • 데이터 안전성: 메시지 손실 없이 데이터를 백업하여 장애 복구 시 데이터 무결성을 유지합니다.

  • 확장성: 부하 증가 시 추가 서버를 통해 효율적으로 확장이 가능합니다.

2. ActiveMQ 이중화 구현 방법

ActiveMQ에서 이중화 구성은 여러 방식으로 구현할 수 있습니다. 여기서는 네트워크 클러스터링과 Master-Slave 방식의 구체적인 설정 예시를 소개합니다.

2.1 네트워크 클러스터링을 통한 이중화

네트워크 클러스터링 방식은 여러 브로커를 하나의 클러스터로 구성하여 서로 데이터를 동기화하는 방법입니다. 아래는 activemq.xml 파일 내에 네트워크 커넥터를 설정하는 예시입니다.

<broker xmlns="http://activemq.apache.org/schema/core" brokerName="BrokerA" dataDirectory="${activemq.data}">
  <!-- 네트워크 클러스터링 설정: 다른 브로커(BrokerB)와 이중화 구성 -->
  <networkConnectors>
    <networkConnector name="clusterConnector" 
                      uri="static:(tcp://brokerB:61616)" 
                      duplex="true" 
                      timeout="3000" 
                      updateClusterClients="true"/>
  </networkConnectors>
  <!-- 기타 브로커 설정 -->
</broker>

위 설정에서는 BrokerA가 BrokerB와 네트워크 커넥터를 통해 이중화 구성을 형성합니다.

  • duplex=”true” 옵션은 양방향 통신을 가능하게 하여, 어느 한쪽이 장애 시 자동으로 연결을 재설정합니다.

  • timeout 및 updateClusterClients 옵션을 통해 클러스터 환경의 안정성을 높일 수 있습니다.

또 다른 방법으로는 Master-Slave 구성을 활용할 수 있습니다. 공유 파일 시스템이나 데이터베이스를 이용해 메시지 데이터를 공유하는 방식입니다.

<broker xmlns="http://activemq.apache.org/schema/core" brokerName="master" dataDirectory="${activemq.data}">
  <persistenceAdapter>
    <kahaDB directory="${activemq.data}/kahadb"/>
  </persistenceAdapter>
  <!-- Master-Slave 구성 설정 -->
  <masterSlave>
    <master/>
  </masterSlave>
</broker>

보조 서버(Slave)는 master의 데이터 저장소를 공유하도록 구성되며, master에 장애가 발생하면 자동으로 slave가 활성화됩니다.

3. 사용자 증가에 따른 성능 튜닝 포인트

시스템에 사용자가 증가하면 브로커의 메시지 처리 능력과 응답 속도를 유지하기 위해 세밀한 튜닝이 필요합니다.

3.1 하드웨어 및 네트워크 최적화

CPU, 메모리, 디스크 I/O, 네트워크 대역폭 등 물리적 자원을 점검하고 최적화하여 병목 현상을 최소화합니다.

3.2 JVM 튜닝

JVM 옵션을 조정하여 Garbage Collection 효율을 높이고, 힙 메모리 크기를 상황에 맞게 설정함으로써, 애플리케이션 지연 시간과 메모리 부족 문제를 예방합니다.

3.3 ActiveMQ 설정 및 브로커 파라미터 튜닝

ActiveMQ의 성능을 극대화하기 위해 activemq.xml 내의 destinationPolicy 설정과 함께, 메시지 큐 및 토픽에 대한 세밀한 파라미터 튜닝이 중요합니다. 아래는 예시 코드입니다.

<destinationPolicy>
  <policyMap>
    <policyEntries>
      <!-- 토픽에 대한 설정: 프로듀서 플로우 컨트롤과 메모리 제한 설정 -->
      <policyEntry topic=">" producerFlowControl="true" memoryLimit="10485760" cursorMemoryHighWaterMark="70">
        <pendingDurableSubscriberPolicy>
          <constantPendingMessageLimitStrategy limit="1000"/>
        </pendingDurableSubscriberPolicy>
      </policyEntry>
      <!-- 큐에 대한 설정: prefetch 및 메모리 사용량 조정 -->
      <policyEntry queue=">" producerFlowControl="true" memoryLimit="5242880" prefetch="50">
        <pendingQueuePolicy>
          <vmQueueCursor/>
        </pendingQueuePolicy>
      </policyEntry>
    </policyEntries>
  </policyMap>
</destinationPolicy>

주요 파라미터 설명

  • producerFlowControl: 프로듀서가 과도한 메시지 전송으로 시스템 부하를 초래하지 않도록 제어합니다.
  • memoryLimit: 각 큐 또는 토픽이 사용할 수 있는 최대 메모리 용량을 제한하여, 메모리 과부하를 방지합니다.
  • prefetch: 한 번에 소비자에게 전달되는 메시지 수를 제한해, 소비자가 안정적으로 처리할 수 있도록 돕습니다.
  • cursorMemoryHighWaterMark: 메모리 사용량의 임계치를 설정하여, 시스템 전체의 안정적인 운영을 유지합니다.

또한, storeUsage 설정을 통해 영속 메시지 저장소의 디스크 사용량을 관리할 수 있습니다. 아래는 기본적으로 설정되어 있는 storeUsage 관련 코드입니다.

<systemUsage>
  <systemUsage>
    ...
    <storeUsage>
      <storeUsage limit="100 gb"/>
    </storeUsage>
    ...
  </systemUsage>
</systemUsage>

storeUsage limit 튜닝의 주요 포인트

  • 디스크 사용량 관리: 영속 메시지 저장소의 디스크 사용 한도를 적절히 조정하여, 디스크 공간 부족으로 인한 장애를 예방할 수 있습니다.
  • 성능 최적화: 사용 환경에 따라 디스크 I/O 성능에 영향을 줄 수 있으므로, 필요한 경우 이 값을 상향 또는 하향 조정하여 최적의 성능을 유지합니다.
  • 모니터링: 디스크 사용량을 지속적으로 모니터링하고, 임계치 도달 시 알림을 설정하는 것이 좋습니다.

관련 자료: JVM 튜닝 기법

결론

ActiveMQ의 이중화 구성과 성능 튜닝은 단순히 안정성을 확보하는 것을 넘어, 사용자 증가에 따른 부하를 효율적으로 관리하는 핵심 전략입니다. 네트워크 클러스터링이나 Master-Slave 구성 등 구체적인 설정 방법을 통해 장애에 강한 시스템을 구축하고, 큐 및 토픽에 대한 세밀한 파라미터 튜닝과 storeUsage limit 조정을 통해 최적의 성능을 유지할 수 있습니다. 이러한 전략을 통해 급격한 사용자 증가 상황에서도 원활한 메시징 서비스를 제공하며, 향후 클라우드 환경에서도 유연하게 대응할 수 있을 것입니다.

참고자료

댓글남기기

참고

Apache 2.4의 MPM 주요설정값 초과시 메시지 예시

Apache 2.4는 MPM(Multi-Processing Module) 구조를 통해 여러 클라이언트 요청을 효율적으로 처리할 수 있도록 설계되어 있다. 하지만 MPM의 주요 설정값들이 현재 시스템 환경에 적절히 설정되지 않으면, 접속 지연, 연결 거부, 리소스 과다 사용 등의 문...

Apache 2.4의 MPM 종류 및 특징 소개

MPM은 Apache 웹서버가 클라이언트로부터 받은 요청을 처리하기 위해 자식 프로세스(child processes)에게 분배하는 방식을 결정하는 모듈입니다. Apache 2.0부터 도입된 이 기능은 웹서버의 가장 기본적인 부분까지 모듈화한 것으로, 서버가 시스템의 네트워크 포트에...

VSCode의 Copilot에서 MCP 활용 데모(유튜브영상요약)

개발자든 콘텐츠 크리에이터든 효율적인 작업 환경은 생산성에 직접적인 영향을 미칩니다. 지난번에 소개해드린 Claude For Desktop에서의 MCP(Model Context Protocol) 사용 사례에 이어, 이번에는 개발자들의 필수 도구인 VSCode와 GitHub Copi...