|
| |
| Sun Java System Message Queue 3 2005Q1 기술 개요 | |
3장
안정적인 메시지 전달이 장에서는 Message Queue 서비스가 안정적인 메시지 전달을 제공하는 방법을 설명합니다. 메시지를 해당 사용자에게 경로 지정하고 전달할 때 그리고 메시지가 전달되었음을 보장할 때 사용되는 다양한 메커니즘을 설명하면서 시스템을 통한 메시지의 경로를 추적합니다.
이 절은 다음 내용으로 구성되어 있습니다.
이 장에는 개발자 및 관리자 모두가 관심을 가질 자료가 있으며 2장, "Message Queue 소개"의 내용을 보완합니다.
시스템에서의 메시지 경로Message Queue 메시지 서비스를 통한 메시지 생성자에서 메시지 사용자로의 메시지 전달은 그림 3-1에서 보여줍니다. 다음에 오는 하위 절에서는 전달 과정의 각 단계에 대한 자세한 설명을 제공합니다.
그림 3-1 메시지 전달 단계
안정적으로 전달되는 지속성 메시지의 메시지 전달 단계는 다음과 같습니다.
메시지 생성
1. 클라이언트 런타임이 연결을 통해 메시지 생성자에서 메시지 서버로 메시지를 전달합니다.
메시지 처리 및 경로 지정
2. 메시지 서버가 연결을 통해 메시지를 읽어 들여 적절한 대상에 저장합니다.
3. 메시지 서버가 (지속성) 메시지를 데이터 저장소에 저장합니다.
4. 메시지 서버가 메시지 생성자의 클라이언트 런타임에게 메시지 수신 확인을 보냅니다.
5. 메시지 서버가 메시지 경로 지정을 결정합니다.
6. 메시지 서버가 대상에서 들어온 메시지를 해당 연결에 기록합니다.
메시지 사용
7. 메시지 사용자의 클라이언트 런타임이 연결에서 메시지 사용자로 메시지를 전달합니다.
8. 메시지 사용자의 클라이언트 런타임이 메시지 사용에 대한 확인을 메시지 서버로 보냅니다.
메시지 수명 끝
9. 메시지 서버는 클라이언트 확인을 처리하여, 대상과 데이터 저장소 양쪽에서 (지속성) 메시지를 삭제합니다.
10. 클라이언트 확인이 처리되었으므로 메시지를 다시 전달할 수 없음에 대한 확인을 메시지 서버가 사용자의 클라이언트 런타임으로 보냅니다.
이러한 전달 단계에서 시스템에 의해 처리된 메시지는 두 가지 범주로 구분됩니다.
메시지 전달 처리생성자에서 사용자에게 메시지를 전달하는 과정에서 Message Queue 서비스에 의한 메시지 처리는 그림 3-1 다음의 단계 설명에서 표시된 대로 여러 단계에서 진행됩니다.
단계는 다음과 같습니다.
다음 절에서 이러한 단계에 대해 설명합니다.
메시지 생성
메시지 생성 단계에서는 클라이언트가 메시지를 작성하고 연결을 통해 클라이언트 런타임이 브로커의 대상으로 전달합니다.
메시지의 전달 모드가 지속성(브로커가 실패한 경우에도 단 한 차례 전달 보장)으로 설정되어 있었다면 브로커는 기본적으로 제어 메시지(브로커 확인)를 다시 클라이언트 런타임으로 전달합니다. 이 브로커 확인은 브로커가 대상으로 메시지를 전달했고 브로커의 데이터 저장소에 저장했음을 나타냅니다. 브로커 확인을 수신할 때까지 클라이언트 스레드가 차단됩니다.
메시지의 전달 모드가 비지속성으로 설정되어 있었다면 브로커는 기본적으로 브로커 확인을 클라이언트 런타임으로 다시 보내지 않으므로 클라이언트 스레드가 차단되지 않습니다. 하지만 브로커가 비지속성 메시지를 수신했는지 여부를 알아야 한다면 브로커 확인을 활성화할 수 있습니다. 실제로, 대상 메모리 제한에 도달할 때 브로커의 메시지 생성 속도를 낮추려면 브로커 확인을 활성화해야 합니다(대상 메시지 제한 참조).
메시지 처리 및 경로 지정
브로커는 들어오는 JMS 페이로드 메시지를 받을 때 메시지를 대상에 저장한 다음 해당 사용자에게로 경로 지정합니다.
일반적으로 모든 메시지는 전달되거나 만료될 때까지 물리적 대상(메모리)에 남아 있습니다. 하지만 브로커에 오류가 발생할 경우 이 메시지는 손실됩니다. 메시지가 지속성이면 브로커는 메시지를 데이터베이스 또는 파일 시스템에 저장하고 오류가 발생하면 복구합니다.
메시지 처리는 다음 절에서 설명하는 것처럼 대상 유형(대기열 또는 주제)에 따라 다릅니다. 또한 관리자가 물리적 대상을 작성할 때 대상에 대해 설정한 대상 등록 정보에 따라 달라집니다.
대기열 대상
대기열 대상은 지점간 메시징에서 사용되며 이 경우 메시지는 한 사용자에게만 전달되고 한 사용자에 의해서만 사용됩니다.
대기열의 메시지는 단일 사용자에게만 전달되지만 Message Queue에서는 다중 사용자가 하나의 대기열에 등록할 수 있습니다. 그런 다음 브로커는 메시지를 등록된 여러 사용자에게 분산하여 사용자 간에 로드 균형을 조정합니다.
기본 경로 지정 메커니즘
메시지가 생성자로부터 도달하면 대기열로 들어갑니다. 각 메시지가 대기열의 맨 앞에 도달하면 대기열에 등록된 단일 사용자로 경로 지정됩니다. 메시지가 대기열의 맨 앞에 도달하는 순서는 도착 순서 및 우선 순위에 따라 결정됩니다.
메시지에 선택기 등록 정보 값이 설정되어 있는 경우 브로커는 이 값을 등록된 사용자가 지정한 선택기 값과 비교하여 선택기 값이 일치하는지 확인한 다음 해당 메시지를 사용자에게 경로 지정합니다.
다중 사용자로의 대기열 전달
다중 사용자로의 대기열 전달 구현에서는 다음과 같은 여러 가지 대기열 대상 등록 정보을 기반으로 구성 가능한 로드 균형 조정 방법을 사용합니다.
사용자 수가 두 등록 정보의 합계를 초과할 경우 새 사용자가 거부됩니다(Message Queue 플랫폼판은 대기열당 최대 3명의 사용자(2명의 활성 사용자와 1명의 백업 사용자)를 지원하고 Message Queue 엔터프라이즈판은 제한이 없음).
로드 균형 조정 메커니즘에서는 여러 사용자의 메시지 사용 속도를 고려합니다. 구성 가능한 크기(대기열 대상의 사용자 흐름 제한 등록 정보)의 일괄 처리에서 대기열 대상의 메시지를 사용 가능한 새 활성 사용자에게 (대기열에 등록된 순서에 따라) 경로 지정합니다. 이 메시지를 전달한 후 사용자가 사용 가능해지면 대기열에 도착하는 추가 메시지를 일괄 처리로 사용자에게 경로 지정합니다. 사용자가 이전에 전달 받은 메시지의 구성 가능한 비율을 사용하면 사용 가능해지는 것입니다. 즉, 각 사용자의 디스패치 속도는 사용자의 현재 용량과 메시지 처리 속도에 따라 다릅니다.
활성 사용자가 실패한 경우 첫 번째 백업 사용자가 활성화되어 실패한 사용자의 작업을 인수합니다. 이러한 메커니즘 때문에, 대기열 대상에 둘 이상의 활성 사용자가 있는 경우 메시지 사용 순서가 지켜지지 않을 수 있습니다.
메시지 생성 속도가 느린 경우 브로커가 활성 사용자들에게 메시지를 고르지 않게 디스패치할 수 있습니다. 활성 사용자가 필요 이상으로 많은 경우 메시지를 받지 못하는 사용자도 있을 수 있습니다.
브로커 클러스터 환경에서는 다중 사용자로의 전달 시 로컬 사용자를 우선하도록 설정할 수 있습니다. 대기열 대상 등록 정보를 사용하여 생성자의 홈 브로커, 즉 생성자가 메시지를 보낸 브로커(로컬 브로커)에 사용자가 없는 경우에만 메시지를 원격 사용자에게 전달하도록 지정할 수 있습니다. 그러면 원격 사용자의 홈 브로커를 통해 원격 사용자에게 경로 지정할 때 처리량이 떨어질 수 있는 상황에서 성능을 향상시킬 수 있습니다.
주제 대상
주제 대상은 대상에서 인터레스트를 등록한 모든 사용자에게 메시지가 전달되는 게시/가입 메시징에서 사용합니다.
기본 경로 지정 메커니즘
생성자로부터 메시지가 도착하면 해당 주제에 가입한 모든 사용자에게 전달됩니다. 사용자가 해당 주제에 대한 영구 가입에 등록한 경우, 메시지가 도달했을 때 사용자는 활성 상태(메시지를 받기 위한)가 아니어도 됩니다. 브로커는 이 사용자가 다시 한 번 활성화될 때까지 메시지를 보관했다가 전달합니다.
메시지에 선택기 등록 정보 값이 설정되어 있는 경우 브로커는 이 값을 등록된 사용자가 지정한 선택기 값과 비교하여 선택기 값이 일치하는지 확인한 다음 해당 메시지를 사용자에게 경로 지정합니다.
영구 가입 및 클라이언트 식별자
오직 한 사용자만 한 주제에 대한 영구 가입을 가질 수 있습니다. 이 사용자가 메시지 서버에 대한 연결을 열고 닫을 때 사용자의 아이디가 동일해야 합니다. 각 영구 가입이 한 사용자에게만 해당하는지 확인하기 위해 클라이언트 식별자가 사용됩니다.
클라이언트 식별자는 클라이언트를 대신하여 메시지 서버에서 관리하는 상태 정보를 메시지 서버에 대한 클라이언트 연결과 연관시킵니다. 정의에 따라 클라이언트 식별자는 고유합니다.
영구 가입을 작성하려면 클라이언트 식별자를 클라이언트가 JMS API 메소드 호출을 사용하여 프로그래밍 방식으로 설정하거나 클라이언트가 사용하는 연결 팩토리 객체에 관리 방식으로 구성되어야 합니다.
메시지 사용
메시지가 경로 지정되었으면 메시지는 해당 사용자에게 전달됩니다. 사용자가 페이로드 메시지를 수신하면 사용자 클라이언트 런타임은 클라이언트가 메시지를 수신하고 처리했음에 대한 확인을 브로커에게 보냅니다. 브로커는 대상에서 메시지를 삭제하기 전에 이 클라이언트 확인을 기다립니다. 클라이언트 확인은 개별 메시지, 메시지 그룹 또는 트랜잭션에 적용할 수 있습니다.
클라이언트 확인
JMS 사양에 따라 클라이언트는 세션을 작성할 때 세 가지 기본 확인 모드 중 하나를 지정할 수 있습니다. 원하는 메시지 전달 안정성에 따라 모드를 선택합니다.
Message Queue는 NO_ACKNOWLDEGE 모드를 추가하여 클라이언트 확인 모드 집합을 확장합니다. 기본 및 확장 모드는 다음 하위 절에서 설명합니다.
AUTO_ACKNOWLEDGE 모드
AUTO_ACKNOWLEDGE 모드에서 세션은 클라이언트에서 사용하는 각 메시지를 자동으로 확인합니다. 또한 브로커가 사용된 각 메시지에 대해 클라이언트 확인을 처리했음을 확인할 때까지 기다리는 동안 세션 스레드는 차단됩니다. 이러한 확인을 브로커 확인이라고 합니다.
CLIENT_ACKNOWLEDGE 모드
CLIENT_ACKNOWLEDGE 모드는 클라이언트에게 대부분의 제어 기능을 부여합니다. 이 모드에서 클라이언트는 하나 이상의 메시지를 사용한 후 명시적으로 확인합니다. 확인은 클라이언트가 메시지 객체의 acknowledge() 메소드를 호출할 때 발생하므로 세션에서 이전 메소드 호출 이후 해당 세션에서 사용한 모든 메시지를 확인할 수 있게 합니다. 따라서 메시지가 사용된 순서와 관련 없이, 세션의 많은 메시지 수신기에서 비동기식으로 사용된 메시지를 포함할 수 있습니다.
또한 브로커가 클라이언트 확인을 처리했음을 확인해주는, 사용된 메시지의 일괄 처리에 대한 브로커 확인이 반환되길 기다리는 동안 세션 스레드를 차단합니다.
클라이언트 확인 및 브로커 확인은 대개 일괄 처리되므로(하나씩 전달되지 않음), CLIENT_ACKNOWLEDGE 모드를 AUTO_ACKNOWLEDGE 모드와 비교해볼 때 일반적으로 연결 대역폭을 보존하고 브로커 확인에 필요한 오버헤드를 줄입니다. 물론 이 모드에서 클라이언트가 각 메시지를 확인할 경우 일괄 처리가 일어나지 않으며 확인이 하나씩 전송됩니다.
주
Message Queue는 또한 표준 동작이 아닌, 메소드를 호출하는 개별 메시지만 확인할 수 있는 CLIENT_ACKNOWLEDGE 모드에서 사용할 수 있는 특정 메소드를 제공합니다. 이는 Java 클라이언트용 Message Queue 개발 안내서에 설명된 프로그래밍 방법을 사용하면 가능합니다.
DUPS_OK_ACKNOWLEDGE 모드
DUPS_OK_ACKNOWLEDGE 모드에서 세션은 메시지를 10개 사용한 후 확인합니다. 이 값은 현재 구성 가능하지 않습니다. AUTO_ACKNOWLEDGE 또는 CLIENT_ACKNOWLEDGE 모드와 달리 DUPS_OK_ACKNOWLEDGE 모드에서는 브로커 확인을 요청하지 않으므로 브로커 확인을 기다릴 때까지 세션 스레드가 차단되지 않습니다.
이는 메시지가 한 번만 전달되어 사용됨을 보장하지 않는다는 의미입니다. 일반적으로 메시지는 그렇게 자주 다시 전달되지 않으며 실패 시에만 메시지가 전달됩니다. 이 경우 브로커는 자신이 전달한 메시지에 대한 클라이언트 확인을 받지 않습니다. 클라이언트가 중복 전달을 걱정하지 않는다면 DUPS_OK_ACKNOWLEDGE 모드를 사용할 수 있습니다.
클라이언트 확인은 일괄 처리되고 클라이언트 스레드가 차단되지 않으므로 메시지 처리 능력은 일반적으로 다른 모드보다 훨씬 높습니다.
NO_ACKNOWLEDGE 모드
NO_ACKNOWLEDGE 모드에서는 브로커가 클라이언트를 대신하여 클라이언트 확인을 수행하므로 사용자 클라이언트에 의해 메시지가 성공적으로 처리되었는지 보장하지 않습니다.
안정적인 전달은 중요하지 않고 메시지 처리 능력이 중요할 때 이 모드를 사용하십시오. 즉, 메시지가 짧은 간격 동안 주기적으로 전송되어 메시지 로드가 높고 메시지 손실이 크게 문제가 되지 않는 경우일 수 있습니다.
이 모드는 JMS 사양을 확장해야 하므로 다른 JMS 공급자와 함께 작동할 필요가 없는 클라이언트에 의해서만 사용되어야 합니다.
트랜잭션
위에서 설명한 클라이언트와 브로커 확인 과정은 JMS 메시지 전달이 트랜잭션으로 그룹화된 경우에도 적용됩니다. 이 경우 클라이언트와 브로커 확인 과정은 트랜잭션 수준에서 수행되므로 트랜잭션과 관련된 모든 메시지가 포함됩니다. 트랜잭션이 완결되면 브로커 확인이 자동으로 보내집니다.
브로커는 트랜잭션을 추적하면서 트랜잭션 완결 또는 실패 시 롤백이 가능하게 합니다. 또한 이 트랜잭션 관리는 더 큰 규모의 분산 트랜잭션에 포함되는 로컬 트랜잭션을 지원합니다(분산 트랜잭션 참조). 브로커는 트랜잭션이 완결될 때까지 그 상태를 추적합니다. 브로커가 시작되면 이 브로커는 아직 완결되지 않은 모든 트랜잭션을 검사하며, 수동으로 해결해야만 하는 PREPARED 상태의 트랜잭션을 제외하고 모든 트랜잭션을 롤백하도록 기본 설정되어 있습니다.
Message Queue는 XA 연결 팩토리를 통해 분산 트랜잭션 지원을 구현합니다. 이를 통해 XA 연결을 생성하고, XA 연결을 통해 XA 세션을 생성할 수 있습니다. 또한 분산 트랜잭션을 지원하려면 타사의 JTS(Java Transaction Service)나 J2EE 호환 Application Server(JTS를 제공하는)가 필요합니다.
메시지 수명 끝
브로커는 메시지가 전달된 후 대상 메모리에서 메시지를 삭제합니다. 하지만 메시지가 제대로 전달되지 않은 상태에서 삭제되는 경우가 있습니다. 다음 하위 절에서는 메시지가 삭제되는 경우를 설명합니다.
메시지의 정상 삭제
정상적인 상황에서 브로커는 클라이언트 확인을 수신하여 메시지가 성공적으로 전달되었을 때 대상 메모리에서 메시지를 삭제합니다.
브로커가 메시지를 사용자에게 전달할 때 메시지를 전송으로 표시하지만 실제로는 메시지의 수신 및 사용 여부를 알지 못합니다. 따라서 브로커는 메시지를 물리적 대상 및 영구 저장소에서 삭제하기 전에 클라이언트 확인을 기다립니다.
메시지가 주제로 전송되면 브로커는 메시지를 전달한 각 메시지 사용자로부터 클라이언트 확인을 받을 때까지 메시지를 삭제하지 않습니다. 어떤 주제에 영구 가입 시, 브로커는 각 메시지를 해당 대상에 보존하고 각 영구 가입자가 활성 사용자가 되면 메시지를 전달합니다. 브로커는 클라이언트 확인을 수신하면 이를 기록하고 모든 확인을 수신한 후에만(그 전에 메시지가 만료되지 않으면) 메시지를 삭제합니다. 클라이언트 확인 모드에 따라 브로커는 브로커 확인을 다시 클라이언트로 전달하여 클라이언트 확인을 수신했음을 확인해줄 수 있습니다.
브로커 또는 연결이 실패한 경우 브로커는 클라이언트 확인을 수신하지 못했으므로 이전에 전달했지만 확인되지 않은 모든 메시지를 다시 전달하여 이들 메시지를 재전송 플래그로 표시합니다. 예를 들어, 대기열 사용자가 메시지 수신을 확인하기 전에 오프라인 상태가 되고 다른 사용자(같은 사용자라도 됨)가 연이어 대기열에 등록하면 브로커는 확인되지 않은 메시지를 새 사용자에게 다시 전달하고 재전송 플래그로 표시합니다. 이러한 상황에서 메시지 재전송에 대하여 걱정하는 클라이이언트 응용 프로그램은 이 플래그에 대한 메시지를 확인해야 합니다.
주
클라이언트가 수신했지만 아직 확인하지 않은 메시지의 재전송을 명시적으로 요청할 수 있는 JMS API(복구 세션)가 있습니다. 이러한 메시지를 다시 전달할 때 브로커는 해당 메시지를 재전송 플래그로 표시합니다.
메시지의 비정상적 삭제
메시지를 전달할 수 없을 때 메시지 전달을 방해한 상황에 따라서 메시지는 삭제되거나 사용 불능 메시지 대기열에 보관됩니다.
다음과 같은 상황에서 메시지는 성공적으로 전달되어 사용되기 전에 브로커에 의해 삭제됩니다.
하지만 다음과 같은 상황에서는 메시지가 사용 불능으로 간주되며 구성한 동작에 따라서 삭제되거나 사용 불능 메시지 대기열에 보관됩니다.
이러한 메시지를 보유하고 사용 불능 메시지 대기열에 보관하도록 선택할 수 있습니다. 사용 불능 메시지 대기열에 메시지를 보관할 때 브로커는 Message Queue별 등록 정보 값을 메시지에 기록하여 해당 대기열에 보관한 시간과 이유를 지정합니다.
따라서 진단 용도로 사용 불능 메시지 대기열에서 메시지를 검색할 수 있습니다. 자세한 내용은 사용 불능 메시지 대기열을 참조하십시오.
성능 문제메시지 전달의 안정성이 높아질수록 이를 실현하기 위해 더 많은 오버헤드와 대역폭이 필요합니다. 안정성과 성능 간의 균형은 설계 시 고려해야 할 중요한 사항입니다. 비지속성 메시지를 생성하고 사용하도록 선택함으로써 성능을 극대화할 수 있습니다. 한편 지속성 메시지를 생성 및 사용하고 트랜잭션된 세션을 사용할 경우 안정성을 극대화할 수 있습니다. 이 둘 간에는 각 응용 프로그램의 필요 사항에 다양한 옵션이 존재합니다.
예를 들어, 메시지를 처리할 수 있는 속도는 메시징 응용 프로그램 설계, 메시지 서버의 구성 및 클라이언트 런타임의 구성을 비롯한 많은 요인의 산물입니다. 이러한 요인은 매우 개별적이지만 상호 작용하여 성능을 최대화하는 작업을 복잡하게 만들 수 있습니다.
이 절에서는 안정성과 성능간의 균형을 찾는 데 필요한 몇 가지 요인을 간단히 검토합니다.
전달 모드 전달 모드는 메시지가 최대 한 번(비지속성) 또는 단 한 차례(지속성) 전달될 지를 지정합니다. 지속성 메시지를 관리하려면 연결을 통해서 흐르는 브로커 확인 메시지를 사용해야 하고 브로커 확인을 수신할 때까지 기다리면서 차단하는 클라이언트 확인 모드를 사용해야 합니다. 처리 능력을 높이기 위해 브로커 확인을 억제하도록 클라이언트 런타임을 설정할 수 있지만 이 경우 지속성 메시지가 단 한 차례 전달됨을 보장할 수 없습니다.
클라이언트 확인 모드 네 가지 클라이언트 확인 모드 각각은 서로 다른 처리 및 대역폭 오버헤드 수준을 필요로 합니다. AUTO_ACKNOWLEDGE 모드는 가장 많은 오버헤드를 사용하지만 메시지 단위로 안정성을 보장하고 CLIENT_ACKNOWLEDGE 모드는 확인을 일괄 처리하므로 대역폭 오버헤드가 덜 요구되는 반면, DUPS_OK_ACKNOWLEDGE 모드는 가장 적은 오버헤드를 사용하지만 메시지의 중복 전달을 허용합니다. NO_ACKNOWLEDGE 모드는 메시지가 손실될 수 있지만 최고의 성능을 제공합니다.
클라이언트 응용 프로그램 설계 세션의 대기열에 있는 메시지 수는 각 사용자의 메시지 로드와 세션을 사용하는 메시지 사용자 수의 함수입니다. 클라이언트가 메시지를 생성하거나 사용할 때 지연되는 경우 일반적으로 응용 프로그램을 재설계하여 메시지 생성자와 사용자를 더 많은 세션에 분산시키거나 세션을 더 많은 연결에 분산시킴으로써 성능을 향상시킬 수 있습니다. 성능에 영향을 미치는 설계 문제는 Java 클라이언트용 Message Queue 개발 안내서 및 C 클라이언트용 Message Queue 개발 안내서에서 설명합니다.
메시지 흐름 측정 연결 대역폭에 대한 제어 메시지와 페이로드 메시지 간 경합은 클라이언트 런타임에서 관리할 수 있습니다. 클라이언트 런타임을 적절하게 구성하면 브로커 확인 전달 속도를 향상시켜, 차단된 세션 스레드를 해제하고 메시지 사용 속도를 높일 수 있습니다. 자세한 내용은 Message Queue 관리 설명서를 참조하십시오.
메시지 흐름 제한 클라이언트 런타임 자원 제한에 도달하면 메시지 사용 속도가 느려질 수 있습니다. 하나 이상의 사용자가 사용할 때까지 대기하면서, 클라이언트 런타임에 보관되는 메시지 수를 제한하면 이러한 자원 제한을 피할 수 있습니다. 자세한 내용은 Message Queue 관리 설명서를 참조하십시오.
