DTA 추적의 MST 측정을 위한 테스트 시나리오
이러한 모든 작업이 실제로 작동하는 방식을 보여 주고 추적용 MST(유지 가능한 최대 처리량)를 측정하는 간단한 기술을 소개하기 위해 추적 MST 측정을 위한 테스트 시나리오를 제공합니다. 여기에는 관련된 기술뿐만 아니라 다른 시스템에 대한 추적 성능을 측정하는 시작점으로 사용할 수 있는 데이터도 제공되어 있습니다.
중요
이 항목에 포함된 정보는 게시된 날짜를 기준으로 논의된 문제에 대한 Microsoft의 현재 관점을 나타냅니다. Microsoft에서는 변화하는 시장 상황과 기술에 반응해야 하므로 게시 날짜 이후에 제공되는 모든 정보의 정확성을 보장할 수는 없습니다.
테스트 시나리오 토폴로지 및 구성
다음 그림은 테스트 시나리오의 토폴로지 및 구성을 보여 줍니다. 4개의 MessageBox 데이터베이스 서버, 전용 BizTalkDTADb 데이터베이스 서버 및 BizTalk Server 실행되는 총 7개의 서버가 있는 크기 조정 가능한 빌드 아웃입니다. 그림에 표시된 BAM 서버는 이 테스트 시나리오에 사용되지 않았습니다.
BizTalkDTADb 유지 가능한 처리량
하드웨어 사양(BizTalk Server)
CPU: 이중 3GHz(캐시: L2: 512KB/L3: 1MB)
메모리: 2GB RAM
HDD: 2 X 32GB/15K
하드웨어 사양(SQL Server)
CPU: 쿼드 2GHz(L2: 512KB/L3: 1MB)
메모리: 4GB RAM
HDD: 2 X 32GB/15K + SAN
다음 그림은 테스트 시나리오 아키텍처의 개요를 보여 줍니다. 여기서 각 약자의 의미는 다음과 같습니다.
TP = 추적 지점, 이벤트 또는 메시지 속성과 같은 일부 요소가 추적되는 지점입니다.
MB = 메시지 본문이 추적되는 지점인 메시지 본문입니다.
다음 솔루션 아키텍처는 3가지 주요 구성 요소가 있는 추적 구성을 보여 줍니다.
기본 DTA 추적. 그림의 모든 이벤트 트랙 지점은 BizTalk Server 설치될 때 기본적으로 설정됩니다.
메시지 속성입니다. 인바운드 파이프라인의 DA(디스어셈블러) 구성 요소와 연결된 추적 지점은 인바운드 메시지에서 10개의 속성에 대한 추적을 나타냅니다. 추적을 위해 속성을 승격하는 방법에 대한 자세한 내용은 속성 승격을 참조하세요.
메시지 본문입니다. 그림에 있는 두 개의 MB(메시지 본문) 지점은 메시지 본문이 추적되는 지점을 나타냅니다. 메시지 본문 추적을 설정하는 방법에 대한 자세한 내용은 BizTalk 아티팩트 관리 및 추적을 참조하세요.
테스트 시나리오 아키텍처
테스트 기술
수신과 송신 모두에 대해 FILE 어댑터를 사용했습니다. 또한 부하 생성 도구인 LoadGen 2007을 사용하여 메시지를 인바운드 파일 공유에 전달했습니다. LoadGen 도구는 추적 MST 수준을 찾는 동안 부하를 다양하게 적용하기 위해 특정 속도로 파일을 전달하도록 구성했습니다. LoadGen 도구에 대한 자세한 내용은 Microsoft BizTalk LoadGen 2007 도구 사용을 참조하세요.
테스트를 위해 BizTalkDTADb 데이터베이스에 24시간 보존이라는 요구 사항이 있다고 가정했습니다. 즉, 24시간이 초과된 항목은 데이터베이스에서 제거했습니다. 보관 및 제거 SQL 작업은 보관된 데이터만 제거되어 처리 중 데이터가 손실되지 않도록 디자인되었습니다.
이러한 요구 사항이 있는 시스템을 완전히 테스트하기 위해 하나 이상의 보관 및 제거 주기가 포함되도록 최소 25시간 동안 부하를 실행해야 했습니다. 여기서는 첫 보관 작업 후의 시스템 유지 가능성을 확인하기 위해 24시간 동안 시스템을 모니터링할 수 있도록 48시간 동안 부하를 실행했습니다. 첫 24시간은 안정적인 상태를 시뮬레이트하기에 충분히 오래 보관된(24시간 간격) 데이터를 모으기 위해 필요했습니다. 그런 다음 이후 24시간 동안 TDDS, 보관 및 제거 등의 모든 프로세스가 처리량을 유지할 수 있는지 확인하기 위해 시스템을 모니터링했습니다.
추적 동작을 살펴본 결과 유지 가능성을 확인하기 위해 일반적으로 모니터링해야 하는 다음과 같은 몇 가지 KPI(핵심 성과 지표)가 있음을 발견했습니다.
BizTalkDTADb 데이터베이스 데이터 파일의 실제 디스크 유휴 시간입니다. 실제 디스크 유휴 시간이 0에 가까운 경우 BizTalkDTADb 데이터베이스가 추적된 데이터의 유입, 보관 활동 및/또는 제거 활동으로 포화 상태라는 좋은 징후입니다.
trackingdata 테이블 깊이입니다. trackingdata 테이블이 일정하게 증가하기 시작하는 경우, 즉 제한 없이 계속 증가하는 경우 현재 처리량 속도로는 TDDS가 BizTalkDTADb 데이터베이스에 유지 가능한 속도로 데이터를 삽입할 수 없다는 명확한 징후입니다.
스풀 깊이입니다. 스풀이 증가하는 요인은 다양합니다. 이 중 하나는 추적 메시지 본문을 MessageBox 데이터베이스에서 BizTalkDTADb 데이터베이스로 복사하는 SQL 작업이 지연되는 경우입니다. 추적되어야 하는 메시지가 BizTalkDTADb 데이터베이스로 성공적으로 복사될 때까지 해당 메시지를 MessageBox 정리 작업을 사용하여 MessageBox 데이터베이스에서 제거할 수 없기 때문에 복사 작업이 지연되는 경우 스풀이 쌓이게 됩니다.
대부분의 시스템에서 부하 상태에 대해 이러한 세 가지 성과 지표만 모니터링하면 부하의 유지 가능성 여부를 결정하는 데 충분한 정보를 얻을 수 있습니다.
유지 가능한 부하 상태의 핵심 성과 지표
초당 20개의 메시지가 수신되는 부하가 있는 샘플 시나리오를 사용한 결과 생성된 성능 모니터 그래프에 표시된 것과 같이 48시간 동안의 핵심 성과 지표를 얻었습니다. 그래프를 살펴보면 유지 가능성을 나타내는 다음과 같은 경향을 확인할 수 있습니다.
BizTalkDTADbdata 깊이(검은색 선). 세 개의 게시 MessageBox 데이터베이스를 사용한 결과 첫 보관 작업 후 24시간이 경과한 다음에도 trackingdata 테이블의 깊이가 안정화되어 계속 증가하지 않음을 확인할 수 있습니다.
스풀 깊이(파란색 선). 스풀 깊이는 전체 실행 기간 동안 매우 안정적이었습니다. 즉, 보관 및 제거 작업이 리소스를 사용하는 경우에도 크기가 각각 10KB인 추적 메시지가 지연되지 않고 BizTalkDTADb 데이터베이스에 복사되었습니다.
BizTalkDTADb 데이터베이스 데이터 파일 물리적 디스크 유휴 시간(빨간색 선). 보관 및 제거 작업이 수행되기 전 첫 24시간 동안 BizTalkDTADb 데이터베이스는 더 많은 데이터를 누적하며 결과적으로 TDDS가 데이터를 삽입할 때 더 많은 디스크 I/O가 발생합니다. 이는 실제 디스크 유휴 시간이 꾸준히 감소되는 것을 통해 명확히 확인할 수 있습니다.
실행 후 24시간이 지나면 I/O 유휴 시간의 명확한 하락이 관찰되며, 이는 보관 및 제거가 해야 할 일이 처음인 것과 일치합니다. 첫 번째 보관 후 제거는 24시간 이전의 데이터를 제거하기 위해 매 분마다 수행해야 합니다(시스템에 여전히 로드됨). 이로 인해 유휴 시간이 거의 없습니다.
여기서 중요한 점은 첫 보관 작업이 발생한 후, 즉 시스템이 첫 "사용 중인 BizTalkDTADb 데이터베이스 데이터 보존" 윈도를 지난 후 시스템이 MST를 유지하고 있거나 이에 가까운 경우 디스크 유휴 시간이 0에 가까워진다는 점입니다. 이는 BizTalkDTADb 데이터베이스에 대한 병목 상태가 항상 디스크 I/O 하위 시스템의 속도이기 때문입니다.
많은 경우 추적을 해제한 상태에서 시스템에 대한 기준으로 사용할 MST를 측정하면 유용합니다. 예를 들어 이 시나리오에서 추적 기능을 모두 해제한 상태에서 측정한 MST는 초당 290개의 메시지였습니다. 이는 추적이 설정되어 있고 위에서 언급한 기능 및 DTA 데이터 보존 윈도가 설정된 시스템에 대한 MST의 몇 배에 이르는 수치입니다. 이러한 사실을 통해 추적이 설정된 시스템은 사용률이 현저하게 낮음을 알 수 있습니다. 즉, 추적이 필요한 항목이 초당 20개 메시지의 MST만 지원하는 경우 초당 290개 메시지를 처리할 수 있는 시스템을 빌드할 필요가 없습니다. 다시 말해 BizTalkDTADb 데이터베이스 하드웨어가 변경되지 않는다고 가정할 때 현재 이 시나리오에 사용된 것보다 훨씬 더 적은 수의 BizTalk 및 MessageBox 데이터베이스 서버만으로도 초당 20개 메시지를 처리할 수 있습니다.
유지 가능한 최대 처리량 검색
MST로 실행하는 시스템의 KPI를 확인했으므로 샘플 시나리오에서 초당 20개 메시지의 MST에 도달한 방법에 대해 설명하겠습니다. 이 시나리오에서는 간단하고 반복적인 "이진 검색"을 사용했으며 사용법은 다음과 같습니다.
시작점을 선택합니다. BizTalk Server 대한 성능 테스트 경험이 없는 한 다른 시스템에서 달성된 내용에 대한 정보를 직접 활용해야 합니다.
예를 들어 여기서는 이 항목의 샘플 시나리오와 관련된 하드웨어, 구성 및 솔루션 아키텍처를 모두 제공했습니다. 이러한 정보와 설정한 추적 유형(기본값 + 10개의 속성 + 10KB의 메시지 본문) 및 24시간 DTA 데이터 보존 윈도로 달성한 MST(초당 20개의 메시지)를 사용자 설정 및 요구 사항과 비교합니다.
해당 솔루션에 대한 MST가 여기서 달성한 것보다 높은지, 아니면 낮은지 정도는 예상할 수 있어야 합니다. 시스템을 비교할 수 있는 다양한 기술 사례 연구를 사용할 수도 있습니다.
예상 MST 부하에서 시스템을 실행하고 KPI를 모니터링합니다. 일반적으로 예상 MST의 상향선에서 시작하면 MST를 찾는 데 걸리는 시간을 단축할 수 있습니다. 이렇게 하면 MST 미만(하나의 전체 데이터 보존 윈도 이상)에 있을 때 걸리는 것보다 짧은 시간 내에 KPI가 포화 상태(특히 디스크 I/O)에 도달하게 만들 수 있습니다.
MST 예상 및 반복을 구체화합니다. 테스트 실행의 결과를 살펴보면서 MST 예상치를 구체화하고 새 예상치를 사용하여 테스트를 반복합니다.
참고 항목
유지 가능한 최대 추적 처리량 측정
DTA 추적 성능 동작 이해
DTA 추적 MST를 찾기 위한 팁 및 트릭
추적 데이터베이스 크기 조정 지침