test

Sun Java System Message Queue 3.7 UR1 관리 설명서

성능에 영향을 미치는 요소

두 가지 주요 성능 표시기인 메시지 대기 시간과 메시지 처리량은 일반 메시지가 메시지 전달 프로세스의 여러 단계를 완료하는 데 걸리는 시간에 따라 달라집니다. 아래는 안정적으로 전달되는 지속성 메시지인 경우에 대해 이러한 단계를 보여 줍니다. 단계는 다음 그림과 같습니다.

그림 11–1 Message Queue 서비스를 통한 메시지 전달

안정적으로 전달되는 지속성 메시지의 메시지 전달 프로세스 단계를 보여 주는 다이어그램. 단계에 대한 설명은 그 다음에 나오는 텍스트에 있음.

Procedure메시지 전달 단계

  1. 메시지가 생성자 클라이언트에서 브로커로 전달됩니다.

  2. 브로커가 메시지를 읽습니다.

  3. 안정성을 위해 메시지가 영구 저장소에 저장됩니다.

  4. 안정성을 위해 브로커가 메시지 수신을 확인합니다.

  5. 브로커가 메시지 경로 지정을 결정합니다.

  6. 브로커가 메시지를 씁니다.

  7. 메시지가 브로커에서 사용자 클라이언트로 전달됩니다.

  8. 안정성을 위해 사용자 클라이언트가 메시지 수신을 확인합니다.

  9. 안정성을 위해 브로커가 클라이언트 확인을 처리합니다.

  10. 브로커가 클라이언트 확인이 처리되었는지 확인합니다.

    이러한 단계는 순차적이므로 어느 단계든 생성자 클라이언트에서 사용자 클라이언트로 메시지를 전달할 때 병목 현상을 일으킬 수 있습니다. 이러한 단계들은 대부분 네트워크 대역폭, 컴퓨터 처리 속도, 메시지 서비스 구조 등 메시징 시스템의 물리적 특성에 영향을 받습니다. 하지만 일부 단계는 메시징 응용 프로그램의 특성과 메시징 응용 프로그램이 요구하는 안정성 수준에 따라서도 달라집니다.

    다음 하위 절에서는 응용 프로그램 설계 요소와 메시징 시스템 요소가 성능에 미치는 영향을 설명합니다. 응용 프로그램 설계와 메시징 시스템 요소가 메시지 전달에서 긴밀하게 상호 작용하지만 각 범주에 대해 별도로 고려합니다.

성능에 영향을 미치는 응용 프로그램 설계 요소

응용 프로그램 설계 결정은 전체 메시징 성능에 상당한 영향을 미칠 수 있습니다.

성능에 영향을 미치는 가장 중요한 요소는 메시지 전달의 안전성에 영향을 미치는 요소입니다. 이러한 요소는 다음과 같습니다.

성능에 영향을 미치는 다른 응용 프로그램 설계 요소는 다음과 같습니다.

다음 절에서는 이러한 요소 각각이 메시징 성능에 미치는 영향을 설명합니다. 일반적으로 성능과 안정성은 동시에 얻을 수 없습니다. 즉, 안정성을 높이는 요소가 성능을 저하시키는 경향이 있습니다.

표 11–1은 여러 응용 프로그램 설계 요소가 일반적으로 메시징 성능에 어떤 영향을 미치는지 보여 줍니다. 이 표에서는 두 가지 시나리오(높은 안정성/낮은 성능 시나리오와 높은 성능/낮은 안정성 시나리오)와 각각을 특징 지우는 응용 프로그램 설계 요소의 선택을 보여 줍니다. 이러한 양극단 사이에는 안정성과 성능 모두에 영향을 미치는 여러 선택 사항과 상충이 있습니다.

표 11–1 높은 안정성 및 높은 성능 시나리오 비교

응용 프로그램 설계 요소 

높은 안정성, 낮은 성능 시나리오 

높은 성능, 낮은 안정성 시나리오 

전달 모드 

지속성 메시지 

비지속성 메시지 

트랜잭션 사용 

트랜잭션된 세션 

트랜잭션 없음 

확인 모드 

AUTO_ACKNOWLEDGE or CLIENT_ACKNOWLEDGE

DUPS_OK_ACKNOWLEDGE

영구/비영구 가입 

