test

Sun Java System Application Server 9.1 배포 계획 설명서

2장 배포 계획

Application Server를 배포하기 전에 먼저 성능 및 가용성 목표를 결정한 후 이에 따라 하드웨어, 네트워크 및 저장소 요구 사항을 결정해야 합니다.

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

성능 목표 설정

가장 단순한 의미에서 높은 성능이란 처리량 최대화와 응답 시간 감소를 의미합니다. 하지만 이러한 기본 목표를 넘어, 다음을 결정하여 특정 목표를 설정할 수 있습니다.

이러한 메트릭 중 일부는 RBE(원격 브라우저 에뮬레이터) 도구나 예상 응용 프로그램 활동을 시뮬레이트하는 웹 사이트 성능 및 벤치마킹 소프트웨어를 사용하여 계산할 수 있습니다. 일반적으로 RBE와 벤치마킹 제품은 동시 HTTP 요청을 생성한 후 지정된 분당 요청 수에 대한 응답 시간을 보고합니다. 이렇게 산출된 수치를 사용하여 서버 활동을 계산할 수 있습니다.

이 장에 설명된 계산 결과는 절대적 결과가 아닙니다. Application Server와 응용 프로그램의 성능을 미세 조정할 때 기준으로 적용할 참조점으로 사용하십시오.

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

처리량 예측

넓은 의미에서 처리량이란 Application Server에서 수행되는 작업의 양을 나타냅니다. Application Server의 경우 처리량은 서버 인스턴스별 분당 처리되는 요청 수로 정의할 수 있습니다. 고가용성 응용 프로그램은 세션 상태 데이터를 정기적으로 저장하기 때문에 HADB에도 일정 수준 이상의 처리량을 요구합니다. HADB의 처리량은 분당 HADB 요청 수와 요청당 평균 세션 크기를 곱한 값인 분당 저장된 세션 데이터의 양으로 정의할 수 있습니다.

다음 절에 설명된 것처럼 Application Server의 처리량은 사용자 요청의 특징과 크기, 사용자 수, 그리고 Application Server 인스턴스와 백엔드 데이터베이스의 성능을 비롯한 많은 요소로 구성된 함수입니다. 시뮬레이트된 작업 로드를 가지고 벤치마킹함으로써 단일 시스템의 처리량을 예측할 수 있습니다.

고가용성 응용 프로그램은 데이터를 HADB에 정기적으로 저장하기 때문에 추가 오버헤드가 발생합니다. 오버헤드 크기는 데이터의 양, 변경 빈도 및 저장 빈도에 따라 결정됩니다. 처음 두 요소는 해당 응용 프로그램에 따라 결정되며 마지막 요소도 서버 설정의 영향을 받습니다.

HADB 처리량은 분당 HADB 요청 수에 요청당 평균 데이터 양을 곱한 값으로 정의할 수 있습니다. HADB 처리량이 클수록 더 많은 HADB 노드와 더 큰 저장소가 필요합니다.

Application Server 인스턴스의 로드 예측

다음 요소를 고려하여 Application Server 인스턴스의 로드를 예측합니다.

최대 동시 사용자 수

사용자는 웹 브라우저나 Java 프로그램과 같은 클라이언트를 통해 응용 프로그램과 상호 작용합니다. 클라이언트는 사용자의 작업에 따라 정기적으로 Application Server에 요청을 보냅니다. 세션이 만료되거나 종료되지 않는 한 사용자는 활성 상태로 간주됩니다. 동시 사용자 수를 예측할 때 이러한 모든 활성 사용자를 포함합니다.

다음 그림은 분당 처리되는 요청 수(처리량) 대 사용자 수를 나타내는 일반적인 그래프입니다. 처음에는 사용자 수가 증가함에 따라 처리량이 증가합니다. 그러나 동시 요청 수가 증가함에 따라 서버 성능이 포화되기 시작하고 처리량이 감소하기 시작합니다.

동시 사용자를 추가함으로써 분당 처리할 수 있는 요청 수가 감소하는 지점을 확인할 수 있습니다. 이 지점은 최적 성능에 도달한 후 처리량이 감소하기 시작하는 시점을 나타냅니다. 일반적으로, 가능한 한 높은 최적 처리량으로 시스템을 작동하도록 노력해야 합니다. 추가 로드를 처리하고 처리량을 높이기 위해 처리 용량을 추가해야 할 수 있습니다.

인지 시간

사용자는 요청을 지속적으로 제출하지 않습니다. 사용자가 요청을 제출하면 서버에서는 요청을 수신하여 처리한 후 사용자가 새 요청을 제출하기 전 시간이 소비되는 시점에 결과를 반환합니다. 한 요청과 다음 요청 사이의 시간을 인지 시간이라고 합니다.

인지 시간은 사용자 유형에 따라 다릅니다. 예를 들어 웹 서비스의 경우와 같은 시스템 간 상호 작용은 일반적으로 사람이 사용자인 경우보다 낮은 인지 시간을 포함합니다. 또한, 시스템과 인간 상호 작용의 혼합을 고려하여 인지 시간을 예측해야 할 수 있습니다.

평균 인지 시간 결정은 중요한 작업입니다. 이 기간을 사용하여 분당 완료해야 하는 요청 수는 물론 시스템에서 지원할 수 있는 동시 사용자 수를 계산할 수 있습니다.

평균 응답 시간

응답 시간이란 Application Server가 사용자에게 요청 결과를 반환하는 데 걸리는 시간을 말합니다. 응답 시간은 네트워크 대역폭, 사용자 수, 제출된 요청의 수와 유형, 그리고 평균 인지 시간과 같은 요소의 영향을 받습니다.

이 절에서 응답 시간은 중간 또는 평균 응답 시간을 나타냅니다. 각 요청 유형에는 고유한 최소 응답 시간이 있습니다. 그러나 시스템 성능을 평가할 때는 모든 요청의 평균 응답 시간을 기반으로 분석합니다.

응답 시간이 빠를수록 처리되는 분당 요청 수는 증가합니다. 하지만 다음 그림에 나타난 것처럼 분당 요청 수가 감소하더라도 시스템의 사용자 수가 증가함에 따라 응답 시간이 증가하기 시작합니다.

