Aaron H. Kim Fearless Integration Maniac

BizTalk HTTP Adapter의 Batch size 설정 관련 주의할 점.


다음은 실제 프로젝트에서 발생한 상황으로, HTTP Adapter의 batch size를 정할 때 주의해야 할 점으로 생각되어 경험을 공유하고자 합니다.

Business Scenario는 결재 시스템으로, BizTalk의 웹서비스를 통해 요청을 수신받고, 메시지를 맵을 태워 SAP의 RFC를 호출하고 결과를 받아온 후, Logging을 위해 외부 웹서비스를 호출하고 있습니다.

일단 상식적으로 Adapter의 Batch Size는 크면 클수록 BizTalk MessageBox로의 Round trip을 줄일 수 있기 때문에 적당히 조절했을 경우엔 Performance에서 이득을 볼 수 있습니다. 가령 Batch size가 100이라고 했을 때 이것은 100개 단위로 batch 처리하겠다는 의미가 되므로, 100개의 메시지를 한 번에 MessageBox에 저장하는 것이 하나씩 100번 DB로 round trip하는 것보다 빠르리라는 것은 쉽게 납득할 수 있습니다. (물론 이 경우도 batch size에 정해진 갯수를 만족할 때까지 무한정 기다리는 것은 아니고 엔진이 판단해서 가져올 수 있도록 내부적인 타이머가 존재하리라 생각합니다)

다만, 이렇게 했을 때의 문제는 각각의 메시지를 처리하는 시간은 늦어질 수 밖에 없다는 것입니다. 만약 한꺼번에 여러 문서가 수신되지 않고, 드문 드문 한 건 씩 들어온다면, 매번 엔진이 판단해서 넘기기 전까지 기다리게 되므로 그만큼 사용자가 느끼는 Latency는 길어질 것이고, 대개의 경우 언제나 Extremely Low Latency를 요구하는 고객들의 원성을 사게 될 것입니다. 전에 시스템을 쓸 땐 안그랬는데, BizTalk으로 바꾸니 느려졌더라 하는 식의 소리가 나오게 되는 것이죠. 따라서 개발자는 메시지가 들어오는 간격과 수량 등을 미리 충분한 테스트를 통해 예측하고 최적의 값을 설정할 필요가 있습니다.

다만, HTTP Adapter의 경우, batch size는 가급적 낮은 숫자로 하는 것이 좋을 듯 합니다. 이해를 돕기 위해 다음 로그를 준비했습니다.

<로그 테이블="" 사진="" 잃어버림=""> 붉은 색 글씨는 웹서버(BizTalk 수신부)에 남겨진 웹로그이며, 나머지는 DebugView에 남겨진 Trace 내용입니다.(웹서버 시간은 UTC이므로 +9) 보시면 두 번째 메시지의 경우 웹로그는 남아 있으나(202 리턴), DebugView 로그가 남겨져 있지 않습니다. DebugView의 로그는 Orchestration이 initiate됨과 동시에 생성되므로, Orchestration이 아예 생성되지 않았음을 알수 있습니다. BizTalk Admin을 살펴본 결과 Suspended 된 메시지도 없습니다. 이런 경우 메시지가 누실되었다라고 하는데, BizTalk은 완벽하게 Reliable한 Messaging을 보장하는 시스템을 표방하므로, 이와같은 일은 절대로  발생해선 안될 상황이지요.   그렇다면 무슨 일이 일어난 걸까요? 정말로 공교롭게도.. 두 번째 메시지가 들어온 시각 근처에 고객측 서버 관리자들의 실수로 인해 네트워크 오류가 발생, BizTalk Server와 SQL Server사이의 네트워크 연결이 끊어지는 상황이 발생했다고 합니다. 여기서 우리가 추론해볼 수 있는 것은, 1. 웹서버에 남겨진 웹로그에는 분명 202를 반환했으므로, 웹서버에서는 메시지를 수신받았으나, 2. batch size가 10이었던 관계로 어댑터는 메시지를 바로 BizTalk MessageBox로 보내지 않았고, 메시지는 웹서버의 메모리에 남아있었으리라는 것입니다. => MS 관계자 분께 문의했더니 이런 경우 메시지는 그냥 Drop한답니다. (07/12/01 수정) 3. 그리고 그 때 당황한 웹 서버 관리자는 iis를 restart했고, 메모리에 있던 메시지는 누실되어 버린 것이죠. => 2번의 이유로 3번은 더 이상 의미가 없군요. (07/12/01 수정) 아주 드문 예이지만, 위와 같은 상황이 다시 발생하는 것을 막기 위해서 가장 먼저 해야 할 것은 batch size를 줄여서 HTTP Adapter가 메시지를 바로바로 BizTalk의 MessageBox에 넣게끔 하는 것입니다. Persistence Point의 필요성을 상기해보면 역시 Reliability와 Performance는 Trade off한 관계이므로, 중요도에 따라 현명하게 판단해야겠지요. 다음으로 주의 할 일은, 네트워크 오류가 해결되고 나면 웹 서버의 메모리에 남아있던 메시지는 정상적으로 BizTalk의 MessageBox로 흘러들어가게 될 것이므로(이 부분은 예측일 뿐입니다만), 웹 서버 관리자는 절대로 당황해서 iis를 restart한다던가 recycle하는 등의 실수를 해서는 안될 것입니다. => 2번의 이유로 인해, http batch size를 1로 하는 것은 필수적이라 해야 겠군요. (07/12/01 수정) (이하 추가 07/12/01) batch size를 줄이는 것 외에도 핸들러가 메시지를 가져오는 간격을 줄여 줄 수도 있습니다. 아래 참조하세요. <http://msdn2.microsoft.com/en-us/library/aa547842.aspx>

Similar Posts

Comments