Tmax 소개

다음은 Tmax를 구성하는 시스템 구성에 대한 그림이다.

다음은 Tmax 시스템이 서비스를 수행하는 과정을 보여주는 그림이다.

다음은 Tmax 시스템이 서비스를 수행하는 절차에 대한 설명이다.

TIM(Tmax Information MAP)은 Tmax 시스템을 운용하는 핵심 정보로 Tmax에서 관리하는 공유 메모리를 의미한다. TIM은 엔진 프로세스 중에 TMM 프로세스에 의해서 생성된다.

TIM은 역할에 따라서 다음과 같이 4개로 구분된다.

Tmax는 UNIX 도메인 소켓(Domain Socket) 통신 방식을 사용한다. UNIX 도메인 소켓 통신 방식은 소켓 API를 수정없이 사용하며, 파일을 이용해서 내부 프로세스 간에 통신을 하는 방식이다. 이는 Port 기반의 외부 통신 방식과는 달리 파일을 이용한 내부 통신 방식으로 더욱 안정적이고, 속도가 빠르다는 장점이 있다. 파일을 통한 통신 방식과 커널에서 메시지를 관리한다는 특징은 FIFO(Named Pipe)와 비슷하나, FIFO와 달리 양방향 통신이 가능하여, 다수의 클라이언트/서버 환경을 구축하기가 쉽다.

다음은 CLL, CLH, TLM이 UNIX 도메인 소켓 통신을 하는 과정에 대한 그림이다. PSR로 표시된 애플리케이션 서버는 CLL, CLH, TLM과 연결되어 진다.

기존의 2-tier 기반의 클라이언트/서버 환경은 애플리케이션 개발의 가장 일반적인 방법으로 하나의 클라이언트에 서버 프로세스가 하나씩 생성되는 방식이다. 즉, 클라이언트의 수가 증가하면 서버 프로세스의 수도 함께 증가한다. 이러한 클라이언트와 서버 프로세스의 증가는 프로세스 생성에 필요한 시간과 파일 및 데이터베이스의 open/close에 많은 시간이 소요되고, 하나의 서버는 연결된 클라이언트에서만 사용이 가능하므로 서버 프로세스의 현저한 사용 저하와 많은 관리 비용의 문제가 발생했다.

2-tier 기반의 클라이언트/서버 환경은 이러한 문제를 해결하기 위해 미들웨어인 TP-Monitor를 이용하여 3-tier로 구성한 클라이언트/서버 구조를 도입하였다. TP-Monitor인 Tmax는 생성되는 프로세스의 수를 조절하고, idle 중인 서버 프로세스를 스케줄링하며, 서버 프로세스의 Tuning을 통한 최적의 시스템을 운영한다.

다음은 2-tier 클라이언트/서버 구조를 나타내는 그림이다.

다음은 3-tier 클라이언트/서버 구조를 나타내는 그림이다.

3-tier 환경은 2-tier 환경보다 성능, 확장성, 관리 기능, 장애 대책 측면에서 월등한 시스템으로 구축할 수 있고, 내부에서 프로세스 관리 모듈을 통해 안정적 서비스를 제공한다. 3-tier 환경에서 Tmax의 내부 프로세스 관리 모듈은 생성되는 프로세스 수 조절하고 Idle 중인 서버 프로세스 스케줄링한다. 또한 서버 프로세스의 Tuning을 통한 최적의 시스템을 운영한다.

다음은 2-tier와 3-tier의 클라이언트/서버 환경에 대한 비교이다.

트랜잭션은 논리적으로 하나의 단위로 처리함으로써 다양한 자원들을 일괄적으로 활용할 수 있으며 분산된 자원 간의 자료 무결성을 유지할 수 있다. 분산 트랜잭션은 네트워크상의 시스템 간의 트랜잭션을 의미하며, 트랜잭션의 ACID(Atomic, Consistent, Isolated, Durable: transaction properties) 특성을 만족하게 해야 한다. Tmax 시스템은 이기종 또는 동종 복수 DBMS 간의 분산된 트랜잭션에서 ACID를 보장한다.

Tmax의 분산 트랜잭션 관리는 기본적으로 국제 표준인 X/Open의 DTP 모델을 준수한다. X/Open DTP 모델을 따라 AP(Application Program), TM(Transaction Manager), RM(Resource Manager), CRM(Communication Resource Manager)로 구성되어 있으며, X/Open DTP 모델을 준수하는 표준 함수의 집합체인 ATMI 함수를 지원한다. 또한 X/Open DTP를 준수하는 서로 다른 종류의 DBMS 사이에 발생하는 트랜잭션을 묶어서 처리한다.

다음은 X/Open DTP의 구조이다.

