메시지 구동 Bean을 클러스터에 연결하는 방법
엔터프라이즈 Bean(EJB) 애플리케이션이 애플리케이션 서버 클러스터에 배치될 때, 애플리케이션은 클러스터의 모든 서버에서 실행되어 애플리케이션의 고가용성 및 확장성을 제공할 수 있습니다. EJB 애플리케이션이 메시지 구동 Bean(MDB)일 때, 해당 프로그램은 클러스터의 모든 서버에서 실행될 수 있으며(고가용성 제공) 클러스터의 여러 애플리케이션 서버에서 동시에 호출될 수 있습니다(확장성 제공). 이 동작은 모든 서비스 통합 버스 멤버에 대한 MDB의 위치 및 MDB 자체의 구성에 따라 다릅니다.
기본적으로 MDB 애플리케이션이 서비스 통합 버스 클러스터 버스 멤버가기도 한 애플리케이션 서버 클러스터에 배치되면, MDB 애플리케이션이 클러스터 내의 서버에 있는 하나 이상의 메시징 엔진에 연결됩니다. 기본 연결 동작 및 메시지 구동 Bean을 포함하는 모든 JMS 애플리케이션에 적용할 수 있는 추가 연결 제어는 버스에서 JMS 애플리케이션이 메시징 엔진에 연결되는 방법에 설명되어 있습니다. 하지만 해당 주제에 설명된 구성 옵션을 사용하는 경우, 메시지 구동 Bean은 시작된 메시징 엔진을 호스트하는 클러스터의 해당 서버에서만 구동됩니다.
- 클러스터에서 처리 성능을 모두 사용하기 위해 클러스터의 모든 서버가 MDB 애플리케이션에서 메시지를 수신할 수 있습니다.
- 메시지의 순차적 처리를 보장하기 위해 한 번에 하나의 서버가 MDB 애플리케이션에서 메시지를 수신할 수 있습니다.
- MDB 연결 동작: 단일 클러스터 버스 멤버 내에서
- MDB 연결 동작: 클러스터와 개별 버스 멤버 간