죄송합니다. 이 설명서 버전에서는 그래픽을 사용할 수 없습니다.

이 그림과 같은 시스템 성능 그래프에 따르면 특정 시점 이후 분당 요청 수는 응답 시간에 반비례합니다. 분당 요청 감소량이 급격할수록 응답 시간의 증가가 더 가파릅니다(점선 화살표로 표시).

그림에서 최대 로드 지점은 분당 요청 수가 감소하기 시작하는 지점입니다. 이 지점 이전의 응답 시간 계산에는 공식에 최대 수치가 사용되지 않기 때문에 반드시 정확할 필요는 없습니다. 이 지점 이후에는 분당 요청과 응답 시간 사이의 반비례 관계 때문에 관리자가 최대 사용자 수 및 분당 요청 수를 사용하여 응답 시간을 더욱 정확하게 계산할 수 있습니다.

다음 공식을 사용하여 최대 로드 시 응답 시간(초)인 Tresponse를 결정합니다.

Tresponse = n/r - Tthink

여기서,

예 2–1 응답 시간 계산

다음과 같은 조건이 있는 경우

평균 인지 시간 Tthink는 요청당 3초입니다.

즉, 응답 시간은 다음과 같이 계산됩니다.

Tresponse = n/r - Tthink = (5000/ 1000) - 3초= 5 - 3초

따라서 응답 시간은 2초입니다.

특히 최대 로드 시 시스템 응답 시간을 계산한 후 응용 프로그램에 대한 허용되는 응답 시간과 비교합니다. 처리량과 함께 응답 시간은 Application Server의 성능에 있어 중요한 기본 요소 중 한 가지입니다.

분당 요청 수

지정된 시간의 동시 사용자 수, 해당 요청의 응답 시간 및 평균 사용자 인지 시간을 알고 있으면 분당 요청 수를 계산할 수 있으며, 일반적으로 시스템에 있는 동시 사용자 수 예측부터 시작합니다.

예를 들어 웹 사이트 성능 소프트웨어를 실행한 후 관리자는 온라인 은행 웹 사이트에서 요청을 제출하는 평균 동시 사용자 수가 3,000이라는 결론을 내립니다. 이 수치는 온라인 은행 회원으로 가입한 사용자 수, 사용자의 은행 업무 트랜잭션 동작, 사용자가 요청을 제출하려고 선택한 시간대나 요일 등에 따라 결정됩니다.

따라서 이 정보를 알고 있으면 이 절에 설명된 분당 요청 수에 대한 공식을 사용하여 시스템에서 이 사용자 기준에 따라 처리할 수 있는 분당 요청 수를 계산할 수 있습니다. 최대 로드 시 분당 요청 수와 응답 시간은 반비례하므로 응답 시간 향상을 위해 허용되는 분당 요청 수를 낮출 것인지 분당 요청 수를 높이기 위해 허용되는 응답 시간을 늦출 것인지를 결정합니다.

시스템 성능을 미세 조정할 시작점에서 허용되는 분당 요청 수 및 응답 시간 임계값을 시험합니다. 그런 다음 조정이 필요한 시스템 영역을 결정합니다.

이전 절의 수식에서 r은 다음과 같이 구할 수 있습니다.

r = n/(Tresponse + Tthink)

예 2–2 분당 요청 수 계산

조건은 다음과 같습니다.

초당 요청 수는 다음과 같이 계산합니다.

r = 2800 / (1+3) = 700

따라서 초당 요청 수는 700이고 분당 요청 수는 42000입니다.

HADB의 로드 예측

HADB의 로드 계산에는 다음 요소를 고려합니다.

세션 지속성 구성에 대한 자세한 내용은 Sun Java System Application Server 9.1 고가용성 관리 설명서의 9 장, 고가용성 세션 지속성 및 페일오버 구성을 참조하십시오.

HTTP 세션 지속성 빈도

HADB에서 수신하는 분당 요청 수는 지속성 빈도에 따라 결정됩니다. 지속성 빈도는 Application Server가 HTTP 세션 데이터를 HADB에 저장하는 빈도를 결정합니다.

지속성 빈도 옵션은 다음과 같습니다.

다음 표는 지속성 빈도 옵션의 장점 및 단점에 대한 간략한 설명입니다.

표 2–1 지속성 빈도 옵션 비교

지속성 빈도 옵션 

장점 

단점 

web-method 

항상 최신 세션 정보를 사용할 수 있습니다. 

응답 시간이 증가하고 처리량이 감소할 수 있습니다. 

time-based 

응답 시간이 향상되고 처리량이 향상될 수 있습니다. 

Application Server 인스턴스에 오류가 발생한 뒤에 최신 세션 정보를 사용하지 못할 수 있습니다. 

HTTP 세션 크기 및 범위

요청당 세션 크기는 세션에 저장된 세션 정보의 양에 따라 결정됩니다.

정보 –

전체 성능을 향상시키려면 세션 정보의 양을 최대한 줄이십시오.

지속성 범위 설정을 통해 요청당 세션 크기를 미세 조정할 수 있습니다. 다음 HTTP 세션 지속성 범위 옵션 중에서 선택합니다.

이 옵션을 사용하려면 응용 프로그램이 다음을 충족해야 합니다.

표 2–2 지속성 범위 옵션 비교

지속성 범위 옵션 

장점 

단점 

modified-session 

세션 상태를 수정하지 않고 요청에 대한 향상된 응답 시간을 제공합니다.  

일반적으로 웹 메소드 doGet() 또는 doPost()를 실행하는 동안 응용 프로그램은 다음 세션 메소드를 호출해야 합니다.

  • 속셩이 변경된 경우 setAttribute()

  • 속성이 제거된 경우 removeAttribute()

session 

응용 프로그램에 대한 제약 조건이 없습니다. 

modified-session 및 modified-attribute 옵션에 비해 처리량과 응답 시간이 저하될 수 있습니다.

modified-attribute 

수정된 세션 상태 비율이 낮은 요청에 대한 처리량과 응답 시간이 향상됩니다. 

