2장 Message Queue 메시징 시스템

이 장에서는 그림 2-1에 나와 있는 시스템의 주요 부분에 중점을 두고 Sun Java^™ System Message Queue 메시징 시스템에 대해 소개합니다. 또한 각 부분이 어떻게 상호 작용하면서 안정적인 메시지 전달을 제공하는지 설명합니다.

그림 2-1에서 보여주는 Message Queue 메시징 시스템의 주요 부분은 다음과 같습니다.

Message Queue 메시지 서버

이 절에서는 그림 2-1에서 보여주는 Message Queue 메시지 서버의 다양한 부분을 설명합니다. 여기에는 다음 항목이 포함됩니다.

브로커 Message Queue 브로커는 Message Queue 메시징 시스템을 위해 전달 서비스를 제공합니다. 메시지 전달은 연결 서비스, 메시지 라우팅 및 전달, 지속성, 보안 및 로깅을 처리하는 수많은 지원 구성 요소에 따라 달라집니다(자세한 정보는 "브로커" 참조). 메시지 서버는 하나 이상의 브로커 인스턴스를 사용할 수 있습니다("멀티 브로커 클러스터(엔터프라이즈판)" 참조).

물리적 대상 메시지 전달은 생성자 클라이언트에서 브로커가 관리하는 물리적 대상으로의 전달 그리고 대상에서 하나 이상의 사용자 클라이언트로의 전달의 2단계로 구성되는 과정입니다. 물리적 대상은 브로커의 물리적 메모리 및/또는 영구 저장소에서의 위치를 나타냅니다(자세한 정보는 "물리적 대상" 참조).

브로커

Message Queue 메시징 시스템의 메시지 전달은 브로커(또는 탠덤으로 작동하는 브로커 인스턴스로 구성된 클러스터)가 수행합니다. 메시지는 생성자 클라이언트에서 대상으로 전달된 다음 대상에서 하나 이상의 사용자 클라이언트로 전달됩니다. 메시지 전달을 수행하려면 브로커가 클라이언트와 통신 채널을 설정하고, 인증 및 권한 부여를 수행하며, 메시지 경로를 올바르게 지정하고, 안정적인 전달을 보장하며, 시스템 성능을 모니터링할 데이터를 제공해야 합니다.

이렇게 복잡한 기능들을 수행하기 위해 브로커는 각각의 전달 과정에서 특별한 역할을 맡는 다양한 내부 구성 요소를 사용합니다. 주요 브로커 구성 요소는 그림 2-2에서 확인할 수 있으며, 표 2-1에서도 간략히 설명합니다. 메시지 라우터 구성 요소가 주요 메시지 라우팅 및 전달 서비스를 수행하고 다른 구성 요소는 메시지 라우터가 종속되는 중요한 지원 서비스를 제공합니다.

표 2-1 주요 브로커 구성 요소 및 기능
구성 요소	설명/기능
메시지 라우터	메시지의 라우팅 및 전달을 관리합니다. 여기에는 JMS 메시지를 비롯하여 Message Queue 메시징 시스템이 JMS 메시지 전달을 지원하기 위해 사용하는 제어 메시지도 포함됩니다.
연결 서비스	브로커와 클라이언트 사이의 물리적 연결을 관리하면서 받고 보내는 메시지 전송을 담당합니다.
지속성 관리자	영구 저장소에 대한 데이터 쓰기를 관리하여 시스템 오류로 인해 JMS 메시지 전달 오류가 발생하지 않게 합니다.
보안 관리자	브로커와의 연결을 요청하는 사용자에게 인증 서비스를 제공하고 인증된 사용자에게 권한 부여 서비스(액세스 제어)를 제공합니다.
모니터링 서비스	관리자가 브로커를 모니터링 및 관리할 때 사용할 수 있는 다양한 출력 채널에 기록 가능한 메트릭 및 진단 정보를 생성합니다.

로드 상태, 응용 프로그램 복잡성 등에 따라 브로커 성능을 최적화하도록 이 내부 구성 요소들을 구성할 수 있습니다. 다음 절에서는 다양한 구성 요소가 수행하는 기능 및 그 동작에 영향을 주도록 구성 가능한 등록 정보를 더 자세히 살펴 봅니다.

연결 서비스

Message Queue 브로커는 Message Queue 응용 프로그램 클라이언트와 Message Queue 관리 클라이언트와의 통신을 모두 지원합니다("Message Queue 관리 도구" 참조). 각 서비스는 서비스 유형 및 프로토콜 유형을 통해 지정됩니다.

서비스 유형 서비스가 JMS 메시지 전달(NORMAL)을 제공하는지 또는 Message Queue 관리(ADMIN) 서비스를 제공하는지 지정합니다.

프로토콜 유형 서비스를 지원하는 기본 전송 프로토콜 계층을 지정합니다.

현재 Message Queue 브로커에서 사용 가능한 연결 서비스는 표 2-2에서 확인할 수 있습니다.

표 2-2 브로커가 지원하는 연결 서비스
서비스 이름	서비스 유형	프로토콜 유형
jms	NORMAL	tcp
ssljms (엔터프라이즈판)	NORMAL	tls (SSL 기반 보안)
httpjms (엔터프라이즈판)	NORMAL	http
httpsjms (엔터프라이즈판)	NORMAL	https (SSL 기반 보안)
admin	ADMIN	tcp
ssladmin (엔터프라이즈판)	ADMIN	tls (SSL 기반 보안)

이 연결 서비스 중 어느 것이라도 또는 전부 실행하도록 브로커를 구성할 수 있습니다. 각 연결 서비스는 특정 포트에서 사용 가능하며, 브로커의 호스트 이름과 포트 번호로 지정됩니다. 포트는 동적으로 할당될 수도 있고 사용자가 연결 서비스에 사용 가능한 포트를 직접 지정할 수도 있습니다.

그림 2-3에 표시된 것처럼 각 서비스는 공통 포트 매퍼에 등록되지만 자체 스레드 풀 관리자도 있습니다.

포트 매퍼

Message Queue는 포트를 여러 연결 서비스에 매핑하는 포트 매퍼를 제공합니다. 포트 매퍼 자체는 표준 포트 번호 7676에 위치합니다. 클라이언트가 브로커와 연결을 설정할 때 이 클라이언트는 먼저 포트 매퍼에 접속하여 원하는 연결 서비스의 포트 번호를 요청합니다.

jms, ssljms, admin 및 ssladmin 연결 서비스를 구성할 때 정적 포트 번호를 할당할 수도 있지만 이런 구성은 특수한 상황(예: 방화벽을 통한 연결)에서만 수행되고 일반적으로는 사용하지 않는 것이 좋습니다. httpjms 및 httpsjms 서비스는 각각 부록 C, "HTTP/HTTPS 지원(엔터프라이즈판)"에서 표 C-1과 표 C-3에서 설명되어 있는 등록 정보를 사용하여 구성합니다.

스레드 풀 관리자

각 연결 서비스는 다중 스레드 방식으로서, 다중 연결을 지원합니다. 이 연결에 필요한 스레드는 스레드 풀 관리자 구성 요소가 관리하는 스레드 풀에서 유지 관리됩니다. 스레드 풀 관리자를 구성하여 스레드 풀에서 유지 관리되는 최소 스레드 수와 최대 스레드 수를 설정할 수 있습니다. 연결 시 스레드가 필요하면 스레드 풀에 해당 스레드가 추가됩니다. 최소 수를 초과할 경우, 시스템은 최소 수 임계값에 도달할 때까지 스레드를 종료시켜 여유 스레드를 확보하는 방법으로 메모리 자원을 절약합니다. 새 스레드가 계속 작성될 필요가 없도록 이 값을 충분히 크게 설정할 수 있습니다. 연결 로드가 많은 경우, 스레드 풀의 최대 수에 도달할 때까지 스레드 수가 증가하기도 합니다. 그 후 스레드가 사용 가능해질 때까지 연결은 대기합니다.

스레드 풀의 스레드는 단일 연결 전용으로 사용되거나(전용 모델) 필요에 따라 여러 연결에 지정될 수 있습니다(공유 모델).

전용 모델 브로커와의 연결마다 연결에서 받는 메시지 처리 전용과 보내는 메시지 처리 전용의 2개의 전용 스레드가 필요합니다. 따라서 연결 수가 스레드 풀에 있는 최대 스레드 수의 절반으로 제한되지만, 이 방법은 우수한 성능을 제공합니다.

공유 모델(엔터프라이즈판) 메시지를 보내거나 받을 때마다 공유 스레드에서 연결을 처리합니다. 이 모델에서는 각 연결에 전용 스레드가 필요하지 않기 때문에 연결 서비스(및 브로커)가 지원할 수 있는 연결 수가 증가합니다. 그러나 스레드 공유와 관련된 어느 정도의 성능 오버헤드가 있습니다. 스레드 풀 관리자는 연결 활동을 모니터링하고 필요에 따라 스레드에 연결을 지정하는 분산자 스레드 집합을 사용합니다. 이러한 각 분산자 스레드가 모니터하는 연결 수를 제한하여 이 활동과 관련된 성능 오버헤드를 최소화할 수 있습니다.

보안

각 연결 서비스는 특정 인증 및 권한 부여(액세스 제어) 기능을 지원합니다("보안 관리자" 참조).

연결 서비스 등록 정보

연결 서비스와 관련하여 구성 가능한 등록 정보는 표 2-3에서 확인할 수 있습니다(등록 정보 구성 지침은 5장, "브로커 시작 및 구성" 참조).