MDB 연결 동작: 단일 클러스터 버스 멤버 내에서
- 메시지 구동 Bean은 시작된 메시징 엔진을 호스트하는 클러스터의 해당 서버에서만 구동됩니다.
이는 기본 옵션입니다. 메시지 구동 Bean이 클러스터 버스 멤버에 배치되면, 로컬로 시작된 메시징 엔진이 있는 서버의 MDB 엔드포인트만 사용 가능한 메시지에 의해 구동될 수 있습니다.
그림 2에서 클러스터 버스 멤버는 세 개의 서버를 포함합니다. server1 및 server2 각각에는 활성 및 장애 복구 메시징 엔진이 있습니다. 두 개의 서버 각각에서 실행 중인 MDB 엔드포인트는 각각 로컬 메시징 엔진에 연결됩니다. server3는 시작된 메시징 엔진을 호스트하지 않지만 두 개의 장애 복구 메시징 엔진은 호스트합니다. 활성 MDB 엔드포인트를 포함하지 않으며 메시지 이용에 적합하지 않습니다.
그림 2. MDB는 시작된 메시징 엔진을 호스트하는 클러스터 버스 멤버에 있는 서버에 의해 구동됩니다(setup 1).메시징 엔진이 클러스터의 서버 사이에서 장애 복구될 수 있는 경우, 이 구성은 MDB 애플리케이션의 고가용성 및 버스 대상에 관한 메시지를 제공합니다.
그림 3에서 이전 그림과 동일한 클러스터 버스 멤버가 표시됩니다. server1의 메시징 엔진이 server2로 장애 복구되었습니다. 결과적으로 server2에 이제 두 개의 활성 메시징 엔진이 포함되어 있고, server2에서 실행되는 MDB 엔드포인트는 이제 로컬 메시징 엔진 둘 다에 연결됩니다. 시작된 메시징 엔진을 호스트하지 않는 세 번째 서버는 활성 MDB 엔드포인트를 포함하지 않으며 메시지 이용에 적합하지 않습니다.
그림 3. MDB는 시작된 메시징 엔진을 호스트하는 클러스터 버스 멤버에 있는 서버에 의해 구동됩니다(setup 2).활성화 스펙에서 모든 서버에서 항상 MDB 활성화 옵션을 선택하지 않으면 이 구성이 사용 가능합니다.
- 클러스터 버스 멤버의 모든 서버는 메시지 구동 Bean에서 메시지를 수신할 수 있습니다.
시작된 로컬 메시징 엔진의 유무에 관계없이 메시지로 구동할 수 있는 모든 클러스터 서버의 MDB 엔드포인트를 설정할 수 있습니다. 시작된 메시징 엔진이 없는 서버의 모든 MDB 엔드포인트는 클러스터의 다른 서버 중 하나에 있는 메시징 엔진 중 하나에 직접 연결됩니다. 이렇게 하면 클러스터의 사용 가능한 모든 자원을 대상으로 전송된 메시지를 처리하는 데 사용할 수 있습니다.
그림 4에서 클러스터 버스 멤버는 세 개의 서버를 포함합니다. 두 개의 서버에는 활성 메시징 엔진이 포함됩니다. 두 서버 각각의 MDB 엔드포인트는 각각 로컬 메시징 엔진에 연결됩니다. 시작된 메시징 엔진을 호스트하지 않는 세 번째 서버에서는 클러스터에 있는 사용 가능한 메시징 엔진의 워크로드 밸런스가 조정됩니다. 세 번째 서버의 MDB 엔드포인트는 다른 두 서버 중 하나에서 실행 중인 메시징 엔진에 연결되어 있습니다.
그림 4. 클러스터 버스 멤버의 서버가 메시지 구동 Bean에서 메시지를 수신함이 구성을 선택하기 위해 활성화 스펙에서 모든 서버에서 항상 MDB 활성화 옵션을 선택합니다.
참고: 이 구성으로 클러스터의 모든 서버는 클러스터 버스 멤버의 메시징 엔진에서 메시지를 수신할 수 있습니다. 구성과 동일한 효과(MDB 엔드포인트가 구동된 측면으로)를 얻을 수 있습니다(이 주제에도 설명됨).
MDB 연결 동작: 클러스터와 개별 버스 멤버 간
- 클러스터의 모든 서버는 클러스터 버스 멤버의 메시징 엔진에서 메시지를 수신할 수 있습니다.
MDB 애플리케이션을 버스 멤버가 아닌 클러스터에 배치하는 경우, MDB는 버스에서 JMS 애플리케이션이 메시징 엔진에 연결되는 방법에 설명된 연결 규칙을 따라 클러스터의 모든 애플리케이션 서버에서 버스 연결을 시도합니다. 이는 일반적으로 버스 멤버의 활성 메시징 엔진에서 동시에 메시지로 구동 중인 클러스터에 있는 모든 MDB 엔드포인트가 연결됩니다. 이렇게 하면 클러스터의 사용 가능한 모든 자원을 클러스터 버스 멤버의 대상으로 전송된 메시지를 처리하는 데 사용할 수 있습니다.
그림 5에서 클러스터는 세 개의 서버를 포함하며, 각 서버에는 MDB 엔드포인트가 있습니다. 클러스터 버스 멤버는 두 개의 서버를 포함하며, 두 서버 중 하나가 활성 메시징 엔진을 호스트합니다. 클러스터에 있는 세 개의 각 MDB 엔드포인트는 클러스터 버스 멤버의 활성 메시징 엔진에 연결됩니다.
참고: 이 구성에서는 연결이 모든 메시징 엔진에 적용되지 않을 수 있으므로 연결이 없는 메시징 엔진이 있을 수 있으며 경보용 메시지로 표시될 수 있습니다. 이러한 상황은 MDB에서 사용하는 활성화 스펙이 서버 범위에 설정된 경우에는 거의 발생하지 않습니다.그림 5. 클러스터의 모든 서버가 클러스터 버스 멤버의 메시징 엔진에서 메시지를 수신함참고: 이 구성으로 클러스터 버스 멤버의 모든 서버는 메시지 구동 Bean에서 메시지를 수신할 수 있습니다. 구성과 동일한 효과(MDB 엔드포인트가 구동된 측면으로)를 얻을 수 있습니다(이 주제에도 설명됨).- 클러스터에 있는 단 하나의 서버만이 클러스터 버스 멤버의 메시징 엔진에서 메시지를 수신할 수 있습니다.
한 번에 하나의 서버로 대상의 메시지를 순차적으로 처리하도록 하려면, 단 하나의 MDB 엔드포인트가 한 번에 메시지로 구동되도록 구성하십시오. server1이 중지하는 경우, 이 패턴에서 기타 MDB 엔드포인트 및 메시징 엔진은 메시지 처리를 효과적으로 대기할 준비가 되어 있습니다.
그림 6에서 클러스터는 세 개의 서버를 포함하며, 각 서버에는 MDB 엔드포인트가 있습니다. 또한 클러스터 버스 멤버는 두 개의 서버도 포함하며, 두 서버 중 하나에 활성 메시징 엔진이 있습니다. 클러스터에 있는 세 개의 MDB 엔드포인트 중 하나만 클러스터 버스 멤버에서 실행 중인 활성 메시징 엔진에 연결되어 있습니다.
그림 6. 클러스터 버스 멤버의 메시징 엔진으로부터 메시지를 수신하는 서버이 구성을 선택하기 위해 모든 비 버스 클러스터 서버의 MDB 엔드포인트가 클러스터 버스 멤버의 메시징 엔진에서 메시지로 구동하고 클러스터 버스 멤버의 대상에서 수신 독점 옵션을 설정할 수 있도록 활성화 스펙을 구성합니다. MDB 엔드포인트 중 하나가 메시징 엔진에 연결되면, 엔진이 사용 가능한 기타 모든 MDB 엔드포인트의 연결을 중지시키고 동일한 MDB 엔드포인트를 통해 메시지를 계속 처리합니다.
MDB로 메시지 연속 처리를 수행하려면 추가 구성이 필요할 수 있습니다. 대상에서의 메시지 연속 처리에 대한 자세한 정보는 메시지 정렬를 참조하십시오.