지정된 요청에 대해 수정된 세션 상태 비율이 60%에 가까우면 처리량과 응답 시간이 저하됩니다. 이 경우 속성을 개별 레코드로 분할하는 오버헤드 때문에 성능이 다른 옵션보다 더 저하됩니다.  

Stateful Session Bean 검사점 지정

SFSB 세션 지속성의 경우 HADB의 로드는 다음에 따라 결정됩니다.

트랜잭션이 롤백되는 경우에도 검사점 지정은 일반적으로 SFSB 관련 트랜잭션이 완료된 후에 수행됩니다.

성능을 향상시키려면 검사점 지정을 위해 소수의 메소드 집합을 지정합니다. 검사점 지정되는 데이터 크기와 검사점 지정 빈도에 따라 지정된 클라이언트 상호 작용에 대한 응답 시간의 추가 오버헤드가 결정됩니다.

네트워크 구성 계획

Application Server를 네트워크로 통합하는 방법을 계획할 때 대역폭 요구 사항을 예측하고 사용자의 성능 요구 사항에 맞출 수 있는 방식으로 네트워크를 계획합니다.

이 절은 다음 내용으로 구성됩니다.

대역폭 요구 사항 예측

원하는 네트워크 크기 및 대역폭을 결정하려면 먼저 네트워크 트래픽을 결정하고 그 최대치를 확인합니다. 전체 양이 최대치에 도달하는 특정 시간, 요일 또는 일자가 있는지 확인하여 트래픽 최대 기간을 결정합니다.

최대 로드 시간 동안 네트워크의 패킷 수는 최고 수준에 도달합니다. 일반적으로 최대 로드를 사용하도록 설계할 경우 최대 양을 100% 처리하도록 시스템 크기를 조정합니다. 그러나 네트워크는 예상치 않게 동작하며, 네트워크 크기를 조정하더라도 최대 양의 100%를 처리하지 못하는 경우가 발생할 수 있다는 사실에 유의해야 합니다.

예를 들어 최대 로드 시 Application Server에 배포된 응용 프로그램에 액세스할 때 사용자의 5%가 간혹 네트워크에 즉시 액세스할 수 없다고 가정합니다. 이 5%의 사용자 중에서 첫 시도 이후 액세스를 다시 시도하는 사용자 수를 예측합니다. 다시 이 사용자 중 일부가 액세스에 실패할 수 있고 이러한 실패한 부분 중 일부 사용자가 또 다시 시도합니다. 따라서 사용자가 계속 액세스를 시도하는 시간 전체에 걸쳐 최대 사용이 분산되기 때문에 최대 로드가 더 오래 나타납니다.

필요 대역폭 계산

성능 목표 설정에서 계산한 결과에 따라 사이트에서 Application Server를 배포하는 데 필요한 추가 대역폭을 결정합니다.

액세스 방식(T-1 회선, ADSL, 케이블 모뎀 등)에 따라 예측된 로드를 처리하는 데 필요한 추가 증가 대역폭 크기를 계산합니다. 예를 들어 사이트에서 T-1 또는 더 높은 속도의 T-3 회선을 사용한다고 가정합니다. 대역폭이 제공되면 해당 사이트에서 초당 생성된 평균 요청 수와 최대 로드 최대값에 따라 네트워크에 필요한 회선 수를 예측합니다. 웹 사이트 분석 및 모니터링 도구를 사용하여 이러한 수치를 계산합니다.

예 2–3 필요 대역폭 계산

단일 T-1 회선은 1.544Mbps를 처리할 수 있습니다. 따라서 T-1 회선 4개로 구성된 네트워크는 약 6Mbps의 데이터를 처리할 수 있습니다. 클라이언트로 반환된 평균 HTML 페이지가 30KB인 경우 T-1 회선 4개로 구성된 이 네트워크는 다음과 같은 초당 트래픽을 처리할 수 있습니다.

6,176,000비트/8비트 = 초당 772,000바이트

초당 772,000바이트/30KB = 초당 약 25개의 동시 응답 페이지

초당 25페이지의 트래픽이 있는 이 시스템에서는 하루 내내 균일한 로드 처리량이 제공된다는 가정 하에 시간당 90,000페이지(25 x 60초 x 60분), 따라서 하루에 최대 2,160,000페이지를 처리할 수 있습니다. 최대 로드 최대값이 이 값보다 큰 경우 대역폭을 적절하게 늘립니다.

최대 로드 예측

하루 내내 균일한 로드 처리량을 제공하는 것은 실제로 불가능할 수 있습니다. 최대 로드 발생 시기, 지속 기간 및 총 로드에 대한 최대 로드 비율을 결정해야 합니다.

예 2–4 최대 로드 계산

최대 로드가 2시간 동안 지속되고 전체 로드의 30%인 2,160,000페이지를 차지할 경우 해당 시간 동안 T-1 회선을 통해 648,000페이지를 전송해야 합니다.

따라서 이 2시간 동안 최대 로드를 수용하려면 다음 계산에 따라 T-1 회선 수를 늘려야 합니다.

648,000페이지/120분 = 분당 5,400페이지

분당 5,400페이지/60초 = 초당 90페이지

4개 회선이 초당 25페이지를 처리할 수 있는 경우 해당 페이지 수의 약 4배에는 회선 수의 4배가 필요하므로 이 경우 16개 회선이 필요합니다. 16개의 회선은 30%의 최대 로드 최대값을 실제로 처리할 수 있음을 의미합니다. 나머지 70%의 로드는 하루 중 나머지 시간 동안 이러한 여러 회선을 통해 처리할 수 있습니다.

서브넷 구성

응용 프로그램 서버 인스턴스와 HADB 노드가 각기 다른 호스트 시스템에 있는 개별 계층 토폴로지를 사용할 경우 모든 HADB 노드를 별도의 서브넷에 배치하여 성능을 향상시킬 수 있습니다. 이는 HADB에서 UDP(User Datagram Protocol)를 사용하기 때문입니다. 별도 서브넷을 사용하면 해당 서브넷 외부 시스템에 대한 UDP 트래픽이 감소합니다.그러나 모든 HADB 노드는 동일한 서브넷에 있어야 합니다.

