WebSphere Enterprise Service Bus, 버전 6.2.0 운영 체제: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


유스 케이스: 실패 이벤트 복구 데이터

유스 케이스는 복구 시나리오의 컨텍스트를 제공합니다. 유스 케이스에 요청을 수신하여 계정을 새로 작성하는 비즈니스 응용프로그램이 있습니다.

솔루션은 모듈 우수 사례를 통해 추천된 여러 모듈로 구성됩니다.

첫째 모듈은 요청을 중개하고 작업을 계정 작성 프로세스에 위임합니다. 아래의 예는 중개 모듈(AccountRouting)과 프로세스 모듈(AccountCreation)간의 요청이 SCA 가져오기/내보내기를 통해 전달된 독립 모듈로 솔루션을 구현한 것입니다. 두 모듈의 그림은 다음 화면 캡처를 참조하십시오.

그림 1. 계정 라우팅 프로세스 어셈블리 다이어그램
중개 모듈(AccountRouting)과 프로세스 모듈(AccountCreation)간의 요청이
SCA 가져오기에서 SCA 내보내기로 전달됩니다.

그림 1의 어셈블리 다이어그램에서 플로우의 어느 위치에서 장애가 발생했을지 찾아 볼 수 있습니다. 어셈블리 다이어그램의 어느 호출 지점에서도 트랜잭션을 전달하거나 포함할 수 있습니다. 응용프로그램 또는 시스템 장애로 인해 데이터가 수집할 플로우에 몇 개의 영역이 있습니다.

트랜잭션 경계는 컴포넌트와 가져오기/내보내기 바인딩과 관련 규정자 사이의 상호작용(동기 및 비동기)에 의해 작성 및 관리되는 것이 일반적입니다. 비즈니스 데이터는 대부분 트랜잭션 장애, 교착 상태 또는 롤백으로 인해 특정 복구 지점에 수집됩니다.

WebSphere® Application Server의 트랜잭션 기능은 WebSphere ESB가 트랜잭션을 서비스 프로바이더와 연결시킵니다. 이렇게 연결된 상호작용에 대해서는 가져오기 및 내보내기 바인딩과 관련하여 특히 잘 알고 있어야 합니다. 특정 비즈니스 케이스의 가져오기 및 내보내기 사용 방법을 숙지하는 것이 복구가 필요한 이벤트가 모이는 위치 판별에 중요합니다.

응용프로그램 개발 전에 오류 처리 계획에서 상호작용 패턴, 사용된 트랜잭션, 가져오기 및 내보내기 사용법을 정의해야 합니다. 솔루션 설계자는 사용할 환경 설정 및 지침을 확인해야 하며 이것은 응용프로그램 작성시 사용됩니다. 예를 들어, 설계자는 언제 동기 호출 대 비동기 호출을 사용할지, 언제 BPEL 결함 처리를 사용할지 등을 알아야 합니다. 설계자는 모든 서비스가 트랜잭션에 참여할 수 있는지 여부, 그리고 참여할 수 없는 서비스의 경우 문제점 발생시 보정 처리 방법을 알아야 합니다.

또한 그림 1의 어셈블리 다이어그램에 표시된 응용프로그램은 연결 그룹 및 모듈 개발 우수 사례를 활용합니다. 이 패턴을 활용하면 AccountRouting 모듈을 중지하여 새 이벤트의 인바운드 플로우를 중지할 수 있습니다.

장애 및 복구 케이스의 비즈니스 데이터 위치는 다음 섹션을 참조하십시오.

비즈니스 플로우 관리자 또는 휴먼 타스크 관리자

이 비즈니스 케이스는 AccountCreation 프로세스의 BPEL 프로세스를 활용합니다.

