소개

본 장에서는 RQ(Reliable Queue)의 정의 및 RQ 시스템 구성에 대해서 설명한다.

1. 개요

클라이언트의 서비스 요구가 집중되어 요구된 서비스를 즉시 처리하지 못하고 내부 큐에 적재된 상태에서 시스템의 장애나 에러로 인하여 시스템이 비정상적으로 종료되는 경우 모든 서비스 데이터는 삭제된다. 이러한 경우 신뢰성이 보장되어야 하는 서비스는 정상적인 업무가 이루어질 수 없다. 이러한 문제점을 보완하기 위하여 Tmax 시스템은 대외기관과의 연동 업무같이 신뢰성이 보장되어야 하며 업무의 특성상 거래 시간이 일반적인 온라인성 업무와 달리 많은 시간이 소요되는 서비스를 처리하기 위해 RQ(Reliable Queue)를 제공한다.

RQ는 안정적인 서비스를 보장하기 위해 클라이언트의 요청을 디스크에 관리하고 일반적인 메시지 큐로서 클라이언트 간 혹은 서버 간 Peer-to-peer 통신을 위해 사용된다.

그러나 RQ를 사용하면 신뢰성은 보장되지만 디스크에 데이터를 기록하기 때문에 그 만큼의 속도가 저하될 수 있다. 따라서 신뢰성이 보장되어야 하고 시간이 많이 걸리는 작업인 경우에 한해서 RQ를 사용하는 것이 바람직하다.

2. 시스템 구성

Tmax RQ(Reliable Queue) 시스템은 클라이언트가 보낸 서비스 요청 메시지나 서비스 수행 결과를 물리적 매체(디스크) 또는 가상 매체(메모리)에 기록하거나 읽어들이고, 이를 운용 및 관리하는 모든 API와 명령어를 포함한다. RQ를 사용함으로써 만일의 사태에도 사용자의 서비스 요청 및 서비스 수행 결과를 잃어버리지 않으며 미처리된 작업도 재개할 수 있다.

figure 1 1
RQ 시스템 구성

RQ 시스템은 다음과 같이 구성된다.

  • RQ 파일 시스템

  • RQS

  • RQ API

  • 관리 툴

RQ 파일 시스템

Tmax RQ 시스템은 RQ를 관리하는 실제 데이터가 저장되는 공간으로 특별한 Raw Device를 사용하지 않는다. RQ 시스템이 기동되면 Tmax는 사용자가 지정한 디렉터리에 16~2047 MB의 파일을 생성하여 RQ 데이터 파일로 사용한다.

RQ 데이터 파일은 Tmax 환경 파일에 지정한 RQ명을 이용하여 "RQ명.data"라는 파일명으로 생성된다. 사용자는 RQ 데이터 파일의 크기와 시스템이 종료된 후 데이터가 남은 상태의 RQ 파일을 재사용할 것인지 등을 지정할 수 있다. 현재 Tmax 버전에서는 RQ 데이터 파일의 크기가 자동적으로 조절되지 않으므로 사용자가 적절한 값을 지정해야 한다.

RQ는 Request, Reply, Fail 3 종류의 큐로 구분된다.

  • Request 큐

    서비스를 수행하기 전에 tpenq() 처리가 된 요청 데이터는 모두 Request 큐에 저장된다.

  • Reply 큐

    정상적으로 서비스를 수행하여 반환된 데이터는 서비스 성공이나 실패에 무관하게 모두 Reply 큐에 저장된다. 특별한 예외로 서비스명을 명시하지 않은 데이터는 이 곳으로 저장된다.

  • Fail 큐

    서비스 수행에 실패했거나 수행되기 전에 종료된 RQ 데이터들은 Fail 큐에 저장된다.

    다음과 같은 경우 Fail 큐에 데이터가 저장된다.

    • tpenq() 처리된 데이터가 서버로부터 정상적인 반환 결과를 받지 못한 경우

    • 해당 서비스가 없는 경우

    • 서비스에서 정상적으로 반환되지 않은 경우

    • Request 큐에 데이터가 있는데 Tmax 시스템이 재기동되었을 때 RQ 타입이 'WARM booting’일 경우

