불필요한 백로그(Backlog) 확인방법
백로그 정보는 Adapter Engine Status > Backlog에서 볼수 있는데요. 예를들어 순차처리EOIO) 인터페이스인데 에러가 발생되어 에러는 캔슬했지만 뒤에 홀딩상태인 로그들이 오랫동안 백로그로 남아있는 경우가 있습니다. 이런 상태의 로그들을 삭제해주는 배치잡이 설정 안되어있다면 계속 불필요한 로그로 계속 남아있을것 같습니다.
이런 불필요한 백로그를 확인해서 처리하는 방법은
Messaging Overview에서 노드별로 확인도 가능하고 Additional Data > Message Details > Message in EOIO Sequences에 나오는 정보에 메시지 아이디를 클릭해서 확인되는 시퀀스 아이디로 조회해서 수동으로 홀딩상태인것들을 캔슬처리해주면 되는데 백로그 메시지들이 쌓이는 경우 시스템에 어떠한 영향을 주는지는 잘 모르겠지만 깔끔하게 정리되니 밀렸던 청소를 한 느낌이였습니다.
Adapter Engine(Adapter Framework)의 전체적인 흐름을 볼때 아래와 같이 메시지 처리가 되는것 같습니다.
위와 같이 간단하게 AdapterEngine내부에 동작흐름을 간단하게 정리해보았고 그중 Module Processor와 Message Queue에 대해 상세하게 정리해보겠습니다.
대기열 이름들은 Send(Asynchronous outbound), Rcv(Asynchronous Inbound), Call(Synchronous outbound) or Rqst(Synchronous inbound) 이런 큐이름과 함께 어댑터 당 4개로 http://sap.com/xi/XI/System<Queue_Name> 형식으로 생성이 됩니다.
PO에 리소스 부족이나 부하 등으로 어댑터별로 아래의 상태의 백로그가 발생 되는 경우, 디스패쳐 대기열의 메시지 우선순위(Message Prioritiztion) 이나 병렬처리(PI Receiver Parallelism)의 개수제한 기능 등 설정을 통해 백로그에 대한 현상을 사전에 줄일수 있습니다.
*Processing Backlog(Synchronous and Asynchronous Message in Status 'DELIVERING' or 'TO BE DELIVERED')
PO 부하를 발생시키는 원인들로 인해 백로그 상태인 메시지들이 쌓이면서 노드가 다운이 되고 이런문제가 지속되어 다른 노드들까지 영향을 받아 연달아 다운이 되는 경우가 있었는데요.
Adapter Engine에 들어오는 문제가 되는 메시지들 사전에 알수 없을까? 라는 의문을 갖게 되는데요. 모니터링 화면을 계속 보면 되긴하는데 그외 SAP PI/PO Directory API를 사용한 프로그램을 구현하여 기본적인 PO모니터링외 확장된 기능을 만들어 사전에 모니터링 자동화 및 알람 받는걸 생각해보는것도 좋을것 같은데요. 사용방법은
http://<host>:<port>/nwa/sssadmin접속하여 'AdapterMessageMonitoringVi'를 검색해서 WSDL파일을 사용하면 될것 같습니다.
Adapter Engine으로 들어온 메시지들은 각 인터페이스들은 수신자가 결정이 되고 데이터 유효성 검증을 통해 매핑 전의 인바운드 메시지 처리와 매핑 후의 아웃바운드 메시지처리가 되면서 아래 단계뼐로 시간과 데이터를 확인 가능한데요. 단계별 데이터 확인은 Meesage Store관련 설정을 통해 보고싶은 단계만 확인 가능합니다.
위에서 언급했던 블랙리스트에 대한 내용을 다루기전 Adapter Engine의 메시지 모니터링에서 주로 확인하는 메시지상태인데요. 블랙리스트를 이해하기전에 미리 숙지하면 좋을것 같습니다.
블랙리스트는 사이즈가 큰 메시지나 그 외 PO서버에 부하를 줄수 있는 문제가 되는 메시지를 식별하여 격리하는 기능입니다. 이 기능의 동작은
클러스터 환경, 보통운영환경에서 계속 호출되는 문제되는 메시지로 잉ㄴ해 서버노드에 장애가 발생하면 장애발생된 노드의 메시지들은 다른 노드에 재 할당이 되지만 그 노드 또한 문제되는 메시지로 인해 장애가 발생되는데 결국엔 전체 노드가 장애가 발생되고 다시 시작해도 장애원인이 되는 메시지를 처리하지 않는이상 또 다시 장애가 발생되어 루프에 빠질수 있습니다.
Adapter Engine(Adapter Framework)의 전체적인 흐름을 볼때 아래와 같이 메시지 처리가 되는것 같습니다.
- 소스시스템에서 호출이 되거나 PO의 Sender채널이 폴링
- Module Processor에서의 실행: SOAP, JDBC Sender채널은 기본으로 존재하는 Adapter Module인 CallSapAdapter가 실행이 되면 관련 여러 스레드들이 실행이 되고 이 스레드들이 실행화면은 SAP Management Console에서 AP별로 확인이 가능합니다. 스레드명들은 SAP_AFScheduler.Worker, JDBC_Sender, HTTP Worker, Proxy_Sender 등으로 확인됩니다.
- Module Processor -> Message Queue(Dispatcher queue): 이 과정에서는 CPA Cache 정보들이 업데이트 되며 각 메시지정보들이 DB의 BC_MSG, BC_MSG_AUDIT 테이블에 적재가 되어 메시지의 여러상태와 로그, 데이터들을 확인가능합니다.
- 타겟시스템에 대한 수신자가 설정이 되고 Module Processor의 아래의 스레드를 사용하여 타겟에 전송이 됩니다. MSJDBC_SystemCall, MSSOAP_SystemSend-12333, NSWS_AEE, SystemCall-3454, MSREST SystemSend-3444
위와 같이 간단하게 AdapterEngine내부에 동작흐름을 간단하게 정리해보았고 그중 Module Processor와 Message Queue에 대해 상세하게 정리해보겠습니다.
Module Processor
입력된 채널의 조건에 따라 Adapter가 실행이 되면서 SAP_AFSchedulerWork, JDBC_Sender, HTTP Work, Proxy_SEnder 이런 스레드가 실행이 되는데요. 가끔 Sender채널이 모니터링 로그에서 'Processing started' 이후 실행이 안되고 멈춰보이는 현상이 있는데 이 경우 실제 스레드 상태를 보면 계속 실행중인 상태로 확인이 됩니다. 정상적으로 소스시스템에서 메시지를 수신받고 Adapter Module의 CallSapAdapter, sap.com/com.sap.aii.af.soapadapter/XISOAPAdapterBean 등이실행되고 이 모듈위치에 추가 가능을 넣을수는 있지만 단, CallSapAdapter은 마지막으로 호출이 되어야합니다.Module Process -> Message Queue
이 단계에서는 Adapter Engine과 CPACache 간 PO의 Integration Directory정보들이 업데이트가 되는데요. 캐시에러 발생시 인터페이스가 월활하게 동작이 안될수도 있으며 이 문제를 해결하는 방법중에는 캐시 새로고침 작업이 필요할수도 있습니다.Message Queue(Dispatcher Queue)
싱글스텍(자바)의 SAP PO에서의 ICO시나리오 생성방식은 수신큐는 상뇽되지 않고 메시징의 모든 처리단계는 발신대기열로 실행이 된다고 합니다.대기열 이름들은 Send(Asynchronous outbound), Rcv(Asynchronous Inbound), Call(Synchronous outbound) or Rqst(Synchronous inbound) 이런 큐이름과 함께 어댑터 당 4개로 http://sap.com/xi/XI/System<Queue_Name> 형식으로 생성이 됩니다.
PO에 리소스 부족이나 부하 등으로 어댑터별로 아래의 상태의 백로그가 발생 되는 경우, 디스패쳐 대기열의 메시지 우선순위(Message Prioritiztion) 이나 병렬처리(PI Receiver Parallelism)의 개수제한 기능 등 설정을 통해 백로그에 대한 현상을 사전에 줄일수 있습니다.
*Processing Backlog(Synchronous and Asynchronous Message in Status 'DELIVERING' or 'TO BE DELIVERED')
PO 부하를 발생시키는 원인들로 인해 백로그 상태인 메시지들이 쌓이면서 노드가 다운이 되고 이런문제가 지속되어 다른 노드들까지 영향을 받아 연달아 다운이 되는 경우가 있었는데요.
결국에는 최악의 상황인 경우인 서버가 다운이 되는 상황까지 발생됐던적이 있었는데.. 서버부하를 발생시키는 인터페이스들로 인해 연달아 노드가 다운되는 현상을 방지하기 위해 블랙리스트 기능이 존재한다고 하는데 그때당시에는 왜지 이 기능이 잘 작동을 안했던걸로 기억이 납니다.
Adapter Engine에 들어오는 문제가 되는 메시지들 사전에 알수 없을까? 라는 의문을 갖게 되는데요. 모니터링 화면을 계속 보면 되긴하는데 그외 SAP PI/PO Directory API를 사용한 프로그램을 구현하여 기본적인 PO모니터링외 확장된 기능을 만들어 사전에 모니터링 자동화 및 알람 받는걸 생각해보는것도 좋을것 같은데요. 사용방법은
http://<host>:<port>/nwa/sssadmin접속하여 'AdapterMessageMonitoringVi'를 검색해서 WSDL파일을 사용하면 될것 같습니다.
Adapter Engine으로 들어온 메시지들은 각 인터페이스들은 수신자가 결정이 되고 데이터 유효성 검증을 통해 매핑 전의 인바운드 메시지 처리와 매핑 후의 아웃바운드 메시지처리가 되면서 아래 단계뼐로 시간과 데이터를 확인 가능한데요. 단계별 데이터 확인은 Meesage Store관련 설정을 통해 보고싶은 단계만 확인 가능합니다.
- MS:stage:SI-VIrus 스캔 인바운드
- MS:stage:BI-인바운드 XML유효성 검사 전
- MS:stage:VI-인바운드 XML 유효성 검사 후
- MS:stage:MS-수신기 결정 후
- MS:Messsage_Put_In_Store-데이터베이스에 메시지 유지
- MS:Messsage_Put_In_Disp_Queue-디스패처 큐에 메시지 넣기
- MS:Messsage_Wait_In_Disp_Queue-디스패처 큐의 대기시간
- MS:Messsage_Put_In_Queue-메시지를 처리 큐에 적재
- MS:Messsage_Wait_In_Queue-처리 대기열의 대기시간
- MS:Messsage_Update_Status-메시지 상태를 업데이트하고 새 상태를 DB에 유지
- MS:stage:AM-매핑 실행 후
- MS:stage:SO-Virus 검사 아웃바운드
- MS:stage:VO-아웃바운드 XML유효성 검사 후
- MS:stage:AT-전송 처리블록 끝. 메시징 시스템 처리 및 어댑터로의 핸드오버종료
위에서 언급했던 블랙리스트에 대한 내용을 다루기전 Adapter Engine의 메시지 모니터링에서 주로 확인하는 메시지상태인데요. 블랙리스트를 이해하기전에 미리 숙지하면 좋을것 같습니다.
- Messages in Status 'Not Delivered(NDLV)'
- Messages in Status 'To Be Delivered(TBDL)'
- Messages in Status 'Delivering(DLNG)'
- Messages in Status 'Hold(HOLD)'
- Messages in Status 'Delivered(DLVD)'
- Messages in Status 'Failed(FAIL)'
- Messages in Status 'Waiting(WAIT)'
블랙리스트는 사이즈가 큰 메시지나 그 외 PO서버에 부하를 줄수 있는 문제가 되는 메시지를 식별하여 격리하는 기능입니다. 이 기능의 동작은
클러스터 환경, 보통운영환경에서 계속 호출되는 문제되는 메시지로 잉ㄴ해 서버노드에 장애가 발생하면 장애발생된 노드의 메시지들은 다른 노드에 재 할당이 되지만 그 노드 또한 문제되는 메시지로 인해 장애가 발생되는데 결국엔 전체 노드가 장애가 발생되고 다시 시작해도 장애원인이 되는 메시지를 처리하지 않는이상 또 다시 장애가 발생되어 루프에 빠질수 있습니다.
블랙리스트 기능은 이런 끊임없이 장애가 발생되어 재시작되는 문제를 방지할수 있는데요. 노드가 실패되고 두 번의 시도 후에 문제되는 메시지를 처리할수 없는경우 NDLV상태가 지정이 되며 이상태가 되기까지 지연이 발생될수 있다고 합니다. 그리고 해당 메시지의 DLNG상태인 것들은 자동으로 NDLV상태로 지정이 되어 재시작 루프를 방지할수 있다고 합니다.
이렇게 블랙리스트에 격리된 메시지들은 사용자가 메시지처리할지 상태를 FAIL로 지정할지 결정할수 있다고 하며
이렇게 블랙리스트에 격리된 메시지들은 사용자가 메시지처리할지 상태를 FAIL로 지정할지 결정할수 있다고 하며
격리된 메시지확인은 Message Monitor > Technical Attributes에 Blacklisted를 체크 후 조회하면 볼수 있습니다.
전에 계속 호출되는 대용량메시지로 인해 블랙리스트에 격리된 메시지를 확인할수 있었는데 그때는 아무처리를 안했는데 시간이 지나니 사라졌던것 같은데 저도 블랙리스트기능이 동작하는것을 제대로 본적이 없었는데 앞으로도 볼일이 없어야 하는 기능이겠죠?
간단하게 블랙리스트 처리 흐름을 정리하자면
정상처리되는 메시지들은 TBDL -> DLNG -> 성공이면 DLVD, 실패하면 FAIL로 처리가 되는데요.
격리가 되는 메시지들은 DLNG 상태에서 'Node Failure - Restart - Failover' 처리가 되며 NDLV상태가 지정되는것 같습니다.
지금까지 SAP PO의 Adapter Engine에 대해 정리를 해봤는데요. 부족한 부분있으시면 언제든지 댓글도움 부탁드리겠습니다.😀
출처:
Tuning the PI/PO Messsaging System Queues
Advenced Adapter Engine > Blacklisting
Module Processor
전에 계속 호출되는 대용량메시지로 인해 블랙리스트에 격리된 메시지를 확인할수 있었는데 그때는 아무처리를 안했는데 시간이 지나니 사라졌던것 같은데 저도 블랙리스트기능이 동작하는것을 제대로 본적이 없었는데 앞으로도 볼일이 없어야 하는 기능이겠죠?
간단하게 블랙리스트 처리 흐름을 정리하자면
정상처리되는 메시지들은 TBDL -> DLNG -> 성공이면 DLVD, 실패하면 FAIL로 처리가 되는데요.
격리가 되는 메시지들은 DLNG 상태에서 'Node Failure - Restart - Failover' 처리가 되며 NDLV상태가 지정되는것 같습니다.
지금까지 SAP PO의 Adapter Engine에 대해 정리를 해봤는데요. 부족한 부분있으시면 언제든지 댓글도움 부탁드리겠습니다.😀
출처:
Tuning the PI/PO Messsaging System Queues
Advenced Adapter Engine > Blacklisting
Module Processor
댓글 없음:
댓글 쓰기