SAF거래 아키텍처

SAF거래는 송신시스템으로부터 메시지를 받아 SAF큐에 저장하는 저장처리와 SAF큐에 저장된 메시지를 받아 수신시스템에 전송하는 두 가지 부분으로 나누어져 있다.

아래는 SAF 거래 처리에 대한 기본적인 아키텍처이다.

거래 메시지 저장

송신시스템이 온라인 거래와 동일한 방식으로 EAI에 메시지를 전송하면, EAI는 해당 메시지를 분석해 SAF 거래이면 인터페이스의 SAF 정보를 이용하여 큐에 저장한다.

SAF큐에 저장시 큐에 연결이 안되는 경우 송신시스템에 에러를 응답하고, 그렇지 않으면 비동기 방식으로 큐에 저장해 송신시스템에 정상을 응답한다.

1. 송신시스템에서 요청한 메시지를 Queue Producer에 전달한다.
2. Queue Producer는 수신 받은 메시지를 SAF큐에 비동기 방식으로 저장한다. (저장하는 SAF 큐의 파티션 수만큼 동시 처리 가능)
3. Queue Producer는 SAF큐에 저장 오류시 내부 큐에 저장하여 재처리한다. 비동기 방식으로 SAF 큐에 저장하므로 비동기 호출 전 에러이면 송신시스템에 거래 처리 오류로 응답하고, SAF큐에 저장하는 도중 에러가 발생하면 재처리를 위해 내부 큐에 저장한다.
4. Send Error Producer는 내부 큐에 저장된 메시지를 SAF큐에 저장한다.
5. Send Error Producer는 SAF큐에 저장 시 오류가 발생하면 메시지 재처리를 위해 내부 큐에 저장하고, 일정 시간 동안 대기했다가 재시도한다. 단, 3회 이상 저장 오류시 해당 메시지는 에러 로깅 후 스킵한다.

거래 메시지 전송

SAF큐의 메시지를 하나씩 읽어 메시지 전송 프로세스를 통하여 수신시스템를 호출한다.

수신시스템은 동기 방식으로 호출하고, 메시지 전송 시점에 오류가 발생하면 내부 큐에 저장하여 재처리하면서 오류 횟수를 관리한다.

만약에 지정된 횟수 이상으로 에러가 발생하면 해당 메시지는 처리할 수 없으므로 스킵한다.

재처리 방식은 내부 큐에 저장되어 있는 SAF 메시지를 별도의 SAF 에러 큐에 저장하여 처리하는 구조이다.

별도의 SAF 에러큐를 이용하여 재처리하는 이유는 재처리로 인하여 정상적으로 처리하는 메시지가 영향을 받지 않도록 하기 위함이다. 단, 재처리를 하는 프로세스는 하나의 스레드로 처리한다.

SAF 에러 큐명은 아래에서 설명하는 SAF 큐 정보의 등록한 큐명에 _error를 추가하여 에러 큐명으로 사용한다.

정보

수신시스템에서 에러로 응답하는 경우엔 EAI에서 에러여부를 판단할 수 없으므로 정상 응답으로 간주한다.

1. Process Consumer는 SAF 큐에서 메시지를 받아 전송 프로세스를 호출한다. 동시 처리를 위해 SAF 큐의 파티션 수만큼 멀티 스레드로 구성되어 있다.
2. 메시지 전송 프로세스는 메시지를 한번에 하나씩 동기 방식으로 수신시스템에 호출한다.
3. 메시지 전송 오류시 처리 횟수를 1증가하여 내부 큐에 저장하여 재처리 한다. 수신시스템에서 메시지를 정상적으로 처리하면 다음 메시지를 처리하고, 그렇지 않으면 처리 횟수를 1 증가시킨 후 내부 큐에 저장하여 재처리 한다.
4. Process Error Producer는 내부 큐에 저장된 메시지를 SAF 에러 큐에 저장한다.
5. Process Error Producer는 SAF 에러 큐에 저장이 안되면 메시지 재전송을 위해 내부 큐에 저장하고, 일정 시간 동안 대기했다가 재시도한다.
6. Process Error Consumer는 SAF 에러 큐에서 메시지를 받아 메시지 전송 프로세스를 호출하여 재처리한다. 단, Process Error Consumer는 순차처리를 위해 하나의 스레드로 구성되어 있다.
7. 지정된 처리 오류 횟수를 초과한 경우 해당 메시지는 처리할 수 없으므로 스킵한다.

거래 재처리

EAI는 수신시스템에 메시지 전송시 오류가 발생하면 지정된 횟수만큼 재처리한다.