복구와 관련하여 BPEL 및 휴먼 타스크 관리에 대한 다음과 같은 사항을 알아야 합니다.
  1. 실행 중인 프로세스 유형(단기 실행 중 또는 장기 실행 중, 비즈니스 상태 머신, 휴먼 타스크)

    단기 실행 중인 프로세스는 마이크로 플로우라고 합니다.

  2. 프로세스가 제대로 개발되었는지 그리고 데이터 무결성을 높이기 위해 결함 처리를 사용하고 있는지 여부
  3. 트랜잭션 경계를 예측하고 제어할 수 있도록 호출 패턴 및 작업 특성 단위를 구성한 방법

위의 사항의 숙지 여부가 아래의 화면 캡처에서 강조표시된 어셈블리 다이어그램의 7 및 8 호출의 복구 전략에 큰 영향을 미칩니다.

그림 2. 계정 라우팅 어셈블리 다이어그램 - 7 호출 및 8 호출
화면 캡처에 7 호출 및 8 호출이 강조표시된 어셈블리 다이어그램이 표시됩니다.

장기 실행 중인 BPEL 프로세스 및 비즈니스 상태 머신과 같은 Stateful 컴포넌트는 프로세스 활동 변경 및 상태 변경이 데이터베이스에 확약된 여러 데이터베이스 트랜잭션이 필요합니다. 데이터베이스를 갱신하고 다음에 수행될 작업을 설명하는 메시지를 내부 큐에 저장하여 작업이 진행됩니다.

비즈니스 플로우 관리자 내부의 메시지 처리에 문제점이 발생하면 이 메시지는 유지 큐로 이동됩니다. 시스템이 메시지 처리를 계속 시도합니다. 다음 메시지가 성공적으로 처리되면 유지 큐의 메시지가 다시 제출되어 처리됩니다. 같은 메시지가 유지 큐에 다섯 번 들어오면 그 메시지는 보류 큐로 보내집니다.

메시지 수 표시 및 메시지 재생에 대한 정보는 유지 큐/보류 큐의 메시지 재생을 참조하십시오.

실패 이벤트 관리자

실패 이벤트 관리자(FEM)는 대부분의 컴포넌트 유형 간 비동기적으로 작성된 이벤트 또는 서비스 호출 요청을 재생하는데 사용됩니다.

AccountRouting 컴포넌트가 SCA 가져오기 바인딩 AccountCreationSCAImport에 비동기 호출을 해서 ServiceRuntimeException이 리턴되면 실패 이벤트가 작성됩니다.

BPEL이 서비스 상호작용의 클라이언트인 케이스에서는 대부분 실패 이벤트가 생성되지 않는 점을 참고하십시오. 이것은 그림 2에 표시된 7 및 8 호출이 일반적으로 실패 이벤트가 되지 않음을 의미합니다. BPEL은 결함 핸들러 및 장애 모델을 만드는 기타 방법을 제공합니다. 이러한 이유로 "JDBCOutboundInterface"를 호출하는 SRE(ServiceRuntimeException)가 있으면 해당 SRE가 처리를 위해 BPEL로 리턴됩니다. 프로젝트의 오류 처리 전략에서 BPEL로 런타임 예외를 지속적으로 처리할 수 있는 방법을 정의해야 합니다.

그러나 BPEL 클라이언트에 대한 비동기 응답 메시지가 하부 구조 장애로 인해 프로세스 인스턴스로 전달될 수 없는 경우 이 메시지의 실패 이벤트가 작성된다는 점에 유의하십시오.

다음 다이어그램은 실패 이벤트 관리자 컴포넌트의 작동 방법을 나타냅니다. 다이어그램 다음에 각 번호의 단계와 연관된 처리에 대한 설명이 있습니다.

