두 대 이상의 JEUS MQ 서버를 구성했다면 클라이언트로부터 이들 서버에 접근하는 연결들을 분산시킬 필요가 있다. 클라이언트로부터 서버로의 연결은 Connection Factory를 통해서 이루어지므로 Connection Factory에서 이런 분산 기능을 지원해야 한다. 이를 Connection Factory 클러스터링이라고 한다.

Connection Factory로부터 Connection을 생성할 때 매 연결마다 서로 다른 서버로 연결하게 되며 매번 다른 서버를 선택하기 위한 정책(Policy)을 설정할 수 있는데 현재는 Round-robin 방식만을 지원하고 있다.

다음은 Connection Factory 클러스터링을 간략하게 나타낸 그림이다.

Connection Factory 클러스터링에 의해서 클라이언트 연결이 적절하게 분산되더라도 클라이언트의 처리 속도 차이나 네트워크 환경에 따라서 클라이언트가 연결된 JEUS MQ 서버의 메시지가 모두 소모되어서 더 이상 받을 수 없는 경우가 있다. 또한 서버에 메시지가 쌓이는 속도에 비해서 소모되는 양이 적다면 메시지가 계속해서 쌓이는 현상이 발생할 수 있다.

이러한 상황에서는 남는 메시지를 메시지가 부족한 JEUS MQ 서버로 이동시켜서 서비스가 지속적으로 이루어지도록 해야한다. 이런 기능을 Destination 클러스터링이라고 한다.

다음은 Destination 클러스터링을 나타낸 그림이다.

JEUS MQ 클러스터링의 전체적인 구성은 JEUS 서버의 클러스터링에 따른다. JEUS 서버 클러스터링에 관한 설명은 “JEUS Domain 안내서”의 “제5장 JEUS 클러스터링”을 참고한다.

JEUS MQ 클러스터링 설정 주의 사항

JEUS MQ 클러스터링에 참여하는 JEUS MQ 서버들의 Destination, Durable Subscriber 설정들은 WebAdmin의 [Clusters] 메뉴에서 설정하여 그에 포함된 각 서버들에 동일하게 적용되며, 서버마다 주소가 다르기 때문에 별도로 설정해야 하는 Connection Factory는 WebAdmin의 [Servers] 메뉴에서 설정한다. 단, 이 경우도 이름은 동일하게 설정해야 한다.

클러스터에 Destination이나 Durable Subscriber를 설정하기위해 [Clusters] > [클러스터 명] > [Engine] 탭의 [Jms Engine]를 선택하면, 다음과 같은 설정화면이 나타난다. 각각의 Destination이나 Durable Subscriber를 설정하는 방법은 서버상에 설정하는 것과 동일하므로 “3.2. JMS 리소스 설정”의 설명을 참고한다.

본 절에서는 JEUS MQ 클러스터링을 사용하려면 클라이언트에서 고려해야 하는 사항들이 존재한다. 클라이언트에서 JEUS MQ 클러스터링을 이용하기 위해서 제일 먼저 설정하는 것이 Connection Factory이기 때문에 주로 이에 관해서 설명한다.

JEUS MQ의 Connection Factory 클러스터링은 클라이언트가 Connection Factory를 얻어오는 방법에 따라서 다음과 같이 2가지로 구분할 수 있다.

JNDI 서비스를 이용하는 방법

JEUS MQ 서버의 클러스터링 여부와 상관없이 “2.2.2. Connection Factory”에서 설명한 것과 같은 방법으로 사용할 수 있다. 단, 클라이언트가 매번 JNDI 서비스를 사용해서 Connection Factory를 다시 Lookup하는지 또는 이미 얻어온 Connection Factory를 재활용해서 커넥션만 다시 생성하는지에 따라서 동작의 주체가 다르다.

또한 동작의 주체에 따라서 JEUS MQ 서버를 선택하는 정책도 달라진다.

JEUS MQ 전용 API를 사용하는 방법

JEUS MQ 전용 API를 사용하여 Connection Factory를 직접 생성하는 경우에는 JEUS MQ 서버가 클러스터링되어 있다면 “2.2.2. Connection Factory”에서 설명한 방법에 외에 추가적인 작업이 필요하다.

다음과 같이 JeusConnectionFactoryCreator.addBrokerAddress() 메소드를 이용하여 클러스터링에 참여하고 있는 모든 서버들의 정보를 추가해야 한다.

jeus.jms.client.util.JeusConnectionFactoryCreator connectionFactoryCreator =
new jeus.jms.client.util.JeusConnectionFactoryCreator();

connectionFactoryCreator.setFactoryName("ConnectionFactory");
connectionFactoryCreator.addBrokerAddress("192.168.1.2", 9741, <service-name>);
connectionFactoryCreator.addBrokerAddress("192.168.1.3", 9741, <service-name>);
connectionFactoryCreator.addBrokerAddress("192.168.1.4", 9741, <service-name>);

ConnectionFactory connectionFactory = connectionFactoryCreator.createConnectionFactory();

물품의 주문을 JEUS MQ를 통해서 처리하는 쇼핑몰을 가정해보자.

웹 페이지에서 생성된 주문은 메시지로 작성되어 클러스터링으로 구성된 JEUS MQ의 큐에 보관되고, 실제로 주문을 처리하는 비즈니스 서버에서 이 메시지를 가져간다. 그리고 이 JEUS MQ들은 물론 클러스터링으로 구성한다.

비즈니스 서버는 각각 하나씩 대응하는 JEUS MQ 서버에서 메시지를 가져가고 주문 메시지는 각 JEUS MQ 서버들에 골고루 쌓인다면 이 구조는 JEUS MQ 서버를 이상적으로 구성한 예가 된다. 만약 특정 비즈니스 서버의 처리 속도가 빨라서 그에 대응하는 JEUS MQ 서버의 큐가 다른 곳보다 먼저 비워지면, 해당 JEUS MQ 서버는 Destination 클러스터링을 통해서 다른 JEUS MQ 서버로부터 메시지들을 받아와서 해당 비즈니스 서버에 메시지를 제공할 것이다.

JEUS MQ 클러스터링의 구성 방법은 매우 다양하지만, 다음과 같은 구조로 사용하는 것은 오히려 효율을 떨어뜨릴 수 있다.

JEUS MQ 클러스터링을 구성하긴 했으나 사용하는 JMS 클라이언트가 한 번 연결한 커넥션을 계속 재활용하면 커넥션의 부하 분산이 제대로 동작하지 않고 JEUS MQ 서버 간에 불필요한 메시지 이동이 일어나게 되어 효율을 크게 저하시킬 수 있다.