시스템 지속 가능성을 계획하고 추정할 때는 장기적으로 지속 가능성 측면에서 생각하는 것이 중요합니다. 주요 고려 사항은 다음과 같습니다.
로드 프로필 및 성능 목표: 프로필 및 성능 목표를 로드할 때 세부 정보를 너무 많이 사용할 수 없습니다. 테스트 및 준비 인증은 이러한 부하를 장기적으로 처리할 수 있는 것을 기반으로 합니다.
서버 리소스를 위해 경쟁하는 다른 활동 및 프로세스: 메시지 로드에 관한 것이 아닙니다. 서버에서 데이터베이스 유지 관리 및 MessageBox 쿼리와 같은 성능에 영향을 주는 다른 프로세스 및 활동이 있습니다.
계획 및 계획되지 않은 시스템 중단 및 가동 중지 시간: Floodgate 이벤트 및 메시지 백로그는 유효 부하 프로필을 변경할 수 있습니다.
지속 가능한 시스템을 구축하고 이를 인증하는 테스트를 고려할 때는 이러한 요인을 고려하여 계획을 세워야 합니다.
성능이 지속 가능한가요?
BizTalk Server 성능에 대해 논의할 때 다음과 같이 지속 가능한 최대 성능을 정의합니다.
프로덕션 환경에서 시스템이 무기한으로 처리할 수 있는 가장 높은 메시지 트래픽 부하입니다.
이는 간단해 보이지만 특정 하드웨어 집합에서 실행되는 솔루션이 프로덕션 환경에 솔루션을 배치한 후 매일 경험하는 부하를 지원할 수 있는지 여부를 평가할 때 고려해야 하는 많은 요소가 있습니다.
솔루션을 프로덕션 환경에 배치하기 전에 다음 요인을 고려하여 솔루션이 메시지 트래픽의 가장 높은 부하를 무기한 처리할 수 있는지 여부를 평가합니다.
원하는 성능 목표 및 처리량/대기 시간 프로필
동일한 하드웨어에서 실행되는 다른 프로세스는 다음과 같습니다.
일반 모니터링 및 문제 해결
로그 전달, 백업, 제거, 인덱스 유지 관리 및 통계 업데이트와 같은 운영 데이터베이스 유지 관리
기타 애플리케이션
다음과 같은 계획되거나 계획되지 않은 시스템 중단:
파트너 사이트 장애로 인해 메시지를 보내거나 받을 수 없습니다.
정기적인 시스템 유지 관리 가동 중지 시간
성능 목표 파악
지속 가능성에 대한 솔루션을 평가하려면 먼저 예상 프로덕션 부하에 대한 자세한 이해가 있어야 합니다. 잘 이해된 목표가 없으면 준비 상태를 평가할 수 없습니다. 잘 구성된 성능 목표 집합은 시스템 테스트 및 인증에 대한 전략을 추진하기 때문에 매우 중요합니다. 성능 목표에는 다음과 같은 요소가 있어야 합니다.
성능을 시간 함수로 정의하는 곡선입니다. 이러한 함수는 매우 간단한 함수부터 매우 복잡한 함수까지 다양할 수 있습니다.
성능 함수와 관련된 성능 요구 사항입니다.
파일 크기 및 형식의 분포입니다.
예제 1
매일 메시지는 오전 8시에 0 메시지/초에서 정오에 80 메시지/초로 증가한 다음, 오후 9시에 0 메시지/초로 감소하며, 대체로 종 모양 곡선을 그립니다.
시스템에는 각 메시지에 대한 특정 대기 시간 요구 사항이 없지만 이 로드와 전날의 모든 메시지 로드(예: 24시간 시스템 중단 발생 시)를 모두 처리할 수 있어야 합니다.
세 가지 문서 유형은 판매 바구니, 백 오더, 재고 요청입니다. 판매 바구니 문서 크기는 2~10킬로바이트 사이이며 지정된 시간에 메시지 수의 75%을 구성합니다. Back Order 및 Stock Request 문서는 항상 크기가 1킬로바이트에 가깝고, 지정된 시간에 메시지 수의 나머지를 각각 10개% 및 15개%로 구성합니다.
예제 2
매일 밤 자정에 처리를 위해 500,000개의 메시지 일괄 처리가 도착합니다.
일괄 처리의 모든 메시지는 8시간 후에 완료될 수 있도록 처리되어야 합니다.
모든 메시지는 동일한 형식이며 10~50킬로바이트(포함) 사이에 균등하게 분산됩니다. 또한 일괄 처리에는 항상 각각 10MB인 10개의 카탈로그 형식 메시지가 포함되며 처리를 위해 개별 카탈로그 항목으로 세분화되어야 합니다.
예제 3
매일 아침 8:00AM에 4,000명의 고객 서비스 담당자가 대화형 시스템에 로그온하여 주 7일 오후 5시 00분에 마감될 때까지 분당 평균 4개의 문의를 수행합니다.
모든 문의는 2초 이내에 결과를 반환해야 합니다.
모든 문의는 동일한 형식이며 500~1,000바이트 크기로 균등하게 분산됩니다.
성능 함수와 관련된 성능 요구 사항
위의 예제를 계속 진행합니다.
예제 1(계속): 시스템에는 각 메시지에 대한 특정 대기 시간 요구 사항이 없지만 이 로드를 처리할 수 있어야 하며, 뒤처지지 않고 전날의 모든 메시지 로드(예: 24시간 시스템 중단 시)를 처리할 수 있어야 합니다.
예제 2(계속됨) : 일괄 처리의 모든 메시지를 8시간 후에 완료하도록 처리해야 합니다.
예제 3(계속됨) : 모든 문의는 2초 이내에 결과를 반환해야 합니다.
파일 크기 및 형식의 분포
예제 1(계속됨): 세 가지 문서 유형, 즉 판매 바구니, 후진 주문 및 주식 요청이 있습니다. 판매 바구니 문서 크기는 2~10킬로바이트 사이이며 지정된 시간에 메시지 수의 75%을 구성합니다. Back Order 및 Stock Request 문서는 항상 크기가 1킬로바이트에 가깝고, 지정된 시간에 메시지 수의 나머지를 각각 10개% 및 15개%로 구성합니다.
예제 2(계속됨): 모든 메시지는 형식이 동일하며 10~50킬로바이트(포함) 사이에 균등하게 분산됩니다. 또한 일괄 처리에는 항상 각각 10MB인 10개의 카탈로그 형식 메시지가 포함되며 처리를 위해 개별 카탈로그 항목으로 세분화되어야 합니다.
예제 3(계속): 모든 문의는 동일한 형식이며 500바이트에서 1,000바이트 사이의 크기(포함)로 균등하게 분산됩니다.
다른 프로세스에 대한 회계
BizTalk 엔진을 통해 직접 전달하는 부하 프로필 외에도 동일한 하드웨어에서 리소스를 위해 경쟁하는 다른 프로세스가 항상 있습니다. 이러한 다른 프로세스는 시스템의 전반적인 지속 가능한 성능 기능을 감소시킬 것입니다. 데이터베이스 유지 관리는 아마도 이러한 유형의 프로세스의 가장 일반적인 예일 것입니다.
규모가 크거나 작은 모든 데이터베이스에는 로그 전달, 백업, 보관 및 제거와 같은 주기적인 운영 유지 관리가 필요합니다. 모니터링 및 문제 해결은 지속 가능한 항목을 정의하고 인증할 때 고려해야 하는 작업의 다른 예입니다. 예를 들어 메시지 상자(예: 관리 콘솔 그룹 허브 페이지를 통해)를 쿼리하여 지난 24시간 동안 일시 중단된 특정 유형의 메시지 수를 확인하려면 메시지를 처리하는 데 사용될 수 있는 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와 같은 모든 저장 및 전달 메시징 기반 비동기 시스템은 계획되거나 계획되지 않은 중단에 대처하기에 충분한 "헤드룸"을 처리하도록 설계되어야 합니다.
또한 참조하십시오
엔진 지속성 및 내구성
단계별 프로젝트 계획 권장 사항
최대 지속 가능한 엔진 처리량 측정
지속 가능한 최대 추적 처리량 측정
솔루션 크기 조정
성능 병목 상태 식별
엔진 성능 및 용량