모든 노드 및 관리 에이전트가 같은 서브넷에 있는 한 관리 클라이언트를 다른 서브넷에서 실행할 수 있습니다. 모든 노드 에이전트에서 모든 호스트와 포트에 액세스할 수 있어야 하고 노드가 방화벽, UDP 차단 등으로 차단되면 안 됩니다.

HADB에는 UDP 멀티캐스트가 사용되므로 HADB 노드가 포함된 서브넷은 멀티캐스트를 사용하도록 구성해야 합니다.

네트워크 카드 선택

큰 대역폭과 최적의 네트워크 성능을 위해 Application Server를 호스팅하는 서버와 HADB 노드 사이에 최소 100Mbps의 이더넷 카드 또는 1Gbps 이더넷 카드(권장)를 사용합니다.

HADB를 위한 네트워크 설정

주 –

HADB는 UDP 멀티캐스트를 사용하므로 시스템의 라우터와 호스트 네트워크 인터페이스 카드에서 멀티캐스트를 활성화해야 합니다. HADB가 여러 하위 네트워크에 걸쳐 있으면 하위 네트워크 사이의 라우터에서도 멀티캐스트를 활성화해야 합니다. 최상의 결과를 얻으려면 HADB 노드를 모두 같은 네트워크에 배치합니다. Application Server 인스턴스는 다른 하위 네트워크에 존재할 수 있습니다.

다음은 네트워크에서 HADB가 최적의 상태로 작동하기 위한 권장 사항입니다.

가용성 계획

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

가용성 조정

시스템 및 응용 프로그램의 가용성을 계획하려면 여러 응용 프로그램에 액세스하는 사용자 그룹의 가용성 요구 사항을 평가합니다. 예를 들어 외부 유료 사용자와 비즈니스 파트너는 종종 내부 사용자보다 더 높은 QoS(서비스 품질) 기대치를 갖습니다. 따라서 응용 프로그램 기능이나 응용 프로그램, 또는 서버를 사용할 수 없게 되는 경우 내부 사용자가 외부 유료 고객보다 상황을 잘 받아들입니다.

다음 그림은 점점 감소하는 발생 가능한 이벤트를 완화하기 위해 증가하는 비용과 복잡성을 보여줍니다. 연속선상의 한쪽 끝인 로드 균형이 조정된 단순 클러스터의 경우 현지화된 응용 프로그램, 미들웨어 및 하드웨어 오류를 허용합니다. 반대편 끝의 지리적으로 떨어져 있는 클러스터의 경우 전체 데이터 센터에 영향을 주는 주요 재난을 완화할 수 있습니다.

적절한 투자 수익률(ROI) 실현을 위해 응용 프로그램 내 기능의 가용성 요구 사항을 확인하는 작업은 종종 의미가 있습니다. 예를 들어 보험 견적 시스템을 사용할 수 없게 되어 잠재적으로 새 비즈니스를 놓치는 상황은 허용될 수 없지만 기존 고객이 현재 보상 범위를 볼 수 있는 계정 관리 기능의 경우 잠시 사용할 수 없더라도 기존 고객을 잃게 되지는 않습니다.

클러스터를 사용하여 가용성 향상

가장 기본적인 수준의 클러스터는 대개 여러 개의 물리적 서버에서 호스팅되지만 클라이언트에 단일 인스턴스로 나타나는 Application Server 인스턴스의 그룹입니다. 클러스터는 단일 시스템의 단일 인스턴스보다 높은 가용성과 수평 확장성을 제공합니다. 이 기본 수준 클러스터링은 HTTP 및 HTTPS 요청을 수신하여 클러스터 내 Application Server 인스턴스 중 하나로 전달하는 Application Server의 HTTP 로드 밸런서 플러그인과 함께 작동합니다. ORB와 통합 JMS 브로커도 Application Server 클러스터에 대한 로드 균형 조정을 수행합니다. 한 인스턴스에 오류가 발생하거나 네트워크 오류 때문에 사용할 수 없게 되거나 응답하지 않으면 요청이 기존에 있던 사용 가능한 시스템으로만 리디렉션됩니다. 또한 로드 밸런서는 실패한 인스턴스가 복구되었을 때를 인식하고 그에 따라 로드를 재분산할 수 있습니다.

HTTP 로드 밸런서는 서버와 특정 URL을 모니터하여 사용 가능 여부를 확인할 수 있는 상태 검사기 프로그램도 제공합니다. 상태 검사 자체가 큰 부담이 되지 않도록 상태 검사 오버헤드 관리에 유의해야 합니다.

상태 비보존형 응용 프로그램이나 중요하지 않은 단순 사용자 트랜잭션만 관련된 응용 프로그램의 경우 로드 균형이 조정된 단순 클러스터만으로 대개 충분합니다. 업무상 중요한 상태 보존형 응용 프로그램의 경우 세션 지속성을 위해 HADB를 사용하는 것이 좋습니다. HADB에 대한 개요를 보려면 Application Server 관리 설명서의 1 장, 제품 개념에서 고가용성 데이터베이스를 참조하십시오.

응용 프로그램을 온라인으로 업그레이드하려면 Application Server 인스턴스를 여러 클러스터로 그룹화하는 것이 좋습니다. Application Server에는 응용 프로그램과 인스턴스를 모두 정지하는 기능이 있습니다. 정지는 현재 인스턴스나 응용 프로그램을 사용하는 사용자에게 영향을 주지 않고 제어된 방식으로 인스턴스(또는 인스턴스 그룹)나 특정 응용 프로그램을 오프라인으로 전환하는 기능입니다. 한 인스턴스가 정지됨에 따라 새 사용자는 다른 인스턴스의 업그레이드된 응용 프로그램을 사용하게 됩니다. 이러한 응용 프로그램 업그레이드 유형을 롤링 업그레이드라고 합니다. 활성 응용 프로그램 업그레이드에 대한 자세한 내용은 Sun Java System Application Server 9.1 고가용성 관리 설명서의 가용성 손실 없이 응용 프로그램 업그레이드 를 참조하십시오.

시스템에 중복 장치 추가

