오래전에 어느 프로젝트에서 SOAP Sender Channel를 사용한 하나의 인터페이스를 가지고 많은 클라인트에서 호출하여 부하테스트를 한적이 있습니다. 그때 인터페이스 하나로 SAP PI 7.3시스템에 부하가 생겨 다른 인터페이스들까지 영향을 주는걸 확인했었는데 이런 현상을 PO 7.5에서 보게 되었네요. 이번기회에 이런 부하가 발생되는 현상과 원인 그리고 해결방법에 대해 공부하면서 정리를 해봤습니다.
징후와 현상
PO 메세지모니터링에서 'To be delivered'라는 메세지를 발견하게되면 제일먼저 소스시스템에서 들어온 메세지가 타겟시스템으로 전송이 원활하지 않다고 생각하게 되며 이런 상태가 쌓이게 되면 PO를 호출하는 HTTP Transport Protocol의 SOAP, REST, ABAP Proxy 및 PO와 HTTP방식으로 구성되는 시스템에서도 영향이 생기는것 같습니다. 예를 들어 ERP에서 ABAP Proxy로 호출하는 메시지에 에러가 발생되는데
408-Request Timeout
PO를 호출했는데 요청대기시간을 초과해서 타임아웃이 발생된거며 PO의 ICM과 Web Dispatcher에서 HTTP 요청에 대해 수신허용시간을 초과해서 발생되는것 같습니다.
411-Connect to [PO Server:Port] failed: NIECONN_Refused(-10)
이 에러에 대해서는 잘 모르겠지만 PO에서 HTTP요청을 정상적으로 받지 못할때 발생되는것 같습니다.
그외 'SPROXY' 티코드를 실행할때 아래와 같은 에러가 발생될수 있습니다.
Could not establish connection to ES Repository using [PO ESR Destination명] : Connection Refused: 404
그리고 PO서버의 AP서버들의 스레드가 문제가되는 인터페이스의해 HTTP관련 모든 스레드가 'Processing' 상태로 점유되는 현상이 발견되며 PO의 접속되는 세션수가 점점 늘어나는 것을 볼수 있습니다.
원인
위와 같은 현상이 발생되는 원인에 대해 아래의 노츠에서 확인을 했습니다.
1623356 - 'To be delivered' messages in Adapter Engine
1593920 - Synchronous SOAP sender calls: fine tune PI under high load
'To be Delivered' 메세지 상태는 PO내부에서 메시지를 처리할수 있는 자원(스레드)수가 부족해서 발생될수 있으며 시스템을 재시작하는 경우 해결되는 경우가 있다고 합니다. 하지만 이건 근본적인 문제 해결은 아닌거 같네요.
예를들어 동일한 어댑터 엔진에 동기방식의 SOAP요청이 너무 많은 메시징 큐에 부하가 발생될수 있습니다.
해결방법
메시징부하를 일키는 스레드에 대해 크기를 늘리는 방법이 있지만 송신 시스템에서 비정상적으로 호출하는 경우 근본적인 해결책은 아닌것 같으며 오히려 Sender채널에 사용된 어댑터 타입에 따라 XI.TImeout 또는 syncTimeout에 타임아웃 값을 설정하여 대량으로 전송되는 메시지에 대해 PO에서 발생될수 성능문제를 방지할수 있을것 같습니다. 단, 평소에 해당 인터페이스의 처리시간을 고려해서 설정할 필요성이 있습니다.
이런문제가 발생되는 경우는 송신시스템에서 비정상적으로 호출이 되어 발생되거나 타겟 처리가 지연됐을때 발생될수 있는 부분이라 근본적인 문제를 해결 후에 PO에 설정이 필요한부분에 대해 고려해야될것 같습니다.
댓글 없음:
댓글 쓰기