1. Process Consumer나 Process Error Consumer는 메시지 전송 처리 오류시 처리 횟수를 증가하여 내부 큐에 저장한다.
2. Process Error Consumer는 SAF 큐에서 메시지를 받아 메시지 전송 전 처리 횟수를 검증하여 재처리 횟수를 초과한 경우 에러 처리하고 해당 메시지는 스킵한다. 재처리 횟수는 시스템 파라미터(SAF_MAX_ERROR_COUNT)에 등록하거나, 등록하지 않으면 기본적으로 3회 재처리 한다. 단, 3회 이상 SAF 에러 큐 저장 오류 발생시 해당 메시지는 에러 로깅 후 스킵한다.
3. 즉시 재처리하지 않고 에러 횟수에 따라서 일정시간 동안 대기 후 재처리 한다. 대기시간은 에러횟수가 증가하면 더 많이 대기하는 구조로, 시스템 파라미터(SAF_RETRY_UNIT_SLEEP_TIME)에 에러 횟수당 대기시간을 등록하며, 기본적으로 5초 대기한다.
4. 단, 수신시스템이 장애인 경우에는 수신시스템 장애에 따른 대기시간이 우선 적용된다. 수신시스템 장애시 처리 방안은 하단의 수신시스템 장애처리를 참조한다.

수신시스템 장애처리

수신시스템 장애로 인하여 SAF메시지를 전송하지 못한 경우, EAI는 수신시스템을 장애로 인지하여 일정시간 동안 대기 후 처리한다.

수신시스템 에러 판단 케이스

• 수신시스템 호출시 에러발생
• 연결 불가
• 타임아웃 발생
• HTTP 상태코드가 2xx가 아닌 경우

장애는 수신시스템 호출 시 에러가 발생하면 시스템 업무 단위로 에러 횟수를 증가하고, 정상적으로 처리하면 에러 횟수를 감소하는 방식으로 관리한다.

만약 에러 횟수가 지정된 횟수(3회)를 초과한 경우 초과한 횟수당 시스템 파라미터(SAF_SYSTEM_UNIT_SLEEP_TIME)에 등록된 시간동안 대기하는데, 기본적으로 횟수당 30초 대기한다.

그러나 대기시간은 최대 10분을 넘지 않는다.

거래 처리를 위한 인스턴스 구성 방안

SAF 거래 처리 인스턴스는 거래량에 따라서 두가지 방식으로 구성할 수 있다.

☑ 하나의 인스턴스로 구성

거래가 적은 경우, 하나의 온라인 인스턴스에서 SAF 거래 저장과 전송을 같이 처리한다.

1. 노드관리 > 인스턴스정보에서 온라인 인스턴스를 등록한다.
2. 인터페이스관리 > 온라인인터페이스에서 SAF큐 팝업을 통해 SAF큐 정보를 등록한다. SAF 큐 정보 등록시 인스턴스ID에 1에서 등록한 인스턴스를 등록하거나 아무것도 등록하지 않으면, 기본적으로 1의 인스턴스에서 해당 SAF큐에 대한 저장과 전송을 처리한다.

☑ 저장과 전송을 분리하여 구성

거래량이 많은 경우, 저장 인스턴스와 전송 인스턴스를 분리하여 구성한다.

1. 노드관리 > 인스턴스정보에서 온라인 인스턴스를 등록한다.

2. 인터페이스관리 > 온라인인터페이스에서 SAF큐 팝업을 통해 SAF큐 정보를 등록한다. 이 때, 인스턴스ID에 반드시 1의 전송 인스턴스를 등록한다.

SAF큐와 인터페이스의 관계

요청한 SAF거래를 처리하는 저장 인스턴스는, SAF 거래 종류별로 각각 온라인 인터페이스 정보를 등록해야 한다.

인터페이스 정보 등록시 해당 거래가 SAF거래이고, 메시지 저장을 어느 SAF 큐에 저장할 것인지에 대한 정보도 함께 등록한다. 사용자는 인터페이스 별로 각각 다른 큐에 저장할 수도 있고, 아니면 인터페이스 여러 개를 하나의 큐에 저장할 수도 있다.

인터페이스별로 각각의 큐에 저장하거나, 여러 개의 인터페이스를 하나의 큐에 저장하는지에 따라서 SAF 거래 메시지를 수신시스템에 전송할 때 영향이 있을 수 있다.

인터페이스 별로 각각의 큐에 저장한다면 해당 메시지 처리시 장애가 발생하거나 처리 속도가 늦은 메시지에 영향이 없지만, 여러 개의 인터페이스를 하나의 큐에 저장하는 경우엔 처리 속도가 늦은 메시지로 인하여 다른 메시지 처리가 늦어질 수도 있다.

그러나 너무 많은 큐를 사용한다면 큐 관리에도 어려움이 있을 수 있으므로 처리해야 하는 거래량에 따라 큐의 갯수를 조정해야 한다.