유지 가능한 성능 정의
시스템 지속성을 계획하고 예측할 때는 장기적인 지속성 관점에서 생각해야 합니다. 주요 고려 사항은 다음과 같습니다.
로드 프로필 및 성능 목표: 프로필 및 성능 목표를 로드할 때 세부 정보를 너무 많이 사용할 수 없습니다. 테스트 및 준비 상태 인증은 장기적으로 이러한 부하를 처리할 수 있는 능력을 기반으로 합니다.
서버 리소스를 위해 경쟁하는 기타 활동 및 프로세스: 메시지 로드에 관한 것이 아닙니다. 데이터베이스 유지 관리 및 MessageBox 쿼리와 같이 서버 성능에 영향을 미치는 다른 프로세스 및 활동도 있습니다.
계획 및 계획되지 않은 시스템 중단 및 가동 중지 시간: Floodgate 이벤트 및 메시지 백로그는 효과적인 부하 프로필을 변경할 수 있습니다.
지속 가능한 시스템 및 이를 인증할 테스트를 작성할 때는 다음과 같은 요소를 고려하여 계획해야 합니다.
유지 가능한 성능
BizTalk Server 성능에 대해 논의할 때 다음과 같이 지속 가능한 최대 성능을 정의합니다.
시스템이 프로덕션 환경에서 무기한으로 처리할 수 있는 최대 메시지 트래픽 부하
정의는 간단해 보이지만 솔루션을 프로덕션으로 옮긴 다음 특정 하드웨어 집합에서 실행되는 솔루션이 매일 발생하는 부하를 지원할 수 있는지 여부를 평가할 때는 많은 요소를 고려해야 합니다.
솔루션을 프로덕션으로 옮기기 전에 다음과 같은 요소를 고려하여 솔루션에서 최대 메시지 트래픽 부하를 무기한으로 처리할 수 있는지 여부를 평가합니다.
원하는 성능 목표 및 처리량/대기 시간 프로필
동일한 하드웨어에서 실행 중인 다음과 같은 기타 프로세스
일반 모니터링 및 문제 해결
로그 전달, 백업, 제거, 인덱스 유지 관리 및 통계 업데이트와 같은 운영 데이터베이스 유지 관리
기타 응용 프로그램
계획되거나 계획되지 않은 다음과 같은 시스템 중단
메시지 송수신을 차단하는 파트너 사이트 다운
정기 시스템 유지 관리 작동 중단
성능 목표 인식
솔루션의 지속성을 평가하려면 예상 프로덕션 부하에 대해 잘 알고 있어야 합니다. 목표를 잘 이해하지 못하면 준비 상태를 평가할 수 없습니다. 잘 구성된 성능 목표 집합은 시스템 테스트 및 인증에 대한 전략을 추진할 때 매우 중요합니다. 성능 목표에는 다음과 같은 요소가 있어야 합니다.
성능을 시간의 함수로 정의하는 그래프. 이러한 함수는 지극히 간단한 것에서부터 매우 복잡한 것까지 아주 다양합니다.
성능 함수와 관련된 성능 요구 사항
배포 파일 크기 및 유형
예 1
매일 오전 8시에 초당 0개의 메시지로 시작하여 정오에 초당 80개의 메시지까지 쌓인 다음 다시 오후 9시에 초당 0개의 메시지로 줄어 종 모양의 곡선이 형성됩니다.
시스템에는 각 메시지에 대해 특별한 대기 시간 요구 사항이 없지만 이 부하와 함께 전날의 모든 메시지 부하(24시간 시스템 중단이 있었던 경우)를 일정에 맞게 처리할 수 있어야 합니다.
세 가지 문서 유형이 있습니다. 판매 장바구니, 백 오더 및 주식 요청. Sales Basket 문서의 크기는 2-10KB로 메시지 수의 75%를 구성합니다. Back Order 및 Stock Request 문서의 크기는 항상 1KB에 근접하며 각각 메시지 수의 나머지 10%와 15%를 구성합니다.
예 2
매일 밤 자정에 처리를 위해 500,000개의 메시지가 일괄적으로 들어옵니다.
일괄 처리의 모든 메시지를 8시간 내에 완료해야 합니다.
모든 메시지는 동일한 유형이며 10-50KB로 고르게 배포됩니다. 또한 일괄 처리는 각각 10MB인 카탈로그 유형 메시지를 항상 10개 포함하므로 처리를 위해 개별 카탈로그 항목으로 분리되어야 합니다.
예제 3
매일 오전 8시에 4000명의 고객 서비스 담당자가 대화형 시스템에 로그온하여 오후 5시에 종료할 때까지 담당자별로 분당 평균 4개의 문의 사항을 게시합니다.
모든 문의 사항에 대한 결과를 2초 이내에 반환해야 합니다.
모든 문의 사항은 동일한 유형이며 500-1000바이트로 고르게 배포됩니다.
성능 함수와 관련된 성능 요구 사항
위의 예를 계속 진행합니다.
예제 1(계속): 시스템에는 각 메시지에 대한 특정 대기 시간 요구 사항이 없지만 이 로드와 전날의 모든 메시지 로드(예: 24시간 시스템 중단 시)를 처리할 수 있어야 합니다.
예제 2(계속): 일괄 처리의 모든 메시지를 8시간 후에 완료하도록 처리해야 합니다.
예제 3(계속): 모든 문의는 2초 이내에 결과를 반환해야 합니다.
배포 파일 크기 및 유형
예제 1(계속): 세 가지 문서 유형이 있습니다. 판매 장바구니, 백 오더 및 재고 요청. Sales Basket 문서의 크기는 2-10KB로 메시지 수의 75%를 구성합니다. Back Order 및 Stock Request 문서의 크기는 항상 1KB에 근접하며 각각 메시지 수의 나머지 10%와 15%를 구성합니다.
예제 2(계속): 모든 메시지는 형식이 동일하며 10~50K바이트 사이에 균등하게 분산됩니다( 포함). 또한 일괄 처리는 각각 10MB인 카탈로그 유형 메시지를 항상 10개 포함하므로 처리를 위해 개별 카탈로그 항목으로 분리되어야 합니다.
예제 3(계속): 모든 문의 유형이 동일하며 500바이트에서 1,000바이트 사이로 균등하게 분산됩니다(포함).
기타 프로세스
BizTalk 엔진을 직접 통과하는 부하 프로필 외에도 항상 동일한 하드웨어의 리소스를 차지하기 위해 경쟁하는 다른 프로세스가 있습니다. 이러한 다른 프로세스는 시스템에서 지속 가능한 전체 성능을 저하시킵니다. 이러한 프로세스 유형의 가장 일반적인 예로는 데이터베이스 유지 관리를 들 수 있습니다.
크기에 상관없이 모든 데이터베이스에는 로그 전달, 백업, 보관 및 제거와 같은 정기적인 운영 유지 관리 작업을 수행해야 합니다. 모니터링 및 문제 해결은 지속성을 정의하고 인증할 때 고려해야 하는 작업의 다른 예입니다. 예를 들어 지난 24시간 동안 일시 중단된 특정 유형의 메시지 수를 확인하기 위해 관리자 콘솔 그룹 허브 페이지 등을 통해 MessageBox를 쿼리하려면 메시지 처리에 사용해야 하는 SQL Server 리소스가 필요합니다.
다음은 일반적으로 BizTalk Server 전반적인 지속 가능성에 가장 큰 영향을 미치는 활동 목록입니다.
로그 전달 및 백업. SQL Server 관련된 대부분의 재해 복구 계획의 일부로 모든 BizTalk Server 그룹 데이터베이스에 대해 주기적으로 로그 전달 및 백업을 수행해야 합니다. 자세한 내용은 BizTalk Server 데이터베이스 백업 및 복원을 참조하세요. 로그 전달도 참조하세요.
추적 데이터 보관 및 제거. 전체 로그 전달 및 백업 계획 외에도 BizTalk 추적(BizTalkDTADb) 데이터베이스에는 자체 보관 및 제거 체제가 있습니다. 자세한 내용은 BizTalk 추적 데이터베이스 보관 및 제거를 참조하세요. 추적을 사용하는 경우 BizTalk 추적 데이터베이스의 보관 및 제거 작업으로 인해 일반적으로 병목 상태가 발생하므로 BizTalk 추적 데이터베이스에서 데이터를 보관하고 제거할 수 있는 속도는 매우 중요합니다.
시스템 쿼리. API 또는 BizTalk Server 관리 콘솔 UI를 사용하여 시스템에 대해 다양한 유형의 쿼리를 실행하는 경우 지속 가능한 성능에 영향을 미칩니다.
MessageBox 유지 관리. 처리를 완료한 메시지 및 인스턴스를 정리하여 MessageBox 데이터베이스를 유지하는 BizTalk Server 핵심 기능의 일부인 여러 SQL 작업이 있습니다. 핵심 엔진의 일부로 이러한 작업을 완료할 수 있는 속도는 지속성을 평가하는 핵심 요소입니다. 이러한 작업 및 해당 역할에 대한 자세한 내용은 BizTalk Server1 유지 관리를 참조하세요.
솔루션 배포 활동. 새 응용 프로그램이나 기존 응용 프로그램의 새 버전을 배포, 바인딩 및 시작하면 MessageBox 데이터베이스에서의 새 등록 생성과 같은 추가 부하가 BizTalk에 발생합니다. 응용 프로그램이 배포된 다음 처리 중인 메시지는 리소스를 차지하기 위해 경쟁하므로 기존 응용 프로그램의 성능에 영향을 미칩니다.
이러한 각 영역에 대해 다음을 물어봐야 합니다. 이러한 활동의 영향을 최소화하기 위한 권장 사항은 무엇인가요? 예를 들어 실행 시간을 오전 3시로 계획해야 하는지 등을 생각해 봅니다.
계획되거나 계획되지 않은 중단 고려
시스템 중단이 시스템 성능에 미치는 영향은 중단이 발생하는 시스템에 따라 다르지만 가장 일반적인 결과는 다음과 같습니다.
플러드게이트 이벤트. 시스템이 일정 기간 동안 다운된 다음 다시 작동되면 메시지가 쌓여 처리를 위해 한꺼번에 도착할 수 있습니다. 예를 들어 BizTalk에서 실행 중인 응용 프로그램이 MSMQ를 통해 메시지를 수신하는 경우 해당 응용 프로그램이 일정 기간 동안 다운되면 메시지가 큐에서 선택될 때까지 계속 쌓입니다. 응용 프로그램이 다시 시작되면 많은 양의 메시지가 한꺼번에 도착합니다.
메시지 백로그. 메시지가 전송된 시스템이 다운되면 일반적으로 추가 리소스를 사용하는 재시도 주기가 생깁니다. 재시도 주기가 모두 사용된 다음에는 일반적으로 메시지가 일시 중단됩니다. 그런 다음 다운된 시스템이 다시 온라인 상태가 되면 많은 수의 메시지를 다시 시작하고/거나 성공적으로 보낼 수 있는 플러드게이트 이벤트 유형이 발생합니다.
시스템을 디자인하고 인증할 때는 정기적인 예약 유지 관리와 같은 계획된 중단을 반드시 고려해야 합니다. 계획되지 않은 중단 및 그 영향에 대해서도 고려하는 것이 좋습니다.
발생할 수 있는 중단 유형을 식별하고 예상 위험 수준(확률 * 심각도)에 따라 해당 유형의 순위를 정하며 위험이 큰 중단의 기간 및 영향(예: 플러드게이트 이벤트, 일시 중단된 메시지 양, 백로그 등)을 예측하면 중단이 발생할 경우의 바람직한 시스템 역량을 알아낼 수 있습니다. BizTalk Server 같은 모든 저장 및 전달 메시징 기반 비동기 시스템은 계획되고 계획되지 않은 중단에 대처하기에 충분한 "헤드룸"을 처리하도록 설계되어야 합니다.
참고 항목
엔진 지속성 및 내구성
단계별 프로젝트 계획 권장 사항
유지 가능한 최대 엔진 처리량 측정
유지 가능한 최대 추적 처리량 측정
솔루션 확장
성능 병목 상태 확인
엔진 성능 및 용량