내용 목차
본 장에서는 JEUS MQ 서버의 부하를 줄이고 원활한 서비스를 위해서 여러 대의 서버를 하나로 묶어서 사용하는 클러스터링에 대해서 설명한다.
한 대의 JEUS MQ 서버에서 서비스되는 메시지가 너무 많거나 또는 서버를 이용하는 클라이언트의 접속이 많으면 네트워크의 부담이 가중된다. 이런 경우 JEUS MQ 서버를 증설하고 이 서버들 간의 관계를 설정해서 전체 MQ 서버들을 한 대의 서버처럼 동작하게 하는 것을 JEUS MQ 클러스터링이라고 한다.
이때 클라이언트는 자신이 접속하려는 JEUS MQ 서버가 클러스터링이 되어 있는지 여부와 상관없이 단일 서버를 이용할 때와 동일한 방법으로 접근할 수 있다.
JEUS MQ 클러스터링을 사용할 때에는 JEUS MQ 서버 간에 메시지의 이동이 발생한다. JMS 클라이언트는 클러스터 내의 어떤 서버라도 접속할 수 있기 때문에, 실제로 메시지가 존재하지 않는 서버에 연결될 수도 있다. 이런 경우 메시지를 수신하게 되면 메시지가 남아 있는 다른 서버로부터 메시지를 전달받아서 서비스한다. 이때 서버 간의 메시지 이동이 발생한다.
또한 Topic에 메시지를 전송하는 경우에는 해당 Topic에서 메시지를 구독하는 수신자는 클러스터 내의 모든 서버에 연결될 수 있으므로, 메시지가 전송되는 시점에 그 즉시 모든 서버로 전파해야 한다. 이때도 서버 간의 메시지 이동이 발생한다.
JEUS MQ 서버 간에 메시지 이동이 발생할 때, 메시지의 유실이나 중복 전달 방지를 위해서 여러 번 메시지를 주고받는다. 이런 메시지 이동이 자주 발생할 경우 오히려 네트워크에 부담이 될 수 있으므로 효율적으로 처리하기 위해서 한 번에 여러 개의 메시지를 이동시킨다. 기본값으로 5개의 메시지를 한 번에 이동시키도록 설정되어 있다.
만약 메시지들의 이동이 완료되지 않은 상태에서 한 쪽 서버가 다운된 경우 해당 메시지들은 일시적으로 서비스가 되지 않을 수 있다. 그 메시지들은 해당 서버가 다시 살아난 후에 정상적으로 서비스가 된다. 만약 JEUS MQ 장애 극복 기능과 함께 사용하고 있다면 다운된 서버의 Standby 서버가 메시지 이동 과정을 이어받아서 정상적으로 서비스를 재개한다.
1. 물리적 연결 공유나 Client Facility Pooling 기능을 사용할 경우 Connection Factory 클러스터링이 의도한 것과 같이 동작하지 않을 수도 있다. 필요한 경우 해당 옵션을 false로 설정하고 사용한다.
2. JEUS MQ 클러스터링을 사용하는 경우 JEUS MQ 서버에 Destination을 동적으로 추가하거나 삭제할 수 없다. 이 기능은 추후에 제공될 예정이다.
클러스터링은 Connection Factory 클러스터링과 Destination 클러스터링의 두 종류로 나누어진다.
두 대 이상의 JEUS MQ 서버를 구성했다면 클라이언트로부터 이들 서버로 접근하는 연결들을 적절하게 분산시켜 줄 필요가 있다. 클라이언트로부터 서버로의 연결은 Connection Factory를 통해서 이루어지므로 Connection Factory에서 이런 분산 기능을 지원해야 하고 이를 Connection Factory 클러스터링이라고 한다.
다음은 Connection Factory 클러스터링을 나타낸 그림이다.
Connection Factory 클러스터링에 의해서 클라이언트 연결이 적절하게 분산되더라도 클라이언트의 처리 속도 차이나 네트워크 환경에 따라서 클라이언트가 연결된 JEUS MQ 서버의 메시지가 모두 소모되어서 더 이상 받을 수가 없는 경우가 있다. 또한 서버에 메시지가 쌓이는 속도에 비해서 소모되는 양이 적다면 메시지가 계속해서 쌓이는 현상이 생길 수 있다.
이러한 상황에서는 남는 메시지를 메시지가 부족한 JEUS MQ 서버로 이동시켜서 서비스가 지속적으로 이루어지도록 할 필요가 있고 이런 기능을 Destination 클러스터링이라고 한다.
다음은 Destination 클러스터링을 나타낸 그림이다.
본 절에서는 JEUS MQ 클러스터링을 사용하기 위해서 필요한 설정들에 대해서 설명한다.
JEUS MQ 클러스터링을 사용하기 위해서 필요한 서버 설정은 <jms-server-cluster> 태그 아래에 설정한다.
[예 4.1] 클러스터링 사용 설정 : <<JMSMain.xml>>
<?xml version="1.0" encoding="UTF-8"?> <jms-server xmlns="http://www.tmaxsoft.com/xml/ns/jeus"> <broker-name>example-broker1</broker-name> . . . <jms-server-cluster> <jms-server-info> <broker-name>example-broker1</broker-name> <jms-server-info> <jms-server-info> <broker-name>example-broker2</broker-name> <jms-server-info> <failure-detection-retries>2</failure-detection-retries> <failure-detection-timeout>5000</failure-detection-timeout> <failure-detection-tcp-port>8000</failure-detection-tcp-port> <failure-detection-tcp-timeout>7000</failure-detection-tcp-timeout> <failure-verification-timeout>5000</failure-verification-timeout> <discovery-timeout>6000</discovery-timeout> </jms-server-cluster> </jms-server>
다음은 설정 태그에 대한 설명이다.
GMS 서비스
<jms-server-info> 이외의 요소는 GMS(Group Management Service) 서비스에 관한 설정이며 대부분의 경우 설정할 필요는 없다.
JEUS MQ 클러스터링은 클러스터를 구성한 JEUS MQ 서버들 간의 네트워크를 구성하기 위해서 JEUS GMS 프레임워크를 이용한다. 이 프레임워크는 JEUS MQ 서버들 간에 메시지를 주고받거나, 타 서버의 Health 상태를 모니터링하고 상태 변화를 통보하는 기능을 제공한다.
GMS에서는 상대방의 Health 상태를 파악하기 위해서 UDP 프로토콜을 사용하여 주기적으로 검사한다.
다음은 GMS 서비스 설정항목에 대한 설명이다.
태그 | 설명 |
---|---|
<failure-detection-retries> | 서버의 Health 상태 검사 중 이상이 발생했을 때 재시도 횟수를 설정한다. |
<failure-detection-timeout> | 상대방 서버의 Health 상태를 검사하는 주기를 설정한다. 또한 이 값은 자신의 Health 상태를 다른 서버들에게 전파하는 주기로도 동작한다. (단위: ms) |
GMS에서는 상대방의 Health 상태를 장애라고 확정하기 전에 별도로 TCP 연결을 하기위해 시도한다.
다음은 해당 설정에 대한 설명이다.
다음은 GMS에 대한 기타 설정들이다.
JEUS MQ 클러스터링에 참여하는 JEUS MQ 서버들의 Destination, Connection Factory, Durable Subscriber 설정들은 모두 동일해야 한다. 또한 JEUS MQ 클러스터링에 참여하는 JEUS MQ 서버에 설정된 위 정보는 자동으로 클러스터링에 참여하는 것으로 간주한다.
본 절에서는 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 서버를 선택하는 정책도 달라지게 된다.
매번 JNDI 서비스를 사용해서 새로운 Connection Factory를 얻어오는 경우는 JEUS MQ 서버를 선택하는 정책을 JNDI 서비스에 의존하게 된다. 이때는 JEUS 노드 클러스터링이 설정되어 있어야 한다.
이에 관한 내용과 JNDI 클러스터링을 사용한 클라이언트 프로그램 방법에 대해서는 “JEUS Server 안내서”의 “제1장 소개” 및 “JEUS Server 안내서”의 “제6장 JNDI Naming Server”를 참고한다.
이미 얻어온 Connection Factory를 재활용하여 커넥션 생성만 다시 하는 경우는 JEUS MQ 서버를 선택하는 정책을 설정할 수 있는데, 현재는 Round-robin 방식만 지원하고 있다.
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
); connectionFactoryCreator.addBrokerAddress("192.168.1.3
",9741
); connectionFactoryCreator.addBrokerAddress("192.168.1.4
",9741
); ConnectionFactory connectionFactory = (ConnectionFactory) connectionFactoryCreator.createConnectionFactory();
만약 JEUS MQ 클러스터링과 함께 JEUS MQ 장애 극복 기능을 사용하고 있다면 다음의 예와 같이 Standby 서버들의 정보도 추가해야 한다. 자세한 내용은 “제3장 JEUS MQ 장애 극복”을 참고한다.
jeus.jms.client.util.JeusConnectionFactoryCreator connectionFactoryCreator = new jeus.jms.client.util.JeusConnectionFactoryCreator(); connectionFactoryCreator.setFactoryName("ConnectionFactory
"); connectionFactoryCreator.addBrokerAddress("192.168.1.2
",9741
, "192.168.1.5
",9741
); connectionFactoryCreator.addBrokerAddress("192.168.1.3
",9741
, "192.168.1.6
",9741
); connectionFactoryCreator.addBrokerAddress("192.168.1.4
",9741
, "192.168.1.7
",9741
); ConnectionFactory connectionFactory = (ConnectionFactory) connectionFactoryCreator.createConnectionFactory();
JEUS MQ 클러스터링의 고급 옵션이나 JEUS MQ 장애 극복 기능과의 복합 사용에 대해서 설명한다.
다음의 3가지는 JEUS MQ 클러스터링의 고급 옵션에 대한 설명이다.
메시지 유무 확인 주기 설정
- Djeus.jms.server.cluster.demand-period
큐나 Durable Subscriber에서 메시지를 수신할 때 해당 JEUS MQ 서버에 메시지가 없을 경우 클러스터링된 다른 서버에 메시지가 있는지 확인하고 혹시 있다면 메시지를 요청해서 받아온다.
이때 메시지가 있는지 확인하는 주기를 설정할 수 있다. (기본값: 10000, 단위: ms)
한번에 이동시킬 메시지의 개수 설정
-Djeus.jms.server.cluster.messages-per-request
서버 간의 메시지를 이동할 때 한 번에 이동시키는 메시지의 수를 설정할 수 있다. (기본값: 5)
GMS 프레임워크에서 사용하는 멤버 그룹명 설정
-Djeus.jms.server.cluster.group-name
GMS 프레임워크에서 사용하는 멤버 그룹의 이름을 설정할 수 있다. 클러스터링이나 장애 극복 기능으로 묶이게 되는 서버들 간에는 모두 같은 그룹 이름을 사용해야 한다. 특별한 경우를 제외하고는 설정해 줄 필요는 없으나 같은 서브넷 내에서 여러 단위의 클러스터를 설정할 필요가 있다면 다른 클러스터 간에는 각자 다른 그룹 이름을 설정해 주어야 한다. (기본값: GMSCluster)
본 절에서는 JEUS MQ 클러스터링과 장애 극복 기능을 동시에 사용할 수 있으며 본 절에서 구성 및 설정 방법을 알아본다.
다음은 JEUS MQ 서버 A와 B는 클러스터링이 되어 있고, 동시에 C는 A의 Standby 서버, D는 B의 Standby 서버로 구성한 예이다.
Active 서버인 A와 Standby 서버인 C의 설정 예는 다음과 같다.
JEUS MQ 클러스터링과 JEUS MQ 장애 극복 기능을 동시에 사용하기 위한 설정을 하는 경우 <jms-server-info>에 Active 서버들의 브로커 이름만 설정해주면 된다. Standby 서버의 경우에도 장애 극복이 실제로 일어났을 때 클러스터링 서비스를 이어받기 위해서 Active 서버들의 브로커 이름만 설정해 주어야 한다.
[예 4.2] JEUS MQ 서버 "A" 설정: <<JMSMain.xml>>
<?xml version="1.0" encoding="UTF-8"?>
<jms-server xmlns="http://www.tmaxsoft.com/xml/ns/jeus">
<broker-name>A</broker-name>
. . .
<fail-over>
<active>
<listen-transport-url>gms</listen-transport-url>
</active>
</fail-over>
. . .
<jms-server-cluster>
<jms-server-info>
<broker-name>A</broker-name>
<jms-server-info>
<jms-server-info>
<broker-name>B</broker-name>
<jms-server-info>
. . .
. . .
</jms-server-cluster>
</jms-server>
[예 4.3] JEUS MQ 서버 "C" 설정 : <<JMSMain.xml>>
<?xml version="1.0" encoding="UTF-8"?>
<jms-server xmlns="http://www.tmaxsoft.com/xml/ns/jeus">
<broker-name>C</broker-name>
. . .
<fail-over>
<standby>
<active-transport-url>gms://A</active-transport-url>
</standby>
</fail-over>
. . .
<jms-server-cluster>
<jms-server-info>
<broker-name>A</broker-name>
<jms-server-info>
<jms-server-info>
<broker-name>B</broker-name>
<jms-server-info>
. . .
</jms-server-cluster>
</jms-server>
JEUS MQ 클러스터링의 예제에 대해 일반적인 사용 예와 잘못된 사용 예에 대하여 설명한다.
물품의 주문을 JEUS MQ를 통해서 처리하는 쇼핑몰을 가정해보자.
웹 페이지에서 생성된 주문은 메시지로 작성되어 JEUS MQ의 큐에 보관되고, 실제로 주문을 처리하는 비즈니스 서버에서 이 메시지를 꺼내 간다. 그리고 이 JEUS MQ들은 물론 클러스터링으로 구성한다.
비즈니스 서버는 각각 하나씩 대응하는 JEUS MQ 서버에서 메시지를 가져가고 주문 메시지는 각 JEUS MQ 서버들에 골고루 쌓인다고 하면 이 구조는 JEUS MQ 서버를 이상적으로 구성한 예가 된다. 만약 특정 비지니스 서버의 처리 속도가 빨라서 그에 대응하는 JEUS MQ 서버의 큐가 다른 곳보다 먼저 비워지면, 해당 JEUS MQ 서버는 Destination 클러스터링을 통해서 다른 JEUS MQ 서버로부터 메시지들을 받아와서 해당 비즈니스 서버에 메시지를 제공할 것이다.