표 2-3 연결 서비스 등록 정보
등록 정보 이름	설명
imq.service.activelist	브로커 시작 시 활성화되는 쉼표로 구분된 이름별 연결 서비스 목록입니다. 지원되는 서비스: jms, ssljms, httpjms, httpsjms, admin, ssladmin. 기본값: jms, admin
imq.ping.interval	브로커가 연결을 통해 Message Queue 클라이언트 런타임을 연속적으로 핑하는 시도 사이의 간격입니다. 기본값: 120초
imq.hostname	사용 가능한 호스트가 두 개 이상 있는 경우(예: 컴퓨터에 네트워크 인터페이스 카드가 두 개 이상인 경우) 모든 연결 서비스를 바인드할 호스트(호스트 이름 또는 IP 주소)를 지정합니다. 기본값: 사용 가능한 모든 IP 주소
imq.portmapper.port	브로커의 기본 포트(포트 매퍼가 위치한 포트)를 지정합니다. 한 호스트에서 둘 이상의 브로커 인스턴스를 실행하는 경우 각 인스턴스는 고유한 포트 매퍼 포트를 지정 받아야 합니다. 기본값: 7676
imq.portmapper.hostname	사용 가능한 호스트가 두 개 이상 있는 경우(예: 컴퓨터에 네트워크 인터페이스 카드가 두 개 이상인 경우) 포트 매퍼를 바인드할 호스트(호스트 이름 또는 IP 주소)를 지정합니다. 기본값: imq.hostname의 값을 상속합니다.
imq.portmapper.backlog	포트 매퍼가 요청 거부 전까지 처리할 수 있는 최대 동시 요청 수를 지정합니다. 이 등록 정보는 운영 체제 백로그에 저장되어 포트 매퍼의 처리를 대기할 수 있는 요청 수를 설정합니다. 기본값: 50
imq.service_name. protocol_type¹.port	jms, ssljms, admin 및 ssladmin 서비스에 한해 명명된 연결 서비스의 포트 번호를 지정합니다. 기본값: 0 (포트 매퍼가 동적으로 포트를 할당) httpjms 및 httpsjms 연결 서비스를 구성하려면 부록 C, "HTTP/HTTPS 지원(엔터프라이즈판)"을 참조하십시오.
imq.service_name. protocol_type¹.hostname	jms, ssljms, admin 및 ssladmin 서비스에 한해, 사용 가능한 호스트가 두 개 이상 있는 경우(예: 컴퓨터에 네트워크 인터페이스 카드가 두 개 이상인 경우) 명명된 연결 서비스를 바인드할 호스트(호스트 이름 또는 IP 주소)를 지정합니다. 기본값: imq.hostname의 값을 상속합니다.
imq.service_name. min_threads	이 스레드 수에 도달하면 명명된 연결 서비스가 사용할 수 있도록 스레드 풀에서 스레드가 유지 관리됩니다. 기본값: 연결 서비스에 따라 다릅니다(표 5-1 참조).
imq.service_name. max_threads	이 스레드 수를 초과하면 명명된 연결 서비스가 사용할 수 있는 신규 스레드가 더 이상 스레드 풀에 추가되지 않습니다. 이 수는 0보다 크고 min_threads 값보다 커야 합니다. 기본값: 연결 서비스에 따라 다릅니다(표 5-1 참조).
imq.service_name. threadpool_model	명명된 연결 서비스에 대해 스레드가 연결 전용인지(전용) 또는 필요에 따라 여러 연결에 의해 공유되는지(공유)를 지정합니다. 공유 모델(스레드 풀 관리)은 브로커가 지원하는 연결 수를 늘리지만, jms 및 admin 연결 서비스에 대해서만 구현됩니다. 기본값: 연결 서비스에 따라 다릅니다(표 5-1 참조).
imq.shared. connectionMonitor_limit	공유 스레드 풀 모델에 한해 분산자 스레드가 모니터링할 수 있는 최대 연결 수를 지정합니다(시스템은 모든 연결을 모니터링하기에 충분한 수의 분산자 스레드를 할당). 이 값이 작을수록 시스템은 더 신속하게 스레드에 활성 연결을 지정할 수 있습니다. 값 -1은 제한이 없음을 의미합니다. 기본값: 운영 체제에 따라 다릅니다(표 5-1 참조).

1protocol_type은 표 2-2에 지정되어 있습니다.

메시지 라우터

지원되는 연결 서비스를 사용하여 클라이언트와 브로커 사이에 연결이 설정되면 라우팅 및 메시지 전달을 할 수 있습니다.

기본적인 전달 메커니즘

포괄적으로 말하자면, 브로커가 처리하는 메시지는 생성자 클라이언트가 사용자 클라이언트를 대상으로 보내는 페이로드 메시지인 JMS 메시지 그리고 JMS 메시지 전달을 지원하고자 클라이언트를 오가는 수많은 제어 메시지의 2가지 범주로 구분됩니다.

받는 메시지가 JMS 메시지인 경우 브로커는 대상 유형(대기열 또는 주제)에 따라 사용자 클라이언트로 경로를 지정합니다.

메시지 라우터가 목표한 모든 사용자에게 메시지를 전달했다면 메시지 라우터는 메모리에서 해당 메시지를 삭제합니다. 지속성 메시지인 경우("안정적인 메시징" 참조) 브로커의 영구 데이터 저장소에서 해당 메시지를 제거합니다.

안정적인 전달: 확인 및 트랜잭션

지금까지 설명한 전달 메커니즘은 안정적인 전달("안정적인 메시징" 참조)을 위한 요구 사항이 추가될 경우 더 복잡해집니다. 안정적인 전달에는 브로커를 오가는 메시지 전달이 성공적으로 이루어지게 하고 실제 메시지 전달 이전에 브로커가 메시지나 전달 정보를 잃어버리지 않게 하는 2가지 측면이 있습니다.

브로커를 오가는 메시지가 성공적으로 전달되도록 하기 위해 Message Queue는 확인이라고 하는 다양한 제어 메시지를 사용합니다.

예를 들어, 생성자가 어떤 대상으로 JMS 메시지(제어 메시지와 반대되는 페이로드 메시지)를 보낼 때 브로커는 JMS 메시지 수신을 확인하는 제어 메시지인 브로커 확인을 회신합니다(기본적으로 생성자가 JMS 메시지를 지속성 메시지로 지정한 경우에만 Message Queue가 이 기능을 수행함). 생성자 클라이언트는 브로커 확인을 통해 대상에게 확실히 전달되도록 합니다("메시지 생성" 참조).

그와 비슷하게 브로커가 사용자에게 JMS 메시지를 전달할 경우, 사용자 클라이언트는 해당 메시지를 수신 및 처리했음을 알리는 확인을 회신합니다. 클라이언트는 세션 객체 작성 시 이 확인을 얼마나 자동으로 또는 얼마나 자주 보낼 것인지 지정하지만, 원칙상 메시지 라우터는 자신이 메시지를 전달했던 각 메시지 사용자로부터 확인을 받지 않은 경우(예: 여러 가입자 각각으로부터 한 주제로) 해당 JMS 메시지를 메모리에서 삭제하지 않습니다.

어떤 주제에 대한 영구 가입자의 경우, 메시지 라우터는 각 JMS 메시지를 대상에 보존하고 각 영구 가입자가 활성 사용자가 되면 메시지를 전달합니다. 메시지 라우터는 클라이언트 확인을 수신하여 이를 기록하고, (그 전까지 JMS 메시지가 만료되지 않는 한) 모든 확인을 수신한 후에야 JMS 메시지를 삭제합니다.

또한 메시지 라우터는 클라이언트에게 브로커 확인을 회신함으로써 클라이언트 확인을 받았음을 알립니다. 사용자 클라이언트는 브로커 확인을 통해 브로커가 JMS 메시지를 2회 이상 전달하지 않도록 합니다("메시지 사용" 참조). 이는 어떤 이유로 브로커가 클라이언트 확인을 받지 못한 경우에 발생할 수 있습니다.

브로커가 클라이언트 확인을 받지 않고 JMS 메시지를 두 번째 전달하는 경우, 메시지에 재전송 플래그가 표시됩니다. 일반적으로 브로커가 클라이언트 확인을 받기 전에 클라이언트 연결이 닫히고 이어서 새 연결이 열리면 브로커는 JMS 메시지를 재전송합니다. 예를 들어 메시지 확인을 받기 전에 대기열의 메시지 사용자가 오프라인되고 이어서 다른 사용자가 해당 대기열에 등록하면 브로커는 미확인된 메시지를 새 사용자에게 재전송합니다.

위에서 설명한 클라이언트와 브로커 확인 과정은 JMS 메시지 전달이 트랜잭션으로 그룹화된 경우에도 적용됩니다. 이 경우 클라이언트와 브로커 확인은 개별 JMS 메시지 송수신 수준뿐 아니라 트랜잭션 수준에서도 수행됩니다. 트랜잭션이 완결되면 브로커 확인이 자동으로 보내집니다.

브로커는 트랜잭션을 추적하면서 트랜잭션 완결 또는 실패 시 롤백이 가능하게 합니다. 또한 이 트랜잭션 관리는 더 큰 규모의 분산 트랜잭션에 포함되는 로컬 트랜잭션을 지원합니다("분산 트랜잭션" 참조). 브로커는 트랜잭션이 완결될 때까지 그 상태를 추적합니다. 브로커가 시작되면 이 브로커는 아직 완결되지 않은 모든 트랜잭션을 검사하며, PREPARED 상태의 트랜잭션을 제외하고 모든 트랜잭션을 롤백하도록 기본 설정되어 있습니다.

안정적인 전달: 지속성

안정적인 전달의 또 다른 측면은 실제로 메시지가 전달될 때까지 브로커가 메시지나 전달 정보를 잃어버리지 않게 하는 것입니다. 일반적으로 메시지는 전달되거나 만료될 때까지 메모리에 남아 있습니다. 그러나 브로커에 오류가 발생할 경우 이 메시지는 손실됩니다.

생성자 클라이언트는 메시지가 지속성을 갖도록 지정할 수 있으며, 이 경우 메시지 라우터는 데이터베이스나 파일 시스템에 메시지를 저장하는 지속성 관리자에게 메시지를 전달하여("지속성 관리자" 참조) 브로커 오류 발생 시 메시지가 복구될 수 있게 합니다.

메모리 자원 및 메시지 흐름 관리

브로커의 성능과 안정성은 사용 가능한 시스템 자원 그리고 메모리와 같은 자원이 얼마나 효율적으로 활용되는가에 따라 달라집니다. 특히 메시지의 생성이 사용보다 훨씬 빠를 경우 메시지 라우터가 넘치게 되어 모든 메모리 자원을 소진할 수 있습니다. 이런 현상을 방지하기 위해 메시지 라우터는 자원이 부족해질 경우 다음과 같은 세 가지 메모리 보호 수준을 사용하여 시스템을 운영합니다.

개별 대상에 대한 메시지 제한 물리적 대상에서 메시지 수와 메시지가 사용하는 총 메모리를 제한하는 속성을 설정할 수 있고(표 6-10 참조), 이러한 제한에 도달할 경우 메시지 라우터가 수행하는 네 가지 응답을 지정할 수도 있습니다. 네 가지 제한 동작은 다음과 같습니다.

시스템 전체 메시지 제한 시스템 전체 메시지 제한은 두 번째 보호 집합을 구성합니다. 총 메시지 수, 모든 메시지가 사용하는 메모리 등과 같이 시스템의 모든 대상에 한꺼번에 적용되는 시스템 전체 제한을 지정할 수 있습니다(표 2-4 참조). 시스템 전체 메시지 제한에 도달하면 메시지 라우터는 새 메시지를 거부합니다.

시스템 메모리 임계값 시스템 메모리 임계값은 세 번째 보호 집합입니다. 브로커가 메모리 과부하 방지를 위한 조치의 수위를 점점 더 높이게 되는 사용 가능한 시스템 메모리의 임계값을 지정할 수 있습니다.

조치는 메모리 자원 상태, 즉 초록(사용 가능한 메모리 충분), 노랑(브로커 메모리 감소 중), 주황(브로커 메모리 부족) 및 빨강(브로커가 사용 가능한 메모리 없음)에 따라 달라집니다. 브로커의 메모리 상태가 초록에서 노랑 및 주황을 거쳐 빨강으로 변하면 브로커는 다음과 같이 점점 더 높은 수준의 조치를 수행합니다.

