성능 결과 정보
테스트에 사용되는 시스템은 프랑크푸르트 및 암스테르담 Oracle Cloud Infrastructure(OCI) 리전에 구성된 Oracle Fusion Middleware(FMW) 확장 클러스터입니다.
WebLogic 도메인은 다양한 토폴로지의 성능 비교를 가능하게 하기 위해 서로 다른 위치에 분산된 5개의 노드로 구성됩니다. 즉, 데이터베이스와 동일한 가용성 도메인에서 실행되는 서버, 동일한 영역이지만 다른 가용성 도메인에 있는 서버, 다른 영역에 있는 서버입니다.
이러한 스트레스 테스트는 SOA Fusion 주문 데모(FOD)를 샘플 SOA 애플리케이션으로 사용하여 수행되었습니다. 주문이 완료될 때 UD(Uniform Distributed Destination) 대상에 JMS(Java Message Service) 메시지를 삽입하도록 FOD 데모가 수정되었습니다. 이 예제는 데이터베이스 중심이며 파일 어댑터 및 JMS 어댑터와 같은 여러 SOA 어댑터를 사용합니다. 또한 Mediator, BPEL(Business Process Execution Language), 규칙 엔진 및 여러 WebLogic 기능과 같은 다양한 SOA 구성 요소가 포함됩니다.
다음 다이어그램은 테스트에 사용되는 FMW 확장 클러스터 환경을 보여줍니다.
fmw-stretched-performance-env-oracle.zip
이 환경의 네트워크 간 실제 대기 시간 값은 다음과 같습니다.
| 호스트 간 | 평균 대기 시간(밀리초) |
|---|---|
| 동일한 가용성 도메인 내 | 0.3 |
| 동일한 리전에서는 동일하지만 다른 가용성 도메인에 있음 | 0.6 |
| 다른 지역(프랑크푸르트 및 암스테르담) | 6.5 |
스트레스 테스트 검토
테스트된 구성 중 일부는 다음과 같습니다.
- 두 개의 노드로 클러스터를 응력하여 서버 간 및 서버 중 하나 간에 서로 다른 대기 시간을 데이터베이스에 적용합니다.
- 각각 데이터베이스에 대해 서로 다른 대기 시간을 가진 개별 서버를 테스트합니다.
- 두 서버가 모두 데이터베이스와 함께 배치(로컬만 해당)되고 두 서버가 데이터베이스에서 원격으로 배치(원격만 해당)된 상태에서 테스트를 실행합니다.
- 각 영역에서 2개의 노드가 활성화된 클러스터를 응력합니다.
각 구성에 대해 서로 다른 작업 로드가 테스트되었습니다. 모든 작업 로드 요청은 Oracle WebLogic Server 인스턴스 간에 전역 로드 밸런싱, 로컬 로드 밸런서, 웹 서버 순으로 분산되는 프론트 엔드로 먼저 전송됩니다. 작업 로드 범주(낮음, 중간, 높음)는 각 설정의 활성 노드 수에 따라 다르며 데이터베이스의 동시성 제한에 의해 제약을 받습니다. 예를 들어, 4개의 노드가 실행 중인 경우 WebLogic 서버에 대해 동시 가상 사용자 80명이 낮은 작업량으로 간주되지만 한 노드만 활성 상태인 경우 높은 작업량으로 간주됩니다. 하지만 데이터베이스의 관점에서 보면 작업 로드는 동일하게 유지됩니다. 단순화를 위해 사용되는 작업 로드는 다음과 같습니다.
- 낮은 작업 로드(WebLogic 서버당 동시 가상 사용자 20명, 시스템의 총 동시 가상 사용자 40명)
- 중간 작업 로드(WebLogic 서버당 동시 가상 사용자 40-60명, 시스템의 총 동시 가상 사용자 120명)
- 높은 워크로드(WebLogic 서버당 동시 가상 사용자 80명, 시스템의 총 동시 가상 사용자 160명)
스트레스 테스트 결과에 따라 결론은 다음과 같습니다.
- 전체 클러스터 성능
서버가 두 개인 클러스터에 대한 전체 클러스터 성능(WebLogic 처리량, 초당 트랜잭션(TX/초))은 다음과 같습니다.
- 두 서버가 동일한 AD(가용성 도메인)에 있는 경우(참조로 사용됨): 100%
- 각 서버가 다른 AD에 있는 경우: ~100%
- 한 서버가 다른 지역에 있을 때(6.5ms RTT(왕복 시간)): 90~95%
- 두 서버가 DB와 다른 지역에 있는 경우(6.5ms RTT): 85-95%
- 서버별 성능
서버별 성능(WebLogic 처리량, TX/초 기준):
- DB와 동일한 AD에 있는 서버의 경우(참조로 사용): 100%
- 다른 AD에 있는 서버의 경우: 98-99%
- 다른 지역의 서버: 85-90%
- 활성 데이터 소스 접속 수
활성 데이터 소스 연결 수가 늘어나고 대기 시간이 높아집니다. 작업 로드에 따라 다르지만 영역 2의 서버는 데이터베이스와 함께 배치된 서버보다 최대 2x의 활성 연결을 표시합니다. WebLogic 데이터 소스 및 데이터베이스 세션의 크기를 정확하게 조정하려면 이 옵션을 고려하십시오.
- JTA 트랜잭션
JTA 트랜잭션은 데이터베이스에 대한 대기 시간이 더 높은 서버에서 장기간 활성 상태로 유지됩니다. 장기간 활성 상태로 남아 있는 트랜잭션은 Failure의 영향을 받을 가능성이 높습니다. 따라서 이러한 시스템에서는 트랜잭션 로그가 JDBC 영구 저장소를 사용하는 것이 특히 중요합니다. 서버 장애의 경우 서비스 마이그레이션이 발생하고 복구가 자동으로 수행됩니다.
- 영역 간 대기 시간
6.5ms RTT의 리전 간 대기 시간 및 FMW 확장 클러스터에 대한 이 문서에서 제공하는 모범 사례 구현:
- 확장된 클러스터를 사용하여 성능 저하가 낮습니다(~10%).
- 각 영역에 하나의 서버가 있고 원격 영역에 두 서버가 모두 있는 클러스터가 있는 클러스터의 경우 비슷한 성능 저하가 발생합니다. 이는 클러스터 내 통신도 대기 시간의 영향을 받기 때문입니다.
- AD 간 대기 시간
AD 간 대기 시간(0.6ms)은 SOA FOD 시스템의 전체 성능에 큰 영향을 주지 않습니다.
주:
위의 모든 사항을 염두에 두고 여러 테스트에서 성능 저하가 관찰된 경우 Oracle은 사이트 간 10밀리초의 대기 시간(RTT)을 초과하는 Oracle Fusion Middleware 확장 클러스터를 지원하지 않습니다. 시스템은 문제 없이 작동할 수 있지만 트랜잭션 시간은 상당히 증가합니다. 10밀리초(RTT)를 초과하는 대기 시간도 배치 및 JT, 웹 서비스 또는 애플리케이션 시간 초과에 사용되는 Oracle Coherence 클러스터의 문제를 야기합니다. 따라서 이 플레이북에 제시된 솔루션은 주로 사이트 간 대기 시간이 짧은 사이트 또는 지역에 적합합니다.
2개의 노드로 클러스터를 응력시킬 때 다음 차트는 서버의 위치에 따라 클러스터의 전체 성능을 보여줍니다. 참조(100%)는 두 서버가 데이터베이스와 동일한 AD에서 실행되는 경우입니다.
2개의 노드로 클러스터를 제한하는 경우 다음 차트는 데이터베이스와 함께 배치되지 않은 서버(다른 AD 또는 원격 영역에 있음)의 성능을 데이터베이스와 함께 배치한 서버의 성능과 비교하여 보여줍니다.
노드가 2개인 클러스터를 강조 표시할 때 이러한 차트는 각 서버에 대한 활성 데이터 소스 연결 수(평균)를 표시합니다. 한 서버는 항상 데이터베이스(site1)와 함께 배치되며 다른 서버는 데이터베이스(site2)와 다른 대기 시간 값에 위치합니다.
데이터베이스 대기 시간이 서로 다른 단일 서버에 스트레스가 발생하면 중간에서 높은 로드로 데이터베이스와 함께 배치된 서버에 비해 다음과 같은 성능 결과가 관찰됩니다. 참조(100%)는 서버가 데이터베이스와 동일한 AD에 있는 경우입니다.
대기 시간이 다른 단일 서버를 데이터베이스에 연결하도록 지정할 경우 이는 중간에서 높은 스트레스 아래의 활성 데이터 소스 연결입니다.
데이터베이스에 대해 서로 다른 대기 시간을 가진 단일 서버를 강조 표시할 때 다음 이미지는 데이터베이스에 대한 서로 다른 대기 시간의 평균 JTA 활성 시간을 보여줍니다.
데이터베이스와 동일한 리전의 두 서버(로컬 전용)와 데이터베이스와 다른 리전의 두 서버(원격 전용)가 있는 클러스터의 성능을 비교할 때 다음과 같은 성능 결과가 관찰됩니다. 참조(100%)는 로컬 전용 클러스터입니다.
다음 그림은 데이터베이스와 동일한 영역에서 실행되는 서버(로컬만 해당)와 데이터베이스와 다른 영역에서 두 서버를 모두 실행하는 클러스터(원격만 해당)의 클러스터에 대한 평균 JTA TX 활성 시간을 보여줍니다.
시작 시간 검토
데이터 소스의 초기 용량 설정에 따라 다른 지연이 예상됩니다. 기본적으로 대부분의 Oracle Fusion Middleware(FMW) 데이터 소스는 연결 풀에 0 초기 용량을 사용합니다. 그러나 일반 런타임 작업 중 시스템의 응답 시간을 줄이려면 초기 풀 용량을 늘리는 것이 좋습니다. 그러나 확장된 클러스터에서 데이터베이스에 원격으로 상주하는 서버는 초기 풀 용량이 높을수록 시작 시 대기 시간이 증가합니다.
정상 작동 중 응답 시간을 최적화하고 시작 시간을 최소화하여 이상적인 초기 용량 설정을 결정하는 사이에 균형 잡힌 결정이 필요합니다. 초기 용량은 데이터 소스(접속 풀) 레벨에서 구성되므로 이러한 설정은 클러스터 내의 모든 서버(데이터베이스에 로컬인 서버 및 원격 서버에 대한 서버)의 시작 시간에 영향을 줍니다.
다음 그래프는 모든 데이터 소스의 여러 초기 크기 값(총 11개의 데이터 소스)에 대해 데이터베이스에 대한 대기 시간이 증가함에 따라 WebLogic 서버 시작 시간을 보여줍니다.
JMS 서비스 이전 시간 검토
그러나 데이터베이스 대기 시간으로 인해 리전 1에서 리전 2로 서비스 마이그레이션 작업에 걸리는 시간이 증가할 수 있습니다. 이 증가는 다른 지역의 데이터베이스에 있는 영구 저장소에서 읽혀지므로 다른 서버의 메시지를 복구하는 데 소요되는 시간에 의해 발생합니다.
영구 저장소에 보류 중인 메시지가 많은 경우 증분이 더 높습니다. 크기가 각각 2.7KB인 JMS 메시지의 경우 다음 이미지는 영구 저장소 중 하나에 보류 중인 메시지 수가 많고(약 8000개) 대상 서버와 데이터베이스 간의 대기 시간이 다르기 때문에 서비스가 데이터베이스와 함께 배치된 서버에서 다른 서버로 이전되는 JMS 서비스 이전 시간을 보여줍니다.
다음 이미지는 대상 서버와 데이터베이스 간의 서로 다른 대기 시간에 대해 보류 중인 메시지(약 8000개) 수가 많은 서비스 마이그레이션 시간 증분(%)을 보여줍니다. 참조(100%)는 서비스가 데이터베이스와 동일한 AD(가용성 도메인)에 있는 서버로 마이그레이션되는 경우입니다.
다음 이미지는 대상 서버와 데이터베이스 간의 대기 시간이 서로 다르지만 보류 중인 메시지 수가 적은(약 50개)의 마이그레이션 시간을 보여줍니다.
다음 이미지는 대상 서버와 데이터베이스 간의 서로 다른 대기 시간에 대해 보류 중인 메시지 수가 적은 JMS 서비스 이전 시간 증분(%)을 보여줍니다(약 50). 참조(100%)는 서비스가 데이터베이스와 동일한 AD에 있는 서버로 마이그레이션되는 경우입니다.
SOA 조합 배치 시간 검토
조합을 배치(첫번째 버전을 배치하거나 최신 버전으로 업데이트)할 때 영역 1의 서버에 영역 2의 서버보다 먼저 조합이 배치될 수 있습니다. 단, 클러스터의 모든 멤버에서 사용할 수 있을 때까지 공식적으로 활성화되지는 않습니다.
다음 그림은 데이터베이스와 동일한 AD(가용성 도메인)에 상주하는 서버에 컴포지트를 로드하는 데 걸린 시간과 비교하여 서버 시작 중 서버의 컴포지트를 로드하는 데 걸린 시간 증가를 보여줍니다. 조합 크기는 365KB입니다.
다음 이미지는 데이터베이스에 대한 배치를 수행하는 서버와 다른 대기 시간에 대해 Oracle WebLogic 스크립팅 툴(WLST) 명령을 사용하여 조합을 배치하는 데 걸린 시간 증가를 보여줍니다.
사이트 간 트래픽 검토
그러나 이러한 격리는 결정적이지 않습니다. 예를 들어, JMS(Java Message Service) 호출이 두 사이트에서 발생할 수 있는 페일오버 시나리오를 위한 공간이 있습니다. 즉, 일반적인 애플리케이션의 경우 Oracle WebLogic Server 인스턴스와 데이터베이스 간에 대부분의 트래픽이 발생합니다. Oracle Fusion Middleware(FMW) 확장된 클러스터 토폴로지 성능의 핵심이 됩니다. 이 이미지는 스트레스 테스트 중 영역 2의 WebLogic 서버와 영역 1의 서로 다른 주소 간 트래픽 비율을 보여줍니다. 영역 1에 있는 서버와 데이터베이스 간에 트래픽이 90% 이상 발생합니다.
사이트 간 IP당 트래픽 양을 캡처하기 위해 iftop 도구를 사용할 수 있습니다. 예:
sudo iftop -i ens3 -F <remote_site_CIDR> -n -t -s 900다음 이미지는 스트레스 테스트 중 영역 2의 WebLogic 서버와 영역 1의 서로 다른 주소 간 트래픽 비율을 보여줍니다.
