SAF 거래 아키텍처
SAF 거래는 두 가지 주요 처리 과정으로 구성된다. 송신 시스템에서 메시지를 받아 SAF 큐에 저장하는 저장 처리와, SAF 큐에 저장된 메시지를 수신 시스템으로 전송하는 전송 처리이다.
아래는 SAF 거래 처리의 기본 아키텍처이다.

1. 거래 메시지 저장
송신 시스템이 EAI에 메시지를 전송하면, EAI는 이를 분석하여 SAF 거래인지 확인한다. SAF 거래일 경우, 인터페이스의 SAF 정보를 이용하여 메시지를 SAF 큐에 저장한다. SAF 큐에 연결할 수 없을 때는 송신 시스템에 오류를 응답하고, 그렇지 않으면 비동기 방식으로 큐에 저장하여 정상 응답한다.

-
송신 시스템에서 요청한 메시지를 Queue Producer에 전달한다.
-
Queue Producer는 수신 받은 메시지를 SAF 큐에 비동기 방식으로 저장한다. (저장하는 SAF 큐의 파티션 수만큼 동시 처리 가능)
-
Queue Producer는 SAF 큐에 저장 오류시 내부 큐에 저장하여 재처리한다. 비동기 방식으로 SAF 큐에 저장하므로 비동기 호출 전 에러이면 송신시스템에 거래 처리 오류로 응답하고, SAF 큐에 저장하는 도중 에러가 발생하면 재처리를 위해 내부 큐에 저장한다.
-
Send Error Producer는 내부 큐에 저장된 메시지를 SAF 큐에 저장한다.
-
Send Error Producer는 SAF 큐에 저장 시 오류가 발생하면 메시지 재처리를 위해 내부 큐에 저장하고, 일정 시간 대기 후 재시도하며, 3회 이상 오류 발생 시 에러 로그 후 메시지를 스킵한다.
2. 거래 메시지 전송
EAI는 SAF 큐의 메시지를 하나씩 읽어 수신 시스템에 전송한다. 수신 시스템은 동기 방식으로 호출되며, 메시지 전송 시 오류가 발생하면 내부 큐에 저장하여 재처리한다. 만약에 지정된 횟수 이상으로 에러가 발생하면 해당 메시지는 처리할 수 없으므로 스킵한다.
재처리 구조는 내부 큐에 저장된 SAF 메시지를 별도의 SAF 에러 큐에 저장하여 처리한다. 별도의 SAF 에러 큐를 이용하여 재처리하는 이유는 재처리로 인하여 정상적으로 처리하는 메시지가 영향을 받지 않도록 하기 위함이다. 단, 재처리를 하는 프로세스는 하나의 스레드로 처리한다. SAF 에러 큐명은 SAF 큐 정보의 등록한 큐명에 _error를 추가하여 에러 큐명으로 사용한다.
수신시스템에서 에러로 응답하는 경우엔 EAI에서 에러여부를 판단할 수 없으므로 정상 응답으로 간주한다. |

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

-
Process Consumer나 Process Error Consumer는 메시지 전송 처리 오류시 처리 횟수를 증가하여 내부 큐에 저장한다.
-
Process Error Consumer는 SAF 에러 큐에서 저장된 메시지를 읽어온다.
-
Process Error Consumer는 메시지 전송 전 처리 횟수를 검증하여 재처리 횟수를 초과한 경우 에러 처리하고 해당 메시지는 스킵한다. 재처리 횟수는 시스템 파라미터(SAF_MAX_ERROR_COUNT)에 등록하거나, 등록하지 않으면 기본적으로 3회 재처리 한다. 단, 3회 이상 SAF 에러 큐 저장 오류 발생시 해당 메시지는 에러 로깅 후 스킵한다.
-
즉시 재처리하지 않고 에러 횟수에 따라서 일정시간 동안 대기 후 재처리 한다. 대기시간은 에러횟수가 증가하면 더 많이 대기하는 구조로, 시스템 파라미터(SAF_RETRY_UNIT_SLEEP_TIME)에 에러 횟수당 대기시간을 등록하며, 기본적으로 5초 대기한다.
-
단, 수신시스템이 장애인 경우에는 수신시스템 장애에 따른 대기시간이 우선 적용된다. 수신시스템 장애시 처리 방안은 하단에 수신시스템 장애처리를 참조한다.
4. 수신시스템 장애처리
수신 시스템 장애로 SAF 메시지를 전송하지 못할 경우, EAI는 이를 인지하고 일정 시간 대기 후 재처리한다.
수신시스템 장애 판단 케이스
|
수신시스템 호출 시 장애가 발생하면 시스템 업무 단위로 에러 횟수를 증가시키고, 정상적으로 처리하면 에러 횟수를 감소시키는 방식으로 관리한다. 에러 횟수가 지정된 횟수를 초과하면 시스템 파라미터 SAF_SYSTEM_UNIT_SLEEP_TIME 값에 따라 대기한다. 기본 대기시간은 30초이며, 최대 10분을 넘지 않는다.

5. 거래 처리를 위한 인스턴스 구성 방안
6. SAF 큐와 인터페이스의 관계
인터페이스 정보를 등록할 때 해당 거래가 SAF 거래임을 명시하고, 메시지를 어느 SAF 큐에 저장할지에 대한 정보도 함께 등록해야 한다. 사용자는 인터페이스 별로 각각 다른 큐에 메시지를 저장할 수 있으며, 여러 개의 인터페이스를 하나의 큐에 저장할 수도 있다.
인터페이스 별로 각각의 큐에 메시지를 저장할 경우, 특정 메시지 처리 시 발생하는 장애나 처리 속도 지연이 다른 메시지에 영향을 미치지 않는다. 반면 여러 인터페이스를 하나의 큐에 저장할 경우, 처리 속도가 늦은 메시지로 인해 다른 메시지의 처리가 지연될 수 있다. 그러나 너무 많은 큐를 사용하면 큐 관리가 어려워질 수 있으므로, 처리해야 하는 거래량에 따라 큐의 갯수를 적절히 조정해야 한다.