분산 트랜잭션을 처리하는 경우 2단계(2 Phase) commit을 지원하여 데이터 무결성을 보장하고 API를 제공하여 전역 트랜잭션을 용이하게 한다. 분산 트랜잭션 관리란, 여러 지역으로 분산된 환경에서 다수의 이기종 하드웨어 플랫폼 및 데이터베이스를 이용하여 실행하는 트랜잭션의 관리를 의미한다.

Tmax는 다양한 부하 조절 기능을 제공하여 전체 시스템의 처리량을 증대시키고 처리 시간을 단축한다. Tmax는 SLM(System Load Management)에 의한 부하 조절, DDR(Data Dependent Routing)에 의한 부하조절, DLM(Dynamic Load Management)에 의한 부하조절을 제공한다.

SLM(System Load Management)은 정의된 부하 비율로 분산 처리하는 방식이다. 하드웨어 성능에 따라 고유의 작업 처리량을 설정해서 한 노드의 서비스 요청량이 작업 처리량을 초과하면 다른 노드로 서비스 연결을 전환하는 방식이다. 노드마다 처리량을 다르게 설정하여 부하를 처리할 수 있다.

SLM은 다음과 같은 동작 방식으로 각 프로세스에서 처리된다.

다음은 SLM에 의해 부하를 조절하는 프로세스의 예로 Node 1, Node 2, Node 3에 작업 처리량을 각각 1:5:2로 설정해 놓으면 Node 1에서 1개의 작업을 처리하고 다음 작업은 Node 2, 다음 작업은 Node 3에서 처리한다. 이후 연속적인 3개의 작업은 Node 2에서 모두 처리한다.

DDR(Data Dependent Routing)은 데이터 값에 따라 분산 처리하는 방식이다. 여러 노드에서 공통된 서비스를 제공하면 데이터 범위에 따라 노드 간 라우팅을 할 수 있도록 지정한다. 입력된 필드의 값을 확인하여 적절한 서버 그룹으로 해당 서비스를 요청한다.

DDR은 다음과 같은 동작 방식으로 각 프로세스에서 처리된다.

다음은 DDR에 의해 부하를 조절하는 프로세스의 예로 연령층 별로 각각 다른 노드에서 고객조회 서비스를 제공한다면 Node 1에서는 0~10세까지, Node 2에서는 11~20세까지, 그리고 그 이외의 연령은 Node 3에서 처리되도록 한다.

DLM(Dynamic Load Management)은 부하 비율에 따라 동적으로 처리 그룹을 선택하는 방식이다. 특정 노드에 부하가 집중되는 경우 Tmax 동적 부하 조절 방법에 따라 부하를 분산하여 전체 시스템의 처리량을 증가시키고 처리 시간을 단축한다. 시스템의 부하는 기동되어 있는 프로세스의 큐잉 상태로 판단된다.

Tmax 시스템은 프로세스별로 메모리 큐를 관리하여 요청된 서비스에 대해서 현재 매핑 가능한 프로세스가 없는 경우에는 메모리 큐에 저장한다. 메모리 큐에 쌓인 거래의 건수가 시스템의 부하를 의미한다.

DLM은 다음과 같은 동작 방식으로 각 프로세스에서 처리된다.

다음은 DLM에 의해 부하를 조절하는 프로세스의 예로 Node 1, Node 2에서 서비스를 동일하게 제공하고, Node 1에 서비스 요청이 집중되는 경우 Tmax에서 제공하는 동적 분산 알고리즘에 의해 부하를 분산하여 처리한다.

Tmax는 시스템 자원의 높은 가용성을 보장하기 위하여 머신, 네트워크, 시스템, 서버 프로세스 등의 장애가 발생하는 경우 장애 대책을 통하여 중단없는 서비스를 제공할 수 있다. 장애는 하드웨어적인 장애와 소프트웨어적인 장애로 구분할 수 있다.

하드웨어적인 장애가 발생하는 경우 Load Balancing을 통한 장애 대책과 서비스 백업에 의한 정상 운영이 가능하다. 서버 프로세스가 다운되는 소프트웨어적인 장애가 발생할 때에도 프로세스가 재시작되어 중단없이 서비스가 제공된다.

Tmax의 시스템 구성은 각 노드가 서로 다른 노드를 감시하는 Peer-to-Peer 방식이다. 따라서, 아무리 많은 노드라 해도 동일한 조건에서 즉각적으로 장애에 대응할 수 있다.

하드웨어 장애는 다음과 같은 2가지의 장애 대책이 있다.

프로그램 내부적인 버그에 의해서 혹은 사용자의 실수로 인하여 비정상적으로 서버 프로세스가 다운됐을 경우 자동으로 재시작될 수 있는 기능을 제공한다. 그러나 TMS, CAS, CLH와 같은 시스템 프로세스들은 제한 없이 무한으로 재시작되고 이 프로세스들이 비정상적으로 종료되었을 때에는 처리 중이던 서버 프로세스도 같이 다운될 가능성이 있으므로 주의해야 한다.

