병목 상태 조사

이 항목에서는 병목 상태를 조사하는 데 권장되는 프로세스에 대해 설명합니다.

문제의 근원은 무엇인가요?

병목 현상의 근원은 하드웨어 또는 소프트웨어 관련일 수 있습니다. 리소스가 과소 사용되면 일반적으로 병목 상태를 나타냅니다. 병목 현상은 하드웨어 제한, 비효율적인 소프트웨어 구성 또는 둘 다에 의해 발생할 수 있습니다.

병목 상태 확인은 하나의 병목 상태를 해소하면 다음 병목 상태를 발견할 수 있는 증분 프로세스입니다. 이러한 병목 상태를 확인하고 해소하는 것이 이 항목의 목적으로 단기간에 시스템이 최대 속도로 작업을 수행할 수 있도록 합니다. 그러나 유지 가능한 처리량의 경우 시스템의 처리 속도는 해당 구성 요소 중 성능이 가장 느린 구성 요소와 같습니다.

반복적인 테스트 방법 사용

병목 현상은 시스템의 엔드포인트(진입/종료) 또는 중간(오케스트레이션/데이터베이스)에서 발생할 수 있습니다. 병목 현상이 격리된 후 구조적 접근 방식을 사용하여 원본을 식별합니다. 병목 현상이 완화된 후에는 시스템의 다른 곳에서 새로운 병목 현상이 발생하지 않도록 성능을 다시 측정하는 것이 중요합니다.

병목 상태를 식별하고 수정하는 프로세스는 반복적인 방식으로 수행해야 합니다. 한 번에 하나의 매개 변수만 변경하고, 각 테스트 실행 중에 정확히 동일한 단계를 반복한 다음, 성능을 측정하여 단일 수정의 영향을 확인합니다. 한 번에 여러 매개 변수를 변경하면 변경 결과가 확인되지 않을 수 있습니다.

예를 들어 매개 변수 1을 변경하면 성능이 향상될 수 있습니다. 그러나 매개 변수 2를 매개 변수 1 변경과 함께 변경하면 해로울 수 있으며 매개 변수 1을 변경하는 이점을 부정할 수 있습니다. 이로 인해 순 제로 효과가 발생하며, 매개 변수 1의 효과에 대한 가음성 및 다양한 매개 변수 2의 효과에 대한 가양성으로 발생합니다.

테스트 일관성

변경의 영향을 확인하려면 설정을 변경한 후 성능 특성을 측정해야 합니다.

• 하드웨어- 하드웨어가 다르면 일관되지 않은 동작이 발생하고 잘못된 결과가 발생할 수 있으므로 일관된 하드웨어를 사용합니다. 예를 들어 랩톱을 사용하여 BizTalk 솔루션의 성능을 테스트하지 않습니다.

• 테스트 실행 기간 - 결과가 지속 가능한지 확인하기 위해 고정된 최소 기간의 성능을 측정합니다. 또한 더 긴 기간 동안 테스트를 실행하면 시스템이 모든 캐시가 채워지고, 데이터베이스 테이블이 예상 개수에 도달하고, 미리 정의된 임계값에 도달하면 처리량을 조절할 수 있는 충분한 시간이 제한되는 초기 웜/램프 업 기간을 통과하게 됩니다. 이 방법은 유지 가능한 최적 처리량을 찾는 데 도움이 됩니다.

• 테스트 매개 변수 – 테스트 실행에서 테스트 실행까지 테스트 매개 변수를 변경하지 마세요. 예를 들어 맵 복잡성 및/또는 문서 크기를 변경하면 처리량과 대기 시간 결과가 다르게 생성될 수 있습니다.