그림 3. 실패 이벤트 관리자 처리
실패 이벤트 관리자 처리
다이어그램. 다이어그램은 번호가 매겨져 있으며 다이어그램 다음에
번호가 매겨진 단계 목록이 있습니다.
실패 이벤트 관리자 처리
  1. 소스 컴포넌트는 비동기 호출 패턴을 사용하여 호출을 합니다.
  2. SCA MDB가 SCA 대상에서 메시지를 선택합니다.
  3. SCA MDB가 올바른 대상 컴포넌트를 호출합니다.
  4. 대상 컴포넌트가 ServiceRuntimeException을 처리합니다.
  5. SCA MDB 트랜잭션이 SCA 대상으로 롤백합니다.
  6. 예외 정보가 미확인 상태로 실패 이벤트 관리자 데이터베이스에 저장됩니다.
  7. 호출이 SIBus에 의해 n회 재시도됩니다.

    재시도 한도 기본값은 맨 처음의 시도와 네 번의 재시도를 포함해 총 5회입니다. 관리 콘솔에서 기본값을 변경할 수 있습니다. 예를 들어, SCA M 모듈의 경우 버스 > SCA.SYSTEM.<CELL>.BUS > 대상 > sca/M 으로 탐색하여 실패한 최대 전달 수 필드의 값을 변경합니다.

  8. 재시도 횟수가 지정 한계에 도달하면 메시지가 FEM 대상으로 이동됩니다.
  9. 실패 이벤트 관리 데이터베이스가 메시지를 선택합니다.
  10. 실패 이벤트 관리자 데이터베이스가 데이터베이스에 실패 이벤트를 갱신하면 상태가 실패로 설정됩니다.

"실패 이벤트" 작성 시간

설명한 대로 실패 이벤트는 동기 호출에도 작성되지 않고 양방향 비즈니스 프로세스 상호작용에도 일반적으로 작성되지 않습니다.

실패 이벤트는 클라이언트가 비동기 호출 패턴을 사용하고 ServiceRuntimeException이 서비스 프로바이더에 의해 처리되는 경우 대부분 작성됩니다.

모든 것이 동기적으로 같은 트랜잭션에서 이루어지면 데이터를 수집할 수 없습니다. 그 대신 호출 한 클라이언트로 모두 롤백됩니다. 데이터는 확약이 발생한 곳에 수집됩니다. 호출이 모두 동기이나 확약이 여러 개인 경우 이 확약이 문제가 됩니다.

다중 트랜잭션이 필요한 경우 비동기 처리 호출이나 장기 실행 중 BPEL을 사용하는 것이 일반적입니다. 따라서 각 ASYNC 호출시 데이터를 모을 수 있습니다. 장기 실행 중 BPEL 프로세스가 콜렉션 위치입니다.

표 1. 호출 패턴 및 실패 이벤트 작성 관계: 서비스 비즈니스 예외
호출 패턴 실패 이벤트 작성 여부(예/아니오) 참고
동기 아니오 서비스 비즈니스 예외에 또는 동기 패턴을 사용할 때 실패 이벤트가 작성되지 않습니다.
비동기 - 단방향 아니오 정의에 따르면 단방향 호출은 결함, 의미를 선언할 수 없으며 ServiceBusinessException을 처리할 수 없습니다.
비동기 - 지연 응답 아니오 실패 이벤트가 서비스 비즈니스 예외에 작성되지 않습니다.
비동기 - 콜백 아니오 실패 이벤트가 서비스 비즈니스 예외에 작성되지 않습니다.
표 2. 호출 패턴 및 실패 이벤트 작성 관계: 서비스 런타임 예외
호출 패턴 실패 이벤트 작성 여부(예/아니오) 참고
동기 아니오 서비스 런타임 예외에 또는 동기 패턴을 사용할 때 실패 이벤트가 작성되지 않습니다.
비동기 - 단방향  
비동기 - 지연 응답  
비동기 - 콜백  
BPEL - 양방향 아니오
소스 컴포넌트가 비즈니스 프로세스인 경우 실패 이벤트가 작성되지 않습니다.
주: 비동기 호출은 응답이 BPEL로 리턴될 수 없으면 실패 이벤트가 작성됩니다.
BPEL - 단방향  
추가 정보는 Information Center의 실패 이벤트 관리라는 제목의 주제를 참조하십시오.

실패 이벤트 보기 및 다시 제출에 대한 정보는 실패 이벤트 다시 제출 섹션을 참조하십시오.

