2 관리 작업

• 3 장, 브로커 및 클라이언트 시작

• 4 장, 브로커 구성

• 5 장, 브로커 관리

• 6 장, 물리적 대상 관리

• 7 장, 보안 관리

• 8 장, 관리 대상 객체 관리

• 9 장, 브로커 클러스터 작업

• 10 장, 브로커 모니터링

• 11 장, 메시지 서비스 분석 및 조정

• 12 장, 문제 해결

3장 브로커 및 클라이언트 시작

Sun Java System^TM Message Queue^TM를 설치하고 몇 가지 준비 단계를 수행한 후에는 브로커와 클라이언트를 시작할 수 있습니다. 브로커의 구성은 일련의 구성 파일에 따라 결정되며, 브로커 유틸리티(imqbrokerd)로 전달되는 명령줄 옵션으로 대체될 수 있습니다. 자세한 내용은 4 장, 브로커 구성을 참조하십시오.

이 장은 다음 내용으로 구성되어 있습니다.

• 시스템 자원 준비

• 브로커 시작

• 브로커 제거

• 클라이언트 시작

시스템 자원 준비

브로커를 시작하기 전에 시스템 클럭을 동기화하고 파일 설명자 제한을 설정(Solaris 또는 Linux)하는 두 가지 예비 시스템 수준 작업을 수행해야 합니다. 다음 절에서는 이러한 작업에 대해 설명합니다.

시스템 클럭 동기화

브로커 또는 클라이언트를 시작하기 전에 Message Queue 시스템과 상호 작용하는 모든 호스트에서 클럭을 동기화해야 합니다. 동기화는 메시지 만료(수명)를 사용할 경우에 특히 중요합니다. 동기화되지 않은 클럭의 타임스탬프는 메시지 만료가 예상한 대로 작동하지 않게 하여 메시지 전달을 막을 수 있습니다. 브로커 클러스터에도 동기화가 중요합니다.

SNTP(Simple Network Time Protocol)와 같은 시간 동기화 프로토콜을 실행하도록 시스템을 구성합니다. 시간 동기화는 일반적으로 xntpd 데몬(Solaris 및 Linux)과 W32Time 서비스(Windows)에 의해 지원됩니다. 이러한 서비스 구성에 대한 자세한 내용은 운영 체제 설명서를 참조하십시오. 브로커가 실행된 이후에는 시스템 클럭을 역방향으로 설정하지 마십시오.

파일 설명자 제한 설정

Solaris와 Linux 플랫폼에서는 클라이언트 또는 브로커가 실행 중인 쉘에 프로세스가 사용할 수 있는 파일 설명자 수에 대한 소프트 제한이 있습니다. Message Queue에서는 클라이언트가 만들거나 브로커가 받아들이는 각 연결에 이러한 파일 설명자 중 하나를 사용합니다. 지속성 메시지를 갖는 각 물리적 대상 역시 파일 설명자를 사용합니다.

따라서 파일 설명자 제한은 브로커 또는 클라이언트가 가질 수 있는 연결 수를 제한합니다. 기본적으로 최대 연결 수는 Solaris의 경우 256이며 Linux의 경우에는 1024입니다. (지속성을 위해 파일 설명자를 사용하기 때문에 연결 제한은 실제로 더 낮음). 이 보다 더 많은 연결이 필요하면 클라이언트나 브로커가 실행될 각 쉘의 파일 설명자 제한을 늘려야 합니다. 파일 설명자 제한을 늘리는 방법에 대한 자세한 내용은 ulimit 설명서 페이지를 참조하십시오.

브로커 시작

Message Queue 명령줄 유틸리티나 Windows 시작 메뉴를 시용하여 브로커를 대화식으로 시작하거나 시스템 시작 시 자동으로 시작하도록 정렬할 수 있습니다. 다음 절에서는 브로커 시작 방법에 대해 설명합니다.

대화식으로 브로커 시작

브로커 유틸리티(imqbrokerd)를 사용하여 명령줄에서 브로커를 대화식으로 시작할 수 있습니다. (Windows에서는 시작 메뉴에서 브로커를 시작할 수도 있습니다.)관리 콘솔(imqadmin) 또는 명령 유틸리티(imqcmd)를 사용하여 브로커를 시작할 수는 없습니다. 이러한 도구를 사용하려면 브로커가 이미 실행되고 있어야 합니다.

Solaris 및 Linux 플랫폼의 경우 브로커 인스턴스는 처음에 시작한 사용자가 항상 시작해야 합니다. 각 브로커 인스턴스는 자체 구성 등록 정보 및 파일 기반 메시지 저장소를 가지고 있습니다. 브로커 인스턴스가 처음 시작되면 Message Queue에서는 해당 사용자의 파일 작성 모드 마스크(umask )를 사용하여 해당 브로커 인스턴스의 구성 정보와 영구 데이터가 들어 있는 디렉토리에 대한 권한을 설정합니다.

브로커 인스턴스는 기본적으로 인스턴스 이름이 imqbroker입니다. 이 이름과 기본 구성을 사용하여 명령줄에서 브로커를 시작하려면 다음 명령을 사용하기만 하면 됩니다.

imqbrokerd

그러면 기본 포트 7676에 포트 매퍼가 있는 로컬 시스템에서 imqbroker라는 브로커 인스턴스가 시작됩니다( 포트 매퍼 참조).

기본값이 아닌 인스턴스 이름을 지정하려면 - name 옵션을 imqbrokerd 명령에 사용합니다. 다음 명령은 인스턴스 이름이 myBroker인 브로커를 시작합니다.

imqbrokerd -name myBroker

imqbrokerd 명령줄에서 다른 옵션을 사용하여 다양한 브로커 작업을 제어할 수 있습니다. 다음 예에서는 - tty 옵션을 사용하여 명령 창에 오류 및 경고를 보냅니다(표준 출력).

imqbrokerd -name myBroker -tty

명령줄에서 -D 옵션을 사용하여 브로커의 인스턴스 구성 파일(config.properties)에 지정된 등록 정보 값을 무시할 수도 있습니다. 이 예에서는 imq.jms.max_threads 등록 정보를 설정하여 jms 연결 서비스에 사용할 수 있는 최대 스레드 수를 2000으로 늘립니다.

imqbrokerd -name myBroker -Dimq.jms.max_threads=2000

imqbrokerd 명령의 구문, 하위 명령 및 옵션에 대한 자세한 내용은 브로커 유틸리티를 참조하십시오. 이 정보에 대한 빠른 요약을 보려면 다음을 입력합니다.

imqbrokerd -help

Sun Java System Message Queue 플랫폼판 사용권이 있는 경우 imqbrokerd 명령의- license 옵션을 사용하여 시험 플랫폼판 사용권을 활성화하여 플랫폼판 기능을 90일 동안 사용할 수 있습니다. 다음과 같이 try를 사용권 이름으로 지정합니다.

imqbrokerd -license try

이 옵션은 브로커를 시작할 때마다 사용해야 하며 그렇지 않으면 브로커의 기본값이 표준 플랫폼판 사용권이 됩니다.

자동으로 브로커 시작

브로커를 명령줄에서 명시적으로 시작하는 대신 시스템을 시작할 때 자동으로 시작하도록 설정할 수 있습니다. 이 방법은 브로커를 실행 중인 플랫폼(Solaris, Linux 또는 Windows)에 따라 다릅니다.

자동 시작(Solaris 및 Linux)

Solaris 및 Linux 시스템에서는 자동 시작을 활성화하는 스크립트가 Message Queue 설치 중에 /etc/rc* 디렉토리 트리에 저장됩니다. 이러한 스크립트를 사용하려면 구성 파일 /etc/imq/imqbrokerd.conf(Solaris) 또는 /etc/opt/sun/mq/imqbrokerd.conf(Linux)를 다음과 같이 편집해야 합니다.

• 시스템을 시작할 때 브로커가 자동으로 시작되게 하려면 AUTOSTART 등록 정보를 YES로 설정합니다.

• 비정상적인 종료 이후에 브로커가 자동으로 다시 시작되게 하려면 RESTART 등록 정보를 YES로 설정합니다.

• 브로커에 대한 시작 명령줄 인수를 설정하려면 ARGS 등록 정보에 대해 하나 이상의 값을 지정합니다.

자동 시작(Windows)

Windows 시스템을 시작할 때 브로커가 자동으로 시작되게 하려면 브로커를 Windows 서비스로 정의해야 합니다. 그리고 나면 브로커가 시스템이 시작될 때 시작되어 시스템이 종료될 때까지 백그라운드에서 실행됩니다. 따라서 추가 인스턴스를 시작하는 경우가 아니면 imqbrokerd 명령을 사용해서 브로커를 시작하지 마십시오.

시스템에는 Windows 서비스로 실행 중인 브로커가 하나 뿐일 수 있습니다. 작업 관리자는 이러한 브로커를 두 개의 실행 가능한 프로세스로 나열합니다.

• Windows 고유의 서비스 래퍼 imqbrokersvc.exe

• 브로커를 실행 중인 Java Runtime

Message Queue를 Windows 시스템에 설치할 때 브로커를 서비스로 설치할 수 있습니다. 설치 이후에 서비스 관리자 유틸리티(imqsvcadmin)를 사용하여 다음 작업을 수행할 수 있습니다.

• 브로커를 Windows 서비스로 추가

• 브로커 서비스에 대한 시작 옵션 결정

• Windows 서비스로 실행 중인 브로커 제거

브로커에 시작 옵션을 전달하려면 -args 인수를 imqsvcadmin 명령에 사용합니다. 브로커 시작에서 설명한 대로 이 옵션은 imqbrokerd 명령의 -D 옵션과 동일하게 작동합니다. 명령 유틸리티(imqcmd)를 사용하여 보통의 경우와 같이 브로커 작업을 제어합니다.

imqsvcadmin 명령의 구문, 하위 명령 및 옵션에 대한 자세한 내용은 서비스 관리자 유틸리티를 참조하십시오.

브로커 서비스 재구성

설치된 브로커를 Windows 서비스로 재구성하는 절차는 다음과 같습니다.

실행 중인 브로커를 Windows 서비스로 재구성하는 방법

1. 서비스를 정지합니다.

   1. Windows 시작 메뉴의 설정 하위 메뉴에서 제어판을 선택합니다.

   2. 관리 도구 제어판을 엽니다.

   3. 아이콘을 선택한 후 파일 메뉴 또는 팝업 컨텍스트 메뉴에서 열기를 선택하거나 아이콘을 두 번 눌러 서비스 도구를 실행합니다.

   4. 서비스(로컬)에서 Message Queue 브로커 서비스를 선택한 후 작업 메뉴에서 등록 정보를 선택합니다.

      또는, Message Queue 브로커를 마우스 오른쪽 버튼으로 누른 다음 팝업 컨텍스트 메뉴에서 등록 정보를 선택하거나 Message Queue 브로커를 두 번 누릅니다. 두 경우 모두 Message Queue 브로커 등록 정보 대화 상자가 나타납니다.

   5. 등록 정보 대화 상자의 일반 탭에서 브로커 서비스를 중지하려면 중지를 누릅니다.

2. 서비스를 제거합니다.

   명령줄에서 다음 명령을 입력합니다.

   imqsvcadmin remove

3. -args 옵션으로 다른 브로커 시작 옵션을 지정하거나 -vmargs 옵션으로 다른 Java 버전 인수를 지정하여 서비스를 다시 설치합니다.

   예를 들어, 서비스의 호스트 이름 및 포트 번호를 broker1 및 7878로 변경하려면 다음 명령을 사용합니다.

   imqsvcadmin install -args "-name broker1 -port 7878"

대체 Java Runtime 사용

imqsvcadmin 명령의 -javahome 또는 -jrehome 옵션을 사용하여 대체 Java Runtime의 위치를 지정할 수 있습니다. 또한 서비스의 등록 정보 대화 창에 있는 일반 탭의 시작 매개 변수 필드에서 해당 옵션을 지정할 수도 있습니다.

시작 매개 변수 필드에서는 백슬래시 문자(\\)가 제어 문자로 간주되기 때문에 백슬래시를 경로 구분자로 사용할 경우 두 번 입력해야 합니다. 예를 들면, 다음과 같습니다.

-javahome c:\\\\j2sdk1.4.0

브로커 서비스 시작 옵션 표시

브로커 서비스의 시작 옵션을 결정하려면 예 3–1에 표시된 대로 imqsvcadmin 명령에 query 옵션을 사용합니다.

예 3–1 브로커 서비스 시작 옵션 표시

imqsvcadmin query

Service Message Queue Broker is installed.
Display Name: Message Queue Broker
Start Type: Automatic
Binary location: C:\\Sun\\MessageQueue\\bin\\imqbrokersvc.exe
JavaHome: c:\\j2sdk1.4.0
Broker Args: -name broker1 -port 7878

서비스 시작 문제 해결

브로커를 Windows 서비스로 시작할 때 오류가 발생하는 경우 기록된 오류 이벤트를 볼 수 있습니다.

기록된 서비스 오류 이벤트를 보는 방법

1. Windows 관리 도구 제어판을 엽니다.

2. 이벤트 뷰어 도구를 시작합니다.

3. 응용 프로그램 이벤트 로그를 선택합니다.

4. 작업 메뉴에서 갱신을 선택하여 오류 이벤트를 표시합니다.

브로커 제거

브로커를 다시 제거하는 절차는 다음 절에 설명된 대로 플랫폼마다 다릅니다.

Solaris 또는 Linux에서 브로커 제거

Solaris 또는 Linux 플랫폼에서 브로커 인스턴스를 제거하려면 imqbrokerd 명령에 -remove 옵션을 사용합니다. 명령 형식은 다음과 같습니다.

imqbrokerd [options…] -remove instance

예를 들어, 브로커 이름이 myBroker인 경우 명령은 다음과 같습니다.

imqbrokerd -name myBroker -remove instance

이 명령은 지정된 브로커에 대해 전체 인스턴스 디렉토리를 삭제합니다.

시스템을 시작할 때 브로커가 자동으로 시작되도록 설정한 경우에는 구성 파일 /etc/imq/imqbrokerd.conf(Solaris) 또는 /etc/opt/sun/mq/imqbrokerd.conf(Linux)를 편집하고 AUTOSTART 등록 정보를 NO로 설정합니다.

imqbrokerd 명령의 구문, 하위 명령 및 옵션에 대한 자세한 내용은 브로커 유틸리티를 참조하십시오. 이 정보에 대한 빠른 요약을 보려면 다음을 입력합니다.

Windows 브로커 서비스 제거

Windows 서비스로 실행 중인 브로커를 제거하려면 다음 명령을 사용하여

imqcmd shutdown bkr

브로커를 종료한 후, 다음 명령을 사용하여

imqsvcadmin remove

서비스를 제거합니다.

또는 관리 도구 제어판의 Windows 서비스 도구를 사용하여 브로커 서비스를 중지하고 제거할 수도 있습니다.

브로커 서비스를 제거한 후에는 컴퓨터를 다시 시작합니다.

클라이언트 시작

클라이언트 응용 프로그램을 시작하기 전에 응용 프로그램 개발자로부터 시스템 설정 방법에 대한 정보를 얻습니다. Java 클라이언트 응용 프로그램을 시작할 경우 CLASSPATH 변수를 적절하게 설정하고 올바른 .jar 파일이 설치되었는지 확인해야 합니다. Java 클라이언트용 Message Queue 개발 안내서에 시스템 설정 관련 일반 단계에 대한 자세한 정보가 있으며 개발자에게는 추가 정보가 있을 수도 있습니다.

Java 클라이언트 응용 프로그램을 시작하려면 다음 명령줄 형식을 사용합니다.

java clientAppName

C 클라이언트 응용 프로그램을 시작하려면 응용 프로그램 개발자가 제공한 형식을 사용합니다.

응용 프로그램 설명서는 응용 프로그램에서 설정하는 속성 값에 대한 정보를 제공해야 하며, 명령줄에서 이러한 속성 값 중 일부를 대체해야 하는 경우도 있습니다. Java 클라이언트의 명령줄에서 JNDI(Java Naming and Directory Interface) 조회를 사용하여 연결 팩토리를 찾는 속성을 지정할 수도 있습니다. 조회에서 응용 프로그램보다 더 오래된 연결 팩토리를 반환할 경우 해당 연결 팩토리는 최신 속성을 지원하지 못할 수 있습니다. 그럴 경우 Message Queue는 해당 속성을 기본값으로 설정합니다. 필요한 경우, 명령줄을 사용하여 해당 기본값을 대체할 수도 있습니다.

명령줄에서 Java 응용 프로그램에 대한 속성 값을 지정하려면 다음 구문을 사용합니다.

java [[-Dattribute=value]
…] clientAppName

16 장, 관리 객체 속성 참조에 표시된 대로 attribute 값은 연결 팩토리 관리 대상 객체 속성이어야 합니다. 값에 공백이 있는 경우 명령줄의 attribute= value 부분을 따옴표로 묶어야 합니다.

다음 예에서는 7677 포트에서 OtherHost 호스트의 브로커에 연결하는 MyMQClient라는 클라이언트 응용 프로그램을 시작합니다.

java -DimqAddressList=mq://OtherHost:7677/jms MyMQClient

명령줄에서 지정한 호스트 이름 및 포트는 응용 프로그램 자체에서 설정된 호스트 이름 및 포트를 대체합니다.

명령줄을 사용하여 속성 값을 지정할 수 없는 경우도 있습니다. 관리자가 읽기 전용 액세스만 허용하도록 관리 객체를 설정하거나 응용 프로그램 개발자가 읽기 전용 액세스만 허용하도록 클라이언트 응용 프로그램을 코딩할 수 있습니다. 클라이언트 프로그램을 시작하는 가장 좋은 방법을 알아보려면 응용 프로그램 개발자와 대화해야 합니다.

4장 브로커 구성

브로커의 구성은 시작 시 일련의 구성 파일 및 imqbrokerd 명령에 전달된 옵션에 따라 결정됩니다. 이 장에서는 사용 가능한 구성 등록 정보와 해당 등록 정보를 사용하여 브로커를 구성하는 방법에 대해 설명합니다.

이 장은 다음 내용으로 구성되어 있습니다.

• 브로커 서비스

• 브로커 등록 정보 설정

• 영구 데이터 저장소 구성

브로커 구성 등록 정보에 대한 자세한 내용은 14 장, 브로커 등록 정보 참조을 참조하십시오.

브로커 서비스

브로커 구성 등록 정보는 적용되는 서비스 또는 브로커 구성 요소에 따라 몇 개의 범주로 구분될 수 있습니다.

• 연결 서비스는 보내고 받는 메시지를 전송하는 브로커와 해당 클라이언트 간의 물리적 연결을 관리합니다.

• 라우팅 서비스는 JMS 페이로드 메시지의 라우팅과 전달을 지정할 뿐만 아니라, 메시지 서비스에서 사용하는 메시지를 제어하여 안정적인 전달을 지원합니다.

• 지속성 서비스는 영구 저장소에 데이터를 기록하고 영구 저장소에서 데이터를 검색하는 작업을 관리합니다.

• 보안 서비스는 브로커에 연결하는 사용자를 인증하고 작업 권한을 부여합니다.

• 모니터링 서비스는 브로커 성능에 대한 메트릭 및 진단 정보를 생성합니다.

다음 절에서는 이러한 각각의 서비스와 특정 필요에 맞추어 이러한 서비스를 사용자 정의하는 데 사용하는 등록 정보에 대해 설명합니다.

연결 서비스

메시지 브로커는 다양한 전송 프로토콜을 사용하여 응용 프로그램과 관리 클라이언트를 모두 지원하는 다양한 연결 서비스를 제공할 수 있습니다. 연결 서비스와 관련된 브로커 구성 등록 정보는 연결 등록 정보에 나와 있습니다.

표 4–1은 다음의 두 가지 특성으로 구별되는 사용 가능한 연결 서비스를 보여줍니다.

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

• 프로토콜 유형은 기본 전송 프로토콜을 지정합니다.

브로커의 imq.service.activelist 등록 정보를 설정하면 이러한 연결 서비스 중 하나 또는 모두를 실행하도록 해당 등록 정보를 구성할 수 있습니다. 이 등록 정보의 값은 브로커가 시작될 때 활성화될 연결 서비스 목록입니다. 등록 정보가 명시적으로 지정되지 않은 경우 기본적으로 jms 및 admin 서비스가 활성화됩니다.

각 연결 서비스는 특정 인증 및 권한 부여 기능도 지원합니다. 자세한 내용은 보안 서비스를 참조하십시오.

포트 매퍼

각 연결 서비스는 호스트 이름(또는 IP 주소)과 포트 번호로 지정되는 특정 포트에 사용할 수 있습니다. 서비스의 정적 포트 번호를 명시적으로 지정하거나 브로커의 포트 매퍼를 동적으로 할당할 수 있습니다. 포트 매퍼 자체는 일반적으로 표준 포트 번호 7676에 있는 브로커의 기본 포트에 있습니다. 필요할 경우, 브로커 구성 등록 정보 imq.portmapper.port를 사용하여 다른 포트 번호로 대체할 수도 있습니다. 기본적으로 각 연결 서비스는 시작 시 포트 매퍼와 함께 자체적으로 등록됩니다. 클라이언트가 브로커에 대한 연결을 생성하면 Message Queue 클라이언트 런타임은 먼저 포트 매퍼에 연결하여 원하는 연결 서비스에 사용할 포트 번호를 요청합니다.

또는 포트 매퍼를 무시하고 imq.serviceName.protocolType. port 구성 등록 정보(여기서 serviceName 및 protocolType은 표 4–1에 나와 있는 특정 연결 서비스를 나타냄)를 사용하여 연결 서비스에 정적 포트 번호를 명시적으로 할당할 수 있습니다. jms, ssljms, admin 및 ssladmin 연결 서비스만 이러한 방식으로 구성할 수 있고, httpjms 및 httpsjms 서비스는 부록 C, HTTP/HTTPS 지원에 설명된 대로 다른 구성 등록 정보를 사용합니다. 그러나, 일반적으로 정적 포트는 방화벽을 통해 연결을 생성하는 경우( 방화벽을 통해 연결 참조)처럼 특수한 경우에만 사용되며 일반 용도로는 바람직하지 않습니다.

두 개 이상의 호스트(예: 컴퓨터에 두 개 이상의 네트워크 카드가 설치된 경우)를 사용할 수 있는 경우에는 브로커 등록 정보를 사용하여 연결 서비스가 바인드해야 할 호스트를 지정할 수 있습니다. imq.hostname 등록 정보는 모든 연결 서비스를 위한 단일 기본 호스트를 지정합니다. 그리고 나서 필요할 경우 imq.serviceName. protocolType.hostname(jms, ssljms, admin 또는 ssl 관리 서비스용) 또는 imq.portmapper.hostname(포트 매퍼 자체용)을 사용하여 대체할 수 있습니다.

여러 포트 매퍼 요청을 동시에 받는 경우 이러한 요청은 작업을 기다리는 동안 운영 체제 백로그에 저장됩니다. imq.portmapper.backlog 등록 정보는 이와 같은 백로그 요청의 최대 수를 지정합니다. 이 제한을 초과하면 백로그가 줄어들 때까지 후속 요청이 거부됩니다.

스레드 풀 관리

각 연결 서비스는 다중 스레드 방식으로서, 다중 연결을 지원합니다. 이러한 연결에 필요한 스레드는 브로커에서 각 서비스의 개별 스레드 풀로 유지 관리됩니다. 연결에 필요한 스레드는 해당 연결을 지원하는 서비스의 스레드 풀에 추가됩니다.

선택한 스레딩 모델은 스레드가 단일 연결 전용인지 또는 여러 연결에서 공유할지 여부를 지정합니다.

• 전용 모델에서 브로커에 대한 각 연결에는 두 개의 스레드(받는 메시지용 및 보내는 메시지용)가 필요합니다. 따라서 지원할 수 있는 연결 수는 제한되지만 성능은 향상됩니다.

• 공유 모델에서 메시지를 보내고 받는 경우 공유 스레드에서 연결을 처리합니다. 각 연결에서는 전용 스레드를 필요로 하지 않기 때문에 이 모델은 사용 가능한 연결 수를 증가시키지만 스레드 관리에 필요한 추가 오버헤드로 인해 성능이 저하됩니다.

브로커의 imq.serviceName. threadpool_model 등록 정보는 두 모델 중에서 해당 연결 서비스에 사용할 모델을 지정합니다. 이 등록 정보는 두 가지 문자열 값(dedicated 또는 shared) 중 하나를 사용합니다. 등록 정보를 명시적으로 설정하지 않으면 기본적으로 dedicated로 간주됩니다.

또한 브로커 등록 정보 imq.serviceName. min_threads 및 imq.serviceName. max_threads를 설정하여 서비스 스레드 풀의 최대 및 최소 스레드 수를 지정할 수 있습니다. 사용 가능한 스레드 수가 지정된 최소 임계값을 초과하는 경우 Message Queue는 최소 임계값에 다시 도달할 때까지 스레드를 종료시켜 여유 스레드를 확보하는 방법으로 메모리 자원을 절약합니다. 로드량이 많은 경우 풀의 최대 수에 도달할 때까지 스레드 수가 증가할 수 있습니다. 이러한 경우 스레드를 사용할 수 있을 때까지 새 연결이 거부됩니다.

공유 스레딩 모델에서는 분산자 스레드를 사용하여 스레드를 활성 연결에 할당합니다. 브로커 등록 정보 imq.shared.connectionMonitor_limit는 단일 분산자 스레드에서 모니터링할 수 있는 최대 연결 수를 지정합니다. 이 등록 정보 값이 작을수록 스레드를 연결에 더 빨리 할당할 수 있습니다. imq.ping.interval 등록 정보는 브로커가 활성 여부를 확인하기 위해 연결을 주기적으로 테스트(“핑”)하는 시간 간격(초)을 지정합니다. 따라서 시도한 메시지 전송이 실패하기 전에 먼저 연결 실패를 감지할 수 있습니다.

라우팅 서비스

브로커에 클라이언트가 연결되면 메시지 경로 지정 및 전달이 수행될 수 있습니다. 이 단계에서 브로커는 여러 종류의 물리적 대상을 작성 및 관리하여 메시지의 원활한 흐름을 보장하고 자원을 효율적으로 관리합니다. 라우팅 등록 정보에 설명된 브로커 구성 등록 정보를 사용하여 응용 프로그램 요구에 맞는 방식으로 이러한 작업을 관리할 수 있습니다.

브로커의 성능과 안정성은 사용 가능한 시스템 자원(메모리 등)과 이러한 자원이 얼마나 효율적으로 활용되는가에 따라 달라집니다. 브로커에서 받는 메시지가 너무 많거나 메모리 부족이 발생하지 않도록 구성 정보를 설정할 수 있습니다. 이러한 등록 정보는 세 가지 서로 다른 수준에서 작동하여 자원이 부족해질 때에도 메시지 서비스의 작동 상태를 유지합니다.

• 시스템 수준 메시지 제한은 시스템의 모든 물리적 대상에 적용됩니다. 여기에는 브로커에서 보유하는 최대 메시지 수(imq.system.max_count)와 해당 메시지가 차지하는 최대 총 바이트 수(imq.system.max_size)가 포함됩니다. 이 제한 중 하나에 도달하면 보류 중인 메시지가 제한 이하로 떨어질 때까지 브로커에서 새 메시지를 거부합니다. 또한 개별 메시지의 최대 크기(imq.message.max_size)와 만료된 메시지가 확보되는 시간 간격(imq.message.expiration.interval)에 대한 제한도 있습니다.

• 개별 대상 제한은 특정 물리적 대상으로의 메시지 흐름을 규제합니다. 이러한 제한을 제어하는 구성 등록 정보는 15 장, 물리적 대상 등록 정보 참조에서 설명합니다. 이 등록 정보에는 대상에서 보유하는 메시지 수와 크기, 대상에 대해 만들 수 있는 메시지 생성자와 사용자의 수, 그리고 대상에 전달하기 위해 함께 일괄 처리할 수 있는 메시지 수에 대한 제한이 포함됩니다.

  메시지 생성자를 통한 메시지 전달 속도를 낮추거나 새로운 받는 메시지를 거부하거나 가장 오래되었거나 우선 순위가 가장 낮은 기존 메시지를 삭제하여 메모리 제한에 응답하도록 대상을 구성할 수 있습니다. 이러한 방법으로 대상에서 삭제되는 메시지를 곧바로 삭제하지 않고 사용 불능 메시지 대기열로 옮길 수 있습니다. 브로커 등록 정보 imq.destination.DMQ.truncateBody는 사용 불능 메시지 대기열에 전체 메시지 본문을 저장할지 또는 헤더와 등록 정보 데이터만 저장할지 여부를 제어합니다.

  응용 프로그램 개발과 테스트의 편의를 위해, 메시지 생성자 또는 사용자가 존재하지 않는 대상에 액세스를 시도할 때마다 새로운 물리적 대상을 자동으로 생성하도록 메시지 브로커를 구성할 수 있습니다. 표 14–3에 요약된 브로커 등록 정보는 방금 설명한 내용과 비슷하지만 관리상 생성된 대상이 아닌 자동 생성 대상에 적용됩니다.

• 시스템 메모리 임계값은 브로커가 메모리 과부하를 방지하기 위해 조치 수위를 점차적으로 높이는 메모리 사용 수준을 정의합니다. 이러한 사용 수준은 네 가지로 정의됩니다.

  • 초록:사용 가능한 메모리 충분

  • 노랑:브로커 메모리 부족 시작

  • 주황:브로커 메모리 부족

  • 빨강:브로커 메모리 없음

    이러한 수준을 정의하는 메모리 사용률은 브로커 등록 정보 imq.green.threshold, imq.yellow.threshold, imq.orange.threshold 및 imq.red.threshold를 통해 지정되며, 각각의 기본값은 초록인 경우 0%, 노랑인 경우 80%, 주황인 경우 90%, 빨강인 경우 98%입니다.

    메모리 사용량이 한 수준에서 다음 수준으로 올라감에 따라, 브로커는 먼저 활성 메모리의 메시지를 영구 저장소로 옮기고 나서 비지속성 메시지의 생성자를 억제한 후 브로커의 메시지 흐름을 중지시킴으로써 단계적으로 응답합니다. 이러한 두 조치 모두 브로커 성능을 떨어뜨립니다. 메시지 생성 억제는 전달되는 각 일괄 처리의 크기를 등록 정보 imq.resourceState .count에 지정된 메시지 수로 제한함으로써 이루어집니다. 여기서 resourceState는 각각 green , yellow, orange 또는 red입니다.

이러한 시스템 메모리 임계값이 트리거되면 시스템 수준과 대상 메시지 제한이 너무 높게 설정되어 있다는 뜻입니다. 메모리 임계값이 항상 잠재적 메모리 과부하를 제때에 잡을 수 있는 것은 아니므로, 메모리 임계값만으로 메모리 사용을 제어하기보다는 메모리 자원을 최적화하도록 시스템 수준과 대상 제한을 다시 구성해야 합니다.

지속성 서비스

오류 발생 시 브로커를 복구하려면 메시지 전달 작업 상태를 다시 작성해야 합니다. 그러기 위해서는 브로커가 상태 정보를 영구 데이터 저장소에 저장해야 합니다. 브로커는 다시 시작할 때 저장된 데이터를 사용하여 대상 및 영구 가입을 다시 작성하고 지속성 메시지를 복구하며 열린 트랜잭션을 롤백하고 전달되지 못한 메시지의 라우팅 테이블을 다시 작성합니다. 그런 다음 메시지 전달을 다시 시작할 수 있습니다.

Message Queue는 파일 기반 및 JDBC 기반 지속성 모듈을 모두 지원합니다(그림 4–1 참조). 파일 기반 지속성에서는 개별 파일을 사용하여 영구 데이터를 저장합니다. JDBC 기반 지속성에서는 JDBC™(Java Database Connectivity) 인터페이스를 사용하여 브로커를 JDBC 호환 데이터 저장소에 연결합니다. 일반적으로 파일 기반 지속성은 JDBC 기반보다 빠르지만, JDBC 호환 저장소가 제공하는 중복 및 관리 제어 기능을 선호하는 사용자도 있습니다. 브로커 구성 등록 정보 imq.persist.store(표 14–4 참조)는 사용할 두 가지 형태의 지속성 중 하나를 지정합니다.

그림 4–1 영구 데이터 저장소

파일 기반 지속성

기본적으로 Message Queue에서는 파일 기반 영구 데이터 저장소를 사용하는데, 이 저장소에서는 개별 파일이 메시지, 대상, 영구 가입 및 트랜잭션과 같은 영구 데이터를 저장합니다. 파일 기반 지속성과 관련된 브로커 구성 등록 정보는 파일 기반 지속성에 나와 있습니다.

파일 기반 저장소는 데이터 저장소가 속한 브로커 인스턴스의 이름(instanceName)으로 식별되는 디렉토리에 있습니다.

…/instances/instanceName
/fs350/

stances 디렉토리의 위치는 부록 A, 플랫폼별 Message Queue^TM 데이터 위치를 참조하십시오. 브로커의 각 대상마다 해당 대상으로 전달된 메시지가 들어 있는 고유의 하위 디렉토리가 있습니다.

영구 데이터 저장소에는 중요 정보나 소유 정보를 포함하는 메시지가 있을 수 있기 때문에 …/instances/ instanceName/fs350/ 디렉토리를 인증되지 않은 액세스로부터 보호해야 합니다. 영구 데이터 보안를 참조하십시오.

메시지 이외의 모든 영구 데이터는 개별 파일(대상용 파일, 영구 가입용 파일 및 트랜잭션 상태 정보용 파일)에 저장됩니다. 대부분의 메시지는 가변 크기 레코드로 구성되는 단일 파일에 저장됩니다. 메시지를 추가 및 제거할 때 단편화를 줄이려면 이 파일을 압축할 수 있습니다( 물리적 대상 압축 참조). 또한, 특정 임계값 크기를 초과하는 메시지는 가변 크기 레코드 파일보다는 고유의 개별 파일에 저장됩니다. 브로커 등록 정보 imq.persist.file.message.max_record_size를 사용하여 이 임계값 크기를 구성할 수 있습니다.

브로커는 더 이상 필요하지 않은 파일을 삭제하는 대신 나중에 다른 메시지에 다시 사용할 수 있도록 대상 디렉토리의 사용 가능 파일 풀로 반환하는 방식으로 개별 메시지 파일의 파일 풀을 관리합니다. 브로커 등록 정보 imq.persist.file.destination.message.filepool.limit는 풀의 최대 파일 수를 지정합니다. 대상의 개별 메시지 파일 수가 이 제한을 초과하면 파일이 더 이상 필요하지 않을 때 풀로 반환되지 않고 삭제됩니다.

파일을 파일 풀로 반환하는 경우 이전 내용을 삭제하지 않고 단순히 파일에 재사용 태그를 표시하여 저장소 공간을 절약할 수 있습니다. imq.persist.file.message.filepool.cleanratio 브로커 등록 정보를 사용하면 단순히 재사용 태그를 표시하지 않고 “깨끗한(빈)” 상태로 유지해야 하는 각 대상의 파일 풀에서 파일 비율을 지정할 수 있습니다. 이 값을 높게 설정할수록 파일 풀에 필요한 공간은 줄어들지만, 파일을 풀로 반환 시 파일 내용을 비우는 데 필요한 오버헤드는 더 커집니다. 브로커의 imq.persist.file.message.cleanup 등록 정보가 true이면 풀의 모든 파일이 브로커 종료 시 비워지므로 clean 상태로 유지됩니다. 이렇게 하면 저장소 공간은 절약되지만 종료 프로세스 속도는 느려집니다.

데이터를 영구 저장소에 기록할 때 운영 체제는 데이터를 동기식으로 쓰거나 “느리게(비동기식으로)” 씁니다. 저속 저장소는 데이터가 영구 저장소에 기록되지 않았는데도 브로커에서 기록되었다고 믿는 경우 시스템이 충돌하면 데이터가 손실될 수 있습니다. 성능을 조금 낮추더라도 절대 안정성을 유지하려는 경우에는 브로커 등록 정보 imq.persist.file.sync.enabled를 true로 설정하여 모든 데이터를 동기식으로 기록해야 합니다. 이 경우, 충돌 후 시스템이 다시 백업되면 데이터를 사용할 수 있으므로 브로커는 작업을 안정적으로 다시 시작할 수 있습니다. 그러나, 데이터가 손실되지 않았어도 클러스터화된 브로커에 현재 공유 데이터가 없으므로 클러스터의 다른 브로커는 사용할 수 없습니다.

JDBC 기반 지속성

파일 기반 지속성을 사용하는 대신 JDBC 호환 드라이버를 통해 액세스할 수 있는 데이터 저장소에 액세스하도록 브로커를 설정할 수 있습니다. 이 경우 해당 JDBC 관련 브로커 구성 등록 정보를 설정하고 데이터베이스 관리자 유틸리티(imqdbmgr)를 사용하여 적절한 스키마를 갖는 데이터베이스를 만들어야 합니다. 자세한 내용은 JDBC 기반 저장소 구성을 참조하십시오.

JDBC 기반 지속성에는 JDBC 데이터베이스를 사용하도록 브로커를 구성하기 위한 등록 정보가 나와 있습니다. 이러한 등록 정보는 각 브로커 인스턴스의 인스턴스 구성 파일(config.properties)이나 브로커 유틸리티(imqbrokerd) 또는 데이터베이스 관리자 유틸리티(imqdbmgr)의 -D 명령줄 옵션을 사용하여 지정할 수 있습니다.

imq.persist.jdbc.driver 등록 정보는 데이터베이스에 연결하는 데 사용할 JDBC 드라이버의 Java 클래스 이름을 제공합니다. 또한 기존 데이터베이스 연결(imq.persist.jdbc.opendburl), 새 데이터베이스 작성(imq.persist.jdbc.createdburl) 및 데이터베이스 연결 닫기(imq.persist.jdbc.closedburl) URL을 지정하는 등록 정보도 있습니다.

imq.persist.jdbc.user 및 imq.persist.jdbc.password 등록 정보는 데이터베이스에 액세스하는 데 사용되는 사용자 이름 및 비밀번호를 제공합니다. imq.persist.jdbc.needpassword는 비밀번호가 필요한지 여부를 지정하는 부울 플래그입니다. 보안상의 이유로 비밀번호는 -passfile 명령줄 옵션을 통해 지정된 비밀번호 파일에만 지정해야 합니다. imqbrokerd 및 imqdbmgr 명령은 대화식으로 비밀번호를 묻습니다. 이와 마찬가지로, 명령줄에서 imqbrokerd 명령의 -dbuser 옵션 또는 imqdbmgr 명령의 -u 옵션을 사용하여 사용자 이름을 입력할 수도 있습니다.

여러 브로커 인스턴스에서 공유하는 JDBC 데이터베이스에서 구성 등록 정보 imq.persist.jdbc.brokerid는 각각의 인스턴스에 대해 데이터베이스 테이블 이름에 추가할 고유한 인스턴스 식별자를 지정합니다. 보통 한 브로커 인스턴스에 대해서만 데이터를 저장하는 내장 데이터베이스에는 이 식별자가 필요하지 않습니다. 나머지 JDBC 관련 구성 등록 정보는 각 데이터베이스 테이블마다 한 개의 등록 정보로 구성된 데이터베이스 스키마를 생성하는 SQL 코드를 사용자 정의하는 데 사용됩니다. 예를 들어, imq.persist.jdbc.table.IMQSV35 등록 정보는 버전 테이블, imq.persist.jdbc.table.IMQCCREC35는 구성 변경 레코드 테이블, 그리고 imq.persist.jdbc.table.IMQDEST35는 대상 테이블을 생성하기 위한 SQL 명령을 제공합니다. 전체 목록은 표 14–6을 참조하십시오.

데이터베이스 시스템마다 필요한 정확한 SQL 구문이 다르기 때문에 자세한 내용은 데이터베이스 공급업체에서 제공하는 설명서를 참조하십시오.

보안 서비스

Message Queue는 사용자 액세스 제어(인증 및 권한 부여)와 암호화를 위한 보안 서비스를 제공합니다.

• 인증은 검증된 사용자만 브로커에 연결할 수 있도록 합니다.

• 권한 부여는 자원을 액세스하고 특정 작업을 수행할 권한이 있는 사용자 또는 그룹을 지정합니다.

• 암호화는 연결을 통한 전달 중 메시지가 훼손되지 않게 보호합니다.

Message Queue 관리자는 브로커가 사용자를 인증하고 작업 권한을 부여하는 데 필요한 정보를 설정해야 합니다. 보안 서비스와 관련된 브로커 등록 정보는 보안 등록 정보에 나와 있습니다. 부울 등록 정보 imq.accesscontrol.enabled는 액세스 제어가 브로커 수준에 적용되는지 여부를 제어하는 마스터 스위치 역할을 합니다. 보다 자세한 제어를 위해 imq.serviceName .accesscontrol.enabled 등록 정보를 설정하여 연결 서비스에 대해 이 설정을 대체할 수 있습니다. 여기서 serviceName은 표 4–1에 표시된 대로 연결 서비스의 이름입니다. 예를 들면 imq.httpjms.accesscontrol.enabled와 같습니다.

그림 4–2는 브로커에서 인증 및 권한 부여 서비스를 제공하는 데 필요한 구성 요소를 보여줍니다. 이러한 서비스는 메시징 시스템 사용자에 대한 정보(이름, 비밀번호 및 그룹 멤버쉽)가 들어 있는 사용자 저장소에 따라 다릅니다. 또한, 사용자나 그룹에 특정 작업에 대한 권한을 부여하기 위해 브로커는 사용자나 그룹이 수행할 수 있는 작업을 지정하는 액세스 제어 등록 정보 파일을 참조합니다. 구성 등록 정보 imq.accesscontrol.file.filename을 사용하여 브로커 전체에 대해 단일 액세스 제어 등록 정보 파일을 지정하거나, imq.serviceName. accesscontrol.file.filename을 사용하여 단일 연결 서비스에 대해 지정할 수 있습니다.

그림 4–2 보안 지원

그림 4–2에 표시된 대로, Message Queue 서비스와 함께 제공되는 플랫 파일 사용자 저장소에 사용자 데이터를 저장하거나 기존 LDAP(Lightweight Directory Access Protocol) 저장소에 플러그 인할 수 있습니다.

• 플랫 파일 저장소를 선택하는 경우에는 Message Queue 사용자 관리자 유틸리티(imqusermgr)를 사용하여 저장소를 관리해야 합니다. 이 옵션은 기본적으로 제공되며 사용하기 쉽습니다.

• 기존 LDAP 서버를 사용하려면 LDAP 공급업체에서 제공하는 도구를 사용하여 사용자 저장소를 채우고 관리합니다. 또한, 브로커에서 LDAP 서버에 사용자 및 그룹에 대한 정보를 쿼리할 수 있도록 브로커 인스턴스 구성 파일의 등록 정보를 설정해야 합니다.

브로커의 imq.authentication.basic.user_repository 등록 정보는 어떤 저장소 유형을 사용할지를 지정합니다. 일반적으로 LDAP 저장소는 확장성이 중요한 경우나 여러 브로커에서 저장소를 공유해야 하는 경우(예: 브로커 클러스터를 사용 중인 경우)에 권장됩니다. 플랫 파일 또는 LDAP 사용자 저장소 설정에 대한 자세한 내용은 사용자 인증을 참조하십시오.

인증

브로커에 연결을 요청하는 클라이언트는 브로커가 사용자 저장소에 저장된 항목과 비교할 사용자 이름 및 비밀번호를 제공해야 합니다. 클라이언트에서 브로커로 전송된 비밀번호는 기본 64 인코딩(플랫 파일 저장소용) 또는 메시지 다이제스트(MD5) 해싱(LDAP 저장소용)을 사용하여 인코딩됩니다. 이 옵션은 브로커 전체의 경우 imq.authentication.type 등록 정보를 통해 제어되거나 특정 연결 서비스의 경우 imq.serviceName. authentication.type 등록 정보를 통해 제어됩니다. imq.authentication.client.response.timeout 등록 정보는 인증 요청 시간 초과 간격을 설정합니다.

비밀번호 파일에 설명한 대로 비밀번호를 대화식으로 묻지 않고 비밀번호 파일에 비밀번호를 입력하도록 선택할 수도 있습니다. 부울 브로커 등록 정보 imq.passfile.enabled는 이 옵션을 제어합니다. 이 등록 정보가 true이면 imq.passfile.dirpath 및 imq.passfile.name 등록 정보에서 비밀번호 파일의 디렉토리 경로와 파일 이름을 제공합니다. imq.imqcmd.password 등록 정보(비밀번호 파일에 내장될 수 있음)는 관리자가 명령 유틸리티(imqcmd)를 사용하여 브로커, 연결 서비스, 연결, 물리적 대상, 영구 가입 및 트랜잭션을 관리하는 데 필요한 인증용 비밀번호를 지정합니다.

LDAP 기반 사용자 저장소를 사용하는 경우에는 LDAP 조회의 다양한 측면을 구성하는 데 사용할 수 있는 다양한 브로커 등록 정보가 있습니다. LDAP 서버 자체의 주소(호스트 이름 및 포트 번호)는 imq.user_repository.ldap.server를 통해 지정됩니다. imq.user_repository.ldap.principal 등록 정보는 LDAP 저장소에 바인드하는 데 필요한 고유 이름을 제공하며, imq.user_repository.ldap.password는 관련 비밀번호를 제공합니다. 기타 등록 정보는 개별 사용자 및 그룹 검색을 위한 디렉토리 기반 및 선택적 JNDI 필터, 사용자 및 그룹 이름의 공급자별 속성 식별자 등을 지정합니다. 자세한 내용은 보안 등록 정보를 참조하십시오.

권한 부여

인증된 사용자는 다양한 Message Queue 관련 작업을 수행할 수 있는 권한을 부여받게 됩니다. Message Queue 관리자는 사용자 그룹을 정의하고 그룹 내 개별 사용자 멤버쉽을 할당할 수 있습니다. 기본 액세스 제어 등록 정보 파일은 admin이라는 단일 그룹만 명시적으로 참조합니다( 그룹 참조). 이 그룹의 사용자는 admin 연결 서비스용 연결 권한이 있으므로 대상 생성, 브로커 모니터링 및 제어와 같은 관리 작업을 수행할 수 있습니다. 다른 그룹으로 정의된 사용자는 기본적으로 admin 서비스에 연결할 수 없습니다.

사용자가 어떤 작업을 수행하려 하면 브로커는 사용자 저장소에 있는 사용자 이름 및 그룹 멤버쉽을 액세스 제어 등록 정보 파일에 있는 해당 작업에 액세스하도록 지정된 사용자 이름 및 그룹 멤버쉽과 대조 확인합니다. 액세스 제어 등록 정보 파일은 다음 작업에 대한 사용자 또는 그룹의 권한을 지정합니다.

• 브로커에 연결

• 대상에 액세스: 지정된 대상 또는 모든 대상에 대해 사용자, 생성자 또는 대기열 브라우저 생성

• 대상 자동 생성

암호화

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

SSL 기반 Message Queue 연결 서비스를 사용하려면 키 도구 유틸리티(imqkeytool)를 사용하여 공용 키/개인 키 쌍을 생성합니다. 이 유틸리티는 자체 서명된 인증서에 공용 키를 내장하고 이를 Message Queue 키 저장소에 저장합니다. 키 저장소 자체에 비밀번호가 설정되어 있으므로 잠금을 해제하려면 시작 시 imq.keystore.password 등록 정보에 지정된 키 저장소 비밀번호를 입력해야 합니다. 키 저장소 잠금이 해제되면 브로커는 연결을 요청하는 모든 클라이언트에게 인증서를 전달할 수 있습니다. 그리고 나서 클라이언트는 인증서를 사용하여 브로커에게 보낼 암호화된 연결을 설정합니다.

imq.audit.enabled 브로커 등록 정보는 Message Queue 브로커 로그 파일에 대한 감사 레코드 로깅을 제어합니다. 자세한 내용은 감사 기록을 참조하십시오.

모니터링 서비스

브로커는 응용 프로그램 및 브로커 성능을 모니터하고 진단할 구성 요소를 포함합니다. 여기에는 다음 항목이 포함됩니다.

• 데이터를 생성하는 구성 요소, 메트릭 생성자 및 이벤트를 기록하는 브로커 코드

• 여러 출력 채널을 통해 정보를 기록하는 로거 구성 요소

• 메트릭 정보를 포함하는 JMS 메시지를 JMS 모니터링 클라이언트가 사용할 수 있도록 주제 대상에게 보내는 메트릭 메시지 생성자

그림 4–3은 일반 체계를 보여줍니다. 모니터링 서비스 구성을 위한 브로커 등록 정보는 모니터링 등록 정보에 나와 있습니다.

그림 4–3 모니터링 지원

메트릭 생성자

메트릭 생성자는 브로커 내부 및 외부로의 메시지 흐름, 브로커 메모리의 메시지 수 및 이 메시지가 사용하는 메모리, 열려 있는 연결 수, 사용 중인 스레드 수 등과 같은 브로커 활동 정보를 제공합니다. 부울 브로커 등록 정보 imq.metrics.enabled는 이러한 정보를 기록할지 여부를 제어합니다. imq.metrics.interval는 빈도를 지정합니다.

로거

로거는 브로커 코드 및 메트릭 생성자가 생성한 정보를 가져와서 오류 발생 시 표준 출력(콘솔), 로그 파일, syslog 데몬 프로세스(Solaris 플랫폼용)에 해당 정보를 기록합니다.사용할 로그 파일은 imq.log.file.dirpath 및 imq.log.file.filename 브로커 등록 정보를 통해 식별됩니다. imq.log.console.stream는 콘솔 출력을 stdout로 전달할지 stderr로 전달할지 여부를 지정합니다.

imq.log.level 등록 정보는 로거에서 수집하는 메트릭 정보 범주 ERROR, WARNING 또는 INFO를 제어합니다. 각 수준에는 상위 수준이 포함됩니다. 예를 들어, WARNING을 로깅 수준으로 지정한 경우 오류 메시지도 기록됩니다. imq.log.console.output 및 imq.log.file.output 등록 정보는 지정된 범주 중에서 콘솔과 로그 파일에 각각 기록할 범주를 제어합니다. 그러나, 이 경우 범주에는 상위 수준이 포함되지 않습니다. 예를 들어, 오류와 경고를 로그 파일에 모두 기록하고 정보 메시지를 콘솔에 기록하려는 경우에는 imq.log.file.output을 ERROR|WARNING으로, imq.log.console.output을 INFO로 명시적으로 설정해야 합니다. Solaris 플랫폼의 경우 또 하나의 등록 정보인 imq.log.syslog.output은 syslog 데몬에 기록할 메트릭 정보 범주를 지정합니다. 사용 불능 메시지를 삭제하거나 사용 불능 메시지 대기열로 옮길 때 기록할지 여부를 지정하는 imq.destination.logDeadMsgs 등록 정보도 있습니다.

로그 파일의 경우 파일을 닫고 출력을 새 파일로 롤오버하는 지점을 지정할 수 있습니다. 로그 파일이 지정된 크기(imq.log.file.rolloverbytes)에 이르거나 지정된 기간(imq.log.file.rolloversecs)에 이르면 해당 로그 파일이 저장되고 새 로그 파일이 만들어집니다.

로깅 관련 추가 브로커 등록 정보는 모니터링 등록 정보을 참조하십시오. 로거 구성 방법과 로거를 사용하여 성능 정보를 얻는 방법에 대한 자세한 내용은 브로커 로깅 구성 및 사용을 참조하십시오.

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

메트릭 메시지 생성자는 주기적으로 메트릭 생성자로부터 정보를 받아서 해당 정보를 메트릭 메시지에 기록합니다. 그런 다음, 이 메트릭 메시지를 메시지에 포함된 메트릭 정보 유형에 따라 다양한 메트릭 주제 대상 중 하나로 전송합니다(표 4–2 참조). Message Queue 클라이언트는 메시지를 사용하거나 포함되어 있는 메트릭 데이터를 처리할 수 있습니다. 이렇게 하면 개발자는 사용자 정의 모니터링 도구를 작성하여 메시징 응용 프로그램을 지원할 수 있습니다. 각 메트릭 메시지 유형에서 보고하는 메트릭 수량에 대한 자세한 내용은 Java 클라이언트용 Message Queue 개발 안내서를 참조하십시오.

브로커 등록 정보 imq.metrics.topic.enabled 및 imq.metrics.topic.interval은 메시지를 메트릭 주제 대상으로 전송할지 여부와 전송 빈도를 각각 제어합니다. imq.metrics.topic.timetolive 및 imq.metrics.topic.persist 등록 정보는 이러한 메시지의 수명과 지속 여부를 지정합니다.

메트릭 메시지 본문에 포함된 정보 이외에 각 메시지의 헤더에는 다음과 같은 추가 정보를 제공하는 등록 정보가 있습니다.

• 메시지 유형

• 메시지를 전송한 브로커의 주소(호스트 이름 및 포트 번호)

• 메트릭 샘플을 가져온 시간

이 등록 정보는 유형이 다르거나 서로 다른 브로커에서 가져온 메트릭 메시지를 처리하는 클라이언트 응용 프로그램에 유용합니다.

브로커 등록 정보 설정

다음 두 가지 방법 중 하나로 브로커의 구성 등록 정보를 지정할 수 있습니다.

• 브로커 구성 파일 편집

• 명령줄에서 등록 정보 값 직접 입력

다음 두 절에서는 두 가지 브로커 구성 방법에 대해 설명합니다.

구성 파일

브로커 구성 파일에는 브로커 구성을 위한 등록 정보 설정이 포함되어 있습니다. 이러한 설정은 디렉토리 내에 보존되며, 이 디렉토리는 사용 중인 운영 체제 플랫폼에 따라 다릅니다. 자세한 내용은 부록 A, 플랫폼별 Message Queue^TM 데이터 위치를 참조하십시오. 이 디렉토리에는 다음과 같은 파일이 저장됩니다.

• 시작 시 로드되는 기본 구성 파일 default.properties. 이 파일은 편집할 수 없지만, 이 파일을 참조하여 기본 설정을 확인하고 변경할 등록 정보의 정확한 이름을 찾을 수 있습니다.

• Message Queue가 설치될 때 지정된 등록 정보를 포함하는 설치 구성 파일 install.properties. 설치한 후에는 이 파일을 편집할 수 없습니다.

또한, 각각의 개별 브로커 인스턴스마다 아래에 설명된 대로 고유의 인스턴스 구성 파일이 있습니다. 클러스터에서 브로커 인스턴스를 연결하는 경우에는 클러스터 구성 파일을 사용하여 클러스터 구성 정보를 지정해야 할 수도 있습니다. 자세한 내용은 클러스터 구성 등록 정보를 참조하십시오.

시작할 때 브로커는 다양한 구성 파일의 등록 정보 값을 병합합니다. 그림 4–4에 표시된 대로 파일은 인스턴스 구성 파일에 지정된 값이 설치 구성 파일에 지정된 값을 대체하고 이 값이 기본 구성 파일의 값을 대체하는 계층 형태로 이루어집니다. 계층의 맨 위에서는 imqbrokerd 명령의 명령줄 옵션을 사용하여 구성 파일에 지정된 등록 정보 값을 수동으로 대체할 수 있습니다.

그림 4–4 브로커 구성 파일

인스턴스 구성 파일 편집

브로커를 처음 실행하면 해당 특정 브로커 인스턴스에 대한 구성 등록 정보를 포함하는 인스턴스 구성 파일이 만들어집니다. 인스턴스 구성 파일의 이름은 config.properties이며 해당 파일이 속해 있는 브로커 인스턴스의 이름으로 식별되는 디렉토리에 저장됩니다.

…/instances/ instanceName/props/config.properties

instances 디렉토리의 위치는 부록 A, 플랫폼별 Message Queue^TM 데이터 위치를 참조하십시오. 파일이 아직 없는 경우에는 브로커를 시작할 때 -name 옵션을 사용해야 합니다. Message Queue에서 파일을 만드는 데 사용할 수 있는 인스턴스 이름을 지정하려면 브로커 유틸리티를 참조하십시오.

instances/instanceName 디렉토리 및 인스턴스 구성 파일은 해당 브로커 인스턴스를 만든 사용자가 소유합니다. 브로커 인스턴스는 항상 이 사용자가 다시 시작해야 합니다.

인스턴스 구성 파일은 브로커 인스턴스에서 관리되며 Message Queue 관리 유틸리티를 사용하여 구성을 변경할 때 수정됩니다. 또한 인스턴스 구성 파일을 사용자가 직접 편집하여 브로커의 작동 및 자원 사용을 사용자 정의할 수 있습니다. 그렇게 하려면 instances/ instanceName 디렉토리의 소유자이거나 root로 로그인하여 디렉토리의 액세스 권한을 변경해야 합니다.

브로커는 시작할 때만 인스턴스 구성 파일을 읽습니다. 브로커의 구성을 영구적으로 변경하려면 브로커를 종료하고 파일을 편집한 다음 브로커를 다시 시작해야 합니다. 파일(또는 구성 파일)의 등록 정보 정의에서는 다음 구문을 사용합니다.

propertyName=value [[,value1] …]

예를 들어, 다음 항목은 브로커가 추가 메시지를 거부하기 전까지 메모리 및 영구 저장소에 최대 50,000개의 메시지를 저장하도록 지정합니다.

imq.system.max_count=50000

다음 항목은 매일(86400초) 새 로그 파일을 작성하도록 지정합니다.

imq.log.file.rolloversecs=86400

사용 가능한 브로커 구성 등록 정보 및 기본값은 브로커 서비스 및 14 장, 브로커 등록 정보 참조을 참조하십시오.

명령줄에서 구성 옵션 설정

브로커를 시작할 때 또는 시작한 후에 명령줄에 브로커 구성 옵션을 입력할 수 있습니다.

시작할 때 브로커 유틸리티(imqbrokerd)를 사용하여 브로커 인스턴스를 시작합니다. 이 명령의 -D 옵션을 사용하여 브로커 구성 등록 정보와 값을 지정할 수 있습니다. 자세한 내용은 브로커 시작 및 브로커 유틸리티를 참조하십시오. 서비스 관리자 유틸리티(imqsvcadmin)를 사용하여 브로커를 Windows 서비스로 시작하는 경우 -args 옵션을 사용하여 시작 구성 등록 정보를 지정할 수 있습니다. 서비스 관리자 유틸리티를 참조하십시오.

브로커 인스턴스를 실행하는 동안 특정 브로커 등록 정보를 변경할 수도 있습니다. 실행 중인 브로커의 구성을 수정하려면 명령 유틸리티의 imqcmd update bkr 명령을 사용합니다. 브로커 등록 정보 업데이트 및 브로커 관리를 참조하십시오.

영구 데이터 저장소 구성

A broker’s 브로커의 영구 데이터 저장소는 물리적 대상, 영구 가입, 메시지, 트랜잭션 및 확인에 대한 정보가 저장되어 있습니다. Message Queue 브로커는 기본적으로 파일 기반 영구 저장소를 사용하도록 구성되어 있지만, JDBC 호환 드라이버를 통해 액세스할 수 있는 데이터 저장소에 플러그 인 되도록 다시 구성할 수도 있습니다.브로커 구성 등록 정보 imq.persist.store(표 14–4 참조)는 사용할 두 가지 형태의 지속성 중 하나를 지정합니다.

이 절에서는 영구 저장소를 사용하도록 브로커를 구성하는 방법에 대해 설명합니다. 이 장은 다음 항목으로 구성되어 있습니다.

• 파일 기반 저장소 구성

• JDBC 기반 저장소 구성

• 영구 데이터 보안

파일 기반 저장소 구성

브로커 인스턴스를 만들면 파일 기반 데이터 저장소가 자동으로 생성됩니다. 이 저장소는 브로커의 인스턴스 디렉토리에 있습니다. 정확한 위치는 부록 A, 플랫폼별 Message Queue^TM 데이터 위치를 참조하십시오.

기본적으로 Message Queue는 디스크에 대한 비동기 쓰기 작업을 수행합니다. 운영 체제는 성능 향상을 위해 이러한 작업을 버퍼링할 수 있습니다. 하지만 쓰기 작업 중에 운영 체제에 예기치 않은 오류가 발생할 경우 메시지가 손실될 수 있습니다. 성능이 조금 저하되더라도 안정성을 향상시키려면 데이터를 비동기식으로 쓰도록 브로커 등록 정보 imq.persist.file.sync를 설정할 수 있습니다. 이 등록 정보에 대한 자세한 내용은 파일 기반 지속성 및 표 14–5를 참조하십시오.

브로커 인스턴스를 시작할 때 imqbrokerd 명령의 -reset 옵션을 사용하여 파일 시스템을 지울 수 있습니다. 이 옵션 및 하위 옵션에 대한 자세한 내용은 브로커 유틸리티를 참조하십시오.

JDBC 기반 저장소 구성

JDBC 기반 지속성을 사용하도록 브로커를 구성하려면 브로커 인스턴스 구성 파일에서 JDBC 관련 등록 정보를 설정하고 적절한 데이터베이스 스키마를 만듭니다. Message Queue 데이터베이스 관리자 유틸리티(imqdbmgr)는 JDBC 드라이버와 브로커 구성 등록 정보를 사용하여 데이터베이스를 만들고 관리합니다.또한, 데이터베이스 관리자를 사용하여 데이터베이스에서 손상된 테이블을 삭제하거나 다른 데이터베이스를 데이터 저장소로 사용할 수도 있습니다. 자세한 내용은 데이터베이스 관리자 유틸리티를 참조하십시오.

Oracle 및 PointBase 데이터베이스 제품의 구성 예를 사용할 수 있습니다. 이 파일의 위치는 플랫폼마다 다르며부록 A, 플랫폼별 Message Queue^TM 데이터 위치의 관련 테이블에서 “응용 프로그램 및 구성 예”에 나와 있습니다. 또한 PointBase 내장 버전, PointBase 서버 버전 및 Oracle의 예는 인스턴스 구성 파일 config.properties에서 주석 처리된 값으로 제공됩니다.

JDBC 기반 데이터 저장소를 구성하는 방법

1. 브로커의 구성 파일에서 JDBC 기반 등록 정보를 설정합니다.

   관련 등록 정보는 JDBC 기반 지속성과 표 14–6에서 설명합니다. 특히, 브로커의 imq.persist.store 등록 정보를 jdbc로 설정해야 합니다( 지속성 등록 정보 참조).

2. 다음 위치에 JDBC 드라이버 .jar 파일의 사본 또는 심볼릭 링크를 넣습니다.

   • Solaris:

     /usr/share/lib/imq/ext/

   • Linux:

     /opt/sun/mq/share/lib/

   • Windows:

     IMQ_VARHOME\\lib\\ext

   예를 들어, Solaris 시스템에서 PointBase를 사용하는 경우 다음 명령을 사용하여 드라이버의 .jar 파일을 해당 위치로 복사합니다.

   % cp j2eeSDKInstallDirectory/pointbase/lib/pointbase.jar /usr/share/lib/imq/ext

   대신, 다음 명령은 심볼링 링크를 만듭니다.

   % ln -s j2eeSDKID/lib/pointbase/pointbase.jar /usr/share/lib/imq/ext

3. Message Queue 지속성에 필요한 데이터베이스 스키마를 만듭니다.

   imqdbmgr create all 명령(내장 데이터베이스용) 또는 imqdbmgr create tbl 명령(외부 데이터베이스용)을 사용합니다( 데이터베이스 관리자 유틸리티 참조).

   1. imqdbmgr이 위치한 디렉토리로 변경합니다.

      • Solaris:

        cd /usr/bin

      • Linux:

        cd /opt/sun/mq/bin

      • Windows:

        cd IMQ_HOME\\bin

   2. imqdbmgr 명령을 입력합니다.

      imqdbmgr create all

      ---

      주 –

      내장 데이터베이스를 사용하는 경우 다음 디렉토리에 해당 데이터베이스를 만드는 것이 좋습니다.

      … /instances/ instanceName/dbstore/ databaseName

      내장 데이터베이스가 사용자 이름과 비밀번호로 보호되지 않는 경우에는 파일 시스템 권한으로 보호합니다. 브로커에서 데이터베이스를 읽고 쓸 수 있게 하려면 브로커를 실행하는 사용자가 imqdbmgr 명령을 사용해서 내장 데이터베이스를 만든 사용자와 같아야 합니다.

      ---

영구 데이터 보안

영구 저장소는 정보 가운데 일시적으로 저장되는 메시지 파일을 포함할 수 있습니다. 이러한 메시지에는 소유 정보가 포함될 수 있기 때문에 인증되지 않은 액세스로부터 데이터 저장소를 보호해야 합니다. 이 절에서는 파일 기반 또는 JDBC 기반 데이터 저장소의 데이터를 보호하는 방법에 대해 설명합니다.

파일 기반 저장소 보안

파일 기반 지속성을 사용하는 브로커는 영구 데이터를 플랫폼마다 다른 위치에 있는 플랫 파일 데이터 저장소에 씁니다(부록 A, 플랫폼별 Message Queue^TM 데이터 위치 참조).

…/instances/ instanceName/fs350/

여기서 instanceName은 브로커 인스턴스를 식별하는 이름입니다.

instanceName/fs350/ 디렉토리는 브로커 인스턴스가 처음으로 시작될 때 생성됩니다. 이 디렉토리 보안 절차는 브로커가 실행 중인 운영 체제 플랫폼에 따라 다릅니다.

• Solaris와 Linux에서는 디렉토리의 권한이 브로커 인스턴스를 시작한 사용자의 파일 모드 작성 마스크(umask)에 따라 결정됩니다. 따라서, 마스크를 적절하게 설정하여 브로커 인스턴스를 시작하고 지속성 파일 읽기 권한을 제한할 수 있습니다. 또는, 관리자(수퍼유저)가 instances 디렉토리에 대한 권한을 700으로 설정하여 영구 데이터를 보호할 수 있습니다.

• Windows에서는 Windows 운영 체제에서 제공한 메커니즘을 사용하여 디렉토리 권한을 설정할 수 있습니다. 여기에는 일반적으로 디렉토리에 대한 등록 정보 대화 상자 열기가 포함됩니다.

JDBC 기반 저장소 보안

JDBC 기반 지속성을 사용하는 브로커는 영구 데이터를 JDBC 호환 데이터베이스에 씁니다. 데이터베이스 서버에서 관리하는 데이터베이스(예: Oracle)의 경우 Message Queue 데이터베이스 테이블(이름이 IMQ로 시작하는 테이블)에 액세스하는 데 사용할 사용자 이름과 비밀번호를 만드는 것이 좋습니다. 데이터베이스에서 개별 테이블을 보호할 수 없는 경우 Message Queue 브로커 전용 데이터베이스를 만듭니다. 사용자 이름/비밀번호 액세스 작성 방법에 대한 자세한 내용은 데이터베이스 공급업체에서 제공하는 설명서를 참조하십시오.

브로커가 데이터베이스 연결을 여는 데 필요한 사용자 이름과 암호는 브로커 구성 등록 정보에서 제공될 수 있습니다. 그러나 imqbrokerd 명령의 -dbuser 및 -dbpassword 옵션을 사용하여 명령줄 옵션으로 제공하는 것이 보다 안전합니다( 브로커 유틸리티 참조).

브로커가 데이터베이스의 JDBC 드라이버를 통해 직접 액세스하는 내장 데이터베이스의 경우 파일 기반 저장소 보안에서 설명한 대로, 일반적으로 영구 데이터가 저장되는 디렉토리에 대한 파일 권한을 설정하여 보안을 제공합니다. 하지만 브로커와 데이터베이스 관리자 유틸리티를 모두 사용하여 데이터베이스를 읽기 및 쓰기 가능하게 하려면 해당 브로커와 유틸리티를 모두 동일한 사용자가 실행해야 합니다.

5장 브로커 관리

이 장에서는 imqcmd 유틸리티를 사용하여 브로커 및 해당 서비스를 관리하는 방법에 대해 설명합니다. 이 장은 다음 내용으로 구성되어 있습니다.

• 전제 조건 전제 조건

• imqcmd 유틸리티 사용 imqcmd 유틸리티 사용

• 브로커 정보 표시

• 브로커 등록 정보 업데이트

• 브로커 일시 중지 및 다시 시작

• 브로커 종료 및 다시 시작

• 브로커 메트릭 표시

• 연결 서비스 관리

• 연결 정보 얻기

• 영구 가입 관리

• 트랜잭션 관리

이 장에서 브로커 관리와 관련된 모든 항목을 설명하지는 않습니다. 추가 항목들은 별도로 다음 장에서 설명합니다.

• 브로커에서 물리적 대상 관리. 물리적 대상 만들기, 표시, 업데이트 및 완전 삭제 방법과 사용 불능 메시지 대기열 사용 방법은 6 장, 물리적 대상 관리을 참조하십시오.

• 브로커에 대한 보안 설정. 사용자 인증, 액세스 제어, 암호화, 비밀번호 파일, 감사 로깅 등과 같은 항목에 대한 자세한 내용은 7 장, 보안 관리을 참조하십시오.

전제 조건

imqcmd 및 imqusermgr 명령줄 유틸리티를 사용하여 브로커를 관리합니다. 브로커를 관리하기 전에 다음을 수행해야 합니다.

• imqbrokerd 유틸리티 명령을 사용하여 브로커를 시작합니다. 브로커가 실행될 때까지는 다른 명령줄 유틸리티를 사용할 수 없습니다.

• Message Queue^TM 관리자를 설정할지 아니면 기본 계정을 사용할지를 결정합니다. 관리 명령을 사용하려면 사용자 이름과 비밀번호를 지정해야 합니다.

  Message Queue를 설치하면 기본 플랫 파일 사용자 저장소가 설치됩니다. 저장소는 admin 및 guest 사용자의 두 가지 기본 항목과 함께 제공됩니다. Message Queue를 테스트하는 경우 기본 사용자 이름과 비밀번호(admin/admin)를 사용하여 imqcmd 유틸리티를 실행할 수 있습니다.

  작업 시스템을 설정하는 경우 관리자에 대한 인증과 권한 부여를 설정해야 합니다. 파일 기반 사용자 저장소 설정 또는 LDAP 디렉토리 서버 사용 구성에 대한 자세한 내용은 7 장, 보안 관리을 참조하십시오. 작업 환경에서는 보안을 위해 기본이 아닌 사용자 이름과 비밀번호를 사용하는 것이 좋습니다.

• 브로커에 대한 보안 연결을 사용하려면 대상 브로커 인스턴스에서 ssladmin 서비스를 설정하고 활성화합니다. 자세한 내용은 메시지 암호화를 참조하십시오.

imqcmd 유틸리티 사용

imqcmd 유틸리티를 사용하여 브로커와 해당 서비스를 관리할 수 있습니다.

imqcmd 명령의 구문, 하위 명령 및 옵션에 대한 자세한 내용은 13 장, 명령줄 참조을 참조하십시오. 물리적 대상 관리에 대한 자세한 내용은 별도의 장으로 제공되는 15 장, 물리적 대상 등록 정보 참조을 참조하십시오.

도움말 표시

imqcmd 유틸리티에서 도움말을 표시하려면 -h 또는 -H 옵션을 사용합니다. 하위 명령은 사용하지 마십시오. 특정 하위 명령에 대한 도움말은 볼 수 없습니다.

예를 들어, 다음 명령은 imqcmd에 대한 도움말을 표시합니다.

imqcmd -H

-h 또는 -H 옵션을 포함하는 명령줄을 하위 명령 또는 다른 옵션과 함께 입력할 경우 imqcmd 유틸리티는 -h 또는 -H 옵션만 처리합니다. 명령줄의 모든 다른 항목은 무시됩니다.

제품 버전 표시

Message Queue 제품 버전을 표시하려면 -v 옵션을 사용합니다. 예를 들면 다음과 같습니다.

imqcmd -v

-v 옵션을 포함하는 명령줄을 하위 명령 또는 다른 옵션과 함께 입력할 경우 imqcmd 유틸리티는 -v 옵션만 처리합니다. 명령줄의 모든 다른 항목은 무시됩니다.

사용자 이름 및 비밀번호 지정

각 imqcmd 하위 명령은 사용자 저장소에 대해 인증되므로 사용자 이름과 비밀번호가 필요합니다. -h 또는 -H 옵션을 사용하여 도움말을 표시하는 명령과, -v 옵션을 사용하여 제품 버전을 표시하는 명령만 제외됩니다.

사용자 이름 지정

-u 옵션을 사용하여 관리자 이름을 지정합니다. 관리자 이름을 생략하면 이름을 묻는 명령 프롬프트가 표시됩니다. 예를 들어, 다음 명령은 기본 브로커에 대한 정보를 표시합니다.

imqcmd query bkr -u admin

이 장의 예에서는 쉽게 이해할 수 있도록 기본 사용자 이름 admin을 -u 옵션의 인수로 표시합니다. 작업 환경에서는 사용자 정의 사용자 이름을 사용하게 됩니다.

비밀번호 지정

다음 방법 중 하나를 사용하여 비밀번호를 지정합니다.

• 비밀번호 파일(passfile)을 만들고 해당 파일에 비밀번호를 입력합니다. 명령줄에서 -passfile 옵션을 사용하여 비밀번호 파일의 이름을 입력합니다.

• 비밀번호를 묻는 명령 프롬프트를 표시하게 합니다.

Message Queue의 이전 버전에서는 imqcmd 명령줄에서 -p 옵션을 사용하여 비밀번호를 지정할 수 있었습니다. 이 옵션은 더 이상 사용되지 않으며 향후 버전에서는 제거됩니다.

브로커 이름 및 포트 지정

imqcmd의 기본 브로커는 로컬 호스트에서 실행되고 있는 브로커이며 기본 포트는 7676입니다.

원격 호스트에서 실행 중인 브로커나 기본 포트가 아닌 포트에서 수신 중인 브로커 또는 둘 다에 명령을 실행하는 경우 -b 옵션을 사용하여 브로커의 호스트 및 포트를 지정해야 합니다.

예

이 절의 예에서는 imqcmd 사용 방법을 설명합니다.

첫 번째 예에서는 localhost의 포트 7676에서 실행 중인 브로커의 등록 정보를 나열하므로 -b 옵션이 필요하지 않습니다. 이 명령에서는 기본 관리자 이름(admin)을 사용하고 비밀번호를 생략했기 때문에 비밀번호를 묻는 명령 프롬프트가 표시됩니다.

imqcmd query bkr -u admin

다음 예에서는 myserver 호스트의 1564 포트에서 실행 중인 브로커의 등록 정보를 나열합니다. 사용자 이름은 aladdin입니다. (이 명령을 실행하려면 사용자 저장소를 업데이트하여 사용자 이름 aladdin을 admin 그룹에 추가해야 함).

imqcmd query bkr -b myserver:1564 -u aladdin

다음 예에서는 localhost의 포트 7676에서 실행 중인 브로커의 등록 정보를 나열합니다. 명령의 초기 시간 제한은 20초로 설정되고 시간 초과 이후의 시도 횟수는 7로 설정됩니다. 사용자의 비밀번호는 명령을 호출할 때 해당 디렉토리에 있는 myPassfile이라는 비밀번호 파일에 있습니다.

imqcmd query bkr -u admin -passfile myPassfile -rtm 20 -rtr 7

브로커에 보안 연결을 위해 이 예에 -secure 옵션을 포함시킬 수 있습니다. -secure 옵션을 지정하면 서비스가 구성되고 시작된 경우 imqcmd에서 ssladmin 서비스가 사용됩니다.

브로커 정보 표시

단일 브로커에 대한 정보를 쿼리 및 표시하려면 query bkr 하위 명령을 사용합니다.

다음은 query bkr 하위 명령 구문입니다.

imqcmd query bkr -b hostName:
portNumber

이 하위 명령은 기본 브로커 또는 지정한 호스트 및 포트의 브로커에 해당하는 현재 등록 정보 설정을 나열합니다. 지정한 브로커에 연결된 실행 중인 브로커(멀티 브로커 클러스터에서)의 목록도 표시합니다.

예를 들면 다음과 같습니다.

imqcmd query bkr -u admin

이 명령은 비밀번호를 묻는 메시지를 표시한 후 다음과 같은 출력을 생성합니다.

Version                                              3.6
Instance Name                                        imqbroker
Primary Port                                         7676
                                                   
Current Number of Messages in System                 0
Current Total Message Bytes in System                0

Current Number of Messages in Dead Message Queue     0
Current Total Message Bytes in Dead Message Queue    0

Log Dead Messages                                    true
Truncate Message Body in Dead Message Queue          false
                                                   
Max Number of Messages in System                     unlimited (-1)
Max Total Message Bytes in System                    unlimited (-1)
Max Message Size                                     70m
                                                   
Auto Create Queues                                   true
Auto Create Topics                                   true
Auto Created Queue Max Number of Active Consumers    1
Auto Created Queue Max Number of Backup Consumers    0
                                                   
Cluster Broker List (active)                         
Cluster Broker List (configured)                     
Cluster Master Broker                                
Cluster URL                                          
                                                   
Log Level                                            INFO
Log Rollover Interval (seconds)                      604800
Log Rollover Size (bytes)                            unlimited (-1)

브로커 등록 정보 업데이트

update bkr 하위 명령을 사용하여 다음과 같은 브로커 등록 정보를 업데이트할 수 있습니다.

• imq.autocreate.queue

• imq.autocreate.topic

• imq.autocreate.queue.maxNumActiveConsumers

• imq.autocreate.queue.maxNumBackupConsumers

• imq.cluster.url

• imq.destination.DMQ.truncateBody

• imq.destination.logDeadMsgs

• imq.log.level

• imq.log.file.rolloversecs

• imq.log.file.rolloverbytes

• imq.system.max_count

• imq.system.max_size

• imq.message.max_size

• imq.portmapper.port

다음은 update bkr 하위 명령 구문입니다.

imqcmd update bkr [-b hostName:
portNumb er]-o attribute=value
 [[-o attribute=value1]
…]

이 하위 명령은 기본 브로커 또는 지정한 호스트 및 포트의 브로커에 해당하는 지정된 속성을 변경합니다. 예를 들어, 다음 명령은 대기열 대상의 자동 생성을 해제합니다.

imqcmd update bkr -o "imq.autocreate.queue=false" -u admin

등록 정보에 대한 자세한 내용은 14 장, 브로커 등록 정보 참조을 참조하십시오.

브로커 일시 중지 및 다시 시작

브로커를 시작한 후에는 imqcmd 하위 명령을 사용하여 브로커의 상태를 제어할 수 있습니다.

브로커 일시 중지

브로커를 일시 중지하면 브로커의 연결 서비스 스레드가 지연되고 브로커에서는 연결 포트의 수신을 중지합니다. 따라서 브로커가 더 이상 새로운 연결을 받아들이거나, 메시지를 수신 또는 디스패치할 수 없습니다.

그러나 브로커를 일시 중지하더라도 admin 연결 서비스는 지연되지 않으므로 브로커에 대한 메시지 흐름을 규제하는 데 필요한 관리 작업은 수행할 수 있습니다. 또한 브로커를 일시 중지해도 cluster 연결 서비스는 지연되지 않습니다. 그러나 클러스터 내의 메시지 전달은 클러스터의 여러 브로커에서 수행하는 전달 기능에 따라 다릅니다. 따라서 클러스터에서 브로커를 일시 중지하면 일부 메시지 트래픽이 느려질 수 있습니다.

다음은 pause bkr 하위 명령 구문입니다.

imqcmd pause bkr [-b hostName:
portNumber]

이 명령은 기본 브로커 또는 지정한 호스트 및 포트의 브로커를 일시 중지합니다.

다음 명령은 myhost의 포트 1588에서 실행 중인 브로커를 일시 중지합니다.

imqcmd pause bkr -b myhost:1588 -u admin

개별 연결 서비스와 개별 물리적 대상을 일시 중지할 수도 있습니다. 자세한 내용은 연결 서비스 일시 중지 및 다시 시작 및 물리적 대상 일시 중지 및 다시 시작을 참조하십시오.

브로커 다시 시작

브로커를 다시 시작하면 브로커의 서비스 스레드가 다시 활성화되고 브로커가 포트 수신을 다시 시작합니다.

다음은 resume bkr 하위 명령 구문입니다.

imqcmd resume bkr [-b hostName:
portNumber]

이 하위 명령은 기본 브로커 또는 지정한 호스트 및 포트의 브로커를 다시 시작합니다.

다음 명령은 localhost의 포트 7676에서 실행 중인 브로커를 다시 시작합니다.

imqcmd resume bkr -u admin

브로커 종료 및 다시 시작

브로커를 종료하면 브로커 프로세스가 자연스럽게 종료됩니다. 브로커가 새로운 연결 및 메시지 수락을 중지하고 기존 메시지 전달을 완료한 다음 브로커 프로세스를 종료합니다.

다음은 shutdown bkr 하위 명령 구문입니다.

imqcmd shutdown bkr [-b hostName:
portNumber]

이 하위 명령은 기본 브로커 또는 지정한 호스트 및 포트의 브로커를 종료합니다.

다음 명령은 ctrlsrv의 포트 1572에서 실행 중인 브로커를 종료합니다.

imqcmd shutdown bkr -b ctrlsrv:1572 -u admin

restart bkr 하위 명령을 사용하여 브로커를 종료하고 다시 시작합니다. 다음은 restart bkr 하위 명령 구문입니다.

imqcmd restart bkr [-b hostName:
portNumber]

이 하위 명령은 브로커를 처음 시작할 때 지정한 옵션을 사용하여 기본 브로커 또는 지정한 호스트 및 포트의 브로커를 종료하고 다시 시작합니다. 다른 옵션을 선택하려면 원하는 옵션을 지정하여 브로커를 종료하였다가 다시 시작합니다.

브로커 메트릭 표시

브로커에 대한 메트릭 정보를 표시하려면 metrics bkr 하위 명령을 사용합니다.

다음은 metrics bkr 하위 명령 구문입니다.

imqcmd metrics bkr [-b hostName:
portNumber]
       [-m metricType] [-int interval] [-msp 
numSamples]

이 하위 명령은 기본 브로커 또는 지정한 호스트 및 포트의 브로커에 대한 브로커 메트릭을 표시합니다.

-m 옵션을 사용하여 다음 메트릭 유형 중 하나를 지정하여 표시합니다.

• ttl 브로커에 유입되고 유출되는 메시지와 패킷에 대한 메트릭을 표시합니다(기본 메트릭 유형).

• rts 브로커에 유입 및 유출되는 메시지와 패킷의 메트릭을 초당 속도로 표시합니다.

• cxn 연결, 가상 메모리 힙 및 스레드를 표시합니다.

-int 옵션을 사용하여 메트릭 표시 간격(초)을 지정합니다. 기본값은 5초입니다.

-msp 옵션을 사용하여 출력에 표시되는 샘플 수를 지정합니다. 기본값은 무제한 수입니다(무한).

예를 들어, 다음 명령은 브로커에 메시지가 유입 및 유출되는 속도를 10초 간격으로 표시합니다.

imqcmd metrics bkr -m rts -int 10 -u admin

다음과 같은 결과가 출력됩니다.

--------------------------------------------------------
 Msgs/sec   Msg Bytes/sec   Pkts/sec    Pkt Bytes/sec   
 In   Out     In      Out     In   Out     In      Out  
--------------------------------------------------------
 0     0      27      56      0     0      38      66   
 10    0     7365     56      10    10    7457    1132  
 0     0      27      56      0     0      38      73   
 0     10     27     7402     10    20    1400    8459  
 0     0      27      56      0     0      38      73

브로커에서 수집하여 보고하는 데이터에 대한 자세한 설명은 브로커 전체 메트릭을 참조하십시오.

연결 서비스 관리

imqcmd 유틸리티에는 다음과 같은 연결 서비스 관리 작업을 수행할 수 있는 하위 명령이 포함되어 있습니다.

• 연결 서비스 나열

• 연결 서비스 정보 표시

• 연결 서비스 등록 정보 업데이트

• 연결 서비스 메트릭 표시

• 연결 서비스 일시 중지 및 다시 시작

브로커는 응용 프로그램 클라이언트 및 관리 클라이언트 모두와의 연결을 지원합니다. 현재 Message Queue 브로커에서 사용 가능한 연결 서비스는 표 5–1에서 확인할 수 있습니다. 표에 나타난 것과 같이 각 서비스는 NORMAL(응용 프로그램 클라이언트) 또는 ADMIN(관리 클라이언트) 중에서 사용하는 서비스 유형과 기본 전송 프로토콜에 연결됩니다.

imqcmd 하위 명령을 사용하면 연결 서비스 전체를 관리하거나 특정 연결 서비스를 관리할 수 있습니다. 하위 명령의 대상이 특정 서비스인 경우 -n 옵션을 사용하여 표 5–1의 서비스 이름 열에 나열된 이름 중 하나를 지정합니다.

연결 서비스 나열

브로커에서 사용 가능한 연결 서비스를 나열하려면 list svc 하위 명령을 사용합니다.

다음은 list svc 하위 명령 구문입니다.

imqcmd list svc [-b hostName:
portNumber]

이 하위 명령은 기본 브로커 또는 지정한 호스트 및 포트의 브로커에서 연결 서비스를 모두 나열합니다.

다음 명령은 localhost의 포트 7676에서 실행 중인 브로커의 모든 서비스를 나열합니다.

imqcmd list svc -u admin

이 명령은 다음과 같은 정보를 출력합니다.

------------------------------------------------
Service Name    Port Number        Service State
------------------------------------------------
admin           41844 (dynamic)    RUNNING
httpjms         -                  UNKNOWN
httpsjms        -                  UNKNOWN
jms             41843 (dynamic)    RUNNING
ssladmin        dynamic            UNKNOWN
ssljms          dynamic            UNKNOWN

연결 서비스 정보 표시

단일 서비스에 대한 정보를 쿼리 및 표시하려면 query 하위 명령을 사용합니다.

다음은 query svc 하위 명령 구문입니다.

imqcmd query svc -n serviceName [-b 
hostName:portNumber]

query svc 하위 명령은 기본 브로커 또는 지정한 호스트 및 포트의 브로커에서 실행 중인 지정된 서비스에 대한 정보를 표시합니다.

예를 들면 다음과 같습니다.

imqcmd query svc -n jms -u admin

이 명령은 비밀번호를 묻는 메시지를 표시한 후 다음과 같은 출력을 생성합니다.

Service Name                           jms
Service State                          RUNNING
Port Number                            60920 (dynamic)
                                     
Current Number of Allocated Threads    0
Current Number of Connections          0
                                     
Min Number of Threads                  10
Max Number of Threads                  1000

연결 서비스 등록 정보 업데이트

update 하위 명령을 사용하여 표 5–2에 나열된 서비스 등록 정보 중 하나 이상을 변경할 수 있습니다.

다음은 update 하위 명령 구문입니다.

imqcmd update svc -n serviceName [-b 
hostName:portNumber] 
         -o attribute=value [-o 
attribute=value1]…

이 하위 명령은 기본 브로커 또는 지정한 호스트 및 포트의 브로커에서 실행 중인, 지정된 서비스의 지정된 속성을 업데이트합니다. 서비스 속성에 대한 자세한 내용은 연결 등록 정보를 참조하십시오.

다음 명령은 jms 서비스에 할당된 최소 스레드 수를 20으로 변경합니다.

imqcmd update svc -n jms -o "minThreads=20" -u admin

연결 서비스 메트릭 표시

단일 서비스에 대한 메트릭 정보를 표시하려면 metrics 하위 명령을 사용합니다.

다음은 metrics 하위 명령 구문입니다.

imqcmd metrics svc -n serviceName [-b 
hostName:portNumber] [-m metricType
]
     [-int interval] [-msp numSamples]

이 하위 명령은 기본 브로커 또는 지정한 호스트 및 포트의 브로커에서 지정된 서비스의 메트릭을 표시합니다.

-m 옵션을 사용하여 표시할 메트릭 유형을 지정합니다.

• ttl 브로커에 유입 및 유출되는 메시지와 패킷의 메트릭을 지정된 연결 서비스를 통해 표시합니다(기본 메트릭 유형).

• rts 브로커에 메시지와 패킷이 유입 및 유출되는 초당 속도에 대한 메트릭을 지정된 연결 서비스를 통해 표시합니다.

• cxn 연결, 가상 메모리 힙 및 스레드를 표시합니다.

-int 옵션을 사용하여 메트릭 표시 간격(초)을 지정합니다. 기본값은 5초입니다.

-msp 옵션을 사용하여 출력에 표시되는 샘플 수를 지정합니다. 기본값은 무제한 수입니다(무한).

예를 들어, 다음 명령은 jms 연결 서비스에서 처리된 메시지 및 패킷의 누적 총 수를 구합니다.

imqcmd metrics svc -n jms -m ttl -u admin

이 명령은 비밀번호를 묻는 메시지를 표시한 후 다음과 같은 출력을 생성합니다.

-------------------------------------------------
  Msgs      Msg Bytes      Pkts      Pkt Bytes   
In   Out    In     Out   In   Out    In     Out  
-------------------------------------------------
164  100  120704  73600  282  383  135967  102127
657  100  483552  73600  775  876  498815  149948

imqcmd를 사용하여 연결 서비스 메트릭을 보고하는 방법에 대한 자세한 내용은 연결 서비스 메트릭을 참조하십시오.

연결 서비스 일시 중지 및 다시 시작

일시 중지할 수 없는 admin 서비스를 제외한 모든 서비스를 일시 중지하려면 pause svc 및 resume svc 하위 명령을 사용합니다.

다음은 pause svc 하위 명령 구문입니다.

imqcmd pause svc -n serviceName [-b 
hostName:portNumber]

이 하위 명령은 기본 브로커 또는 지정한 호스트 및 포트의 브로커에서 실행 중인 지정된 서비스를 일시 중지합니다.예를 들어, 다음 명령은 기본 프로커에서 실행 중인 httpjms 서비스를 일시 중지합니다.

imqcmd pause svc -n httpjms -u admin

서비스를 일시 중지하면 다음과 같은 현상이 나타납니다.

• 브로커는 일시 중지된 서비스에서 새 클라이언트 연결 수신을 멈춥니다. Message Queue 클라이언트가 새 연결을 열려고 하면 예외가 발생합니다.

• 일시 중지된 서비스의 기존 연결은 모두 그대로 유지되지만 브로커는 서비스가 다시 시작될 때까지 이러한 연결의 모든 메시지 처리를 지연합니다(예를 들어, 클라이언트가 메시지를 보내려고 하면 서비스가 다시 시작될 때까지 send 메소드가 차단됨).

• 브로커가 이미 수신한 메시지의 메시지 전달 상태는 그대로 유지됩니다(예를 들어, 트랜잭션이 중단되지 않고 서비스가 다시 시작되면 메시지 전달이 재개됨).

서비스를 다시 시작하려면 resume svc 하위 명령을 사용합니다.

다음은 resume svc 하위 명령 구문입니다.

imqcmd resume svc -n serviceName[-b 
hostName:portNumber]

이 하위 명령은 기본 브로커 또는 지정한 호스트 및 포트에서 실행 중인 지정된 서비스를 다시 시작합니다.

연결 정보 얻기

imqcmd 유틸리티의 하위 명령을 사용하여 연결 정보를 나열하고 가져올 수 있습니다.

list cxn 하위 명령은 지정된 서비스 이름의 모든 연결을 나열합니다. 다음은 list cxn 하위 명령 구문입니다.

imqcmd list cxn [-svn serviceName] [-b 
hostName:portNumber]

이 하위 명령은 기본 브로커 또는 지정한 호스트 및 포트의 브로커에서 지정된 서비스 이름의 연결을 모두 나열합니다.서비스 이름을 지정하지 않는 경우 모든 연결이 나열됩니다.

예를 들어, 다음 명령은 기본 브로커에 대한 모든 연결을 나열합니다.

imqcmd list cxn -u admin

이 명령은 비밀번호를 묻는 메시지를 표시한 후 다음과 같은 출력을 생성합니다.

Listing all the connections on the broker specified by:
-----------------------------------
Host                   Primary Port
------------------------------------
localhost              7676

---------------------------------------------------------------------------
Connection ID         User    Service   Producers  Consumers    Host
---------------------------------------------------------------------------
1964412264455443200   guest   jms       0          1            127.0.0.1
1964412264493829311   admin   admin     1          1            127.0.0.1

Successfully listed connections.

단일 연결 서비스에 대한 정보를 쿼리 및 표시하려면 query 하위 명령을 사용합니다.

query cxn -n connectionID [-b 
hostName:portNumber]

이 하위 명령은 기본 브로커 또는 지정한 호스트 및 포트의 브로커에서 지정된 연결에 대한 정보를 표시합니다.

예를 들면 다음과 같습니다.

imqcmd query cxn -n 421085509902214374 -u admin

이 명령은 비밀번호를 묻는 메시지를 표시한 후 다음과 같은 출력을 생성합니다.

Connection ID      421085509902214374
User               guest
Service            jms
Producers          0
Consumers          1
Host               111.22.333.444
Port               60953
Client ID          
Client Platform    

영구 가입 관리

imqcmd 하위 명령을 사용하면 다음 중 하나를 수행하여 브로커의 영구 가입을 관리할 수 있습니다.

• 영구 가입 나열

• 영구 가입에 대한 모든 메시지 제거

• 영구 가입 완전 삭제

영구 가입은 클라이언트에 영구로 등록된 주제에 가입하는 것입니다. 여기에는 고유한 아이디가 있으며, 사용자가 비활성 상태인 동안에도 브로커에서 가입에 대한 메시지를 보존해야 합니다. 보통 브로커는 메시지가 만료될 때 영구 가입자에 대해 보존된 메시지만 삭제할 수 있습니다.

지정된 물리적 대상에 대한 영구 가입을 나열하려면 list dur 하위 명령을 사용합니다. 다음은 list dur 하위 명령 구문입니다.

imqcmd list dur -d destName

예를 들어, 다음 명령은 로컬 호스트의 기본 포트에서 브로커를 사용하여 SPQuotes 주제에 대한 모든 영구 가입을 나열합니다.

imqcmd list dur -d SPQuotes

list dur 하위 명령은 주제의 각 영구 가입에 대해 영구 가입의 이름과 사용자의 클라이언트 아이디, 이 주제의 대기열에 들어 있는 메시지의 수, 영구 가입 상태(활성/비활성)를 반환합니다. 예를 들면 다음과 같습니다.

Name        Client ID       Number of   Durable Sub
                            Messages      State
----------------------------------------------------------------
myDurable   myClientID       1           INACTIVE

list dur 하위 명령에서 반환된 정보를 사용하여 완전 삭제하거나 메시지를 제거할 영구 가입을 확인할 수 있습니다.

purge dur 하위 명령은 지정된 클라이언트 식별자를 사용하여 지정된 영구 가입에 대한 모든 메시지를 제거합니다. 다음은 purge dur 하위 명령 구문입니다.

imqcmd purge dur -n subscrName -c 
clientID

destroy dur 하위 명령은 지정한 클라이언트 식별자에 해당하는 지정된 영구 가입을 완전 삭제합니다. 다음은 destroy dur 하위 명령 구문입니다.

imqcmd destroy dur -n subscrName -c 
clientID

예를 들어, 다음 명령은 영구 가입 myDurable과 클라이언트 아이디 myClientID를 완전 삭제합니다.

imqcmd destroy dur -n myDurable -c myClientID

트랜잭션 관리

클라이언트 응용 프로그램에서 시작하는 모든 트랜잭션은 브로커에서 추적됩니다. 이는 단순한 Message Queue 트랜잭션일 수도 있고 분산 트랜잭션(XA 자원) 관리자가 관리하는 분산 트랜잭션일 수도 있습니다.

모든 트랜잭션에는 브로커의 트랜잭션을 고유하게 나타내는 64비트 숫자 즉, Message Queue 트랜잭션 아이디가있습니다. 분산 트랜잭션에도 분산 트랜잭션 관리자가 할당하는 최대 128바이트의 분산 트랜잭션 아이디(XID)가 있습니다. Message Queue에서는 Message Queue 트랜잭션 아이디와 XID 사이의 연결을 보존합니다.

분산 트랜잭션에 오류가 발생하면 그 트랜잭션은 PREPARED 상태로 남아 완결되지 않을 수도 있습니다. 따라서 관리자는 준비된 상태로 남아 있는 트랜잭션을 모니터하고 롤백 또는 완결해야 합니다.

브로커가 추적 중인 모든 트랜잭션을 나열하려면 list txn 명령을 사용합니다. 다음은 list tx 하위 명령 구문입니다.

imqcmd list txn

예를 들어, 다음 명령은 브로커에 있는 모든 트랜잭션을 나열합니다.

imqcmd list txn

list 하위 명령은 각 트랜잭션에 대해 트랜잭션 아이디, 상태, 사용자 이름, 메시지 또는 확인 응답의 수, 작성 시간을 반환합니다. 예를 들면 다음과 같습니다.

---------------------------------------------------------------
Transaction ID  State    User name   # Msgs/   Creation time
                                     # Acks
---------------------------------------------------------------

64248349708800  PREPARED  guest      4/0      1/30/02 10:08:31 AM
64248371287808  PREPARED  guest      0/4      1/30/02 10:09:55 AM

명령은 브로커에 있는 로컬 및 분산 트랜잭션을 모두 표시합니다. PREPARED 상태인 트랜잭션만을 완결 또는 롤백할 수 있습니다. 트랜잭션이 오류로 인해 준비 상태에 있고 분산 트랜잭션 관리자에서 완결을 진행하고 있지 않다는 것이 확인된 경우에만 완결 또는 롤백할 수 있습니다.

예를 들어, 브로커의 자동 롤백 등록 정보가 false로 설정되어 있으면(표 14–2 참조) 브로커를 시작할 때 PREPARED 상태인 트랜잭션을 수동으로 완결 또는 롤백해야 합니다.

list 하위 명령도 트랜잭션에서 생성된 메시지의 수와 트랜잭션에서 확인 응답된(#Msgs/#Acks) 메시지의 수를 표시합니다. 트랜잭션이 완결될 때까지는 이런 메시지가 전달되지 않으며 확인 응답이 처리되지도 않습니다.

query 하위 명령을 사용하면 클라이언트 아이디, 연결 아이디, 분산 트랜잭션 아이디(XID) 등의 여러 추가 값을 볼 수 있습니다. 다음은 query txn 하위 명령 구문입니다.

imqcmd query txn -n transactionID

예를 들어, 다음 예는 아래와 같은 출력을 생성합니다.

imqcmd query txn -n 64248349708800

Client ID
Connection                 guest@192.18.116.219:62209->jms:62195
Creation time              1/30/02 10:08:31 AM
Number of acknowledgments 0
Number of messages         4
State                      PREPARED
Transaction ID             64248349708800
User name                  guest
XID
6469706F6C7369646577696E6465723130313234313431313030373230

commit 및 rollback 하위 명령을 사용하여 분산 트랜잭션을 완결 또는 롤백할 수 있습니다. 앞에서 설명한 것과 같이, PREPARED 상태에 있는 트랜잭션만 완결 또는 롤백할 수 있습니다.

다음은 commit 하위 명령 구문입니다.

imqcmd commit txn -n transactionID

예를 들면 다음과 같습니다.

imqcmd commit txn -n 64248349708800

다음은 rollback 하위 명령 구문입니다.

imqcmd rollback txn -n transactionID

자세한 내용은 표 14–2의 imq.transaction.autorollback 등록 정보를 참조하십시오.

브로커를 시작할 때 PREPARED 상태에 있는 트랜잭션을 자동으로 롤백하도록 브로커를 구성할 수도 있습니다.

6장 물리적 대상 관리

이 장에서는 imqcmd 유틸리티를 사용하여 물리적 대상을 관리하는 방법에 대해 설명합니다. Message Queue^TM 메시지는 브로커의 물리적 대상을 통해 사용자 클라이언트로 라우팅됩니다. 브로커는 물리적 대상에 연결된 메모리와 영구 저장소를 관리하고 해당 동작을 설정합니다.

브로커 클러스터에서 브로커 하나에 물리적 대상을 만들면 클러스터가 해당 물리적 대상을 모든 다른 브로커에 전파합니다. 브로커는 공동 작업을 통해 클러스터 전체에서 메시지 경로를 지정하기 때문에 응용 프로그램 클라이언트는 항목에 가입하거나 클러스터의 모든 브로커에 있는 대기열을 사용할 수 있습니다. 하지만 메시지가 처음 생성된 브로커에서만 해당 메시지에 대한 지속성과 확인을 관리할 수 있습니다.

이 장은 다음 내용으로 구성되어 있습니다.

• 명령 유틸리티 사용

• 물리적 대상 만들기

• 물리적 대상 나열

• 물리적 대상 정보 표시

• 물리적 대상 등록 정보 업데이트

• 물리적 대상 일시 중지 및 다시 시작

• 물리적 대상 제거

• 물리적 대상 완전 삭제

• 물리적 대상 압축

• 사용 불능 메시지 대기열 사용

표 13–5는 물리적 대상 관리와 이러한 작업 수행에 사용되는 imqcmd 하위 명령에 대한 전체 참조 정보를 제공합니다.

물리적 대상에 대한 소개는 Message Queue 기술 개요를 참조하십시오.

클라이언트 응용 프로그램은 물리적 대상과 상호 작용할 때마다 Destination 객체를 사용합니다. 공급자 독립성과 이식성을 위해 클라이언트는 대상 관리 객체라는 관리자 생성 대상 객체를 일반적으로 사용합니다. 8 장, 관리 대상 객체 관리에서 설명한 대로 클라이언트 응용 프로그램에 사용하도록 관리 대상 객체를 구성할 수 있습니다.

명령 유틸리티 사용

Message Queue 명령 유틸리티(imqcmd)를 사용하여 물리적 대상을 관리합니다. imqcmd 명령 구문은 다른 브로커 서비스 관리에 사용할 때의 구문과 동일합니다.

imqcmd와 해당 하위 명령과 옵션에 대한 자세한 내용은 13 장, 명령줄 참조에서 확인할 수 있습니다.

하위 명령

표 6–1에는 이 장에서 설명하는 imqcmd 하위 명령이 나열되어 있습니다. 이러한 하위 명령에 대한 자세한 내용은 물리적 대상 관리를 참조하십시오.

물리적 대상 만들기

물리적 대상을 만들려면 imqcmd create 하위 명령을 사용합니다. 다음은 create 하위 명령 구문입니다.

create dst -t destType -n 
destName [-o property=value
] [-o property=value1]
…

예를 들어, 대기열 대상을 만들려면 다음과 같이 명령을 입력합니다.

imqcmd create dst -n myQueue -t q -o "maxNumActiveConsumers=5"

주제 대상을 만들려면 다음과 같이 명령을 입력합니다.

imqcmd create dst -n myTopic -t t -o "maxBytesPerMsg=5000"

물리적 대상을 만들 때 다음을 지정해야 합니다.

• 물리적 대상 유형, t(주제) 또는 q(대기열).

• 물리적 대상 이름. 이름 지정 규칙은 다음과 같습니다.

  • 이름은 영숫자만 포함할 수 있으며공백을 포함할 수 없습니다.

  • 이름은 영문자, 밑줄 문자(_) 또는 달러 기호($)로 시작할 수 있습니다. mq 문자열로는 시작할 수 없습니다.

  기본값이 아닌 모든 물리적 대상 등록 정보 값

물리적 대상을 업데이트할 때 등록 정보도 설정할 수 있습니다.

많은 물리적 대상 등록 정보가 브로커 메모리 자원과 메시지 흐름에 영향을 미칩니다. 예를 들어, 물리적 대상에 보낼 수 있는 생성자 수, 생성자가 보낼 수 있는 메시지 수와 크기, 물리적 대상 제한에 도달할 때 브로커가 수행해야 하는 응답 등을 지정할 수 있습니다. 이러한 제한은 브로커 구성 등록 정보를 통해 제어되는 브로커 전체 제한과 비슷합니다.

다음 등록 정보는 대기열 대상과 주제 대상 모두에 사용됩니다.

• maxNumMsgs. 물리적 대상에 허용되는 사용되지 않은 최대 메시지 수를 지정합니다.

• maxTotalMsgBytes. 물리적 대상의 사용되지 않은 메시지에 허용되는 최대 메모리 합계(바이트)를 지정합니다.

• limitBehavior. 메모리 제한 임계값에 도달할 경우에 브로커가 응답하는 방법을 지정합니다.

• maxBytesPerMsg. 물리적 대상에 허용되는 단일 메시지의 최대 크기(바이트)를 지정합니다.

• maxNumProducers. 물리적 대상의 최대 생성자 수를 지정합니다.

• consumerFlowLimit. 일괄적으로 사용자에게 전달되는 최대 메시지 수를 지정합니다.

• isLocalOnly. 브로커 클러스터에만 적용됩니다. 물리적 대상이 다른 브로커에 복제되지 않도록 지정합니다. 따라서, 메시지 전달이 로컬 사용자(물리적 대상이 생성되는 브로커에 연결된 사용자)에게만 제한됩니다.

• useDMQ. 물리적 대상의 사용 불능 메시지를 제거할지, 사용 불능 메시지 대기열에 넣을지를 지정합니다.

다음은 대기열 대상에만 사용되는 등록 정보입니다.

• maxNumActiveConsumers. 대기열 대상으로부터의 로드 균형 조정 전달에서 활성 상태가 될 수 있는 최대 사용자 수를 지정합니다.

• maxNumBackupConsumers. 대기열 대상으로부터의 로드 균형 조정 전달 중에 오류가 발생할 경우 활성 사용자를 대신할 수 있는 백업 사용자의 최대 수를 지정합니다.

• localDeliveryPreferred. 브로커 클러스터의 로드 균형 조정된 대기열 전달에만 적용됩니다. 로컬 브로커에 사용자가 없는 경우에만 원격 사용자에게 메시지를 전달하도록 지정합니다.

물리적 대상 등록 정보에 대한 자세한 내용은 15 장, 물리적 대상 등록 정보 참조을 참조하십시오.

자동 생성 대상의 경우 브로커의 인스턴스 구성 파일에 기본 등록 정보 값을 설정합니다. 자동 생성 등록 정보에 대한 자세한 내용은 표 14–3을 참조하십시오.

물리적 대상 나열

물리적 대상의 현재 속성 값, 물리적 대상과 연관된 생성자 또는 사용자 수 및 메시징 메트릭(물리적 대상의 메시지 수 및 크기 등)에 대한 정보를 얻을 수 있습니다.

정보를 얻으려는 물리적 대상을 찾으려면 list dst 하위 명령을 사용하여 브로커의 모든 물리적 대상을 나열합니다. 다음은 list dst 하위 명령 구문입니다.

list dst [-t destType] [-tmp]

이 명령은 지정된 유형의 물리적 대상을 나열합니다. 대상 유형(-t) 옵션 값은 q(대기열) 또는 t(주제)입니다.

대상 유형을 생략하면 모든 유형의 물리적 대상이 나열됩니다.

list dst 하위 명령에서는 나열할 대상의 유형을 지정하거나 임시 대상을 포함하도록 지정할 수도 있습니다(-tmp 옵션 사용). 임시 대상은 일반적으로 다른 클라이언트에 보낸 메시지에 대한 응답을 수신하기 위해 클라이언트가 만듭니다.

예를 들어, myHost의 포트 4545에서 실행 중인 브로커의 모든 물리적 대상을 나열하려면 다음 명령을 입력합니다.

imqcmd list dst -b myHost:4545

주제만 포함하도록 t 대상 유형을 지정하지 않는 한 mq.sys.dmq 사용 불능 메시지 대기열에 대한 정보가 항상 다른 물리적 대상과 함께 표시됩니다.

물리적 대상 정보 표시

물리적 대상의 현재 등록 정보에 대한 정보를 보려면 query dst 하위 명령을 사용합니다. 다음은 query dst 하위 명령 구문입니다.

query dst -t destType -n 
destName

이 명령은 지정한 유형과 이름의 대상에 대한 정보를 나열합니다.예를 들어, 다음 명령은 XQueue 대기열 대상에 대한 정보를 표시합니다.

imqcmd query dst -t q -n XQueue -u admin

다음과 같은 결과가 출력됩니다.

------------------------------------
Destination Name    Destination Type
------------------------------------
XQueue              Queue

On the broker specified by:

-------------------------
Host         Primary Port
-------------------------
localhost    7676

Destination Name                      XQueue
Destination Type                      Queue
Destination State                     RUNNING
Created Administratively              true

Current Number of Messages            0
Current Total Message Bytes           0
Current Number of Producers           0
Current Number of Active Consumers    0
Current Number of Backup Consumers    0

Max Number of Messages                unlimited (-1)
Max Total Message Bytes               unlimited (-1)
Max Bytes per Message                 unlimited (-1)
Max Number of Producers               100
Max Number of Active Consumers        1
Max Number of Backup Consumers        0

Limit Behavior                        REJECT_NEWEST
Consumer Flow Limit                   1000
Is Local Destination                  false
Local Delivery is Preferred           false
Use Dead Message Queue                true

출력에는 해당 대상에 연관되어 있는 생성자와 사용자 수도 표시됩니다. 대기열 대상의 경우 이 수에는 활성 사용자와 백업 사용자가 포함됩니다.

update dst 하위 명령을 사용하여 하나 이상의 등록 정보 값을 변경할 수 있습니다( 물리적 대상 등록 정보 업데이트 참조).

물리적 대상 등록 정보 업데이트

update dst 하위 명령과 업데이트할 등록 정보를 지정하는 -o 옵션을 사용하여 물리적 대상의 등록 정보를 변경할 수 있습니다. 다음은 update dst 하위 명령 구문입니다.

update dst -t destType -n 
destName -o property=value [[-o 
property=value1]…]

이 명령은 지정한 대상에서 지정한 등록 정보의 값을 업데이트합니다.등록 정보 이름은 표 15–1에 나열된 등록 정보 중 하나일 수 있습니다.

-o 옵션을 여러 번 사용하여 여러 등록 정보를 업데이트할 수 있습니다. 예를 들어, 다음 명령은 maxBytesPerMsg 등록 정보를 1000으로 변경하고 MaxNumMsgs 등록 정보를 2000으로 변경합니다.

imqcmd update dst -t q -n myQueue -o "maxBytesPerMsg=1000"
              -o "maxNumMsgs=2000" -u admin

업데이트할 수 있는 등록 정보 목록은 15 장, 물리적 대상 등록 정보 참조을 참조하십시오.

update dst 하위 명령을 사용하여 물리적 대상의 유형을 업데이트하거나 isLocalOnly 등록 정보를 업데이트할 수 없습니다.

사용 불능 메시지 대기열은 등록 정보가 다른 대상과 약간 차이가 나는 특수한 물리적 대상입니다. 자세한 내용은 사용 불능 메시지 대기열 사용을 참조하십시오.

물리적 대상 일시 중지 및 다시 시작

물리적 대상을 일시 중지하여 생성자에서 대상으로, 대상에서 사용자로 또는 두 가지 모두에 대한 메시지 전달을 제어할 수 있습니다. 특히, 대상으로의 메시지 흐름을 일시 중지하면 메시지 생성이 사용보다 훨씬 빠를 때 대상에서 메시지가 넘치는 것을 방지할 수 있습니다.물리적 대상을 압축하려면 먼저 일시 중지해야 합니다.

물리적 대상에서 주고 받는 메시지 전달을 일시 중지하려면 pause dst 하위 명령을 사용합니다. 다음은 pause dst 하위 명령 구문입니다.

pause dst [-t destType -n 
destName] [-pst pauseType]

지정된 유형과 이름의 대상에서 사용자에게 메시지 전달(-pst CONSUMERS), 생성자로부터 메시지 전달(-pst PRODUCERS) 또는 두 가지 모두(-pst ALL)를 일시 중지합니다.대상 유형과 이름을 지정하지 않은 경우 모든 물리적 대상이 일시 중지됩니다. 기본값은 ALL입니다.

예:

imqcmd pause dst -n myQueue -t q -pst PRODUCERS -u admin
imqcmd pause dst -n myTopic -t t -pst CONSUMERS -u admin

일시 중지된 대상으로의 전달을 다시 시작하려면 resume dst 하위 명령을 사용합니다. 다음은 resume dst 하위 명령 구문입니다.

resume dst [-t destType -n 
destName]

이 하위 명령은 지정된 유형과 이름의 일시 중지된 대상으로의 메시지 전달을 다시 시작합니다.대상 유형과 이름을 지정하지 않으면 모든 대상이 다시 시작됩니다.

예:

imqcmd resume dst -n myQueue -t q

브로커 클러스터에서 물리적 대상 인스턴스는 클러스터의 각 브로커에 있습니다. 각 인스턴스를 개별적으로 일시 중지해야 합니다.

물리적 대상 제거

현재 물리적 대상의 대기열에 들어 있는 모든 메시지를 제거할 수 있습니다. 물리적 대상을 제거하는 것은 대상에 저장된 모든 메시지를 삭제하는 것을 의미합니다.

누적된 메시지가 시스템의 자원을 너무 많이 차지하는 경우에 메시지를 제거할 수 있습니다. 이런 상황은 대기열에 등록된 사용자 클라이언트가 없는 상태에서 너무 많은 메시지를 받으면 발생할 수 있습니다. 주제의 비활성 영구 가입자가 활성화되지 않는 경우에도 발생할 수 있습니다. 두 경우 모두 불필요한 메시지가 보존됩니다.

물리적 대상의 메시지를 제거하려면 purge dst 하위 명령을 사용합니다. 다음은 purge dst 하위 명령 구문입니다.

purge dst -t destType -n 
destName

이 하위 명령은 지정한 유형과 이름의 물리적 대상에서 메시지를 제거합니다.

예:

imqcmd purge dst -n myQueue -t q -u admin
imqcmd purge dst -n myTopic -t t -u admin

브로커를 종료했다가 다시 시작할 때 오래된 메시지가 전달되지 않게 하려면 -reset messages 옵션을 사용하여 오래된 메시지를 제거합니다. 예를 들면 다음과 같습니다.

imqbrokerd -reset messages -u admin

그러면 브로커를 다시 시작한 후에 대상을 제거할 필요가 없습니다.

브로커 클러스터에서 물리적 대상 인스턴스는 클러스터의 각 브로커에 있습니다. 이러한 대상을 개별적으로 제거해야 합니다.

물리적 대상 완전 삭제

물리적 대상을 완전 삭제하려면 destroy dst 하위 명령을 사용합니다. 다음은 destroy dst 하위 명령 구문입니다.

destroy dst -t destType -n 
destName

이 하위 명령은 지정한 유형과 이름의 물리적 대상을 완전 삭제합니다.

예:

imqcmd destroy dst -t q -n myQueue -u admin

물리적 대상을 완전 삭제하면 대상에 있는 모든 메시지가 제거되고 대상이 브로커에서 제거됩니다. 이 작업은 다시 되돌릴 수 없습니다.

사용 불능 메시지 대기열은 완전 삭제할 수 없습니다.

물리적 대상 압축

파일 기반 데이터 저장소를 메시지의 영구 저장소로 사용하는 경우, 필요할 때마다 디스크 사용률을 모니터하고 디스크를 압축할 수 있습니다.

파일 기반 메시지 저장소는 메시지가 보관될 물리적 대상에 해당하는 디렉토리에 저장되도록 구성됩니다. 각 물리적 대상 디렉토리에서 대부분의 메시지는 가변 크기 레코드로 구성되는 단일 파일에 저장됩니다. (단편화를 줄이기 위해 크기가 구성 가능한 임계값을 초과하는 메시지는 자체의 개별 파일에 저장).

레코드 파일에서 다양한 크기의 메시지가 지속되다가 제거될 때 파일에서 사용 가능한 레코드가 다시 사용되지 않는 공간이 생길 수 있습니다.

사용되지 않은 사용 가능한 레코드를 관리하려면 명령 유틸리티의 하위 명령을 사용하여 물리적 대상별 디스크 사용률을 모니터하고 사용률이 떨어지면 사용 가능한 디스크 공간을 확보합니다.

물리적 대상 디스크 사용률 모니터링

물리적 대상의 디스크 사용률을 모니터하려면 다음과 같은 명령을 사용합니다.

imqcmd metrics dst -t q -n myQueue -m dsk -u admin

다음과 같은 결과가 출력됩니다.

--------------------------------------
Reserved   Used      Utilization Ratio
--------------------------------------
806400     804096    99
1793024    1793024   100
2544640    2518272   98

하위 명령 출력에서 각 열의 의미는 다음과 같습니다.

사용되지 않은 물리적 대상 디스크 공간 확보

특정 물리적 대상을 사용하는 메시징 응용 프로그램의 특성에 따라 디스크 사용률 패턴이 달라집니다. 물리적 대상에 유입 및 유출되는 메시지의 상대적 흐름과 상대적 메시지 크기에 따라 예약된 디스크 공간이 점점 더 커질 수 있습니다.

메시지 생성 속도가 메시지 사용 속도보다 큰 경우 사용 가능한 레코드를 다시 사용하고 사용률을 높은 수준으로 유지해야 합니다. 그러나 메시지 생성 속도가 메시지 사용 속도보다 작거나 비슷한 경우 사용률이 낮아도 됩니다.

일반적으로 예약된 디스크 공간은 안정적으로 유지하고 사용률은 높게 유지해야 합니다. 일반적으로 시스템에서 예약된 디스크 공간은 매우 일정하게 유지되고 사용률이 높은(75% 이상) 안정적인 상태에 도달하는 경우 사용되지 않는 디스크 공간을 확보할 필요가 없습니다. 시스템에서 안정적인 상태에 도달하고 사용률이 낮은(50% 이하) 경우 디스크를 압축하여 사용 가능한 레코드가 사용 중인 디스크 공간을 확보할 수 있습니다.

compact dst 하위 명령을 사용하여 데이터 저장소를 압축합니다. 다음은 compact dst 하위 명령 구문입니다.

compact dst [-t destType -n 
destName]

이 하위 명령은 파일 기반 데이터 저장소에서 지정된 유형과 이름의 물리적 대상을 압축합니다.대상 유형과 이름을 지정하지 않으면 모든 대상이 압축됩니다. 물리적 대상을 압축하려면 먼저 일시 중지해야 합니다.

예약된 디스크 공간이 점점 증가하는 경우 대상 메모리 제한 등록 정보와 제한 동작(표 15–1 참조)을 설정하여 대상의 메모리 관리를 다시 구성해야 합니다.

사용되지 않는 물리적 대상 디스크 공간을 확보하는 방법

1. 대상을 일시 중지합니다.

   imqcmd pause dst -t q -n myQueue -u admin

2. 디스크를 압축합니다.

   imqcmd compact dst -t q -n myQueue -u admin

3. 물리적 대상을 다시 시작합니다.

   imqcmd resume dst -t q -n myQueue -u admin

   대상 유형과 이름을 지정하지 않으면 이 작업이 모든 물리적 대상에 대해 수행됩니다.

사용 불능 메시지 대기열 사용

사용 불능 메시지 대기열 mq.sys.dmq는 브로커 및 다른 물리적 대상의 사용 불능 메시지를 보관하는 시스템 생성 물리적 대상입니다. 사용 불능 메시지 대기열은 모니터링, 시스템 효율성 조정 및 문제 해결을 위한 도구입니다. “사용 불능 메시지”의 용어 정의와 사용 불능 메시지 대기열에 대한 자세한 내용은 Message Queue 기술 개요를 참조하십시오.

브로커는 시작될 때 사용 불능 메시지 대기열을 자동으로 생성합니다. 브로커는 메시지를 처리할 수 없거나 수명이 만료된 경우 해당 메시지를 대기열에 넣습니다. 다른 물리적 대상도 사용 불능 메시지 대기열을 사용하여 제거된 메시지를 보관합니다. 사용 불능 메시지 대기열을 사용하면 시스템 문제 해결에 유용한 정보를 확인할 수 있습니다.

사용 불능 메시지 대기열 사용 구성

기본적으로 물리적 대상은 사용 불능 메시지 대기열을 사용하도록 구성됩니다. 물리적 대상 등록 정보 useDMQ를 설정하여 물리적 대상에서 사용 불능 메시지 대기열을 사용 불가능하게 하거나 사용 가능하게 할 수 있습니다.

다음 예에서는 기본적으로 사용 불능 메시지 대기열을 사용하는 myDist 대기열을 만듭니다.

imqcmd create dst -n myDist -t q

다음 예에서는 동일한 대기열에 대해 사용 불능 메시지 대기열을 사용 불가능하게 합니다.

imqcmd update dst -n myDist -t q -o useDMQ=false

imq.autocreate.destination.useDMQ 브로커 등록 정보를 설정하여 브로커의 모든 자동 생성 물리적 대상이 사용 불능 메시지 대기열을 사용 가능하게 하거나 사용 불가능하게 할 수 있습니다.

사용 불능 메시지 대기열 관리

Message Queue 명령 유틸리티(imqcmd)를 사용하면 약간의 차이는 있겠지만 다른 대기열을 관리하는 것처럼 사용 불능 메시지 대기열을 관리할 수 있습니다. 예를 들어, 사용 불능 메시지 대기열은 시스템에서 생성되기 때문에 사용자가 생성, 일시 중지 또는 완전 삭제할 수 없습니다. 또한 표 6–3에서 표시된 것처럼 사용 불능 메시지 대기열의 기본값은 경우에 따라 일반 대기열의 기본값과 다를 수도 있습니다.

사용 불능 메시지 대기열 등록 정보

사용 불능 메시지 대기열은 다른 대기열과 같은 방법으로 구성하지만 특정 물리적 대상 등록 정보가 적용되지 않거나 다른 기본값을 갖습니다. 표 6–3에는 사용 불능 메시지 대기열에서 고유한 방법으로 처리하는 대기열 등록 정보가 나열되어 있습니다.

메시지 내용

브로커는 헤더와 등록 정보 데이터만 유지하고 전체 메시지를 사용 불능 메시지 대기열에 넣거나 메시지 본문 내용을 삭제할 수 있습니다. 기본적으로 사용 불능 메시지 대기열은 전체 메시지를 저장합니다.

사용 불능 대기열의 크기를 줄이거나 사용 불능 메시지를 복원하지 않으려면 imq.destination.DMQ.truncateBody 브로커 등록 정보를 true로 설정하는 것을 고려해 보십시오.

imqcmd update bkr -o imq.destination.DMQ.truncateBody=true

그러면 메시지 본문이 삭제되고 헤더와 등록 정보 데이터만 유지됩니다.

사용 불능 메시지 로깅 사용

사용 불능 메시지 로깅은 기본적으로 비활성화됩니다. 사용 불능 메시지 로깅을 사용하면 브로커에서 다음 이벤트를 기록할 수 있습니다.

• 브로커가 메시지를 사용 불능 메시지 대기열로 이동합니다.

• 브로커가 사용 불능 메시지 대기열과 사용 불능 메시지 대기열을 사용하지 않는 모든 물리적 대상에서 메시지를 제거합니다.

• 물리적 대상이 한계에 도달했습니다.

다음 명령은 사용 불능 메시지 로깅을 활성화합니다.

imqcmd update bkr -o imq.destination.logDeadMsgs=true

사용 불능 메시지 로깅은 사용 불능 메시지 대기열을 사용하는 모든 물리적 대상에 적용됩니다. 개별 물리적 대상에 대해 로깅을 활성화하거나 비활성화할 수 없습니다.

7장 보안 관리

사용자 인증에 사용할 사용자 저장소를 구성하고 액세스 제어를 정의하며 클라이언트 브로커 통신을 암호화하는 SSL(Secure Socket Layer) 연결 서비스를 구성하고 브로커를 시작할 때 사용할 비밀번호 파일을 설정함으로써 보안을 관리합니다.

이 장은 다음 내용으로 구성되어 있습니다.

• 사용자 인증

• 사용자 권한 부여: 액세스 제어 등록 정보 파일

• 메시지 암호화

• 비밀번호 파일

• 감사 기록

사용자 인증

사용자가 브로커에 연결하려고 시도하면 브로커는 제공된 이름과 비밀번호를 검사하여 사용자를 인증합니다. 이름과 비밀번호가 각 브로커가 참조하도록 구성된 브로커별 사용자 저장소의 이름 및 비밀번호와 일치하면 브로커는 연결을 허용합니다.

사용자 저장소에서 사용자 목록, 해당 그룹, 비밀번호를 관리해야 합니다. 브로커 인스턴스마다 다른 사용자 저장소를 사용할 수 있습니다. 이 절에서는 이러한 저장소를 만들고 채우고 관리하는 방법에 대해 설명합니다.

저장소 유형은 다음 중 하나가 될 수 있습니다.

• Message Queue^TM와 함께 제공되는 플랫 파일 저장소

  이 사용자 저장소 유형은 사용하기가 매우 쉽습니다. 사용자 관리자 유틸리티(imqusermgr)를 사용하면 저장소를 채우고 관리할 수 있습니다. 인증을 사용하려면 각 사용자의 이름, 비밀번호, 사용자 그룹 이름으로 사용자 저장소를 채웁니다.

  사용자 저장소의 설정 및 관리에 대한 자세한 내용은 플랫 파일 사용자 저장소 사용을 참조하십시오.

• LDAP 서버

  LDAP v2 또는 v3 프로토콜을 사용하는 기존 또는 새 LDAP 디렉토리 서버가 될 수 있습니다. 플랫 파일 저장소만큼 사용이 쉽지는 않지만 더 확장 가능하므로 작업 환경에 적합합니다.

  LDAP 사용자 저장소를 사용하는 경우에는 LDAP 공급업체에서 제공하는 도구를 사용하여 사용자 저장소를 채우고 관리해야 합니다. 자세한 내용은 사용자 저장소에 LDAP 서버 사용을 참조하십시오.

플랫 파일 사용자 저장소 사용

Message Queue에서는 플랫 파일 사용자 저장소와 플랫 파일 사용자 저장소를 채우고 관리할 때 사용할 수 있는 명령줄 도구인 사용자 관리자 유틸리티(imqusermgr)를 제공합니다. 다음 절에서는 플랫 파일 사용자 저장소에 대해 설명하고 사용자 관리자 유틸리티를 사용하여 해당 저장소를 채우고 관리하는 방법을 설명합니다.

사용자 저장소 만들기

플랫 파일 사용자 저장소는 인스턴스마다 다릅니다. 기본 사용자 저장소(passwd)는 사용자가 시작하는 각 브로커 인스턴스에 대해 자동으로 만들어집니다. 이 사용자 저장소는 저장소와 연관된 브로커 인스턴스의 이름으로 식별되는 디렉토리에 저장됩니다(부록 A, 플랫폼별 Message Queue^TM 데이터 위치 참조).

   …/instances/instanceName/etc/passwd

저장소는 이 두 항목을 사용하여 만들어집니다. 표 7–1의 각 행은 하나의 항목을 나타냅니다.

이러한 초기 항목을 사용하면 관리자가 개입하지 않아도 설치 후 바로 Message Queue 브로커를 사용할 수 있습니다.

• 초기 guest 사용자 항목을 사용하면 클라이언트가 기본 guest 사용자 이름과 비밀번호를 사용하여 브로커 인스턴스에 연결할 수 있습니다.

• 초기 admin 사용자 항목을 사용하면 imqcmd 명령을 사용하여 기본 admin 사용자 이름과 비밀번호로 브로커 인스턴스를 관리할 수 있습니다. 비밀번호를 변경하려면 이 초기 항목을 업데이트해야 합니다( 기본 관리자 비밀번호 변경 참조).

다음 절에서는 플랫 파일 사용자 저장소를 채우고 관리하는 방법을 설명합니다.

사용자 관리자 유틸리티

Message Queue 사용자 관리자 유틸리티(imqusermgr)를 사용하면 플랫 파일 사용자 저장소를 편집하거나 채울 수 있습니다. 이 절에서는 사용자 관리자 유틸리티에 대해 소개합니다. 다음 절에서는 imqusermgr 하위 명령을 사용하여 특정 작업을 수행하는 방법에 대해 설명합니다.

imqusermgr 명령에 대한 자세한 내용은 13 장, 명령줄 참조을 참조하십시오.

사용자 관리자를 사용하기 전에 주의해야 할 사항은 다음과 같습니다.

• 브로커별 사용자 저장소가 없는 경우 해당 브로커 인스턴스를 시작하여 브로커별 사용자 저장소를 만들어야 합니다.

• imqusermgr 명령은 브로커가 설치된 호스트에서 실행해야 합니다.

• 저장소에 쓸 수 있는 적절한 권한이 필요합니다. 즉, Solaris 및 Linux의 경우 해당 브로커 인스턴스를 처음으로 만든 사용자나 루트 사용자여야 합니다.

다음 절의 예에서는 기본 브로커 인스턴스인 경우를 가정합니다.

하위 명령

imqusermgr 명령에는 add, delete, list 및 update 하위 명령이 있습니다.

• add 하위 명령은 지정한(또는 기본) 브로커 인스턴스 저장소에 사용자와 관련 비밀번호를 추가하고 선택적으로 사용자 그룹을 지정합니다. 하위 명령의 구문은 다음과 같습니다.

  add [-i instanceName] -u userName -p passwd [-g group] [ -s]

• delete 하위 명령은 지정한(또는 기본) 브로커 인스턴스 저장소에서 지정한 사용자를 삭제합니다. 하위 명령의 구문은 다음과 같습니다.

  delete [-i instanceName] -u userName [ -s] [-f]

• list 하위 명령은 지정한(또는 기본) 브로커 인스턴스 저장소의 지정한 사용자 또는 모든 사용자에 대한 정보를 표시합니다. 하위 명령의 구문은 다음과 같습니다.

  list [ -i instanceName] [-u userName]

• update 하위 명령은 지정한(또는 기본) 브로커 인스턴스 저장소에 있는 지정한 사용자의 비밀번호 및/또는 상태를 업데이트합니다. 하위 명령의 구문은 다음과 같습니다.

  update [ -i instanceName] -u userName -p passwd [ -a state] [-s] [ -f]

  update [-i instanceName] -u userName -a state [-p passwd] [-s] [-f]

명령 옵션

표 7–2에서는 imqusermgr 명령의 옵션이 나열되어 있습니다.

그룹

브로커 인스턴스의 사용자 저장소에 사용자 항목을 추가할 때, 사전 정의된 admin, user 또는 anonymous의 세 가지 그룹 중 하나를 지정할 수 있습니다. 그룹을 지정하지 않으면 기본 그룹인 user가 할당됩니다. 그룹은 다음과 같이 할당해야 합니다.

• admin 그룹. 브로커 관리자에 사용됩니다. 이 그룹에 할당된 사용자는 기본적으로 브로커를 구성하고 관리할 수 있습니다. admin 그룹에 사용자를 두 명 이상 할당할 수도 있습니다.

• user 그룹. 관리자가 아닌 일반 Message Queue 클라이언트 사용자에 사용됩니다. 대부분의 클라이언트 사용자는 user 그룹에 속합니다. 기본적으로 이 그룹의 사용자는 모든 주제와 대기열에 메시지를 생성하고 모든 주제와 대기열에서 메시지를 사용하고 모든 대기열에서 메시지를 찾아볼 수 있습니다.

• anonymous 그룹. 브로커에 알려진 사용자 이름을 사용하지 않는(클라이언트 응용 프로그램에서 사용해야 할 실제 사용자 이름을 모르기 때문일 수 있음) Message Queue 클라이언트에 사용됩니다. 이 계정은 대부분의 FTP 서버에 있는 anonymous 계정과 유사합니다. anonymous 그룹에는 한 번에 한 사용자만 할당할 수 있습니다. user 그룹과 비교하여 이 그룹의 액세스 권한을 제한하거나, 배포 시 그룹에서 사용자를 제거해야 합니다.

사용자의 그룹을 변경하려면, 사용자 항목을 삭제한 후 그 사용자에 다른 항목을 추가하여 새 그룹을 지정해야 합니다.

시스템에서 생성한 그룹의 경우 이름을 변경하거나 삭제할 수 없습니다. 또한 새 그룹을 만들 수도 없습니다. 하지만 해당 그룹의 구성원이 수행할 수 있는 작업을 정의하는 액세스 규칙을 지정할 수 있습니다. 자세한 내용은 사용자 권한 부여: 액세스 제어 등록 정보 파일을 참조하십시오.

사용자 상태

사용자를 저장소에 추가하면 그 사용자는 기본적으로 활성 상태가 됩니다. 사용자를 비활성 상태로 만들려면 update 명령을 사용해야 합니다. 예를 들어, 다음 명령은 사용자 JoeD를 비활성 상태로 만듭니다.

imqusermgr update -u JoeD -a false

비활성 상태인 사용자의 항목은 저장소에 보존되지만, 비활성 상태인 사용자가 새 연결을 열 수는 없습니다. 사용자가 비활성 상태일 때 같은 이름을 가진 다른 사용자를 추가하면 작업이 실패합니다. 비활성 사용자 항목을 삭제하거나, 새 사용자의 이름을 변경하거나, 새 사용자에게 다른 이름을 사용해야 합니다. 그러면 중복되는 사용자 이름을 추가하지 않게 됩니다.

사용자 이름 및 비밀번호 형식

사용자 이름과 비밀번호는 다음과 같은 지침을 따라야 합니다.

• 사용자 이름에는 별표(*), 쉼표(,), 콜론(:), 줄바꿈 또는 캐리지 리턴 문자가 포함되지 않아야 합니다.

• 사용자 이름 또는 비밀번호는 한 문자 이상이어야 합니다.

• 사용자 이름 또는 비밀번호에 공백이 포함된 경우에는 이름 또는 비밀번호 전체를 따옴표로 묶어야 합니다.

• 명령 쉘에서 명령줄에 입력할 수 있는 최대 문자 수가 제한되어 있는 것 외에는 비밀번호 또는 사용자 이름에 적용되는 길이 제한은 없습니다.

사용자 저장소 채우기 및 관리

저장소에 사용자를 추가하려면 add 하위 명령을 사용합니다. 예를 들어, 다음 명령은 기본 브로커 인스턴스 사용자 저장소에 비밀번호가 sesame인 사용자 Katharine을 추가합니다.

imqusermgr add -u Katharine -p sesame -g user

저장소에서 사용자를 삭제하려면 delete 하위 명령을 사용합니다. 예를 들어, 다음 명령은 Bob이라는 사용자를 삭제합니다.

imqusermgr delete -u Bob

사용자의 비밀번호 또는 상태를 변경하려면 update 하위 명령을 사용합니다. 예를 들어, 다음 명령은 Katharine의 비밀번호를 aladdin으로 변경합니다.

imqusermgr update -u Katharine -p aladdin

한 사용자 또는 모든 사용자에 대한 정보를 나열하려면 list 명령을 사용합니다. 다음 명령은 isa라는 사용자에 대한 정보를 표시합니다.

imqusermgr list -u isa

% imqusermgr list -u isa

User repository for broker instance: imqbroker
----------------------------------
User Name    Group    Active State
----------------------------------
isa          admin    true

다음 명령은 모든 사용자에 대한 정보를 나열합니다.

imqusermgr list

% imqusermgr list

User repository for broker instance: imqbroker
--------------------------------------
User Name    Group        Active State
--------------------------------------
admin        admin        true
guest        anonymous    true
isa          admin        true
testuser1    user         true
testuser2    user         true
testuser3    user         true
testuser4    user         false
testuser5    user         false

기본 관리자 비밀번호 변경

보안을 위해 admin의 기본 비밀번호를 자신만 아는 비밀번호로 변경해야 합니다. 다음 명령은 mybroker 브로커 인스턴스의 기본 관리자 비밀번호를 admin에서 grandpoobah로 변경합니다.

imqusermgr update mybroker -u admin -p grandpoobah

브로커 인스턴스가 실행 중일 때 명령줄 도구 중 하나를 실행하여 이러한 변경 사항의 적용 여부를 빠르게 확인할 수 있습니다. 예를 들어, 다음 명령은 비밀번호를 묻습니다.

imqcmd list svc mybroker -u admin

새 비밀번호(grandpoobah)가 올바르게 작동해야 하고 이전 비밀번호는 실패해야 합니다.

비밀번호를 변경한 후에 관리 콘솔을 포함한 Message Queue 관리 도구를 사용하려면 새 비밀번호를 입력해야 합니다.

사용자 저장소에 LDAP 서버 사용

사용자 저장소에 LDAP 서버를 사용하려면 다음 작업을 수행합니다.

• 인스턴스 구성 파일 편집

• 관리자에 대한 액세스 제어 설정

인스턴스 구성 파일 편집

브로커가 디렉토리 서버를 사용하게 하려면 브로커 인스턴스 구성 파일 config.properties에서 특정 등록 정보의 값을 설정해야 합니다. 이 등록 정보를 사용하면 사용자가 브로커 인스턴스에 연결하거나 메시징 작업을 수행하려 할 때마다 브로커 인스턴스가 LDAP 서버로부터 사용자 및 그룹에 대한 정보를 쿼리할 수 있습니다.

인스턴스 구성 파일은 브로커 인스턴스 디렉토리 아래의 디렉토리에 있습니다. 경로 형식은 다음과 같습니다.

…/instances/instanceName

/props/config.properties

운영 체제별 인스턴스 디렉토리 위치에 대한 자세한 내용은 부록 A, 플랫폼별 Message Queue^TM 데이터 위치를 참조하십시오.

LDAP 서버를 사용하도록 구성 파일을 편집하는 방법

1. 다음 등록 정보를 설정하여 LDAP 사용자 저장소를 사용하고 있음을 지정합니다.

   imq.authentication.basic.user_repository=ldap

2. imq.authentication.type 등록 정보를 설정하여 클라이언트에서 브로커로 전달되는 비밀번호를 인코딩하는 데 base-64(basic)를 사용할지 또는 MD5(digest)를 사용할지 여부를 결정합니다. 사용자 저장소에 LDAP 디렉토리를 사용하는 경우에는 인증 유형을 basic으로 설정해야 합니다. 예를 들면 다음과 같습니다.

   imq.authentication.type=basic

3. LDAP 액세스를 제어하는 브로커 등록 정보도 설정해야 합니다. 이러한 등록 정보는 브로커의 인스턴스 구성 파일에 저장됩니다. 등록 정보는 보안 서비스에서 설명되고 보안 등록 정보에 요약되어 있습니다.

   Message Queue는 JNDI API를 사용하여 LDAP 디렉토리 서버와 통신합니다. 이러한 등록 정보에 사용되는 구문과 용어에 대한 자세한 내용은 JNDI 설명서를 참조하십시오. Message Queue는 Sun JNDI LDAP 공급자를 사용하며 단순 인증을 사용합니다.

   Message Queue는 LDAP 인증 페일오버를 지원하므로 인증을 시도할 LDAP 디렉토리 서버 목록을 지정할 수 있습니다(자세한 내용은 imq.user.repos.ldap.server 등록 정보 참조).

   LDAP 사용자 저장소 관련 등록 정보를 설정하는 방법은 브로커의 config.properties 파일을 참조하십시오.

4. 필요한 경우에는 액세스 제어 등록 정보 파일에서 사용자/그룹과 규칙을 편집해야 합니다. 액세스 제어 등록 정보 파일 사용에 대한 자세한 내용은 사용자 권한 부여: 액세스 제어 등록 정보 파일을 참조하십시오.

5. 연결 인증 및 그룹 검색 중 브로커가 SSL을 통해 LDAP 디렉토리 서버와 통신하도록 하려면 LDAP 서버에서 SSL을 활성화한 후 브로커 구성 파일에서 다음 등록 정보를 설정해야 합니다.

   • LDAP 서버가 SSL 통신에 사용하는 포트를 지정합니다. 예를 들면 다음과 같습니다.

     imq.user_repository.ldap.server=myhost:7878

   • 브로커 등록 정보 imq.user_repository.ldap.ssl.enabled를 true로 설정합니다.

     여러 LDAP 디렉토리 서버를 사용하는 경우 ldap://를 사용하여 각 디렉토리 서버를 추가로 지정합니다. 예를 들면 다음과 같습니다.

     imq.user_repository.ldap.server = myHost:7878 ldap:// otherHost:7878 …

     추가된 각 디렉토리 서버를 공백으로 구분합니다. 목록의 모든 디렉토리 서버는 기타 LDAP 관련 등록 정보에 대해 동일한 값을 사용해야 합니다.

관리자에 대한 액세스 제어 설정

관리자를 만들려면 액세스 제어 등록 정보 파일을 사용하여 ADMIN 연결을 생성할 수 있는 사용자와 그룹을 지정합니다. 이러한 사용자와 그룹을 LDAP 디렉토리에서 사전 정의해야 합니다.

ADMIN 연결을 만들 수 있는 모든 사용자나 그룹은 관리 명령을 실행할 수 있습니다.

관리자 설정 방법

1. 브로커 등록 정보 imq.accesscontrol.enabled를 true(기본값)로 설정하여 액세스 제어 파일을 사용 가능하게 합니다.

   imq.accesscontrol.enabled 등록 정보는 액세스 제어 파일을 사용 가능하게 합니다.

2. 액세스 제어 파일 accesscontrol.properties를 엽니다. 파일 위치는 부록 A, 플랫폼별 Message Queue^TM 데이터 위치에 나와 있습니다.

   파일에는 다음과 같은 항목이 포함되어 있습니다.

   service connection access control##################################connection.NORMAL.allow.user=*connection.ADMIN.allow.group=admin

   나열된 항목은 예입니다. admin 그룹은 파일 기반 사용자 저장소에 있지만 기본적으로 LDAP 디렉토리에는 없습니다. LDAP 디렉토리에 정의된 그룹의 이름을 Message Queue 관리자 권한을 부여할 그룹 이름으로 대체해야 합니다.

3. 사용자에게 Message Queue 관리자 권한을 부여하려면 다음과 같이 사용자 이름을 입력합니다.

   connection.ADMIN.allow.user= userName[[,userName2] …]

4. 그룹에 Message Queue 관리자 권한을 부여하려면 다음과 같이 그룹 이름을 입력합니다.

   connection.ADMIN.allow.group= groupName[[,groupName2] …]

사용자 권한 부여: 액세스 제어 등록 정보 파일

access control properties file(ACL 파일)에는 사용자와 사용자 그룹이 수행할 수 있는 작업을 지정하는 규칙이 포함되어 있습니다. ACL 파일을 편집하여 이런 작업을 특정 사용자 및 그룹으로 제한합니다. 브로커 인스턴스마다 다른 ACL 파일을 사용할 수 있습니다.

ACL 파일은 사용자 정보가 플랫 파일 사용자 저장소에 있는지 또는 LDAP 사용자 저장소에 있는지 여부와 상관 없이 모두 사용할 수 있습니다.브로커는 클라이언트 응용 프로그램이 다음 작업 중 하나를 수행할 때 ACL 파일을 확인합니다.

• 연결 만들기

• 생성자 만들기

• 사용자 만들기

• 대기열 찾아보기

브로커는 ACL 파일을 확인하여 작업 수행 권한을 요청을 생성한 사용자에게 부여할지 해당 사용자가 속하는 그룹에 부여할지를 결정합니다.

ACL 파일을 편집한 경우 브로커가 다음에 파일을 검사하여 권한 부여를 확인할 때 새로운 설정이 적용됩니다. 파일을 편집한 후 브로커를 다시 시작할 필요가 없습니다.

액세스 제어 등록 정보 파일 작성

ACL 파일은 인스턴스에 고유합니다. 브로커 인스턴스를 시작할 때마다 기본 파일 accesscontrol.properties가 인스턴스 디렉토리에 생성됩니다. 파일에 대한 경로 형식은 다음과 같습니다(부록 A, 플랫폼별 Message Queue^TM 데이터 위치 참조).

…/instances/brokerInstanceName/etc/accesscontrol.properties

ACL 파일은 Java 등록 정보 파일과 같은 형식으로 구성됩니다. 먼저 파일 버전을 정의하는 것으로 시작하여 다음 세 개 섹션에서 액세스 제어 규칙을 지정합니다.

• 연결 액세스 제어

• 물리적 대상 액세스 제어

• 물리적 대상 자동 생성 액세스 제어

version 등록 정보는 ACL 등록 정보 파일의 버전을 정의하며 이 항목은 변경할 수 없습니다.

version=JMQFileAccessControlModel/100

액세스 규칙의 기본 구문, 권한을 계산하는 방법 및 ACL 파일에서 액세스 제어를 지정하는 세 개의 섹션에 대한 설명이 아래에 나와 있습니다.

액세스 규칙 구문

ACL 등록 정보 파일에서 액세스 제어는 물리적 대상 및 연결 서비스와 같이 보호된 자원에 대해 특정 사용자 또는 그룹이 갖는 액세스 권한을 정의합니다. 액세스 제어는 규칙 또는 규칙 집합으로 나타내며 각 규칙은 Java 등록 정보로 표시됩니다.

이 규칙의 기본 구문은 다음과 같습니다.

resourceType.resourceVariant

.operation.access.
principalType=principals

표 7–3에서는 구문 규칙의 요소에 대해 설명합니다.

다음은 액세스 규칙의 몇 가지 예입니다.

• 다음 규칙은 모든 사용자가 q1이라는 이름의 대기열에 메시지를 보낼 수 있다는 것을 나타냅니다.

  queue.q1.produce.allow.user=*

• 다음 규칙은 모든 사용자가 모든 대기열에 메시지를 보낼 수 있다는 것을 나타냅니다.

  queue.*.produce.allow.user=*

ASCII가 아닌 사용자, 그룹 또는 대상 이름을 지정하려면 유니코드 제어(\\uXXXX) 표기를 사용해야 합니다. ACL 파일을 편집한 후 ASCII 인코딩이 아닌 이름으로 저장한 경우에는 Java native2ascii 도구를 사용해서 해당 파일을 ASCII로 변환할 수 있습니다. 자세한 내용은 다음을 참조하십시오.

http://java.sun.com/j2se/1.4/docs/guide/intl/faq.html

사용 권한 계산 방법

파일에 여러 액세스 규칙이 있는 경우 사용 권한은 다음과 같이 계산됩니다.

• 구체적인 액세스 규칙은 일반적인 액세스 규칙을 대체합니다. 다음 두 규칙을 적용하고 나면 모든 사용자가 모든 대기열에 전송할 수 있지만 Bob은 tq1에 전송할 수 없습니다.

  queue.*.produce.allow.user=*
  queue.tq1.produce.deny.user=Bob

• 명시된 principal로 지정한 액세스 권한은 * principal로 지정한 액세스 권한을 대체합니다. 다음 규칙은 tq1에서 메시지를 생성할 권한을 Bob에게는 허용하지 않지만 다른 모든 사람에게는 허용합니다.

  queue.tq1.produce.allow.user=*
  queue.tq1.produce.deny.user=Bob

• 사용자에 대한 * principal 규칙은 그룹에 대한 해당 * principal을 대체합니다. 예를 들어, 다음 두 규칙은 인증된 모든 사용자가 tq1에 메시지를 보낼 수 있도록 허용합니다.

  queue.tq1.produce.allow.user=*
  queue.tq1.produce.deny.group=*

• 사용자에게 부여된 액세스 권한은 사용자 그룹에 부여된 액세스 권한을 대체합니다. 다음 예에서 Bob은 User의 구성원이지만 tq1에 메시지를 생성할 수 없습니다. User의 다른 모든 구성원은 메시지를 생성할 수 있습니다.

  queue.tq1.produce.allow.group=User
  queue.tq1.produce.deny.user=Bob

• 액세스 규칙을 통해 명확하게 부여되지 않은 모든 액세스 권한은 거부됩니다. 예를 들어, ACL 파일에 액세스 규칙이 없으면 모든 사용자의 모든 작업이 거부됩니다.

• 같은 사용자 또는 그룹에 권한을 거부하고 허용하면 설정이 서로 상쇄됩니다. 예를 들어, 다음과 같은 두 규칙이 있으면 Bob은 q1을 찾아볼 수 없습니다.

  queue.q1.browse.allow.user=Bob
  queue.q1.browse.deny.user=Bob

  다음 두 규칙은 User 그룹이 q5에서 메시지를 사용하지 못하게 합니다.

  queue.q5.consume.allow.group=User
  queue.q5.consume.deny.group=User

• 왼쪽의 같은 규칙이 여러 개 있는 경우에는 마지막 항목만 적용됩니다.

연결 서비스에 대한 액세스 제어

ACL 등록 정보 파일의 연결 액세스 제어 섹션에는 브로커의 연결 서비스에 대한 액세스 제어 규칙이 있습니다. 연결 액세스 제어 규칙의 구문은 다음과 같습니다.

connection.resourceVariant.
access.principalType=
principals

resourceVariant에 정의할 수 있는 값은 NORMAL과 ADMIN 두 가지입니다. 이러한 사전 정의된 값은 사용자가 액세스 권한을 부여할 수 있는 유일한 연결 서비스 유형입니다.

기본 ACL 등록 정보 파일은 모든 사용자에게 NORMAL 연결 서비스에 대한 액세스 권한을 부여하고 admin 그룹에 속하는 사용자에게는 ADMIN 연결 서비스에 대한 액세스 권한을 부여합니다.

connection.NORMAL.allow.user=*
connection.ADMIN.allow.group=admin

파일 기반 사용자 저장소를 사용하는 경우 기본 그룹 admin이 사용자 관리자 유틸리티를 통해 만들어집니다. LDAP 사용자 저장소를 사용하는 경우 다음 중 하나를 수행하여 기본 ACL 등록 정보 파일을 사용할 수 있습니다.

• LDAP 디렉토리에서 admin 그룹을 정의합니다.

• ACL 등록 정보 파일의 이름 admin을 LDAP 디렉토리에 정의된 하나 이상의 그룹 이름으로 교체합니다.

연결 액세스 권한을 제한할 수 있습니다. 예를 들어, 다음 규칙에서는 NORMAL에 대한 Bob의 액세스를 거부하지만 다른 모든 사람은 허용합니다.

connection.NORMAL.deny.user=Bob
connection.NORMAL.allow.user=*

별표(*) 문자를 사용해서 인증된 모든 사용자 또는 그룹을 지정할 수 있습니다.

ACL 등록 정보 파일을 사용하여 ADMIN 연결에 대한 액세스 권한을 부여하는 방법은 파일 기반 사용자 저장소와 LDAP 사용자 저장소에서 다음과 같이 다릅니다.

• 파일 기반 사용자 저장소

  • 액세스 제어가 비활성화된 경우 admin 그룹의 사용자가 ADMIN 연결 권한을 갖습니다.

  • 액세스 제어가 활성화된 경우 ACL 파일을 편집합니다. ADMIN 연결 서비스에 대한 액세스 권한을 사용자 또는 그룹에 명시적으로 부여합니다.

• LDAP 사용자 저장소. LDAP 사용자 저장소를 사용하는 경우 다음을 모두 수행합니다.

  • 액세스 제어를 활성화합니다.

  • ACL 파일을 편집하고 ADMIN 연결을 만들 수 있는 사용자 또는 그룹의 이름을 제공합니다. LDAP 디렉토리 서버에 정의된 사용자 또는 그룹을 지정합니다.

물리적 대상에 대한 액세스 제어

액세스 제어 등록 정보 파일의 대상 액세스 제어 섹션에는 물리적 대상 기반 액세스 제어 규칙이 있습니다. 이 규칙은 누가(사용자/그룹) 어디에서(물리적 대상) 무엇을(작업) 할 수 있는지 결정합니다. 이 규칙으로 규제되는 액세스 유형에는 대기열로 메시지 전송, 주제에 메시지 게시, 대기열에서 메시지 수신, 주제에 가입, 대기열에서 메시지 찾아보기가 포함됩니다.

기본적으로 모든 사용자 또는 그룹은 모든 물리적 대상에 대해 모든 유형의 액세스 권한을 갖습니다. 특정 대상 액세스 규칙을 추가하거나 기본 규칙을 편집할 수 있습니다. 이 절의 나머지 부분에서는 규칙을 직접 작성하기 위해 알아야 하는 물리적 대상 액세스 규칙의 구문에 대해 설명합니다.

대상 규칙의 구문은 다음과 같습니다.

resourceType.resourceVariant.operation.access.principalType=principals

표 7–4에서는 이러한 요소에 대해 설명합니다.

하나 이상의 사용자 또는 하나 이상의 그룹에 액세스를 허용할 수 있습니다.

다음 예에서는 다양한 종류의 물리적 대상 액세스 제어 규칙을 보여줍니다.

• 모든 사용자가 모든 대기열 대상에 메시지를 보낼 수 있도록 허용합니다.

  queue.*.produce.allow.user=*

• user 그룹의 모든 구성원에 대해 Admissions 주제에 가입하지 못하게 합니다.

  topic.Admissions.consume.deny.group=user

자동 생성 물리적 대상에 대한 액세스 제어

ACL 등록 정보 파일의 마지막 섹션에는 브로커에서 물리적 대상을 자동 생성하는 사용자 또는 그룹을 지정하는 액세스 규칙이 있습니다.

사용자가 아직 존재하지 않는 물리적 대상에서 생성자 또는 사용자를 만든 경우 브로커의 자동 생성 등록 정보가 활성화되어 있으면 브로커가 해당 대상을 만듭니다.

기본적으로 모든 사용자 또는 그룹은 브로커가 물리적 대상을 자동 생성하도록 할 수 있습니다. 이 권한은 다음과 같은 규칙으로 지정합니다.

queue.create.allow.user=*
topic.create.allow.user=*

ACL 파일을 편집하여 이 유형의 액세스를 제한할 수도 있습니다.

물리적 대상 자동 생성 액세스 규칙의 일반 구문은 다음과 같습니다.

resourceType.create.access.principalType=principals

여기서 resourceType은 queue 또는 topic입니다.

예를 들어, 다음 규칙은 브로커가 Snoopy를 제외한 모든 사람에 대해 주제 대상을 자동 생성하도록 허용합니다.

topic.create.allow.user=*
topic.create.deny.user=Snoopy

물리적 대상 자동 생성 규칙의 효과와 물리적 대상 액세스 규칙의 효과 사이에 모순이 없도록 해야 합니다. 예를 들어, 1) 어떤 사용자도 대상으로 메시지를 보낼 수 없도록 대상 액세스 규칙을 변경했는데 2) 대상의 자동 생성은 허용했다면, 브로커는 물리적 대상이 없는 경우 물리적 대상을 만들기는 하지만 메시지를 그 물리적 대상으로 전달하지는 않습니다.

메시지 암호화

이 절에서는 클라이언트와 브로커 간에 암호화된 메시지를 보내는 SSL(Secure Socket Layer) 표준을 기반으로 연결 서비스를 설정하는 방법에 대해 설명합니다. Message Queue는 다음과 같은 SSL 기반 연결 서비스를 지원합니다.

• ssljms 서비스는 TCP/IP 전송 프로토콜을 사용하여 클라이언트와 브로커 간에 암호화된 보안 메시지를 전달합니다.

• ssladmin 서비스는 TCP/IP 전송 프로토콜을 사용하여 Message Queue 명령 유틸리티(imqcmd)와 브로커 간에 암호화된 보안 연결을 생성합니다. 관리 콘솔(imqadmin)에서는 암호화된 연결이 지원되지 않습니다.

• cluster 서비스는 TCP/IP 전송 프로토콜을 사용하여 클러스터의 브로커 간에 암호화된 보안 통신을 제공합니다.

• httpsjms 서비스는 HTTP 전송 프로토콜과 HTTPS 터널 서블릿을 사용하여 클라이언트와 브로커 간에 암호화된 보안 메시지를 전달합니다.

이 절의 나머지 부분에서는 ssljms, ssladmin 및 cluster 연결 서비스를 사용하여 TCP/IP를 통해 보안 연결을 설정하는 방법에 대해 설명합니다. httpsjms 서비스를 사용하여 HTTP를 통해 보안 연결을 설정하는 방법은 부록 C, HTTP/HTTPS 지원을 참조하십시오.

자체 서명된 인증서 사용

TCP/IP를 통해 SSL 기반 연결 서비스를 사용하려면 키 도구 유틸리티(imqkeytool)를 사용하여 공개/개인 키 쌍을 생성합니다. 이 유틸리티는 브로커에 대해 연결을 요청하는 모든 클라이언트로 전달되는 자체 서명된 인증서에 공용 키를 포함합니다. 그러면 클라이언트에서 이 인증서를 사용하여 암호화된 연결을 설정합니다. 이 절에서는 그런 자체 서명된 인증서를 사용하여 SSL 기반 서비스를 설정하는 방법에 대해 설명합니다.

인증 수준을 강화하려면 인증 기관이 확인한 서명된 인증서를 사용할 수 있습니다. 서명된 인증서를 사용하려면 자체 서명된 인증서에 필요한 단계 이외에 몇 가지 추가 단계를 수행해야 합니다. 이 절에서 설명하는 단계를 수행한 다음 서명된 인증서 사용 에 설명된 추가 단계를 수행해야 합니다.

자체 서명된 인증서를 사용한 Message Queue의 SSL 지원은 클라이언트가 알려지고 신뢰할 수 있는 서버와 통신한다는 가정 하에 전송 데이터를 보호하기 위한 것입니다. 다음 절차에서는 자체 서명된 인증서를 사용하도록 SSL 기반 연결 서비스를 설정하는 데 필요한 단계를 보여 줍니다. 다음에 오는 하위 절에서는 각 단계에 대해 자세히 설명합니다.

자체 서명된 인증서를 사용하여 SSL 기반 연결 서비스를 설정하는 방법

1. 자체 서명된 인증서를 생성합니다.

2. 브로커에서 ssljms, ssladmin 또는 cluster 연결 서비스를 활성화합니다.

3. 브로커를 시작합니다.

4. 클라이언트를 구성하고 실행합니다.

   이 단계는 ssljms 연결 서비스에만 적용되고 ssladmin 또는 cluster에는 적용되지 않습니다.

자체 서명된 인증서 생성

키 도구 유틸리티(imqkeytool)를 실행하여 브로커에 대한 자체 서명된 인증서를 생성합니다. (UNIX® 시스템에서 키 저장소를 만들 권한을 가지려면 유틸리티를 수퍼유저(root)로 실행해야 할 수도 있음). ssljms, ssladmin 또는 cluster 연결 서비스에 동일한 인증서를 사용할 수 있습니다.

명령 프롬프트에서 다음을 입력합니다.

imqkeytool -broker

키 도구 유틸리티가 키 저장소 비밀번호를 묻습니다.

   Generating keystore for the broker ...
   Enter keystore password:

그런 다음 이 인증서가 속하는 브로커를 식별하는 정보를 묻습니다. 입력한 정보를 기반으로 X.500 고유 이름이 생성됩니다. 표 7–5에서는 프롬프트와 각 프롬프트에 대해 제공할 값을 보여 줍니다. 값은 대소문자가 구분되고 공백을 포함할 수 있습니다.

정보 입력이 끝나면 키 도구 유틸리티에서 확인을 위해 해당 정보를 표시합니다. 예를 들면 다음과 같습니다.

   Is CN=mqserver.sun.com, OU=purchasing, ON=My Company, Inc.,
   L=San Francisco, ST=California, C=US correct?

현재 값을 적용하고 계속하려면 yes를 입력하고, 값을 다시 입력하려면 기본값을 적용하거나 no를 입력합니다. 확인이 끝난 후 키 쌍이 생성되는 동안 유틸리티가 일시 중지됩니다.

그런 다음 키 쌍을 잠글 비밀번호(키 비밀번호)를 묻습니다. 키 비밀번호 및 키 저장소 비밀번호와 동일한 비밀번호를 사용하려면 이 프롬프트에서 Return 키를 누릅니다.

지정한 비밀번호를 기억해 두십시오. 브로커를 시작할 때 이 비밀번호를 입력해야 브로커가 키 저장소를 열 수 있습니다. 비밀번호 파일에 키 저장소 비밀번호를 저장할 수 있습니다( 비밀번호 파일 참조).

키 도구 유틸리티는 자체 서명된 인증서를 생성한 다음 Message Queue의 키 저장소에 넣습니다. 부록 A, 플랫폼별 Message Queue^TM 데이터 위치에 표시된 것처럼 키 저장소는 운영 체제에 따라 다른 디렉토리에 있습니다.

SSL 기반 연결 서비스의 Message Queue 키 저장소에 대해 구성 가능한 등록 정보는 다음과 같습니다.

• imq.keystore.file.dirpath: 키 저장소 파일을 포함하는 디렉토리 경로입니다. 기본값은 부록 A, 플랫폼별 Message Queue^TM 데이터 위치를 참조하십시오.

• imq.keystore.file.name: 키 저장소 파일의 이름입니다.

• imq.keystore.password: 키 저장소 비밀번호입니다.

특정 문제를 해결하기 위해 키 쌍을 재생성해야 하는 경우도 있습니다. 예를 들어, 키 저장소 비밀번호를 잊은 경우나 브로커를 시작할 때 SSL 기반 서비스가 초기화되지 않고 예외가 발생되는 경우가 있습니다.

java.security.UnrecoverableKeyException:Cannot recover key

이 예외는 자체 서명된 인증서를 생성할 때의 키 저장소 비밀번호가 지정한 키 비밀번호와 다른 경우 발생할 수 있습니다.

키 쌍을 다시 생성하는 방법

1. 부록 A, 플랫폼별 Message Queue^TM 데이터 위치에 나와 있는 위치에 있는 브로커의 키 저장소를 제거합니다.

2. 위에서 설명한 것처럼 imqkeytool을 다시 실행하여 새 키 쌍을 생성합니다.

SSL 기반 연결 서비스 활성화

브로커에서 SSL 기반 연결 서비스를 활성화하려면 ssljms 또는 ssladmin을 imq.service.activelist 등록 정보에 추가해야 합니다.

브로커에서 SSL 기반 서비스를 활성화하는 방법

1. 브로커의 인스턴스 구성 파일을 엽니다.

   인스턴스 구성 파일은 구성 파일이 연결되어 있는 브로커 인스턴스의 이름(instanceName)으로 식별되는 디렉토리에 있습니다(부록 A, 플랫폼별 Message Queue^TM 데이터 위치 참조).

      .../instances/instanceName/props/config.properties
   

2. imq.service.activelist 등록 정보에 항목을 추가하고(항목이 아직 없는 경우) 목록에 원하는 SSL 기반 서비스를 포함시킵니다.

   기본적으로 이 등록 정보에는jms 및 admin 연결 서비스가 포함됩니다. 활성화할 SSL 기반 서비스(ssljms, ssladmin 또는 둘 다)를 추가합니다.

   imq.service.activelist=jms,admin,ssljms,ssladmin
   

   ---

   주 –

   SSL 기반 cluster 연결 서비스는 imq.cluster.transport 등록 정보를 imq.service.activelist 등록 정보 대신 사용하여 활성화합니다. 자세한 내용은 브로커 연결을 참조하십시오.

   ---

3. 인스턴스 구성 파일을 저장하고 닫습니다.

브로커 시작

브로커를 시작하고 키 저장소 비밀번호를 제공합니다. 다음과 같은 두 가지 방법으로 비밀번호를 제공할 수 있습니다.

• 브로커를 시작할 때 비밀번호를 묻는 프롬프트가 표시되게 합니다.

     imqbrokerd
     Please enter Keystore password:

• 비밀번호 파일에서 설명한 대로 비밀번호 파일에 비밀번호를 입력합니다. 그런 다음 imq.passfile.enabled 등록 정보를 true로 설정하고 다음 중 하나를 수행합니다.

  • 비밀번호 파일의 위치를 imqbrokerd 명령에 전달합니다.

    imqbrokerd -passfile /passfileDirectory/passfileName
    

  • -passfile 옵션 없이 브로커를 시작하되, 다음의 두 브로커 구성 등록 정보를 사용하여 비밀번호 파일의 위치를 지정합니다.

    imq.passfile.dirpath=/passfileDirectory
    
    imq.passfile.name=passfileName
    

SSL을 사용하는 브로커나 클라이언트를 시작할 때 몇 초간 CPU 사용량이 갑자기 증가하는 경우가 있을 수 있습니다. 이것은 Message Queue에서 난수를 생성하는 데 사용하는 JSSE(Java Secure Socket Extension) 메서드 java.security.SecureRandom이 초기 난수 시드를 생성하는 데 많은 시간이 소요되기 때문입니다. 시드를 만들고 나면 CPU 사용 수준이 정상으로 돌아갑니다.

SSL 기반 클라이언트 구성 및 실행

SSL 기반 연결 서비스를 사용하도록 클라이언트를 구성하는 절차는 ssljms 연결 서비스를 사용하는 응용 프로그램 클라이언트인지 ssladmin 연결 서비스를 사용하는 Message Queue 관리 클라이언트(예: imqcmd)인지 여부에 따라 다릅니다.

응용 프로그램 클라이언트

응용 프로그램 클라이언트의 경우 다음과 같은 .jar 파일이 CLASSPATH 변수에 지정되어 있어야 합니다.

imq.jar




jms.jar

Java 2 Software Development Kit(J2SDK) 1.4 이전 버전을 사용할 경우 다음과 같은 JSSE(Java Secure Socket Extension) 및 JNDI(Java Naming and Directory Interface) .jar 파일을 포함시켜야 합니다.

jsse.jar




jnet.jar




jcert.jar




jndi.jar

J2SDK 1.4 이상에서는 JSSE 및 JNDI를 기본적으로 지원하므로 이러한 파일을 포함시킬 필요가 없습니다.

CLASSPATH 파일을 제대로 지정한 경우 다음과 같은 명령을 입력하여 클라이언트를 시작하고 브로커의 ssljms 연결 서비스에 연결할 수 있습니다.

java -DimqConnectionType=TLS clientAppName

그러면 연결에서 SSL 기반 연결 서비스를 사용하게 됩니다.

관리 클라이언트

관리 클라이언트의 경우 imqcmd 명령을 호출할 때 -secure 옵션을 포함시켜 보안 연결을 설정할 수 있습니다. 예를 들면 다음과 같습니다.

imqcmd list svc -b hostName:portNumber -u adminName -secure

여기서 adminName은 Message Queue 사용자 저장소에 유효한 항목입니다. 이 명령은 비밀번호를 묻는 프롬프트를 표시합니다(플랫 파일 저장소를 사용하는 경우 기본 관리자 비밀번호 변경 참조).

연결 서비스를 나열하는 것은 ssladmin 서비스가 실행 중이며 다음 출력과 같이 보안 관리 연결을 성공적으로 설정할 수 있다는 것을 확인하는 방법입니다.

Listing all the services on the broker specified by:

Host                 Primary Port
localhost            7676

Service Name     Port Number       Service State
admin            33984 (dynamic)   RUNNING
httpjms          -                 UNKNOWN
httpsjms         -                 UNKNOWN
jms              33983 (dynamic)   RUNNING
ssladmin         35988 (dynamic)   RUNNING
ssljms           dynamic           UNKNOWN

Successfully listed services.

서명된 인증서 사용

서명된 인증서는 자체 서명된 인증서보다 더 높은 수준의 서버 인증을 제공합니다. 서명된 인증서는 클라이언트와 브로커 간에만 구현 가능하고 동일 클러스터 내의 브로커 간에는 구현할 수 없습니다. 그럴 경우 위에서 설명한 자체 서명된 인증서 구성 단계 이외에 다음과 같은 추가 단계를 수행해야 합니다. 이러한 단계에 대해서는 다음에 나오는 하위 절에 자세히 설명되어 있습니다.

서명된 인증서를 사용하는 방법

1. 키 저장소에 인증서를 설치합니다.

2. 브로커에 SSL 기반 연결을 설정할 때 서명된 인증서를 요구하도록 Message Queue 클라이언트를 구성합니다.

서명된 인증서 가져오기 및 설치

다음 절차에서는 서명된 인증서를 가져와서 설치하는 방법에 대해 설명합니다.

서명된 인증서를 가져오는 방법

1. J2SE keytool 명령을 사용하여 이전 절에서 생성한 자체 서명된 인증서에 대한 CSR(Certificate Signing Request)을 생성합니다.

   keytool 명령에 대한 자세한 내용은 을 참조하십시오.

   http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html

   예를 들면 다음과 같습니다.

   keytool -certreq -keyalg RSA -alias imq -file certreq.csr -keystore /etc/imq/keystore -storepass myStorePassword

   이 명령은 지정된 파일(이 예의 경우 certreq.csr)에서 인증서를 캡슐화하는 CSR을 생성합니다.

2. CSR을 사용하여 서명된 인증서를 생성하거나 요청합니다.

   이 작업은 다음 중 한 가지 방법으로 수행할 수 있습니다.

   • Thawte 또는 Verisign과 같이 공신력 있는 인증 기관(CA)에서 서명한 인증서를 가져옵니다. 이 작업을 수행하는 방법에 대한 자세한 내용은 CA의 설명서를 참조하십시오.

   • SSL 서명 소프트웨어 패키지를 사용하여 인증서에 직접 서명합니다.

     결과적으로 만들어지는 서명된 인증서는 ASCII 문자 시퀀스입니다. CA로부터 서명된 인증서를 받을 때 해당 인증서는 전자 메일 첨부 파일이나 메시지 텍스트로 전달될 수 있습니다.

3. 서명된 인증서를 파일에 저장합니다.

   아래 지침에서는 broker.cer이라는 이름 예를 사용하여 브로커 인증서를 나타냅니다.

서명된 인증서 설치 방법

1. J2SE가 기본적으로 인증 기관을 지원하는지 여부를 확인합니다.

   다음 명령은 시스템 키 저장소에 있는 루트 CA를 나열합니다.

   keytool -v -list -keystore $JAVA_HOME/lib/security/cacerts
   

   해당 CA가 목록에 있는 경우 다음 단계를 건너뜁니다.

2. 인증 기관이 J2SE에서 지원되지 않는 경우 CA의 루트 인증서를 Message Queue 키 저장소로 가져옵니다.

   예를 들면 다음과 같습니다.

   keytool -import -alias ca -file ca.cer -noprompt -trustcacerts
           -keystore /etc/imq/keystore -storepass myStorePassword
   

   여기서 ca.cer은 CA에서 가져온 루트 인증서가 들어 있는 파일입니다.

   CA 테스트 인증서를 사용하는 경우 테스트 CA 루트 인증서를 가져와야 할 수 있습니다. CA에는 복사본을 가져오는 방법에 대한 지침이 있어야 합니다.

3. 서명된 인증서를 키 저장소로 가져와서 자체 서명된 원본 인증서를 대체합니다.

   예를 들면 다음과 같습니다.

   keytool -import -alias imq -file broker.cer -noprompt -trustcacerts
           -keystore /etc/imq/keystore -storepass myStorePassword
   

   여기서 broker.cer은 CA로부터 받은 서명된 인증서가 들어 있는 파일입니다.

   Message Queue 키 저장소에는 이제 SSL 연결에 사용할 서명된 인증서가 포함되어 있습니다.

서명된 인증서를 요구하도록 Message Queue 클라이언트 런타임 구성

서명된 인증서를 요구하도록 Message Queue 클라이언트 런타임을 구성하고 인증서에 서명한 인증 기관을 신뢰하는지를 확인해야 합니다.

서명된 인증서를 요구하도록 클라이언트 런타임을 구성하는 방법

1. 연결 팩토리의 imqSSLIsHostTrusted 속성을 false로 설정합니다.

   기본적으로 클라이언트가 브로커 연결을 설정하는 데 사용할 연결 팩토리 객체의 imqSSLIsHostTrusted 속성은 true로 설정되어 있습니다. 즉, 클라이언트 런타임에서 제공된 인증서를 수용합니다. 클라이언트 런타임이 제공되는 모든 인증서를 검증하도록 이 값을 false로 변경해야 합니다. 인증서 서명자가 클라이언트의 트러스트 저장소에 없는 경우 검증이 실패합니다.

2. 서명 기관이 클라이언트의 트러스트 저장소에 등록되어 있는지 여부를 확인합니다.

   클라이언트가 인증 기관에서 서명한 인증서를 수용하는지 여부를 테스트하려면 SSL 기반 클라이언트 구성 및 실행에서 설명한 것처럼 SSL 연결 설정을 시도합니다. CA가 클라이언트의 트러스트 저장소에 있으면 성공적으로 연결되고 다음 단계를 건너뛸 수 있습니다. 연결이 실패하고 인증서 검증 오류가 발생하면 다음 단계로 이동합니다.

3. 서명 CA의 루트 인증서를 클라이언트의 트러스트 저장소에 설치합니다.

   클라이언트는 기본적으로 키 저장소 파일 cacerts 및 jssecacerts를 검색하므로 인증서를 이러한 파일에 설치할 때 추가 구성이 필요하지 않습니다. 다음 예에서는 Verisign 인증 기관의 테스트 루트 인증서를 testrootca.cer 파일에서 기본 시스템 인증서 파일 cacerts에 설치합니다.이 예제에서는 J2SE가 $JAVA_HOME/usr/j2se 디렉토리에 설치된다고 가정합니다.

   keytool -import -keystore /usr/j2se/jre/lib/security/cacerts
           -alias VerisignTestCA -file testrootca.cer -noprompt
           -trustcacerts -storepass myStorePassword
   

   대체(권장) 옵션으로 루트 인증서를 대체 시스템 인증서 파일 jssecacerts에 설치할 수 있습니다.

   keytool -import -keystore /usr/j2se/jre/lib/security/jssecacerts
           -alias VerisignTestCA -file testrootca.cer -noprompt
           -trustcacerts -storepass myStorePassword
   

   세 번째 방법으로 루트 인증서를 다른 키 저장소 파일에 설치하고 해당 저장소 파일을 트러스트 저장소로 사용하도록 클라이언트를 구성할 수 있습니다. 다음 예에서는 /home/smith/.keystore 파일에 설치합니다.

   keytool -import -keystore /home/smith/.keystore
           -alias VerisignTestCA -file testrootca.cer -noprompt
           -trustcacerts -storepass myStorePassword
   

   클라이언트는 기본적으로 이 키 저장소를 검색하지 않기 때문에 클라이언트에서 트러스트 저장소로 사용하도록 해당 위치를 명시적으로 지정해야 합니다. 이 작업은 클라이언트가 다음을 실행 중일 때 Java 시스템 등록 정보 javax.net.ssl.trustStore를 설정하여 수행합니다.

   javax.net.ssl.trustStore=/home/smith/.keystore
   

비밀번호 파일

여러 가지 명령 유형에 비밀번호가 필요합니다. 표 7–6에서 첫 번째 열에는 비밀번호가 필요한 명령이 나열되고 두 번째 열에는 비밀번호가 필요한 이유가 나열됩니다.

비밀번호 파일에 이러한 비밀번호를 지정하고 -passfile 옵션을 사용하여 파일의 이름을 지정할 수 있습니다. -passfile 옵션의 형식은 다음과 같습니다.

imqbrokerd -passfile myPassfile

이전 릴리스에서는 -p, -password, -dbpassword 및 -ldappassword 옵션을 사용하여 명령줄에서 비밀번호를 지정할 수 있었습니다. 이러한 옵션은 더 이상 사용되지 않으며 향후 릴리스에서는 제거됩니다. 현재 릴리스에서는 이러한 옵션 중 하나에 대한 명령줄의 값이 비밀번호 파일의 관련 값보다 우선합니다.

보안 문제

모니터를 다른 사람이 보고 있지 않다면 프롬프트에 응답하여 비밀번호를 대화식으로 지정하는 것이 가장 안전한 비밀번호 지정 방법입니다. 명령줄에서 비밀번호 파일을 지정할 수도 있습니다. 명령을 비대화식으로 사용할 경우 비밀번호 파일을 사용해야 합니다.

비밀번호 파일은 암호화되지 않기 때문에 사용 권한을 설정하여 인증되지 않은 액세스로부터 보호해야 합니다. 브로커를 시작하는 사용자가 파일을 볼 수 있지만 읽기 액세스만 허용되도록 사용 권한을 설정합니다.

비밀번호 파일 내용

비밀번호 파일은 일련의 등록 정보와 값이 들어 있는 간단한 텍스트 파일입니다. 각 값은 명령에 사용되는 비밀번호입니다.

비밀번호 파일에는표 7–7에 표시된 비밀번호를 포함할 수 있습니다.

imq.keystore.password

imq.persist.jdbc.password

imqbrokerd
imdbmgr

imq.user_repository.ldap.password

imqbrokerd

샘플 비밀번호 파일은 Message Queue 제품의 일부입니다. 샘플 파일의 위치는 부록 A, 플랫폼별 Message Queue^TM 데이터 위치를 참조하십시오.

방화벽을 통해 연결

방화벽을 사용하여 클라이언트 응용 프로그램을 브로커와 분리하면 연결 설정을 위해 특별한 조치가 필요합니다. 한 가지 방법으로 httpjms 또는 httpsjms 연결 서비스를 사용하여 방화벽을 통해 "터널"을 생성할 수 있습니다. 자세한 내용은 부록 C, HTTP/HTTPS 지원을 참조하십시오. HTTP 연결은 다른 연결 서비스보다 더 느립니다. 그러나 그 보다 빠른 방법은 Message Queue 포트 매퍼를 우외하고 원하는 연결 서비스에 정적 포트 주소를 명시적으로 할당한 다음 방화벽에서 해당 포트를 여는 것입니다. 이 방법을 사용하면 jms 또는 ssljms 연결 서비스(또는 admin 또는 ssladmin)를 사용하여 방화벽을 통해 연결할 수 있습니다.

방화벽을 통해 브로커 연결을 활성화하는 방법

1. 사용할 연결 서비스에 정적 포트 주소를 할당합니다.

   포트 매퍼를 우회하고 연결 서비스에 정적 포트 번호를 직접 할당하려면 브로커 구성 등록 정보 imq.serviceName. protocolType.port를 설정합니다. 여기서 serviceName은 연결 서비스의 이름이고 protocolType은 해당 프로토콜 유형입니다(표 7–8 참조). 브로커 구성 등록 정보와 마찬가지로 브로커를 시작할 때 명령줄에서 또는 브로커의 인스턴스 구성 파일에서 이 등록 정보를 지정할 수 있습니다. 예를 들어, 포트 번호 10234를 jms 연결 서비스에 할당하려면

      imq.jms.tcp.port=10234
   

   행을 구성 파일에 포함시키거나 다음 명령을 사용하여 브로커를 시작합니다.

      
   imqbrokerd  -name myBroker  -Dimq.jms.tcp.port=10234
   

2. 연결 서비스에 할당된 포트 번호에 연결할 수 있도록 방화벽을 구성합니다.

   또한 방화벽을 통해 Message Queue의 포트 매퍼 포트(포트 매퍼를 다른 포트에 다시 할당하지 않은 경우 일반적으로 7676)에 연결할 수 있어야 합니다. 위 예에서 포트 10234 및 7676에 대해 방화벽을 열어야 합니다.

감사 기록

Message Queue는 엔터프라이즈판에서만 감사 기록을 지원합니다. 감사 로깅이 활성화되면 Message Queue는 다음과 같은 이벤트 유형에 대한 레코드를 생성합니다.

• 브로커 인스턴스 시작, 종료, 다시 시작 및 제거

• 사용자 인증 및 권한 부여

• 영구 저장소 재설정

• 물리적 대상 생성, 제거 및 완전 삭제

• 관리상 영구 가입자 완전 삭제

Message Queue 브로커 로그 파일에 감사 레코드를 기록하려면 imq.audit.enabled 브로커 등록 정보를 true로 설정합니다. 로그의 모든 감사 레코드에는 AUDIT 키워드가 있습니다.

8장 관리 대상 객체 관리

관리 대상 객체는 공급자별 구성 및 이름 지정 정보를 캡슐화하여 하나의 JMS 공급자에서 다른 공급자로 이식할 수 있는 클라이언트 응용 프로그램을 개발할 수 있도록 합니다. Message Queue^TM 관리자는 일반적으로 클라이언트 응용 프로그램이 메시지 송/수신을 위해 브로커에 연결하는 데 사용할 관리 대상 객체를 만듭니다.

이 장에서는 객체 관리자 유틸리티(imqobjmgr)를 사용하여 생성 및 관리 대상 객체를 관리하는 방법에 대해 설명합니다. 이 장은 다음 내용으로 구성되어 있습니다.

• 객체 저장소

• 관리 객체 속성

• 객체 관리자 유틸리티 사용

• 관리 객체 추가

• 관리 객체 나열

• 관리 객체 정보 보기

• 관리 객체 속성 수정

객체 저장소

관리 대상 객체는 클라이언트 응용 프로그램에서 JNDI(Java Naming and Directory Interface)를 통해 액세스할 수 있도록 미리 만들어진 객체 저장소에 있습니다. 사용할 수 있는 객체 저장소에는 표준 LDAP(Lightweight Directory Access Protocol) 디렉토리 서버와 로컬 파일 시스템의 디렉토리의 두 가지 유형이 있습니다.

LDAP 서버 객체 저장소

LDAP 서버는 작업 메시징 시스템에 권장되는 객체 저장소입니다. LDAP 서버는 분산 시스템에서 사용할 수 있도록 디자인되었으며 작업 환경에서 유용한 보안 기능을 제공합니다.

LDAP 구현은 여러 공급업체에서 제공합니다. Message Queue 관리 도구를 사용하여 LDAP 서버의 객체 저장소를 관리하려면 먼저 Java 객체를 저장할 서버를 구성한 다음 JNDI 조회를 수행해야 합니다. 자세한 내용은 LDAP 구현과 함께 제공된 설명서를 참조하십시오.

LDAP 서버를 객체 저장소로 사용하려면 표 8–1에 표시된 속성을 지정해야 합니다. 이 속성들은 다음 범주로 구분됩니다.

• 초기 컨텍스트. java.naming.factory.initial 속성은 서버에서 JNDI 조회를 위한 초기 컨텍스트를 지정합니다. 이 속성 값은 지정된 LDAP 객체 저장소에 대해 고정되어 있습니다.

• 위치.java.naming.provider.url 속성은 LDAP 서버의 URL과 디렉토리 경로를 지정합니다. 지정한 디렉토리 경로가 있는지 확인해야 합니다.

• 보안.java.naming.security.principal , java.naming.security.credentials 및 java.naming.security.authentication 속성은 객체 저장소에 액세스를 시도하는 호출자의 인증을 관리합니다. 이러한 속성의 정확한 형식 및 값은 LDAP 서비스 공급자에 따라 다릅니다. 보안 정보가 모든 작업에 필요한지 또는 저장된 데이터를 변경하는 작업에만 필요한지 여부를 결정하거나 자세한 내용을 보려면 해당 LDAP 구현에 제공된 설명서를 참조하십시오.

파일 시스템 객체 저장소

Message Queue에서는 관리 대상 객체에 대한 객체 저장소로 로컬 파일 시스템의 디렉토리 사용을 지원합니다. 이 방법은 작업 시스템에는 바람직하지 않지만, 개발 환경에서는 사용하기 쉬운 장점이 있습니다. 그러나, 여러 컴퓨터 노드에 배포된 클라이언트의 중앙 집중식 객체 저장소로 사용할 디렉토리의 경우에는 해당 모든 클라이언트가 디렉토리에 액세스할 수 있어야 합니다. 또한 해당 디렉토리에 액세스할 수 있는 모든 사용자는 Message Queue 관리 도구를 사용하여 관리 대상 객체를 만들고 관리할 수 있습니다.

파일 시스템 디렉토리를 객체 저장소로 사용하려면 표 8–2에 표시된 속성을 지정해야 합니다. LDAP 객체 저장소의 경우 이러한 속성은 위에서 설명한 것과 동일한 일반적인 의미를 지닙니다. 특히 java.naming.provider.url 속성은 객체 저장소를 포함하는 디렉토리의 디렉토리 경로를 지정합니다. 해당 디렉토리가 존재해야 하며 Message Queue 관리 도구 사용자와 이 저장소에 액세스할 클라이언트 응용 프로그램 사용자에게 적절한 액세스 권한이 있어야 합니다.

java.naming.factory.initial

java.naming.provider.url

관리 객체 속성

Message Queue 관리 대상 객체에는기본적으로 다음과 같은 두 가지 종류가 있습니다.

• 연결 팩토리는 클라이언트 응용 프로그램에서 브로커에 대한 연결을 만들 때 사용됩니다.

• 대상은 클라이언트 응용 프로그램이 메시지를 교환(전송/검색)할 수 있는 브로커 상의 위치를 나타냅니다.

SOAP 메시징에서는 특수한 SOAP 종점 관리 대상 객체를 사용합니다. 자세한 내용은 Java 클라이언트용 Message Queue 개발 안내서를 참조하십시오.

각 관리 대상 객체 유형에는 객체의 등록 정보와 동작을 결정하는 특정 속성이 있습니다. 이 절에서는 객체 관리자 명령줄 유틸리티(imqobjmgr)를 사용하여 이러한 속성을 설정하는 방법에 대해 설명합니다. 또한 관리 객체 작업에 설명된 대로 GUI 관리 콘솔을 사용하여 설정할 수도 있습니다.

연결 팩토리 속성

클라이언트 응용 프로그램에서는 연결 팩토리 관리 대상 객체를 사용하여 메시지를 브로커와 교환하는 데 사용할 연결을 만듭니다. 연결 팩토리의 속성은 생성되는 모든 연결의 등록 정보를 정의합니다. 연결이 만들어지고 나면 등록 정보를 변경할 수 없습니다. 따라서 연결 등록 정보를 구성하는 유일한 방법은 연결을 만드는 데 사용되는 연결 팩토리의 속성을 설정하는 것입니다.

Message Queue는 두 종류의 연결 팩토리 객체를 정의합니다.

• ConnectionFactory 객체는 일반 메시징과 비분산 트랜잭션을 지원합니다.

• XAConnectionFactory 객체는 분산 트랜잭션을 지원합니다.

두 종류 모두 자원, 성능 및 메시지 처리량을 최적화하는 데 사용할 수 있는 동일한 구성 속성을 공유합니다. 이러한 속성은 16 장, 관리 객체 속성 참조에 나열되어 있으며 다음 절에서 설명합니다.

• 연결 처리

• 클라이언트 아이디

• 안정성 및 흐름 제어

• 대기열 브라우저 및 서버 세션

• 표준 메시지 등록 정보

• 메시지 헤더 대체

연결 처리

연결 처리 속성은 연결할 브로커 주소를 지정하고, 필요한 경우 연결 실패를 찾아내어 재연결을 시도하는 방법을 지정합니다. 이러한 속성은 표 16–1에 요약되어 있습니다.

브로커 주소 목록

가장 중요한 연결 처리 속성은 imqAddressList로서, 이 속성은 브로커 또는 연결을 설정할 브로커를 지정합니다. 이 속성의 값은 하나의 브로커 주소 또는 (브로커 클러스터의 경우) 쉼표로 구분된 여러 주소를 포함하는 문자열입니다. 브로커 주소는 사용할 연결 서비스( 연결 서비스 참조)와 연결 설정 방법에 따라 다양한 주소 지정 체계를 사용할 수 있습니다.

• mq는 브로커의 포트 매퍼를 사용하여 jms 또는 ssljms 연결 서비스를 위해 포트를 동적으로 할당합니다.

• mqtcp는 포트 매퍼를 우회하고 jms 연결 서비스를 사용하여 지정된 포트로 직접 연결합니다.

• mqssl은 ssljms 연결 서비스를 사용하여 지정된 포트에 SSL(Secure Socket Layer) 연결을 설정합니다.

• http는 httpjms 연결 서비스를 사용하여 지정된 URL에서 Message Queue 터널 서블릿으로 HTTP(Hypertext Transport Protocol) 연결을 설정합니다.

• https는 httpsjms 연결 서비스를 사용하여 지정된 URL에서 Message Queue 터널 서블릿으로 HTTPS(Secure Hypertext Transport Protocol) 연결을 설정합니다.

이러한 주소 지정 체계는 표 16–2에 요약되어 있습니다.

각 브로커 주소의 일반 형식은 다음과 같습니다.

scheme://address

여기서 scheme은 위에 나열된 주소 지정 체계 중 하나이며 address는 브로커 주소 자체를 나타냅니다. 표 16–2의 마지막 열에 표시된 대로, 주소를 지정하는 정확한 구문은 주소 지정 체계에 따라 다릅니다. 표 16–3에서는 다양한 주소 형식의 예를 보여줍니다.

다중 브로커 클러스터 환경의 주소 목록에는 두 개 이상의 브로커 주소가 포함될 수 있습니다. 첫 번째 연결 시도가 실패하면 Message Queue 클라이언트 런타임에서 목록에 있는 다른 주소로 연결을 시도하며, 연결되지 않은 경우 목록의 마지막 항목에 이를 때까지 계속 시도합니다. 두 개의 추가 연결 팩토리 속성이 이러한 연결 시도 방법을 제어합니다.

• imqAddressListBehavior는 지정한 주소로 연결을 시도하는 순서를 지정합니다. 이 속성이 PRIORITY 문자열로 설정된 경우 주소에 대한 연결 시도는 주소 목록에 나타나는 순서대로 실행됩니다. 속성 값이 RANDOM이면 임의의 순서대로 주소를 선택하여 연결을 시도합니다. 이 방법은 많은 Message Queue 클라이언트가 동일한 연결 팩토리 객체를 공유하는 경우 모든 클라이언트가 동일한 브로커 주소로의 연결을 시도하지 않도록 하는 데 유용합니다.

• imqAddressListIterations는 연결을 포기하고 실패를 보고하기 전에 목록 전체를 몇 번씩 반복할지 지정합니다. 값 -1은 무제한 반복을 의미합니다. 연결이 설정되거나 종료 시간까지(둘 중 먼저 발생하는 항목) 클라이언트 런타임에서 연결을 계속 시도합니다.

자동 재연결

연결 팩토리의 imqReconnectEnabled 속성을 true로 설정하면 연결에 실패한 경우 클라이언트가 브로커에 자동으로 다시 연결할 수 있습니다. imqReconnectAttempts 속성은 지정된 브로커 주소에 대한 재연결 시도 횟수를 제어하고, imqReconnectInterval 속성은 시도 간격(초)을 지정합니다.

브로커 주소 목록(imqAddressList)에 여러 주소가 지정되어 있는 브로커 클러스터에서 실패한 연결은 원래의 브로커에서뿐만 아니라 클러스터의 다른 브로커에서도 복원될 수 있습니다. 원래 브로커로의 재연결이 실패하면 클라이언트 런타임은 목록의 다른 주소로 시도합니다. imqAddressListBehavior 및 imqAddressListIterations 속성은 이전 절에 설명한 대로 연결 시도되는 주소의 순서와 목록 반복 횟수를 제어합니다. 각 주소에 대해 imqReconnectInterval 밀리초 간격으로 반복을 시도하며, imqReconnectAttempts를 통해 지정된 최대 시도 횟수까지 반복을 시도합니다.

자동 재연결은 메시지 사용에 대한 모든 클라이언트 확인 모드를 지원합니다. 연결이 다시 설정된 후 브로커는 이전에 전달한 확인되지 않은 모든 메시지를 다시 전달하며 해당 메시지에 Redeliver 플래그를 표시합니다. 응용 프로그램 코드에서는 이 플래그를 사용하여 이미 사용되었지만 아직 확인되지 않은 메시지가 있는지 확인합니다. 그러나 비영구 가입자의 경우 연결이 닫히게 되면 브로커에 메시지가 저장되지 않습니다. 따라서 연결이 종료된 상태에서 해당 가입자에 대해 생성된 메시지는 재연결 후에도 전달할 수 없으므로 손실됩니다.자동 재연결 중에는 메시지 생성이 차단됩니다. 메시지 생성자는 연결이 다시 설정될 때까지 브로커로 메시지를 보낼 수 없습니다.

자동 재연결은 연결 페일오버를 제공하지만 데이터 페일오버는 제공하지 않습니다. 실패한 브로커 또는 연결이 끊긴 브로커가 가지고 있는 지속성 메시지 및 기타 상태 정보는 클라이언트가 다른 브로커 인스턴스에 재연결될 때 손실될 수 있습니다. 연결 재설정을 시도하는 동안 Message Queue에서는 클라이언트 런타임이 제공한 객체(세션, 메시지 사용자 및 메시지 생성자)를 유지합니다. 연결 실패 시 잠시 동안 임시 대상도 유지 관리됩니다. 클라이언트가 다시 연결하여 임시 대상에 다시 액세스할 수도 있기 때문입니다. 클라이언트에게 다시 연결하여 이러한 대상을 사용할 수 있는 시간을 제공한 후 브로커는 해당 대상을 삭제합니다. 재연결 시 클라이언트측 상태를 브로커에서 완전히 복원할 수 없는 경우(예: 연결 시간 동안에만 존재하는 트랜잭션된 세션 사용 시) 자동 재연결이 수행되지 않으며 연결의 예외 처리기가 대신 호출됩니다. 그리고 나면 응용 프로그램 코드에 따라 예외, 재연결 및 복원 상태를 파악하게 됩니다.

주기적 연결 테스트(핑)

연결을 주기적으로 테스트하거나 “핑”을 실행하도록 Message Queue 클라이언트 런타임을 구성하면 시도한 메시지 전송이 실패하기 전에 먼저 연결 실패를 감지할 수 있습니다. 이러한 테스트는 메시지를 사용하기만 하고 생성하지는 않는 클라이언트 응용 프로그램에 특히 중요합니다. 그렇지 않으면 연결이 실패한 경우 이러한 응용 프로그램을 찾아낼 수 없기 때문입니다. 메시지를 가끔씩만 생성하는 클라이언트에도 이 기능을 유용하게 사용할 수 있습니다.

연결 팩토리 속성 imqPingInterval은 연결을 핑할 빈도(초)를 지정합니다. 기본적으로 이 간격은 30초로 설정되며 값 -1은 핑 작업을 수행할 수 없습니다.

실패한 핑에 대한 응답은 운영 체제 플랫폼마다 다릅니다. 일부 운영 체제에서는 클라이언트 응용 프로그램의 예외 수신기에 예외가 즉시 발생합니다. 클라이언트에 예외 수신기가 없는 경우에는 다음 번 연결 사용 시도가 실패합니다. 다른 시스템에서는 핑이 성공하거나 버퍼 오버플로가 발생할 때까지 연속적으로 핑을 버퍼링하여 브로커에 대한 연결 설정을 계속해서 시도하기도 합니다.

클라이언트 아이디

표 16–4에 나열된 연결 팩토리 속성은 클라이언트 인증과 영구 가입자의 클라이언트 식별자 설정을 지원합니다.

클라이언트 인증

메시지 서비스에서 관리하는 사용자 저장소에 대해 사용자 이름 및 비밀번호를 사용하여 브로커에 연결하려는 모든 시도를 인증해야 합니다. 연결 팩토리 속성 imqDefaultUsername 및 imqDefaultPassword는 연결을 생성할 때 클라이언트가 명시적으로 제공하지 않을 경우 사용할 기본 사용자 이름 및 비밀번호를 지정합니다.

응용 프로그램 개발 및 테스트 중 사용자 저장소 채우기를 번거롭게 여기는 개발자의 편의를 제공하기 위해 Message Queue는 사용자 이름과 비밀번호가 모두 guest인 guest 사용자 계정을 제공합니다. 또한 이 값은 imqDefaultUsername 및 imqDefaultPassword 속성의 기본값이기도 하므로, 명시적으로 지정되지 않은 경우 클라이언트는 항상 guest 계정으로 연결을 설정할 수 있습니다. 작업 환경에서 브로커 연결 액세스는 사용자 저장소에 명시적으로 등록되어 있는 사용자로만 제한되어야 합니다.

클라이언트 식별자

Java Message Service 사양에서는 브로커가 클라이언트를 대신하여 지속성 상태를 유지해야 할 때마다 연결이 고유한 클라이언트 식별자를 제공하도록 규정합니다. Message Queue는 이러한 클라이언트 식별자를 사용하여 주제 대상에 대한 영구 가입자를 추적합니다. 영구 가입자가 비활성 상태인 경우 브로커는 주제에 대한 모든 수신 메시지를 보관했다가 가입자가 다시 활성화되면 전달합니다. 브로커는 클라이언트 식별자로 가입자를 식별합니다.

클라이언트 응용 프로그램이 연결 객체의 setClientID 메소드를 사용하여 프로그래밍 방식으로 고유의 클라이언트 식별자를 설정할 수 있지만, 각 식별자가 고유하도록 클라이언트 식별자를 조정하기는 어렵습니다. 일반적으로는 클라이언트를 대신하여 연결을 생성하는 경우 Message Queue에서 고유한 식별자를 자동으로 할당하게 하는 편이 더 좋습니다. 그러기 위해서는 연결 팩토리의 imqConfiguredClientID 속성을 다음 형식의 값으로 설정하면 됩니다.

${u}factoryID

${u} 문자는 속성 값의 처음 네 문자여야 합니다. 중괄호 안에 u 이외의 문자를 지정할 경우 연결 생성 시 예외가 발생하게 됩니다. 이러한 문자가 다른 위치에서 사용되는 경우에는 특별한 의미 없이 일반 텍스트로 간주됩니다. factoryID의 값은 연결 팩토리 객체와 관련된 고유 문자열입니다.

특정 클라이언트에 대한 연결을 생성하는 경우 Message Queue는 ${u} 문자를 u:userName으로 바꾸어 클라이언트 식별자를 구성합니다. 여기서 userName은 연결 인증에 사용되는 사용자 이름입니다. 따라서 해당 연결 팩토리가 생성한 연결은 다른 모든 측면에서는 동일하더라도 각 연결마다 고유한 클라이언트 식별자를 갖게 됩니다. 예를 들어, 사용자 이름이 Calvin이고 연결 팩토리의 imqConfiguredClientID 속성에 대해 지정된 문자열이 ${u}Hobbes이면 지정된 클라이언트 식별자는 u:CalvinHobbes가 됩니다.

두 클라이언트가 모두 기본 사용자 이름 guest를 사용하여 연결을 시도하는 경우에는 각 클라이언트마다 동일한 ${u} 구성 요소를 가진 클라이언트 식별자를 갖게 되므로 이 방법이 적용되지 않습니다. 이 경우, 연결을 요청한 첫 번째 클라이언트만 연결됩니다. Message Queue에서 클라이언트 식별자가 동일한 두 개의 연결을 생성할 수는 없으므로 두 번째 클라이언트의 연결 시도는 실패하게 됩니다.

imqConfiguredClientID를 사용하여 클라이언트 식별자를 지정한 경우에도 클라이언트 응용 프로그램은 setClientID 연결 메소드를 사용하여 이 설정을 무시할 수 있습니다. 연결 팩토리의 imqDisableSetClientID 속성을 true로 설정하면 이 작업을 막을 수 있습니다. 영구 가입자를 사용하는 응용 프로그램의 경우에는 imqConfiguredClientID를 사용한 관리 방식이나 setClientID를 사용한 프로그램 방식으로 클라이언트 식별자를 설정해야 합니다.

안정성 및 흐름 제어

클라이언트에서 송/수신되는 “페이로드” 메시지와 Message Queue에서 자체적으로 사용하는 제어 메시지(브로커 확인 등)는 동일한 클라이언트 브로커 연결을 생략하기 때문에 과도한 페이로드 트래픽 수준이 제어 메시지 전달을 방해할 수 있습니다. 이 문제를 줄이려면 표 16–5에 나열된 연결 팩토리 속성을 사용하여 두 가지 메시지 유형의 상대적 흐름을 관리할 수 있습니다. 이 속성들은 다음 네 가지 범주로 분류됩니다.

• 확인 시간 초과는 예외 발생 전 브로커 확인을 기다리는 최대 시간(imqAckTimeout)을 지정합니다.

• 연결 흐름 측정은 페이로드 메시지 전송을 지정된 크기의 일괄 처리(imqConnectionFlowCount)로 제한하여 누적된 제어 메시지를 주기적으로 전달할 수 있게 합니다.

• 연결 흐름 제어는 사용될 때까지 기다리고 있는 연결에 대해 보류 중일 수 있는 페이로드 메시지의 수(imqConnectionFlowLimit)를 제한합니다. 제한에 도달하면 사용 대기 중인 메시지 수가 제한보다 적을 때까지 연결에 대한 페이로드 메시지 전달이 일시 중단됩니다. 이 기능의 사용은 부울 플래그(imqConnectionFlowLimitEnabled)를 통해 제어됩니다.

• 사용자 흐름 제어는 사용될 때까지 기다리고 있는 단일 사용자에 대해 보류 중일 수 있는 페이로드 메시지의 수(imqConsumerFlowLimit)를 제한합니다. 이 제한은 consumerFlowLimit와 같은 특정 대기열 대상의 등록 정보로 지정할 수도 있습니다. 제한에 도달하면 사용 대기 중인 메시지 수를 나타내는 imqConsumerFlowLimit의 비율이 imqConsumerFlowThreshold 속성에서 지정한 제한보다 낮을 때까지 사용자에 대한 페이로드 메시지의 전달이 일시 중단됩니다. 따라서 여러 사용자가 동일한 연결에 집중되지 않도록 함으로써 사용자 간 로드 균형 유지를 향상시킬 수 있습니다.

이러한 흐름 제어 기술 중 하나를 사용하려면 신뢰성과 처리량을 적절히 조정해야 합니다. 자세한 내용은 클라이언트 런타임 메시지 흐름 조정을 참조하십시오.

대기열 브라우저 및 서버 세션

표 16–6은 클라이언트 대기열 찾아보기와 서버 세션에 영향을 주는 연결 팩토리 속성을 나열합니다. imqQueueBrowserMaxMessagesPerRetrieve 속성은 대기열 대상 내용을 찾아볼 때 한 번에 검색할 수 있는 최대 메시지 수를 지정합니다. imqQueueBrowserRetrieveTimeout은 메시지 검색 시 최대 대기 시간을 지정합니다. imqQueueBrowserMaxMessagesPerRetrieve는 검색되는 총 메시지 수에는 영향을 주지 않고 클라이언트 런타임에 전달하기 위해 메시지가 청크되는 방법에만 영향을 줍니다. 청크가 클수록 메시지 수는 적고, 청크가 작을수록 메시지 수는 많아집니다. 클라이언트 응용 프로그램은 항상 대기열의 모든 메시지를 받습니다. 속성 값을 변경하면 성능에 영향을 줄 수 있지만, 검색되는 총 데이터 양에는 영향을 주지 않습니다.부울 속성 imqLoadMaxToServerSession은 응용 프로그램 서버 세션에서 연결 사용자의 동작을 제어합니다. 이 속성의 값이 true이면 클라이언트는 서버 세션에 최대 메시지 수까지 로드할 수 있습니다. false이면 한 번에 하나의 메시지만 로드합니다.

표준 메시지 등록 정보

JMS(Java Message Service) 사양은 JMS 공급자(Message Queue 등)가 필요에 따라 지원을 선택할 수 있는 특정 표준 메시지 등록 정보를 정의합니다. 편의상 이러한 표준 등록 정보의 이름은 모두 JMSX로 시작됩니다. 표 16–7에 나열된 연결 팩토리 속성은 Message Queue 클라이언트 런타임에서 특정 표준 등록 정보를 설정할지 여부를 제어합니다. 생성된 메시지의 경우에는 다음 등록 정보를 포함합니다.

• JMSXUserID 메시지를 보내는 사용자의 아이디

• JMSXAppID 메시지를 보내는 응용 프로그램의 아이디

• JMSXProducerTXID 메시지가 생성된 트랜잭션의 트랜잭션 식별자

사용된 메시지의 경우에는 다음 등록 정보를 포함합니다.

• JMSXConsumerTXID 메시지가 사용된 트랜잭션의 트랜잭션 식별자

• JMSXRcvTimestamp 메시지가 사용자에게 전달된 시간

메시지 헤더 대체

표 16–8에 나열된 연결 팩토리 속성을 사용하여 특정 JMS 메시지 헤더 필드에 대해 클라이언트가 설정한 값을 무시할 수 있습니다. 사용자가 지정한 설정은 연결 팩토리에서 가져온 연결에서 생성된 모든 메시지에 사용됩니다. 이 방법으로 무시할 수 있는 헤더 필드는 다음과 같습니다.

• JMSDeliveryMode 전달 모드(지속성 또는 비지속성

• JMSExpiration 만료 시간

• JMSPriority 우선 순위 수준

이러한 각 필드에는필드를 무시할 수 있는지 여부를 제어하는 부울 속성과 값을 지정하기 위한 부울 속성의 두 가지 속성이 있습니다. 예를 들어, 우선 순위 수준을 설정하기 위한 속성은 imqOverrideJMSPriority와 imqJMSPriority입니다. 임시 대상에 적용되는 값을 무시할지 여부를 제어하는 imqOverrideJMSHeadersToTemporaryDestinations 속성도 있습니다.

무시되는 메시지 헤더는 특정 응용 프로그램의 요구에 맞지 않을 수도 있으므로 이 속성은 반드시 응용 프로그램 설계자 또는 사용자와 상의하여 사용해야 합니다.

대상 속성

물리적 대기열 또는 주제 대상을 식별하는 대상 관리 객체는 표 16–9에 나열된 두 가지 속성만 갖습니다. 중요한 한 가지 속성은 imqDestinationName으로, 이 속성은 관리 대상 객체가 나타내는 물리적 대상의 이름을 제공합니다. 이 이름은 물리적 대상을 만든 imqcmd create dst 명령에 -n 옵션을 사용하여 지정된 이름입니다. 대상 관리 객체와 해당 객체가 나타내는 물리적 대상이 반드시 일대일 관계가 아니어도 됩니다. 하나의 물리적 대상을 여러 관리 대상 객체가 참조할 수도 있고 물리적 대상을 참조하는 관리 대상 객체가 없을 수도 있습니다.또한 imqDestinationDescription이라는 선택적 설명 문자열도 있습니다. 이 문자열을 사용하면 대상 객체를 식별하거나 사용자가 만든 대상 객체를 다른 대상 객체와 구분하기가 쉽습니다.

객체 관리자 유틸리티 사용

Message Queue 객체 관리자 유틸리티(imqobjmgr)를 사용하면 관리 대상 객체를 만들고 관리할 수 있습니다. imqobjmgr 명령은 관리 대상 객체에 대한 다양한 작업을 수행하기 위해 다음과 같은 하위 명령을 제공합니다.

add

관리 대상 객체를 객체 저장소에 추가

delete

객체 저장소에서 관리 대상 객체 삭제

list

객체 저장소에 기존 관리 대상 객체 나열

query

관리 대상 객체에 대한 정보 표시

update

관리 대상 객체의 속성 수정

imqobjmgr 명령의 구문, 하위 명령 및 옵션에 대한 자세한 내용은 객체 관리자 유틸리티를 참조하십시오.

대부분의 객체 관리자 작업의 경우 imqobjmgr 명령 옵션으로 다음 정보를 지정해야 합니다.

• 관리 대상 객체의 JNDI 조회 이름(-l)

  이 이름은 클라이언트 응용 프로그램에서 JNDI(Java Naming and Directory Interface)를 사용하여 객체 저장소의 관리 객체를 조회할 수 있는 논리적 이름입니다.

• JNDI 객체 저장소의 속성(-j)

  사용 가능한 속성 및 값에 대한 자세한 내용은 객체 저장소를 참조하십시오.

• 관리 대상 객체의 유형(-t)

  사용 가능한 유형은 다음과 같습니다.

  q

  대기열 대상

  t

  주제 대상

  cf

  연결 팩토리

  qf

  대기열 연결 팩토리

  tf

  주제 연결 팩토리

  xcf

  분산 트랜잭션의 연결 팩토리

  xqf

  배포 트랜잭션의 대기열 연결 팩토리

  xtf

  분산 트랜잭션의 주제 연결 팩토리

  e

  SOAP 종점

• 관리 대상 객체의 속성(-o)

  사용 가능한 속성 및 값에 대한 자세한 내용은 관리 객체 속성을 참조하십시오.

관리 객체 추가

imqobjmgr 명령의 add 하위 명령은 연결 팩토리의 관리 대상 객체나 주제 또는 대기열 대상을 객체 저장소에 추가합니다. LDAP 객체 저장소에 저장된 관리 대상 객체에는 cn=; 접두사로 시작하는 조회 이름이 지정되어야 하며, 파일 시스템 객체 저장소의 조회 이름은 특정 접두사로 시작할 필요는 없지만 슬래시 문자(/)를 포함할 수 없습니다.

객체 관리자는 Message Queue 관리 대상 객체만 나열하고 표시합니다. 객체 저장소에 추가할 관리 대상 객체와 동일한 조회 이름을 가진 비 Message Queue 객체를 포함해야 하는 경우에 이 객체를 추가하려고 하면 오류 메시지가 표시됩니다.

연결 팩토리 추가

클라이언트 응용 프로그램에서 브로커 연결을 생성할 수 있도록 하려면 생성할 연결 유형(대기열 연결 팩토리 또는 주제 연결 팩토리)에 대해 연결 팩토리 관리 대상 객체를 추가합니다. 예 8–1은 대기열 연결 팩토리(관리 대상 객체 유형 qf)를 LDAP 객체 저장소에 추가하는 명령을 보여줍니다. 객체에는 조회 이름 cn=myQCF가 지정되며 jms 연결 서비스를 사용하여 7272 포트 번호를 통해 myHost 호스트에서 실행 중인 브로커에 연결합니다.

예 8–1 연결 팩토리 추가

imqobjmgr add
   -l "cn=myQCF"
   -j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
   -j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
   -j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
   -j "java.naming.security.credentials=doh"
   -j "java.naming.security.authentication=simple"
   -t qf
   -o "imqAddressList=mq://myHost:7272/jms"

대상 추가

대상을 나타내는 관리 객체를 만드는 경우 관리 객체를 객체 저장소에 추가하기 전에 먼저 물리적 대상을 만드는 것이 좋습니다. 물리적 대상 만들기에 설명한 대로 명령 유틸리티(imqcmd )를 사용하여 물리적 대상을 만듭니다.

예 8–2에 나와 있는 명령은 조회 이름 myTopic을 사용하여 주제 대상을 나타내는 LDAP 객체 저장소에 관리 대상 객체를 추가하며, 물리적 대상 이름은 physTopic입니다. 대기열 대상을 추가하는 명령도 이와 비슷하며, 관리 대상 객체 유형(-t 옵션)으로 t("주제 대상") 대신에 q("대기열 대상")를 사용하는 것이 다릅니다.

예 8–2 LDAP 객체 저장소에 대상 추가

imqobjmgr add
   -l "cn=myTopic"
   -j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
   -j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
   -j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
   -j "java.naming.security.credentials=doh"
   -j "java.naming.security.authentication=simple"
   -t t
   -o "imqDestinationName=physTopic"

예 8–3은 LDAP 서버 대신에 Solaris 파일 시스템에 저장된 관리 대상 객체를 사용하는 동일한 명령을 보여줍니다.

예 8–3 파일 시스템 객체 저장소에 대상 추가

imqobjmgr add
   -l "cn=myTopic"
   -j "java.naming.factory.initial=
           com.sun.jndi.fscontext.RefFSContextFactory"
   -j "java.naming.provider.url=file:///home/foo/imq_admin_objects"
   -t t
   -o "imqDestinationName=physTopic"

관리 객체 삭제

객체 저장소에서 관리 대상 객체를 삭제하려면 imqobjmgr 명령의 delete 하위 명령을 사용하고 삭제할 객체의 조회 이름, 유형 및 위치를 지정합니다. 예 8–4에 표시된 명령은 위 대상 추가에서 추가된 객체를 삭제합니다.

예 8–4 관리 객체 삭제

imqobjmgr delete
   -l "cn=myTopic"
   -j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
   -j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
   -j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
   -j "java.naming.security.credentials=doh"
   -j "java.naming.security.authentication=simple"
   -t t

관리 객체 나열

객체 관리자의 list 하위 명령을 사용하면 객체 저장소의 모든 관리 대상 객체 또는 특정 유형의 관리 대상 객체 목록을 가져올 수 있습니다. 예 8–5는 LDAP 서버의 모든 관리 대상 객체를 나열하는 방법을 보여줍니다.

예 8–5 모든 관리 객체 나열

imqobjmgr list
   -j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
   -j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
   -j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
   -j "java.naming.security.credentials=doh"
   -j "java.naming.security.authentication=simple"

예 8–6은 모든 대기열 대상(유형 q)을 나열합니다.

예 8–6 특정 유형의 관리 객체 나열

imqobjmgr list
   -j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
   -j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
   -j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
   -j "java.naming.security.credentials=doh"
   -j "java.naming.security.authentication=simple"
   -t q

관리 객체 정보 보기

query 하위 명령은 객체의 조회 이름과 객체를 포함하는 객체 저장소의 속성을 통해 식별되는 지정된 관리 대상 객체에 대한 정보를 표시합니다. 예 8–7은 조회 이름이 cn=myTopic인 객체에 대한 정보를 표시합니다.

예 8–7 관리 객체 정보 보기

imqobjmgr query
   -l "cn=myTopic"
   -j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
   -j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
   -j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
   -j "java.naming.security.credentials=doh"
   -j "java.naming.security.authentication=simple"

관리 객체 속성 수정

관리 대상 객체의 속성을 수정하려면 imqobjmgr update 하위 명령을 사용합니다. 객체의 조회 이름 및 위치를 입력하고 -o 옵션을 사용하여 새 속성 값을 지정합니다.

관리 객체 속성 수정에서는 예 8–8에서 객체 저장소에 추가된 대기열 연결 팩토리에 대한 imqReconnectAttempts 속성 값을 변경합니다.

예 8–8 관리 대상 객체 속성 수정

imqobjmgr update
   -l "cn=myQCF"
   -j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
   -j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
   -j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
   -j "java.naming.security.credentials=doh"
   -j "java.naming.security.authentication=simple"
   -t qf
   -o "imqReconnectAttempts=3"

명령 파일 사용

imqobjmgr 명령에 대한 -i 옵션을 사용하면 하위 명령 절의 전체 또는 일부를 나타내기 위해 Java 등록 정보 파일 구문을 사용하는 명령 파일의 이름을 지정할 수 있습니다. 이 기능은 일반적으로 입력을 많이 해야 하거나 imqobjmgr의 여러 호출에서 동일한 내용을 입력해야 하는 객체 저장소 속성을 지정하는 데 특히 유용합니다. 명령 파일을 사용하면 명령줄에 허용되는 최대 문자 수를 초과하는 일을 방지할 수도 있습니다.

예 8–9는 객체 관리자 명령 파일의 일반 구문을 보여줍니다. version 속성은 명령줄 옵션이 아닙니다. 이 속성은 Message Queue 제품 버전이 아니라 명령 파일 자체의 버전을 참조하므로 값을 2.0으로 설정해야 합니다.

예 8–9 객체 관리자 명령 파일 구문

version=2.0
cmdtype=[ add | delete | list | query | update ]
obj.lookupName=lookup name
objstore.attrs.objStoreAttrName1=value1
objstore.attrs.objStoreAttrName2=value2
   . . .
objstore.attrs.objStoreAttrNameN=valueN
obj.type=[ q | t | cf | qf | tf | xcf | xqf | xtf | e ]
obj.attrs.objAttrName1=value1
obj.attrs.objAttrName2=value2
   . . .
obj.attrs.objAttrNameN=valueN

예를 들어, 대기열 연결 팩토리를 LDAP 객체 저장소에 추가한 이전의 예 8–1에서 객체 관리자 명령을 살펴보겠습니다. 이 명령을 예 8–10에 표시된 대로 명령 파일에 캡슐화할 수 있습니다. 명령 파일의 이름이 MyCmdFile이면 명령줄에서 다음 명령을 실행할 수 있습니다.

imqobjmgr -i MyCmdFile

예 8–10 명령 파일 예

version=2.0
cmdtype=add
obj.lookupName=cn=myQCF
objstore.attrs.java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
objstore.attrs.java.naming.provider.url=ldap://mydomain.com:389/o=imq
objstore.attrs.java.naming.security.principal=\\
                                       uid=homerSimpson,ou=People,o=imq
objstore.attrs.java.naming.security.credentials=doh
objstore.attrs.java.naming.security.authentication=simple
obj.type=qf
obj.attrs.imqAddressList=mq://myHost:7272/jms

명령 파일을 사용하면 나머지 부분을 명령줄에 명시적으로 제공하면서 imqobjmgr 하위 명령 절의 일부만 지정할 수도 있습니다. 예를 들어, 예 8–11에 표시된 명령 파일은 LDAP 객체 저장소의 속성 값만 지정합니다.

예 8–11 부분 명령 파일

version=2.0
objstore.attrs.java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
objstore.attrs.java.naming.provider.url=ldap://mydomain.com:389/o=imq
objstore.attrs.java.naming.security.principal=\\
                                       uid=homerSimpson,ou=People,o=imq
objstore.attrs.java.naming.security.credentials=doh
objstore.attrs.java.naming.security.authentication=simple

그리고 나면 이 명령 파일을 사용하여 예 8–12에 표시된 대로 나머지 옵션을 명시적으로 제공하면서 imqobjmgr 명령에 객체 저장소를 지정할 수 있습니다.

예 8–12 부분 명령 파일 사용

imqobjmgr add
   -l "cn=myQCF"
   -i MyCmdFile
   -t qf
   -o "imqAddressList=mq://myHost:7272/jms"

사용자의 플랫폼에 따라 다음 위치에서 명령 파일의 예를 추가로 확인할 수 있습니다.

Solaris:/usr/demo/imq/imqobjmgr Linux:/opt/sun/mq/examples/imqobjmgr Windows:IMQ_HOME/demo/imqobjmgr

9장 브로커 클러스터 작업

Message Queue^TM Enterprise Edition은 메시지 전달 서비스를 클라이언트에 제공하기 위해 함께 작업하는 브로커 그룹인 브로커 클러스터의사용을 지원합니다. 클러스터를 사용하여 메시지 서비스는 다중 브로커 간에 클라이언트 연결을 분배하는 방식으로 메시지 트래픽의 볼륨에 대한 작업 크기를 조절할 수 있습니다. 클러스터 및 클러스터 작업 방법에 대한 자세한 내용은 Message Queue 기술 개요를 참조하십시오.

이 장에서는 브로커 클러스터를 관리하고 브로커를 브로커 클러스터에 연결하는 방법 및 브로커 클러스터 구성 방법을 설명합니다. 이 장은 다음 내용으로 구성되어 있습니다.

• 클러스터 구성 등록 정보

• 클러스터 관리

• 마스터 브로커

클러스터 구성 등록 정보

각 클러스터 구성원 브로커에 대한 클러스터 구성 등록 정보를 지정하여 클러스터를 정의합니다. 이러한 등록 정보는 클러스터의 각 브로커에 대해 개별적으로 설정할 수도 있지만 모든 브로커가 참조하는 중앙 클러스터 구성 파일에 모으는 것이 일반적으로 더 편리합니다. 이렇게 하면 설정이 달라지지 않으므로 클러스터의 모든 브로커가 동일하고 일관된 구성 정보를 공유하게 됩니다.

클러스터 구성 등록 정보는 표 14–9에서 자세히 설명합니다. 여기에는 다음 항목이 포함됩니다.

• imq.cluster.brokerlist 클러스터에 속하는 모든 브로커의 호스트 이름과 포트 번호를 지정합니다.

• imq.cluster.masterbroker 상태 변경을 추적하는 마스터 브로커에 해당하는 브로커(있는 경우)를 지정합니다.

• imq.cluster.url 클러스터 구성 파일(있는 경우)의 위치를 지정합니다.

• imq.cluster.hostname 클러스터 내의 브로커 간 내부 통신에 사용되는 cluster 연결 서비스의 호스트 이름 또는 IP 주소를 지정합니다. 이 설정은 컴퓨터에 여러 개의 네트워크 인터페이스 카드가 있을 때처럼사용 가능한 호스트가 두 개 이상인 경우에 유용합니다.

• imq.cluster.port cluster 연결 서비스에 포트 번호를 제공합니다.

• imq.cluster.transport cluster 연결 서비스에 사용되는 전송 프로토콜(예: tcp 또는 ssl)을 지정합니다.

hostname 및 port 등록 정보는 각 개별 브로커에 대해 독립적으로 설정할 수 있지만 brokerlist, masterbroker, url 및 transport는 클러스터 내의 모든 브로커에 대해 동일한 값을 가져야 합니다.

다음 절에서는 클러스터 구성 파일을 사용하여 브로커의 클러스터 구성 등록 정보를 설정하는 방법(클러스터의 각 브로커에 대해 개별 설정 또는 중앙 설정)에 대해 설명합니다.

개별 브로커에 대한 클러스터 등록 정보 설정

인스턴스 구성 파일(또는 브로커를 시작할 때 명령줄에서) 브로커 클러스터 구성 등록 정보를 설정할 수 있습니다. 예를 들어, host1의 9876 포트, host2의 5000 포트 및 ctrlhost의 기본 포트(7676)에서 여러 브로커로 구성된 클러스터를 만들려면 세 브로커 모두의 인스턴스 구성 파일에 다음 등록 정보를 포함시켜야 합니다.

imq.cluster.brokerlist=host1:9876,host2:5000,ctrlhost

이 방법을 사용하면 클러스터 구성을 변경해야 하는 경우 클러스터 내 모든 브로커의 인스턴스 구성 파일을 업데이트해야 합니다.

클러스터 구성 파일 사용

일관성과 간편한 유지 관리를 위해서는 클러스터 구성 등록 정보를 브로커별로 개별 설정하는 대신 모든 공유 클러스터 구성 등록 정보를 단일 클러스터 구성 파일에 모으는 것이 좋습니다. 이 방법에서 각 브로커의 인스턴스 구성 파일은 클러스터 구성 파일의 위치를 가리키도록 imq.cluster.url 등록 정보를 설정해야 합니다. 예를 들면, 다음과 같습니다.

imq.cluster.url=file:/home/cluster.properties

그런 다음 클러스터 구성 파일은 클러스터 내의 모든 브로커에 대해 연결할 브로커 목록(imq.cluster.brokerlist), cluster 연결 서비스에 사용할 전송 프로토콜(imq.cluster.transport ) 및 마스터 브로커의 주소(imq.cluster.masterbroker)와 같은 공유 구성 등록 정보를 정의합니다. 다음 코드는 마스터 브로커 역할을 하는 ctrlhost에서 실행되는 브로커와 함께 이전 예에서와 같은 클러스터를 정의합니다.

imq.cluster.brokerlist=host1:9876,host2:5000,ctrlhost
imq.cluster.masterbroker=ctrlhost

클러스터 관리

이 절에서는 브로커 집합을 연결하여 클러스터를 형성하고 기존 클러스터에 새 브로커를 추가하고 클러스터에서 브로커를 제거하는 방법에 대해 설명합니다.

브로커 연결

일반적으로 명령줄에서 (-cluster 옵션 사용) 또는 클러스터 구성 파일에서 imq.cluster.brokerlist 등록 정보를 설정하는 두 가지 방법으로 클러스터에 브로커를 연결할 수 있습니다. 사용하는 방법에 관계없이 시작한 각 브로커는 5분마다 다른 브로커에 연결하려고 시도합니다. 이 때 마스터 브로커(구성되어 있는 경우)가 시작되면 연결에 성공한 것입니다. 클러스터의 브로커가 마스터 브로커보다 먼저 시작된 경우 일시 중지된 상태를 유지하여 클라이언트 연결을 거부합니다. 일시 중지된 브로커는 마스터 브로커가 시작되면 자동으로 다시 작동합니다.

명령줄에서 브로커 클러스터를 구성하려면 -cluster 옵션을 imqbrokerd 명령에 사용하여 클러스터 내의 전체 브로커 목록을 지정합니다. 예를 들어, 다음 명령은 새 브로커를 시작하여 host1의 기본 포트(7676), host2의 5000 포트 및 기본 호스트(localhost)의 9876 포트에서 실행하는 브로커에 연결합니다.

imqbrokerd -cluster host1,host2:5000,:9876

대체 방법으로 imq.cluster.brokerlist 등록 정보를 사용하여 연결할 브로커 목록을 지정하는 클러스터 구성 파일을 만들 수 있습니다. 이 방법은 작업 시스템에 더 적합한 방법입니다. 그런 다음 클러스터의 각 브로커에서 이 클러스터 구성 파일을 가리키도록 자체 imq.cluster.url 등록 정보를 설정해야 합니다.

사용하는 방법에 관계없이 네트워크 루프백 IP 주소(127.0.0.1)로 확인되는 주소가 클러스터의 브로커에 지정되지 않아야 합니다. 이 주소로 구성된 브로커는 클러스터의 다른 브로커에 연결할 수 없습니다.

일부 Linux 설치 프로그램은 localhost 항목을 네트워크 루프백 주소로 자동으로 설정합니다. 그러한 시스템에서 사용자는 클러스터의 모든 브로커 주소가 제대로 지정될 수 있도록 시스템 IP 주소를 수정해야 합니다.

클러스터에 참여하는 모든 Linux 시스템의 경우 클러스터 설정 과정의 일부로 /etc/hosts 파일을 확인합니다. 시스템에서 정적 IP 주소를 사용하는 경우 /etc/hosts 파일을 편집하여 올바른 localhost 주소를 지정합니다. 주소가 DNS(Domain Name Service)에 등록되면 /etc/nsswitch.conf 파일을 편집하여 로컬 hosts 파일을 참조하기 전에 DNS 조회를 수행하도록 항목의 순서를 변경합니다. /etc/nsswitch.conf의 행은 다음과 같아야 합니다.

hosts:dns files

클러스터 내의 브로커 간에 암호화된 보안 메시지를 전달하려면 SSL 기반 전송 프로토콜을 사용하도록 cluster 연결 서비스를 구성합니다. 메시지 암호화에 설명된 것처럼 클러스터 내의 각 브로커에 대해 SSL 기반 연결 서비스를 설정합니다. 그런 다음 클러스터 구성 파일에서 또는 브로커별로 개별적으로 각 브로커의 imq.cluster.transport 등록 정보를 ssl로 설정합니다.

클러스터에 브로커 추가

클러스터에 새 브로커를 추가하는 절차는 클러스터가 클러스터 구성 파일을 사용하는지 여부에 따라 달라집니다.

클러스터 구성 파일을 사용하여 클러스터에 새 브로커를 추가하는 방법

1. 클러스터 구성 파일의 imq.cluster.brokerlist 등록 정보에 새 브로커를 추가합니다.

2. 클러스터의 브로커에 대해 다음 명령을 실행합니다.

   imqcmd reload cls

   이 명령은 각 브로커가 클러스터 구성을 다시 로드하게 하여 클러스터에 있는 브로커의 모든 영구 정보를 최신 상태로 유지합니다. 클러스터의 모든 브로커에 대해 이 명령을 실행할 필요는 없습니다. 한 브로커에 대해 명령을 실행하면 모든 브로커에서 클러스터 구성이 다시 로드됩니다.

3. (선택 사항) 클러스터 구성 파일을 가리키도록 브로커의 config.properties 파일에서 imq.cluster.url 등록 정보 값을 설정합니다.

4. 새 브로커를 시작합니다.

   클러스터에 브로커 추가를 수행하지 않은 경우 imqbrokerd 명령줄에서 -D 옵션을 사용하여 imq.cluster.url 값을 설정합니다.

클러스터 구성 파일을 사용하지 않고 클러스터에 새 브로커를 추가하는 방법

config.properties 파일을 편집하거나 imqbrokerd 명령줄에서 -D 옵션을 사용하여 다음 등록 정보 값을 설정합니다.

• imq.cluster.brokerlist

• imq.cluster.masterbroker(필요한 경우)

• imq.cluster.transport(보안 cluster 연결 서비스를 사용하는 경우)

클러스터에서 브로커 제거

클러스터에서 브로커를 제거하는 데 사용하는 방법은 처음에 클러스터를 만들 때 명령줄을 사용했는지 중앙 클러스터 구성 파일을 사용했는지에 따라 달라집니다.

명령줄을 사용하여 브로커 제거

명령줄에서 imqbrokerd 명령을 사용하여 클러스터에 브로커를 연결한 경우 명령줄에서 새 클러스터 구성원 집합을 지정하여 각 브로커를 중지한 다음 다시 시작해야 합니다. 절차는 다음과 같습니다.

명령줄을 사용하여 클러스터에서 브로커를 제거하는 방법

1. imqcmd 명령을 사용하여 클러스터에서 각 브로커를 중지합니다.

2. imqbrokerd 명령의 -cluster 옵션을 사용하여 남아 있는 브로커만 지정하여 클러스터에서 해당 브로커를 다시 시작합니다.

   예를 들어, 처음에 다음 명령을 사용하여 A, B, C 브로커 각각을 시작하여 세 개의 브로커로 구성된 클러스터를 만들었다고 가정합니다.

   imqbrokerd -cluster A,B, C

   클러스터에서 A 브로커를 제거하려면 다음 명령을 사용하여 B와 C 브로커를 다시 시작합니다.

   imqbrokerd -cluster B,C

클러스터 구성 파일을 사용하여 브로커 제거

처음에 중앙 클러스터 구성 파일의 imq.cluster.brokerlist 등록 정보를 사용하여 구성원 브로커를 지정해 클러스터를 만든 경우 브로커 중 하나를 제거하기 위해 브로커를 중지할 필요가 없습니다. 대신 구성 파일을 편집하여 제거할 브로커를 제외시키고 나머지 클러스터 구성원이 클러스터 구성을 다시 로드하게 한 다음 제외된 브로커가 해당 클러스터 구성 파일을 더 이상 가리키지 않도록 다시 구성하기만 하면 됩니다. 절차는 다음과 같습니다.

클러스터 구성 파일을 사용하여 클러스터에서 브로커를 제거하는 방법

1. 클러스터 구성 파일을 편집하여 imq.cluster.brokerlist 등록 정보에 지정된 목록에서 제외된 브로커를 제거합니다.

2. 클러스터에 남아 있는 각 브로커에 대해 다음 명령을 실행합니다.

   imqcmd reload cls

   이렇게 하면 브로커가 클러스터 구성을 다시 로드합니다.

3. 클러스터에서 제거할 브로커를 중지합니다.

4. 해당 브로커의 config.properties 파일을 편집하여 imq.cluster.url 등록 정보에 대한 값을 제거하거나 다른 값을 지정합니다.

마스터 브로커

각 클러스터는 클러스터의 지속성 상태에 대한 모든 변경을 추적하기 위해 구성 변경 기록을 관리하는 마스터 브로커 하나를 선택적으로 가질 수 있습니다. 마스터 브로커는 클러스터 구성 파일이나 개별 브로커의 인스턴스 구성 파일에 있는 imq.cluster.masterbroker 구성 등록 정보에서 식별됩니다.

구성 변경 기록에는 영구 가입, 관리자가 만든 물리적 대상 등과 같이 클러스터에 연결된 지속성 항목에 대한 변경 관련 정보가 포함되어 있습니다. 클러스터의 모든 브로커는 시작할 때 마스터 브로커를 참조하여 이러한 지속성 항목에 대한 정보를 업데이트합니다. 마스터 브로커에 오류가 발생하면 이러한 동기화가 불가능해집니다. 자세한 내용은 마스터 브로커를 사용할 수 없는 경우를 참조하십시오.

구성 변경 기록 관리

구성 변경 기록에는 중요한 정보가 포함되어 있으므로 오류가 발생할 경우 복원할 수 있도록 정기적으로 백업해야 합니다. 백업으로부터 복원하더라도 백업을 수행한 이후에 발생된 클러스터 지속성 상태의 변경 사항은 손실되지만 백업을 자주 수행하면 이러한 잠재적 정보 손실을 최소화할 수 있습니다. 백업 및 복원 작업을 수행하면 시간이 지나면 상당히 커질 수 있는, 구성 변경 레코드에 포함된 변경 기록을 압축하고 최적화할 수 있는 이점도 있습니다.

구성 변경 기록을 백업하는 방법

imqbrokerd 명령의 -backup 옵션을 사용하여 백업 파일의 이름을 지정합니다. 예:

imqbrokerd -backup mybackuplog

구성 변경 기록을 복원하는 방법

1. 클러스터에 있는 모든 브로커를 종료합니다.

2. 다음 명령을 사용하여 백업 파일로부터 마스터 브로커의 구성 변경 기록을 복원합니다.

   imqbrokerd -restore mybackuplog

3. 마스터 브로커에 새 이름이나 포트 번호를 할당하는 경우 클러스터 구성 파일에서 imq.cluster.brokerlist 및 imq.cluster.masterbroker 등록 정보를 각각 업데이트합니다.

4. 클러스터에 있는 모든 브로커를 다시 시작합니다.

마스터 브로커를 사용할 수 없는 경우

클러스터의 모든 브로커는 마스터 브로커가 있어야 지속성 작업을 수행할 수 있기 때문에 마스터 브로커를 사용할 수 없을 때 클러스터의 브로커에 대해 다음 imqcmd 하위 명령을 수행하면 오류가 반환됩니다.

• create dst

• destroy dst

• update dst

• destroy dur

자동 생성된 물리적 대상과 임시 대상에는 영향을 주지 않습니다.

마스터 브로커가 없는 경우 클라이언트 응용 프로그램이 영구 가입자를 만들거나 영구 가입을 취소하려고 시도하면 오류가 발생합니다. 하지만 클라이언트는 기존 영구 가입을 지정하여 상호 작용할 수 있습니다.

10장 브로커 모니터링

이 장에서는 브로커를 모니터하는 데 사용 가능한 도구와 메트릭 데이터를 가져오는 방법에 대해 설명합니다. 이 장은 다음 내용으로 구성되어 있습니다.

• 모니터링 도구 소개

• 브로커 로깅 구성 및 사용

• 메트릭을 대화식으로 표시

• 브로커를 모니터하는 응용 프로그램 작성

특정 메트릭에 대한 자세한 내용은 18 장, 메트릭 참조을 참조하십시오.

모니터링 도구 소개

Message Queue^TM 정보에 대한 모니터링 인터페이스에는 로그 파일, 대화식 명령 및 메트릭을 얻을 수 있는 클라이언트 API가 있습니다. 각 인터페이스는 다음과 같은 장점과 단점이 있습니다.

• 로그 파일은 장기간의 메트릭 데이터 기록을 제공하지만 구문 분석하기가 어렵습니다.

• 명령을 사용하면 요구에 맞는 정보를 빠르게 샘플링할 수 있지만 기록 정보를 살피거나 데이터를 프로그래밍 방식으로 조작할 수 없습니다.

• 클라이언트 API를 사용하면 정보 추출 및 처리, 데이터 조작, 그래프 표현, 경고 보내기 등을 할 수 있습니다. 하지만 클라이언트 API를 사용하려면 데이터를 캡처하고 분석하기 위한 사용자 정의 응용 프로그램을 작성해야 합니다.

표 10–1에서는 다른 도구들을 비교합니다.

표에 나와 있는 차이점 이외에 각 도구는 브로커가 생성한 메트릭 정보 중 약간씩 다른 하위 집합을 수집합니다. 각 모니터링 도구가 수집하는 메트릭 데이터에 대한 자세한 내용은 18 장, 메트릭 참조을 참조하십시오.

브로커 로깅 구성 및 사용

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

로거에서 수집된 정보의 유형과 각 출력 채널에 기록된 유형을 지정할 수 있습니다. 특히 메트릭 정보가 로그 파일에 기록되도록 지정할 수 있습니다.

이 절에서는 브로커의 기본 로깅 구성에 대해 설명하며, 로그 정보를 대체 출력 채널로 리디렉션하는 방법, 로그 파일 롤오버 기준 변경 방법 및 메트릭 데이터를 로그 파일로 보내는 방법을 설명합니다.

기본 로깅 구성

브로커는 로그 출력을 로그 파일 집합에 저장하도록 자동으로 구성됩니다. 로그 파일은 연결된 브로커 인스턴스의 이름으로 식별되는 디렉토리에 있습니다(부록 A, 플랫폼별 Message Queue^TM 데이터 위치 참조).

…/instances/instanceName/log

라이프사이클이 Application Server에 의해 제어되는 브로커의 경우 해당 브로커가 시작된 도메인에 대한 도메인 디렉토리의 하위 디렉토리에 로그 파일이 있습니다.

…/appServer_domainName_dir/imq/instances/imqbroker/log

로그 파일은 단순 텍스트 파일입니다. 이름은 다음과 같으며 이 순서대로 지정됩니다.

log.txt
log_1.txt
log_2.txt
…log_9.txt

기본적으로 로그 파일은 한 주에 한 번씩 롤오버되며 시스템에서는 9개의 백업 파일을 보존합니다.

• 로그 파일을 보존하는 디렉토리를 변경하려면 imq.log.file.dirpath 등록 정보를 원하는 경로로 설정합니다.

• 로그 파일의 기본 이름을 log가 아닌 다른 이름으로 변경하려면 imq.log.file.filename 등록 정보를 설정합니다.

브로커는ERROR, WARNING , INFO 등 세 가지 로그 수준을 지원합니다. 각 수준은 표 10–2에 설명되어 있습니다.

로깅 수준을 설정하면 해당 수준 이상의 메시지를 수집합니다. 기본 로그 수준은 INFO이므로 ERROR, WARNING 및 INFO 메시지가 기본적으로 모두 기록됩니다.

로그 메시지 형식

기록된 메시지는 타임스탬프, 메시지 코드, 메시지 자체로 이루어집니다. 정보의 양은 설정한 로그 수준에 따라 달라집니다. 다음은 INFO 메시지의 예입니다.

[13/Sep/2000:16:13:36 PDT] [B1004]: Starting the broker service using tcp 
[25374,100] with min threads 50 and max threads of 500

타임스탬프 표준 시간대를 변경하려면 표 14–8에 설명되어 있는 imq.log.timezone 등록 정보에 대한 정보를 참조하십시오.

로거 구성 변경

로그 관련 등록 정보에 대한 설명은 표 14–8에 나와 있습니다.

브로커의 로거 구성을 변경하는 방법

1. 로그 수준을 설정합니다.

2. 로깅 범주 하나 이상에 해당하는 출력 채널(파일, 콘솔, 또는 둘 다)을 설정합니다.

3. 출력을 파일에 기록하는 경우에는 파일의 롤오버 기준을 구성합니다.

   이 단계들은 로거 등록 정보를 설정하여 완료합니다. 이 작업은 두 방법 중 한 가지를 사용하여 수행할 수 있습니다.

   • 브로커를 시작하기 전에 브로커의 config.properties 파일에 있는 로거 등록 정보를 변경 또는 추가합니다.

   • 브로커를 시작하는 imqbrokerd 명령에서 로거 명령줄 옵션을 지정합니다. 브로커 옵션 -D를 사용하여 로거 등록 정보(또는 모든 브로커 등록 정보)를 변경할 수도 있습니다.

   명령줄에 전달되는 옵션은 브로커 인스턴스 구성 파일에서 지정한 등록 정보를 대체합니다. 로깅에 영향을 주는 imqbrokerd 옵션은 다음과 같습니다.

   -metrics interval

   브로커 메트릭 로깅 간격(초)

   -loglevel level

   로깅 수준(ERROR, WARNING, INFO 또는 NONE)

   -silent

   자동 모드(콘솔에 기록하지 않음)

   -tty

   모든 메시지를 콘솔에 기록

   다음 절에서는 기본 구성을 변경하여 다음을 수행하는 방법을 설명합니다.

   • 출력 채널(로그 메시지 대상) 변경

   • 롤오버 기준 변경

출력 채널 변경

기본적으로 오류 및 경고 메시지는 로그 파일에 기록될 뿐 아니라 터미널에도 표시됩니다. Solaris의 경우에는 오류 메시지가 시스템의 syslog 데몬에도 기록됩니다.

로그 메시지의 출력 채널은 다음과 같은 방법으로 변경할 수 있습니다.

• 모든 로그 범주(주어진 수준에서)의 출력이 화면에 표시되게 하려면 imqbrokerd 명령에 -tty 옵션을 사용합니다.

• 로그 출력이 화면에 표시되지 않게 하려면 imqbrokerd 명령에 -silent 옵션을 사용합니다.

• 로그 파일에 기록할 로깅 정보의 범주를 지정하려면 imq.log.file.output 등록 정보를 사용합니다. 예를 들면, 다음과 같습니다.

  imq.log.file.output=ERROR

• 콘솔에 기록할 로깅 정보의 범주를 지정하려면 imq.log.console.output 등록 정보를 사용합니다. 예를 들면, 다음과 같습니다.

  imq.log.console.output=INFO

• Solaris의 경우 Solaris syslog에 기록할 로깅 정보의 범주를 지정하려면 imq.log.syslog.output 등록 정보를 사용합니다. 예를 들면, 다음과 같습니다.

  imq.log.syslog.output=NONE

로거 출력 채널을 변경하기 전에 출력 채널에 매핑할 정보를 지원하는 수준으로 로깅을 설정해야 합니다. 예를 들어, 로그 수준을 ERROR로 설정하고 imq.log.console.output 등록 정보를 WARNING으로 설정한 경우에는 WARNING 메시지의 로깅을 활성화하지 않았기 때문에 메시지가 기록되지 않습니다.

로그 파일 롤오버 기준 변경

로그 파일의 롤오버 기준에는시간과 크기의 두 가지가 있습니다. 기본값은 시간 기준을 사용하고 7일마다 파일을 롤오버하는 것입니다.

• 시간 간격을 변경하려면 imq.log.file.rolloversecs 등록 정보를 변경해야 합니다. 예를 들어, 다음과 같은 등록 정보 정의를 사용하면 시간 간격을 10일로 변경할 수 있습니다.

  imq.log.file.rolloversecs=864000

• 롤오버 기준을 파일 크기로 변경하려면 imq.log.file.rolloverbytes 등록 정보를 설정해야 합니다. 예를 들어, 다음 정의는 500,000바이트 제한에 도달하면 파일을 롤오버하도록 브로커를 설정합니다.

  imq.log.file.rolloverbytes=500000

시간 및 크기 관련 롤오버 등록 정보를 모두 설정한 경우에는 먼저 도달한 제한에 의해 롤오버가 발생합니다. 앞에서 설명했듯이 브로커는 아홉 개까지의 롤오버 파일을 보존합니다.

브로커가 실행되고 있을 때 로그 파일 롤오버 등록 정보를 설정 또는 변경할 수 있습니다. 이러한 등록 정보를 설정하려면 imqcmd update bkr 명령을 사용합니다.

로그 파일로 메트릭 데이터 보내기

이 절에서는 브로커 로그 파일을 사용하여 메트릭 정보를 보고하는 절차를 설명합니다. 로거 구성에 대한 자세한 내용은 브로커 로깅 구성 및 사용을 참조하십시오.

로그 파일을 사용하여 메트릭 정보를 보고하는 방법

1. 브로커의 메트릭 생성 기능을 구성합니다.

   1. imq.metrics.enabled=true인지 확인합니다.

      로깅을 위한 메트릭 생성은 기본적으로 설정되어 있습니다.

   2. 메트릭 생성 간격을 원하는 시간(초)으로 설정합니다.

      imq.metrics.interval=interval

      이 값은 config.properties 파일에서 설정하거나 브로커를 시작할 때 -metrics interval 명령줄 옵션을 사용하여 설정할 수 있습니다.

2. 로거가 메트릭 정보를 수집하는지 확인합니다.

   imq.log.level=INFO

   기본값입니다. 이 값은 config.properties 파일에서 설정하거나 브로커를 시작할 때 -loglevel level 명령줄 옵션을 사용하여 설정할 수 있습니다.

3. 로거가 메트릭 정보를 로그 파일에 기록하도록 설정되어 있는지 확인합니다.

   imq.log.file.output=INFO

   기본값입니다. 이 값은 config.properties 파일에서 설정할 수 있습니다.

4. 브로커를 시작합니다.

   다음에는 로그 파일로의 샘플 브로커 메트릭 출력이 나와 있습니다.

   [21/Jul/2004:11:21:18 PDT] Connections: 0 JVM Heap: 8323072 bytes (7226576 free) Threads: 0 (14-1010) In: 0 msgs (0bytes) 0 pkts (0 bytes) Out: 0 msgs (0bytes) 0 pkts (0 bytes) Rate In: 0 msgs/sec (0 bytes/sec) 0 pkts/sec (0 bytes/sec) Rate Out: 0 msgs/sec (0 bytes/sec) 0 pkts/sec (0 bytes/sec)

   메트릭 데이터에 대한 자세한 내용은 18 장, 메트릭 참조을 참조하십시오.

사용 불능 메시지 기록

브로커에 대한 사용 불능 메시지 로깅을 사용하여 물리적 대상을 모니터할 수 있습니다. 사용 불능 메시지 대기열을 사용하는지 여부에 관계 없이 사용 불능 메시지를 기록할 수 있습니다.

사용 불능 메시지 로깅을 사용하는 경우 브로커는 다음과 같은 이벤트 유형을 기록합니다.

• 물리적 대상이 최대 크기를 초과했습니다.

• 브로커가 다음과 같은 이유로 물리적 대상에서 메시지를 제거했습니다.

  • 대상 크기 제한에 도달했습니다.

  • 메시지 활성 시간이 만료되었습니다.

  • 메시지가 너무 큽니다.

  • 브로커가 메시지를 처리하는 중에 오류가 발생했습니다.

사용 불능 메시지 대기열을 사용하는 경우 다음과 같은 이벤트 유형도 로깅에 포함됩니다.

• 브로커가 메시지를 사용 불능 메시지 대기열로 이동했습니다.

• 브로커가 메시지를 사용 불능 메시지 대기열에서 제거하여 삭제했습니다.

다음은 사용 불능 메시지에 대한 로그 형식의 예입니다.

[29/Mar/2006:15:35:39 PST] [B1147]: Message 8-129.145.180.87(e7:6b:dd:5d:98:aa)-
35251-1143675279400 from destination Q:q0 has been placed on the DMQ because 
[B0053]: Message on destination Q:q0 Expired: expiration time 1143675279402, 
arrival time 1143675279401, JMSTimestamp 1143675279400

사용 불능 메시지 로깅은 기본적으로 비활성화됩니다. 사용 불능 메시지 로깅을 사용하려면 imq.destination.logDeadMsgs 브로커 속성을 설정합니다.

메트릭을 대화식으로 표시

Message Queue 브로커는 다음과 같은 이벤트 유형을 보고할 수 있습니다.

• JVM(Java 가상 머신) 메트릭. JVM 힙 크기에 대한 정보.

• 브로커 전체 메트릭. 브로커에 저장되어 있는 메시지, 브로커에 유입 및 유출되는 메시지, 메모리 사용 등에 대한 정보. 메시지는 메시지 수와 바이트 수라는 측면에서 추적됩니다.

• 연결 서비스 메트릭. 연결 및 연결 스레드 자원에 대한 정보 및 특정 연결 서비스의 메시지 흐름에 대한 정보.

• 대상 메트릭. 특정 물리적 대상에 유입 및 유출되는 메시지 정보, 물리적 대상 사용자에 대한 정보, 메모리 및 디스크 공간 사용에 대한 정보.

imqcmd 명령은 브로커 전체, 개별 연결 서비스 및 개별 물리적 대상에 대한 메트릭 정보를 얻을 수 있습니다. 메트릭 데이터를 얻으려면 일반적으로 imqcmd의 metrics 하위 명령을 사용합니다. 메트릭 데이터는 지정한 간격이나 지정한 횟수에 콘솔 화면에 기록됩니다.

query 하위 명령을 사용하여 구성 정보를 포함하는 유사한 데이터를 볼 수도 있습니다. 자세한 내용은 imqcmd query를 참조하십시오.

imqcmd metrics

imqcmd metrics의 구문과 옵션은 각각 표 10–3 및 표 10–4에 나타나 있습니다.

metrics bkr
   [-b hostName:portNumber]
   [-m metricType]
   [-int interval]
   [-msp numSamples]

metrics svc -n serviceName
   [-b hostName:portNumber]
   [-m metricType]
   [-int interval]
   [-msp numSamples]

metrics dst -t destType
   -n destName
   [-b hostName:portNumber]
   [-m metricType]
   [-int interval]
   [-msp numSamples]

-b hostName: portNumber

-int interval

-m metricType

-msp numSamples

-n destName

-n serviceName

-t destType

메트릭 하위 명령을 사용하여 메트릭 데이터 표시

이 절에서는 metrics 하위 명령을 사용하여 메트릭 정보를 보고하는 절차를 설명합니다.

메트릭 하위 명령을 사용하는 방법

1. 메트릭 정보가 필요한 브로커를 시작합니다.

   브로커 시작을 참조하십시오.

2. 표 10–3과 표 10–4에 표시된 대로 적절한 imqcmd metrics 하위 명령과 옵션을 실행합니다.

메트릭 출력: imqcmd metrics

이 절에서는 imqcmd metrics 하위 명령의 출력 예를 보여줍니다. 예로는 브로커 전체, 연결 서비스 및 물리적 대상 메트릭이 나와 있습니다.

브로커 전체 메트릭

메시지와 패킷이 브로커에 유입 및 유출되는 속도를 10초 간격으로 구하려면 다음과 같이 metrics bkr 하위 명령을 사용합니다.

imqcmd metrics bkr -m rts -int 10 -u admin

이 명령은 다음과 유사한 결과를 출력합니다(표 18–2의 데이터 설명 참조).

--------------------------------------------------------
 Msgs/sec   Msg Bytes/sec   Pkts/sec    Pkt Bytes/sec   
 In   Out     In      Out     In   Out     In      Out  
--------------------------------------------------------
 0     0      27      56      0     0      38      66   
 10    0     7365     56      10    10    7457    1132  
 0     0      27      56      0     0      38      73   
 0     10     27     7402     10    20    1400    8459  
 0     0      27      56      0     0      38      73   

연결 서비스 메트릭

jms 연결 서비스가 처리한 메시지와 패킷의 누적 총 수를 구하려면 다음과 같이 metrics svc 하위 명령을 사용합니다.

imqcmd metrics svc -n jms -m ttl -u admin

이 명령은 다음과 유사한 결과를 출력합니다(표 18–3의 데이터 설명 참조).

-------------------------------------------------
  Msgs      Msg Bytes      Pkts      Pkt Bytes     
In   Out    In     Out   In   Out    In     Out  
-------------------------------------------------
164  100  120704  73600  282  383  135967  102127
657  100  483552  73600  775  876  498815  149948

물리적 대상 메트릭

물리적 대상에 대한 메트릭 정보를 얻으려면 다음과 같이 metrics dst 하위 명령을 사용하십시오.

imqcmd metrics dst -t q -n XQueue -m ttl -u admin

이 명령은 다음과 유사한 결과를 출력합니다(표 18–4의 데이터 설명 참조).

-----------------------------------------------------------------------------
  Msgs      Msg Bytes         Msg Count         Total Msg Bytes (k)     Largest
In   Out    In     Out    Current  Peak  Avg  Current  Peak     Avg    Msg (k)
-----------------------------------------------------------------------------
200  200  147200  147200     0     200    0      0      143      71        0  
300  200  220800  147200    100    200   10     71      143      64        0  
300  300  220800  220800     0     200    0      0      143      59        0  

물리적 대상의 사용자에 대한 정보를 얻으려면 다음과 같이 metrics dst 하위 명령을 사용합니다.

imqcmd metrics dst -t q -n SimpleQueue -m con -u admin

이 명령은 다음과 유사한 결과를 출력합니다(표 18–4의 데이터 설명 참조).

------------------------------------------------------------------
  Active Consumers         Backup Consumers         Msg Count
Current  Peak  Avg      Current  Peak    Avg    Current  Peak  Avg
------------------------------------------------------------------
   1       1      0        0       0      0       944    1000  525

imqcmd query

imqcmd query의 구문과 옵션은 이 명령이 제공하는 메트릭 데이터에 대한 설명과 함께 표 10–5에 나와 있습니다.

query bkr
   [-b hostName: portNumber]

query svc -n serviceName
  [-b  hostName:portNumber]

query dst -t destType
  -n destName
  [-b hostName:portNumber]

imqcmd query에서 제공하는 메트릭 데이터는 제한되어 있기 때문에 이 도구는 18 장, 메트릭 참조에 제시된 표에 설명되어 있지 않습니다.

브로커를 모니터하는 응용 프로그램 작성

Message Queue는 브로커가 메트릭 데이터를 JMS 메시지에 기록한 다음 메시지에 포함된 메트릭 정보 유형에 따라 여러 메트릭 주제 대상 중 하나에 보낼 수 있는 메트릭 모니터링 기능을 제공합니다.

메트릭 주제 대상에 가입하고 이러한 대상에서 메시지를 사용하며 메시지에 포함된 메트릭 정보를 처리하는 클라이언트 응용 프로그램을 작성하여 이러한 메트릭 정보에 액세스할 수 있습니다.

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

메시지 기반 모니터링 설정

이 절에서는 메시지 기반 모니터링 기능을 사용하여 메트릭 정보를 수집하는 절차를 설명합니다. 이 절차는 클라이언트 개발과 관리 작업을 모두 포함합니다.

메시지 기반 모니터링을 설정하는 방법

1. 메트릭 모니터링 클라이언트를 작성합니다.

   메트릭 주제 대상에 가입하고 메트릭 메시지를 사용하며 이러한 메시지에서 메트릭 데이터를 추출하는 클라이언트를 프로그래밍하는 데 대한 지침은 Java 클라이언트용 Message Queue 개발 안내서를 참조하십시오.

2. config.properties 파일에서 브로커 등록 정보 값을 설정하여 브로커의 메트릭 메시지 생성자를 구성합니다.

   1. 메트릭 메시지 생성을 활성화합니다.

      imq.metrics.topic.enabled=true를 설정합니다.

      기본값은 true입니다.

   2. 메트릭 메시지가 생성되는 간격(초)을 설정합니다.

      imq.metrics.topic.interval=interval을 설정합니다.

      기본값은 60초입니다.

   3. 메트릭 메시지가 지속되는지(즉, 브로커에 오류가 발생해도 메시지가 보존되는지) 여부를 지정합니다.

      imq.metrics.topic.persist를 설정합니다.

      기본값은 false입니다.

   4. 메트릭 메시지가 삭제되기 전까지 해당 대상에 남아 있는 기간을 지정합니다.

      imq.metrics.topic.timetolive를 설정합니다.

      기본값은 300초입니다.

3. 메트릭 주제 대상에 대한 액세스 제어가 필요한 경우 설정합니다.

   아래의 보안 및 액세스 고려 사항에 있는 설명을 참조하십시오.

4. 메트릭 모니터링 클라이언트를 시작합니다.

   사용자가 메트릭 주제에 가입하면 메트릭 주제 대상이 자동으로 만들어집니다. 메트릭 주제가 만들어지면 브로커 메트릭 메시지 생성자가 메트릭 메시지를 메트릭 주제로 보내기 시작합니다.

보안 및 액세스 고려 사항

메트릭 주제 대상에 대한 액세스를 제한하는 이유는 두 가지입니다.

• 메트릭 데이터에는 브로커와 그 자원에 대한 중요한 정보가 포함되어 있을 수 있습니다.

• 메트릭 주제 대상에 대한 가입 수가 과도한 경우 브로커 오버헤드가 늘어나고 성능에 부정적인 영향을 미칠 수 있습니다.

이러한 사항을 고려할 때 메트릭 주제 대상에 대한 액세스를 제한하는 것이 좋습니다.

모니터링 클라이언트는 다른 클라이언트와 같은 인증 및 권한 부여 제어를 받습니다. Message Queue 사용자 저장소에서 유지 관리되는 사용자만 브로커에 연결할 수 있습니다.

사용자 권한 부여: 액세스 제어 등록 정보 파일에 설명되어 있는 액세스 제어 등록 정보 파일을 통해 특정 메트릭 주제 대상에 대한 액세스를 제한하여 추가 보호를 제공할 수 있습니다.

예를 들어, accesscontrol.properties 파일의 다음 항목은 user1과 user2를 제외한 모든 사람에 대해 mq.metrics.broker 메트릭 주제에 대한 액세스를 거부합니다.

topic.mq.metrics.broker.consume.deny.user=*
topic.mq.metrics.broker.consume.allow.user=user1,user2

다음 항목은 사용자 user3만 주제 t1을 모니터할 수 있도록 합니다.

topic.mq.metrics.destination.topic.t1.consume.deny.user=*
topic.mq.metrics.destination.topic.t1.consume.allow.user=user3

메트릭 데이터의 중요도에 따라 암호화된 연결을 사용하여 메트릭 모니터링 클라이언트를 브로커에 연결할 수도 있습니다. 암호화된 연결 사용에 대한 자세한 내용은 메시지 암호화를 참조하십시오.

메트릭 출력: 메트릭 메시지

메시지 기반 모니터링 API를 사용하여 얻는 메트릭 데이터 출력은 사용자가 어떤 메트릭 모니터링 클라이언트를 작성하는지에 따라 다릅니다. 단지 브로커의 메트릭 생성기에서 어떤 데이터를 제공하는지에 따라 제한을 받습니다. 이 데이터의 전체 목록을 보려면 18 장, 메트릭 참조을 참조하십시오.

11장 메시지 서비스 분석 및 조정

이 장에서는 메시징 응용 프로그램의 성능을 최적화하기 위해 Message Queue^TM 서비스를 분석하고 조정하는 방법에 대한 여러 항목을 다룹니다. 이 장은 다음 항목으로 구성되어 있습니다.

• 성능 정보

• 성능에 영향을 미치는 요소

• 성능 향상을 위한 구성 조정

성능 정보

이 절에서는 성능 조정에 대한 배경 정보를 제공합니다.

성능 조정 프로세스

메시징 응용 프로그램의 성능은 응용 프로그램과 Message Queue 서비스 사이의 상호 작용에 따라 달라집니다. 따라서 성능을 최대화하려면 응용 프로그램 개발자와 관리자가 함께 노력해야 합니다.

성능 최적화 프로세스는 응용 프로그램 설계에서 시작되어 응용 프로그램을 배포 이후 메시지 서비스 조정에 이르기까지 계속됩니다. 성능 조정 프로세스에는 다음 단계가 포함됩니다.

• 응용 프로그램의 성능 요구 사항 정의

• 성능에 영향을 미치는 요소(특히 안정성과 성능 간의 균형)를 고려하여 응용 프로그램 설계

• 기본 성능 측정 설정

• 성능 최적화를 위해 메시지 서비스 조정 또는 재구성

위에서 설명한 프로세스는 자주 반복됩니다. 응용 프로그램 배포 중에 Message Queue 관리자는 메시지 서비스가 응용 프로그램의 일반 성능 요구 사항에 적합한지 평가합니다. 벤치마크 테스트가 이러한 요구 사항을 충족시키는 경우 관리자는 이 장에서 설명한 대로 시스템을 조정할 수 있습니다. 하지만 벤치마크 테스트가 성능 요구 사항을 충족시키지 못하는 경우 응용 프로그램을 재설계하거나 배포 구조를 수정해야 합니다.

성능 요소

일반적으로 성능은 메시지 서비스가 생성자의 메시지를 사용자에게 전달하는 속도와 효율성에 대한 측정입니다. 하지만 사용자의 필요에 따라 중요할 수 있는 여러 다른 성능 요소가 있습니다.

연결 로드

메시지 생성자나 메시지 사용자 수 또는 시스템이 지원할 수 있는 동시 연결 수입니다.

메시지 처리량

메시징 시스템을 통해 전달될 수 있는 초당 메시지 수 또는 메시지 바이트입니다.

대기 시간

메시지 생성자로부터 메시지 사용자에게 특정 메시지를 전달하는 데 걸리는 시간입니다.

안정성

메시지 서비스의 전체적인 가용성 또는 로드량이 많거나 장애가 발생하는 경우 메시지 서비스 성능이 유연하게 감소되는 정도입니다.

효율성

메시지 전달의 효율성, 즉 사용된 컴퓨팅 자원을 기준으로 메시지 처리량을 측정한 것입니다.

이러한 성능의 여러 요소들은 일반적으로 상호 연관됩니다. 메시지 처리량이 높으면 메시지가 브로커에서 백로그될 가능성이 적어지므로 대기 시간이 짧아집니다(단일 메시지가 매우 빠르게 전달될 수 있음). 하지만 대기 시간은 통신 연결 속도, 브로커 처리 속도, 클라이언트 처리 속도 등 많은 요소에 따라 달라질 수 있습니다.

어느 경우든 여러 다른 성능 요소가 있습니다. 어떤 성능 요소가 가장 중요한지는 일반적으로 특정 응용 프로그램의 요구 사항에 따라 달라집니다.

벤치마크

벤치마크는 메시징 응용 프로그램을 위한 테스트 프로그램을 만들고 이 테스트 프로그램의 메시지 처리량이나 기타 성능 요소를 측정하는 프로세스입니다.

예를 들어, 일정 수의 생성자 클라이언트가 일정 수의 연결, 세션 및 메시지 생성자를 사용하여 메시징 응용 프로그램 설계에 따라 다른 특정 수의 대기열이나 주제에 표준 크기의 지속성 또는 비지속성 메시지를 지정된 속도로 보내는 테스트 프로그램을 만들 수 있습니다. 마찬가지로 테스트 프로그램에는 일정 수의 연결, 세션 및 특정 확인 모드로 테스트 프로그램 물리적 대상에서 메시지를 사용하는 특정 유형의 메시지 사용자를 사용하는 일정 수의 사용자 클라이언트가 포함됩니다.

표준 테스트 프로그램을 사용하면 메시지 생성에서 사용까지 걸리는 시간이나 평균 메시지 처리 속도를 측정할 수 있으며 시스템을 모니터하여 연결 스레드 사용, 메시지 저장소 데이터, 메시지 흐름 데이터 및 기타 관련 메트릭을 살펴볼 수 있습니다. 그런 다음 성능에 부정적인 영향을 미칠 때까지 메시지 생성 속도, 메시지 생성자 수 또는 기타 변수를 증가시켜볼 수 있습니다. 달성할 수 있는 최대 처리량이 메시지 서비스 구성에 대한 벤치마크입니다.

이 벤치마크를 사용하여 테스트 프로그램의 일부 특성을 수정할 수 있습니다. 성능에 영향을 미칠 수 있는 모든 요소( 성능에 영향을 미치는 응용 프로그램 설계 요소 참조)를 조심스럽게 제어하여 이러한 요소들 중 일부를 변경했을 때 벤치마크에 미치는 영향을 살펴볼 수 있습니다. 예를 들어, 연결 수나 메시지 크기를 5배나 10배 증가시켜 성능에 미치는 영향을 살펴볼 수 있습니다.

이와 반대로 응용 프로그램 기반 요소를 일정하게 유지하면서 제어 가능한 방식으로 브로커 구성을 변경하고(예: 연결 등록 정보, 스레드 풀 등록 정보, JVM 메모리 제한, 제한 동작, 파일 기반 지속성 대 JDBC 기반 지속성 등을 변경) 이러한 변경이 성능에 미치는 영향을 살펴볼 수 있습니다.

이러한 응용 프로그램 벤치마크는 메시지 서비스를 조정하여 배포된 응용 프로그램의 성능을 높이고자 할 때 유용한 정보를 제공합니다. 벤치마크를 사용하면 한 가지 변경 사항이나 일련의 변경 사항이 미치는 영향을 좀 더 정확하게 예상할 수 있습니다.

일반적으로 벤치마크는 제어된 테스트 환경에서 메시지 서비스가 안정될 정도의 충분한 기간 동안 실행해야 합니다. Java 코드를 기계 코드로 변환하는 JIT(Just-In-Time) 컴파일 과정은 시작 시 성능에 부정적인 영향을 미칩니다.

기본 사용 패턴

일단 메시징 응용 프로그램이 배포되어 실행 중이면 기본 사용 패턴을 설정하는 것이 중요합니다. 최대 수요가 발생하는 시기를 알아 해당 수요를 수량화할 수 있습니다. 예를 들어, 수요는 일반적으로 최종 사용자 수, 활동 수준, 시간 또는 이러한 모든 요소에 의해 변동됩니다.

기본 사용 패턴을 설정하려면 메시지 서비스를 오랫동안 모니터하여 다음과 같은 데이터를 조사해야 합니다.

• 연결 수

• 브로커 또는 특정 물리적 대상에 저장된 메시지 수

• 브로커 또는 특정 물리적 대상에 유입 및 유출되는 메시지

• 활성 사용자 수

메트릭 데이터에서 제공하는 평균 값과 최대 값을 사용할 수도 있습니다.

이러한 기본 메트릭을 설계 예측과 비교하여 확인하는 것이 중요합니다. 이렇게 함으로써 클라이언트 코드가 제대로 작동하는지 확인할 수 있습니다. 예를 들어, 연결이 열려 있는 상태로 남아 있지 않은지 또는 사용된 메시지가 인식할 수 없는 상태로 남아 있지 않은지 확인할 수 있습니다. 이러한 코딩 오류는 브로커 자원을 사용하므로 성능에 상당한 영향을 미칠 수 있습니다.

기본 사용 패턴을 통해 최적 성능을 위해 시스템을 조정하는 방법을 결정할 수 있습니다. 예를 들면 다음과 같습니다.

• 한 물리적 대상이 다른 물리적 대상에 비해 훨씬 더 많이 사용되는 경우 해당 물리적 대상에 다른 물리적 대상보다 더 높은 메시지 메모리 제한을 설정하거나 상황에 맞게 제한 동작을 조정할 수 있습니다.

• 필요한 연결 수가 최대 스레드 풀 크기에서 허용하는 연결 수보다 훨씬 더 큰 경우 스레드 풀 크기를 늘리거나 공유 스레드 모델을 적용할 수 있습니다.

• 최대 메시지 흐름이 평균 흐름보다 훨씬 큰 경우 메모리가 부족할 때 사용하는 제한 동작에 영향을 미칠 수 있습니다.

일반적으로 사용 패턴에 대해 더 많이 알수록 이러한 패턴에 맞춰 시스템을 조정하고 향후 요구에 더 잘 대비할 수 있습니다.

성능에 영향을 미치는 요소

두 가지 주요 성능 표시기인 메시지 대기 시간과 메시지 처리량은 일반 메시지가 메시지 전달 프로세스의 여러 단계를 완료하는 데 걸리는 시간에 따라 달라집니다. 아래는 안정적으로 전달되는 지속성 메시지인 경우에 대해 이러한 단계를 보여 줍니다. 단계는 다음 그림과 같습니다.

그림 11–1 Message Queue 서비스를 통한 메시지 전달

메시지 전달 단계

1. 메시지가 생성자 클라이언트에서 브로커로 전달됩니다.

2. 브로커가 메시지를 읽습니다.

3. 안정성을 위해 메시지가 영구 저장소에 저장됩니다.

4. 안정성을 위해 브로커가 메시지 수신을 확인합니다.

5. 브로커가 메시지 경로 지정을 결정합니다.

6. 브로커가 메시지를 씁니다.

7. 메시지가 브로커에서 사용자 클라이언트로 전달됩니다.

8. 안정성을 위해 사용자 클라이언트가 메시지 수신을 확인합니다.

9. 안정성을 위해 브로커가 클라이언트 확인을 처리합니다.

10. 브로커가 클라이언트 확인이 처리되었는지 확인합니다.

    이러한 단계는 순차적이므로 어느 단계든 생성자 클라이언트에서 사용자 클라이언트로 메시지를 전달할 때 병목 현상을 일으킬 수 있습니다. 이러한 단계들은 대부분 네트워크 대역폭, 컴퓨터 처리 속도, 메시지 서비스 구조 등 메시징 시스템의 물리적 특성에 영향을 받습니다. 하지만 일부 단계는 메시징 응용 프로그램의 특성과 메시징 응용 프로그램이 요구하는 안정성 수준에 따라서도 달라집니다.

    다음 하위 절에서는 응용 프로그램 설계 요소와 메시징 시스템 요소가 성능에 미치는 영향을 설명합니다. 응용 프로그램 설계와 메시징 시스템 요소가 메시지 전달에서 긴밀하게 상호 작용하지만 각 범주에 대해 별도로 고려합니다.

성능에 영향을 미치는 응용 프로그램 설계 요소

응용 프로그램 설계 결정은 전체 메시징 성능에 상당한 영향을 미칠 수 있습니다.

성능에 영향을 미치는 가장 중요한 요소는 메시지 전달의 안전성에 영향을 미치는 요소입니다. 이러한 요소는 다음과 같습니다.

• 전달 모드(지속성/비지속성 메시지)

• 트랜잭션 사용

• 확인 모드

• 영구 및 비영구 가입

성능에 영향을 미치는 다른 응용 프로그램 설계 요소는 다음과 같습니다.

• 선택기 사용(메시지 필터링)

• 메시지 크기

• 메시지 본문 유형

다음 절에서는 이러한 요소 각각이 메시징 성능에 미치는 영향을 설명합니다. 일반적으로 성능과 안정성은 동시에 얻을 수 없습니다. 즉, 안정성을 높이는 요소가 성능을 저하시키는 경향이 있습니다.

표 11–1은 여러 응용 프로그램 설계 요소가 일반적으로 메시징 성능에 어떤 영향을 미치는지 보여 줍니다. 이 표에서는 두 가지 시나리오(높은 안정성/낮은 성능 시나리오와 높은 성능/낮은 안정성 시나리오)와 각각을 특징 지우는 응용 프로그램 설계 요소의 선택을 보여 줍니다. 이러한 양극단 사이에는 안정성과 성능 모두에 영향을 미치는 여러 선택 사항과 상충이 있습니다.

전달 모드(지속성/비지속성 메시지)

지속성 메시지는 브로커에 오류가 발생하는 경우 메시지 전달을 보장합니다. 브로커는 의도된 모든 사용자가 메시지 사용을 확인할 때까지 메시지를 영구 저장소에 저장합니다.

다음과 같은 이유로 브로커의 지속성 메시지 처리가 비지속성 메시지 처리보다 느립니다.

• 브로커는 브로커에 오류가 발생하더라도 지속성 메시지가 손실되지 않도록 안정적으로 메시지를 저장해야 합니다.

• 브로커는 수신되는 각 지속성 메시지의 수신을 확인해야 합니다. 메시지를 생성하는 메소드가 예외 없이 반환되면 브로커로의 전달이 보장됩니다.

• 클라이언트 확인 모드에 따라 브로커는 지속성 메시지를 사용자 클라이언트가 확인했는지 확인해야 할 수 있습니다.

영구 가입자가 있는 대기열과 주제는 비영구 메시지에 비해 속도가 약 40% 향상되었습니다. 이는 10k 크기 메시지와 AUTO_ACKNOWLEDGE 모드에서 생성된 결과입니다.

트랜잭션 사용

트랜잭션은 트랜잭션된 세션에서 생성된 모든 메시지와 트랜잭션된 세션에서 사용된 모든 메시지가 하나의 단위로 처리되거나 처리되지 않도록(롤백되도록) 보장합니다.

Message Queue는 로컬 트랜잭션과 분산 트랜잭션을 모두 지원합니다.

트랜잭션된 세션에서의 메시지 생성이나 확인은 다음과 같은 이유 때문에 트랜잭션되지 않은 세션보다 느립니다.

• 생성된 각 메시지와 함께 추가 정보를 저장해야 합니다.

• 가입이 없는 주제 대상에 전달되는 지속성 메시지는 일반적으로 삭제되지만 트랜잭션이 시작될 때 가입에 대한 정보를 사용할 수 없는 경우와 같이 일반적으론 그럴 수 없는데도 트랜잭션의 메시지가 저장되는 경우가 있습니다..

• 트랜잭션이 완료될 때 트랜잭션 내의 메시지 사용과 확인에 대한 정보를 저장하고 처리해야 합니다.

확인 모드

JMS 메시지 전달의 안정성을 보장하는 한 가지 방법은 Message Queue 브로커가 클라이언트에 전달한 메시지 사용에 대해 클라이언트가 확인 응답을 보내는 것입니다.

클라이언트의 메시지 확인 없이 세션이 닫히거나 확인이 처리되기 전에 브로커에 오류가 발생하는 경우 브로커는 해당 메시지를 재전송하여 JMSRedelivered 플래그를 설정합니다.

트랜잭션되지 않은 세션의 경우 클라이언트는 각각 고유한 성능 특성을 가지는 다음과 같은 세 가지 확인 모드 중 하나를 선택할 수 있습니다.

• AUTO_ACKNOWLEDGE. 사용자가 메시지를 처리하면 시스템이 자동으로 메시지를 확인합니다. 이 모드는 공급자 오류 후 최대 한 개의 재전송 메시지를 보장합니다.

• CLIENT_ACKNOWLEDGE. 응용 프로그램이 메시지가 확인되는 시점을 제어합니다. 이전 확인 이후 해당 세션에서 처리된 모든 메시지가 확인됩니다. 일련의 확인을 처리하는 동안 브로커가 실패하는 경우 해당 그룹에서 하나 이상의 메시지가 재전송될 수 있습니다.

• DUPS_OK_ACKNOWLEDGE. 이 모드는 시스템에게 메시지를 느리게 확인하도록 명령합니다. 공급자 오류 후 여러 메시지가 재전송될 수 있습니다.

(CLIENT_ACKNOWLEDGE 모드를 사용하는 것은 처리 중에 공급자 오류가 발생하는 경우 모든 확인이 함께 처리되도록 보장하지 않는다는 점을 제외하고는 트랜잭션 사용과 유사합니다.)

확인 모드는 다음과 같은 이유로 성능에 영향을 미칩니다.

• AUTO_ACKNOWLEDGE 및 CLIENT_ACKNOWLEDGE 모드에서는 브로커와 클라이언트 사이에 추가 제어 메시지가 필요합니다. 추가 제어 메시지는 처리 오버헤드를 추가하고 JMS 페이로드 메시지를 방해할 수 있으므로 처리가 지연됩니다.

• AUTO_ACKNOWLEDGE 및 CLIENT_ACKNOWLEDGE 모드에서는 클라이언트가 추가 메시지를 사용할 수 있으려면 브로커가 클라이언트 확인을 처리했다고 확인할 때까지 대기해야 합니다. (이와 같은 브로커 확인은 브로커가 실수로 이 메시지를 재전송하지 않도록 보장합니다.)

• 사용자가 받은 모든 지속성 메시지에 대한 확인 정보로 Message Queue 영구 저장소를 업데이트해야 하므로 성능이 감소됩니다.

영구 및 비영구 가입

주제 대상의 가입자는 영구 가입자와 비영구 가입자의 두 가지 범주로 구분됩니다.

영구 가입은 다음과 같은 이유로 안정성이 향상되지만 처리량이 떨어집니다.

• Message Queue 메시지 서비스는 브로커에 오류가 발생하더라도 복구 후 목록을 사용할 수 있도록 각 영구 가입에 할당된 메시지 목록을 영구 저장해야 합니다.

• 브로커에 오류가 발생하더라도 복구 후 해당 사용자가 활성화되면 메시지를 계속 전달할 수 있도록 영구 가입의 지속성 메시지가 영구적으로 저장됩니다. 반면 비영구 가입의 지속성 메시지는 영구 저장되지 않습니다. 브로커에 오류가 발생하는 경우 해당 사용자 연결이 끊기며 메시지가 전달되지 않습니다.

지속성 및 비지속성 10k 크기 메시지의 두 경우에 대한 영구 가입자와 비영구 가입자의 성능을 비교했습니다. 두 가지 경우 모두 AUTO_ACKNOWLEDGE 확인 모드를 사용합니다. 지속성 메시지의 경우에만 약 30%의 성능 감소 효과가 있음을 확인했습니다.

선택기 사용(메시지 필터링)

응용 프로그램 개발자가 특정 사용자들을 메시지 집합의 대상으로 지정할 수 있습니다. 이는 메시지 집합마다 고유 물리적 대상을 지정하거나 단일 물리적 대상을 사용하여 각 사용자에 대해 하나 이상의 선택기를 등록하여 수행할 수 있습니다.

선택기는 해당 문자열과 일치하는 등록 정보 값을 갖는 메시지만 특정 사용자에게 전달되도록 요청하는 문자열입니다. 예를 들어 선택기 NumberOfOrders >1은 NumberOfOrders 등록 정보 값이 2이상인 메시지만 전달합니다.

선택기를 사용하여 사용자를 생성하면 각 메시지를 처리하는 데 추가 처리가 필요하므로 여러 물리적 대상을 사용하는 것에 비해 성능이 떨어집니다. 선택기를 사용하는 경우 선택기가 이후의 메시지와 일치될 수 있도록 구문 분석되어야 합니다. 또한 각 메시지가 라우팅될 때 각 메시지의 메시지 등록 정보를 검색하고 선택기와 비교해야 합니다. 그러나 선택기를 사용하면 메시징 응용 프로그램의 융통성이 증가합니다.

메시지 크기

생성자 클라이언트에서 브로커로 그리고 브로커에서 사용자 클라이언트로 더 많은 데이터가 전달되어야 하고 지속성 메시지의 경우 더 큰 메시지를 저장해야 하므로 메시지 크기는 성능에 영향을 미칩니다.

그러나 작은 메시지들을 단일 메시지로 일괄 처리하면 개별 메시지의 라우팅과 처리를 최소화하여 전체적 성능 향상을 제공할 수 있습니다. 이 경우 개별 메시지의 상태에 대한 정보는 손실됩니다.

AUTO_ACKNOWLEDGE 확인 모드에서 대기열 대상에 1k, 10k 및 100k 크기의 메시지를 전달할 때의 초당 처리량 비교 테스트에서, 비영구 메시지의 경우 1k 메시지는 약 50%, 10k 메시지는 약 20%, 100k 메시지는 약 5% 더 빨라졌습니다. 메시지 크기는 영구 메시지와 비영구 메시지 모두에서 성능에 큰 영향을 미쳤습니다. 100k 메시지는 10k 메시지보다 약 10배 더 빠르지만, 10k 메시지는 1k 메시지보다 약 5배 더 빠릅니다.

메시지 본문 유형

JMS는 복잡성 순서에 따라 아래에 대략적으로 표시된 다섯 개의 메시지 본문 유형을 지원합니다.

• BytesMessage는 응용 프로그램에서 지정하는 형식의 바이트 집합을 포함합니다.

• TextMessage는 간단한 Java 문자열입니다.

• StreamMessage는 Java 프리미티브 값의 스트림을 포함합니다.

• MapMessage는 일련의 이름-값 쌍을 포함합니다.

• ObjectMessage는 Java 일련화 객체를 포함합니다.

일반적으로 메시지 유형은 응용 프로그램의 필요에 따라 제어되지만 좀 더 복잡한 유형(MapMessage 및 ObjectMessage)은 성능 저하(데이터 일련화 및 일련화 해제로 인한 저하)를 수반합니다. 성능 저하는 데이터의 단순성이나 복잡성에 따라 달라집니다.

성능에 영향을 미치는 메시지 서비스 요소

메시징 응용 프로그램의 성능은 응용 프로그램 설계뿐만 아니라 메시지 라우팅 및 전달을 수행하는 메시지 서비스의 영향도 받습니다.

다음 절에서는 성능에 영향을 미칠 수 있는 여러 메시지 서비스 요소를 설명합니다. 이러한 요소의 영향을 이해하는 것은 메시지 서비스 크기를 지정하고 배포된 응용 프로그램에서 발생할 수 있는 성능 병목 현상을 진단하고 해결하는 데 중요합니다.

Message Queue 서비스에서 성능에 영향을 미치는 가장 중요한 요소는 다음과 같습니다.

• 하드웨어

• 운영 체제

• Java 가상 머신(JVM)

• 연결

• 브로커 제한 및 동작

• 메시지 서비스 구조

• 데이터 저장소 성능

• 클라이언트 런타임 구성

아래의 절에서는 이러한 각 요소가 메시징 성능에 미치는 영향을 설명합니다.

하드웨어

Message Queue 브로커나 클라이언트 응용 프로그램 모두 CPU 처리 속도와 사용 가능한 메모리가 메시지 서비스 성능의 주요 결정 요소입니다. 처리량을 높이면 많은 소프트웨어 제한 사항을 제거할 수 있고 메모리를 추가하면 처리 속도와 용량을 모두 늘릴 수 있습니다. 그러나 일반적으로 하드웨어 업그레이드만으로 병목 현상을 극복하려면 비용이 많이 듭니다.

운영 체제

하드웨어 플랫폼이 같은 경우라도 각기 다른 운영 체제의 효율성으로 인해 성능은 다양할 수 있습니다. 예를 들어, 운영 체제에서 사용하는 스레드 모델은 브로커가 지원할 수 있는 동시 연결 수에 중요한 영향을 미칠 수 있습니다. 일반적으로 모든 하드웨어가 동일한 경우 Solaris가 Linux보다 빠르며 Linux가 Windows보다 빠릅니다.

Java 가상 머신(JVM)

브로커는 호스트 JVM에서 실행되고 지원되는 Java 프로세스입니다. 결과적으로 JVM 처리는 브로커가 얼마나 빠르고 효율적으로 메시지를 라우팅하고 전달할 수 있는지 결정하는 중요 요소입니다.

특히 JVM의 메모리 자원 관리는 중요할 수 있습니다. 메모리 로드 증가를 수용하기 위해 충분한 메모리를 JVM에 할당해야 합니다. 또한 JVM은 주기적으로 사용되지 않은 메모리를 재생 이용하며 이러한 메모리 재생 이용은 메시지 처리를 지연시킬 수 있습니다. JVM 메모리 힙이 클수록 메모리 재생 이용 중에 경험할 수 있는 잠재적 지연은 더 길어집니다.

연결

클라이언트와 브로커간 연결의 수와 속도는 메시지 서비스가 처리할 수 있는 메시지 수와 메시지 전달 속도에 영향을 미칠 수 있습니다.

브로커 연결 제한

브로커에 대한 모든 액세스는 연결을 통해서 이루어집니다. 동시 연결 수에 대한 제한은 브로커를 동시에 사용할 수 있는 생성자나 사용자 클라이언트 수에 영향을 미칠 수 있습니다.

일반적으로 브로커에 대한 연결 수는 사용 가능한 스레드 수에 의해 제한됩니다. 전용 스레드 모델이나 공유 스레드 모델 중 하나를 지원하도록 Message Queue를 구성할 수 있습니다( 스레드 풀 관리 참조).

전용 스레드 모델은 각 연결이 전용 스레드를 가지므로 아주 빠르지만 연결 수가 사용 가능한 스레드 수에 의해 제한됩니다(연결당 하나의 입력 스레드와 하나의 출력 스레드 필요). 공유 스레드 모델은 연결 수에 대한 제한이 없지만 많은 연결 사이에서 스레드를 공유하며 이러한 연결이 사용 중인 경우에는 상당한 오버헤드와 처리량 지연이 발생합니다.

전송 프로토콜

Message Queue 소프트웨어를 사용하면 클라이언트가 다양한 저급 전송 프로토콜을 사용하여 브로커와 통신할 수 있습니다. Message Queue는 연결 서비스에 설명된 연결 서비스와 해당 프로토콜을 지원합니다.

프로토콜은 응용 프로그램 요구 사항(암호화, 방화벽을 통한 액세스 가능)을 기반으로 선택하지만 이 선택은 전체 성능에 영향을 미칩니다.

그림 11–2 전송 프로토콜 속도

테스트를 통해 높은 안정성 시나리오(영구 가입이 있고 AUTO_ACKNOWLEDGE 확인 모드를 사용하는 주제 대상에 1k의 지속성 메시지를 보냄)와 높은 성능 시나리오(영구 가입이 없고 DUPS_OK_ACKNOWLEDGE 확인 모드를 사용하는 주제 대상에 1k의 비지속성 메시지를 보냄)의 두 가지 경우에 대해 TCP와 SSL의 처리량을 비교했습니다.

일반적으로 프로토콜은 높은 안정성 사례에서 미치는 영향이 더 적습니다. 이는 아마도 높은 안정성 사례에서 필요한 지속성 오버헤드가 처리량을 제한하는 데 프로토콜 속도보다 더 중요한 요소이기 때문일 것입니다. 또는

• TCP는 브로커와 통신할 수 있는 가장 빠른 방법을 제공합니다.

• SSL은 메시지를 보내고 받을 때 TCP보다 50-70퍼센트 더 느립니다(지속성 메시지의 경우 50퍼센트, 비지속성 메시지의 경우 70퍼센트에 근접). 또한 클라이언트와 브로커(또는 HTTPS의 경우 웹 서버)가 전송할 데이터를 암호화할 때 사용될 개인 키를 설정해야 하므로 SSL을 사용하면 초기 연결 설정이 더 느려집니다(몇 초 걸릴 수 있음). 각 저급 TCP 패킷을 암호화하고 해독하는 데 필요한 추가 처리에 의해 성능이 저하됩니다.

• HTTP는 TCP나 SSL보다 느립니다. HTTP는 웹 서버에서 실행되는 서블릿을 클라이언트와 브로커 사이의 프록시로 사용합니다. 성능 오버헤드는 HTTP 요청의 패킷 캡슐화와 메시지가 브로커에 도달하기 위해 두 개의 홉(클라이언트에서 서블릿으로, 서블릿에서 브로커로)을 통과해야 한다는 점과 관련됩니다.

• 클라이언트와 서블릿 사이 그리고 서블릿과 브로커 사이에서 패킷을 암호화하는 데 필요한 추가 오버헤드로 인해 HTTPS는 HTTP보다 더 느립니다.

메시지 서비스 구조

Message Queue 메시지 서비스는 단일 브로커로 구현되거나 다중 상호 연결 브로커 인스턴스로 구성된 클러스터로 구현될 수 있습니다.

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

일반적으로 이러한 확장은 클라이언트, 특히 메시지 생성자 클라이언트가 클러스터 전체에 균등하게 분산되어 있는 경우에 가장 잘 작동합니다. 클러스터에 있는 브로커 사이의 메시지 전달과 관련된 오버헤드로 인해 제한된 연결 수나 메시지 전달 비율을 갖는 클러스터는 단일 브로커보다 더 낮은 성능을 보일 수 있습니다.

또한 브로커 클러스터를 사용하여 네트워크 대역폭을 최적화할 수 있습니다. 예를 들어, 클러스터 내의 원격 브로커들 사이에는 느린 장거리 네트워크 링크를 사용하고 클라이언트와 해당 브로커 인스턴스의 연결에는 고속 링크를 사용할 수 있습니다.

클러스터에 대한 자세한 내용은 9 장, 브로커 클러스터 작업을 참조하십시오.

브로커 제한 및 동작

브로커가 처리해야 하는 메시지 처리량은 브로커가 지원하는 메시징 응용 프로그램의 사용 패턴에 달려 있습니다. 하지만 브로커는 메모리, CPU 사이클 등 자원이 제한되어 있습니다. 따라서 브로커가 넘치게 되어 응답하지 않거나 불안정하게 될 수 있습니다.

Message Queue 메시지 브로커에는 메모리 자원을 관리하고 브로커의 메모리 부족을 방지하기 위해 기본적으로 제공되는 메커니즘이 있습니다. 이러한 메커니즘은 브로커나 개별 물리적 대상이 보유할 수 있는 메시지 수나 메시지 바이트에 대한 구성 가능한 제한을 포함하며 물리적 대상 제한에 이르면 시작될 수 있는 동작 집합을 포함합니다.

이러한 구성 가능한 메커니즘은 세밀하게 모니터하고 조정하면 메시지 유입과 유출의 균형을 유지하여 시스템 과부하가 발생할 수 없도록 하는 데 사용할 수 있습니다. 이 메커니즘은 오버헤드를 사용하고 메시지 처리량을 제한하는 단점이 있지만 운영 무결성을 유지할 수 있습니다.

데이터 저장소 성능

Message Queue는 파일 기반 및 JDBC 기반 지속성 모듈을 모두 지원합니다. 파일 기반 지속성에서는 개별 파일을 사용하여 영구 데이터를 저장합니다. JDBC 기반 지속성은 JDBC™(Java Database Connectivity) 인터페이스를 사용하고 JDBC 호환 데이터 저장소가 필요합니다. 일반적으로 파일 기반 지속성은 JDBC 기반보다 빠르지만, JDBC 호환 저장소가 제공하는 중복 및 관리 제어 기능을 선호하는 사용자도 있습니다.

파일 기반 지속성의 경우 지속성 작업이 메모리 상태에서 데이터 저장소와 동기화되도록 지정하여 안정성을 최대화할 수 있습니다. 이렇게 하면 시스템 중단으로 인한 데이터 손실을 방지할 수 있지만 성능은 저하됩니다.

클라이언트 런타임 구성

Message Queue 클라이언트 런타임은 클라이언트 응용 프로그램에 Message Queue 메시지 서비스에 대한 인터페이스를 제공합니다. 이 클라이언트 런타임은 클라이언트가 물리적 대상에게 메시지를 보내고 대상으로부터 메시지를 받는 데 필요한 모든 작업을 지원합니다. 연결 팩토리 속성 값을 설정하여 클러이언트 런타임을 구성할 수 있으므로 연결 흐름 측정, 사용자 흐름 제한 및 연결 흐름 제한과 같은 다양한 동작 측면을 제어하여 성능 및 메시지 처리량을 향상시킬 수 있습니다. 이러한 기능과 기능을 구성하는 데 사용되는 속성에 대한 자세한 내용은 클라이언트 런타임 메시지 흐름 조정을 참조하십시오.

성능 향상을 위한 구성 조정

다음 절에서는 구성 조정이 성능에 미치는 영향에 대해 설명합니다.

시스템 조정

다음 절에서는 운영 체제, JVM 및 통신 프로토콜에서 조정할 수 있는 내용을 설명합니다.

Solaris 조정: CPU 사용률, 페이징/스왑/디스크 입출력

운영 체제 조정에 대해서는 시스템 설명서를 참조하십시오.

Java 가상 머신 조정

기본적으로 브로커는 192MB의 JVM 힙을 사용합니다. 이 크기는 대량의 메시지 로드를 처리하기에 비해 너무 작은 경우가 많으므로 늘리는 것이 좋습니다.

브로커가 Java 객체에서 사용되는 JVM 힙 공간을 소진하는 데 이르면 브로커는 흐름 제어, 메시지 스왑 등 여러 기술을 사용하여 메모리를 확보합니다. 아주 드물게 메모리를 확보하고 메시지 유입을 줄이기 위해 클라이언트 연결을 닫는 경우도 있습니다. 따라서, 이러한 경우가 발생하지 않도록 최대 JVM 힙 공간을 충분하게 설정하는 것이 좋습니다.

하지만, 최대 Java 힙 공간을 너무 높게 설정하면 브로커가 전체 시스템 메모리가 부족해 질 때까지 Java 힙 공간을 계속해서 증가시킬 수 있습니다. 그렇게 되면 성능이 감소하거나, 예상치 않은 브로커 충돌이 발생하거나, 시스템에서 실행 중인 다른 응용 프로그램 및 서비스의 동작에 영향을 미칠 수 있습니다. 일반적으로 운영 체제 및 시스템에서 실행할 다른 응용 프로그램이 충분한 물리적 메모리를 사용할 수 있도록 해야 합니다.

일반적으로 정상 시스템 메모리와 최대 시스템 메모리를 평가하여 시스템 메모리 문제를 일으키지 않고 우수한 성능을 제공할 수 있도록 Java 힙 크기를 구성하는 것이 좋습니다.

브로커의 최소 및 최대 힙 크기를 변경하려면 브로커를 시작할 때 -vmargs 명령줄 옵션을 사용합니다. 예를 들면 다음과 같습니다.

/usr/bin/imqbrokerd -vmargs "-Xms256m -Xmx1024m"

이 명령은 시작 Java 힙 크기를 256MB로 설정하고 최대 Java 힙 크기를 1GB로 설정합니다.

• Solaris 또는 Linux에서 /etc/rc*(즉, /etc/init.d/imq)를 통해 브로커를 시작하는 경우 /etc/imq/imqbrokerd.conf(Solaris) 또는 /etc/opt/sun/mq/imqbrokerd.conf(Linux) 파일에 브로커 명령줄 인수를 지정합니다. 자세한 내용은 해당 파일의 주석을 참조하십시오.

• Windows에서 브로커를 Windows 서비스로 시작하는 경우 imqsvcadmin install 명령에 -vmargs 옵션을 사용하여 JVM 인수를 지정합니다. 13 장, 명령줄 참조의 서비스 관리자 유틸리티를 참조하십시오.

어떤 경우든 브로커 로그 파일을 확인하거나 imqcmd metrics bkr -m cxn 명령을 사용하여 설정을 확인합니다.

전송 프로토콜 조정

응용 프로그램 요구에 맞는 프로토콜을 선택했으면 선택한 프로토콜을 기반으로 추가 조정하여 성능을 향상시킬 수 있습니다.

다음 세 가지 브로커 등록 정보를 사용하여 프로토콜의 성능을 수정할 수 있습니다.

• imq.protocol.protocolType .nodelay

• imq.protocol.protocolType .inbufsz

• imq.protocol.protocolType .outbufsz

TCP 및 SSL 프로토콜의 경우 이러한 등록 정보는 클라이언트와 브로커 사이의 메시지 전달 속도에 영향을 미칩니다. HTTP 및 HTTPS 프로토콜의 경우 이 등록 정보는 웹 서버에서 실행 중인 Message Queue 터널 서블릿과 브로커 사이의 메시지 전달 속도에 영향을 미칩니다. HTTP/HTTPS 프로토콜의 경우 성능에 영향을 미칠 수 있는 추가 등록 정보가 있습니다( HTTP/HTTPS 조정 참조).

프로토콜 조정 등록 정보에 대해서는 다음 절에서 설명합니다.

nodelay

nodelay 등록 정보는 지정된 프로토콜의 Nagle 알고리즘(TCP/IP에서 TCP_NODELAY 소켓 수준 옵션 값)에 영향을 미칩니다. Nagle 알고리즘은 WAN(Wide-Area Network) 같은 느린 연결을 사용하는 시스템에서 TCP 성능을 향상시키는 데 사용됩니다.

이 알고리즘이 사용되면 TCP는 여러 개의 작은 데이터 청크가 원격 시스템으로 보내지지 않도록 데이터를 큰 패킷으로 묶으려고 합니다. 소켓에 기록된 데이터가 필요한 버퍼 크기를 채우지 못하는 경우 프로토콜은 버퍼가 채워지거나 특정 지연 시간이 경과될 때까지 패킷 전송을 지연합니다. 버퍼가 채워지거나 시간 초과가 발생하면 패킷을 보냅니다.

대부분의 메시징 응용 프로그램에서 패킷을 지연 없이 보내는 경우(Nagle 알고리즘을 사용하지 않는 경우) 최고의 성능을 냅니다. 이는 클라이언트와 브로커 사이의 상호 작용이 대부분 클라이언트가 데이터 패킷을 브로커에게 보내고 응답을 기다리는 요청/응답 상호 작용이기 때문입니다. 예를 들어, 일반적인 상호 작용에는 다음이 포함됩니다.

• 연결 만들기

• 생성자 또는 사용자 만들기

• 지속성 메시지 보내기(브로커가 메시지 수신 확인)

• AUTO_ACKNOWLEDGE 또는 CLIENT_ACKNOWLEDGE 세션에서 클라이언트 확인 보내기(브로커가 확인 처리 확인)

이러한 상호 작용에서 대부분의 패킷은 버퍼 크기보다 작습니다. 이는 Nagle 알고리즘이 사용되는 경우 브로커가 사용자에게 응답을 보내기 전에 몇 밀리초를 지연함을 의미합니다.

하지만 Nagle 알고리즘은 연결이 느리고 브로커 응답이 필요하지 않은 경우 성능을 향상시킬 수 있습니다. 이런 것으로는 클라이언트가 비지속성 메시지를 보내는 경우나 클라이언트 확인을 브로커에서 확인하지 않는 경우(DUPS_OK_ACKNOWLEDGE 세션)를 들 수 있습니다.

inbufsz/outbufsz

inbufsz 등록 정보는 소켓에서 들어오는 데이터를 읽는 입력 스트립의 버퍼 크기를 설정합니다. 마찬가지로 outbufsz는 데이터를 소켓에 기록하기 위해 브로커가 사용하는 출력 스트림의 버퍼 크기를 설정합니다.

일반적으로 두 매개 변수 모두 보내거나 받는 평균 패킷보다 약간 큰 값으로 설정해야 합니다. 경험에 따르면 이 등록 정보 값을 평균 패킷에 1KB를 더한 크기(가장 가까운 KB값으로 반올림)로 설정하는 것이 좋습니다. 예를 들어, 브로커가 본문 크기가 1KB인 패킷을 받는 경우 패킷의 전체 크기(메시지 본문 + 헤더 + 등록 정보)는 약 1200바이트입니다. inbufsz가 2KB(2048바이트)인 경우 적당한 성능을 제공합니다. inbufsz나 outbufsz를 이 크기보다 더 늘리면 성능은 약간 늘어날 수 있지만 각 연결에 필요한 메모리가 늘어나게 됩니다.

HTTP/HTTPS 조정

앞의 두 절에서 설명한 일반 등록 정보 이외에도 HTTP/HTTPS 성능은 클라이언트가 Message Queue 터널 서블릿을 호스트하는 웹 서버에 대해 HTTP 요청을 얼마나 빨리 보낼 수 있는지에 따라 제한됩니다.

단일 소켓에서 다중 요청을 처리하도록 웹 서버를 최적화해야 할 수 있습니다. JDK 버전 1.4 이상에서는 웹 서버에 대한 HTTP 연결이 유지되어(웹 서버 소켓이 열린 상태로 유지) 다중 HTTP 요청을 처리할 때 웹 서버에서 사용되는 자원을 최소화합니다. JDK 버전 1.4를 사용하는 클라이언트 응용 프로그램의 성능이 이전 JDK 릴리스로 실행 중인 같은 응용 프로그램보다 느린 경우 성능을 향상시키기 위해 웹 서버의 연결 유지 구성 매개 변수를 조정해야 할 수 있습니다.

이러한 웹 서버 조정과 더불어 클라이언트가 웹 서버를 폴하는 간격도 조정할 수 있습니다. HTTP는 요청 기반 프로토콜입니다. 따라서 HTTP 기반 프로토콜을 사용하는 클라이언트는 웹 서버에서 메시지가 대기 중인지 주기적으로 확인해야 합니다. imq.httpjms.http.pullPeriod 브로커 등록 정보(및 해당 imq.httpsjms.https.pullPeriod 등록 정보)는 Message Queue 클라이언트 런타임이 웹 서버를 폴하는 간격을 지정합니다.

pullPeriod 값이 -1(기본값)인 경우 클라이언트 런타임은 이전 요청이 반환되자마자 서버를 폴하여 개별 클라이언트의 성능을 최대화합니다. 따라서 각 클라이언트 연결이 웹 서버의 요청 스레드를 독점하여 웹 서버 자원이 고갈될 수 있습니다.

pullPeriod 값이 양수인 경우 클라이언트 런타임은 주기적으로 웹 서버에 요청을 보내 보류 중인 데이터가 있는지 확인합니다. 이 경우 클라이언트가 웹 서버의 요청 스레드를 독점하지 않습니다. 따라서 많은 수의 클라이언트가 웹 서버를 사용 중인 경우 pullPeriod를 양수로 설정하면 웹 서버 자원을 절약할 수 있습니다.

파일 기반 영구 저장소 조정

파일 기반 영구 저장소 조정에 대한 자세한 내용은 지속성 서비스를 참조하십시오.

브로커 조정

다음 절에서는 브로커 등록 정보를 조정하여 성능을 향상시키는 방법에 대해 설명합니다.

메모리 관리: 로드 하에서 브로커 안정성 증가

대상별 또는 시스템 전체 수준(모든 대상을 묶어서)에서 메모리 관리를 구성할 수 있습니다.

물리적 대상 제한 사용

물리적 대상 제한에 대한 자세한 내용은 6 장, 물리적 대상 관리을 참조하십시오.

시스템 전체 제한 사용

메시지 생성자가 메시지 사용자보다 넘치는 경향이 있는 경우 메시지가 브로커에 누적될 수 있습니다. 브로커에는 메모리가 부족한 경우 생성자를 억제하고 활성 메모리로부터 메시지를 스왑하는 메커니즘이 포함되어 있지만 브로커가 보관할 수 있는 전체 메시지 수와 메시지 바이트에 대해 엄격한 제한을 설정하는 것이 좋습니다.

imq.system.max_count 및 imq.system.max_size 브로커 등록 정보를 설정하여 이러한 제한을 제어합니다.

예를 들면 다음과 같습니다.

imq.system.max_count=5000

위에서 정의한 값은 브로커가 전달되지 않은/확인되지 않은 메시지를 5000개까지만 보관함을 의미합니다. 추가로 보내는 메시지는 브로커에서 거부됩니다. 메시지가 지속성인 경우 생성자가 메시지를 보내려고 하면 예외가 발생합니다. 메시지가 비지속성인 경우 브로커는 메시지를 자동으로 삭제합니다.

메시지를 보낼 때 예외가 반환되면 클라이언트는 잠시 동안 일시 중지하고 전송을 다시 시도해야 합니다. 브로커에서 메시지를 받지 못해서 발생하는 예외는 없습니다. 예외가 발생된다면 송신측의 클라이언트에서 발생되는 예외뿐입니다.

다중 사용자 대기열 성능

여러 대기열 사용자가 단일 대기열 대상에서 메시지를 처리하는 효율성은 다음과 같은 구성 가능한 대기열 대상 속성에 따라 달라집니다.

• 활성 사용자 수(maxNumActiveConsumers)

• 일괄적으로 사용자에게 전달될 수 있는 최대 메시지 수(consumerFlowLimit)

최적의 메시지 처리량을 달성하려면 대기열의 메시지 생성 속도에 부합하는 충분한 활성 사용자의 수가 있어야 하며 대기열의 메시지를 그 사용 속도를 최대화할 수 있는 방식으로 라우팅한 다음 활성 사용자에게 전달해야 합니다. 여러 사용자 간에 메시지 전달의 균형을 조정하기 위한 일반 메커니즘에 대해서는 Sun Java System^TM Message Queue Technical Overview에서 설명합니다.

메시지가 대기열에 누적되고 있는 경우 활성 사용자 수가 메시지 로드를 처리하기에 충분하지 않을 수 있습니다. 또는 사용자에서 메시지 정체를 일으키는 일괄 처리 크기로 메시지가 사용자에게 전달되고 있을 수 있습니다. 예를 들어 일괄 처리 크기(consumerFlowLimit)가 너무 큰 경우 한 사용자가 대기열의 모든 메시지를 받는 동안 다른 활성 사용자는 메시지를 전혀 받지 못할 수 있습니다. 사용자가 아주 빠른 경우 이것은 문제가 되지 않을 수 있습니다.

하지만 사용자가 비교적 느린 경우 메시지를 사용자에게 균등하게 분산시켜야 하므로 일괄 처리 크기가 작은 게 좋습니다. 일괄 처리 크기가 작을수록 메시지를 사용자에게 전달하는 데 더 많은 오버헤드가 필요합니다. 그럼에도 불구하고 느린 사용자의 경우 작은 일괄 처리 크기를 사용하는 것이 결과적으로 성능 향상이 있습니다.

클라이언트 런타임 메시지 흐름 조정

이 절에서는 성능에 영향을 미치는 흐름 제어 동작에 대해 설명합니다( 클라이언트 런타임 구성 참조). 이러한 동작은 연결 팩토리 관리 객체의 속성으로 구성됩니다. 연결 팩토리 속성 설정에 대한 자세한 내용은 8 장, 관리 대상 객체 관리을 참조하십시오.

메시지 흐름 측정

클라이언트가 보내고 받는 메시지(페이로드 메시지)와 Message Queue 제어 메시지는 동일한 클라이언트 브로커 연결을 통해 전달됩니다. 제어 메시지가 페이로드 메시지 전달로 인해 일시 중단되면 브로커 확인과 같은 제어 메시지 전달이 지연될 수 있습니다. 이러한 유형의 혼잡을 막기 위해 Message Queue는 연결에서 페이로드 메시지의 흐름을 측정합니다.

페이로드 메시지는 imqConnectionFlowCount 연결 팩토리 속성에서 지정한 대로 설정된 수만 전달되도록 일괄 처리됩니다. 일괄 처리가 전달된 후에는 페이로드 메시지 전달이 일시 중지되고 보류 중인 제어 메시지만 전달됩니다. 페이로드 메시지의 추가 일괄 처리가 전달된 다음 보류 중인 제어 메시지가 전달되는 식으로 이러한 주기가 반복됩니다.

클라이언트가 브로커에 많은 응답을 요구하는 작업을 수행 중인 경우 imqConnectionFlowCount 값을 유지해야 합니다. 예를 들어, 클라이언트가 CLIENT_ACKNOWLEDGE or AUTO_ACKNOWLEDGE 모드, 지속성 메시지, 트랜잭션 또는 대기열 브라우저를 사용하고 있거나 클라이언트가 사용자를 추가 또는 제거하고 있는 경우가 있습니다. 반면 클라이언트에 연결에서 DUPS_OK_ACKNOWLEDGE 모드를 사용하는 단순 사용자만 있는 경우 성능을 저하시키지 않고 imqConnectionFlowCount를 늘릴 수 있습니다.

메시지 흐름 제한

메모리와 같은 로컬 자원 제한이 발생하기 전에 Message Queue 클라이언트 런타임이 처리할 수 있는 페이로드 메시지 수에 대한 제한이 있습니다. 이 제한에 가까워지면 성능에 악영향을 줍니다. 따라서 Message Queue에서는 연결을 통해 전달되고 클라이언트 런타임에 버퍼링되어 사용 대기 중일 수 있는 사용자당 메시지(또는 연결당 메시지) 수를 제한할 수 있습니다.

사용자 흐름 제한

클라이언트 런타임에 전달된 페이로드 메시지 수가 사용자의 imqConsumerFlowLimit 값을 초과하면 해당 사용자에 대해 메시지 전달이 중지됩니다. 해당 사용자의 사용되지 않은 메시지 수가 imqConsumerFlowThreshold에 설정된 값 이하로 떨어져야만 메시지 전달이 재개됩니다.

다음은 이러한 제한의 사용을 보여 주는 예입니다. 주제 사용자의 기본 설정을 고려해 보십시오.

imqConsumerFlowLimit=1000
imqConsumerFlowThreshold=50

사용자가 만들어지면 브로커는 초기 일괄 처리인 1000개의 메시지(있는 경우)를 일시 중지 없이 이 사용자에게 전달합니다. 1000개의 메시지를 보낸 다음 브로커는 클라이언트 런타임이 추가 메시지를 요청할 때까지 전달을 중지합니다. 클라이언트 런타임은 응용 프로그램이 메시지를 처리할 때까지 이 메시지들을 보관합니다. 그런 다음 클라이언트 런타임은 브로커에게 다음 일괄 처리를 보내도록 요청하기 전에 응용 프로그램이 적어도 메시지 버퍼 용량(imqConsumerFlowThreshold)의 50%(즉, 500개의 메시지)를 사용할 수 있도록 합니다.

같은 상황에서 임계값이 10%인 경우 클라이언트 런타임은 다음 일괄 처리를 요청하기 전에 응용 프로그램이 최소 900개의 메시지를 사용할 때까지 기다립니다.

다음 일괄 처리 크기는 다음과 같이 계산됩니다.

imqConsumerFlowLimit - (current number of pending msgs in buffer
)

따라서 imqConsumerFlowThreshold가 50%인 경우 다음 일괄 처리 크기는 응용 프로그램의 메시지 처리 속도에 따라 500과 1000 사이에서 변동될 수 있습니다.

imqConsumerFlowThreshold가 너무 높게 설정된 경우(100% 가까이) 브로커는 더 작은 일괄 처리를 보내는 경향이 있으므로 메시지 처리량이 떨어질 수 있습니다. 이 값이 너무 낮게 설정된 경우(0%에 근접) 브로커가 다음 집합을 전달하기 전에 클라이언트가 버퍼링된 나머지 메시지를 모두 처리할 수 있으므로 메시지 처리량이 다시 저하됩니다. 일반적으로 특정 성능이나 안정성 문제가 있는 경우가 아니라면 imqConsumerFlowThreshold 속성의 기본값을 변경할 필요가 없습니다.

사용자 기반 흐름 제어(특히 imqConsumerFlowLimit)는 클라이언트 런타임의 메모리 관리에 가장 좋은 방법입니다. 일반적으로 클라이언트 응용 프로그램에 따라 연결에서 지원해야 할 사용자 수, 메시지 크기 및 클라이언트 런타임에서 사용할 수 있는 전체 메모리 양에 대해 알고 있습니다.

연결 흐름 제한

하지만 일부 클라이언트 응용 프로그램의 경우 최종 사용자의 선택에 따라 사용자 수가 불확실할 수 있습니다. 이러한 경우에도 연결 수준 흐름 제한을 사용하여 메모리를 관리할 수 있습니다.

연결 수준 흐름 제어는 연결의 모든 사용자에 대해 버퍼링되는 전체 메시지 수를 제한합니다. 이 수가 imqConnectionFlowLimit의 값을 초과하면 전체 수가 연결 제한 아래로 떨어질 때까지 해당 연결을 통한 메시지 전달이 중지됩니다(imqConnectionFlowLimitEnabled를 true로 설정하는 경우에만 imqConnectionFlowLimit 속성을 사용할 수 있음).

세션의 대기열에 있는 메시지 수는 각 사용자의 메시지 로드와 세션을 사용하는 메시지 사용자 수의 함수입니다. 클라이언트가 메시지를 생성하거나 사용할 때 지연을 나타내는 경우 일반적으로 응용 프로그램을 재설계하여 메시지 생성자와 사용자를 여러 세션에 분산시키거나 세션을 여러 연결에 분산시킴으로써 성능을 향상시킬 수 있습니다.

12장 문제 해결

이 장에서는 다음과 같은 문제를 이해하고 해결하는 방법을 설명합니다.

• 클라이언트가 연결을 설정할 수 없음

• 연결 처리 속도가 너무 느림

• 클라이언트가 메시지 생성자를 만들 수 없음

• 메시지 생성이 지연되거나 느림

• 메시지가 백로그됨

• 브로커 처리량이 일정하지 않음

• 메시지가 사용자에게 도달하지 않음

• 사용 불능 메시지 대기열에 메시지가 포함되어 있음

문제가 발생할 경우 설치된 Message Queue^TM 소프트웨어의 버전 번호를 확인하는 것이 좋습니다. 버전 번호를 사용하여 사용 중인 설명서 버전이 소프트웨어 버전과 일치하는 지 확인합니다. 문제를 Sun에 보고할 때도 버전 번호가 필요합니다. 버전 번호를 확인하려면 다음 명령을 실행합니다.

imqcmd -v

클라이언트가 연결을 설정할 수 없음

증상:

• 클라이언트가 새 연결을 설정할 수 없습니다.

• 클라이언트가 실패한 연결을 자동으로 다시 연결할 수 없습니다.

가능한 원인:

• 클라이언트 응용 프로그램이 연결을 닫을 수 없어 연결 수가 자원 제한을 초과합니다.

• 브로커가 실행 중이지 않거나 네트워크 연결에 문제가 있습니다.

• 연결 서비스가 비활성 상태이거나 일시 중지되어 있습니다.

• 필요한 연결 수에 비해 사용 가능한 스레드 수가 너무 적습니다.

• Solaris나 Linux 플랫폼에서 필요한 연결 수에 비해 파일 설명자가 너무 적습니다.

• TCP 백로그가 동시에 설정할 수 있는 새 연결 요청 수를 제한합니다.

• 운영 체제가 동시 연결 수를 제한합니다.

• 사용자의 인증 또는 권한 부여가 실패합니다.

가능한 원인: 클라이언트 응용 프로그램이 연결을 닫을 수 없어 연결 수가 자원 제한을 초과합니다.

문제의 원인을 확인하는 방법: 브로커에 대한 연결을 모두 나열합니다.

imqcmd list cxn

출력에 모든 연결과 각 연결이 설정된 호스트가 나열되고 특정 클라이언트에 비정상적인 수의 연결이 열려 있는 것으로 표시됩니다.

문제를 해결하는 방법: 문제가 있는 클라이언트를 다시 작성하여 사용되지 않는 연결을 닫습니다.

가능한 원인: 브로커가 실행 중이지 않거나 네트워크 연결에 문제가 있습니다.

문제의 원인을 확인하는 방법:

• 브로커의 기본 포트(예: 기본값 7676)로 텔넷하고 브로커가 포트 매퍼 출력으로 응답하는지 확인합니다.

• 브로커 프로세스가 호스트에서 실행 중인지 확인합니다.

문제를 해결하는 방법:

• 브로커를 시작합니다.

• 네트워크 연결 문제를 해결합니다.

가능한 원인: 연결 서비스가 비활성 상태이거나 일시 중지되어 있습니다.

문제의 원인을 확인하는 방법: 모든 연결 서비스의 상태를 확인합니다.

imqcmd list svc

연결 서비스 상태가 unknown 또는 paused로 표시되어 있는 경우 클라이언트가 해당 서비스를 사용하여 연결을 설정할 수 없습니다.

문제를 해결하는 방법:

• 연결 서비스의 상태가 unknown으로 표시되어 있는 경우 해당 연결 서비스가 활성 서비스 목록(imq.service.active)에 없는 것입니다. SSL 기반 서비스의 경우 서비스가 잘못 구성되어 있을 수도 있습니다. 이로 인해 브로커가 브로커 로그에 다음과 같은 항목과

  ERROR [B3009]: Unable to start service ssljms: [B4001]: Unable to open protocol tls for ssljms service...

  이 예외의 근본 원인에 대한 설명을 포함시키게 됩니다.

  SSL 서비스를 올바르게 구성하려면 메시지 암호화를 참조하십시오.

• 연결 서비스의 상태가 paused로 표시되어 있는 경우 서비스를 다시 시작합니다( 연결 서비스 일시 중지 및 다시 시작 참조).

가능한 원인: 필요한 연결 수에 비해 사용 가능한 스레드 수가 너무 적습니다.

문제의 원인을 확인하는 방법: 브로커 로그에서 다음 항목이 있는지 확인합니다.

WARNING [B3004]: No threads are available to process a new connection on service ... Closing the new connection.

또한 다음 형식 중 하나를 사용하여 연결 서비스의 연결 수와 현재 사용 중인 스레드 수를 확인합니다.

imqcmd query svc -n serviceName imqcmd metrics svc -n serviceName -m cxn

각 연결에는 받는 메시지와 보내는 메시지에 하나씩 두 개의 스레드가 필요합니다( 스레드 풀 관리 참조).

문제를 해결하는 방법:

• 전용 스레드 풀 모델을 사용하고 있는 경우(imq. serviceName.threadpool_model= dedicated) 최대 연결 수는 스레드 풀의 최대 스레드 수의 반입니다. 따라서 연결 수를 늘리려면 스레드 풀의 크기를 늘리거나(imq. serviceName.max_threads) 공유 스레드 풀 모델로 전환합니다.

• 공유 스레드 풀 모델을 사용하고 있는 경우(imq. serviceName.threadpool_model=shared) 최대 연결 수는 연결 모니터 제한(imq.serviceName.connectionMonitor_limit )과 최대 스레드 수(imq. serviceName.max_threads)를 곱한 수의 반입니다. 따라서 연결 수를 늘리려면 스레드 풀의 크기를 늘리거나 연결 모니터 제한을 늘립니다.

• 결국 지원 가능한 연결 수(또는 연결의 처리량)는 입출력 제한에 도달합니다. 그런 경우 다중 브로커 클러스터를 사용하여 클러스터 내의 브로커 인스턴스로 연결을 분산합니다.

가능한 원인: Solaris나 Linux 플랫폼에서 필요한 연결 수에 비해 파일 설명자가 너무 적습니다.

이 문제에 대한 자세한 내용은 파일 설명자 제한 설정을 참조하십시오.

문제의 원인을 확인하는 방법: 브로커 로그에 다음과 유사한 항목이 있는지 확인합니다.

Too many open files

문제를 해결하는 방법: ulimit 설명서 페이지에 설명한 대로 파일 설명자 제한을 늘립니다.

가능한 원인: TCP 백로그가 동시에 설정할 수 있는 새 연결 요청 수를 제한합니다.

TCP 백로그는 포트 매퍼가 추가 요청을 거부하기 전에 시스템 백로그(imq.portmapper.backlog)에 저장할 수 있는 동시 연결 요청 수를 제한합니다(Windows 플랫폼의 경우 하드 코드된 백로그 제한이 있으며 Windows 데스크탑의 경우 5이고 Windows 서버의 경우 200임).

백로그 제한으로 인한 요청 거부는 비정상적으로 많은 동시 연결 요청 수로 인해 발생하는 일시적인 현상입니다.

문제의 원인을 확인하는 방법: 브로커 로그를 검사합니다. 먼저, 브로커가 특정 기간 동안 일부 연결은 수신하고 다른 일부 연결은 거부하는지 여부를 확인합니다. 그런 다음, 거부된 연결을 설명하는 메시지를 확인합니다. 그러한 메시지가 있다면 브로커는 TCP 백로그로 인한 연결 거부를 기록하지 않으므로 TCP 백로그 문제가 아닐 수 있습니다. 일부 성공적인 연결이 기록되어 있고 연결 거부는 기록되어 있지 않은 경우 TCP 백로그에 문제가 있을 수 있습니다.

문제를 해결하는 방법:

• 클라이언트가 시도했던 연결을 잠시 후에 다시 시도하도록 프로그래밍합니다(이 문제가 본래 임시적이기 때문에 이렇게 하면 대개 제대로 작동됨).

• imq.portmapper.backlog 값을 늘립니다.

• 클라이언트가 너무 자주 연결을 닫은 다음 열고 있지는 않은지 확인합니다.

가능한 원인: 운영 체제가 동시 연결 수를 제한합니다.

Windows 운영 체제 사용권에서는 지원되는 동시 원격 연결 수를 제한합니다.

문제의 원인을 확인하는 방법: 연결에 사용할 수 있는 스레드가 충분한지 확인하고(imqcmd query svc 사용) Windows 사용권 계약 조항을 확인합니다. 로컬 클라이언트에서는 연결할 수 있지만 원격 클라이언트에서는 연결할 수 없는 경우 운영 체제 제한이 문제의 원인일 수 있습니다.

문제를 해결하는 방법:

• 더 많은 연결을 허용하도록 Windows 사용권을 업그레이드합니다.

• 다중 브로커 클러스터를 설정하여 연결을 여러 브로커 인스턴스에 분산합니다.

가능한 원인: 사용자의 인증 또는 권한 부여가 실패합니다.

다음과 같은 이유로 인해 인증이 실패할 수 있습니다.

• 잘못된 비밀번호

• 사용자 저장소에 사용자 항목 없음

• 사용자에게 연결 서비스에 대한 액세스 권한이 없음

문제의 원인을 확인하는 방법: 브로커 로그의 항목에 Forbidden 오류 메시지가 있는지 확인합니다. 이 메시지는 인증 오류를 나타낼 뿐 그 원인은 나타내지 않습니다.

• 파일 기반 사용자 저장소를 사용하는 경우 다음 명령을 입력합니다.

  imqusermgr list -i instanceName -u userName

  출력에 사용자가 표시되는 경우 잘못된 비밀번호가 제출된 것일 수 있습니다. 출력에 다음과 같은 오류가 표시되는 경우 사용자 저장소에 사용자 항목이 없는 것입니다.

  Error [B3048]: User does not exist in the password file

• LDAP 서버 사용자 저장소를 사용 중인 경우 적절한 도구를 사용하여 사용자 항목이 있는지 확인합니다.

• 액세스 제어 등록 정보 파일에 연결 서비스 액세스에 대한 제한이 있는지 확인합니다.

문제를 해결하는 방법:

• 잘못된 비밀번호가 사용된 경우 올바른 비밀번호를 제공합니다.

• 사용자 저장소에 사용자 항목이 없는 경우 사용자를 추가합니다( 사용자 저장소 채우기 및 관리 참조).

• 사용자가 연결 서비스에 대한 액세스 권한이 없는 경우 해당 권한을 허용하도록 액세스 제어 등록 정보 파일을 편집합니다( 연결 서비스에 대한 액세스 제어 참고).

연결 처리 속도가 너무 느림

증상:

• 메시지 처리량이 기대에 미치지 못합니다.

• 브로커에 대해 지원되는 연결 수가 클라이언트가 연결을 설정할 수 없음에 설명된 대로 제한되는 것이 아니라 메시지 입출력 속도에 의해 제한됩니다.