Tmax에서 제공하는 Naming 서비스는 간단 명료한 서비스 호출이 가능하도록 하여 위치 투명성(Location Transparency)을 보장한다. Tmax는 Naming 서비스를 통해 분산 시스템 내의 서비스 위치 정보를 이름으로 제공하여 간단하고 용이한 서비스 호출이 가능하고 위치 투명성을 제공한다. Naming 서비스는 간단 명료한 서비스 호출이 가능하고 서비스명만 호출하여 해당하는 서비스를 받으므로 프로그래밍이 쉽다. 클라이언트는 서버의 주소를 알지 못해도 서비스명을 통해 서버의 정보를 얻을 수 있다.

Tmax에서는 3가지 종류의 서버 프로세스를 지원한다.

Tmax의 RQ(Reliable Queue)는 서비스 수행도중 장애 등으로 인하여 요청 내용이 사라지는 것을 방지하여 서비스가 신뢰성있게 처리되도록 한다. 많은 시간이 필요한 작업이라든지 반드시 신뢰성이 보장되어야 하는 업무의 경우 요청된 업무를 일단 디스크에 저장하고 처리한다. 시스템 장애 혹은 다른 치명적인 요인이 발생한 때에도 시스템 복구 후 해당 업무를 정상적으로 처리하는 방식이다.

tpenq() 함수의 반환값을 통하여 요청된 서비스가 정확히 디스크에 저장되었는지 확인할 수 있다. 큐잉 업무처리는 Queue manager(Qmgr)가 독립적으로 담당함으로써 다른 업무처리에는 전혀 영향을 주지 않는다. tpdeq() 함수를 사용하여 Queue manager의 처리결과에 대한 정상 유무를 확인할 수 있다.

Tmax는 Fiffie-Hellman 알고리즘 바탕의 데이터 보호 기능을 제공하고 UNIX에서 제공하는 보안기능을 포함하여 5단계 보안기능을 지원한다.

프로세스 상태, 서비스 큐잉 상태, 서비스 처리 건수, 평균 서비스 처리 시간과 같은 전체 시스템 진행 상황을 모니터링할 수 있고 시스템 상태 및 큐 관리 시스템 통계 분석 및 보고서 작성이 가능하다.

시스템 관리는 정적 시스템 관리, 동적 시스템 관리, 모니터링 및 운영(Administration) 기능을 지원한다.

애플리케이션과 데이터베이스의 통합 관리를 통해서 자원의 효율적인 관리가 가능하다.

기존 시스템에서는 전체 시스템에 대한 관리가 이루어지지 못해서 자원의 낭비가 발생해서 분산 시스템은 더 확실한 관리 기능이 요구되었다. Tmax는 전체의 분산 시스템에 대한 중앙 집중식의 모니터링 기능을 통해 애플리케이션을 관리한다.

단일 애플리케이션에 동종의 데이터베이스 혹은 이기종의 데이터베이스를 함께 사용하는 경우 Tmax는 다양한 종류의 자원을 애플리케이션 차원에서 통합관리가 가능하다.

Tmax 도메인은 Tmax에서 독립적으로 관리(start/down)되는 최상위 단위로 지역별 또는 업무별로 시스템을 여러 개의 도메인으로 분산 관리하는 때에도 도메인 게이트웨이를 통해 도메인 간의 연동뿐만 아니라 멀티 도메인 2PC 등의 기능을 지원한다.

Tmax는 장거리 분산 시스템의 상호 데이터를 교환하고, 다른 플랫폼 기반의 시스템 간 손쉬운 연동을 지원하며, SNA CICS, SNA IMS, TCP CICS, TCP IMS, OSI TP 등과 같은 다양한 게이트웨이 모듈을 지원한다. 도메인 간 트랜잭션 서비스 처리 및 라우팅 기능이 가능하다.

여러 노드를 한 도메인에서 관리할 때 발생하는 전체 노드 관리의 어려움, 노드 간 통신 트래픽 급증 등의 문제점을 해결할 수 있다. 또한, 어느 시스템에서든지 요청된 서비스의 처리가 가능하다. 멀티 도메인 환경에서 서비스 방식은 도메인 간 서비스 처리, 도메인 간 라우팅 , 도메인 간 트랜잭션으로 이루어진다.

다음은 멀티 도메인 구성에 따른 서비스 호출 흐름에 대한 설명이다. 멀티 도메인은 게이트웨이를 통해 연결된다. 도메인 게이트웨이는 서로 연결을 맺을 때 서버 또는 클라이언트로 동작한다. 게이트웨이 간 기동 순서는 없다.