고가용성을 얻기 위한 한 가지 방법으로 하드웨어 및 소프트웨어를 중복하여 시스템에 추가할 수 있습니다. 한 장치에 오류가 발생하면 중복 장치가 역할을 인계 받게 되는데, 이를 내결함성이라고도 합니다. 일반적으로 고가용성을 극대화하기 위해 시스템의 모든 가능한 오류 지점을 확인 및 제거합니다.

오류 클래스 확인

중복 수준은 시스템이 허용해야 하는 오류 클래스(오류 유형)에 의해 결정됩니다. 다음은 오류 클래스의 몇 가지 예입니다.

중복 시스템 프로세스는 단일 시스템 프로세스 오류 및 단일 시스템 오류를 허용합니다. 미러된(쌍을 이룬) 중복 시스템을 다른 전원 공급 장치에 연결할 경우 단일 전원 오류가 허용됩니다. 미러된 시스템을 다른 건물에서 유지할 경우 한 건물에서 발생한 화재를 허용할 수 있습니다. 미러된 시스템을 지리적으로 격리된 위치에서 유지하면 지진과 같은 자연 재난을 허용할 수 있습니다.

HADB 중복 장치를 사용하여 가용성 향상

가용성을 향상시키기 위해 HADB 노드는 성능 목표 설정의 설명대로 항상 DRU(Data Redundancy Unit)에서 사용됩니다.

HADB 예비 노드를 사용하여 내결함성 향상

예비 노드를 사용하면 내결함성이 향상됩니다. 예비 노드는 필수 항목은 아니지만 최대 가용성을 제공합니다.

페일오버 용량 계획

페일오버 용량 계획은 서버나 프로세스 오류 시 시스템 중단 없이 데이터를 복구하고 처리를 계속할 수 있도록 Application Server 배포에 추가해야 하는 추가 서버 및 프로세스의 수를 결정하는 작업입니다. 시스템이 오버로드되면 프로세스나 서버 오류가 발생하여 응답 시간 저하나 전체 서비스 손실을 초래할 수 있습니다. 성공적인 배포에는 반드시 이러한 상황에 대한 대비가 있어야 합니다.

특히 최대 로드 시 용량을 유지하려면 Application Server 인스턴스를 실행하는 예비 시스템을 기존 배포에 추가합니다.

예를 들어 각각 한 개의 Application Server 인스턴스를 실행하는 시스템 두 대로 구성된 시스템을 가정할 경우 두 대의 시스템에서 초당 요청이 300개에 달하는 최대 로드를 함께 처리합니다. 두 시스템 간 로드 분산이 균일하다고 했을 때 둘 중 한 대의 시스템을 사용할 수 없게 될 경우 이 시스템은 요청을 150개만 처리할 수 있으므로 최대 로드 시 요청의 절반이 처리되지 않습니다.

설계 결정 사항

설계 결정 사항에는 시스템 설계를 최대 로드에 맞출 것인지 고정 상태 로드에 맞출 것인지에 대한 선택과 다양한 역할의 시스템 수 및 해당 시스템 크기가 포함됩니다.

최대 로드 설계 또는 고정 상태 로드 설계

일반적인 배포에서 고정 상태 작업 로드와 최대 작업 로드 사이에는 다음과 같은 차이가 있습니다.

시스템에서 최대 로드를 처리하게 될 빈도에 따라 설계 기준이 최대 로드 또는 고정 상태 로드로 결정됩니다.

최대 로드가 하루 중에도 여러 번 발생하는 경우에는 최대 로드를 처리할 용량을 확장하는 것이 좋은 선택이 될 수 있습니다. 시스템이 작동 시간의 90%는 고정 상태 로드로 작동하고 나머지 10%의 시간 동안만 최대 로드 상태에서 작동하는 경우에는 고정 상태 로드를 중심으로 설계된 시스템을 배포하는 것이 바람직합니다. 이는 시스템의 응답 시간이 10%에 해당하는 시간 동안만 느려진다는 것을 의미합니다. 시스템이 최대 로드에서 작동하는 빈도나 지속 시간을 확인하여 자원을 시스템에 추가해야 하는지 여부를 결정합니다.

시스템 크기 조정

Application Server 인스턴스의 로드, HADB의 로드 및 페일오버 요구 사항에 따라 다음을 결정할 수 있습니다.

Application Server 인스턴스 수

각 인스턴스는 둘 이상의 CPU(Central Processing Unit)를 사용할 수 있지만 필요한 Applications Server 인스턴스(호스트) 수를 결정하려면 각 Application Server 인스턴스에 대해 Application Server 인스턴스의 로드 예측에 설명된 요소를 기초로 환경을 평가합니다.

HADB 노드 수

일반적인 지침으로 시스템에서 CPU별로 하나의 HADB 노드를 포함하도록 계획합니다. 예를 들어 CPU가 두 개인 하나의 시스템에 HADB 노드 두 개를 사용합니다.

주 –

더 큰 시스템을 사용하는 경우처럼 시스템당 둘 이상의 HADB 노드가 있는 경우에는 시스템에 여러 개의 무정전 전원 공급 장치, 독립 디스크 컨트롤러 등 충분한 중복성과 확장성이 있어야 합니다.

또는 다음 절차를 사용합니다.

Procedure필요한 HADB 노드 수를 결정하는 방법

  1. 다음 매개 변수를 결정합니다.

    • 최대 동시 사용자 수 n users

    • 평균 BLOB 크기 s

    • 사용자당 최대 처리 속도(NTPS)

  2. 최대 기본 데이터 양의 크기(GB)를 나타내는 V data를 결정합니다.

    다음 공식을 사용합니다.

    V data = nusers .s

  3. 최대 HADB 데이터 전송 속도 R dt를 결정합니다.

    이 값은 응용 프로그램측에서 HADB로 전송되는 데이터 양을 반영합니다. 다음 공식을 사용합니다.

    Rdt = nusers .s .NTPS

  4. 노드 수 N NODES를 결정합니다.

    다음 공식을 사용합니다.

    NNODES = V data /5GB

    노드는 쌍으로 작동하므로 이 값을 짝수로 반올림합니다.

HADB 호스트 수