시스템 메모리 임계값에 도달하는 경우는 대상별 메시지 제한과 시스템 전체 메시지 제한을 잘못 설정했기 때문입니다. 임계값만으론 잠재적 메모리 과부하를 제때에 잡을 수 없는 경우도 있습니다. 따라서 이 기능에만 의존하여 메모리 자원을 제어해서는 안 되고 대상을 개별적 및 전체적으로 구성하여 메모리 자원을 최적화하는 것이 좋습니다.

메시지 라우터 등록 정보

메모리 자원 관리를 위한 시스템 전체 제한 및 시스템 메모리 임계값은 표 2-4에 자세히 설명되어 있습니다(등록 정보 설정 지침은 5장, "브로커 시작 및 구성" 참조).

표 2-4 메시지 라우터 등록 정보
등록 정보 이름	설명
imq.message.expiration. interval	만료된 메시지 재생 이용이 발생하는 빈도를 초 단위로 지정합니다. 기본값: 60
imq.system.max_count	브로커가 보관하는 최대 메시지 수를 지정합니다. 추가 메시지가 거부됩니다. 값 -1은 제한이 없음을 의미합니다. 기본값: -1
imq.system.max_size	브로커가 보관하는 최대 전체 메시지 최대 크기(바이트, KB, MB)를 지정합니다. 추가 메시지가 거부됩니다. 값 -1은 제한이 없음을 의미합니다. 기본값: -1
imq.message.max_size	메시지 본문의 최대 허용 크기(바이트, KB, MB 단위)를 지정합니다. 이 크기를 초과하는 메시지는 거부됩니다. 값 -1은 제한이 없음을 의미합니다. 기본값: 70m (MB)
imq.resource_state. threshold	각 메모리 자원 상태가 트리거되는 메모리 사용률을 지정합니다. 자원 상태는 초록, 노랑, 주황 및 빨강으로 표시됩니다. 기본값: 각각 0, 80, 90 및 98
imq.resource_state.count	일괄 처리에서 허용되는 받는 메시지의 최대 수를 지정합니다. 이 제한에 이르면 각 메모리 자원 상태가 트리거됩니다. 이 제한은 시스템 메모리가 점점 부족해지면 메시지 생성자를 억제합니다. 기본값: 각각 5000, 500, 50 및 0
imq.transaction. autorollback	PREPARED 상태에 있는 분산 트랜잭션이 브로커 시작 시 자동으로 롤백되는지 여부를 지정합니다(true/false). false라면 imqcmd를 사용하여 수동으로 트랜잭션을 완결하거나 롤백해야 합니다("트랜잭션 관리" 참조). 기본값: false

지속성 관리자

오류 발생 시 브로커를 복구하려면 메시지 전달 작업 상태를 다시 작성해야 합니다. 그러기 위해서는 모든 지속성 메시지와 기본적인 라우팅 및 전달 정보를 데이터 저장소에 저장해야 합니다. 지속성 관리자 구성 요소는 이 정보의 작성 및 검색을 관리합니다.

오류가 발생한 브로커를 복구하려면 전달되지 못한 메시지를 복원하는 것 이상의 작업이 필요합니다. 또한 브로커는 다음을 수행할 수 있어야 합니다.

지속성 관리자는 이 모든 상태 정보의 저장 및 복원을 관리합니다.

브로커가 다시 시작되면 대상 및 영구 가입을 다시 작성하고 지속성 메시지를 복구하며 모든 트랜잭션의 상태를 복원하고 전달되지 못한 메시지의 라우팅 테이블을 다시 작성합니다. 그런 다음 메시지 전달을 다시 시작할 수 있습니다.

Message Queue는 기본 제공 및 플러그 인 지속성 모듈을 모두 지원합니다(그림 2-4 참조). 기본 제공 지속성은 파일 기반 데이터 저장소입니다. 플러그 인 지속성은 JDBC^™(Java Database Connectivity) 인터페이스를 사용하며 JDBC 호환 데이터 저장소가 필요합니다. 일반적으로 기본 제공 지속성은 플러그 인 지속성보다 더 빠릅니다. 그러나 JDBC 호환 데이터베이스 시스템 사용의 중복 및 관리 기능을 선호하는 사용자도 있습니다.

기본 제공 지속성

기본 Message Queue 영구 저장소 솔루션은 파일 기반 데이터 저장소입니다. 이 방법에서는 개별 파일을 사용하여 메시지, 대상, 영구 가입, 트랜잭션과 같은 지속성 데이터를 저장합니다.

파일 기반 데이터 저장소는 데이터 저장소와 연관된 브로커 인스턴스의 이름(instanceName)으로 식별되는 디렉토리에 있습니다(부록 A, "Message Queue 데이터의 위치" 참조).

메시지가 있는 대상에 따라 지속성 메시지를 디렉토리에 저장하도록 파일 기반 데이터 저장소를 구성합니다. 대부분의 메시지는 가변 크기 레코드로 구성되는 단일 파일에 저장됩니다.

메시지를 추가 및 제거할 때 단편화를 줄이려면 가변 크기 레코드 파일을 압축할 수 있습니다("대상 압축" 참조). 또한, 기본 제공 지속성 관리자는 크기가 구성 가능한 임계값(imq.persist.file.message.max_record_size)을 초과하는 메시지를 가변 크기 레코드 파일이 아니라 각자 해당 파일에 저장합니다. 이러한 개별 파일에서는 파일을 재사용할 수 있도록 파일 풀이 유지 관리됩니다. 메시지 파일이 더 이상 필요하지 않은 경우 해당 파일이 삭제되는 대신 대상 디렉토리의 사용 가능한 파일 풀에 추가되어 새 메시지를 저장하는 데 사용됩니다.

대상 파일 풀의 최대 파일 수(imq.persist.file.destination.message.filepool.limit)를 구성할 수 있으며 재사용 태그 표시(잘라내지 않음)와 반대되는 개념으로 파일 풀에서 지울(0으로 잘라냄) 사용 가능한 파일 비율(imq.persist.file.message.filepool.cleanratio)을 지정할 수도 있습니다. 지운 파일의 비율이 높을수록 파일 풀 관리에 필요한 디스크 공간은 더 줄어들지만 더 많은 오버헤드가 필요합니다. 또한 종료 시 태그가 표시된 파일을 지울 것인지 여부도 지정할 수 있습니다(imq.persist.file.message.cleanup 참조). 파일을 지우면 디스크 공간은 덜 차지하지만, 브로커 종료 속도가 느려집니다.

다른 모든 지속성 데이터(대상, 영구 가입 및 트랜잭션)는 별도의 파일에 저장됩니다. 즉, 모든 대상, 모든 영구 가입 등이 각각 서로 다른 별도의 파일에 저장됩니다.

안정성을 최대화하려면 지속성 작업이 메모리 상태에서 물리적 저장 장치와 동기화되도록 지정할 수 있습니다(imq.persist.file.sync.enabled). 이렇게 하면 시스템 충돌로 인한 데이터 손실은 제거할 수 있지만 성능이 떨어집니다.

데이터 저장소에는 중요 정보나 소유 정보를 포함하는 메시지가 있을 수 있기 때문에 .../instances/instanceName/fs350/ 디렉토리를 인증되지 않은 액세스로부터 보호하는 것이 좋습니다. 자세한 지침은 "지속성 데이터 보안"을 참조하십시오.

플러그 인 지속성

JDBC 드라이버를 통해 액세스 가능한 데이터 저장소를 모두 액세스하도록 브로커를 설정할 수 있습니다. 이 경우 여러 JDBC 관련 브로커 구성 등록 정보를 설정하고 데이터베이스 관리자 유틸리티(imqdbmgr)를 사용하여 적합한 체계를 갖는 데이터 저장소를 만들어야 합니다. 절차 및 관련 구성 등록 정보는 부록 B, "플러그 인 지속성 설정"을 참조하십시오.

지속성 관리자 등록 정보

표 2-5에 있는 등록 정보는 첫 번째만 제외하고 모두 기본 제공 지속성에만 연관됩니다. 플러그 인 지속성과 관련된 등록 정보는 표 B-1에 있습니다.

표 2-5 지속성 관리자 등록 정보
등록 정보 이름	설명
imq.persist.store	브로커가 기본 제공 파일 기반(file) 지속성 또는 플러그 인 JDBC 호환(jdbc) 지속성을 사용하고 있는지 지정합니다. 기본값: file
imq.persist.file.sync. enabled	지속성 작업이 메모리 상태에서 물리적 저장 장치와 동기화될 것인지 여부를 지정합니다. 값이 true이면 시스템 충돌로 인한 데이터 손실은 줄어들지만 지속성 작업의 성능이 저하됩니다. 기본값: false
imq.persist.file.message. max_record_size	기본 제공 파일 기반 지속성에 대해 개별 파일에 저장되는 것과는 반대로 메시지 저장소 파일에 추가될 메시지의 최대 크기를 지정합니다. 기본값: 1m (MB)
imq.persist.file. destination.message. filepool.limit	기본 제공 파일 기반 지속성에 대해 대상 파일 풀에서 재사용 가능한 최대 파일 수를 지정합니다. 이 수가 클수록 브로커는 지속성 데이터를 더 빠르게 처리할 수 있습니다. 이 값을 초과하는 사용 가능한 파일은 삭제됩니다. 이 한도를 초과할 경우 브로커는 필요에 따라 추가 파일을 작성하고 삭제합니다. 기본값: 100
imq.persist.file.message. filepool.cleanratio	기본 제공 파일 기반 지속성에 대해 대상 파일 풀에서 clean 상태(0으로 잘라낸 상태)로 유지되는 사용 가능한 파일의 비율을 지정합니다. 이 값이 클수록 작업 중 파일을 지우는 데 필요한 오버헤드가 늘어나지만, 파일 풀에서 필요한 디스크 공간은 줄어듭니다. 기본값: 0
imq.persist.file.message. cleanup	기본 제공 파일 기반 지속성에 대해 브로커가 종료 시 대상 파일 저장소에서 사용 가능한 파일을 지울 것인지 여부를 지정합니다. false 값은 브로커 종료 속도를 향상시키지만, 파일 저장소에 더 많은 디스크 공간이 필요합니다. 기본값: false

보안 관리자

Message Queue는 인증 및 권한 부여(액세스 제어) 기능을 제공하며 암호화 기능도 지원합니다.

인증 및 권한 부여 기능은 사용자 저장소(그림 2-5 참조), 즉 메시징 시스템 사용자에 대한 정보(예: 아이디, 비밀번호, 그룹 멤버쉽)를 포함하는 파일, 디렉토리 또는 데이터베이스에 따라 달라집니다. 아이디와 비밀번호는 브로커와의 연결 요청 시 사용자를 인증할 때 사용됩니다. 대상에 대한 메시지 생성/사용과 같은 작업 권한을 부여할 때 아이디와 그룹 멤버쉽이 액세스 제어 파일과 함께 사용됩니다.