서비스 통합 버스 대상

처리 대기 중인 메시지는 몇 개의 SIBus(Service Integration Bus) 대상에 모일 수 있습니다. 이 대상의 대부분은 "시스템" 대상입니다. 이 대상에 모인 메시지는 일반적으로 다음의 세 가지 유형이 혼합되어 있습니다.
  • 비동기 처리 요청
  • 비동기 요청 응답
  • 직렬화 해제 또는 함수 선택기 해상도에 실패한 비동기 메시지
    주: 비동기 응답은 유효한 비즈니스 오브젝트이거나 요청의 결과로 리턴된 결함이 될 수 있습니다.

SCA 모듈 대상

이 비즈니스 케이스를 다시 참조하십시오.

솔루션에 다음과 같은 두 개의 "SCA 모듈" 대상이 있을 것입니다.
  • sca/AccountRouting
  • sca/AccountCreation

이 대상은 모듈이 Application Server나 클러스터로 전개될 때 작성됩니다.

이 대상에는 메시지가 거의 모이지 않습니다. 이 위치에 메시지가 모이면 성능에 문제점이 있거나 응용프로그램에 결함이 있을 가능성이 높다는 것을 의미합니다. 즉시 검사를 하십시오. 메시지 백업으로 인해 시스템이 정지되거나 재순환 시간이 길어질 수 있으므로 선택한 모니터링 솔루션으로 모듈 대상의 깊이를 모니터하는 것이 중요합니다.

생성된 이름이 "sca/"가 추가된 모듈 이름과 같으므로 이 "SCA 모듈" 대상을 호출합니다. 이 대상이 SCA 비동기 호출 기능(요청 및 응답 브로커)의 중추입니다. SCA.SYSTEM 버스에 응용프로그램을 설치하는 중에 생성된 추가 대상이 많이 있으나 여기에서는 "SCA 모듈" 대상의 중요성에 대해 설명할 것입니다.

시스템 통합 버스 재시도

위에서 설명한대로 FEM에는 SCA 메시지 구동 Bean(MDB)이 포함된 재시도 매커니즘이 내장되어 있습니다. 이 재시도 동작은 모듈 대상의 "실패한 최대 전달 수" 속성을 수정하여 제어할 수 있습니다.
주: 일반적으로 이 재시도 기능을 조정할 필요는 없습니다. 여기에 제공된 것으로 충분히 기능할 수 있습니다.

이 비즈니스 케이스의 경우 SCA에 의해 비동기 통신을 지원하도록 작성된 SI Bus 대상이 많이 있습니다.

위에서 설명한 바와 같이 이 대상 중 하나를 "sca/AccountRouting"이라고 합니다. ServiceRuntimeException의 비동기 서비스 호출 중에 발생하는 재시도 횟수를 관리 콘솔을 통해 "실패한 최대 전달 수" 특성 값을 변경하여 조정할 수 있습니다. 그러나 BPEL 프로세스가 포함된 모듈에 값을 2 미만으로 설정할 수 없습니다. 두 번째 전달은 ServiceRuntimeExceptions를 다시 BPEL로 리턴하여 처리하도록 요청됩니다.

시스템 예외 대상

실패 이벤트 관리자는 장애 관리가 표시되는 곳입니다. JMS 또는 EIS 기반의 가져오기 및 내보내기를 처리할 때 다른 중요한 위치를 고려해야 합니다.

SCA.Application 버스의 대상은 실패 메시지를 해당 버스의 SIB 시스템 예외 대상으로 라우트하도록 구성됩니다. 따라서 JMS 내보내기가 SCA 응용프로그램 버스에서 메시지를 선택해서 롤백 상태로 실행하면 실패 메시지가 WBI 복구 예외 대상이 아닌 SIB 시스템 예외 대상으로 라우트됩니다. 이 시나리오는 위에서 설명한 SCA.Application 버스의 메시지 직렬화 해제 장애가 실패 이벤트가 되지 않는 경우의 실패 이벤트와는 다릅니다. 솔루션의 모든 버스에 시스템 예외 대상이 있습니다. 이 대상을 MQ 하부 구조에 공통인 "데드 레터 큐"처럼 모니터 및 관리해야 합니다.