데이터 전송 요구 사항에 따라 HADB 호스트 수를 결정합니다. 이 계산에서는 모든 호스트의 하드웨어 구성과 운영 체제가 비슷하고 호스트에서 실행하는 노드를 수용하는 데 필요한 자원이 있다고 가정합니다.

Procedure호스트 수를 계산하는 방법

  1. 최대 호스트 데이터 전송 속도 R max를 결정합니다.

    이 값은 네트워크와 호스트 하드웨어에 따라 결정되므로 경험을 기초로 결정합니다. 이 값은 이전 절에서 결정한 최대 HADB 데이터 전송률 R dt와 다른 값입니다.

  2. 이 데이터를 수용하는 데 필요한 호스트 수를 결정합니다.

    호스트 수 N HOSTS에 분산된 데이터의 양 V를 업데이트하면 각 호스트가 약 4V/N HOSTS의 데이터를 수신합니다. 다음 공식으로 이 데이터 양을 수용하는 데 필요한 호스트 수를 결정합니다.

    NHOSTS = 4 .Rdt / Rmax

    각 DRU의 호스트 수를 같게 하기 위해 이 값을 가장 가까운 짝수로 반올림합니다.

  3. 각 DRU에 예비 노드용 호스트를 하나씩 추가합니다.

    다른 호스트가 각기 N개의 데이터 노드를 실행할 경우 이 호스트에서 N개의 예비 노드를 실행하게 합니다. 그러면 N개 데이터 노드를 다운시키는 단일 시스템 오류가 허용됩니다.

    각 호스트는 하나 이상의 노드를 실행해야 하므로 노드 수가 호스트 수보다 작을 경우(NNODES < NHOSTS) NNODES를 NHOSTS와 같아지도록 조정합니다. 노드 수가 호스트 수보다 큰 경우에는(NNODES \> NHOSTS) 동일한 호스트에서 여러 개의 노드를 실행할 수 있습니다.

HADB 저장 용량

HADB는 네트워크 용량이 초과될 때까지 노드를 추가할 수 있으므로 직선에 가까운 확장이 가능합니다. 각 노드는 전용 디스크의 저장 장치에 구성되어야 합니다. 모든 노드에는 저장 장치에 할당된 크기에 상당하는 공간이 있어야 합니다. 저장 장치가 로컬 디스크에 할당되어 있는지 확인합니다.

예상 세션 데이터 크기를 xMB라고 가정합니다. HADB에서는 데이터를 미러 노드에 복제하므로 2xMB의 저장소가 필요합니다. 또한 HADB는 색인을 사용하여 데이터에 빠르게 액세스할 수 있도록 합니다. 두 개의 노드에는 색인에 사용할 추가 2xMB가 필요하므로 전체 4x의 저장 용량이 필요합니다. 따라서 HADB의 예상 저장 용량 요구 사항은 예상 데이터 양의 4배입니다.

새 노드를 추가한 후 데이터를 다시 단편화해야 할 수 있으므로 향후 HADB의 데이터 손실 없는 확장을 고려하면 온라인 업그레이드를 위한 추가 저장 용량을 제공해야 합니다. 이 경우 데이터 장치에 비슷한 크기의 추가 공간(4x)이 필요합니다. 따라서 예상 저장 용량은 예상 데이터 양의 8배입니다.

또한 HADB에서는 다음과 같은 디스크 공간이 사용됩니다.

다음은 xMB의 세션 데이터에 대한 HADB 저장 공간 요구 사항을 간략하게 설명한 표입니다.

표 2–3 XMB의 세션 크기에 대한 HADB 저장 공간 요구 사항

조건 

필요한 HADB 저장 공간 

온라인일 필요가 없는 상태에서 HADB 노드 추가 또는 제거

4xMB + (4*로그 버퍼 크기) + 장치 크기의 1%

온라인이여야 하는 상태에서 HADB 노드 추가 또는 제거 

8xMB + (4*로그 버퍼 크기) + 장치 크기의 1%

HADB는 장치 공간이 부족할 경우 데이터를 삽입하거나 업데이트하는 클라이언트 요청을 허용하지 않지만 삭제 작업은 허용합니다. HADB에 장치 공간이 부족하면 오류 코드 4593 또는 4592가 반환되고 해당 오류 메시지가 내역 파일에 기록됩니다. 이러한 메시지에 대한 자세한 내용은 Sun Java System Application Server 9.1 Error Message Reference의 14 장, HADB Error Messages를 참조하십시오.

Message Queue 브로커 배포 계획

Java Message Service(JMS) API는 J2EE 응용 프로그램 및 구성 요소가 메시지를 작성하고, 보내고, 받고, 읽을 수 있도록 하는 메시징 표준입니다. 또한 느슨하게 결합되고 안정적인 비동기식 분산 통신을 가능하게 합니다. JMS를 구현하는 Sun Java System Message Queue는 Application Server와 통합되어 MDB(Message-Driven Bean)와 같은 구성 요소를 만들 수 있도록 합니다.

Sun Java System Message Queue(MQ)는 J2EE Connector Architecture(JCA) 사양 1.5에서 정의된 자원 어댑터라고도 하는 커넥터 모듈을 사용하여 Application Server와 통합됩니다. 커넥터 모듈은 Application Server에 기능을 추가하는 표준화된 방법입니다. Application Server에 배포된 J2EE 구성 요소는 커넥터 모듈을 통해 통합된 JMS 공급자를 사용하여 JMS 메시지를 교환합니다. 기본적으로 JMS 공급자는 Sun Java System Message Queue이지만 원하는 경우 JCA 1.5를 구현하는 다른 JMS 공급자를 사용할 수 있습니다.

Application Server에서 JMS 자원을 만들면 백그라운드에서 커넥터 자원이 만들어집니다. 따라서 각 JMS 작업은 커넥터 런타임을 호출하며 백그라운드에서 MQ 자원 어댑터를 사용합니다.

자원 어댑터 API 사용 외에도 Application Server에서는 추가 MQ API를 사용하여 MQ와 향상된 통합을 제공합니다. 이러한 긴밀한 통합으로 인해 MDB에 대한 커넥터 페일오버, 아웃바운드 연결의 로드 균형 조정 및 인바운드 메시지의 로드 균형 조정과 같은 기능을 사용할 수 있습니다. 이러한 기능은 메시징 트래픽에 내결함성과 고가용성을 제공합니다.

