|
| Sun ONE Message Queue, 버전 3.0.1 관리자 설명서 |
이 장에서는 그림 2-1에서 보여주는 시스템의 주요 부분에 중점을 두고 Sun™ ONE Message Queue (MQ) 메시징 시스템에 대해 소개합니다. 또한 각 부분이 어떻게 상호 작용하면서 안정적인 메시지 전달을 제공하는지 설명합니다.
그림 2-1 MQ 시스템 구조
그림 2-1에서 보여주는 MQ 메시징 시스템의 주요 부분은 다음과 같습니다.
- MQ 메시지 서버
- MQ 클라이언트 런타임
- MQ 관리 객체
- MQ 관리
첫 세 항목에 대해서는 다음 절에서 다룹니다. 마지막 항목은 3장, "MQ 관리"에서 소개합니다.
MQ 메시지 서버
이 절에서는 그림 2-1에서 보여주는 MQ 메시지 서버의 다양한 부분을 설명합니다. 여기에는 다음 항목이 포함됩니다.
브로커 MQ 브로커는 MQ 메시징 시스템의 전달 서비스를 제공합니다. 메시지 전달은 연결 서비스, 메시지 경로 지정 및 전달, 지속성, 보안 및 로깅을 처리하는 수많은 지원 구성 요소에 따라 달라집니다(자세한 정보는 "브로커" 참조). 메시지 서버는 하나 이상의 브로커 인스턴스를 사용할 수 있습니다("다중 브로커 클러스터(엔터프라이즈판)" 참조).
물리적 대상 메시지 전달은 생성자 클라이언트에서 브로커가 관리하는 물리적 대상으로의 전달 그리고 대상에서 하나 이상의 사용자 클라이언트로의 전달의 2단계로 구성되는 과정입니다. 물리적 대상은 브로커의 물리적 메모리 및/또는 영구 저장소에서의 위치를 나타냅니다(자세한 정보는 "물리적 대상" 참조).
브로커
MQ 메시징 시스템의 메시지 전달, 즉 생성자 클라이언트에서 대상까지의 전달 그리고 대상에서 하나 이상의 사용자 클라이언트까지의 전달은 브로커(또는 탠덤으로 작동하는 브로커 인스턴스로 구성된 클러스터)가 수행합니다. 메시지 전달을 수행하려면 브로커가 클라이언트와 통신 채널을 설정하고, 인증 및 권한 부여를 수행하며, 메시지 경로를 올바르게 지정하고, 안정적인 전달을 보장하며, 시스템 성능을 모니터링할 데이터를 제공해야 합니다.
이렇게 복잡한 기능들을 수행하기 위해 브로커는 각각의 전달 과정에서 특별한 역할을 맡는 다양한 구성 요소를 사용합니다. 로드 상태, 응용 프로그램 복잡성 등에 따라 브로커 성능을 최적화하도록 이 내부 구성 요소들을 구성할 수 있습니다. 주요 브로커 구성 요소는 그림 2-2에서 확인할 수 있으며, 표 2-1에서도 간략히 설명합니다.
그림 2-2 브로커 구성 요소
다음 절에서는 다양한 브로커 구성 요소가 수행하는 기능 및 그 동작에 영향을 주도록 구성 가능한 등록 정보를 더 자세히 살펴 봅니다.
연결 서비스
MQ 브로커는 JMS 클라이언트와 MQ 관리 클라이언트와의 통신을 모두 지원합니다("MQ 관리 도구" 참조). 각 서비스는 서비스 유형 및 프로토콜 유형을 통해 지정됩니다.
서비스 유형 서비스가 JMS 메시지 전달(NORMAL)을 제공하는지 또는 MQ 관리(ADMIN) 서비스를 제공하는지 지정합니다.
프로토콜 유형 서비스를 지원하는 기본 전송 프로토콜 계층을 지정합니다.
현재 MQ 브로커에서 사용 가능한 연결 서비스는 표 2-2에서 확인할 수 있습니다.
이 연결 서비스 중 어느 것이라도 또는 전부 실행하도록 브로커를 구성할 수 있습니다. 각 서비스는 그림 2-3과 같이 스레드 풀 관리자가 있으며 공통 포트 매퍼 서비스에 해당 서비스를 등록합니다.
그림 2-3 연결 서비스 지원
각 연결 서비스는 특정 포트에서 사용 가능하며, 브로커의 호스트 이름과 포트 번호로 지정됩니다. 포트는 정적으로 또는 동적으로 할당할 수 있습니다. MQ는 동적으로 할당된 포트를 여러 연결 서비스와 매핑하는 포트 매퍼를 제공합니다. 포트 매퍼 자체는 표준 포트 번호 7676에 위치합니다. 클라이언트가 브로커와 연결을 설정할 때 이 클라이언트는 먼저 포트 매퍼에 접속하여 원하는 연결 서비스의 포트 번호를 요청합니다.
또한 jms, ssljms, admin 및 ssladmin 연결 서비스에 대해 이 연결 서비스를 구성할 때 정적 포트 번호를 지정할 수 있지만, 권장되는 방법은 아닙니다. httpjms 및 httpsjms 서비스는 각각 부록 B, "HTTP/HTTPS 지원(엔터프라이즈판)"에서 표 B-1과 표 B-3에 설명되어 있는 등록 정보를 사용하여 구성합니다.
각 연결 서비스는 다중 스레드 방식으로서, 다중 연결을 지원합니다. 이 연결에 필요한 스레드는 스레드 풀 관리자 구성 요소가 관리하는 스레드 풀에서 유지 관리됩니다. 스레드 풀 관리자를 구성하여 스레드 풀에서 유지 관리되는 최소 스레드 수와 최대 스레드 수를 설정할 수 있습니다. 연결 시 스레드가 필요하면 스레드 풀에 해당 스레드가 추가됩니다. 최소 수를 초과할 경우, 시스템은 최소 수 임계값에 도달할 때까지 스레드를 종료시켜 여유 스레드를 확보하는 방법으로 메모리 자원을 절약합니다. 새 스레드가 계속 작성될 필요가 없도록 이 값을 충분히 크게 설정할 수 있습니다. 연결 로드가 많은 경우, 스레드 풀의 최대 수에 도달할 때까지 스레드 수가 증가하기도 합니다. 그 후 스레드가 사용 가능해질 때까지 연결은 대기합니다.
스레드 풀의 스레드는 단일 연결 전용으로 사용되거나(전용 모델) 필요에 따라 여러 연결에 지정될 수 있습니다(공유 모델).
전용 모델 전용 모델에서는 브로커와의 연결마다 받는 메시지 처리 전용과 보내는 메시지 처리 전용의 2개 스레드가 필요합니다. 따라서 연결 수가 스레드 풀에 있는 최대 스레드 수의 절반으로 제한되지만, 이 방법은 우수한 성능을 제공합니다.
공유 모델(엔터프라이즈판) 공유 스레드 모델에서는 메시지를 보내거나 받을 때에만 스레드에 연결이 지정됩니다. 연결 시 스레드를 공유하는 이 모델에서는 연결 서비스(브로커)가 지원하는 연결의 수는 늘어나지만, 어느 정도의 성능 오버헤드가 발생합니다. 스레드 풀 관리자는 연결 활동을 모니터링하고 필요에 따라 스레드에 연결을 지정하는 분산자 스레드 집합을 사용합니다. 각 분산자 스레드가 모니터링하는 연결 수를 제한하여 성능을 높일 수 있습니다.
각 연결 서비스는 특정 인증 및 권한 부여(액세스 제어) 기능을 지원합니다("보안 관리자" 참조).연결 서비스와 관련하여 구성 가능한 등록 정보는 표 2-3에서 확인할 수 있습니다(등록 정보 구성 지침은 5장, "브로커 시작 및 구성" 참조).
표 2-3 연결 서비스 등록 정보
등록 정보 이름
설명
imq.service.activelist
브로커 시작 시 활성화되는 쉼표로 구분된 이름별 연결 서비스 목록입니다. 지원되는 서비스: jms, ssljms, httpjms, httpsjms, admin, ssladmin. 기본값: jms, admin
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
공유 스레드 풀 모델에 한해 분산자 스레드가 모니터링할 수 있는 최대 연결 수를 지정합니다(시스템은 모든 연결을 모니터링하기에 충분한 수의 분산자 스레드를 할당). 이 값이 작을수록 시스템은 더 신속하게 스레드에 활성 연결을 지정할 수 있습니다. 값 0은 제한이 없음을 의미합니다. 기본값: 운영 체제에 따라 다릅니다(표 5-1 참조).
imq.portmapper.port
브로커의 기본 포트, 즉 포트 매퍼가 위치한 포트입니다. 한 호스트에서 둘 이상의 브로커 인스턴스를 실행하는 경우 각 인스턴스는 고유한 포트 매퍼 포트를 지정 받아야 합니다. 기본값: 7676
imq.service_name.
protocol_type1.port
jms, ssljms, admin 및 ssladmin 서비스에 한해 명명된 연결 서비스의 포트 번호를 지정합니다. 기본값: 0 (포트 매퍼가 동적으로 포트를 할당)
httpjms 및 httpsjms 연결 서비스를 구성하려면 부록 B, "HTTP/HTTPS 지원(엔터프라이즈판)"을 참조하십시오.
imq.service_name.
protocol_type1.hostname
jms, ssljms, admin 및 ssladmin 서비스에 한해, 사용 가능한 호스트가 두 개 이상 있는 경우(예: 컴퓨터에 네트워크 인터페이스 카드가 두 개 이상인 경우) 명명된 연결 서비스를 바인드할 호스트(호스트 이름 또는 IP 주소)를 지정합니다.
기본값: null (모든 호스트)
1protocol_type은 표 2-2에 나와 있습니다. 메시지 라우터
지원되는 연결 서비스를 사용하여 클라이언트와 브로커 사이에 연결이 설정되면 경로 지정 및 메시지 전달을 할 수 있습니다.
기본적인 전달 메커니즘
포괄적으로 말하자면, 브로커가 처리하는 메시지는 생성자 클라이언트가 사용자 클라이언트를 대상으로 보내는 페이로드 메시지인 JMS 메시지 그리고 JMS 메시지 전달을 지원하고자 클라이언트를 오가는 수많은 제어 메시지의 2가지 범주로 구분됩니다.
받는 메시지가 JMS 메시지인 경우 브로커는 대상 유형(대기열 또는 주제)에 따라 사용자 클라이언트로 경로를 지정합니다.
- 대상이 주제라면 JMS 메시지는 해당 주제의 모든 활성 가입자로 향하는 경로를 즉시 지정합니다. 비활성 영구 가입자의 경우, 메시지 라우터는 메시지를 보관했다가 해당 가입자가 활성 상태가 되면 전달합니다.
- 대상이 대기열이라면 JMS 메시지는 해당 대기열로 들어가고, 대기열의 맨 앞에 도달하는 시점에 해당 사용자에게 전달됩니다. 메시지가 대기열의 맨 앞에 도달하는 순서는 도착 순서 및 우선 순위에 따라 결정됩니다.
메시지 라우터가 목표한 모든 사용자에게 메시지를 전달했다면 메시지 라우터는 메모리에서 해당 메시지를 삭제합니다. 지속성 메시지인 경우("안정적인 메시징" 참조) 브로커의 영구 데이터 저장소에서 해당 메시지를 제거합니다.
안정적인 전달: 확인 및 트랜잭션
지금까지 설명한 전달 메커니즘은 안정적인 전달("안정적인 메시징" 참조)을 위한 요구 사항이 추가될 경우 더 복잡해집니다. 안정적인 전달에는 브로커를 오가는 메시지 전달이 성공적으로 이루어지게 하고 실제 메시지 전달 이전에 브로커가 메시지나 전달 정보를 잃어버리지 않게 하는 2가지 측면이 있습니다.
브로커를 오가는 메시지가 성공적으로 전달되도록 하기 위해 MQ는 확인이라고 하는 다양한 제어 메시지를 사용합니다.
예를 들어, 생성자가 어떤 대상으로 JMS 메시지(제어 메시지와 반대되는 페이로드 메시지)를 보낼 때 브로커는 JMS 메시지 수신을 확인하는 제어 메시지인 브로커 확인을 회신합니다(실제로는 생성자가 JMS 메시지를 지속성 메시지로 지정한 경우에만 MQ가 이 기능을 수행함). 생성자 클라이언트는 브로커 확인을 통해 대상에게 확실히 전달되도록 합니다("메시지 생성" 참조).
그와 비슷하게 브로커가 사용자에게 JMS 메시지를 전달할 경우, 사용자 클라이언트는 해당 메시지를 수신 및 처리했음을 알리는 확인을 회신합니다. 클라이언트는 세션 객체 작성 시 이 확인을 얼마나 자동으로 또는 얼마나 자주 보낼 것인지 지정하지만, 원칙상 메시지 라우터는 자신이 메시지를 전달했던 각 메시지 사용자로부터 확인을 받지 않은 경우(예: 여러 가입자 각각으로부터 한 주제로) 해당 JMS 메시지를 메모리에서 삭제하지 않습니다.
어떤 주제에 대한 영구 가입자의 경우, 메시지 라우터는 각 JMS 메시지를 대상에 보존하고 각 영구 가입자가 활성 사용자가 되면 메시지를 전달합니다. 메시지 라우터는 클라이언트 확인을 수신하여 이를 기록하고, (그 전까지 JMS 메시지가 만료되지 않는 한) 모든 확인을 수신한 후에야 JMS 메시지를 삭제합니다.
또한 메시지 라우터는 클라이언트에게 브로커 확인을 회신함으로써 클라이언트 확인을 받았음을 알립니다. 사용자 클라이언트는 브로커 확인을 통해 브로커가 JMS 메시지를 2회 이상 전달하지 않도록 합니다("메시지 사용" 참조). 이는 어떤 이유로 브로커가 클라이언트 확인을 받지 못한 경우에 발생할 수 있습니다.
브로커가 클라이언트 확인을 받지 않고 JMS 메시지를 두번째 전달하는 경우, 메시지에 재전송 플래그가 표시됩니다. 일반적으로 브로커가 클라이언트 확인을 받기 전에 클라이언트 연결이 끊기고 이어서 새 연결이 설정되면 브로커는 JMS 메시지를 재전송합니다. 예를 들어 메시지 확인을 받기 전에 대기열의 메시지 사용자가 오프라인되고 이어서 다른 사용자가 해당 대기열에 등록하면 브로커는 미확인된 메시지를 새 사용자에게 재전송합니다.
위에서 설명한 클라이언트와 브로커 확인 과정은 JMS 메시지 전달이 트랜잭션으로 그룹화된 경우에도 적용됩니다. 이 경우 클라이언트와 브로커 확인은 개별 JMS 메시지 송수신 수준뿐 아니라 트랜잭션 수준에서도 수행됩니다. 트랜잭션이 완결되면 브로커 확인이 자동으로 보내집니다.
브로커는 트랜잭션을 추적하면서 트랜잭션 완결 또는 실패 시 롤백이 가능하게 합니다. 또한 이 트랜잭션 관리는 더 큰 규모의 분산 트랜잭션에 포함되는 로컬 트랜잭션을 지원합니다("분산 트랜잭션" 참조). 브로커는 트랜잭션이 완결될 때까지 그 상태를 추적합니다. 브로커가 시작되면 이 브로커는 아직 완결되지 않은 모든 트랜잭션을 검사하며, PREPARED 상태의 트랜잭션을 제외하고 모든 트랜잭션을 롤백하도록 기본 설정되어 있습니다.
안정적인 전달: 지속성
안정적인 전달의 또 다른 측면은 실제로 메시지가 전달될 때까지 브로커가 메시지나 전달 정보를 잃어버리지 않게 하는 것입니다. 일반적으로 메시지는 전달되거나 만료될 때까지 메모리에 남아 있습니다. 그러나 브로커가 실패할 경우 이 메시지는 손실됩니다.
생성자 클라이언트는 메시지가 지속성을 갖도록 지정할 수 있으며, 이 경우 메시지 라우터는 데이터베이스나 파일 시스템에 메시지를 저장하는 지속성 관리자에게 메시지를 전달하여("지속성 관리자" 참조) 브로커 실패 시 메시지가 복구될 수 있게 합니다.
시스템 자원 관리
브로커의 성능은 사용 가능한 시스템 자원 그리고 메모리와 같은 자원이 얼마나 효율적으로 활용되는가에 따라 달라집니다. 예를 들어 메시지 라우터는 시스템 상의 메모리를 살펴보는 메모리 관리 메커니즘을 가지고 있습니다. 메모리 자원이 부족해지면 메모리를 확보하고 받는 메시지 속도를 낮추는 메커니즘이 활성화됩니다.
메모리 관리 메커니즘은 메모리 자원 상태, 즉 초록(사용 가능 메모리 충분), 노랑(브로커 메모리 감소 중), 주황(브로커 메모리 부족) 및 빨강(브로커 메모리 부족)에 따라 달라집니다. 메모리 자원 상태가 초록에서 노랑 및 주황을 거쳐 빨강으로 바뀌면 브로커는 메모리를 확보하고 메시지 생성자를 계속해서 억제한 뒤 결국 브로커로 향하는 메시지 흐름을 중지시킵니다.
메모리의 메시지 총 수 및 총 크기를 제한하고 메모리 자원이 새로운 상태로 바뀌는 사용 임계값을 조정하는 등록 정보를 사용하여 브로커의 메모리 관리 기능을 구성할 수 있습니다.
이 등록 정보는 표 2-4에서 자세히 설명합니다(등록 정보 설정 지침은 5장, "브로커 시작 및 구성" 참조).
표 2-4 메시지 라우터 등록 정보
등록 정보 이름
설명
imq.message.expiration.
interval
만료된 메시지 재생 이용이 발생하는 빈도를 초 단위로 지정합니다. 기본값: 60
imq.system.max_count
(스왑 때문에) 메모리와 디스크 모두에 위치한 메시지의 최대 수를 지정합니다. 추가 메시지가 거부됩니다. 값 0은 제한이 없음을 의미합니다. 기본값: 0
imq.system.max_size
(스왑 때문에) 메모리와 디스크 모두에 위치한 메시지의 총 크기(바이트, KB, MB 단위)를 지정합니다. 추가 메시지가 거부됩니다. 값 0은 제한이 없음을 의미합니다. 기본값: 0
imq.message.max_size
메시지 본문의 최대 허용 크기(바이트, KB, MB 단위)를 지정합니다. 이 크기를 초과하는 메시지는 거부됩니다. 값 0은 제한이 없음을 의미합니다. 기본값: 70m (MB)
imq.resource_state.
threshold
각 메모리 자원 상태가 트리거되는 메모리 사용률을 지정합니다. 자원 상태는 초록, 노랑, 주황 및 빨강으로 표시됩니다. 기본값: 각각 0, 60, 75, 90
imq.redelivered.
optimization
메시지가 재전송될 때마다(true) 또는 논리적으로 필요한 경우에 한해(false) 메시지 라우터가 재전송 플래그를 설정하여 성능을 최적화하는지 지정합니다(true/false). 기본값: true
imq.transaction.
autorollback
PREPARED 상태에 있는 분산 트랜잭션이 브로커 시작 시 자동으로 롤백되는지 여부를 지정합니다(true/false). false라면 imqcmd를 사용하여 수동으로 트랜잭션을 완결하거나 롤백해야 합니다("트랜잭션 관리" 참조). 기본값: false
지속성 관리자
오류 발생 시 브로커를 복구하려면 메시지 전달 작업 상태를 다시 작성해야 합니다. 그러기 위해서는 모든 지속성 메시지와 기본적인 경로 지정 및 전달 정보를 데이터 저장소에 저장해야 합니다. 지속성 관리자 구성 요소는 이 정보의 작성 및 검색을 관리합니다.
실패한 브로커를 복구하려면 전달되지 못한 메시지를 복원하는 것 이상의 작업이 필요합니다. 또한 브로커는 다음을 수행할 수 있어야 합니다.
- 대상 다시 작성
- 각 주제의 영구 가입 목록 복원
- 각 메시지의 확인 목록 복원
- 완결된 모든 트랜잭션 상태 복제
지속성 관리자는 이 모든 상태 정보의 저장 및 복원을 관리합니다.
브로커가 다시 시작되면 대상 및 영구 가입을 다시 작성하고 지속성 메시지를 복구하며 모든 트랜잭션의 상태를 복원하고 전달되지 못한 메시지의 경로 지정 테이블을 다시 작성합니다. 그런 다음 메시지 전달을 다시 시작할 수 있습니다.
MQ는 기본 제공 및 플러그 인 지속성 모듈을 모두 지원합니다(그림 2-4 참조). 기본 제공 지속성은 플랫 파일 데이터 저장소를 기반으로 합니다. 플러그 인 지속성은 JDBC (Java Database Connectivity) 인터페이스를 사용하며 JDBC 호환 데이터 저장소가 필요합니다. 일반적으로 기본 제공 지속성은 플러그 인 지속성보다 더 빠릅니다. 그러나 JDBC 호환 데이터베이스 시스템 사용의 중복 및 관리 기능을 선호하는 사용자도 있습니다.
그림 2-4 지속성 관리자 지원
기본 제공 지속성
기본 MQ 영구 저장소 솔루션은 플랫 파일 저장소입니다. 이 방법에서는 개별 파일을 사용하여 메시지, 대상, 영구 가입, 트랜잭션과 같은 지속성 데이터를 저장합니다.
플랫 파일 데이터 저장소의 위치는 다음과 같습니다.
여기서 brokerName은 브로커 인스턴스를 식별하는 이름입니다.
IMQ_VARHOME/instances/brokerName/filestore/
(Solaris의 경우 /var/imq/instances/brokerName/filestore/)파일 기반 데이터 저장소는 지속성 메시지가 각자 해당 파일에 저장되도록, 즉 파일당 메시지 하나씩 포함하도록 구성됩니다. 그러나 대상, 영구 가입 및 트랜잭션은 모두 하나의 개별 파일에, 즉 모든 대상은 하나의 파일에, 모든 영구 가입은 또 다른 파일에 저장됩니다.
데이터 저장소에 메시지가 추가되고 삭제되면서 파일을 작성하고 삭제하려면 고비용의 파일 시스템 작업이 필요합니다. 따라서 MQ 구현에서는 이 메시지 파일을 재사용합니다. 어떤 파일이 더 이상 필요 없어지면 삭제하는 대신 재사용 가능 파일 풀에 추가됩니다. 이 파일 풀의 크기를 구성할 수 있습니다. 또한 재사용 태그 표시(잘라내지 않음)와 반대되는 개념으로 파일 풀에서 지울(0으로 잘라냄) 사용 가능 파일의 비율을 지정할 수 있습니다. 지운 파일의 비율이 높을수록 파일 풀 관리에 필요한 디스크 공간은 더 줄어들지만 더 많은 오버헤드가 필요합니다. 또한 종료 시 태그가 표시된 파일을 지울 것인지 여부도 지정할 수 있습니다. 파일을 지우면 디스크 공간은 덜 차지하지만, 브로커 종료 속도가 느려집니다.
플랫 파일 저장소에서의 메시지 저장 속도는 데이터 저장소가 사용 가능한 파일 설명자의 수에 따라 달라집니다. 설명자가 많으면 시스템은 많은 양의 지속성 메시지를 더 빨리 처리할 수 있습니다. 파일 설명자 수를 늘리는 것에 대한 정보는 MQ 릴리스 노트의 "기술 노트" 절을 참조하십시오.
또한 대상 파일 저장소의 경우 대상이 추가되면 파일 크기를 늘리는 방법보다는 특정 크기의 파일에 대상을 추가하는 것이 더 효율적입니다. 따라서 최종적으로 저장할 대상의 수를 예상하여 대상 파일의 원래 크기를 설정하면 성능을 높일 수 있습니다(각 대상은 약 500바이트 사용).
데이터 저장소에는 소유 정보가 포함된 메시지가 있을 수 있으므로 brokerName/filestore/ 디렉토리는 인증되지 않은 액세스로부터 보호하는 것이 바람직합니다. 자세한 지침은 MQ 릴리스 노트의 "기술 노트" 절을 참조하십시오.
플러그 인 지속성
JDBC 드라이버를 통해 액세스 가능한 데이터 저장소를 모두 액세스하도록 브로커를 설정할 수 있습니다. 이 경우 여러 JDBC 관련 브로커 구성 등록 정보를 설정하고 데이터베이스 관리자 유틸리티(imqdbmgr)를 사용하여 적합한 체계를 갖는 데이터 저장소를 만들어야 합니다. 절차 및 관련 구성 등록 정보는 부록 A, "플러그 인 지속성 설정"을 참조하십시오.
지속성 관련 구성 등록 정보는 표 2-5를 참조하십시오(등록 정보 설정 지침은 5장, "브로커 시작 및 구성" 참조).
보안 관리자
MQ는 인증 및 권한 부여(액세스 제어) 기능을 제공하며 암호화 기능도 지원합니다.
인증 및 권한 부여 기능은 사용자 저장소(그림 2-5 참조), 즉 메시징 시스템 사용자에 대한 정보(예: 아이디, 비밀번호, 그룹 멤버쉽)를 포함하는 파일, 디렉토리 또는 데이터베이스에 따라 달라집니다. 아이디와 비밀번호는 브로커와의 연결 요청 시 사용자를 인증할 때 사용됩니다. 대상에 대한 메시지 생성/사용과 같은 작업 권한을 부여할 때 아이디와 그룹 멤버쉽이 액세스 제어 파일과 함께 사용됩니다.
MQ 관리자는 MQ 제공 사용자 저장소("플랫 파일 사용자 저장소 사용" 참조)를 채우거나 기존 LDAP 사용자 저장소를 보안 관리자 구성 요소에 플러그 인합니다. 플랫 파일 사용자 저장소는 쉽게 사용할 수 있지만 보안 공격에 취약하므로 평가 및 개발 용도에 한해 사용해야 합니다. 반면 LDAP 사용자 저장소는 안전하므로 작업 환경에 가장 적합합니다.
인증
MQ 보안은 비밀번호 기반의 인증을 지원합니다. 클라이언트가 브로커와의 연결을 요청할 경우 이 클라이언트는 아이디와 비밀번호를 제출해야 합니다. 보안 관리자는 클라이언트가 제출한 아이디와 비밀번호를 사용자 저장소에 저장된 정보와 비교합니다. 클라이언트가 브로커에게 비밀번호를 전송할 때 이 비밀번호는 기본 64 인코딩이나 메시지 다이제스트(MD5) 중 한 가지를 사용하여 암호화됩니다. 보다 안전한 전송에 대해서는 "암호화(엔터프라이즈판)"를 참조하십시오. 별도로 각 연결 서비스가 사용하는 인코딩 유형을 구성하거나 브로커 전체에 대한 인코딩을 설정할 수 있습니다.
권한 부여
클라이언트 응용 프로그램 사용자가 인증되면 이 사용자는 여러 MQ 관련 작업을 수행할 권한을 갖습니다. 보안 관리자는 사용자 기반 및 그룹 기반 액세스 제어를 모두 지원합니다. 사용자 저장소에 있는 아이디 또는 해당 사용자가 속한 그룹에 따라 이 사용자는 특정 MQ 작업을 수행할 권한을 갖습니다. 액세스 제어 등록 정보 파일에서 이 액세스 제어를 지정합니다(그림 2-5 참조).
사용자가 어떤 작업을 수행하려 하면 보안 관리자는 (액세스 제어 등록 정보 파일에 있는) 해당 작업 액세스를 위해 지정된 아이디/그룹 멤버쉽을 (사용자 저장소에 있는) 아이디/그룹 멤버쉽과 대조 확인합니다. 액세스 제어 등록 정보 파일은 다음 작업에 대한 권한을 지정합니다.
- 브로커와의 연결 설정
- 대상에 액세스: 사용자, 생성자 또는 특정 대상이나 모든 대상에 대한 대기열 브라우저 작성
- 대상 자동 작성
그림 2-5 보안 관리자 지원
MQ 3.0.1에서는 기본 액세스 제어 등록 정보 파일이 admin이라는 단일 그룹만 명시적으로 참조합니다("그룹" 참조). admin 그룹의 사용자는 관리 서비스 연결 권한을 갖습니다. 관리 서비스 사용자는 대상 작성, 브로커 모니터링 및 제어와 같은 관리 기능을 수행할 수 있습니다. 다른 그룹으로 정의된 사용자는 기본적으로 관리 서비스 연결 권한을 가질 수 없습니다.
MQ 관리자는 사용자 저장소에서 그룹 및 이 그룹의 사용자를 정의할 수 있습니다
(단, 플랫 파일 사용자 저장소에서는 그룹 기능이 완전히 지원되지 않음). 그런 다음 액세스 제어 등록 정보 파일을 편집하여 메시지 생성 및 사용 또는 대기열 대상에서의 메시지 찾아보기 목적으로 대상에 대한 액세스를 사용자 및 그룹별로 지정할 수 있습니다. 개별 대상이나 모든 대상에 대한 액세스 권한을 특정 사용자나 그룹에게만 부여할 수 있습니다.또한 브로커가 대상을 자동으로 작성할 수 있도록 구성된 경우("자동 작성(대 관리 작성) 대상" 참조), 액세스 제어 등록 정보 파일을 편집하여 브로커가 특정 사용자를 위해 대상을 자동으로 작성할 수 있도록 제어할 수 있습니다.
암호화(엔터프라이즈판)
클라이언트와 브로커 사이에 전송되는 메시지를 암호화하려면 Secure Socket Layer (SSL) 표준 기반의 연결 서비스를 사용해야 합니다. SSL은 SSL 사용 가능 브로커와 SSL 사용 가능 클라이언트 사이에 암호화된 연결을 설정함으로써 연결 수준에서의 보안을 제공합니다.
MQ SSL 기반 연결 서비스를 사용하기 위해 키 도구 유틸리티(imqkeytool)를 사용하여 개인 키/공용 키 쌍을 생성합니다. 이 유틸리티는 자체 서명된 인증서에 공용 키를 내장하고 이를 MQ 키 저장소에 저장합니다. MQ 키 저장소 자체도 비밀번호로 보호됩니다. 이 잠금을 해제하려면 시작할 때 키 저장소 비밀번호를 제공해야 합니다. "암호화: 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)를 설정합니다. 액세스 제어 등록 정보 파일에 지정된 대로 인증된 사용자가 연결 서비스를 사용하거나 특정 대상에 대해 특정 MQ 작업을 수행할 권한이 있는가를 시스템이 확인할 것인지 여부를 표시합니다. 기본값: true
imq.service_name.
accesscontrol.enabled
명명된 연결 서비스의 액세스 제어를 설정하며 (true/false), 이 값은 브로커 전체에 대한 설정을 무시합니다. 액세스 제어 등록 정보 파일에 지정된 대로 인증된 사용자가 명명된 연결 서비스를 사용하거나 특정 대상에 대해 특정 MQ 작업을 수행할 권한이 있는가를 시스템이 확인할 것인지 여부를 표시합니다.
기본값: imq.accesscontrol.enabled 등록 정보의 설정을 상속합니다.imq.accesscontrol.file.
filename
브로커가 지원하는 모든 연결 서비스에 대한 액세스 제어 등록 정보 파일의 이름을 지정합니다. 파일 이름은 IMQ_HOME/etc (Solaris의 경우 /etc/imq) 디렉토리에 대한 상대 파일 경로를 지정합니다.
기본값: accesscontrol.propertiesimq.service_name.
accesscontrol.file.
filename
명명된 연결 서비스의 액세스 제어 등록 정보 파일 이름을 지정합니다. 파일 이름은 IMQ_HOME/etc (Solaris의 경우 /etc/imq) 디렉토리에 대한 상대 파일 경로를 지정합니다.
기본값: imq.accesscontrol.file.filename에서 지정한 설정을 상속합니다.imq.passfile.enabled
안전한 통신을 위한 사용자 비밀번호(SSL, LDAP, JDBC)가 passfile에 설정되는지 여부를 지정합니다(true/false).
기본값: falseimq.passfile.dirpath
passfile을 포함하는 디렉토리 경로를 지정합니다.
기본값: Solaris의 경우 IMQ_HOME/etc (/etc/imq)imq.passfile.name
passfile 이름을 지정합니다. 기본값: passfile
imq.keystore.property_name
SSL 기반 서비스에 대해 SSL 키 저장소와 관련된 보안 등록 정보를 지정합니다. 표 8-8을 참조하십시오.
로거
브로커는 로그 작업을 모니터링하고 진단할 다양한 구성 요소를 포함합니다. 그 중에는 데이터를 생성하는 구성 요소(브로커 코드, 메트릭 생성기, 디버거)가 있으며 또한 다양한 출력 채널(로그 파일, 콘솔, Solaris syslog)을 통해 정보를 기록하는 로거 구성 요소가 있습니다. 그림 2-6은 그러한 체계를 보여줍니다.
그림 2-6 로깅 체계
메트릭 데이터 생성을 설정 또는 해제하고 메트릭 보고서 생성 빈도를 지정할 수 있습니다.
또한 가장 심각하고 중요한 정보(오류)부터 상대적으로 중요도가 낮은 정보(메트릭 데이터)까지 로거 수준을 지정할 수 있습니다. 표 2-7은 정보 범주를 심각도 내림차순으로 표시합니다.
표 2-7 로깅 범주
범주
설명
ERROR
시스템 오류가 발생할 수 있는 문제에 대한 메시지
WARNING
주의해야 하지만 시스템 오류는 발생하지 않을 경고
INFO
메트릭 및 기타 정보 메시지 보고
로거 수준을 설정하려면 이 범주 중 하나를 지정합니다. 로거는 지정된 범주 및 모든 상위 범주의 데이터를 기록합니다. 예를 들어, WARNING 수준의 로깅을 지정한 경우 로거는 경고 정보 및 오류 정보를 기록합니다.
로거는 표준 출력(콘솔), 로그 파일 그리고 Solaris 플랫폼에서는 syslog 데몬 프로세스 등 다양한 출력 채널에 데이터를 기록할 수 있습니다.
각 출력 채널마다 로거에 대해 설정된 범주 중 어느 것이 해당 채널에 기록될 것인지 지정할 수 있습니다. 예를 들어, 로거 수준이 ERROR로 설정된 경우 콘솔에는 오류와 경고만, 로그 파일에는 정보(메트릭 데이터)만 기록하게 지정할 수 있습니다. Solaris syslog 구성 및 사용에 대한 정보는 syslog(1M), syslog.conf(4) 및 syslog(3C) 설명서 페이지를 참조하십시오.
로그 파일의 경우 로그 파일을 닫고 출력을 새 파일로 롤오버하는 지점을 지정할 수 있습니다. 로그 파일이 지정된 크기나 표시 시간에 도달하면 이 파일을 저장하고 새 로그 파일을 작성합니다. 로그 파일이 저장되는 위치는 다음과 같습니다.
IMQ_VARHOME/instances/brokerName/log/
(Solaris의 경우 /var/imq/instances/brokerName/log/)새 롤오버 로그 파일을 작성하면서 가장 최신의 로그 파일 9개로 구성된 아카이브를 보존합니다. 로그 파일은 다음과 같이 순차적 이름을 갖는 텍스트 파일입니다.
log.txt
log_1.txt
log_2.txt
...
log_9.txtlog.txt가 가장 최신 파일이며, 번호가 가장 높은 파일이 가장 오래된 것입니다.
브로커의 정보 생성 및 로깅을 설정하는 구성 가능한 등록 정보는 표 2-8에서 확인할 수 있습니다(등록 정보 구성 지침은 5장, "브로커 시작 및 구성" 참조).
물리적 대상
MQ 메시징은 2단계 메시지 전달을 기반으로 합니다. 먼저 생성자 클라이언트에서 브로커의 대상으로 메시지가 전달되고, 두 번째로는 브로커의 대상에서 하나 이상의 사용자 클라이언트로 메시지가 전달됩니다. 대상에는 2가지 유형이 있는데("프로그래밍 도메인" 참조), 대기열(지점간 전달 모델)과 주제(게시/가입 전달 모델)입니다. 이러한 대상은 브로커의 물리적 메모리에서의 위치를 나타내며, 여기서는 받은 메시지가 사용자 클라이언트에게 전달되기 전에 마샬링됩니다.
MQ 관리 도구("대상 관리" 참조)를 사용하여 물리적 대상을 작성합니다. 또한 "자동 작성(대 관리 작성) 대상"의 설명처럼 자동으로 대상을 작성할 수도 있습니다.
이 절에서는 2가지 물리적 대상 유형, 즉 대기열과 주제의 등록 정보 및 동작에 대해 설명합니다.
대기열 대상
대기열 대상은 대상에서 인터레스트를 등록한 여러 사용자 중 단 한 명에게 메시지가 전달되는 지점간 메시징에서 사용합니다. 생성자 클라이언트로부터 도착한 메시지는 대기열에 있다가 사용자 클라이언트에게 전달됩니다.
대기 메시지의 경로 지정은 대기열의 전달 정책에 따라 달라집니다. MQ는 3가지 대기열 전달 정책을 구현합니다.
- 단일 이 대기열에서는 단일 메시지 사용자에게 메시지를 전달하는 것만 가능합니다. 제2의 메시지 사용자가 해당 대기열에 등록을 시도하면 거부됩니다. 등록한 메시지 사용자가 연결을 끊으면 메시지는 더 이상 전달되지 않으며, 새 사용자가 등록할 때까지 메시지는 저장됩니다.
- 페일오버(엔터프라이즈판) 이 대기열은 둘 이상의 메시지 사용자에게 메시지를 전달할 수 있지만, 기본 메시지 사용자(해당 브로커에 처음으로 등록한 사용자)가 연결을 끊을 때에만 그렇게 할 수 있습니다. 그 경우 메시지는 그 다음으로 등록한 메시지 사용자에게 전달되며, 이 사용자가 실패하는 경우처럼 특정 시점까지는 계속 그 사용자에게 전달됩니다. 등록한 메시지 사용자가 없으면 사용자가 등록할 때까지 메시지를 저장합니다.
- 라운드 로빈(엔터프라이즈판) 이 대기열은 둘 이상의 메시지 사용자에게 메시지를 전달할 수 있습니다. 한 대기열에 대해 여러 사용자가 등록했다고 가정하면 대기열에 들어간 첫 번째 메시지는 첫 번째로 등록한 메시지 사용자에게 전달되고, 두 번째 메시지는 두 번째로 등록한 사용자에게 전달되는 방식입니다. 동일한 순서대로 동일한 사용자 세트에 추가 메시지는 전달됩니다. 사용자가 대기열에 등록하기 전에 여러 메시지가 대기열에 있을 경우, 한 사용자에게 집중되지 않도록 배치 방식으로 메시지가 전달됩니다. 한 메시지 사용자가 연결이 끊기면 그 사용자에게 경로가 지정되었던 메시지는 나머지 활성 사용자들에게 다시 배포됩니다. 이러한 재배포 때문에 사용자들에게 메시지가 전달되는 순서가 대기열에서 메시지가 수신되는 순서와 동일하다고 할 수는 없습니다.
메시지가 대기열에 오래 머무를 수 있으므로 메모리 자원이 문제가 되기도 합니다. 대기열에 메모리를 너무 많이(메모리는 저활용 상태) 또는 너무 적게(메시지가 거부됨) 할당하기를 원치 않을 것입니다. 유연성을 위해 각 대기열의 로드 수요에 따라 대기열 생성 시 대기열의 메시지 최대 수, 대기 메시지에 할당되는 최대 메모리, 대기 메시지의 최대 크기 등의 물리적 등록 정보를 설정할 수 있습니다(표 6-10 참조).
주제 대상
주제 대상은 대상에서 인터레스트를 등록한 모든 사용자에게 메시지가 전달되는 게시/가입 메시징에서 사용합니다. 생성자로부터 메시지가 도착하면 해당 주제에 가입한 모든 사용자에게 전달됩니다. 사용자가 해당 주제에 대한 영구 가입에 등록한 경우, 메시지가 주제에 전달되는 시점에 사용자는 활성 상태가 아니어도 됩니다. 브로커는 이 사용자가 활성화될 때까지 메시지를 보관했다가 전달합니다.
일반적으로 메시지는 주제 대상에 오래 머무르지 않으므로 메모리 자원은 큰 문제가 되지 않는 편입니다. 그러나 대상이 수신하는 메시지에 허용되는 최대 크기를 구성할 수 있습니다(표 6-10 참조).
자동 작성(대 관리 작성) 대상
JMS 메시지 서버는 메시징 시스템에서 중앙 허브가 되므로 이 서버의 성능 및 안정성이 성공적인 엔터프라이즈 응용 프로그램에 있어 중요한 요소입니다. 대상은 (처리하는 메시지의 수 및 크기, 등록하는 메시지 사용자의 수 및 영구성에 따라) 많은 자원을 사용할 수 있으므로 메시지 서버 성능 및 안정성을 보장하도록 면밀하게 관리해야 합니다. 따라서 MQ 관리자가 응용 프로그램을 대신하여 대상을 작성하고 대상을 모니터링하며 필요 시 자원 요구 사항을 재구성하는 것이 표준 방식입니다.
그러나 대상을 동적으로 작성하는 것이 바람직한 경우가 있습니다. 예를 들어 개발 및 테스트 주기에서는 관리자가 개입할 필요 없이 필요에 따라 브로커가 자동으로 대상을 작성하는 것이 나을 수 있습니다.
MQ는 이 자동 작성 기능을 지원합니다. 자동 작성이 가능한 경우 브로커는 메시지 사용자나 메시지 생성자가 존재하지 않는 대상에 액세스를 시도할 때마다 자동으로 대상을 작성합니다(클라이언트 응용 프로그램의 사용자는 자동 작성 권한이 있어야 합니다. "대상 자동 작성 액세스 제어" 참조).
그러나 대상이 명시적이 아니라 자동으로 작성될 경우, (동일한 대상 이름을 사용하는) 서로 다른 클라이언트 응용 프로그램이 충돌하거나 (대상 지원에 필요한 자원 때문에) 시스템 성능이 저하될 수 있습니다. 이런 이유로 MQ 자동 작성 대상은 더 이상 사용되지 않을 경우, 즉 더 이상 메시지 사용자 클라이언트가 없거나 어떤 메시지도 포함하지 않는 경우 브로커에 의해 자동으로 삭제됩니다. 브로커가 다시 시작되면 지속성 메시지가 있는 경우에만 자동 작성 대상을 다시 작성합니다.
표 2-9에 있는 등록 정보를 사용하여 자동 작성 기능이 사용 가능/불가능하도록 MQ 메시지 서버를 구성할 수 있습니다(등록 정보 구성 지침은 5장, "브로커 시작 및 구성" 참조).
임시 대상
임시 대상은 다른 클라이언트에게 보낸 메시지에 대해 응답을 받을 대상이 필요한 클라이언트 응용 프로그램이 (JMS API를 사용하여) 명시적으로 작성 및 삭제합니다. 이러한 대상은 작성 시 해당 연결이 지속되는 동안 브로커에 의해 유지 관리됩니다. 임시 대상은 관리자가 삭제할 수 없습니다. 그리고 사용 중이라면, 즉 활성 메시지 사용자가 있는 경우에는 클라이언트 응용 프로그램에서도 삭제할 수 없습니다. 임시 대상은 (지속성 메시지가 있는) 관리에 의해 작성되거나 자동으로 작성된 대상과 달리 영구 저장되지 않으며 브로커가 다시 시작할 때 다시 작성되지 않습니다. 또한 MQ 관리 도구에 표시되지 않습니다.
다중 브로커 클러스터(엔터프라이즈판)
MQ 엔터프라이즈판은 상호 연결된 여러 브로커 인스턴스들, 즉 브로커 클러스터를 사용하는 메시지 서버 구현을 지원합니다. 클러스터 지원은 메시지 서버의 확장성을 제공합니다.
브로커에 연결된 클라이언트 수가 늘어나고 전달되는 메시지 수가 늘어나면 브로커는 파일 설명자, 메모리 제한과 같은 자원 제한 사항을 초과하게 됩니다. 늘어나는 로드를 수용하는 한 가지 방법은 MQ 메시지 서버에 브로커(브로커 인스턴스)를 추가하여 클라이언트 연결 및 메시지 전달을 여러 브로커에 걸쳐 분산시키는 것입니다.
또한 여러 브로커를 사용하여 네트워크 대역폭을 최적화할 수 있습니다. 예를 들어, 원격 브로커들 사이에는 더 느린 장거리 네트워크 링크를 사용하고 클라이언트와 브로커를 연결할 경우에는 더 빠른 링크를 사용할 수 있습니다.
브로커 클러스터를 사용하는 또 다른 이유들이 있지만(예: 사용자 저장소가 다른 작업 그룹 수용, 방화벽 제한 사항 처리) 페일오버는 해당되지 않습니다. 클러스터 중에서 한 브로커를 실패하는 다른 브로커의 자동 백업으로 사용할 수 없습니다. 브로커의 자동 페일오버 보호는 MQ 버전 3.0.1에서 지원하지 않습니다(그러나 여러 브로커를 사용하여 사용자 정의 페일오버 체계를 구현하는 응용 프로그램 설계는 가능).
브로커 클러스터 구성 및 관리에 대해서는 "클러스터를 사용한 작업(엔터프라이즈판)"을 참조하십시오.
다음 절에서는 MQ 브로커 클러스터의 구조 및 내부 기능에 대해 설명합니다.
다중 브로커 구조
다중 브로커 메시지 서버에서는 그림 2-7과 같이 여러 브로커 인스턴스 사이에 클라이언트 연결을 분산시킬 수 있습니다. 클라이언트 관점에서 각 클라이언트는 개별 브로커(자신의 홈 브로커)와 연결되며, 홈 브로커가 클러스터에서 유일한 브로커인 것처럼 메시지를 보내고 받습니다. 그러나 메시지 서버 관점에서 이 홈 브로커는 클러스터의 다른 브로커들과 탠덤 방식으로 작동하면서 직접 연결된 메시지 생성자 및 사용자에게 전달 서비스를 제공합니다.
일반적으로 클러스터 내부의 브로커는 임의의 토폴로지로 연결할 수 있습니다. 그러나 MQ 버전 3.0.1은 완전 연결된 클러스터, 즉 그림 2-7에서처럼 각 브로커가 클러스터의 다른 모든 브로커와 직접 연결되는 토폴로지만 지원합니다.
그림 2-7 다중 브로커(클러스터) 구조
다중 브로커 구성에서는 클러스터의 모든 브로커에 각 대상의 인스턴스가 존재합니다. 또한 각 브로커는 다른 모든 브로커에 등록된 메시지 사용자에 대해서도 알고 있습니다. 따라서 각 브로커는 자신과 직접 연결된 메시지 생성자로부터 원격 메시지 사용자에게 메시지를 전달하고, 원격 생성자로부터 자신과 직접 연결된 사용자에게 메시지를 전달합니다.
클러스터 구성에서 각 메시지 생성자와 직접 연결된 브로커는 해당 사용자가 자신에게 보내는 메시지에 대해 경로 지정을 수행합니다. 따라서 지속성 메시지는 그 메시지의 홈 브로커에 의해 저장되고 경로가 지정됩니다.
관리자가 브로커에서 대상을 작성하거나 삭제할 때마다 이 정보는 클러스터의 다른 모든 브로커들에게 자동 전파됩니다. 이와 비슷하게 메시지 사용자가 홈 브로커에 등록되거나 사용자와 홈 브로커 사이의 연결이 (명시적으로 또는 클라이언트나 네트워크 오류로 인해 또는 홈 브로커가 중단되어) 끊길 때마다 이 사용자에 대한 관련 정보가 클러스터 전체에 전파됩니다. 또한 영구 가입에 대한 정보도 클러스터의 모든 브로커에게 전파됩니다.
주 과도한 네트워크 트래픽 및/또는 대용량 메시지는 내부 클러스터 연결에 지장을 줄 수 있습니다. 대기 시간이 길어지면 잠금 프로토콜 시간 초과 오류가 발생하기도 합니다. 그 결과 클라이언트가 영구 가입자나 대기열 메시지 사용자를 작성하려고 할 때 예외가 발생할 수 있습니다. 일반적으로 이러한 문제는 더 빠른 연결을 사용하여 방지할 수 있습니다.
특정 브로커에게 대상과 메시지 사용자에 대한 정보를 전파하려면 일반적으로 공유 자원이 변경될 때 브로커가 온라인 상태가 되어야 합니다. 그러한 변경이 이루어질 때 브로커가 오프라인 상태라면(예: 브로커가 충돌하거나 나중에 다시 시작하거나 클러스터에 새 브로커가 동적으로 추가되는 경우) 어떻게 됩니까?
오프라인된 브로커(또는 새로 추가된 브로커)를 수용하기 위해 MQ는 클러스터의 모든 지속성 항목에 대한 변경 기록, 즉 작성되거나 삭제된 모든 대상 및 영구 가입에 대한 기록을 관리합니다. 클러스터에 동적으로 브로커가 추가되면 이 브로커는 먼저 이 구성 변경 기록에서 대상 및 영구 가입자 정보를 읽습니다. 브로커가 온라인 상태가 되면 다른 브로커들과 현재 활성 상태인 사용자에 대한 정보를 교환합니다. 새 브로커는 이 정보를 사용하여 클러스터에 완전히 통합됩니다.
구성 변경 기록은 클러스터에서 마스터 브로커로 지정된 브로커가 관리합니다. 마스터 브로커는 클러스터에 브로커를 동적으로 추가하는 데 핵심적인 역할을 하므로 항상 이 브로커를 먼저 시작해야 합니다. 마스터 브로커가 온라인이 아닌 경우 클러스터의 다른 브로커들은 초기화를 완료할 수 없습니다.
마스터 브로커가 오프라인이 되면 구성 변경 기록은 다른 브로커에서 액세스할 수 없으며, MQ는 대상 및 영구 가입이 클러스터에 전파되지 않게 합니다. 이 상태에서 대상이나 영구 가입을 작성하거나 삭제하려고 하면(또는 영구 가입 재활성화와 같은 다양한 관련 작업을 시도할 경우) 예외가 발생합니다.
중요한 응용 프로그램 환경에서는 구성 변경 기록을 정기적으로 백업하여 사고에 의한 기록 손상 및 마스터 브로커 오류를 방지하는 것이 바람직합니다. 구성 변경 기록을 비롯한 백업 파일 작성 방법을 제공하는 imqbrokerd 명령의 -backup 옵션을 사용하면 됩니다(표 5-2 참조). 나중에 -restore 옵션을 사용하여 구성 변경 기록을 복원할 수 있습니다.
필요하다면 마스터 브로커로 제공되는 브로커를 변경할 수 있습니다. 구성 변경 기록을 백업하고 해당 클러스터 구성 등록 정보(표 2-10 참조)를 수정하여 새 마스터 브로커를 지정하고 -restore 옵션을 사용하여 새 마스터 브로커를 다시 시작하면 됩니다.
개발 환경에서의 클러스터 사용
클러스터를 테스트 용도로 사용하고 확장성 및 브로커 복구를 심각하게 고려하지 않아도 되는 개발 환경에서는 마스터 브로커가 별로 필요하지 않습니다. 마스터 브로커 없이 구성된 환경에서 MQ는 다른 브로커를 시작하기 위해 마스터 브로커가 반드시 실행 중이어야할 필요는 없으며, 대상 및 영구 가입을 변경할 수 있고 이 변경 사항은 클러스터에서 실행 중인 다른 모든 브로커에게 전파될 수 있습니다. 그러나 브로커가 오프라인되었다가 나중에 복원될 경우 오프라인 상태였을 때 변경된 사항은 동기화하지 않습니다.
테스트 환경에서는 일반적으로 대상은 자동 작성되고("자동 작성(대 관리 작성) 대상" 참조), 이 대상에 대한 영구 가입은 테스트 중인 응용 프로그램에서 작성하고 삭제합니다. 대상 및 영구 가입의 변경 사항은 클러스터 전체에 전파됩니다. 그러나 마스터 브로커를 사용하도록 환경을 재구성할 경우, MQ는 대상 및 영구 가입을 변경하고 이 변경 사항이 클러스터 전체에 전파되려면 마스터 브로커가 실행 중이어야 합니다.
클러스터 구성 등록 정보
클러스터의 각 브로커는 시작 시 클러스터의 다른 브로커에 대한 정보(호스트 이름 및 포트 번호)를 전달 받아야 합니다. 이 정보는 클러스터의 브로커 간 연결을 설정할 때 사용합니다. 또한 마스터 브로커를 사용할 경우 각 브로커는 마스터 브로커의 호스트 이름 및 포트 번호를 알고 있어야 합니다.
클러스터의 모든 브로커는 동일한 클러스터 구성 등록 정보를 사용해야 합니다. 이 등록 정보를 단일 중앙 클러스터 구성 파일에 저장하고 각 브로커가 시작할 때마다 이 파일을 참조하게 하면 됩니다.
(또한 이 구성 등록 정보를 복제하여 각 브로커에게 개별적으로 제공할 수 있습니다. 그러나 클러스터 구성의 일관성이 손상될 수 있으므로 바람직한 방법은 아닙니다. 클러스터 구성 등록 정보의 복사본을 하나만 유지하면 모든 브로커가 동일한 정보를 참조할 수 있습니다.)
MQ 클러스터 구성 등록 정보는 표 2-10에서 확인할 수 있습니다(등록 정보 설정 지침은 "클러스터를 사용한 작업(엔터프라이즈판)" 참조).
클러스터 구성 파일은 브로커 세트가 공통적으로 사용하는 모든 브로커 구성 등록 정보를 저장할 때 사용할 수 있습니다. 원래 클러스터를 구성하기 위해 만들어졌지만 클러스터의 모든 브로커에 공통적인 다른 브로커 등록 정보를 저장하는 용도로도 사용 가능합니다.
MQ 클라이언트 런타임
MQ 클라이언트 런타임은 클라이언트 응용 프로그램에 MQ 메시지 서버와의 인터페이스를 제공합니다. 즉, 클라이언트 응용 프로그램에 "JMS 프로그래밍 모델"에서 소개한 모든 JMS 프로그래밍 객체를 제공합니다. 클라이언트가 대상에게 메시지를 보내고 대상으로부터 메시지를 받는 데 필요한 모든 작업을 지원합니다.
이 절에서는 MQ 클라이언트 런타임의 작동 방식을 간략하게 설명합니다. 성능 관련 요소들은 클라이언트 응용 프로그램 설계 및 성능에 영향을 미치므로 MQ Developer's Guide에서 다룹니다.
그림 2-8은 메시지 생성 및 사용 시 클라이언트 응용 프로그램과 MQ 클라이언트 런타임 사이의 상호 작용 그리고 메시지 전달 시 MQ 클라이언트 런타임과 MQ 메시지 서버 사이의 상호 작용이 어떻게 이루어지는지 보여줍니다.
그림 2-8 메시징 작업
메시지 생성
메시지 생성 단계에서는 클라이언트가 메시지를 작성하고 연결을 통해 브로커의 대상으로 전달합니다. MessageProducer 객체의 메시지 전달 모드가 지속성으로 설정된 경우(한 번씩만 전달), 메시지가 대상에 전달되었으며 브로커의 영구 데이터 저장소에 저장되었음을 브로커가 확인할 때까지 클라이언트 스레드가 차단됩니다. 메시지가 지속성을 갖지 않은 경우 브로커는 브로커 확인 메시지(등록 정보 이름에서 "Ack"라고 표시됨)를 보내지 않으며 클라이언트 스레드는 차단되지 않습니다.
메시지 사용
메시지 사용은 생성보다 더 복잡합니다. 브로커의 대상에 도착한 메시지는 다음 조건에서 MQ 클라이언트 런타임과의 연결을 통해 전달됩니다.
- 클라이언트가 특정 대상에 대해 사용자를 설정한 경우
- 사용자의 선택 기준이 있는 경우 이 기준이 특정 대상에 도착한 메시지의 기준과 일치하는 경우
- 연결이 메시지 전달을 시작하도록 통보 받은 경우
연결을 통해 전달된 메시지는 해당 MQ 세션으로 배포되고, 그림 2-9에서처럼 MessageConsumer 객체에 의해 사용될 때까지 대기합니다. 메시지는 각 세션 대기열에서 한 번에 하나씩 전송되며(세션은 단일 스레드로 구성) 동기식(receive 메소드를 호출하는 클라이언트 스레드를 통해) 또는 비동기식(MessageListener 객체의 onMessage 메소드를 호출하는 세션 스레드를 통해)으로 사용됩니다.
그림 2-9 MQ 클라이언트 런타임으로의 메시지 전달
브로커가 클라이언트 런타임으로 메시지를 전달할 때 그에 따라 메시지에 표시하지만 실제로 수신 또는 사용되었는지 여부는 알 수 없습니다. 따라서 브로커는 브로커의 대상에서 메시지를 삭제하기 전에 클라이언트가 메시지 수신을 확인할 때까지 기다립니다.
MQ 관리 객체
관리 객체를 사용하면 클라이언트 응용 프로그램 코드는 공급자 독립성을 갖습니다. 이는 클라이언트 응용 프로그램이 공급자 독립성을 갖는 방식으로 사용하는 객체에 공급자별 구현 및 구성 정보를 캡슐화하여 수행합니다. 관리 객체는 관리자가 작성 및 구성하고 이름 서비스에서 저장하며 클라이언트 응용 프로그램이 표준 JNDI 조회 코드를 사용하여 액세스합니다.
MQ는 ConnectionFactory와 Destination의 2가지 관리 객체 유형을 제공합니다. 두 객체 모두 공급자별 정보를 캡슐화하지만, 클라이언트 응용 프로그램 내부에서 그 용도는 매우 다릅니다. ConnectionFactory 객체는 메시지 서버와의 연결을 생성할 때 사용하며, Destination 객체는 물리적 대상을 식별할 때 사용합니다.
관리 객체를 사용하면 MQ 메시지 서버를 매우 쉽게 제어하고 관리할 수 있습니다.
- 클라이언트 응용 프로그램이 사전 구성된 ConnectionFactory 객체에 액세스하도록 요구함으로써 연결의 동작을 제어할 수 있습니다("관리 객체 속성" 참조).
- 클라이언트 응용 프로그램이 기존 물리적 대상과 일치하는 사전 구성된 Destination 객체에 액세스하도록 요구함으로써 물리적 대상의 증가를 제어할 수 있습니다(또한 브로커의 자동 작성 기능을 사용 불가능하게 할 수 있습니다. "자동 작성(대 관리 작성) 대상" 참조).
- 클라이언트 응용 프로그램이 설정한 메시지 헤더 값을 무시함으로써 MQ 메시지 서버 자원을 제어할 수 있습니다("관리 객체 속성" 참조).
따라서 이러한 방법을 통해 MQ 관리자는 메시지 서버의 구성 세부 정보를 제어함과 동시에 클라이언트 응용 프로그램이 공급자 독립성을 갖도록 할 수 있습니다. 즉 클라이언트 응용 프로그램은 공급자별 구문 및 객체 이름 지정 규약("JMS 공급자 독립성" 참조) 또는 공급자별 구성 등록 정보를 알 필요가 없습니다.
7장 "관리 객체 관리"에서 설명하는 것처럼 MQ 관리 도구를 사용하여 관리 객체를 만듭니다. 관리 객체를 만들 때 읽기 전용으로, 즉 객체 생성 시 설정한 MQ 특정 구성 값을 클라이언트 응용 프로그램에서 변경할 수 없도록 지정할 수 있습니다. 다시 말해 클라이언트 코드는 읽기 전용 관리 객체에 대해 속성 값을 설정할 수 없으며, 관리자는 "클라이언트 시작 시 속성 값 무시"에서 설명하는 것처럼 응용 프로그램 시작 옵션을 사용하여 이 값을 무시할 수 없습니다.
클라이언트 응용 프로그램에서 ConnectionFactory와 Destination 관리 객체 모두를 자체적으로 인스턴스화할 수 있지만, 이는 MQ 관리자가 응용 프로그램에서 필요로 하는 브로커 자원을 제어하고 그 성능을 조정하게 하려는 관리 객체의 기본 목표에 어긋납니다. 또한 관리 객체를 직접 인스턴스화하면 클라이언트 응용 프로그램은 공급자의 영향을 받지 않고 공급자별 특성을 갖게 됩니다.
연결 팩토리 관리 객체
ConnectionFactory 객체는 클라이언트 응용 프로그램과 MQ 메시지 서버 사이의 물리적 연결을 설정하는 데 사용합니다. 또한 연결 및 이 연결을 사용하여 브로커에 액세스하는 클라이언트 런타임의 동작을 지정하는 데에도 사용합니다.
분산 트랜잭션을 지원하려면("로컬 트랜잭션" 참조) 분산 트랜잭션을 지원하는 특정 XAConnectionFactory 객체를 사용해야 합니다.
ConnectionFactory 관리 객체를 만들려면 "연결 팩토리 추가"를 참조하십시오.
ConnectionFactory 관리 객체를 구성하여 이 객체가 생성하는 모든 연결에 공통적인 속성 값(등록 정보)을 지정할 수 있습니다. ConnectionFactory 및 XAConnectionFactory 객체는 동일한 속성 세트를 갖습니다. 이 속성들은 영향을 미치는 동작에 따라 여러 범주로 그룹화됩니다.
- 연결 사양
- 자동 재연결 동작
- 클라이언트 식별
- 메시지 헤더 무시
- 안정성 및 흐름 제어
- 대기열 브라우저 동작
- 응용 프로그램 서버 지원
- JMS 정의 등록 정보 지원
각 범주와 관련 속성은 MQ Developer's Guide에서 자세히 다룹니다. MQ 관리자로서 이 속성 값을 조정해야 하는 경우가 있지만, 일반적으로 클라이언트 응용 프로그램의 성능 조정을 위해 어떤 속성을 조정할 것인가는 응용 프로그램 개발자가 결정합니다. 표 7-3은 이 속성을 알파벳 순서로 요약합니다.
대상 관리 객체
Destination 관리 객체는 브로커상에서 공개적으로 명명된 Destination 객체에 해당되는 물리적 대상(대기열이나 주제)을 의미합니다. 그 2가지 속성을 표 2-11에서 확인할 수 있습니다. Destination 객체를 만들어 클라이언트 응용 프로그램의 MessageConsumer 및/또는 MessageProducer 객체가 그 물리적 대상에 액세스하게 할 수 있습니다.Destination 관리 객체를 만들려면 "주제 또는 대기열 추가"를 참조하십시오.
클라이언트 시작 시 속성 값 무시
모든 Java 응용 프로그램처럼 명령줄에서 시스템 등록 정보를 지정하여 메시징 응용 프로그램을 시작할 수 있습니다. 또한 이 메커니즘은 클라이언트 응용 프로그램 코드에서 사용하는 관리 객체의 속성 값을 무시할 때 사용할 수 있습니다. 예를 들어 클라이언트 응용 프로그램 코드 중 JNDI 조회를 통해 액세스하는 관리 객체 구성을 무시할 수 있습니다.
클라이언트 응용 프로그램 시작 시 관리 객체 설정을 무시하려면 다음 명령줄 구문을 사용합니다.
java [[-Dattribute=value ]...] clientAppName
여기서 attribute는 "연결 팩토리 관리 객체"에서 소개하는 ConnectionFactory 관리 객체 속성 중 하나를 의미합니다.
예를 들어 클라이언트 코드에서 액세스하는 ConnectionFactory 관리 객체에 지정된 브로커가 아닌 다른 브로커에 클라이언트 응용 프로그램을 연결하려면 명령줄 무시를 통해 다른 브로커의 imqBrokerHostName 및 imqBrokerHostPort를 설정하여 클라이언트 응용 프로그램을 시작할 수 있습니다.
그러나 관리 객체가 읽기 전용으로 설정된 경우 그 속성 값은 명령줄 무시로 변경할 수 없습니다. 그러한 무시는 적용되지 않습니다.