다음 시나리오를 고려하십시오.

시스템 예외 처리 방법을 표시하는 다이어그램
외부 JMS 클라이언트가 메시지를 JMS 내보내기를 통해 인바운드 큐에 저장합니다. JMS 내보내기 바인딩 MDB가 처리할 메시지를 선택합니다. 여기에서 다음 중 하나가 발생합니다.
  1. JMS 내보내기가 메시지 구문 분석을 완료하여 호출할 인터페이스의 조작과 처리할 메시지를 SCA 런타임으로 전달할 지점을 판별합니다.
  2. JMS 내보내기가 메시지 본문을 유효한 비즈니스 오브젝트로 인식하지 못하거나 JMS 내보내기 바인딩이 메시지 본문을 직렬화 해제하지만 호출할 인터페이스의 해당 조작을 판별하지 못합니다. 이 지점에서 메시지를 버스의 시스템 예외 대상에 저장합니다.

이런 유형의 장애는 AccountRoutingJMSExport(1)의 요청을 받을 때 발생합니다. 이 내보내기는 JMS 내보내기이며 이벤트가 SCA.Application.Bus의 시스템 예외 대상에 모일 수 있습니다. 선택한 IT 모니터링 솔루션을 사용하여 이 대상의 깊이를 관찰하십시오.

실패 이벤트 관리자 및 SIB 대상

WebSphere ESB의 경우 예외 대상이 WebSphere ESB 예외 대상 큐에 설정됩니다. 이 큐는 다음과 같은 이름 지정 규칙을 따릅니다.
Node name: WESBNode
Server name: server1
Recovery exception destination: WBI.FailedEvent.WESBNode.server1
일반적으로 SCA.System 버스에 작성된 모든 대상은 실패 메시지를 복구 예외 대상에 라우트하도록 구성됩니다.

시스템 장애가 발생하면 이 예외 대상에 실패 메시지를 저장함과 더불어 이 문서의 실패 이벤트 관리자 섹션에 설명된 바와 같이 WebSphere ESB 복구 기능도 시스템 오류를 표시하는 실패 이벤트를 생성하고 복구 데이터베이스에 저장합니다.

요약

간단히 말해 WebSphere ESB는 기본 WebSphere Application Server 플랫폼 이상의 관리 기능을 제공합니다. 오류 방지 및 복구 계획의 오류 방지 계획 섹션에 설명된 다음의 지침과 더불어 이 기능을 올바르게 이해하고 사용할 수 있는 방법이 마련되어야 합니다.

표 3. 장애 관리를 위한 관리 기능
관리 기능 WebSphere ESB 포함 번들화 Y/N? 요약
실패 이벤트 관리자 읽기/편집/삭제 액세스. 이것은 서비스 런타임 예외 및 기타 형태의 하부 구조 장애 중앙 관리소입니다.

서비스 통합 버스 브라우저

읽기/삭제하기. 관리 콘솔의 서비스 통합 버스 브라우저를 사용하여 서비스 통합 버스의 일일 조작 타스크를 찾아보고 수행합니다.

주: 이 도구를 사용하여 동시에 관리할 수 있는 이벤트 및 레코드 수는 메모리 할당, 결과 설정 및 DB 성능 조정, 연결 제한시간과 같은 외부 요소에 따라 결정됩니다. 예외(OOM, TransactionTimeOut)가 발생하지 않도록 테스트를 실행하고 해당 임계값을 설정하십시오.

concept 개념 주제

이용약관 | 피드백


시간소인 아이콘 마지막 갱신 날짜: 2010년 7월 7일 수요일


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/crec_use_case_recovery.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
이 Information Center는 Eclipse 기술을 기반으로 합니다(http://www.eclipse.org 웹 사이트 참조).