유지 가능한 최대 추적 처리량 측정
BizTalk Server 플랫폼에 기간 업무 솔루션을 배포한 후 시스템을 추적하고 모니터링하여 다음을 이해해야 합니다.
시스템 수행 상태
발생하는 예외 및 오류와 원인
BizTalk 솔루션으로 구현된 비즈니스 프로세스의 현재 상태
많은 조직에서 거부하지 않는 목적으로 시스템을 통해 흐르는 실제 원시 메시지를 기록하는 것도 중요합니다. BizTalk Server 이러한 요구 사항을 해결하는 두 가지 유형의 추적 기능을 제공합니다.
DTA(데이터 추적 및 활동) 추적. DTA는 다양한 사용자 정의 메시지 속성, 오케스트레이션 디버그 이벤트, 메시지 흐름 이벤트 및 서비스 인스턴스 상태를 추적합니다. BizTalk DTA 추적 데이터베이스(BizTalkDTADb)에 저장된 데이터를 쿼리하는 데 추적을 사용합니다. DTA 추적에는 비거부 및 문제 해결 목적을 위해 메시지 본문이라고도 하는 원시 메시지를 추적하는 작업도 포함됩니다.
BAM(비즈니스 활동 모니터링) 추적. BAM은 사용자 정의 추적 프로필을 사용하여 특수한 BAM 데이터베이스 집합으로 비즈니스 프로세스의 상태를 추적합니다.
이 항목에서는 DTA 아키텍처에 대해 설명하고 DTA를 사용하는 시스템에서 무기한으로 유지할 수 있는 최대 처리량를 결정하는 체계적 접근 방법에 대해 설명합니다. DTA와 BAM은 아키텍처 구성 요소를 일부 공유하지만 이 항목에서는 DTA 동작만 다룹니다. BAM 아키텍처에 대한 자세한 내용은 BAM(비즈니스 활동 모니터링)을 참조하세요.
DTA 추적 아키텍처 개요
메시지가 시스템을 통해 이동함에 따라 메시지 본문, 속성 및 이벤트와 같은 다양한 추적된 요소가 일련의 프로세스 및 데이터베이스를 거쳐 궁극적으로 BizTalkDTADb 데이터베이스에 기록됩니다. 해당 요소가 BizTalkDTADb 데이터베이스에 기록되면 추적을 사용하여 추적된 정보를 쿼리할 수 있습니다. BizTalkDTADb 데이터베이스 설정 및 사용 및 추적에 대한 자세한 내용은 기록 및 추적된 데이터 보기를 참조하세요.
시스템이 계속 유지되고 지정된 메시지 흐름 속도로 계속 실행되도록 하려면 추적된 요소가 BizTalkDTADb 데이터베이스에 도달하기 위해 통과하는 경로 및 데이터베이스 자체를 양호한 상태로 유지해야 합니다. 예를 들어 도중에 데이터베이스 테이블 또는 DTA에 쌓이는 메시지를 제대로 관리하지 않으면 데이터베이스 파일의 크기가 무제한으로 늘어나 유지가 불가능해질 수 있습니다.
이에 따라 추적된 정보가 통과하는 아키텍처 및 경로를 먼저 알아 봅니다. 이렇게 하면 추적 시스템이 BizTalk Server 엔진을 통해 흐르는 메시지 트래픽을 얼마나 잘 따라가는지 확인하기 위해 모니터링해야 하는 주요 리소스 및 성능 지표가 표시됩니다.
다음 그림은 DTA 추적 아키텍처 및 경로를 개략적으로 보여 줍니다.
그림에서 번호가 매겨진 프로세스를 순서대로 보면 모든 DTA 추적 데이터가 다음과 같이 BizTalkDTADb 데이터베이스를 통해 흐름을 알 수 있습니다.
BizTalk Server 런타임 프로세스에는 인터셉터라는 구성 요소가 포함됩니다. 인터셉터는 추적된 요소를 런타임에 캐시하고 다음 MessageBox 데이터베이스 왕복 시(예: MessageBox 데이터베이스 큐에 메시지를 넣음) 캐시된 요소를 MessageBox 데이터베이스로 전달합니다. 인터셉터는 관리 데이터베이스에서 가져와 인터셉터에서 사용할 수 있도록 각 호스트 런타임 인스턴스에 캐시되는 추적 구성(추적 프로필)을 참조하여 추적할 요소를 결정합니다.
위의 그림에서처럼 MessageBox 데이터베이스에는 다음과 같은 두 개의 데이터 스트림이 삽입되어 있습니다.
Spool 테이블로 표시되는 데이터 스트림
TrackingData 테이블로 표시되는 데이터 스트림
추적된 메시지 본문에는 이 두 스트림이 모두 사용됩니다. 즉, 메시지 본문 자체(데이터 BLOB으로 간주)는 Spool 테이블로 표시되는 테이블 집합을 통해 처리됩니다. 메시지 본문과 연결된 메시지 이벤트(예: 메시지 식별자 즉, 메시지 본문 추적 시 메시지 본문에 연결된 인스턴스)는 TrackingData 테이블을 통해 처리됩니다. 메시지 본문 추적에 연결되지 않은 모든 추적 요소는 TrackingData 테이블을 통해서만 처리됩니다.
MessageBox 데이터베이스는 추적된 데이터가 거치는 첫 번째 경로일 뿐이며 추가 데이터 추적 처리 작업에 의해 직접 차단되지 않고 런타임에서 계속 처리를 수행할 수 있도록 추적된 데이터를 캐시하는 데 사용됩니다.
추적된 메시지 본문(Blob)을 BizTalkDTADb 데이터베이스로 전송하여 보고 더 영구적인 스토리지에 보관할 수 있도록 BizTalk Server 각 MessageBox 데이터베이스 서버에서 실행되는 TrackedMessages_Copy_BizTalkMsgBoxDb 라는 SQL 에이전트 작업을 사용합니다. 이 작업은 추적용으로 표시된 메시지 본문을 BizTalkDTADb 데이터베이스에 복사합니다.
메시지 본문 이외의 추적된 모든 데이터는 하나 이상의 BizTalk Server 호스트에서 실행되는 TDDS라는 서비스에 의해 MessageBox 데이터베이스에서 BizTalkDTADb 데이터베이스로 이동됩니다. 호스트가 BizTalk Server 관리 콘솔의 호스트 속성 페이지를 통해 호스트 추적으로 구성될 때마다 TDDS 하위 서비스가 해당 호스트의 모든 인스턴스에서 실행됩니다.
BizTalkDTADb 데이터베이스를 주기적으로 제거하지 않으면 크기가 무제한으로 늘어나 결국 작동 문제까지 발생할 수 있습니다. BizTalkDTADb 데이터베이스를 제거하는 작업으로는 DTA 제거 및 보관(BizTalkDTADb) SQL 에이전트 작업이 유일합니다. 기본적으로 이 작업은 1분마다 실행되어 24시간과 같이 사용자가 구성한 시간보다 오래된 인스턴스 중 완료된 인스턴스를 모두 제거합니다.
DTA 제거 및 보관 작업에 대한 자세한 내용은 DTA 제거 및 보관 작업을 구성하는 방법을 참조하세요.
필요에 따라 DTA 제거 및 보관 작업은 장기간 스토리지 및/또는 데이터 오프라인 보기를 위해 BizTalkDTADb 데이터를 SQL 백업으로 보관할 수도 있습니다. 보관된 BizTalkDTADb 데이터를 쿼리해야 할 경우 먼저 해당 데이터를 SQL Server에서 새 데이터베이스로 복원해야 추적 또는 SQL 쿼리 분석기와 같은 도구를 사용하여 쿼리할 수 있습니다.