영구 가입 

비영구 가입 

선택기 사용 

메시지 필터링 

메시지 필터링 없음 

메시지 크기 

많은 수의 작은 메시지 

적은 수의 큰 메시지 

메시지 본문 유형 

복합 본문 유형 

단순 본문 유형 

전달 모드(지속성/비지속성 메시지)

지속성 메시지는 브로커에 오류가 발생하는 경우 메시지 전달을 보장합니다. 브로커는 의도된 모든 사용자가 메시지 사용을 확인할 때까지 메시지를 영구 저장소에 저장합니다.

다음과 같은 이유로 브로커의 지속성 메시지 처리가 비지속성 메시지 처리보다 느립니다.

영구 가입자가 있는 대기열과 주제는 비영구 메시지에 비해 속도가 약 40% 향상되었습니다. 이는 10k 크기 메시지와 AUTO_ACKNOWLEDGE 모드에서 생성된 결과입니다.

트랜잭션 사용

트랜잭션은 트랜잭션된 세션에서 생성된 모든 메시지와 트랜잭션된 세션에서 사용된 모든 메시지가 하나의 단위로 처리되거나 처리되지 않도록(롤백되도록) 보장합니다.

Message Queue는 로컬 트랜잭션과 분산 트랜잭션을 모두 지원합니다.

트랜잭션된 세션에서의 메시지 생성이나 확인은 다음과 같은 이유 때문에 트랜잭션되지 않은 세션보다 느립니다.

확인 모드

JMS 메시지 전달의 안정성을 보장하는 한 가지 방법은 Message Queue 브로커가 클라이언트에 전달한 메시지 사용에 대해 클라이언트가 확인 응답을 보내는 것입니다.

클라이언트의 메시지 확인 없이 세션이 닫히거나 확인이 처리되기 전에 브로커에 오류가 발생하는 경우 브로커는 해당 메시지를 재전송하여 JMSRedelivered 플래그를 설정합니다.

트랜잭션되지 않은 세션의 경우 클라이언트는 각각 고유한 성능 특성을 가지는 다음과 같은 세 가지 확인 모드 중 하나를 선택할 수 있습니다.

(CLIENT_ACKNOWLEDGE 모드를 사용하는 것은 처리 중에 공급자 오류가 발생하는 경우 모든 확인이 함께 처리되도록 보장하지 않는다는 점을 제외하고는 트랜잭션 사용과 유사합니다.)

확인 모드는 다음과 같은 이유로 성능에 영향을 미칩니다.

영구 및 비영구 가입

주제 대상의 가입자는 영구 가입자와 비영구 가입자의 두 가지 범주로 구분됩니다.

영구 가입은 다음과 같은 이유로 안정성이 향상되지만 처리량이 떨어집니다.

지속성 및 비지속성 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는 복잡성 순서에 따라 아래에 대략적으로 표시된 다섯 개의 메시지 본문 유형을 지원합니다.

일반적으로 메시지 유형은 응용 프로그램의 필요에 따라 제어되지만 좀 더 복잡한 유형(MapMessage 및 ObjectMessage)은 성능 저하(데이터 일련화 및 일련화 해제로 인한 저하)를 수반합니다. 성능 저하는 데이터의 단순성이나 복잡성에 따라 달라집니다.

성능에 영향을 미치는 메시지 서비스 요소

메시징 응용 프로그램의 성능은 응용 프로그램 설계뿐만 아니라 메시지 라우팅 및 전달을 수행하는 메시지 서비스의 영향도 받습니다.

다음 절에서는 성능에 영향을 미칠 수 있는 여러 메시지 서비스 요소를 설명합니다. 이러한 요소의 영향을 이해하는 것은 메시지 서비스 크기를 지정하고 배포된 응용 프로그램에서 발생할 수 있는 성능 병목 현상을 진단하고 해결하는 데 중요합니다.

Message Queue 서비스에서 성능에 영향을 미치는 가장 중요한 요소는 다음과 같습니다.

아래의 절에서는 이러한 각 요소가 메시징 성능에 미치는 영향을 설명합니다.

하드웨어

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의 처리량을 비교했습니다.