Message Queue 관리자는 Message Queue 제공 사용자 저장소("플랫 파일 사용자 저장소 사용" 참조)를 채우거나 기존 LDAP 사용자 저장소를 보안 관리자 구성 요소에 플러그 인합니다("사용자 저장소에 LDAP 서버 사용" 참조). 플랫 파일 사용자 저장소는 쉽게 사용할 수 있지만 보안 공격에 취약하므로 평가 및 개발 용도에 한해 사용해야 합니다. 반면 LDAP 사용자 저장소는 안전하므로 작업 환경에 가장 적합합니다.

인증

Message Queue 보안은 비밀번호 기반의 인증을 지원합니다. 클라이언트가 브로커와의 연결을 요청할 경우 이 클라이언트는 아이디와 비밀번호를 제출해야 합니다. 보안 관리자는 클라이언트가 제출한 아이디와 비밀번호를 사용자 저장소에 저장된 정보와 비교합니다. 클라이언트가 브로커에게 비밀번호를 전송할 때 이 비밀번호는 기본 64 인코딩이나 메시지 다이제스트(MD5) 중 한 가지를 사용하여 암호화됩니다. 보다 안전한 전송에 대해서는 "암호화(엔터프라이즈판)"를 참조하십시오. 별도로 각 연결 서비스가 사용하는 인코딩 유형을 구성하거나 브로커 전체에 대한 인코딩을 설정할 수 있습니다.

권한 부여

클라이언트 응용 프로그램 사용자가 인증되면 이 사용자는 여러 Message Queue 관련 작업을 수행할 권한을 갖습니다. 보안 관리자는 사용자 기반 및 그룹 기반 액세스 제어를 모두 지원합니다. 사용자 저장소에 있는 아이디 또는 해당 사용자가 속한 그룹에 따라 이 사용자는 특정 Message Queue 작업을 수행할 권한을 갖습니다. 액세스 제어 등록 정보 파일에서 이 액세스 제어를 지정합니다(그림 2-5 참조).

사용자가 어떤 작업을 수행하려 하면 보안 관리자는 (액세스 제어 등록 정보 파일에 있는) 해당 작업 액세스를 위해 지정된 아이디/그룹 멤버쉽을 (사용자 저장소에 있는) 아이디/그룹 멤버쉽과 대조 확인합니다. 액세스 제어 등록 정보 파일은 다음 작업에 대한 권한을 지정합니다.

기본 액세스 제어 등록 정보 파일이 admin이라는 단일 그룹만 명시적으로 참조합니다("그룹" 참조). admin 그룹의 사용자는 관리 서비스 연결 권한을 갖습니다. 관리 서비스 사용자는 대상 작성, 브로커 모니터링 및 제어와 같은 관리 기능을 수행할 수 있습니다. 다른 그룹으로 정의된 사용자는 기본적으로 관리 서비스 연결 권한을 가질 수 없습니다.

Message Queue 관리자는 사용자 저장소에서 그룹을 정의하고 사용자를 해당 그룹에 연결할 수 있습니다(단, 플랫 파일 사용자 저장소에서는 그룹 기능이 완전히 지원되지 않음). 그런 다음 액세스 제어 등록 정보 파일을 편집하여 메시지 생성 및 사용 또는 대기열 대상에서의 메시지 찾아보기 목적으로 대상에 대한 액세스를 사용자 및 그룹별로 지정할 수 있습니다. 개별 대상이나 모든 대상에 대한 액세스 권한을 특정 사용자나 그룹에게만 부여할 수 있습니다.

또한 브로커가 대상을 자동으로 작성할 수 있도록 구성된 경우("자동 작성(대 관리 작성) 대상" 참조), 액세스 제어 등록 정보 파일을 편집하여 브로커가 특정 사용자를 위해 대상을 자동으로 작성할 수 있도록 제어할 수 있습니다.

암호화(엔터프라이즈판)

클라이언트와 브로커 사이에 전송되는 메시지를 암호화하려면 Secure Socket Layer (SSL) 표준 기반의 연결 서비스를 사용해야 합니다. SSL은 SSL 사용 가능 브로커와 SSL 사용 가능 클라이언트 사이에 암호화된 연결을 설정함으로써 연결 수준에서의 보안을 제공합니다.

Message Queue SSL 기반 연결 서비스를 사용하려면 키 도구 유틸리티(imqkeytool)를 사용하여 개인 키/공용 키 쌍을 생성합니다. 이 유틸리티는 자체 서명된 인증서에 공용 키를 내장하고 이를 Message Queue 키 저장소에 저장합니다. Message Queue 키 저장소 자체도 비밀번호로 보호됩니다. 이 잠금을 해제하려면 시작할 때 키 저장소 비밀번호를 제공해야 합니다. "암호화: SSL 기반 서비스를 사용한 작업(엔터프라이즈판)"을 참조하십시오.

키 저장소 잠금이 해제되면 브로커는 연결을 요청하는 모든 클라이언트에게 인증서를 전달할 수 있습니다. 그리고 나서 클라이언트는 인증서를 사용하여 브로커에게 보낼 암호화된 연결을 설정합니다.

인증, 권한 부여, 암호화 및 기타 보안이 설정된 통신에 대해 구성 가능한 등록 정보는 표 2-6에서 확인할 수 있습니다(등록 정보 구성 지침은 5장, "브로커 시작 및 구성" 참조).

