Aaron H. Kim Fearless Integration Maniac

BizTalk 주요 Bottleneck 분석

2008-07-24
Aaron Kim

오늘은 Tuning에 대한 얘기를 해볼까 합니다.

BizTalk 시스템의 개발이 완료되고 나서 운영을 하다보면 개발시에는 발생하지 않았던 문제들이 발견되곤 하는데
이건 운영 환경으로 넘어갔을 때 트랜잭션의 양이 늘어남에 따라 발생할 수 있는 문제점들을 충분히 고려치 못했기 때문입니다. 따라서 사전에 LoadGen 과 같은 Tool을 통해 Stress Test(부하 테스트)를 해보는 것이 중요하겠지요.

참고로 BizTalk 2004 시절에는 Tuning을 한다는 것이 새가슴의 소유자에겐 쉽지 않은 일이었습니다. Management Console의 속성창을 가지고 해볼 수 있는 건 많지 않았고, 직접 레지스트리를 손대거나,  adm_ServiceClass : BizTalkMgmt Db의 값을 수정해주거나 해야 했기 때문이지요. 하지만 BizTalk 2006에서는 Throttling이 자동으로 이루어 지며, 속성창을 통해 이 값들을 수정해줄 수 있습니다. (물론 권장하진 않음) BizTalk 2006의 Management Console –> Hosts –> Hosts 선택 –> Properties –> Advanced에서 확인 가능합니다.

BizTalk Server 2006은 2004버전에 비해 Tuning하기가 비교적 수월해졌습니다만 레지스트리나, adm_ServiceClass가 없어진 것은 아닙니다. HTTP나 SOAP Adapter의 일부 Tuning은 여전히 레지스트리를 건드려줘야 하고, BizTalk은 기본적으로 최대 0.5초 내에 수신 메시지들을 폴링하는 간격을 자동 조절하는 방법으로 최적화가 이뤄지는데 Latency(잠복기)가 이슈가 될 경우, adm_ServiceClass내의 MaxReceiveInterval 값을 수정해주는 방법을 써야 Tuning이 가능합니다.

Tuning을 위해 준비해야 할 첫번째는 일단 시스템의 어느 부분이 bottleneck(병목)인지를 확인하는 것입니다.  이걸 확인하는데는 Performance Counter(성능 카운터)가 주로 사용되는데 운영체제 시스템 용도로만 있는게 기본적으로 30개, 여기에 BizTalk Server를 설치하면 추가되는 카운터가 무려 294개, 만약 두 대의 BizTalk 서버가 있다면 성능 측정할 카운터가 무려 648개(294 x 2 + 30 x 2)가 됩니다. 그렇다면 이 많은 카운터들을 일일이 추가하는 것도 참 번거롭겠군요. 이를 좀 더 간편화하는 방법에 대해서는 기존에 말씀드린 내용을 참고하시면 되겠습니다.

Powershell Script로 Perfmon counter 추가하기 [Script] Performance Counter][2]

그렇다면 이제 데이터 수집은 끝났다 치고, 이렇게 수집한 정보를 가지고 Bottleneck을 분석한 후 문제 해결 방법을 모색해 봐야 할 차례입니다. Performance Counter를 분석한 사례별로 가능 원인 및 대처할 사항, 추가로 도움될 만한 내용들을 정리해 봤습니다.

1. BizTalk Server에서의 낮은 % CPU idle time

원인 및 대처 : CPU idle time이 낮다는 것은 그만큼 사용률이 높다는 뜻입니다. 서버에 너무 많은 호스트 인스턴스가 실행되고 있거나 Custom pipeline을 잘못 사용하고 있을 확률이 높습니다. Custom component 개발 내용을 살펴보고 필요시 최적화 해줄 필요가 있습니다. 

추가 :

  1. 수신, 처리, 송신 각 기능별로 호스트를 나누고, BizTalk Server Group내의 서로 다른 서버에서 호스트 인스턴스를 생성해 돌린다.
  2. 메시지 변환(Map)은 가급적 Orchestration에서가 아닌 포트에서 처리할 수 있도록 이동시킨다. 이렇게 하면 불필요한 메시지 복사를 줄일 수 있다.
  3. 메시지 필터도 되도록 포트나 수신 위치에서 처리하도록 이동시킨다.
  4. 스키마를 최적화 할 것. 큰 스키마는 성능에 영향을 미친다.
  5. Promoted Properties나 Xpath를 사용하기 보다 항상 모든 가능한 경우에 Distinguished Field를 사용한다.
  6. 가급적 가능한 모든 경우에 pass-through pipeline을 사용한다.

2. SQL Server에서의 낮은 % CPU idle time

원인 및 대처 : BizTalk 서버 설치시 BizTalk이 알아서 설정해둔 세팅을 혹 DBA가 바꾼게 아닌지 확인해야 합니다. 이중에는 DBA가 일반적인 SQL Server 성능 향상을 위해 하는 설정과 반하는 것들이 있기 때문입니다. (예 : BizTalk에서는 Auto-Create Statistics = off, Auto-Update Statistics = off, Max Degree of Parallelism = 1 로 설정합니다.)

추가 :

  1. Persistence Point를 최대한 줄인다. 
    다음 웹캐스트 참조 : <A href=”http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032355826&EventCategory=2&culture=ko-KR&CountryCode=KR” target=_blank>BizTalk 2006 R2 : 보다 나은 오케스트레이션의 설계 및 구현</A>
  2. Atomic Scope에서 .Net Helper Class 사용시 nonserializable한 컴포넌트를 Serializable한 클래스로 감싸느라 애쓰지 말고 그냥 Static 함수를 사용한다.
  3. 가급적 Parallel Shape(병렬 셰이프)은 사용하지 않는다. 물론 필요한 경우는 제외.
  4. 다중 MessageBox를 사용하는 시나리오의 경우, 적어도 세 개의 MessageBox를 사용해야 함을 잊지 말것. 마스터 MessageBox가 메시지들을 보조 MessageBox들에게 Routing하는 작업은 CPU가 Intensive하게 사용 되며 메시지 이동간에 항상 MS-DTC가 관여하므로 적어도 세 개의 MessageBox는 있어야 그 오버헤드를 상쇄시킬 수 있다.

3. SQL Server에서의 낮은 % Disk idle time / 높은 평균 Disk Queue 길이

원인 및 대처 :

  1. BizTalkDTADb와 MessageBox Db가 동일 디스크에 있는게 아닌지 체크할 것.
  2. Data와 Log 파일들이 같은 디스크에 있는게 아닌지 체크할 것.
  3. 로그 사이즈 체크할 것.
  4. SQL Agent를 통해 BizTalk Databases 백업 Job이 잘 돌아가고 있는지 확인할 것.
       (Backup BizTalk Server (BizTalkMgmtDb))
  5. Job을 통해 Tracking한 메시지들의 Body가 제대로 Archive되고 있는지 확인할 것.
       (DTA Purge and Archive (BizTalkDTADb))

추가 :

  1. SAN을 사용할 것.
  2. Tracking을 위한 DB와 MessageBox DB들이 서로 다른 서버에 있게 할 것. 같은 서버를 사용해야 한다면 서로 다른 디스크를 사용하도록 할 것.
  3. Data와 Log 파일들이 같은 디스크를 사용하지 않도록 할 것.
  4. BizTalk Job들을 실행시키는 SQL Agent가 돌아가고 있는지 확인할 것.

정리했으니 다음에 찾아보기는 좀 더 쉽겠죠.


Similar Posts

Comments