다중 브로커 클러스터

MQ Enterprise Edition에서는 브로커 클러스터라고도 하는 여러 개의 상호 연결된 브로커 인스턴스를 사용할 수 있습니다. 브로커 클러스터를 사용하면 클라이언트 연결이 클러스터에 있는 모든 브로커 간에 분산됩니다. 클러스터링은 수평적 확장을 제공하며 가용성을 향상시킵니다.

단일 메시지 브로커는 약 8개까지 CPU를 확장할 수 있으며 일반적인 응용 프로그램에 충분한 처리량을 제공합니다. 브로커 프로세스에 오류가 발생하면 브로커가 자동으로 다시 시작됩니다. 그러나 브로커에 연결된 클라이언트 수가 증가하고 전달되는 메시지 수가 증가함에 따라 브로커는 결국 파일 설명자 수 및 메모리 등의 제한을 초과하게 됩니다.

한 클러스터에 단일 브로커가 아니라 여러 개의 브로커를 사용하면 다음이 가능합니다.

그러나 브로커가 여러 개 있어도 브로커 오류 발생 시 진행 중인 트랜잭션이 대체 브로커에서 계속되지 않을 수도 있습니다. MQ에서 실패한 연결을 클러스터 내 다른 브로커와 다시 설정하지만 진행 중인 트랜잭션 메시징과 롤백 트랜잭션이 손실됩니다. 완료하지 못한 트랜잭션을 제외하고 사용자 응용 프로그램에는 영향이 없습니다. 연결을 계속 사용할 수 있으므로 서비스 페일오버가 보장됩니다.

따라서 MQ는 클러스터에서 고가용성 지속성 메시징을 지원하지 않습니다. 브로커가 오류 발생 이후 다시 시작되면 지속성 메시지 전달을 자동으로 복구하여 완료합니다. 지속성 메시지는 파일 시스템 또는 데이터베이스에 저장될 수 있습니다. 그러나 브로커를 호스팅하는 시스템의 하드웨어 고장이 복구되지 않으면 메시지가 손실될 수 있습니다.

Sun Message Queue용 Sun Cluster 데이터 서비스가 설치된 Solaris 플랫폼에서는 지속성 메시지의 투명한 페일오버를 지원합니다. 이 구성은 Sun Cluster의 전역 파일 시스템과 IP 페일오버를 사용하여 신뢰할 수 있는 고가용성을 제공하며 Java Enterprise System에 포함되어 있습니다.

마스터 브로커와 클라이언트 동기화

다중 브로커 구성에서 각 대상은 클러스터 내 모든 브로커에서 복제됩니다. 각 브로커는 다른 모든 브로커의 대상에 등록된 메시지 사용자를 인식합니다. 따라서 각 브로커는 직접 연결된 해당 고유 메시지 생성자에서 원격 메시지 사용자로 메시지를 라우팅하고 원격 생성자에서 직접 연결된 해당 고유 사용자로 메시지를 전달합니다.

클러스터 구성에서 각 메시지가 생성자가 직접 연결된 브로커는 해당 생성자에 의해 브로커에 전송된 메시지의 라우팅을 수행합니다. 따라서, 지속성 메시지는 메시지의 홈 브로커에 의해 저장 및 라우팅됩니다.

관리자가 브로커에서 대상을 만들거나 삭제할 때마다 이 정보는 클러스터에 속한 다른 모든 브로커에 자동으로 전파됩니다. 마찬가지로 메시지 사용자가 홈 브로커에 등록될 때마다 또는 명시적으로 지정되었거나 클라이언트나 네트워크 오류, 홈 브로커 다운으로 인해 메시지 사용자가 홈 브로커에서 연결이 끊어질 때마다 해당 메시지 사용자에 대한 관련 정보가 클러스터 전체에 전파됩니다. 영구 가입 정보도 비슷한 방식으로 클러스터의 모든 브로커에 전파됩니다.

Message Queue 브로커를 사용하도록 Application Server 구성

Application Server의 Java Message Service는 Message Queue에 대한 커넥터 모듈(자원 어댑터)을 나타냅니다. 관리 콘솔이나 asadmin 명령줄 유틸리티를 사용하여 Java Message Service를 관리할 수 있습니다.

MQ 브로커(JMS 호스트)는 Application Server 프로세스와 다른 JVM에서 실행됩니다. 따라서 여러 Application Server 인스턴스나 클러스터가 같은 MQ 브로커 집합을 공유할 수 있습니다.

Application Server에서 JMS 호스트는 MQ 브로커를 나타냅니다. Application Server의 Java Message Service 구성에는 사용할 모든 JMS 호스트가 포함된 JMS 호스트 목록(AddressList)이 있습니다.

관리 콘솔을 사용하여 JMS 관리

관리 콘솔에서 Java Message Service 노드를 사용하여 특정 구성에 대한 JMS 등록 정보를 설정할 수 있습니다. 다시 연결 간격 및 다시 연결 시도와 같은 등록 정보를 설정할 수 있습니다. 자세한 내용은 Sun Java System Application Server 9.1 관리 설명서의 4 장, JMS(Java Message Service) 자원 구성을 참조하십시오.

Java Message Service 노드 아래의 JMS 호스트 노드에는 JMS 호스트 목록이 포함되어 있습니다. 목록에서 호스트를 추가 및 제거할 수 있습니다. 각 호스트에 대한 호스트 이름, 포트 번호, 그리고 관리 사용자 이름 및 비밀번호를 설정할 수 있습니다. 기본적으로 JMS 호스트 목록에는 Application Server와 통합된 로컬 MQ 브로커를 나타내는 “default_JMS_host”라는 MQ 브로커가 포함되어 있습니다.

클러스터의 모든 MQ 브로커를 포함하도록 JMS 호스트 목록을 구성합니다. 예를 들어 세 개의 MQ 브로커가 포함된 클러스터를 설정하려면 브로커별로 Java Message Service 내에 JMS 호스트를 추가합니다. Message Queue 클라이언트는 Java Message Service의 구성 정보를 사용하여 MQ 브로커와 통신합니다.