• 클린 상태 - 테스트가 완료되면 다음 테스트를 실행하기 전에 테스트 환경의 상태가 클린 있는지 확인합니다. 예를 들어 기록 데이터는 런타임 처리량에 영향을 주는 데이터베이스에서 빌드할 수 있습니다. 서비스 인스턴스를 재활용하면 메모리, 데이터베이스 연결 및 스레드와 같은 캐시된 리소스를 해제하는 데 도움이 됩니다. 테스트 환경에서 테스트 환경의 MessageBox 데이터베이스에서 수동으로 데이터를 제거하는 방법 (https://go.microsoft.com/fwlink/?LinkId=158064)에 설명된 대로 bts_CleanupMsgbox 저장 프로시저를 만들고 실행할 수 있습니다. 이 스크립트는 실행 간의 메시지 상자와 관련하여 BizTalk Server 테스트 환경을 새 상태로 되돌리기 위한 것입니다. 스크립트는 실행 중인 모든 인스턴스와 상태, 메시지 및 구독을 포함한 해당 인스턴스에 대한 모든 정보를 삭제하지만 오케스트레이션을 다시 등록하거나 포트를 보낼 필요가 없도록 모든 활성화 구독을 남깁니다. 이 도구는 프로덕션 시스템에서 지원되지 않습니다.

• 성능 테스트 및 튜닝 - 이 테스트 범주의 목표는 애플리케이션의 성능과 처리량을 최대화하고 시스템의 MST(지속 가능한 최대 처리량)를 찾는 것입니다. 지속 가능한 최대 성능 계획 및 측정에 대한 자세한 내용은 지속 가능한 성능 계획 (https://go.microsoft.com/fwlink/?LinkId=158065) 및 지속 가능한 성능이란?을 참조하세요. (https://go.microsoft.com/fwlink/?LinkId=132304).

  MST는 프로덕션 환경에서 시스템이 무기한으로 처리할 수 있는 메시지 트래픽의 가장 높은 부하입니다. 모든 BizTalk 애플리케이션은 프로덕션 환경에 들어가기 전에 성능 및 처리량을 테스트해야 합니다. 최소한 가장 일반적인 사용 시나리오를 나타내는 대표적인 테스트 사례 집합을 실행해야 합니다. 프로덕션 환경의 특성과 일치하는 별도의 환경에서 예상 부하 및 최대 부하에 대해 테스트하는 것이 좋습니다. 이 환경에는 모니터링 에이전트 및 바이러스 백신 소프트웨어와 같은 모든 회사 표준 서비스가 설치 및 실행되어야 합니다.

• 또한 실행 중인 다른 BizTalk 애플리케이션과 함께 프로덕션의 동일한 하드웨어에서 새 BizTalk 애플리케이션을 테스트하는 것이 좋습니다. 이러한 다른 BizTalk 애플리케이션은 BizTalk Server, SQL Server, 네트워크 I/O 및 디스크 I/O에 추가 부하를 적용합니다. 또한 한 BizTalk 애플리케이션으로 인해 스풀 깊이가 너무 커지면 다른 애플리케이션이 제한될 수 있습니다. 모든 BizTalk 애플리케이션은 프로덕션 환경에 들어가기 전에 성능/스트레스를 테스트해야 합니다. 또한 최대 부하에서 시스템을 복구하는 데 걸리는 시간을 결정해야 합니다. 다음 최대 부하가 발생하기 전에 시스템이 최대 부하에서 완전히 복구되지 않으면 문제가 발생합니다. 시스템은 더 이상 뒤처지고 완전히 복구할 수 없습니다.

예상 결과: 처리량 및 대기 시간

배포된 시스템에서 일정량의 처리량 및/또는 대기 시간을 예상할 수 있습니다. 높은 처리량과 짧은 대기 시간을 동시에 달성하려고 시도하면 시스템에 대한 요구가 반대됩니다. 적절한 대기 시간으로 최적의 처리량을 기대할 수 있습니다. 처리량이 향상되면 시스템의 스트레스(예: CPU 사용량 증가, 디스크 I/O 경합 증가, 메모리 압력 및 잠금 경합 증가)가 증가합니다. 이 상황은 대기 시간에 부정적인 영향을 미칠 수 있습니다. 시스템의 최적의 용량을 검색하려면 병목 상태를 식별하고 최소화하는 것이 좋습니다.

데이터베이스에 있는 완료된 인스턴스는 병목 현상을 일으킬 수 있습니다. 병목 현상이 발생하면 성능이 저하됩니다. 시스템에 드레이닝할 충분한 시간을 제공하면 문제를 해결하는 데 도움이 될 수 있습니다. 백로그 빌드의 원인을 검색하고 문제를 해결하는 데 도움이 되는 것이 중요합니다.

백로그의 원인을 검색하려면 기록 데이터를 분석하고 성능 카운터를 모니터링하여 사용 패턴을 검색하고 백로그의 원본을 진단할 수 있습니다. 일반적으로 백로그는 대량의 데이터가 야간에 일괄 처리된 방식으로 처리될 때 발생할 수 있습니다. 시스템의 용량과 백로그에서 복구하는 기능을 검색하는 것이 유용할 수 있습니다. 이 정보는 오버드라이브 시나리오를 처리하기 위한 하드웨어 요구 사항과 예기치 않은 처리량 급증을 처리하기 위해 시스템 내에서 수용할 버퍼 공간의 양을 예측하는 데 도움이 될 수 있습니다.

성능 카운터를 모니터링하면 런타임에 발생할 수 있는 잠재적인 병목 상태를 완화할 수 있습니다. 그러나 CPU 또는 메모리 병목 현상의 원인은 솔루션을 구성하는 사용자 지정 구성 요소 중 하나일 수 있다고 판단되는 경우 성능 테스트 중에 Visual Studio Profiler 또는 ANTS 성능 프로파일러와 같은 프로파일링 도구를 사용하여 문제를 생성하는 클래스의 범위를 좁혀서 세분화하는 것이 좋습니다. 물론 애플리케이션을 프로파일링하면 성능이 저하됩니다. 따라서 이러한 테스트는 메모리 사용량, CPU 사용률 또는 대기 시간을 유발하는 구성 요소의 완화에 중점을 두어야 하며 이러한 테스트 중에 수집된 수치는 삭제해야 합니다.

최적의 지속 가능한 처리량을 위해 시스템을 조정하려면 배포된 애플리케이션, 시스템의 강점 및 약점 및 특정 시나리오의 사용 패턴을 깊이 이해해야 합니다. 병목 상태를 찾고 유지 가능한 최적 처리량을 명확하게 예측하는 유일한 방법은 프로덕션에서 사용할 토폴로지와 거의 일치하는 토폴로지에 대한 철저한 테스트뿐입니다. 특정 사용 사례에 대해 부하 및 스트레스 테스트를 실행하는 경우 단일 아티팩트(수신 위치, 송신 포트, 오케스트레이션)를 별도의 호스트 인스턴스로 격리하고 성능 모니터 도구 내에서 올바른 카운터를 설정하는 것이 병목 현상의 원인을 좁히는 데 중요합니다.

이 섹션의 다른 topics 해당 토폴로지를 정의하는 프로세스를 안내하고 병목 상태를 줄이고 방지하는 방법에 대한 지침을 제공합니다.

크기 조정

병목 현상은 배포된 토폴로지의 다양한 단계에서 발생할 수 있습니다. 환경을 확장하거나 스케일 아웃하여 일부 병목 상태를 해결할 수 있습니다. 확장은 기존 컴퓨터를 업그레이드하는 프로세스입니다. 예를 들어 BizTalk Server 컴퓨터를 4개 프로세서 컴퓨터에서 8개 프로세서 컴퓨터로 업그레이드하고 기존 CPU를 대체하고 RAM을 더 추가할 수 있습니다. 이러한 방식으로 문서 구문 분석 및 매핑과 같은 리소스 집약적 작업을 가속화할 수 있습니다. 스케일 아웃은 배포에 서버를 추가하는 프로세스입니다. 스케일 업 또는 스케일 아웃 결정은 병목 상태의 유형과 구성되는 애플리케이션에 따라 달라집니다. 스케일 업 또는 스케일 아웃을 활용하려면 처음부터 애플리케이션을 빌드해야 합니다. 다음 지침에서는 발생한 병목 현상에 따라 하드웨어 배포 토폴로지를 변경하는 방법을 설명합니다.

스케일 업은 업그레이드된 하드웨어(예: CPU 및 메모리 추가)에서 BizTalk 솔루션을 실행하는 것을 의미합니다. 1) 스케일 아웃이 너무 비싸거나 2) 스케일 아웃이 병목 현상을 해결하는 데 도움이 되지 않을 때 스케일 업하는 것을 살펴봐야 합니다. 예를 들어 더 빠른 컴퓨터에서 작업을 실행하는 경우 큰 메시지를 변환하고 처리하는 데 소요되는 시간을 크게 줄일 수 있습니다.

애플리케이션 플랫폼 확장은 BizTalk Server 그룹에 BizTalk 노드를 추가하고 이를 사용하여 솔루션의 하나 이상의 부분을 실행하는 것으로 구성됩니다. 메모리, I/O 또는 네트워크 I/O 리소스가 단일 서버에 대해 최대화될 때 1) 송신, 수신, 처리, 추적 호스트 또는 2)를 격리해야 하는 경우 스케일 아웃을 확인해야 합니다. 부하는 여러 서버에 분산될 수 있습니다. 그러나 BizTalk Server 그룹에 새 노드를 추가하면 MessageBox 데이터베이스의 잠금 경합이 증가할 수 있습니다.

그렇다면 스케일 업 또는 스케일 아웃해야 할까요? 단일 작업(예: 메시지 매핑)을 더 빠르게 실행하므로 플랫폼을 확장하면 BizTalk 솔루션의 대기 시간을 줄일 수 있습니다. 스케일 아웃하면 워크로드를 여러 컴퓨터에 분산할 수 있으므로 BizTalk 솔루션의 최대 지속 가능한 처리량과 확장성을 향상시킬 수 있습니다.

참고 항목

병목 상태 찾기 및 제거