메시지 고려 사항

BizTalk Server는 메시지를 보내고, 받고, 변환하고, 처리하기 위한 광범위한 기능 집합을 제공합니다. 이러한 기능 중 일부는 다음과 같습니다.

  • HTTP, SMTP, FTP/FTPS 및 WCF와 같은 여러 업계 표준 전송을 사용하여 메시지를 보내고 받는 기능. 메시지를 보내고 받기 위한 전송 수준 지원은 BizTalk Server 어댑터를 사용하여 수행됩니다. BizTalk Server 메시지 처리와 다양한 LOB("기간 업무") 애플리케이션의 통합은 사용 가능한 여러 BizTalk Server 가속기 또는 어댑터(예: HIPAA용 BizTalk Accelerator, BIzTalk Accelerator for SWIFT 또는 BizTalk SAP 어댑터) 중 하나를 사용하여 수행됩니다. 이러한 가속기 및 어댑터는 산업 표준을 준수하며, 이를 통해 BizTalk Server와 특정 업계 표준을 준수하는 시스템을 간편하게 통합할 수 있습니다.

  • 일반 텍스트, XML, 이진 등과 같은 여러 메시지 형식을 처리하는 기능 이 기능은 광범위한 거래 파트너와 BizTalk Server의 통합을 제공하는 데 중요합니다.

  • 메시지 변환 또는 문서 매핑을 지원합니다. 매핑은 서로 다른 스키마 간의 데이터 변환을 수용합니다. 예를 들어 매핑을 사용하여 받은 고객 구매 주문의 내용을 고객에게 다시 보낼 배송 알림이 있는 영수증으로 변환할 수 있습니다.

  • BizTalk Server 오케스트레이션은 시간, 조직, 애플리케이션 및 사람을 포괄하는 비즈니스 프로세스를 만들기 위한 기능을 제공합니다. BizTalk Server는 오케스트레이션 디자이너 그래픽 인터페이스를 제공하여 트랜잭션 지원(기존의 "원자성" MSDTC 형식 및 장기 실행), 예외 처리, 디버깅, 추적 및 외부 코드 호출 확장성을 포함하는 비즈니스 프로세스를 개발합니다.

    비고

    BizTalk Server에서 오케스트레이션을 사용할 때 수행할 모범 사례에 대한 지침은 오케스트레이션 성능 최적화 를 참조하세요. 오케스트레이션 디자이너 사용에 대한 자세한 내용은 BizTalk Server 설명서에서 오케스트레이션 디자이너(https://go.microsoft.com/fwlink/?LinkId=158997)를 사용하여 오케스트레이션 만들기 항목을 참조하세요.

    이 항목의 나머지 부분에서는 BizTalk Server 환경에서 처리되는 메시지의 크기, 복잡성 및 배포 프로필과 관련된 성능 고려 사항에 대해 설명합니다.

메시지 크기 고려 사항

BizTalk Server는 메시지 크기에 제한을 두지 않지만, 큰 메시지에는 더 많은 처리 리소스가 필요하기 때문에 실제 제한 및 종속성을 통해 메시지 크기를 최소화해야 할 수 있습니다. 메시지 크기가 증가함에 따라 전체 처리량(초당 처리된 메시지)이 감소합니다. 시나리오를 디자인하고 용량을 계획할 때는 BizTalk Server 프로세스의 평균 메시지 크기, 메시지 유형 및 메시지 수를 고려합니다. 불필요하게 긴 특성 및 태그 이름을 사용하지 마세요. 가능하면 길이를 50자 미만으로 유지합니다. 예를 들어 메시지 크기가 1 바이트인 경우에는 200자 태그 이름을 사용하지 마세요.

받은 메시지의 메모리 내 크기가 큰 메시지 조각 크기에 지정된 바이트 수를 초과하는 경우(BizTalk Server 관리 콘솔의 BizTalk 그룹에 대한 그룹 속성 페이지에서 구성 가능) 메시지는 지정된 크기의 조각으로 분할됩니다. 또한 조각은 다음과 같이 MSDTC(Microsoft Distributed Transaction Coordinator) 트랜잭션의 컨텍스트에 따라 Messagebox에 기록됩니다.

  1. 들어오는 메시지가 기존 MSDTC 트랜잭션의 컨텍스트에서 게시되는 경우 이 트랜잭션은 BizTalk MessageBox 데이터베이스에 메시지 조각을 쓸 때 사용됩니다. 예를 들어 들어오는 메시지가 트랜잭션을 요구하도록 구성된 트랜잭션 어댑터에 의해 게시되는 경우 메시지 조각을 MessageBox 데이터베이스에 쓸 때 기존 트랜잭션이 사용됩니다.

  2. 들어오는 메시지가 기존 MSDTC 트랜잭션의 컨텍스트에서 게시되지 않는 경우 메시지 조각을 MessageBox 데이터베이스에 쓰기 위해 새 MSDTC 트랜잭션이 만들어집니다. 이 시나리오에서는 다음과 같은 고려 사항이 적용됩니다.

    • 큰 메시지 조각 크기의 값을 늘려 큰 메시지가 조각화되는 빈도를 줄이고 관련 MSDTC 트랜잭션을 만드는 발생률을 줄입니다. MSDTC 트랜잭션의 과도한 사용은 성능 관점에서 비용이 많이 들기 때문에 이 작업을 수행해야 합니다. 이 값을 늘리면 사용되는 사용 가능한 메모리의 양이 증가할 수도 있습니다.

    • MessageBox에 메시지를 쓰는 데 허용되는 최대 MSDTC 트랜잭션 시간 제한인 60분보다 오래 걸리면 트랜잭션 시간이 초과되고 오류가 발생하며 메시지 작성 시도가 실패하고 롤백됩니다. 대용량 메시지를 처리할 때 이 문제를 방지하려면 큰 메시지 조각 크기 값을 충분히 늘려야 합니다. 사용 가능한 메모리에 따라 이 값은 최대 1000000바이트까지 증가해야 합니다.

    • 메시지의 각 메시지 조각은 MessageBox 데이터베이스에 대해 하나 이상의 SQL Server 데이터베이스 잠금을 만듭니다. 잠금 수가 수십만을 초과하면 SQL Server에서 "잠금 해제" 오류가 발생할 수 있습니다. 이 문제가 발생하는 경우 큰 메시지 조각 크기의 값을 늘려 조각 수를 줄이거나(MessageBox 데이터베이스에 대해 수행된 SQL Server 데이터베이스 잠금의 수를 줄임) 64비트 버전의 SQL Server에 MessageBox 데이터베이스를 보관하는 것이 좋습니다. 사용 가능한 잠금 수는 64비트 버전의 SQL Server에서 32비트 버전의 SQL Server보다 훨씬 높습니다. 다음 수식을 사용하여 MessageBox 데이터베이스가 32비트 버전의 SQL Server에 저장될 때 교환당 최대 메시지 수를 예측할 수 있습니다.

      200,000 / (Number of CPUs * BatchSize * MessagingThreadPoolSize)
      

    큰 메시지를 처리하기 위한 지침을 포함하여 BizTalk Server가 큰 메시지를 처리하는 방법에 대한 자세한 내용은 BizTalk Server가 큰 메시지를 처리하는 방법 (https://go.microsoft.com/fwlink/?LinkID=154680)을 참조하세요.

메시지 유형 고려 사항

메시지는 두 가지 기본 형식인 XML 파일 또는 플랫 파일 중 하나로 BizTalk Server로 수신됩니다. XML 및 플랫 파일 메시지의 리소스 요구 사항이 다양하기 때문에 메시지 유형은 항상 메시지 배포 프로필에 고려되어야 합니다.

  • XML 파일 BizTalk Server가 통과 라우팅 이외의 메시지에 대한 처리를 수행하려면 메시지가 XML 파일 형식이어야 합니다.

  • 플랫 파일 BizTalk Server가 통과 라우팅 이외의 처리를 수행하려면 플랫 파일을 XML 형식으로 구문 분석해야 합니다. 플랫 파일을 XML 파일로 구문 분석하면 파일의 크기가 크게 증가할 수 있습니다. 플랫 파일에는 데이터에 대한 설명 정보가 포함된 XML 태그가 포함되어 있지 않습니다. 반면 XML 파일은 모든 데이터를 설명이 포함된 XML 태그로 래핑합니다. 일부 시나리오에서는 구문 분석에서 파일의 XML 태그에 포함된 설명 데이터의 양에 따라 플랫 파일의 크기를 10배 이상 늘릴 수 있습니다.

  • XML 문서의 단일 CDATA 섹션 노드에 래핑된 플랫 파일 문서 BizTalk Server는 처리하기 전에 전체 래핑된 플랫 파일 문서를 메모리에 로드해야 하므로 이 유형의 문서는 XML 및 플랫 파일의 조합이며 메모리 집약적인 경우가 많습니다.

오버로드 고려 사항

대부분의 BizTalk Server 애플리케이션은 특정 일정한 속도로 메시지를 수신하지 않습니다. 일반적으로 메시지 처리에는 피크와 계곡이 적용됩니다. 예를 들어 온라인 뱅킹 애플리케이션은 아침, 한낮 및 하루가 끝날 때 더 많은 양의 메시지를 처리할 수 있습니다. BizTalk Server 솔루션을 테스트하여 이러한 오버로드 시나리오를 처리할 수 있는지 확인해야 합니다. BizTalk Server 솔루션이 오버로드 시나리오를 얼마나 잘 처리할 수 있는지 확인하려면 BizTalk Server 솔루션의 MST(지속 가능한 최대 처리량)를 결정해야 합니다. MST는 시스템이 프로덕션 환경에서 무기한으로 처리할 수 있는 가장 높은 메시지 트래픽 부하입니다. MST에 대한 자세한 내용은 지속적인 성능 계획 (https://go.microsoft.com/fwlink/?LinkID=158065) 및 지속 가능한 성능이란? 을 참조하세요. (https://go.microsoft.com/fwlink/?LinkID=132304) BizTalk Server 설명서에 있습니다.

스키마 복잡성

메시지 구문 분석(특히 플랫 파일 구문 분석)에 대한 처리량은 스키마의 복잡성에 영향을 받습니다. 스키마 복잡성이 증가함에 따라 전반적인 성능이 저하됩니다. 스키마를 디자인할 때 노드 이름의 길이를 줄이고 승격된 속성을 스키마 맨 위로 이동합니다. 이렇게 하면 검색 시간이 줄어들고 성능이 향상됩니다.

맵 복잡성

지도의 복잡성에 따라 지도 변환은 리소스를 많이 사용할 수 있습니다. 지도 복잡성이 증가함에 따라 전반적인 성능이 저하됩니다. 전반적인 성능을 향상시키려면 맵에 사용되는 링크 및 펑토이드의 수를 최소화합니다. 특히 DB 조회 펑토이드와 같은 외부 리소스를 호출하는 펑토이드입니다.

플랫 파일 구문 분석 고려 사항

플랫 파일 구문 분석의 성능에 가장 큰 영향을 주는 두 가지 요소는 파일 크기 및 스키마 복잡성입니다. 모호한 스키마는 많은 선택적 필드를 포함하는 스키마입니다. 큰 파일 크기를 사용하는 경우 많은 선택적 필드가 있는 스키마는 더 큰 파일이 스키마의 다른 분기와 일치할 수 있으므로 성능이 저하될 수 있습니다. 스키마 복잡성은 더 큰 파일보다 작은 파일에 미치는 영향이 적습니다.

또한 참조하십시오

BizTalk Server 애플리케이션 최적화