우수한 성능의 어댑터 디자인 방법
뛰어난 성능을 얻기 위해서는 모든 어댑터가 메시지의 일괄 처리 제출, 일괄 처리 전송, 일괄 처리 내의 메시지에 대한 일반적인 작업 수행 등 일괄 처리에 대해 인식해야 합니다. 어댑터는 일괄 처리의 크기 또는 일괄 처리 내의 바이트 수 등 어댑터의 디자인 타임 사용자 인터페이스에서 구성할 수 있는 성능 관련 특성을 제공해야 합니다.
앞서 설명한 것처럼 송신 어댑터는 항상 비차단 송신을 수행함으로써 송신 호스트의 성능이 저하되지 않도록 해야 합니다. 메시징 엔진 API를 추가로 차단하는 것은 권장되지 않습니다.
메시지 컨텍스트에 쓰거나 컨텍스트에서 읽는 작업은 런타임 성능에 영향을 줍니다. 일반적으로 어댑터는 지나치게 많은 수의 메시지 컨텍스트 속성을 읽거나 쓰거나 승격하지 않아야 합니다. 속성을 승격하면 승격된 각 속성에 대해 런타임에 등록 평가가 수행되므로 성능이 더욱 저하됩니다. 하지만 어댑터가 성능에 현저하게 영향을 줄 만큼 상당히 많은 수의 속성을 승격해야 하는 경우도 있습니다. 이러한 경우에는 반드시 승격해야 하는 속성만 승격하는 것이 좋습니다.
송수신 조정
로드가 구성된 임계값을 초과하는 경우 BizTalk 엔진에서는 어댑터와 오케스트레이션을 조정하여 최적의 성능을 유지합니다. 수신 쪽에서 엔진의 워크로드가 지정된 임계값을 초과하면 부하가 충분히 감소할 때까지 어댑터의 IBTTransportBatch.Done 호출이 차단됩니다. 이를 통해 엔진을 사용할 수 있을 때만 어댑터가 엔진에 새로운 작업을 전송할 수 있습니다. 송신 측의 경우, 엔진이 아웃바운드 메시지를 보내는 어댑터를 조정하고 있는 동안에는 로드가 줄어들 때까지 엔진이 새 메시지를 배달하지 않습니다.
따라서 어댑터는 백 엔드 시스템에 대한 연결 수 제한과 같이 꼭 필요한 경우가 아니면 조정에 관여할 필요가 없습니다. 엔진과 어댑터 프레임워크 모두 이러한 유형의 시나리오는 지원하지 않습니다.
어댑터의 소스 코드를 제어할 수 있는지 여부에 따라 몇 가지 방법으로 사용자 지정 송신 어댑터에서 보낸 메시지 수를 조정할 수 있습니다.
송신 측 조정을 통한 성능 향상
어댑터의 소스 코드를 제어할 수 있는 경우 언제든지 보낼 수 있도록 큐에 대기시킬 메시지의 최대 수를 추론을 통해 지정할 수 있습니다. 메시징 엔진이 메서드를 호출 TransmitMessage 하고 송신 어댑터에 새 메시지를 전달하는 경우 스레드를 차단하거나 검사 선택하여 큐의 메시지 수가 이전에 결정한 최대값보다 큰지 확인할 수 있습니다. 최대 메시지 수를 초과한 경우 메서드를 Resubmit 사용하여 메시지를 메시징 엔진에 다시 제출할 수 있습니다. 동기 어댑터의 경우에는 메시지가 이미 차단되어 있습니다.
어댑터의 소스 코드를 제어하지 않는 경우 BizTalk Management 데이터베이스의 Adm_serviceclass 테이블에서 Highwatermark 값을 변경하여 대기 중인 메시지 수를 변경할 수 있습니다. Highwatermark 속성의 최대값은 200입니다. Lowwatermark 속성의 값을 더 작은 값으로 변경할 수도 있습니다.
비동기 어댑터의 Highwatermark 속성 값은 메시징 엔진이 어댑터에 제공한 메시지 수를 고려합니다. 메시징 엔진은 메서드를 통해 TransmitMessage 어댑터에 전달합니다. 이러한 메시지는 전송에서 여전히 미해결 상태일 수 있습니다. 예를 들어 어댑터가 , Resubmit, MoveToNextTransport또는 Microsoft.BizTalk.TransportProxy.Interop.BatchOperationType.MoveToSuspendQ 메서드를 해당 호출DeleteMessage하지 않은 경우입니다. 동기 어댑터의 경우 Highwatermark 속성은 이 호출이 동기적으로 처리되어 호출 메시징 엔진 스레드를 차단하기 때문에 Messaging Engine이 TransmitMessage 메서드를 사용하여 어댑터에 전달한 메시지 수만 고려합니다.
HTTP, FTP, 양방향 SOAP 등 속도가 느린 프로토콜에 사용할 송신 어댑터를 작성할 때는 다음 사항을 고려하십시오.
어댑터가 BizTalk 메시징 엔진으로부터 자신의 전송 속도보다 빠르게 전송해야 할 메시지를 수신할 수 있습니다. 이러한 속도 불일치로 인해 다양한 수준에서 문제가 발생할 수 있습니다. 전송 중인 메시지는 메모리에 남아 가상 메모리를 사용하므로 전반적으로 시스템의 속도가 느려집니다.
어댑터가 프로토콜 관련 리소스를 사용할 수 있습니다. 예를 들어 서버에 대한 동시 연결을 너무 많이 열어서 원격 서버의 작업을 방해할 수 있습니다.
어댑터가 다른 어댑터에 영향을 줄 수 있습니다. 예를 들어 특정 어댑터의 큐에 메시지가 너무 많이 쌓인 경우 메시징 엔진은 해당 프로세스에서 다른 송신 어댑터로 요청을 발급하는 것을 중지합니다.
이 경우 개별 BizTalk 호스트에 저속 및 고속 어댑터를 배치하고 "상위 워터마크" 및 "하위 워터마크" 설정을 통해 메시지 수를 제어하여 문제를 해결할 수 있습니다.
수신 측 조정을 통한 성능 향상
수신 어댑터가 시스템의 다른 부분에서 처리할 수 있는 것보다 빠른 속도로 메시지를 수신하는 경우가 많습니다. 이러한 상황이 발생하면 메시지가 MessageBox 데이터베이스에서 백로그로 처리됩니다. 이 경우 전체 시스템의 성능이 급격히 저하됩니다.
어댑터에 이러한 문제가 발생하면 다음 방법 중 하나를 통해 수신 어댑터의 속도를 낮출 수 있습니다.
메시징 엔진 스레드 풀의 크기를 줄입니다. 메시징 엔진이 MessageBox에 메시지를 게시하는 데 사용하는 스레드 수를 제어할 수 있습니다. 스레드 수를 줄여 수신 어댑터가 MessageBox로 들어오는 메시지를 수신하는 속도를 줄입니다. 이 값은 어댑터의 수신 핸들러에 해당하는 호스트에서만 설정하면 됩니다. 송신 어댑터의 속도도 줄이려는 경우가 아니면 어댑터의 송신 핸들러에 해당하는 호스트에서는 이 값을 설정하지 마십시오.
어댑터 일괄 처리 크기를 줄입니다. 대부분의 고속 수신 어댑터는 일괄 처리로 MessageBox에 메시지를 게시합니다. 일반적으로 이러한 일괄 처리의 크기는 수신 위치 속성 페이지에서 구성할 수 있습니다. 일괄 처리 크기를 줄여 시스템으로 들어오는 전체 메시지 처리량을 줄일 수 있습니다.
다른 어댑터 설정을 변경합니다. 앞의 두 단계를 완료한 후 다른 어댑터 매개 변수를 조정하여 추가로 처리량을 줄일 수 있습니다. 일부 어댑터는 처리량을 줄이는 데 사용할 수 있는 내부 매개 변수를 제공합니다. 예를 들어 MQSeries 어댑터에는 "순차적 전달" 설정이 있습니다. 순차적 전달은 어댑터가 메시지 일괄 처리를 게시하고 해당 일괄 처리가 완료될 때까지 대기한 후 다음 일괄 처리를 게시하도록 지정합니다. 이 설정을 사용하면 수신 어댑터에서 병렬 처리가 실행되지 않습니다. 이와는 반대로 매개 변수를 조정하여 수신 어댑터의 수신 속도를 높일 수도 있습니다.
어댑터는 전송 프록시에 필요한 만큼 얼마든지 일괄 처리를 전송할 수 있습니다. 시스템의 스트레스가 심하면 필요한 리소스가 시스템에 릴리스될 때까지 IBTTransportBatch 인터페이스의 Done 메서드를 호출하면 메시지가 차단됩니다.
비동기 송수신에 대한 계획 수립
BizTalk Server 메시징 API는 비동기 프로그래밍을 완벽하게 지원합니다. 확장 가능한 어댑터를 작성하려는 경우 비동기 모델의 동시성이 훨씬 우수하므로 처음부터 비동기 모델을 사용한다고 가정하고 계획을 세우는 것이 좋습니다.
수신 쪽에서 어댑터가 IBTTransportBatch::D one을 호출하여 BizTalk 메시징 엔진에 메시지 일괄 처리를 제출하면 메시징 엔진은 내부 스레드 풀을 사용하여 작업을 큐에 대기하고 즉시 반환합니다. 그런 다음 엔진이 별도의 스레드에서 메시지를 처리하므로 어댑터가 이전 메시지에 대한 처리가 완료될 때까지 대기할 필요 없이 소스에서 더 많은 메시지를 읽고 전송할 수 있습니다.
송신 측에서는 비동기 또는 동기 어댑터를 사용할 수 있습니다. 하지만 프로토콜이 비동기 작업을 지원하는 경우에는 확장 가능한 어댑터를 작성해야 합니다. 예를 들어 파일 및 HTTP 송신 어댑터는 완전히 비동기식이며 차단/동기 작업을 거의 수행하지 않습니다.
비동기 작업에서는 메시징 엔진과 어댑터 모두가 일반 메시지 처리 작업을 수행할 때 서로가 해당 작업을 완료할 때까지 대기할 필요 없이 각각의 작업을 병렬로 수행할 수 있습니다.
일괄 처리를 통한 성능 향상
일괄 처리는 확장 가능한 어댑터를 작성하는 데 매우 유용합니다. 이는 송신 측 및 수신 측 어댑터 모두에 해당합니다. 모든 일괄 처리는 BizTalk Server 내의 데이터베이스 트랜잭션을 경유하며 이는 어댑터가 비트랜잭션 어댑터인 경우에도 마찬가지입니다. 각 트랜잭션에는 관련된 고정 지연 시간이 있으므로 하나의 일괄 처리에 둘 이상의 작업을 포함하여 트랜잭션 수를 최소화해야 합니다.
.NET 스레드 풀 활용
BizTalk 어댑터를 작성하는 것은 .NET 런타임 코드를 작성하기 위한 연습이며 .NET 런타임 코드를 작성하는 것은 비동기 프로그래밍을 수행하기 위한 연습입니다.
.NET 스레드 풀을 충분히 활용하지 않으면 .NET의 모든 비동기 프로그래밍을 수행하는 데 어려움이 따를 수 있으며 이는 특히 BizTalk 어댑터 프로그래머가 피해야 할 일입니다.
.NET 스레드 풀은 제한적이기는 하지만 폭넓게 공유되는 리소스를 제공합니다. .NET 스레드 풀의 스레드 중 하나를 사용하는 코드를 작성한 다음 이것만 사용하여 다른 작업 항목이 실행되지 않도록 차단하는 것은 간단합니다.
BeginInvoke를 사용하거나 타이머를 사용할 때마다 .NET 스레드 풀 스레드를 사용합니다. 수행할 작업이 여러 개 있는 경우(예: MQSeries에서 BizTalk Server 메시지 복사) 작업 항목 하나(BizTalk Server 메시지 일괄 처리)를 실행한 다음, 수행할 작업이 더 많은 경우 스레드 풀에서 다시 큐에 추가해야 합니다. 스레드의 루프에 앉지 while 마세요.
구체적으로 말해 루프를 BeginInvoke에 대한 반복 호출로 바꾸는 while 것을 의미합니다. 이와 같이 간단하게 변경하는 것만으로도 응답 성능을 크게 향상시키고 전체 구현 성능을 높일 수 있습니다.
일괄 처리 크기를 제한할 경우 적절한 기준 선택
BizTalk Server에 일괄 처리 메시지를 전송하는 경우 메시지 개수에만 기준을 두고 일괄 처리 크기를 제한해서는 안 됩니다. 어댑터가 메시지 수에 따라 일괄 처리로 구성된 경우 발생하는 작업을 고려합니다. 일괄 처리 크기가 2이고 어댑터가 각각 4KB, 8KB, 1MB 및 5MB 크기의 4개 메시지를 받는 경우 첫 번째 일괄 처리의 크기는 12KB이고 두 번째 일괄 처리는 6MB 크기가 됩니다.
BizTalk 메시징 엔진은 단일 일괄 처리의 모든 메시지를 순차적으로 처리하므로 이 예의 경우 두 번째 일괄 처리는 첫 번째 일괄 처리보다 훨씬 느리게 처리됩니다. 그 결과 처리량이 줄어들게 됩니다. 이러한 문제를 효과적으로 해결하려면 일괄 처리의 메시지 개수와 총 바이트 수 모두를 기준으로(예: 바이트당 일괄 처리) 일괄 처리를 만들어야 합니다. 총 바이트에 대해 정해진 값은 없습니다. 그러나 일반적인 처리 시나리오의 경우 일괄 처리 크기가 1MB를 초과하면 동시성 및 처리량이 낮아지기 시작합니다.
일반적으로 어댑터는 메시지에 대해 알지 못할 뿐만 아니라 프로덕션 환경의 메시지 크기에 대해서도 예측하지 않습니다. 들어오는 메시지의 크기는 매우 다양합니다. 따라서 항상 메시지 개수와 총 바이트 수를 기준으로 일괄 처리를 만드는 것이 좋습니다.