제1장 소개

내용 목차

1.1. 프로그램 흐름
1.1.1. TCS
1.1.2. POD
1.1.3. UCS
1.2. UCS와 RDP
1.2.1. UCS
1.2.2. RDP

본 장에서는 UCS의 개요 및 함수에 대해 설명한다.

1.1. 프로그램 흐름

1.1.1. TCS

TCS(Tmax Control Server)는 다른 미들웨어(Tuxedo, Entera, TopEnd 등)에서 사용되는 것과 같이 클라이언트의 요청이 있을 경우에만 서비스를 제공하는 전형적인 프로세스 컨트롤 방법이다.

TCS 프로세스는 일반적인 3계층(Tier) 개념을 가지고 있는 서버 프로세스이다. Tmax는 클라이언트의 요청을 적절한 서버 프로세스의 서비스에 전달하고, 서버 프로세스의 서비스는 비즈니스 로직에 맞는 연산 작업을 수행한 후 결과값을 생성해서 클라이언트에 반환한다.

TCS 타입의 서버 프로그램 흐름은 다음과 같다.

[그림 1.1] TCS 타입 서버 프로그램

TCS 타입 서버 프로그램

1.1.2. POD

POD(Process On Demand)는 클라이언트의 요청이 있을 때 서버 프로세스가 기동되어 서비스를 수행하는 프로세스 컨트롤 방법이다.

POD 프로세스는 TCS와 비슷한 형태의 프로세스이다. Tmax를 기동할 때 프로세스가 기동되어 있는 상태가 아니더라도 클라이언트에서 요청이 오면 Tmax에서 해당 프로세스를 기동시켜 요청을 처리한 후에 다시 프로세스를 종료시키는 점이 다르다.

1.1.3. UCS

일반적으로 TCS, POD는 클라이언트의 요청에 대해서만 작업을 수행하는 수동적인 프로세스이다. 그에 반해서 UCS(User Control Server)는 클라이언트의 요청이 없더라도 클라이언트에게 데이터를 전송하는 등의 별도의 작업을 수행할 수 있다. 또한 클라이언트의 요청이 발생했을 때에도 이를 처리할 수 있다. UCS는 TP-Monitor 중 Tmax만의 고유한 기능이다.

UCS 타입의 서버 프로그램 흐름은 다음과 같다.

[그림 1.2] UCS 서버 프로그램

UCS 서버 프로그램

1.2. UCS와 RDP

1.2.1. UCS

UCS(User Control Server)란, 프로그램의 처리 흐름을 미들웨어에서 제어하지 않고, 사용자가 직접 제어할 수 있는 Tmax 고유의 프로그램 형태이다. 이를 이용한 프로그램과 프로세스를 각각 UCS 프로그램 및 UCS 프로세스라고 한다. 클라이언트의 요청(이벤트)에 의해서만 작업을 수행하는 기존의 방식으로도 작업을 수행할 뿐만 아니라, 서버 프로세스(UCS 프로세스)가 능동적으로 이벤트를 발생시켜 작업을 수행할 수 있다.

클라이언트의 요청이 없어도 정보 전달이 필요한 업무(증권 시세 정보, notify 등), 작업 스케줄링 업무 및 대외기관과의 연동 업무 등에 UCS가 사용되고 있다.

UCS의 필요성

UCS는 말 그대로 사용자가 제어할 수 있는 서버이다. 기존에 데몬 형태로 기동되어 수행했던 특정 시간에 작업수행, 다른 대외기관과의 연동 작업, 클라이언트로의 정보전달 등을 UCS 형태로 작성할 수 있다. 이렇게 작성된 프로그램의 프로세스들은 모두 Tmax 관할이 되어 별도의 프로세스 관리(비정상 종료의 경우 재기동 등)가 필요없다.

다음은 UCS가 사용되는 경우이다.

  • 정보를 변경하면 접속된 클라이언트(특정 클라이언트나 모든 클라이언트)에게 알려주는 형태의 업무

    • 업무사례 1

      증권 업무에서 시시각각 변하는 시세 정보를 클라이언트의 요청이 없이도 전달하여, 클라이언트가 보다 빠르고 정확한 데이터를 받을 수 있다.

    • 업무사례 2

      소프트웨어 장애나 작업 일정에 대한 통보, 기타 공지 사항 등을 관리자나 개발자 또는 사용자에게 통지할 수 있다.

    • 업무사례 3

      은행 업무에서 환거래가 발생한 경우 직접 해당 클라이언트에게 통보하거나 자동화기기의 상태를 특정 클라이언트(자동화기기 관리자)에게 알려줄 수 있다.

  • 작업 스케줄링 형태의 업무

    • 업무사례

      특정 시간에 배치 작업을 수행하거나 기타 스케줄링이 필요한 업무에 사용할 수 있다.

  • 대외 연동 업무

    • 업무사례

      대외기관과의 연동 업무를 구현할 때 보다 효율적이고 간단한 프로그램 구조를 제공한다. 비동기 형태의 거래흐름, 데이터의 도착 유무를 체크하기 위한 looping(이하 루핑)이 없어지므로, 프로그램을 간편하게 작성할 수 있을 뿐만 아니라 CPU의 자원을 절약할 수 있다. 또한 다양한 형태의 업무를 UCS 타입으로 구현할 수 있다. 따라서 개발자가 UCS 프로그램의 처리 흐름을 정확히 이해하고 사용하면 업무를 구현할 때 유용하게 사용할 수 있다.

1.2.2. RDP

RDP(Realtime Data Processor)는 UCS와 같은 형식의 서버로 동작한다. RDP는 지속적으로 변하는 데이터를 효율적이고 빠르게 클라이언트에 전달하기 위해 UCS 타입의 프로세스를 커널 수준에서 개량한 프로세스이다. RDP는 CLH를 거치지 않고 클라이언트로 데이터를 전달하기 때문에 소량의 데이터를 다수의 클라이언트에게 짧은 시간 간격으로 보낼 경우에 프로세스 점유율이나 처리 속도의 측면에서 UCS보다 월등한 성능을 보인다.

[그림 1.3] RDP의 동작 방식

RDP의 동작 방식

RDP 서버는 한 노드에 유일해야 하며 해당 노드에 존재하는 모든 서비스는 RDP 서버로 서비스의 결과 데이터를 전송한 후 RDP 서버에서 데이터를 클라이언트로 보내게 된다.

다른 서버 프로세스에서 처리한 결과를 얻어오기 위한 채널의 수(RSCPC)를 설정해야 하며 CLH와 RDP 서버 프로세스의 수는 일정하게 유지되어야 한다(MIN 값과 MAX 값이 같아야 한다). 단, RDP 서버 프로세스의 MIN, MAX는 항상 CLH보다 많아야 하며 통상 2배수로 설정한다. 또한 CLH는 MINCLH, MAXCLH의 수를 동일하게 설정해야 한다.

프로그램 구성 및 API는 UCS와 동일하며 환경설정과 컴파일 방법에서 약간 차이가 있다. RDP의 환경설정 및 컴파일 방법에 대한 자세한 설명은 “5.3. RDP 환경설정 및 컴파일”을 참고한다.