RQ에 저장된 데이터는 시스템 장애 및 네트워크 불안정 등으로 Tmax 시스템이 재기동되더라도 다시 사용할 수 있다. 데이터 복구를 위해서는 환경 파일에 설정이 되어 있어야 한다. 환경 파일 설정에 대한 자세한 내용은 UCS 사용 프로그램의 예제를 참고한다.

복구될 때 Request 큐에 쌓여있던 데이터와 Fail 큐에 쌓여있던 데이터는 Fail 큐로 옮겨지며 Reply 큐에 쌓여있던 데이터는 그대로 Reply 큐에 위치한다. 이 데이터들은 다시 꺼내어 서비스를 수행하게 하거나 다른 용도로 사용할 수 있다.

figure 1 3
시스템 Fail인 경우 RQ
RQS

RQS는 RQ 관리자로 CLH(클라이언트 매니저)의 제어를 받으며 실제 RQ 파일에 데이터를 저장하고 읽어 들이는 모든 과정을 관리하고 제어한다. RQS는 자체적인 버퍼를 가지고 실제 디스크에 저장된 데이터와 동기화된 데이터를 유지하여 RQ를 사용하는 서비스의 수행에 대해 Caching 기능을 제공한다. 사용자는 RQS가 디스크에 데이터를 저장하는 방법을 지정할 수 있다.

RQ API

RQ 시스템을 사용하는 애플리케이션을 위한 API를 제공한다. API에 대한 자세한 내용은 API를 참고한다.

관리 툴

관리자는 Tmax에서 제공하는 tmadmin을 사용하여 RQ 시스템의 상태 정보를 조회하거나 관리할 수 있다. tmadmin을 사용한 RQ 시스템 관리에 대한 자세한 내용은 시스템 관리를 참고한다.

3. RQ 시스템 흐름

기본적인 RQ 시스템의 흐름은 다음과 같다. 클라이언트에서 RQ를 통해 서비스를 요청하고 그 결과값을 RQ를 통해 받아가는 일반적인 사용법을 보여준다.

figure 1 2
RQ 시스템 프로세스

다음은 RQ 시스템 흐름 순서에 대한 설명이다.

  1. 클라이언트에서 "ATTACK"이라는 서비스를 tpenq()로서 요청한다.

  2. 클라이언트의 요청을 받은 Tmax 시스템 핸들러(이하 CLH)는 tpenq()에 대한 처리를 RQS(RQ 관리자)에게 의뢰한다.

  3. RQS는 해당 서비스를 Request 큐(Disk)에 기록한다.

  4. RQS는 CLH에게 정상적으로 Request 큐에 서비스를 입력했다는 결과를 전송한다.

  5. CLH는 클라이언트에게 서비스 요청에 대한 응답으로 정상적으로 처리되었다는 결과를 전송한다.

  6. RQS는 CLH에게 서비스의 처리를 요청한다.

  7. CLH는 요청받은 서비스(ATTACK)를 수행한다.

  8. 해당 서비스(ATTCK)가 루틴을 수행 후 tpreturn()을 한다.

  9. 서비스(ATTCK)의 결과를 받은 CLH는 그 결과를 RQS로 전송한다.

  10. 서비스 처리 결과를 받은 RQS는 정상적으로 처리된 경우에는 Reply 큐에 기록하고 실패한 경우에는 Fail 큐에 기록한다.

  11. 클라이언트는 해당 서비스명(ATTACK)으로 tpdeq()를 요청한다.

  12. CLH는 RQS에게 처리 결과를 요청한다.

  13. RQS는 디스크 내용에 대한 최신 정보를 메모리에 유지함으로써 추가적인 디스크 I/O없이 응답을 CLH에 전송한다.

  14. CLH는 응답을 클라이언트에게 전송한다.