일반적으로 프로토콜은 높은 안정성 사례에서 미치는 영향이 더 적습니다. 이는 아마도 높은 안정성 사례에서 필요한 지속성 오버헤드가 처리량을 제한하는 데 프로토콜 속도보다 더 중요한 요소이기 때문일 것입니다. 또는

메시지 서비스 구조

Message Queue 메시지 서비스는 단일 브로커로 구현되거나 다중 상호 연결 브로커 인스턴스로 구성된 클러스터로 구현될 수 있습니다.

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

일반적으로 이러한 확장은 클라이언트, 특히 메시지 생성자 클라이언트가 클러스터 전체에 균등하게 분산되어 있는 경우에 가장 잘 작동합니다. 클러스터에 있는 브로커 사이의 메시지 전달과 관련된 오버헤드로 인해 제한된 연결 수나 메시지 전달 비율을 갖는 클러스터는 단일 브로커보다 더 낮은 성능을 보일 수 있습니다.

또한 브로커 클러스터를 사용하여 네트워크 대역폭을 최적화할 수 있습니다. 예를 들어, 클러스터 내의 원격 브로커들 사이에는 느린 장거리 네트워크 링크를 사용하고 클라이언트와 해당 브로커 인스턴스의 연결에는 고속 링크를 사용할 수 있습니다.

클러스터에 대한 자세한 내용은 9 장, 브로커 클러스터 작업을 참조하십시오.

브로커 제한 및 동작

브로커가 처리해야 하는 메시지 처리량은 브로커가 지원하는 메시징 응용 프로그램의 사용 패턴에 달려 있습니다. 하지만 브로커는 메모리, CPU 사이클 등 자원이 제한되어 있습니다. 따라서 브로커가 넘치게 되어 응답하지 않거나 불안정하게 될 수 있습니다.

Message Queue 메시지 브로커에는 메모리 자원을 관리하고 브로커의 메모리 부족을 방지하기 위해 기본적으로 제공되는 메커니즘이 있습니다. 이러한 메커니즘은 브로커나 개별 물리적 대상이 보유할 수 있는 메시지 수나 메시지 바이트에 대한 구성 가능한 제한을 포함하며 물리적 대상 제한에 이르면 시작될 수 있는 동작 집합을 포함합니다.

이러한 구성 가능한 메커니즘은 세밀하게 모니터하고 조정하면 메시지 유입과 유출의 균형을 유지하여 시스템 과부하가 발생할 수 없도록 하는 데 사용할 수 있습니다. 이 메커니즘은 오버헤드를 사용하고 메시지 처리량을 제한하는 단점이 있지만 운영 무결성을 유지할 수 있습니다.

데이터 저장소 성능

Message Queue는 파일 기반 및 JDBC 기반 지속성 모듈을 모두 지원합니다. 파일 기반 지속성에서는 개별 파일을 사용하여 영구 데이터를 저장합니다. JDBC 기반 지속성은 JDBC™(Java Database Connectivity) 인터페이스를 사용하고 JDBC 호환 데이터 저장소가 필요합니다. 일반적으로 파일 기반 지속성은 JDBC 기반보다 빠르지만, JDBC 호환 저장소가 제공하는 중복 및 관리 제어 기능을 선호하는 사용자도 있습니다.

파일 기반 지속성의 경우 지속성 작업이 메모리 상태에서 데이터 저장소와 동기화되도록 지정하여 안정성을 최대화할 수 있습니다. 이렇게 하면 시스템 중단으로 인한 데이터 손실을 방지할 수 있지만 성능은 저하됩니다.

클라이언트 런타임 구성

Message Queue 클라이언트 런타임은 클라이언트 응용 프로그램에 Message Queue 메시지 서비스에 대한 인터페이스를 제공합니다. 이 클라이언트 런타임은 클라이언트가 물리적 대상에게 메시지를 보내고 대상으로부터 메시지를 받는 데 필요한 모든 작업을 지원합니다. 연결 팩토리 속성 값을 설정하여 클러이언트 런타임을 구성할 수 있으므로 연결 흐름 측정, 사용자 흐름 제한 및 연결 흐름 제한과 같은 다양한 동작 측면을 제어하여 성능 및 메시지 처리량을 향상시킬 수 있습니다. 이러한 기능과 기능을 구성하는 데 사용되는 속성에 대한 자세한 내용은 클라이언트 런타임 메시지 흐름 조정을 참조하십시오.