asadmin을 사용하여 JMS 관리

관리 콘솔 외에도 asadmin 명령줄 유틸리티를 사용하여 Java Message Service와 JMS 호스트를 관리할 수 있습니다. 다음 asadmin 명령을 사용합니다.

Java Message Service 유형

Application Server와 MQ 브로커 간 통합에는 로컬과 원격의 두 가지 유형이 있습니다. 관리 콘솔의 Java Message Service 페이지에서 이 유형 속성을 설정할 수 있습니다.

로컬 Java Message Service

유형 속성이 LOCAL인 경우 Application Server에서 MQ 브로커를 시작 및 중지합니다. Application Server가 시작될 때 기본 JMS 호스트로 지정된 MQ 브로커를 시작합니다. 마찬가지로 Application Server 인스턴스가 종료될 때 MQ 브로커를 종료합니다. 독립 실행형 Application Server 인스턴스에는 LOCAL 유형이 가장 적절합니다.

LOCAL 유형을 사용할 경우 Start Arguments 속성을 사용하여 MQ 브로커 시작 매개 변수를 지정합니다.

원격 Java Message Service

유형 속성이 REMOTE인 경우 Application Server에서는 외부에서 구성된 브로커나 브로커 클러스터를 사용합니다. 이 경우 Application Server와는 별도로 MQ 브로커를 시작 및 중지해야 하며 MQ 도구를 사용하여 브로커 또는 브로커 클러스터를 구성하고 조정해야 합니다. REMOTE 유형은 Application Server 클러스터에 가장 적절합니다.

REMOTE 유형을 사용할 경우 MQ 도구를 사용하여 MQ 브로커 시작 매개 변수를 지정해야 합니다. Start Arguments 속성은 무시됩니다.

기본 JMS 호스트

관리 콘솔의 Java Message Service 페이지에서 기본 JMS 호스트를 지정할 수 있습니다. Java Message Service 유형이 LOCAL인 경우 Application Server 인스턴스가 시작될 때 Application Server에서 기본 JMS 호스트를 시작합니다.

MQ 브로커 클러스터를 사용하려면 기본 JMS 호스트를 삭제한 다음 클러스터의 모든 MQ 브로커를 JMS 호스트로 추가합니다. 이 경우 JMS 호스트 목록의 첫 번째 JMS 호스트가 기본 JMS 호스트가 됩니다.

JMS 호스트 중 하나를 기본 JMS 호스트로 지정하여 설정할 수도 있습니다. Application Server에서 Message Queue 클러스터를 사용할 경우 기본 JMS 호스트가 MQ 특정 명령을 실행합니다. 예를 들어 MQ 브로커 클러스터에 대한 물리적 대상을 만들 때 기본 JMS 호스트는 물리적 대상을 만드는 명령을 실행하지만 클러스터의 모든 브로커는 물리적 대상을 사용합니다.

배포 시나리오 예

메시징 요구 사항을 수용하려면 배포, 성능 및 가용성 요구에 맞게 Java Message Service와 JMS 호스트 목록을 수정합니다. 다음 절에서는 몇 가지 일반적인 시나리오에 대해 설명합니다.

최상의 가용성을 얻기 위해서는 메시징 요구 사항이 Application Server와 맞지 않을 경우 MQ 브로커와 Application Server를 서로 다른 시스템에 배포하거나, 메시징 용량이 충분해질 때까지 각 시스템에서 Application Server 인스턴스와 MQ 브로커를 실행합니다.

기본 배포

Application Server를 설치하면 DAS(Domain Administration Server)가 자동으로 생성됩니다. 기본적으로 DAS의 Java Message Service 유형은 LOCAL입니다. 따라서 DAS를 시작하면 기본 MQ 브로커도 시작됩니다.

새 도메인을 만들면 새 브로커도 생성됩니다. 기본적으로 독립 실행형 서버 인스턴스나 클러스터를 도메인에 추가하면 해당 Java Message Service는 REMOTE로 구성되며 DAS에 의해 시작되는 브로커가 기본 JMS 호스트가 됩니다.

기본 배포에서는 세 개의 인스턴스가 포함된 Application Server 클러스터를 사용한 기본 배포의 예를 보여줍니다.

Application Server 클러스터와 함께 MQ 브로커 클러스터 사용

MQ 브로커 클러스터를 사용하도록 Application Server를 구성하려면 Application Server의 Java Message Service에서 모든 MQ 브로커를 JMS 호스트로 추가합니다. 생성된 모든 JMS 연결 팩토리와 배포된 MDB는 지정된 JMS 구성을 사용합니다.

다음 그림은 브로커 클러스터의 MQ 브로커 세 개와 클러스터의 Application Server 인스턴스 세 개를 사용하는 배포 예를 보여줍니다.

응용 프로그램 특정 MQ 브로커 클러스터 지정

경우에 따라 응용 프로그램은 Application Server 클러스터에서 사용하는 MQ 브로커 클러스터와 다른 클러스터를 사용해야 할 수 있습니다. 응용 프로그램 특정 MQ 브로커 클러스터 지정에서는 이러한 시나리오의 예를 보여줍니다. 이를 위해서는 JMS 연결 팩토리의 AddressList 등록 정보나 MDB 배포 설명자의 activation-config 요소를 사용하여 MQ 브로커 클러스터를 지정합니다.

연결 팩토리 구성에 대한 자세한 내용은 Sun Java System Application Server 9.1 관리 설명서의 JMS 연결 팩토리를 참조하십시오. MDB에 대한 자세한 내용은 Sun Java System Application Server 9.1 Developer’s Guide의 Using Message-Driven Beans를 참조하십시오.

응용 프로그램 클라이언트

응용 프로그램 클라이언트나 독립 실행형 응용 프로그램에서 JMS 관리 대상 객체에 처음 액세스하면 클라이언트 JVM이 서버에서 Java Message Service 구성을 검색합니다. 클라이언트 JVM을 다시 시작해야 JMS 서비스의 추가 변경 사항을 사용할 수 있습니다.