표 2-6 보안 관리자 등록 정보
등록 정보 이름	설명
imq.authentication.type	비밀번호를 기본 64 코딩(basic)으로 전달할지 MD5 다이제스트(digest)로 전달할지 여부를 지정합니다. 브로커가 지원하는 모든 연결 서비스에 대한 인코딩을 설정합니다. 기본값: digest
imq.service_name. authentication.type	비밀번호를 기본 64 코딩(basic)으로 전달할지 MD5 다이제스트(digest)로 전달할지 여부를 지정합니다. 명명된 연결 서비스의 인코딩을 설정하며, 이 값은 브로커 전체에 대한 설정을 무시합니다. 기본값: imq.authentication.type 값을 상속합니다.
imq.authentication. basic.user_repository	(기본 64 코딩에 대해) 인증에 사용할 사용자 저장소 유형을 지정하며, 파일 기반(file) 또는 LDAP (ldap) 중 하나입니다. 추가적인 LDAP 등록 정보에 대해서는 표 8-5를 참조하십시오. 기본값: file
imq.authentication. client.response.timeout	클라이언트가 브로커로부터의 인증 요청에 응답할 때까지 시스템이 대기할 시간(초)을 지정합니다. 기본값: 180(초)
imq.accesscontrol.file. enabled	브로커가 지원하는 모든 연결 서비스에 대해 액세스 제어(true/false)를 설정합니다. 액세스 제어 등록 정보 파일에 지정된 대로 인증된 사용자가 연결 서비스를 사용하거나 특정 대상에 대해 특정 Message Queue 작업을 수행할 권한이 있는가를 시스템이 확인할 것인지 여부를 표시합니다. 기본값: true
imq.service_name. accesscontrol.enabled	명명된 연결 서비스의 액세스 제어를 설정하며(true/false), 이 값은 브로커 전체에 대한 설정을 무시합니다. 액세스 제어 등록 정보 파일에 지정된 대로 인증된 사용자가 명명된 연결 서비스를 사용하거나 특정 대상에 대해 특정 Message Queue 작업을 수행할 권한이 있는가를 시스템이 확인할 것인지 여부를 표시합니다. 기본값: imq.accesscontrol.enabled 값을 상속합니다.
imq.accesscontrol.file. filename	브로커가 지원하는 모든 연결 서비스에 대한 액세스 제어 등록 정보 파일의 이름을 지정합니다. 파일 이름은 액세스 제어 디렉토리에 대한 상대 파일 경로를 지정합니다(부록 A, "Message Queue 데이터의 위치" 참조). 기본값: accesscontrol.properties
imq.service_name. accesscontrol.file. filename	브로커 인스턴스의 명명된 연결 서비스에 대한 액세스 제어 등록 정보 파일의 이름을 지정합니다. 파일 이름은 액세스 제어 디렉토리에 대한 상대 파일 경로를 지정합니다(부록 A, "Message Queue 데이터의 위치" 참조). 기본값: imq.accesscontrol.file.filename 값을 상속합니다.
imq.passfile.enabled	안전한 통신을 위한 사용자 비밀번호(SSL, LDAP, JDBC^™가 passfile에 설정되는지 여부를 지정합니다(true/false). 기본값: false
imq.passfile.dirpath	passfile이 포함된 디렉토리의 경로를 지정합니다(운영 체제에 따라 다름). 기본값: 부록 A, "Message Queue 데이터의 위치"를 참조하십시오.
imq.passfile.name	passfile 이름을 지정합니다. 기본값: passfile
imq.keystore.property_name	SSL 기반 서비스에 대해 SSL 키 저장소와 관련된 보안 등록 정보를 지정합니다. 표 8-8을 참조하십시오.

모니터링 서비스

브로커는 로그 작업을 모니터링하고 진단할 다양한 구성 요소를 포함합니다. 다음은 그러한 구성 요소의 예입니다.

메트릭 생성자

메트릭 생성자는 브로커 내부 및 외부로의 메시지 흐름, 브로커 메모리의 메시지 수 및 이 메시지가 사용하는 메모리, 열려 있는 연결 수, 사용 중인 스레드 수 등과 같은 브로커 활동 정보를 제공합니다.

메트릭 데이터 생성을 설정 또는 해제하고 메트릭 보고서 생성 빈도를 지정할 수 있습니다.

로거

Message Queue 로거는 브로커 코드 및 메트릭 생성자가 생성한 정보를 가져와서 표준 출력(콘솔), 로그 파일, syslog 데몬 프로세스(Solaris^™ 플랫폼인 경우) 등과 같은 여러 출력 채널에 기록합니다.

로거에서 수집되는 정보 유형과 각 출력 채널에 기록되는 유형을 지정할 수 있습니다.

예를 들어, 가장 심각하고 중요한 정보(오류)에서 중요도가 상대적으로 낮은 정보(메트릭 데이터)까지 로거 수준(로거에서 수집되는 정보 유형)을 지정할 수 있습니다. 표 2-7은 정보 범주를 심각도 내림차순으로 표시합니다.

표 2-7 로깅 범주
범주	설명
ERROR	시스템 오류가 발생할 수 있는 문제에 대한 메시지
WARNING	주의해야 하지만 시스템 오류는 발생하지 않을 경고
INFO	메트릭 및 기타 정보 메시지 보고

로거 수준을 설정하려면 이 범주 중 하나를 지정합니다. 로거는 지정된 범주 및 모든 상위 범주의 데이터를 기록합니다. 예를 들어, WARNING 수준의 로깅을 지정한 경우 로거는 경고 정보 및 오류 정보를 기록합니다.

각 출력 채널마다 로거에 대해 설정된 범주 중 어느 것이 해당 채널에 기록될 것인지 지정할 수 있습니다. 예를 들어, 로거 수준이 INFO로 설정된 경우 콘솔에는 오류와 경고만, 로그 파일에는 정보(메트릭 데이터)만 기록하게 지정할 수 있습니다(Solaris syslog 구성 및 사용에 대한 정보는 syslog(1M), syslog.conf(4) 및 syslog(3C) 설명서 페이지 참조).

로그 파일의 경우 로그 파일을 닫고 출력을 새 파일로 롤오버하는 지점을 지정할 수 있습니다. 로그 파일이 지정된 크기나 표시 시간에 도달하면 이 파일을 저장하고 새 로그 파일을 작성합니다. 로그 파일은 로그 파일이 연관되어 있는 브로커 인스턴스의 이름(instanceName)으로 식별되는 디렉토리에 기록됩니다(부록 A, "Message Queue 데이터의 위치" 참조).

새 롤오버 로그 파일을 작성하면서 가장 최신의 로그 파일 9개로 구성된 아카이브를 보존합니다.

메트릭 메시지 생성자(엔터프라이즈판)

메시지 생성자 구성 요소는 메트릭 생성자 구성 요소로부터 일정 간격으로 정보를 받아서 메시지로 기록한 다음 메시지에 포함된 메트릭 정보 유형에 따라 여러 메트릭 주제 대상 중 하나로 보냅니다.

다섯 개의 메트릭 주제 대상이 있으며 표 2-8에 그 이름과 함께 각 대상에 전달되는 메트릭 메시지 유형이 표시되어 있습니다.

표 2-8 메트릭 주제 대상
주제 대상 이름	메트릭 메시지 유형
mq.metrics.broker	브로커 메트릭
mq.metrics.jvm	Java 가상 머신 메트릭
mq.metrics.destination_list	대상 및 대상 유형 목록
mq.metrics.destination.queue. monitoredDestinationName	지정한 이름의 대기열에 대한 대상 메트릭
mq.metrics.destination.topic. monitoredDestinationName	지정한 이름의 주제에 대한 대상 메트릭

이러한 메트릭 주제 대상에 가입한 Message Queue 클라이언트는 대상의 메시지를 사용하고 메시지에 포함된 메트릭 정보를 처리합니다. 예를 들어, 클라이언트가 mq.metrics.broker 대상에 가입하여 브로커의 총 메시지 수와 같은 정보를 받아서 처리할 수 있습니다.

메트릭 메시지 생성자는 메트릭 데이터에 해당하는 이름-값 쌍이 포함된 메시지(MapMessage 유형)를 만드는 내부 Message Queue 클라이언트입니다. 이러한 메시지는 해당 메트릭 주제 대상에 한 명 이상의 가입자가 있는 경우에만 생성됩니다.

메트릭 메시지 생성자가 생성하는 메시지는 MapMessage 유형이며 포함된 메트릭 유형에 따라 여러 이름/값 쌍으로 구성됩니다. 각 이름/값 쌍은 메트릭 수량과 값에 해당합니다. 예를 들어, 브로커 메트릭 메시지는 브로커를 오가는 메시지 수와 이 메시지의 크기, 현재 메모리에 있는 메시지의 수 및 크기 등 약 12가지의 메트릭 수량 값을 포함합니다. 각 메트릭 메시지 유형에서 보고하는 메트릭 수량에 대한 자세한 내용은 메트릭 메시지를 사용할 Message Queue 클라이언트 작성 방법을 설명하는 Message Queue Java Client Developer's Guide를 참조하십시오.

메트릭 메시지 본문에 포함된 메트릭 정보 외에 각 메시지의 헤더에는 메트릭 메시지 유형을 지정하는 등록 정보와 타임스탬프를 기록하는 등록 정보의 두 가지 등록 정보가 있습니다. 이 헤더 등록 정보는 Message Queue 클라이언트 응용 프로그램이 메트릭 메시지에서 데이터를 추출하고 해당 타임스탬프를 기록하는 데 사용될 수 있습니다.

모니터링 서비스 등록 정보

브로커의 정보 생성, 로깅 및 메트릭 메시지 생성을 설정하는 구성 가능한 등록 정보는 표 2-9에서 확인할 수 있습니다(등록 정보 구성 지침은 5장, "브로커 시작 및 구성" 참조).

표 2-9 모니터링 서비스 등록 정보
등록 정보 이름	설명
imq.metrics.enabled	메트릭 정보를 로거에 기록할지 여부를 지정합니다(true/false). 메트릭 메시지 생성에는 영향을 미치지 않습니다(imq.metrics.topic.enabled 참조). 기본값: true
imq.metrics.interval	메트릭 로깅이 사용 가능한 경우(imq.metrics.enabled=true) 메트릭 정보가 로거에 기록되는 간격(초)을 지정합니다. 값이 -1이면 기록하지 않습니다. 메트릭 메시지 생성 간격에는 영향을 미치지 않습니다(imq.metrics.topic.interval 참조). 기본값: -1
imq.log.level	로거 수준, 즉 출력 채널에 기록 가능한 출력 범주를 지정합니다. 지정된 범주 및 모든 상위 범주가 함께 포함됩니다. 값은 내림차순으로 ERROR, WARNING, INFO입니다. 기본값: INFO
imq.log.file.output	로그 파일에 기록하는 로깅 정보의 범주를 지정합니다. 사용 가능한 값은 세로 막대(\|)로 구분된 임의의 로깅 범주 집합, ALL 또는 NONE입니다. 기본값: ALL
imq.log.file.dirpath	로그 파일이 포함된 디렉토리의 경로를 지정합니다(운영 체제에 따라 다름). 기본값: 부록 A, "Message Queue 데이터의 위치"를 참조하십시오.
imq.log.file.filename	로그 파일의 이름을 지정합니다. 기본값: log.txt
imq.log.file.rolloverbytes	새 로그 파일로 출력을 롤오버할 로그 파일 크기(바이트)를 지정합니다. 값 -1은 파일 크기를 기준으로 하는 롤오버가 없음을 의미합니다. 기본값: -1
imq.log.file.rolloversecs	새 로그 파일로 출력을 롤오버할 로그 파일 표시 시간(초)을 지정합니다. 값 -1은 파일 표시 시간을 기준으로 하는 롤오버가 없음을 의미합니다. 기본값: 604800 (1주)
imq.log.console.output	콘솔에 기록하는 로깅 정보의 범주를 지정합니다. 사용 가능한 값은 세로 막대(\|)로 구분된 임의의 로깅 범주 집합, ALL 또는 NONE입니다. 기본값: ERROR\| WARNING
imq.log.console.stream	콘솔 출력을 stdout (OUT) 또는 stderr (ERR)에 기록할 것인지 지정합니다. 기본값: ERR
imq.log.syslog.facility	(Solaris에만 적용) Message Queue 브로커가 어떤 syslog 기능으로 로깅할 것인지 지정합니다. 값은 syslog(3C) 설명서 페이지에 있는 값을 미러링합니다. Message Queue에서 사용 가능한 값은 LOG_USER, LOG_DAEMON 그리고 LOG_LOCAL0부터 LOG_LOCAL7까지입니다. 기본값: LOG_DAEMON
imq.log.syslog.logpid	(Solaris에만 적용) 브로커 프로세스 아이디를 메시지와 함께 로깅할 것인지 여부를 지정합니다(true/false). 기본값: true
imq.log.syslog.logconsole	(Solaris에만 적용) 메시지를 syslog에 보낼 수 없을 경우 시스템 콘솔에 기록할 것인지 여부를 지정합니다(true/false). 기본값: false
imq.log.syslog.identity	(Solaris에만 적용) syslog에 기록되는 모든 메시지의 앞에 추가될 아이디 문자열을 지정합니다. 기본값: 브로커 인스턴스 이름 앞에 imqbrokerd_가 붙습니다.
imq.log.syslog.output	(Solaris에만 적용) syslogd(1M)에 기록하는 로깅 정보의 범주를 지정합니다. 사용 가능한 값은 세로 막대(\|)로 구분된 임의의 로깅 범주 집합, ALL 또는 NONE입니다. 기본값: ERROR
imq.log.timezone	로그 타임스탬프의 표준 시간대를 지정합니다. 식별자는 java.util.TimeZone.getTimeZone()에 사용되는 식별자와 동일합니다. 예: GMT, 미국/로스앤젤레스, 유럽/로마, 아시아/도쿄. 기본값: 지역 표준 시간대
imq.metrics.topic.enabled	메트릭 메시지 생성이 가능한지 여부를 지정합니다(true/false). false인 경우 메트릭 주제 대상에 가입하려고 하면 클라이언트측 예외가 발생합니다. 기본값: true
imq.metrics.topic.interval	메트릭 메시지를 생성하여 메트릭 주제 대상에 보내는 간격(초)을 지정합니다. 기본값: 60
imq.metrics.topic.persist	메트릭 메시지가 지속성인지 여부를 지정합니다(true/false). 기본값: false
imq.metrics.topic.timetolive	메트릭 주제 대상에 보낸 메트릭 메시지의 수명(초)을 지정합니다. 기본값: 300

물리적 대상

Message Queue 메시징은 2단계 메시지 전달을 기반으로 합니다. 먼저 생성자 클라이언트에서 브로커의 대상으로 메시지가 전달되고, 두 번째로는 브로커의 대상에서 하나 이상의 사용자 클라이언트로 메시지가 전달됩니다. 대상에는 2가지 유형이 있는데("프로그래밍 도메인" 참조), 대기열(지점간 전달 모델)과 주제(게시/가입 전달 모델)입니다. 이러한 대상은 브로커의 물리적 메모리에서의 위치를 나타내며, 여기서는 받은 메시지가 사용자 클라이언트에게 라우팅되기 전에 마샬링됩니다.

이 절에서는 2가지 물리적 대상 유형, 즉 대기열과 주제의 등록 정보 및 동작에 대해 설명합니다.

대기열 대상

대기열 대상은 대상에서 인터레스트를 등록한 여러 사용자 중 단 한 명에게 메시지가 전달되는 지점간 메시징에서 사용합니다. 메시지 생성자로부터 도착한 메시지는 대기열에 있다가 단일 메시지 사용자에게 전달됩니다.

다중 사용자로의 대기열 전달

대기열 대상의 메시지는 단일 사용자에게만 전달되지만 Message Queue에서는 다중 사용자가 하나의 대기열에 등록할 수 있습니다. 브로커는 받는 메시지를 여러 사용자에게 라우팅하여 사용자 간에 로드 균형을 조정합니다.

다중 사용자로의 대기열 전달 구현에서는 다음 대기열 대상 속성을 기반으로 구성 가능한 로드 균형 조정 방법을 사용합니다.

사용자 수가 두 속성의 합계를 초과할 경우 새 사용자가 거부됩니다(Message Queue 플랫폼판은 대기열당 최대 3명의 사용자(2명의 활성 사용자와 1명의 백업 사용자)를 지원하고 Message Queue 엔터프라이즈판은 제한이 없음).

로드 균형 조정 메커니즘에서는 여러 사용자의 메시지 사용 속도를 고려합니다. 작동 방식은 다음과 같습니다.

구성 가능한 크기(대기열 대상의 consumerFlowLimit 속성)의 일괄 처리에서 대기열 대상의 메시지를 사용 가능한 새 활성 사용자에게 대기열에 등록된 순서에 따라 라우팅합니다. 이 메시지를 전달한 후 사용자가 사용 가능해지면(즉, 사용자가 이전에 전달 받은 메시지의 구성 가능한 비율을 사용하면) 대기열에 도착하는 추가 메시지를 일괄 처리로 사용자에게 라우팅합니다. 각 사용자의 디스패치 속도는 사용자의 현재 용량과 메시지 처리 속도에 따라 다릅니다.

메시지 생성 속도가 느린 경우 브로커가 활성 사용자들에게 메시지를 고르지 않게 디스패치할 수 있습니다. 활성 사용자가 필요 이상으로 많은 경우 메시지를 받지 못하는 사용자도 있을 수 있습니다.

활성 사용자가 실패하면 첫 번째 백업 사용자가 활성화되어 실패한 사용자의 작업을 대신 수행합니다. 대기열 대상에 둘 이상의 활성 사용자가 있는 경우 메시지 사용 순서가 지켜지지 않을 수 있습니다.

브로커 클러스터 환경에서는 다중 사용자로의 전달 시 로컬 사용자를 우선하도록 설정할 수 있습니다. 대기열 대상 속성 localDeliveryPreferred를 사용하면 생성자의 홈 브로커, 즉 생성자가 메시지를 보낸 브로커(로컬 브로커)에 사용자가 없는 경우에만 메시지를 원격 사용자에게 전달하도록 지정할 수 있습니다. 그러면 원격 사용자의 홈 브로커를 통해 원격 사용자에게 라우팅할 때 처리량이 떨어질 수 있는 상황에서 성능을 향상시킬 수 있습니다. 이 속성을 사용하려면 대상 범위가 로컬 전용 전달로 제한되지 않아야 합니다(표 6-10 참조).

메모리 고려 사항

메시지가 대기열에 오래 머무를 수 있으므로 메모리 자원이 문제가 되기도 합니다. 대기열에 메모리를 너무 많이(메모리는 저활용 상태) 또는 너무 적게(메시지가 거부됨) 할당하기를 원치 않을 것입니다. 유연성을 위해 각 대기열의 로드 수요에 따라 대기열 생성 시 대기열의 메시지 최대 수, 대기 메시지에 할당되는 최대 메모리, 대기 메시지의 최대 크기 등의 물리적 등록 정보를 설정할 수 있습니다(표 6-10 참조).

주제 대상

주제 대상은 대상에서 인터레스트를 등록한 모든 사용자에게 메시지가 전달되는 게시/가입 메시징에서 사용합니다. 생성자로부터 메시지가 도착하면 해당 주제에 가입한 모든 사용자에게 라우팅됩니다. 사용자가 해당 주제에 대한 영구 가입에 등록한 경우, 메시지가 주제에 전달되는 시점에 사용자는 활성 상태가 아니어도 됩니다. 브로커는 이 사용자가 활성화될 때까지 메시지를 보관했다가 전달합니다.

일반적으로 메시지는 주제 대상에 오래 머무르지 않으므로 메모리 자원은 큰 문제가 되지 않는 편입니다. 그러나 대상이 수신하는 메시지에 허용되는 최대 크기를 구성할 수 있습니다(표 6-10 참조).

자동 작성(대 관리 작성) 대상

Message Queue 메시지 서버는 메시징 시스템에서 중앙 허브가 되므로 이 서버의 성능 및 안정성이 성공적인 엔터프라이즈 응용 프로그램에 있어 중요한 요소입니다. 대상은 (처리하는 메시지의 수 및 크기, 등록하는 메시지 사용자의 수 및 지속성에 따라) 많은 자원을 사용할 수 있으므로 메시지 서버 성능 및 안정성을 보장하도록 면밀하게 관리해야 합니다. 따라서 관리자가 응용 프로그램을 대신하여 대상을 만들고 대상을 모니터하며 필요 시 자원 요구 사항을 재구성하는 것이 표준 방식입니다.

그러나 대상을 동적으로 작성하는 것이 바람직한 경우가 있습니다. 예를 들어 개발 및 테스트 주기에서는 관리자가 개입할 필요 없이 필요에 따라 브로커가 자동으로 대상을 작성하는 것이 나을 수 있습니다.

Message Queue는 이 자동 작성 기능을 지원합니다. 자동 작성이 가능한 경우 브로커는 메시지 사용자나 메시지 생성자가 존재하지 않는 대상에 액세스를 시도할 때마다 자동으로 대상을 작성합니다(클라이언트 응용 프로그램의 사용자는 자동 작성 권한이 있어야 합니다. "대상 자동 작성 액세스 제어" 참조).

그러나 대상이 명시적이 아니라 자동으로 작성될 경우, (동일한 대상 이름을 사용하는) 서로 다른 클라이언트 응용 프로그램이 충돌하거나 (대상 지원에 필요한 자원 때문에) 시스템 성능이 저하될 수 있습니다. 이런 이유로 자동 작성 대상은 더 이상 사용되지 않을 경우, 즉 더 이상 메시지 사용자 클라이언트가 없거나 어떤 메시지도 포함하지 않는 경우 브로커에 의해 자동으로 삭제됩니다. 브로커가 다시 시작되면 지속성 메시지가 있는 경우에만 자동 작성 대상을 다시 작성합니다.

표 2-10에 있는 등록 정보를 사용하여 자동 작성 기능이 사용 가능/불가능하도록 Message Queue 메시지 서버를 구성할 수 있습니다(등록 정보 구성 지침은 5장, "브로커 시작 및 구성" 참조).

표 2-10 자동 작성 구성 등록 정보
등록 정보 이름	설명
imq.autocreate.topic	브로커가 주제 대상을 자동 작성할 수 있는지 여부를 지정합니다(true/false). 기본값: true
imq.autocreate.queue	브로커가 대기열 대상을 자동 작성할 수 있는지 여부를 지정합니다(true/false). 기본값: true
imq.autocreate.destination. maxNumMsgs	자동 작성된 대상에 허용되는 사용되지 않은 최대 메시지 수를 지정합니다. 기본값: 100,000
imq.autocreate.destination. maxTotalMsgBytes	대상의 사용되지 않은 메시지에 허용되는 최대 메모리 합계(바이트)를 지정합니다. 기본값: 10m (MB)
imq.autocreate.destination. limitBehavior	메모리 제한 임계값에 도달할 경우에 브로커가 응답하는 방법을 지정합니다. 값은 다음과 같습니다. FLOW_CONTROL - 생성자 수를 조금씩 줄입니다. REMOVE_OLDEST - 가장 오래된 메시지를 삭제합니다. REMOVE_LOW_PRIORITY - 메시지 보존 기간을 기준으로 우선 순위가 가장 낮은 메시지를 삭제합니다. REJECT_NEWEST - 최신 메시지를 거부합니다. 기본값: REJECT_NEWEST
imq.autocreate.destination. maxBytesPerMsg	자동 작성된 대상에 허용되는 단일 메시지의 최대 크기(바이트)를 지정합니다. 기본값: 10k (10,240)
imq.autocreate.destination. maxNumProducers	대상에 허용되는 최대 생성자 수를 지정합니다. 이 제한에 도달하면 새로운 생성자가 생성되지 않습니다. 기본값: 100
imq.autocreate.destination. isLocalOnly	브로커 클러스터에만 적용됩니다. 대상을 다른 브로커에 복사하지 않도록 지정합니다. 따라서, 메시지 전달이 로컬 사용자(대상이 생성되는 브로커에 연결된 사용자)에게만 제한됩니다. 대상이 생성된 이후에는 이 속성을 업데이트할 수 없습니다. 기본값: false
imq.autocreate.queue. maxNumActiveConsumers	자동 생성된 대기열 대상으로부터의 로드 균형 조정 전달에서 활성 상태가 될 수 있는 최대 사용자 수를 지정합니다. 값 -1은 무제한을 의미합니다. 기본값: 1
imq.autocreate.queue. maxNumBackupConsumers	자동 작성된 대기열 대상으로부터의 로드 균형 조정 전달 중에 오류가 발생할 경우 활성 사용자를 대신할 수 있는 최대 백업 사용자 수를 지정합니다. 값 -1은 무제한을 의미합니다. 기본값: 0
imq.autocreate.queue. consumerFlowLimit	일괄적으로 사용자에게 전달되는 최대 메시지 수를 지정합니다. 로드 균형 조정된 대기열 전달에서 이 수는 로드 균형 조정을 시작하기 전에 활성 사용자에게 라우팅되는 초기 대기 메시지 수입니다("다중 사용자로의 대기열 전달" 참조). 이 제한은 해당 연결에서 대상 사용자에게 설정된 낮은 값으로 대체될 수 있습니다(Message Queue Java Client Developer's Guide의 연결 팩토리 속성 참조). 값 -1은 무제한을 의미합니다. 기본값: 1000
imq.autocreate.topic. consumerFlowLimit	일괄적으로 사용자에게 전달되는 최대 메시지 수를 지정합니다. 값 -1은 무제한을 의미합니다. 기본값: 1,000
imq.autocreate.queue. localDeliveryPreferred	브로커 클러스터의 로드 균형 조정된 대기열 전달에만 적용됩니다. 로컬 브로커에 사용자가 없는 경우에만 원격 사용자에게 메시지를 전달하도록 지정합니다. 자동 작성된 대상을 로컬에만 전달로 제한해서는 안 됩니다(isLocalOnly = false). 기본값: false

임시 대상

임시 대상은 다른 클라이언트에게 보낸 메시지의 응답을 받을 대상이 필요한 클라이언트가 (JMS API를 사용하여) 명시적으로 만들고 삭제합니다. 이러한 대상은 작성 시 해당 연결이 지속되는 동안 브로커에 의해 유지 관리됩니다. 임시 대상은 관리자가 삭제할 수 없습니다. 그리고 사용 중이라면, 즉 활성 메시지 사용자가 있는 경우에는 클라이언트 응용 프로그램에서도 삭제할 수 없습니다. 임시 대상은 (지속성 메시지가 있는) 관리 작성되거나 자동 작성된 대상과 달리 영구 저장되지 않으며 브로커가 다시 시작할 때 다시 작성되지는 않지만, Message Queue 관리 도구에 표시될 수 있습니다(표 6-9 참조).

멀티 브로커 클러스터(엔터프라이즈판)

Message Queue 엔터프라이즈판은 상호 연결된 여러 브로커 인스턴스들, 즉 브로커 클러스터를 사용하는 메시지 서버 구현을 지원합니다. 클러스터 지원은 메시지 서버의 확장성을 제공합니다.

브로커에 연결된 클라이언트 수가 늘어나고 전달되는 메시지 수가 늘어나면 브로커는 파일 설명자, 메모리 제한과 같은 자원 제한 사항을 초과하게 됩니다. 늘어나는 로드를 수용하는 한 가지 방법은 Message Queue 메시지 서버에 브로커(브로커 인스턴스)를 추가하여 클라이언트 연결 및 메시지 전달을 여러 브로커에 걸쳐 분산시키는 것입니다.

또한 여러 브로커를 사용하여 네트워크 대역폭을 최적화할 수 있습니다. 예를 들어, 원격 브로커들 사이에는 더 느린 장거리 네트워크 링크를 사용하고 클라이언트를 개별 브로커 인스턴스에 연결할 경우에는 더 빠른 링크를 사용할 수 있습니다.

브로커 클러스터를 사용하는 또 다른 이유들이 있지만(예: 사용자 저장소가 다른 작업 그룹 수용, 방화벽 제한 사항 처리) 페일오버는 해당되지 않습니다. Message Queue에서는 클러스터의 다른 브로커를 사용하여 실패한 연결을 다시 설정할 수 있지만 상태 정보는 손실됩니다. 따라서 클러스터의 한 브로커를 실패한 다른 브로커의 자동 백업으로 사용할 수 없습니다.

즉, Message Queue에서는 현재 고가용성 메시지 서버를 지원하지 않습니다. 그러나 Sun Cluster 소프트웨어와 고가용성 데이터베이스를 사용하여 브로커 페일오버에 대비할 수 있습니다. 멀티 브로커를 사용하도록 메시징 응용 프로그램을 설계하여 사용자 정의 페일오버 솔루션을 구현할 수도 있습니다.

다음 절에서는 Message Queue 브로커 클러스터의 구조 및 내부 기능에 대해 설명합니다.

멀티 브로커 구조

멀티 브로커 메시지 서버에서는 그림 2-7과 같이 여러 브로커 인스턴스 사이에 클라이언트 연결을 분산시킬 수 있습니다. 클라이언트 관점에서 각 클라이언트는 개별 브로커(자신의 홈 브로커)와 연결되며, 홈 브로커가 클러스터에서 유일한 브로커인 것처럼 메시지를 보내고 받습니다. 그러나 메시지 서버 관점에서 이 홈 브로커는 클러스터의 다른 브로커들과 탠덤 방식으로 작동하면서 직접 연결된 메시지 생성자 및 사용자에게 전달 서비스를 제공합니다.

이론적으로는 클러스터 내부의 브로커가 임의의 토폴로지로 연결할 수 있습니다. 그러나 Message Queue는 완전 연결된 클러스터, 즉 그림 2-7에서처럼 각 브로커가 클러스터의 다른 모든 브로커와 직접 연결되는 토폴로지만 지원합니다.

메시지 전달

멀티 브로커 구성에서는 각 대상이 클러스터의 모든 브로커에 복제됩니다(몇 가지 예외가 있지만 클러스터 환경의 대상 속성은 일반적으로 대상의 모든 인스턴스에 즉, 개별 대상 인스턴스가 아니라 전체 클러스터에 집합적으로 적용됩니다. 또한, isLocalOnly 속성이 true로 설정된 대상은 클러스터에 복제되지 않습니다. 자세한 내용은 표 6-10의 대상 속성 설명 참조).

각 브로커는 다른 모든 브로커의 대상에 등록된 메시지 사용자에 대해 알고 있습니다. 따라서 각 브로커는 자신과 직접 연결된 메시지 생성자로부터 원격 메시지 사용자에게 메시지를 라우팅하고, 원격 생성자로부터 자신과 직접 연결된 사용자에게 메시지를 전달합니다.

클러스터 구성에서 각 메시지 생성자와 직접 연결된 브로커는 해당 사용자가 자신에게 보내는 메시지에 대해 라우팅을 수행합니다. 따라서 지속성 메시지는 그 메시지의 홈 브로커에 의해 저장되고 라우팅됩니다.

클러스터에서 브로커 간의 트래픽을 최소화하기 위해 사용자 연결의 흐름 제어 메커니즘을 통해 대상에서 클라이언트 런타임으로의 메시지 전달을 규제합니다. 이 방법에서는 메시지를 대상 브로커에 연결된 사용자에게 전달해야 하는 경우에만 메시지를 한 브로커에서 다른 브로커로 보내므로 브로커 간의 불필요한 메시지 전달이 방지됩니다. 또한 여러 사용자로의 대기열 전달과 같은 몇 가지 경우에는 로컬 사용자로의 전달이 원격 사용자로의 전달보다 우선 순위를 갖도록 지정하여 브로커간 트래픽을 최소화할 수 있습니다(표 6-10의 localDeliveryPreferred 대기열 대상 속성 참조).

클라이언트와 메시지 서버 간에 암호화된 보안 메시지 전달이 필요한 경우 클러스터에서 브로커 간의 메시지 전달도 보안하도록 클러스터를 구성할 수 있습니다("브로커간 연결 보안" 참조).

클러스터 동기화

관리자가 브로커에서 대상을 작성하거나 삭제할 때마다 이 정보는 클러스터의 다른 모든 브로커들에게 자동 전파됩니다. 이와 비슷하게 메시지 사용자가 홈 브로커에 등록되거나 사용자와 홈 브로커 사이의 연결이 (명시적으로 또는 클라이언트나 네트워크 오류로 인해 또는 홈 브로커가 중단되어) 끊길 때마다 이 사용자에 대한 관련 정보가 클러스터 전체에 전파됩니다. 또한 영구 가입에 대한 정보도 클러스터의 모든 브로커에게 전파됩니다.

특정 브로커에게 대상과 메시지 사용자에 대한 정보를 전파하려면 일반적으로 공유 자원이 변경될 때 브로커가 온라인 상태가 되어야 합니다. 그러한 변경이 이루어질 때 브로커가 오프라인 상태라면(예: 브로커가 충돌하거나 나중에 다시 시작하거나 클러스터에 새 브로커가 동적으로 추가되는 경우) 어떻게 될까요?


주	과도한 네트워크 트래픽 및/또는 대용량 메시지는 내부 클러스터 연결에 지장을 줄 수 있습니다. 대기 시간이 길어지면 잠금 프로토콜 시간 초과 오류가 발생하기도 합니다. 그 결과 클라이언트가 영구 가입자나 대기열 메시지 사용자를 작성하려고 할 때 예외가 발생할 수 있습니다. 일반적으로 이러한 문제는 더 빠른 연결을 사용하여 방지할 수 있습니다.

오프라인된 브로커(또는 새로 추가된 브로커)를 수용하기 위해 Message Queue는 클러스터의 모든 지속성 항목에 대한 변경 기록, 즉 작성되거나 삭제된 모든 대상 및 영구 가입에 대한 기록을 관리합니다. 클러스터에 동적으로 브로커가 추가되면 이 브로커는 먼저 이 구성 변경 기록에서 대상 및 영구 가입자 정보를 읽습니다. 브로커가 온라인 상태가 되면 다른 브로커들과 현재 활성 상태인 사용자에 대한 정보를 교환합니다. 새 브로커는 이 정보를 사용하여 클러스터에 완전히 통합됩니다.

구성 변경 기록은 클러스터에서 마스터 브로커로 지정된 브로커가 관리합니다. 마스터 브로커는 클러스터에 브로커를 동적으로 추가하는 데 핵심적인 역할을 하므로 항상 이 브로커를 먼저 시작해야 합니다. 마스터 브로커가 온라인이 아닌 경우 클러스터의 다른 브로커들은 초기화를 완료할 수 없습니다.

마스터 브로커가 오프라인이 되면 구성 변경 기록은 다른 브로커에서 액세스할 수 없으며, Message Queue는 대상 및 영구 가입이 클러스터에 전파되지 않게 합니다. 이 상태에서 대상이나 영구 가입을 작성하거나 삭제하려고 하면(또는 영구 가입 재활성화와 같은 다양한 관련 작업을 시도할 경우) 예외가 발생합니다.

중요한 응용 프로그램 환경에서는 구성 변경 기록을 정기적으로 백업하여 사고에 의한 기록 손상 및 마스터 브로커 오류를 방지하는 것이 바람직합니다. 구성 변경 기록을 비롯한 백업 파일 작성 방법을 제공하는 imqbrokerd 명령의 -backup 옵션을 사용하면 됩니다(표 5-2 참조). 나중에 -restore 옵션을 사용하여 구성 변경 기록을 복원할 수 있습니다.

필요하다면 마스터 브로커로 제공되는 브로커를 변경할 수 있습니다. 구성 변경 기록을 백업하고 해당 클러스터 구성 등록 정보(표 5-3 참조)를 수정하여 새 마스터 브로커를 지정하고 -restore 옵션을 사용하여 새 마스터 브로커를 다시 시작하면 됩니다.

개발 환경에서의 클러스터 사용

클러스터를 테스트 용도로 사용하고 확장성 및 브로커 복구를 심각하게 고려하지 않아도 되는 개발 환경에서는 마스터 브로커가 별로 필요하지 않습니다. 마스터 브로커 없이 구성된 환경에서 Message Queue는 다른 브로커를 시작하기 위해 마스터 브로커가 반드시 실행 중이어야 할 필요는 없으며, 대상 및 영구 가입을 변경할 수 있고 이 변경 사항은 클러스터에서 실행 중인 다른 모든 브로커에게 전파될 수 있습니다. 그러나 브로커가 오프라인되었다가 나중에 복원될 경우 오프라인 상태였을 때 변경된 사항은 동기화하지 않습니다.

테스트 환경에서는 일반적으로 대상은 자동 작성되고("자동 작성(대 관리 작성) 대상" 참조), 이 대상에 대한 영구 가입은 테스트 중인 응용 프로그램에서 작성하고 삭제합니다. 대상 및 영구 가입의 변경 사항은 클러스터 전체에 전파됩니다. 그러나 마스터 브로커를 사용하도록 환경을 재구성할 경우, Message Queue는 대상 및 영구 가입을 변경하고 이 변경 사항이 클러스터 전체에 전파되려면 마스터 브로커가 실행 중이어야 합니다.

클러스터 구성 등록 정보

클러스터의 각 브로커는 시작 시 클러스터의 다른 브로커에 대한 정보(호스트 이름 및 포트 번호)를 전달 받아야 합니다. 이 정보는 클러스터의 브로커간 연결을 설정할 때 사용합니다. 또한 마스터 브로커를 사용할 경우 각 브로커는 마스터 브로커의 호스트 이름 및 포트 번호를 알고 있어야 합니다.

클러스터의 모든 브로커는 공통 클러스터 구성 등록 정보를 사용해야 합니다. 이 등록 정보를 단일 중앙 클러스터 구성 파일에 저장하고 각 브로커가 시작할 때마다 이 파일을 참조하게 하면 됩니다.

또한 클러스터 구성 등록 정보를 복제하여 각 브로커에게 개별적으로 제공할 수 있습니다. 그러나 클러스터 구성의 일관성이 손상될 수 있으므로 바람직한 방법은 아닙니다. 클러스터 구성 등록 정보의 복사본을 하나만 유지하면 모든 브로커가 동일한 정보를 참조할 수 있습니다.

클러스터 구성 파일은 브로커 집합이 공통적으로 사용하는 모든 브로커 구성 등록 정보를 저장할 때 사용할 수 있습니다. 원래 클러스터를 구성하기 위해 만들어졌지만 클러스터의 모든 브로커에 공통적인 다른 브로커 등록 정보를 저장하는 용도로도 사용 가능합니다.

Message Queue 클라이언트 런타임

Message Queue 클라이언트 런타임은 클라이언트 응용 프로그램에 Message Queue 메시지 서비스와의 인터페이스를 제공합니다. 즉, Java 클라이언트 응용 프로그램에 "JMS 프로그래밍 모델"에서 소개한 모든 JMS 프로그래밍 객체를 제공하고 C 클라이언트 응용 프로그램에 해당 C 인터페이스를 제공합니다. Message Queue 클라이언트 런타임은 클라이언트가 대상에게 메시지를 보내고 대상으로부터 메시지를 받는 데 필요한 모든 작업을 지원합니다.

이 절에서는 Message Queue 클라이언트 런타임의 작동 방식을 간략하게 설명합니다. Java 클라이언트 런타임 및 C 클라이언트 런타임의 클라이언트 응용 프로그램 설계 및 성능에 영향을 미치는 요소는 각각 Message Queue Java Client Developer's Guide 및 Message Queue C Client Developer's Guide에 설명되어 있습니다.

그림 2-8은 메시지 생성 및 사용 시 클라이언트 응용 프로그램과 Message Queue 클라이언트 런타임 사이의 상호 작용 그리고 메시지 전달 시 Message Queue 클라이언트 런타임과 Message Queue 메시지 서버 사이의 상호 작용이 어떻게 이루어지는지 보여 줍니다.

메시지 생성

메시지 생성 단계에서는 클라이언트가 메시지를 작성하고 연결을 통해 브로커의 대상으로 전달합니다. MessageProducer 객체의 메시지 전달 모드가 지속성으로 설정된 경우(한 번씩만 전달), 메시지가 대상에 전달되고 브로커의 영구 데이터 저장소에 저장되었음을 브로커가 확인할 때까지 클라이언트 스레드가 차단됩니다. 메시지가 지속성을 갖지 않은 경우 브로커는 브로커 확인 메시지(등록 정보 이름에서 "Ack"라고 표시됨)를 보내지 않으며 클라이언트 스레드는 차단되지 않습니다.

메시지 사용

메시지 사용은 생성보다 더 복잡합니다. 브로커의 대상에 도착한 메시지는 다음 조건에서 Message Queue 클라이언트 런타임과의 연결을 통해 전달됩니다.

연결을 통해 전달된 메시지는 해당 Message Queue 세션으로 배포되고, 그림 2-9에서처럼 MessageConsumer 객체에 의해 사용될 때까지 대기합니다. 메시지는 각 세션 대기열에서 한 번에 하나씩 전송되며(세션은 단일 스레드로 구성) 동기식(receive 메소드를 호출하는 클라이언트 스레드를 통해) 또는 비동기식(MessageListener 객체의 onMessage 메소드를 호출하는 세션 스레드를 통해)으로 사용됩니다.

브로커가 클라이언트 런타임으로 메시지를 전달할 때 그에 따라 메시지에 표시하지만 실제로 수신 또는 사용되었는지 여부는 알 수 없습니다. 따라서 브로커는 브로커의 대상에서 메시지를 삭제하기 전에 클라이언트가 메시지 수신을 확인할 때까지 기다립니다.

Message Queue 관리 대상 객체

관리 대상 객체를 사용하면 클라이언트 응용 프로그램 코드는 공급자 독립성을 가질 수 있습니다. 이는 클라이언트 응용 프로그램이 공급자와 독립적인 방식으로 사용하는 객체에 공급자별 구현 및 구성 정보를 캡슐화하여 수행합니다. 관리 대상 객체는 관리자가 작성 및 구성하고 이름 서비스에서 저장하며 클라이언트 응용 프로그램이 표준 JNDI 조회 코드를 사용하여 액세스합니다.

Message Queue는 ConnectionFactory와 Destination의 2가지 관리 대상 객체 유형을 제공합니다. 두 객체 모두 공급자별 정보를 캡슐화하지만, 클라이언트 응용 프로그램 내부에서 그 용도는 매우 다릅니다. ConnectionFactory 객체는 메시지 서버와의 연결을 생성할 때 사용하며, Destination 객체는 물리적 대상을 식별할 때 사용합니다.

관리 대상 객체를 사용하면 Message Queue 메시지 서버를 매우 쉽게 제어하고 관리할 수 있습니다.

따라서 이러한 방법을 통해 Message Queue 관리자는 메시지 서버의 구성 세부 정보를 제어함과 동시에 클라이언트 응용 프로그램이 공급자 독립성을 갖도록 할 수 있습니다. 즉 클라이언트 응용 프로그램은 공급자별 구문 및 객체 이름 지정 규약("JMS 공급자 독립성" 참조) 또는 공급자별 구성 등록 정보를 알 필요가 없습니다.

7장, "관리 대상 객체 관리"에 설명된 것처럼 Message Queue 관리 도구를 사용하여 관리 대상 객체를 만듭니다. 관리 객체를 만들 때 읽기 전용으로, 즉 객체를 만들 때 설정한 Message Queue 특정 구성 값을 클라이언트 응용 프로그램에서 변경하지 못하도록 지정할 수 있습니다. 다시 말해 클라이언트 코드는 읽기 전용 관리 대상 객체에 대해 속성 값을 설정할 수 없으며, 관리자는 "클라이언트 시작 시 속성 값 무시"에서 설명하는 것처럼 응용 프로그램 시작 옵션을 사용하여 이 값을 무시할 수 없습니다.

클라이언트 응용 프로그램에서 ConnectionFactory와 Destination 관리 대상 객체 모두를 자체적으로 인스턴스화할 수 있지만, 이는 Message Queue 관리자가 응용 프로그램에서 필요로 하는 브로커 자원을 제어하고 그 성능을 조정하게 하려는 관리 대상 객체의 기본 목표에 어긋납니다. 또한 관리 대상 객체를 직접 인스턴스화하면 클라이언트 응용 프로그램은 공급자 독립성을 갖기 보다는 공급자별 특성을 갖게 됩니다.

연결 팩토리 관리 대상 객체

ConnectionFactory 객체는 클라이언트 응용 프로그램과 Message Queue 메시지 서버 사이의 물리적 연결을 설정하는 데 사용합니다. 또한 연결 및 이 연결을 사용하여 브로커에 액세스하는 클라이언트 런타임의 동작을 지정하는 데에도 사용합니다.

분산 트랜잭션을 지원하려면("로컬 트랜잭션" 참조) 분산 트랜잭션을 지원하는 특정 XAConnectionFactory 객체를 사용해야 합니다.

ConnectionFactory 관리 대상 객체를 만들려면 "연결 팩토리 추가"를 참조하십시오.

ConnectionFactory 관리 대상 객체를 구성하여 이 객체가 생성하는 모든 연결에 공통적인 속성 값(등록 정보)을 지정할 수 있습니다. ConnectionFactory 및XAConnectionFactory 객체는 동일한 속성 집합을 갖습니다. 이 속성들은 영향을 미치는 동작에 따라 여러 범주로 그룹화됩니다.

각 범주와 관련 속성은 Message Queue Java Client Developer's Guide에서 자세히 다룹니다. Message Queue 관리자로서 이 속성 값을 조정해야 하는 경우가 있지만, 일반적으로 클라이언트 응용 프로그램의 성능 조정을 위해 어떤 속성을 조정할 것인가는 응용 프로그램 개발자가 결정합니다. 표 7-3은 이 속성을 알파벳 순서로 요약합니다.

대상 관리 대상 객체

Destination 관리 대상 객체는 브로커상에서 공개적으로 명명된 Destination 객체에 해당되는 물리적 대상(대기열이나 주제)을 의미합니다. 그 2가지 속성을 표 2-11에서 확인할 수 있습니다. Destination 객체를 만들어 클라이언트 응용 프로그램의 MessageConsumer 및/또는 MessageProducer 객체가 그 물리적 대상에 액세스하게 할 수 있습니다.

클라이언트 시작 시 속성 값 무시

모든 Java 응용 프로그램처럼 명령줄에서 시스템 등록 정보를 지정하여 메시징 응용 프로그램을 시작할 수 있습니다. 또한 이 메커니즘은 클라이언트 응용 프로그램 코드에서 사용하는 관리 대상 객체의 속성 값을 무시할 때 사용할 수 있습니다. 예를 들어 클라이언트 응용 프로그램 코드 중 JNDI 조회를 통해 액세스하는 관리 대상 객체 구성을 무시할 수 있습니다.

클라이언트 응용 프로그램 시작 시 관리 대상 객체 설정을 무시하려면 다음 명령줄 구문을 사용합니다.

표 2-11 대상 속성
속성/등록 정보 이름	설명
imqDestinationName	물리적 대상의 공급자별 이름을 지정합니다. 물리적 대상을 만들 때 이 이름을 지정합니다. 대상 이름은 영숫자(공백 없음)만 포함하고 영문자나 "_" 및 "$" 문자로 시작할 수 있습니다. "mq" 문자열로는 시작할 수 없습니다. 기본값: Untitled_Destination_Object
imqDestinationDescription	객체 관리에 유용한 정보를 지정합니다. 기본값: 대상 객체 설명

예를 들어 클라이언트 코드에서 액세스하는 ConnectionFactory 관리 대상 객체에 지정된 브로커가 아닌 다른 브로커에 클라이언트 응용 프로그램을 연결하려면 명령줄 무시를 통해 다른 브로커의 imqBrokerHostName 및 imqBrokerHostPort를 설정하여 클라이언트 응용 프로그램을 시작할 수 있습니다.

그러나 관리 대상 객체가 읽기 전용으로 설정된 경우 그 속성 값은 명령줄 무시로 변경할 수 없습니다. 그러한 무시는 적용되지 않습니다.

이전 목차 색인 다음
Sun Java System Message Queue 3.5 SP1 관리 설명서