Tmax는 TCP/IP, X.25, SNA 등 다양한 게이트웨이를 제공해서 타업무 시스템/대외기관과의 연동을 쉽게 해준다. 게이트웨이는 효과적인 통신을 가능하게 하고 업무 로직과 연계 모듈 분리를 통해 관리의 편의성을 제공한다. 게이트웨이는 Tmax에 의해 관리되므로 자동으로 장애 복구가 가능하고 관리자에 의한 별도 관리가 필요없다.

다음은 게이트웨이의 동작에 대한 설명으로 클라이언트가 서비스를 요청하면 해당 서비스가 있는 도메인으로부터 그 처리 결과를 응답받는 것을 보여준다. 이때 양쪽 도메인에서는 게이트웨이를 통해 트랜잭션 서비스나 값에 따라 도메인 간에 라우팅할 수 있다.

2-tier 시스템에서 3-tier 시스템으로 변환이 용이하도록 다양한 에이전트를 제공한다.

RCA는 Tmax 클라이언트 라이브러리를 사용할 수 없는 기존 통신 프로그램과 TCP/IP 소켓으로 연결하여 Tmax 시스템에서 제공하는 서비스를 이용할 수 있도록 지원하는 에이전트로 리모트(REMOTE) 모드 또는 로컬(LOCAL) 모드의 서비스를 지원한다. 기존 Tmax 클라이언트 라이브러리처럼 하나의 클라이언트 라이브러리는 하나의 클라이언트 프로그램에서만 사용한다. 그러나 RCA는 Multi Thread 방식으로 작성되어 하나의 Thread가 하나의 Tmax 클라이언트로 동작한다. 또한, 다양한 형태의 클라이언트를 지원하기 위해 최대 32개까지의 멀티 포트 지정이 가능하다.

RCA는 사용자의 접속을 제어하는 RCAL, 사용자의 로직과 함께 생성되는 RCAH를 통해 안정적인 장애대책이 가능하고 관리 툴인 rcastat와 rcakill을 제공한다.

다음은 RCA의 구조이다.

SCA는 Tmax 클라이언트 라이브러리를 사용할 수 없는 기존의 통신 프로그램과 TCP/IP 통신으로 연결하여 Tmax 시스템에서 제공하는 서비스를 이용할 수 있도록 지원하는 에이전트이다. SCA는 customizing routine과 CLH 라이브러리로 구성된다. CLH는 CLH 라이브러리와 링크된다.

클라이언트와 접속 및 해제, 데이터의 송수신에 해당하는 네트워크에서의 처리 부분은 시스템 내부적으로 처리된다. 개발자는 클라이언트와 미리 정의된 포트 번호를 Tmax 환경파일에 설정하여 클라이언트와 접속할 수 있으며, 수신된 데이터와 송신할 데이터를 개발자의 의도에 맞도록 수정 및 보완할 수 있다.

SCA는 다양한 형태의 클라이언트를 지원하기 위해 최대 8개까지 포트 지정이 가능하다. SCA 모듈은 CLH 모듈과 직접적인 데이터의 전달이 가능하고 Non-Tmax 클라이언트/Tmax 클라이언트를 동시에 수용할 수 있다. SCA의 서비스 방식은 TCP/IP raw 소켓을 이용하는 방법과 Tmax 클라이언트 라이브러리를 이용하는 방법으로 나뉜다.

다음은 SCA 중 하나인 CA(Client Agent)를 이용한 서비스 호출 형태를 보여주는 그림이다.

클라이언트에서 서버로 통신을 요청하는 다음과 같은 4가지 방식을 지원한다.

실시간으로 지속적으로 변하는 데이터를 보다 빠르게 처리하기 위해 CLH(Client Handler)를 거치지 않고 RDP에서 클라이언트에게 직접적으로 데이터를 전달할 수 있다.

따라서 RDP를 이용하게 되면 CLH의 부하를 크게 낮출 수 있기 때문에 Tmax 시스템 전체적인 성능을 높일 수 있다. RDP는 UDP 데이터 유형에 대해서만 지원하고 있다. RDP는 UCS 서버 프로세스 형태로 구성된다.

Window 기반의 클라이언트 프로그램에서 사용할 수 있는 편리한 라이브러리를 제공한다. WinTmax 라이브러리와 tmaxmt 라이브러리 2가지 종류가 있으며 기본적으로 Thread 기반으로 동작한다.

Tmax는 HMS(Hybrid Messaging System)를 통해서 안정적인 메시지 전달을 지원한다.

Tmax HMS는 다음과 같은 특징을 갖는다.

HMS는 Tmax의 기능으로 Sender와 Receiver의 느슨한 결합(loosely coupled)을 위한 통신 매개체이며, Queue 방식과 Topic 방식을 지원한다.

다음은 Tmax 도입 시 고려해야 할 시스템 환경에 대한 설명이다.

Tmax를 도입할 때 기능, 성능 및 안정성 등 여러 측면에서 고려해야 할 사항이 있다.