administration guide스를 관리하는 daemon 프로세스와 서비스를 담당하는 ntas engine...

개요 1-1

NTAS™

Administration Guide

NTAS™ Version 3.0

NTAS Administration Guide

1-2 개요

Copyright © 2003 Ari System, Inc. All Rights reserved.

“NTAS” are trademarks or registered trademarks of Ari System, Inc.

개요

개요 1-3

Table of Contents

CHAPTER 1 개요 .......................................................................................... 1-6

1.1 개요 ................................................................................................. 1-6

1.2 이 글을 읽을 대상 .......................................................................... 1-6

1.3 참고해야할 문헌들 .......................................................................... 1-6

CHAPTER 2 NTAS의 구조 ............................................................................ 2-7

2.1 NTAS의 구조 ................................................................................... 2-7

2.1.1 개요 ..................................................................................... 2-7

2.1.2 NTAS의 논리적 구조 .............................................................. 2-8

Connection..................................................................................................2-8

Business .....................................................................................................2-8

Leader .........................................................................................................2-8

Session .......................................................................................................2-9

Web .............................................................................................................2-9

2.2 클러스터링 시스템으로써의 NTAS ................................................. 2-9

2.2.1 소규모의 가장 단순한 형태 .................................................... 2-10

2.2.2 최소한의 노드수로 fail over 구조 ........................................... 2-11

2.2.3 클라이언트 접속이 적고 비즈니스 처리 양이 많은경우 .............. 2-11

2.2.4 클라이언트 접속이 적고 비즈니스 처리 양이 많은경우 - 최적화 유형

2-12

2.2.5 4대의 노드의 경우 최적화 방안 ............................................. 2-13

2.2.6 규모가 있는 시스템의 유형 .................................................... 2-14

2.3 NTAS의 생산성/유지보수/테스트 .................................................. 2-14

CHAPTER 3 기초적인 Admin .................................................................... 3-15

3.1 개요 ............................................................................................... 3-15

3.2 서버기동 및 종료 .......................................................................... 3-15

3.2.1 NTAS System 시작 ............................................................... 3-16

3.2.2 NTAS System 종료 ............................................................... 3-19


1-4 개요

3.3 모니터링 ........................................................................................ 3-20

3.3.1 NTAS Server에 접근 ............................................................. 3-20

3.3.2 전체 모니터링– Nodes .......................................................... 3-20

3.3.3 상세 모니터링 ..................................................................... 3-23

시스템 상태 그래프 .................................................................................. 3-23

데이터베이스 Connection 사용 상태 정보 그래프 ................................... 3-23

서버정보 ................................................................................................... 3-24

스레드/메모리/NTAS연결의 정보를 을 수치로 실시간 관찰 ..................... 3-25

라이센스에 대한 표현 ............................................................................... 3-25

텍스트 모니터링 ....................................................................................... 3-25

사용자 관리 .............................................................................................. 3-26

옵션 .......................................................................................................... 3-28

메시지 테스터 ........................................................................................... 3-29

3.4 속성설정 ........................................................................................ 3-30

3.4.1 Daemon 설정 ...................................................................... 3-31

3.4.2 Main 설정 ........................................................................... 3-33

참조할 Leader 설정 전체 보기 ................................................................ 3-34

참조할 Leader의 세부 설정 ...................................................................... 3-34

참조할 Session 설정 전체 보기 ............................................................... 3-35

참조할 Session의 세부 설정 .................................................................... 3-35

참조할 Business 설정 전체 보기 ............................................................. 3-36

참조할 Business의 세부 설정 .................................................................. 3-37

Data Source 설정 전체 보기.................................................................... 3-38

DataSource의 세부 설정 .......................................................................... 3-38

3.4.3 Business 설정 ..................................................................... 3-40

3.4.4 Connection 설정 ................................................................. 3-42

CHAPTER 4 전문적인 Admin .................................................................... 4-45

4.1 개요 ............................................................................................... 4-45

4.2 서버 디렉토리 구조 ....................................................................... 4-45

4.3 Client가 Connection에게 접근하는 방법 ..................................... 4-47

4.4 Message와 Process의 동작원리 .................................................. 4-48

4.4.1 하나의 노드에서 처리 될 때 .................................................. 4-48

4.4.2 클러스터링 구조에서 메시지 처리 패턴 ................................... 4-49

4.5 Ntas의 Thread Pool 관리 메커니즘 ............................................. 4-51

개요

개요 1-5

4.6 Time Scheduler 의 메커니즘 ........................................................ 4-52

4.7 클러스터 성능의 한계 ................................................................... 4-53

4.8 데이터베이스 관리 메커니즘 ........................................................ 4-54

4.8.1 Database Pool .................................................................... 4-54

4.8.2 리소스 관리 ........................................................................ 4-55

4.8.3 Two Phase Commit .............................................................. 4-55

4.9 세션관리 메커니즘 ........................................................................ 4-56


1-6 개요

CHAPTER 1 개요

1.1 개요

이 가이드는 NTAS 시스템의 구조를 정확히 이해하기 위해 참조하는 자료이다.

NTAS 시스템 기반에서 프로그래밍을 하면서 메커니즘을 좀더 정확하게 이해하

고 적용의 범위를 넓혀 가기위해 필요하다. NTAS 시스템 기반에서 단지 프로그

램을 동작시키기 위한 개발자라면 chapter 3을 중점적으로 읽기 바란다. 하지만,

Admin으로써 자격을 갖추려면 이 자료 전체를 충분히 이해해야 한다.

1.2 이 글을 읽을 대상

java프로그래밍을 경험하고, Ntas시스템 기반에서 기초적인 프로그래밍이 가능한

사람이면 가능하다.

1.3 참고해야할 문헌들

Ntas Install Guide

Ntas Programming Guide

NTAS의 구조

NTAS의 구조 2-7

CHAPTER 2 NTAS의 구조

2.1 NTAS의 구조

그림 2-1

2.1.1 개요

NTAS 시스템은 TCP/IP 의 네트워크를 기반으로 클러스터링을 지원하며 다양한

시스템 자원을 통합시켜주는 시스템 소프트웨어이며, 클러스터링으로 바라본다

면 부하분산 클러스터링 과 고가용성 클러스터링의 두가지 요소를 갖는 시스템

으로 볼수 있다. 또한 이기종의 다양한 시스템의 통합과, 다양한 프로그래밍 언


2-8 NTAS의 구조

어를 통합시켜주는 기능을 가지고 있으며, 클러스터링의 지원으로 높은 속도와

안정성 및 다양한 툴로 인한 개발생산성 인프라 지원한다. NTAS는 Network

Transaction Application Server의 약자로 네트워크 기반의 Server side 시스템

개발에 필요한 통합 어플리케이션 서버를 의미하며, 또한 클라이언트 개발을 위

해 여러 프로그래밍 언어 클라이언트 라이브러리와 툴을 제공한다. 다양한 언어

의 지원에 대해서는 Ntas Programming Guide를 참조하라.

2.1.2 NTAS의 논리적 구조

그림2-1에서 보는 바와같이 NTAS시스템은 TCP/IP 기반의 통신프로토콜인

NTAS Protocol을 지원한다. NTAS의 기본구조는 Leader, Business, Connection,

Session, Web 등의 논리적 구조가 존재하며, 이러한 논리적 구조는 물리적 구조

로 구성이 가능하며 여러 대가 하나의 기능을 수행하기도 한다. 서버가 일부 다

운되더라도 다른 서버를 재 시작 할 필요가 없다. 서비스를 하는 도중에도 문제

가 발생한 서버만을 교체하면 되고, 서버를 증설하기 위하여 서비스를 재 시작

할 필요없이 증설할 서버의 세팅을 하고 네트워크 연결만으로 서비스의 재 시작

없이 계속적인 서비스를 할 수 있는 부하분산/고가용성의 클러스터링 시스템이

다.

NTAS SYSTEM은 TCP/IP기반에 NTAS Protocol을 사용하며, 4가지의 논리적 구

조가 있으며 그 특징은 다음과 같다.

Connection

클라이언트와 Ntp 프로토콜 접속을 처리하는 기능을 담당한다.

Business

Business 로직을 처리하는 기능을 담당한다.

Leader

모든 서버의 실시간 시스템 정보를 유지하면서 Client 접속에 따른 Connection

의 Load Balancing과 전체 서버의 Monitoring을 위한 서버 시스템이다.

클러스터링 시스템으로써의 NTAS

NTAS의 구조 2-9

Session

클라이언트 Session별 데이터관리 및 시스템간의 통합 정보관리를 위한 시스템

이다. 이시스템에는 개발자가 로직을 추가함으로써 사용자 정의의 세션관리를

할 수 있다.

Web

Java 의 J2EE 스펙의 Servlet Container 를 지원한다.

2.2 클러스터링 시스템으로써의 NTAS

NTAS시스템은 부하분산과 고가용성의 두가지 개념의 클러스터링을 지원한다.

하지만, 이것은 소프트웨어 자체만으로는 결코 불가능하다. 적절한 H/W와의 결

합이 반드시 필요하다. 물리적인 H/W 장애 자체를 소프트웨어 자체만으로는 어

떻게 해볼수 있는 방법은 없다. H/W의 장애시 혹은 성능의 한계시에 이를 극복

하는 방법을 S/W로 해결하고자 하는 것이다. 다음은 구조의 몇가지의 경우를

예를 들어서 분석하고, 장애 및 성능의 한계를 어떻게 극복 할것인가를 제시하

고 그 구조의 장단점과 주의 사항을 설명하겠다.

주) NTAS의 시스템 구조를 고려할때는 물리적이든지 혹은 논리적이든지 항상

서비스 대상의 논리구조(Leader, Connection, Business, Session)를 배치해야

한다는 것을 명심하라. (Web 은 Ntas 클러스터링과 직접적인 연관성이 없으므

로 클러스터링 구조설명에서 제외한다.)


2-10 NTAS의 구조

2.2.1 소규모의 가장 단순한 형태

그림 2-2

노드 1대에서 모든 논리적 구조가 수행되는 형태이다. 이는 시스템의 중요도가

그렇게 높지 않은 시스템에서 배치될 수 있는 구조이다. 이는 단순히 실행만 되

고, 부하 분산 혹은 고가용성의 클러스터의 효과를 볼 수는 없다. 물론 NTAS시

스템의 개발생산성을 위해서 도입을 했고, 차후에 사용자가 늘어나서 시스템 증

설이 예측된다면 초기에 이런형태의 구조로 가져갈 수도 있다. 또한 개발자 환

경의 경우도 이경우 일것이다. 개발자가 개발코드의 기능 테스트하기 위해 여러

노드의 클러스터링 구조일 필요는 없다. 하지만 서비스를 한다면 (서비스의 중

요도에 따라서) 최소한 fail over는 고려해야 된다. 최소한의 노드수로 fail over

를 고려하려면 그림2-3을 참조하라.


NTAS의 구조 2-11

2.2.2 최소한의 노드수로 fail over 구조

그림 2-3

그림2-2의 똑 같은 구조의 노드를 하나 더 증설한 구조이다. 이는 한쪽 서버가

fail over되더라도 다른 하나의 서버가 기능을 대체 할 수 있는 구조이다. 따라서

두대의 노드가 동시에 다운될 확률은 아주 적기 때문에 한대의 노드 구조 보다

는 훨씬 서비스의 안정을 줄 수 있다. 물론 한대의 노드 보다는 두대의 서버에

의해 부하 분산이 되기 때문에 그 성능도 높일 수 있다.

2.2.3 클라이언트 접속이 적고 비즈니스 처리 양이 많은경우

그림 2-4

그림 2-2는 비즈니스는 처리량은 많고 실제 Connection에 접속하는 Client의

접속 수는 적을 때 주로 사용하는 구조이다. 이것은 모든 논리구조를 완전히 노


2-12 NTAS의 구조

드별로 구분해서 Business 처리 성능은 향상이 되지만, 헛점이 있다. 바로 Fail

Over가 전혀 고려되지 않았다. Fail over가 고려되지 않았다는 것을 쉽게 찾는

방법은 논리구조가 하나만 구성되어 있다면 그것은 바로 fail over가 고려되지

않은 것이다. 따라서 각각의 논리구조를 Count 해서 한 개만 구성이 되어 있다

면 fail over가 고려되지 않은 구조이고 두개 이상이면 fail over가 고려된 것으로

보면 된다. 여기서 fail over가 고려되지 않은 것은 Leader, Connection, Session

등이 그러하다. Domain=4, Distribution=1, Connection=1, Session=1 여기서 1

개만 구성되어 있는 것을 찾으면 된다. 그럼 여기서 7대의 Business 노드가 있

는데 그것만으로 fail over를 고려해서 최적화 하고자 한다면 그림 2-5를 참조하

라.

2.2.4 클라이언트 접속이 적고 비즈니스 처리 양이 많은경우 - 최적화 유

형

그림 2-5

그림 2-4의 노드 수를 기준으로 구조를 최적화 해 보았다. 여기서 클라이언트의

접속이 많지 않으면서도 물리적으로 2대의 노드를 Connection으로 배치를 했다.

그래서 이 구조가 Connection에서 낭비가 아닌가 생각될 수 도 있다 Business

가 여러 개의 경우 우선 자신의 노드에 Business이 존재 하는지의 여부에 관계

없이 적절한 Business을 찾게된다. 모든 것은 업무와 상황에 따라 충분히 조절

될 수 있으며 서비스 수행중에도 상황에 따라 적절하게 재배치가 필요하다.

Session에 부하가 발생될 수도 있는 상황이 발생 될 수도 있다. 그럴때 노드를

완전히 분리함으로써 그노드는 Session의 역할만을 수행 하도록 하는 배치방법


NTAS의 구조 2-13

이 적절하다.

만일에 하나의 노드에 Business와 다른 논리가 존재하고 나머지 Business노드

에는 순수히 Business의 역할만 수행한다고 가정했을때, 그 노드는 다른

Business노드에 비해 부하가 예측 될수 있다. 이때는 그노드의 속성을 비즈니스

처리 비율에 맞게 적절하게 가중치를 부여하여 분산할 수 있다. 비즈니스 처리

비율을 적용하는 경우는 이경우 외에도 다른 상황이 존재 할 수 있다. 예를 들

어 각각의 Domain 노드의 처리할수 있는 능력이 다르다고 가정했을 때는 처리

할 수 있는 가중치를 적절하게 부여할 수 도 있을 것이다. 비즈니스 처리비율의

적용은 ‘3.4 속성설정’을 참조하라

2.2.5 4대의 노드의 경우 최적화 방안

그림 2-6

전체 4대가 Connection, Business이 있고, Leader, Session이 각각 2개의 노드

에 등록되어 있다. Leader는 그 숫자와 클러스터링 시스템의 성능과는 크게 관

계가 없으므로 Leader는 단지 fail over에 관심을 두면 될것이다. 따라서 그림

2-6의 형태가 적절하다고 본다.

그림 2-7


2-14 NTAS의 구조

위의 그림은 Session을 따로 분리한 형태이다.

2.2.6 규모가 있는 시스템의 유형

위에서는 규모가 있는 시스템의 유형을 하나의 예를 들어 배치를 해보았다.

이것은 예를 든 것 뿐이다. 클러스터의 성능을 최대화 하기위해서는 NTAS

System을 이해하고 정확한 업무분석을 통해서 클러스트를 구성해야할 것이다.

2.3 NTAS의 생산성/유지보수/테스트

NTAS System 기반에서 네트워크 프로그램을 개발할 경우 개발자는 실제적으로

네트웍에 대한 경험이 없더라도 비즈니스를 구현하는데 전혀 지장이 없는 구조

이다. NTAS Programming Guide에서 나와 있듯이 개발자는 오로지 비즈니스에

전념할 수 있는 구조이다. 그리고, PSDT(Protocol Specification Design Tool)와

Message Tester, MMConsole(Monitoring and Managemant Console)등의 툴로

개발 생산성 및 유지보수 그리고, 개발 테스트 등을 지원 함으로써 설계 에서부

터 구현, 테스트 까지 지원하여 프로젝트 생산성을 극대화 하고 있다.

개요

기초적인 Admin 3-15

CHAPTER 3 기초적인 Admin

3.1 개요

하나의 서버를 기준으로 시작부터 모니터링 하는 방법, 배치, 테스트, 종료까지

의 일련의 과정을 설명한다. 주로 MMConsole Tool을 기준으로 설명을 한다.

3.2 서버기동 및 종료

NTAS 시스템은 내부적으로 두개의 프로세스가 존재한다. 하나는 NTAS 프로세

스를 관리하는 Daemon 프로세스와 서비스를 담당하는 NTAS Engine 프로세스

이다. MMConsole Tool을 이용하여 Start/Stop 하는 것은 Ntas Engine 프로세스

에게 직접 명령하는 게 아니고 Daemon 프로세스에게 명령해서 NTAS Engine


3-16 기초적인 Admin

이 Start/Stop하도록 하는 구조이다.

NTAS System을 O/S가 booting할 때 시작 하게 할 수도 있지만 지금은

booting시에 시작되는 상황이 아니라 실제 서버를 시작해야 하는 방법을 설명한

다.

3.2.1 NTAS System 시작

NTAS System을 시작하려면 우선 Daemon을 시작해야 한다. (NTAS Server를 바

로 시작할 수는 없다)

Windows : %NTAS_SERVER_HOME%\bin\startserver.exe

Unix/linux : $NTAS_SERVER_HOME/bin/startserver.sh

Daemon을 실행하면 Daemon 프로세스가 실행되고 나서 바로 NTAS Engine 도

실행된다.

실행되고 나서 실행 상태를 세부적으로 확인하기 위해서는 MMConsole 혹은

log파일을 통해서 확인할 수 있다. window에서는 log파일을 문서 편집기로 열어

보면 되고, unix/linux에서는 tail 명령을 사용해서 확인 할 수 있다. 시작시 시

스템 로그는 NTAS_SERVER_HOME/logs/년_월_일.ntas.log 파일에 쓰여진다.

tail –f NTAS_SERVER_HOME/logs/ 년_월_일.ntas.log

이렇게 확인하기 바란다.

01 [27/Jan/2011:14:20:56 +0900],[ntasserver.middleware.handle.Ntas]

02 INFOMATION License file name : null

03 License Name : You have not license name

04 License Serial Number : You have not serial number

05 Company : Not set company

06 Description : You have not license

07 Unlimited : false

08 Start Date :

09 End Date : Thu Feb 03 14:20:56 KST 2011

10 Expired Usable Time(HOUR) : 48

11 License Check Interval(Minute) : 5

12 Web License :

13 Ntas License :

14 FrameBuilder License :

15 Visualizer License :

16 Data Sync Manager License :

17

18


20 INFOMATION You have not a license file

서버기동 및 종료


21


23 INFOMATION

24 +----------------------------------------------------------------------+

25 Network Transaction Application Server ( NTAS ) System(Version 3.0.0)

26 Copyright(c) 2003 All right reserved. Written by AriSystem

27

28 For more information visit http://www.arisystem.com

29 +----------------------------------------------------------------------+

30

31


33 INFOMATION set the detected ip : 100.100.100.19

34


36 INFOMATION Local Host Address : 100.100.100.19

37


39 INFOMATION Ntas Engine Starting .......

40


42 INFOMATION Daemon Inner Sync Manager Port : 1227

43


45 INFOMATION Connected Inner Sync Pool:1226

46


48 INFOMATION Connected Inner Async Socket:1225

49

50 [27/Jan/2011:14:20:56 +0900],[ntasserver.middleware.util.pool.SocketPool]

51 INFOMATION newSocket : INNER_DAEMON_ASYNC_POOL

52


54 INFOMATION SocketPool : connected -> INNER_DAEMON_ASYNC_POOL:100.100.100.19:1225

55


57 INFOMATION Connected Inner Async Pool

58


60 INFOMATION newSocket : INNER_DAEMON_SYNC_POOL

61


63 INFOMATION SocketPool : connected -> INNER_DAEMON_SYNC_POOL:100.100.100.19:1226

64


66 INFOMATION Connected Inner Sync Pool

67


69 INFOMATION Accept System Async Manager Port : 1228

70


72 INFOMATION Accept System Sync Manager Port : 1229

73


75 INFOMATION Start time the Ntas System --> 2011년 1월 27일 목요일 14:20:57

76

77 [27/Jan/2011:14:20:58 +0900],[ntasserver.middleware.dbpoolcontainer.DbConnectionPool]



78 INFOMATION DB CONNECTION SUCCESSFUL

79 DATA SOURCE NAME : test

80 URL : jdbc:mysql://localhost/localtest

81 DRIVER :com.mysql.jdbc.Driver

82 USER :root

83 SUPPORTS SAVEPOINT : true

84 SUPPORTS TRANSACTION : true

85 SUPPORTS ISOLATION LEVEL TRANSACTION_NONE : false

86 SUPPORTS ISOLATION LEVEL TRANSACTION_READ_COMMITTED : true

87 SUPPORTS ISOLATION LEVEL TRANSACTION_READ_UNCOMMITTED : true

88 SUPPORTS ISOLATION LEVEL TRANSACTION_REPEATABLE_READ : true

89 SUPPORTS ISOLATION LEVEL TRANSACTION_SERIALIZABLE : true

90

91 [27/Jan/2011:14:21:19 +0900],[ntasserver.middleware.util.TimeScheduler]

92 INFOMATION 0,30:*:*:*:*:*

93

94 [27/Jan/2011:14:21:19 +0900],[ntasserver.middleware.util.TimeScheduler]

95 INFOMATION registed Time Scheduler(ntasserver.message.session.process.SessionProcess)

96

97 [27/Jan/2011:14:21:19 +0900],[ntasserver.middleware.handle.SessionHandler]

98 INFOMATION ********** START SESSION SERVER

99

100 [27/Jan/2011:14:21:19 +0900],[ntasserver.middleware.handle.BusinessHandler]

101 INFOMATION ********** START BUSINESS SERVER

102


104 INFOMATION newSocket : ntasserver_ASYNC

105


107 INFOMATION newSocket : ntasserver_ASYNC

108


110 INFOMATION SocketPool : connected -> ntasserver_ASYNC:100.100.100.19:1228

111


113 INFOMATION newSocket : ntasserver_SYNC

114


116 INFOMATION newSocket : ntasserver_SYNC

117


119 INFOMATION SocketPool : connected -> ntasserver_SYNC:100.100.100.19:1229

120


122 INFOMATION Connected Biz Async Pool : ntasserver(100.100.100.19:1228)

123


125 INFOMATION Connected Biz Sync Pool : ntasserver(100.100.100.19:1229)

126

127 [27/Jan/2011:14:21:20 +0900],[ntasserver.middleware.handle.ConnectionHandler]

128 INFOMATION Connection Async Port : 1212

129


131 INFOMATION Connection Sync Port : 1213

132


서버기동 및 종료


134 INFOMATION ************* START CONNECTION SERVER

135

136 [27/Jan/2011:14:21:21 +0900],[ntasserver.middleware.handle.WebHandler]

137 INFOMATION ********** START WEB SERVER

138


140 INFOMATION ******************** START ALL SERVERS ********************

141

START ALL SERVERS` 는 NTAS Server가 시작해서 서비스 가능하다는 뜻이다.

WARNING 이나 ERROR 가 없고, START ALL SERVERS 가 출력되었다면 정상

적으로 시작된 것이다.

3.2.2 NTAS System 종료

정상적인 서버 종료방법은

Window : %NTAS_SERVER_HOME%\bin\stopserver.exe

Unix/linux : $NTAS_SERVER_HOME/bin/stopserver.sh

위의 명령어를 사용하는 것이다.

가능하다면 명령어를 통해서 종료하는 것이 가장 안전한 방법이다.

Engine이 비즈니스로직을 수행하고 있거나, 특정한 경우에 계속 수행해야 하는

경우가 발생되었을 때 Daemon 은 30초 이상 Engine 이 종료되지 않았을 경우

에는 강제로 종료시킨다.



3.3 모니터링

3.3.1 NTAS Server에 접근

그림 3-1

처음 모니터링 시스템을 실행하면 그림 3-1과 같은 접속화면이 나타난다.

만일 접속윈도우에 등록된 서버의 정보가 없다면 접속윈도우의 버튼을 누

른다. 접속할 서버를 마우스로 선택을 하고 비밀번호를 입력하고 연결 버튼을

누르면 서버에 접속을 하게된다. 처음 접근할때의 아이디/비밀번호는 ntas/ntas

이다. 기본적인 아이디/비밀번호가 등록되어 있으므로 접속후에 사용자 정보관

리에서 추가 및 수정을 하면 된다.

3.3.2 전체 모니터링– Nodes

클러스터링으로 묶인 전체 서버를 나타내준다.

모니터링


그림 3-2

정상적인 서버상태이다. 현재 이서버 노드는 4개의 논리구조가 모두 동작중인

상태이다.

Node-1은 4가지 논리구조의 동작상태를 Animation으로 나타낸다.

Node-2는 Thread Pool의 Thread상태, Heap Memory 상태, Client Connect 상

태등을 각각 막대 그래프를 사용하여 백분율로 나타내고 있다.

Node-3은 데이터베이스 접속상태를 나타낸다. 푸른색은 접속상태가 정상적임을

나타내고 회색과 빨간색이 교차되면서 깜빡일때는 접속에 이상이 있다는 것을

의미한다. 그리고, DB접속은 DataSource기준으로 여러 개로 구분되서 관리되며,

이중에 하나라도 접속상태가 이상이 발생되면, 깜빡이게 된다.

데이터베이스 접속에 이상이 발생하여 데이터베이스를 복구하면 자동으로 접속

이 이루어 지게 되어있으므로 복구후 서버를 재기동 할 필요가 없다.

Node-4는 서버의 이름과 IP정보를 나타낸다. 만일 localhost, 127.0.0.1, 혹은

나타나지 않았을 경우에는 그 서버의 hosts를 수정하여 정확한 ip가 나타나도록

해야 한다.

그림 3-3

Nodes-1

Nodes-2

Nodes-3

Nodes-4



위 그림(그림3-4)은 MMConsole과 서버와의 접속이 단절되었음을 나타낸다. 따

라서 이럴경우에는 다시 접속을 시도해야 한다. 서버에 이상이 있는 경우도 있

으나 단지 서버와 접속만 단절 되어서 그런경우도 있으니 확인후 조치하기 바란

다.

이렇게 나타나는 경우는 여러 서버가 하나의 클러스터링으로 묶였을 경우에 나

타날 수 있다. 이전에 서버가 클러스터링으로 한번이라도 묶여진 경우가 있다면

서버상의 모니터링 정보에 그 기록이 남는다. 그런데 그 서버가 아직 정상적으

로 기동하지 않을 경우에 나타날 수 있는 현상이다. 만일 앞으로 클러스터링 그

룹에 넣지 않을 계획이라면 그 노드 정보를 삭제 하기 바란다. 삭제하지 않는다

면 계속적으로 나타나게 될 것이다. 삭제 방법은 그 노드에 마우스 오른쪽 버튼

을 누르면 Popup menu 나타나고 Delete Node를 선택하면 삭제가 된다. 여기서

의 삭제는 서버상에서 예전에 접속했던 정보만을 없애게 되는 것 뿐이다. 만일

다시 클러스터링 그룹에 추가를 할 경우에는 자동으로 다시 나타나게 되므로 클

러스터링 동작과는 아무런 관계가 없다 안심하고 삭제하기 바란다.

그림 3-4

그림3-6은 WEB이 정지상태로 나타나 있다. 이경우 이노드에 LEADER,

SES(Session), CON(Connection), DOM(Business)의 논리구조는

동작 중이지만, WEB은 논리구조에서 빠졌고, 동작하지 않는다는 의미이다.

모니터링


3.3.3 상세 모니터링

그림 3-5

상세 모니터링을 나타나게 하려면 노드 혹은 그래프에서 원하는 노드를 Double

Click하거나 오른쪽 마우스를 눌러서 Popup Menu를 나타나게 한 다음 ‘노드 상

세 모니터링 보기’을 선택하면 그림3-9 화면이 나타나게 된다.

시스템 상태 그래프

그림 3-6

Nodes 에서 Graphs와 같은 정보이다. 단지 상태정보 백분율로 긴 시간동안 표

현을 한 것이다.

데이터베이스 Connection 사용 상태 정보 그래프

그림 3-7



그림 3-8

그림 3-12

데이터베이스 Connection 사용 상태를 백분율로 그래프로 표현한 것이다. 데이

터소스의 개수 만큼 선이 나타나는데 각각의 선은 그림3-11의 선과 그림3-12

의 data source에 부여된 색상과 연관지어 관찰하면 된다.

그림 3-12는 등록된 데이터소스의 정보와 사용되고 있는 실시간 정보를 수치로

나타내고 있다.

서버정보

그림 3-9

Logical Structure 는 각각 논리구조가 활성화 되어있는지 여부를 나타낸다.

우측은 설정된 서비스 포트를 나타낸다. Connection 비동기, Connection 동기,

Tcp Distribution Servece 포트는, 만일 ssl 설정이 되어있다면 빨간색으로 표시

된다.

Connection 의 비동기포트 와 동기포트에 대한 정보를 표현하고 있다.

Data source별 자

동으로 부여된 색

상이다. 그림3-

11의 선색상과 연

관해서 관찰하라.

모니터링


스레드/메모리/NTAS연결의 정보를 을 수치로 실시간 관찰

그림 3-10

- Thread Pool에서 사용되어지고 있는 스레드의 사용 상태를 실시간 수치로 표

현

- 사용되어지고 있는 Heap Memory의 사용상태를 실시간 수치로 표현

- Connection 에 대한 Client의 접속 수를 실시간 수치로 표현

라이센스에 대한 표현

그림 3-11

텍스트 모니터링

그림 3-12

NTAS Server 라이센스

종류에 대한 표시

서버 Engine 에서 사용

할 수 있는 max

memory



그림 3-13

이것은 모든 클러스트된 모든 서버의 상태정보를 수치와 문자로 실시간으로 표

현하고 있다. 이자료는 옵션설정에 의해 MMConsole이 실행되고 있는 클라이언

트에 파일로 저장될 수도있다. 이자료를 기반으로 긴 시간동안의 상태를 다른

방법으로 표현할 수 있는 기초자료를 개발자에게 제공한다.

사용자 관리

그림 3-14

모니터링


그림 3-15

Mam을 사용해서 접근을 할 수 있는 사용자 정보를 관리하는 화면이다.

이 권한을 가지려면 권한이 사용자 관리자가 check되어야 한다.

사용자의 정보는 Distribution서버에 각각 정의 되어 있다. 클러스트된 서버중에

서 Leader가 2개 일경우 각각 사용자 정보를 따로 가지고 있다.

# 모니터링 사용자 – 서버의 상태를 관찰할 수 는 있으나 그 이외의 권한은 없

다.

# 시스템 관리자 – 주로 System Admin이 가지는 권한이다. 이 권한은 모니터

링 사용자의 권한을 같이 갖는다.

# 사용자 관리자 – 가장 최상위 권한이다. 이권한을 갖는 자는 모든 권한을 갖

게 된다.



옵션

그림 3-16

그림 3-17

옵션을 설정하는 기능이다.

# 다운로드 간격– 서버의 상태정보를 내려받는 간격을 설정한다.(초단위)

# 텍스트 모니터링 파일 – 그림3-18에서 표현되는 데이터를 지속적으로 보관해

모니터링


서 다른 자료로 참조할수 있다. 그자료를 보관할것인지 여부와 보관할 파일의

크기를 결정한다. 크기를 정확하게 말한다면 내려받는 상태정보를 몇건씩 묶어

서 파일로 보관할 것인가를 설정한다.

# 모니터링 색상– 그래프와 노드를 표현하는 색상을 결정할 수 있다.

# 노드 정렬– 여러 개의 노드가 클러스트된 경우 표현되는 순서를 정할 수 있

다. 하지만 이것을 쓰지않고, 노드가 표현된 곳에서 바로 Drag and Drop해서 표

현 위치/순서를 정할 수 있다.

메시지 테스터

그림 3-18

메시지 테스터는 NTAS Programming Guide에 이미 설명을 했으므로 그 내용에

대해서는 언급하지 않겠다. 메시지 테스터에 접근 하는 방법은 2가지가 존재한

다. 첫번째는 위와같이 Mam에서 접근하는 방법이 있으며, 두번째는 실행 스크

립트 파일을 직접 실행하는 방법이 있다.



3.4 속성설정

그림 3-19

속성 설정을 하기 위해서는 우선 속성을 변경하고자 하는 노드를 선택한 뒤에

위 그림과 같이 메뉴를 선택한다.

속성설정


3.4.1 Daemon 설정

그림 3-20

Daemon 프로세스는 NTAS Engine 프로세스를 관리하는 기능을 갖는다.

서버명

이 노드의 이름을 설정한다.

클러스터를 구성할 때 이 이름은 아주 중요하다.

만일 클러스터 그룹에서 이 명칭이 중복이 될 경우에는 오동작

을 일으키므로 주의해서 입력하도록 한다.

비동기 포트

동기 포트

Daemon 서비스를 제공하는 Port이다. MMConsole 은 이 포트

를 통해서 서비스를 제공 받는다.



Local IP 주소

Ntas 시스템이 동작중인 IP 노드의 IP를 입력한다. 이것은 입력

하지 않더라도 자동으로 IP를 인식하는 기능이 있으므로 입력할

필요가 없지만, 자신의 IP 를 인식하지 못할 경우나 혹은 여러

개의 IP 를 가지고 있는 시스템의 경우 특정한 IP 를 기본 IP로

설정하고자 할 경우에 입력된다.

Distribution IP 주소

Leader 에서 접속 IP를 클라이언트에게 넘길 때 사용되는 포트

이다. 클러스터는 내부네트워크로 구성되고, 클라이언트 서비스

는 인터넷과 같은 외부네트워크 으로 하고자 할 경우 이 값을

외부망 IP를 설정한다.

TCP Distribution Service

포트

접속할 서버의 정보를 서비스하는 포트를 지정한다.

Tcp Distribution

Service SSL 사용

TCP Distribution Service 포트 가 SSL로 지정하고자 할 경우 체

크한다. 아래의 KeyStore는 SSL 에 필요한 key/인증서 정보를

입력한다.

Java VM 옵션

NTAS Engine를 실행 하고자 할 때 사용되는 Java VM 옵션이다.

일반적인 Java VM 옵션을 기록하면 되고, 이후에 실행되는

NTAS Engine은 이 옵션에 영향을 받게 될 것이다.

Connection 서버 활성화

Business 서버 활성화

Session 서버 활성화

Web 서버 활성화

현재 이 노드의 NTAS Server가 실행될 때 활성화 될 논리구조를

설정한다.

클래스 새로고침

이것이 체크된 상태에서 Save 버튼을 누르게 되면 Ntas 서버의

ClassLoader 가 클래스를 재구성하게 되어 클래스들이 새롭게

적용된다.

속성설정


데이터베이스 새로고침

이것이 체크된 상태에서 Save 버튼을 누르게 되면 Ntas 서버의

DB Pool 이 Config 파일을 다시 읽어서 DB Pool 을 재구성하게

된다.

3.4.2 Main 설정

그림 3-21

초기 스레드 개수 NTAS Engine이 실행이 될 때 Thread Pool에서 확보할 Thread

의 초기 개수를 설정한다.

최대 스레드 개수

서버가 실행되면서 Thread 가 부족하게 될 경우에 Thread 를

추가로 생성하게 되는데 이때 최대 생성될 수 있는 Thread 개

수.

Thread 는 일정 주기로 관리를 하게 된다. 일정 시간동안 사용

되지 않는 Thread 는 해제가 되는데. 최소 초기 값은 유지가

된다.

로그 파일 보관일 로그 파일을 남기는 주기 일자



참조할 Leader 설정 전체 보기

그림 3-22

현재 이 NTAS Server가 참조해야할 Leader을 설정하는 화면이다.

이것은 클러스트를 구성할 때 복수개가 지정될 수 있다.

최소한 하나 이상은 선언이 되어야 하며, 자신이 Leader를 Active했다면 자신의

정보를 넣을 수 있다.

참조할 Leader의 세부 설정

그림 3-23

서버명 참조할 서버의 이름을 입력한다.

이 이름은 그림3-25에서와 같이 입력된 값과 일치하도록 한다.

IP 주소

참조할 Leader의 IP를 입력한다.

자신의 노드의 경우 loop back을 입력해도 무관하지만, 클러스터를

구성할 경우 혼돈을 줄 수 있으므로 정확한 IP를 주는게 좋은 방법이

다. Loop back이든 자신의 실 IP를 입력하든지 자신의 IP를 자동으로

인식을 하여 자신이면 네트웍으로 연결을 하지 않고 같은 프로세스

속성설정


에 존재하므로 객체 레퍼런스로 실행하게 된다.

비동기 포트

동기 포트

접근할 Leader 에서 서비스하는 Port

접근할 Leaer 에서 지정한 Port와 일치 시킨다.

참조할 Session 설정 전체 보기

그림 3-24

현재 이 NTAS Server가 참조해야할 Session을 설정하는 화면이다.


최소한 하나 이상은 선언이 되어야 하며, 자신이 Session을 Active했다면 자신

의 정보를 넣을 수 있다.

참조할 Session의 세부 설정

그림 3-25



Session명 참조할 서버의 이름을 입력한다.


Load Balance 비율 세션수행 가중치를 설정한다.

참조할 Business 설정 전체 보기

그림 3-26

현재 이 NTAS Server가 참조해야할 Business를 설정하는 화면이다.

이 값은 Connection이 참조하는 값이다.


속성설정


참조할 Business의 세부 설정

그림 3-27

Business명 참조할 서버의 이름을 입력한다.


Load Balance 비율

Business가 여러 노드에 설정되어 있다면 Connection이 비지니스로

직을 위임 할 때 그중 하나의 Business 에게 비즈니스로직을 위임하

는데 사용되는 기초 수치이다. 통상 백분율로서 지정을 하면 적절할

것이다.

즉 Load Balancing 처리를 하는데 필요한 가중치이다.



Data Source 설정 전체 보기

그림 3-28

현재 이 NTAS Server내에서 전체적으로 사용하게 될 Data Source를 설정하는

화면이다. 이것은 복수개가 지정될 수 있다.

DataSource의 세부 설정

그림 3-29

데이터소스명 Data Source 이름을 입력한다.

속성설정


설명 설명을 입력한다.

초기 개수 초기에 확보할 DB Connection 개수

최대 개수 최고 확보할 수 있는 DB Connection 개수

주소 접근할 DB의 url정보를 입력한다.

아이디/비밀번호 DB에 접근할 수 있는 사용자 정보를 입력한다.

드라이버 JDBC Driver를 입력한다.

Ping 간격 DB Connection 에 Ping 을 날려서 유효성 여부를 체크하는 주기(초

단위)

Ping Query

DB Connection 유효성 체크시 select 문장을 이용하여 Ping 체크할

경우, DB상에 존재하는 table, view 을 select 하는 문장을 넣는다.

여기에 값이 없으면 Query 로 수행하지 않는다.

Timeout Minute 사

용

비즈니스 로직이 수행할 때 DB Connection을 얻어서 수행후 반납을

하게 되는데, Connection을 얻은 시점부터 시간을 체크하여 반납하

지 않은 Connection을 강제로 수거해 가는 시간을 분 단위로 설정하

게 된다.(분단위)

최대 대기 시간 비즈니스 로직이 수행할 때 DB Connection을 요청하게 되는데, 이때

Connection을 얻기 위해 기다리는 최대 시간을 설정한다.(초단위)



3.4.3 Business 설정

그림 3-30

서버측 비즈니스 로직을 수동으로 등록하는 기능이다. 이기능은 MMConsole 의 배포 기능

을 사용하면 이 화면에 자동으로 등록되며, 여기서 수동으로 등록할 필요는 없으며, 등록된

비즈니스 프로세스를 확인하는 용도로 사용된다.

패키지명 패키지명을 입력한다.

프로세스명 프로세스 모듈 이름을 입력한다.

설명 이 모듈에 대한 설명을 입력한다.

프로토콜 번호 ~Message.java에 있는 실제 Protocol 번호를 입력한다.

격리레벨 격리 수준을 선택한다. 이것은 java.sql.Connection 인터페이스 스펙

속성설정


에 대한 내용이며, Connection인터페이스의 문서를 참조하기 바란다.

선택하지 않을경우는 기본값(TRANSACTION_READ_COMMITTED)을

갖는다

트랜젝션

Ntas 는 자체적으로 트랜잭션을 관리해 주는 기능이 있으며, 적절한

트랜잭션 값을 설정한다.

TX_USER_MANAGED

- 개발자가 직접 트랜잭션을 관리하도록 하는 설정값이며 , 이값으

로 설정되었을 경우에는 개발자가 직접 COMMIT, ROLLBACK 를 조

절해 주어야 한다. 하지만 개발자가 주지 않더라도 최종적으로 Ntas

Container 로 제어가 넘어오게 되면 Commit 처리가 된다. 또한

Exception 이나 GeneralContext 에 rollback 이 설정되어 있다면

Rollback 이 된다.

TX_CONTAINER_MANAGED

- Ntas Container 에서 자동으로 트랜잭션을 관리하도록한다. 이것

은 Two Phase Commit 과 같은 복잡한 트랙잭션을 처리할 경우에

매우 유용하며 개발자가 코드상에서 Commit 혹은 Rollback 처리를

할 수 없다.

프로세스 실행 시간

Time Schedule을 설정하는 부분이다. 일정시간마다 주기적/자동적으

로 이 프로세스 모듈을 실행하고자 할 경우에 설정한다. 만일 등록

패턴이 일치하지 않을 경우에는 실행되지 않는다. 우측에 도움말 버

튼을 이용해서 도움말을 참조하기 바란다. 또한 우측에 Time

Schedule Wizard가 있으니 그것을 이용할 수도 있다.

Time Schedlue에 의해서 호출될 때는 프로세스 모듈의 execute()메

소드가 호출이 된다. 이때 첫번째 파라메타인 BaseMessage는 null값

임을 명심하라.

그리고, 다른 프로세스 모듈과 마찬가지로 일반적인 호출에도 동작을

한다. 그때는 동작 패턴이 일반적인 패턴과 동일하다.

초기 파라메터 리스

트

프로세스 모듈(~Process)은 서버가 초기화 될 때 오직 한번만 객체

생성이 된다. 이때 init()메소드가 한번 호출이 되는데, 이때 이값이

전달이 된다.



3.4.4 Connection 설정

그림 3-31

소켓 체크-주기 클라이언트 접속 유효성 여부를 체크하는 주기를 설정한다.(초단위)

소켓 체크-간격 Ntp 프로토콜은 내부적으로 패킷을 주기적으로 전송하여 유효성을

지속적으로 확인한다. 이때 특정 시간동안 패킷이 전송되지 않았을

경우는 잘못된 접속으로 판단하는데 그 시간을 설정한다.(초단위)

속성설정


동기 정보

포트 동기 통신포트

TCP No Delay TCP/IP 의 TCP_NO_DELAY 옵션으로써 패킷을 전송시 Delay 여부를

설정한다.

Send Buffer Size

Per Socket

Receive Buffer Size

Per Socket

소켓의 송수신 스트림에 할당되는 버퍼크기

Connection Max

Packet Size

클라이언트가 서버에 전송하는 데이터 패킷의 최대 크기를 설정한다.

이는 클라이언트가 해킹의 목적으로 대량의 패킷 전송을 방지하기

위한 것이다.

동기 SSL 사용 SSL로 지정하고자 할 경우 체크한다. 아래의 KeyStore는 SSL 에 필

요한 key/인증서 정보를 입력한다.

비동기 정보

소켓 Manage 타입 Client가 접근하는 소켓의 관리방식을 설정하는 항목이다.

- Multiplexing 방식

- One Thread One Socket 방식

Multiplexing 방식은 하나의 Thread가 여러개의 Socket이벤트를 처리

할 수 있는 기법을 말한다.. 따라서 하나의 Connection 에서 많은

수의 Client 접속을 처리할 수 있는 방식을 말한다.

One Thread One Socket 방식은 하나의 Thread가 하나의 Socket을

관리하는 방식을 말한다. 이는 일반 기업용 어플리케이션을 개발할

때 주로 사용하며, 용량이 큰 메시지 데이터를 주고 받을때 적합하

다. Multiplexing은 많은 사용자가 접근을 할 수 있으며, 주로 적은



양의 메시지를 주고 받을 때 적합하다. 이 두가지 특성을 고려하여

업무에 맞게 적절하게 설정을 하면 된다.

소켓 Channel 크기 Multiplexing 으로 설정하였을 경우 하나의 Thread 가 관리하는

Socket 개수를 설정한다.

포트 비동기 통신포트

TCP No Delay TCP/IP 의 TCP_NO_DELAY 옵션으로써 패킷을 전송시 Delay 여부를

설정한다.

Send Buffer Size

Per Socket

Receive Buffer Size

Per Socket

소켓의 송수신 스트림에 할당되는 버퍼크기

Connection Max

Packet Size

클라이언트가 서버에 전송하는 데이터 패킷의 최대 크기를 설정한다.

이는 클라이언트가 해킹의 목적으로 대량의 패킷 전송을 방지하기

위한 것이다.

비동기 SSL 사용 SSL로 지정하고자 할 경우 체크한다. 아래의 KeyStore는 SSL 에 필

요한 key/인증서 정보를 입력한다.

개요

전문적인 Admin 4-45

CHAPTER 4 전문적인 Admin

4.1 개요

‘기초적인 Admin’에서는 MMConsole 에서 UI기반의 Admin을 기준으로 설명을

했다. 이번 장에서는 좀더 깊이 들어가서 시스템을 이해하고 문제가 발생했을

때 대처하는 수준을 한단계 높일 수 있는 능력과 응용능력을 높일 수 있는 장이

될 것이다.

여러대의 노드로 클러스트된 서버를 기준으로 속성설정 방법을 설명한다.

4.2 서버 디렉토리 구조

디렉토리 구조는 모든 Platform에 동일하게 적용이 되며 그 구조는 다음과 같다.

설치디렉토리 ntas를 기준으로 ntasclient와 ntasserver가 각각 설치가 된다.

ntasclient

MMConsole, PSDT, Message Tester등이 동작되기 위하여 존재하는 클라이언트 디렉토리

- bin 실행파일/스크립트 파일이 존재하는 디렉토리

- classes client Message Test가 실행이 될 때 테스트를 하기 위한 Message class들이 이

안으로 들어간다. 직접 복사해 넣을 수도 있지만, MMConsole에서 서버로 Deploy할 때

Message class들은 이 안으로 자동 복사가 된다.


4-46 전문적인 Admin

위와 같이 Sync Classes 메뉴를 이용하여 서버에 배포되어 있는 Message를 내려 받을 수

이다.

- config 환경변수가 들어 있는 디렉토리

- lib client가 실행하는 데 필요한 클래스 라이브러리들이 들어있는 디렉토리

- lib/ext client가 실행하는 데 필요한 외부 클래스 라이브러리들이 들어 있는 디렉토리

- logs log파일들이 들어 있는 디렉토리

- resources 각종 resource들이 들어 있는 디렉토리. 특이 이 디렉토리에는 PSDT Tool 이

사용하는 skeleton파일이 들어 있다

ntasserver

서버 제품군이 동작되기 위하여 존재하는 디렉토리

- applications 처음 설치를 하면 이 디렉토리는 sample class 이외에는 아무것도 없다 이

디렉토리는 NTAS System 기반에서 개발되어서 서비스를 하기 위한 비즈니스 어플리케이션

이 존재하는 디렉토리이다. 특히 MMConsole에서 Deploy되는 모든 class, library, resource

는 자동으로 이 디렉토리 아래에 복사가 된다.

- applications/classes class 주로 business class들 이 안으로 들어가게 된다.

Mam에서 deploy시에 class 영역에 들어가는 모든 내용은 여기로 들어간다. 압축된 내용은

압축이 해제된 다음에 이 디렉토리에 복사가 된다.

- applications/lib Mam에서 deploy시에 library 영역으로 올렸을 경우에는 그 내용 그대로

가 이 영역으로 들어간다. 서버가 재기동 할 때는 모든 class library들은 classpath에 자동

으로 설정이 된다.

- applications/resources 단지 리소스를 보관하는 디렉토리이다. MMConsole에서 deploy할

때 resource영역에 있는 모든 내용은 이 디렉토리에 들어 가게 된다.

Client가 Connection에게 접근하는 방법


서버측 프로그램에서 이 resource에 접근을 하기 위해서는 환경속성에서

$NTAS_SERVER_HOME/applications/resources 이렇게 접근할 수 있다.

- bin 서버측 실행 및 종료 스크립트가 존재한다.

- config 서버측의 환경파일이 존재한다.

- lib server가 실행하는 데 필요한 클래스 라이브러리들이 들어있는 디렉토리

- lib/ext server가 실행하는 데 필요한 외부 클래스 라이브러리들이 들어 있는 디렉토리

- logs 서버가 동작하면서 생산되는 log 파일등이 들어 있는 디렉토리

- resources 서버 구동을 위하여 필요한 각종 resource들이 들어 있는 디렉토리.

4.3 Client가 Connection에게 접근하는 방법

그림 4-1

클러스터링 구조에서 Connection이 2개 이상으로 구성되어 있다면, client가

Connection에 접근하는 방식은 Leader 의 수집된 정보에 의해서 Connection으

로 접근을 하게 된다. Client library에는 이러한 기능을 수행하는 라이브러리가

존재하므로 그 기능을 사용할 수 있다.

현재는 클러스터링 구조가 아니더라도 차후에 증설이 예상된다면 위와 같은 방

법으로 구현을 하는 것이 맞다. 그리고 특정한 서버에 직접 접근하는 라이브러

리도 존재한다. 구체적인 라이브러리에 대해서는 NTAS Programming Guide를

참조하라.



4.4 Message와 Process의 동작원리

4.4.1 하나의 노드에서 처리 될 때

그림 4-2

하나의 노드에서는 각각 논리구조들은 네트웍으로 메시지를 주고 받지않는다.

서로 옆에 있는 메소드를 호출하듯이 객체의 Reference를 주고 받으면서 서로

협동을 한다. 위의 구조에서 A 라는 Message를 Client가 보냈을 때

Connection은 Business로 보내서 처리를 위임하게 된다. 주의할 점은 Async

Message와 Process의 동작원리


Port의 경우 Client에 메시지를 보낼 때 프로세스 모듈에서 리턴값이 null이라면

메시지를 보내지 않는다. 따라서 Client 어플리케이션을 개발할 때 서버상의 프

로세스 모듈의 리턴값이 있는지 없는지를 확실히 알아야 한다. 예를들어 Client

라이브러리 기능중에 call 이라는 명칭의 메소드를 지원하는 기능이 있는데 이러

한 메소드들은 메시지를 보내면 받드시 리턴값이 있다는 가정에서 사용하는 메

소드이다. 이는 주로 Sync Port 로 접근한다는 가정이다. 하지만 서버측에서 리

턴 메시지를 보낼 경우도 있고, 어떠한 경우에는 보내지 않는 경우가 있다면 그

것은 Client 어플리케이션이 이상하게 동작될 수도 있다. 이러한 상황을 잘 이해

하기 바란다.

참고적으로 Session과의 통신은 다른 논리구조와 는 패턴이 약간 다르다 내부

적으로 항상 리턴값이 존재한다. Null 일경우에 이에 해당하는 값을 미들웨어 내

부적으로 메시지를 만들어 사용하고 있다. 따라서 Session에서 작성되는 프로세

스 모듈의 경우에는 null을 리턴하더라도 로직상에 문제는 전혀 없다. 단지 그

이외에 논리구조에서는 반드시 null 을 리턴하는지 혹은 리턴 Message값이 있

는지 혹은 리턴하는 패턴이 일정한지를 꼭 분석하기 바란다.

4.4.2 클러스터링 구조에서 메시지 처리 패턴

그림 4-3

위의 구조는 Connection에 Domain이 같이 존재한다. 그림에서는 Push메시지를

예를 들어 설명했지만 일반적인 Request/Response구조에서도 부하분산의 문제



는 없다.

위에서 처리되는 설명을 풀이하겠다. 우선 Connection이 메시지를 받게 된다면

자신에게 해당되는 프로세스 모듈이 존재하는지를 확인한다.

만일 존재한다면

여기서는 Push를 예로 들었기 때문에, 비즈니스를 처리하고, Client 2에게 결과

로써 메시지를 전달하고자 한다. 비즈니스가 처리되고 나서부터는 Business에게

Push를 요청을 하게 된다. Domain은 Client 2가 접속해 있는 Connection을 찾

아서 Push를 던지게 되고 그 Connection은 해당하는 Client 2에게 메시지를 던

지게 된다.

만일 존재하지 않는다면

비즈니스로직을 당연히 같은 노드에 있는 Business에게 위임을 할 것이다. 비즈

니스로직은 Business에서 처리가 되고 그 결과를 Client2가 접속해 있는

Connection에게 던질 것이고, 그 Connection역시 해당하는 Client 2에게 push

메시지를 던지게 된다.

한가지 의문이 있을 수 있다. ‘Business 1이 Client 2 가 어느 Connection에 접

속해 있는지 어떻게 알까 ?’ 그것은 NTAS System 내부 알고리즘에 의해 가능

하다는 것으로만 이해하고 넘어가자.

그림 4-4

Ntas의 Thread Pool 관리 메커니즘


이 경우에는 프로세스 모듈을 적절하게 배치하는 것이 중요하다. Connection 1

에서 요청을 받아서 Business 로 위임을 하는데 Connection 1이 위치한 노드에

는 Business 가 없으므로 클러스트된 외부 노드에 Business 를 찾게 될 것이다.

이때 2대 이상의 노드에 Business 가 존재하므로 Business를 위임하기에 적절

한 Business 를 찾기위해 계산을 할것이다. 여기서 적절한 Business 를 찾기위

한 계산의 기초자료는 ‘3-4-2 Main 설정 중에서 참조할 Business 의 세부 설

정’의 그림3-32에 나와 있듯이 Load Balance Rate가 있는데 그 값을 기초자료

로 활용되고 있다.

4.5 Ntas의 Thread Pool 관리 메커니즘

NTAS System은 Thread Pool을 활용해서 Thread의 자원을 재활용을 극대화 하

고 있다.

그림 4-5

하나의 노드에는 4가지의 논리구조가 존재할 수도 있고 하나의 논리구조를 가질

수 있다 하지만 이들 논리구조는 각기 다른 프로세스가 아니다. 말 그대로 단지

하는 역할에 따라서 논리적으로 구분을 했을 뿐이다. 한 노드에 논리구조를 모

두 가지고 있다고 하더라도 하나의 프로세스에서 동작이 되며 이들의 처리 하는

Thread는 개별적으로 획득하는 것이 아니라 프로세스 자체가 관리하고 있는

Thread Pool을 공유하도록 하고 있다. 이것은 하나의 프로세스에서도 Thread를

따로 관리한다면 반드시 잉여분이 생기게 될것이다. 왜냐하면 당연히 모자라게

되면 서비스에 이상이 발생되기 때문에 반드시 남으면 남았지 모자라게 설정을



하지 않을 것이다. 처리 역할에 따라서 Thread를 관리하게 되면 당연히 낭비가

되는 것은 당연한 것이다. NTAS System은 Thread자원의 효율을 극대화 하기위

하여 Process내의 모든 Thread 사용을 Thread Pool을 이용하도록 설계되어 있

다.

4.6 Time Scheduler 의 메커니즘

이기능은 유닉스의 crontab과 유사한 기능이다.

이기능은 Client 요청이 없더라도 일정 주기마다 실행을 하도록 프로세스 모듈

에 정의한다. 물론 프로세스 모듈을 정의 했기 때문에 Client요청에 의해서 처리

될 수도 있다. 주의 할 점은 스케쥴에 의해서 프로세스 모듈이 호출될 경우는

execute()의 첫번째 파라메타인 BaseMessage 타입이 null이라는 것이다. 코드

를 작성할 때 이점을 유의해야 하며, Client 에의해서 호출된 경우에는 클라이언

트가 보낸 메시지가 BaseMessage 파라메타에 들어간다. 일반적인 호출과 동일

하다는 말이다.

이기능을 사용하는 경우는 특정한 날에 주기적으로 실행을 하고자 할 경우에 이

기능을 사용하게 되는데, 주로 주기적인 결산이라든지, 몇초 주기로 데이터를

검색해서 Client에게 Push를 보내야 할경우라든지 활용의 경우는 많이 있다.

Time Schedule을 설정하는 방법에는 두가지가 있다. 직접입력방법과 Wizard를

통해서 간단하게 입력하는 방법이 있는데, 직접입력방법은 실수 할 수 있는 여

지가 있으므로 복잡한 Schedule이외에는 Wizard를 사용하는게 좋을 것이다.

클러스터 성능의 한계


그림 4-6 Time Schedule Wizard

Wizard는 단지 원하는 시간을 지정만 하면 된다. 아주 단순할 것이다. 항상(*)는

‘매’ 라는 의미를 가지고 있다. 즉 초의 경우에 ‘매초’마다 라는 의미이다. 그리

고 일, 달 과 주는 서로 섞여서 지정할 수 가 없다. 일, 달이 입력되고 주를 입

력하게 되면, 일, 달에서 입력된 내용은 무효가 되어 버린다. 이점 참조하기 바

란다.

직접입력 방법은 다음과 같다.

총 6개의 구분이 있다. 각 구분은 ‘:’ 으로 구분되며 구분자 내에는 스케줄정보

를 입력하게 된다. 수치 이외에 입력될 수 있는 문자는 ‘,’, ‘-‘ 가 있다. ‘,’ 한

번 이상 입력할 때 콤마로 구분해서 복수개로 지정을 할 때 사용된다. ‘-‘는 범

위를 설정하고자 할 경우에 사용이 된다. 예를 들어 5일부터 10일까지 매일 실

행을 하고자 한 다면 5,,6,7,8,9,10과 같이 입력할 수 도 있지만, 계속적으로 연

결이 되어 있기 때문에 5-10 과 같이 범위를 지정하는 것이 훨씬 간단할 것이

다. *의 의미는 시간을 예로들어서 0-23과 동일한 의미이다. 각각의 값은 아래

표를 참조하기 바란다.

초 0-59

분 0-59

시간 0-23

일 1-31

월 0 -11 ( 0 = 1 월., 11=12 월.)

요일 1 -7 ( 1 = 일요일, 7 = 토요일)

월 중 일의 경우는 28 의 경우와 29, 30, 혹은 31 등의 각각의 월에 따라서 달

라질 수 있다. 이경우에 매월 말일로 지정을 하고 싶다면 31로 지정을 하면 된

다. 만일 31일로 지정을 했는데 2월에 28일 까지 밖에 없을 경우에는 말일인

28일에 스케줄이 작동을 해서 프로세스 모듈을 수행하게 된다.

4.7 클러스터 성능의 한계

NTAS System의 클러스트 방식은 부하분산/고가용성 클러스트를 지원한다.

클러스터는 여러 대의 컴퓨터들이 마치 1대의 컴퓨터처럼 작동하면서 고도의 신



뢰성을 제공한다. 이 방식을 사용하면 서버, 상호접속장치, 저장장치, 제어기,

어댑터 등이 복수로 작동하기 때문에 시스템의 신뢰성이 높아진다. 다시 말해

각 구성요소가 중복되어 있기 때문에, 어느 부분이 고장이 나도(하드웨어나 소

프트웨어를 막론하고) 다른 부문은 계속 작동하기 때문에 시스템이 멈추는 일은

없다. 이것을 고가용성의 효과로 보면되겠다. 또한가지는 여러 개의 컴퓨터가

일을 분산해서 처리하기 때문에 높은 성능을 낼수 있다. 즉 부하분산에 의한 효

과를 누릴수 있는것이다. 높은 성능을 내는 것은 클러스터링보다는 슈퍼컴퓨터

를 쓰는게 좋겠지만, 성능대비 가격은 거의 천문학적인 차이를 보인다. 따라서

적은 비용으로 성능과 안정성의 효과를 누리는 방법은 클러스터링을 이용하는게

효율적이라고 할 수 있다.

클러스터를 구축한다고 해서 서버증설에 따라서 무한대로 그 효과를 누릴수 있

는 것은 아니다. 클러스터링은 하드웨어의 버스 대신에 빠른 네트웍을 이용해서

구성된다. 따라서 클러스터링의 한계는 내부 네트워크의 한계와 밀접한 관련성

이 있다. 클러스터링의 기본 개념과 다른 또한가지 한계는 지적한다면 데이터베

이스 시스템의 한계이다. 이것은 데이터베이스 Access 많은 시스템의 경우이긴

하지만, NTAS System에서 최적화된 클러스터링을 제공한다고 하더라도 데이베

이스 시스템에서 제대로 성능을 발휘하지 못한다면 모든 클러스터링 노드들이

데이터베이스 Access에서 병목현상이 발생이 될 것이다. 다른 모든 미들웨어가

마찬가지지만, 데이터베이스의 성능 제공은 필수적으로 필요하다. 데이터베이스

의 성능을 높이기 위한 방법의 한가지로 Two Phase를 이용할 수 있는데 그것은

서로 관련성이 없는 테이블을 분리해서 각각 다른 데이터베이스에 적재를 하는

데이터베이스의 분산을 이용할 수도 있다.

4.8 데이터베이스 관리 메커니즘

NTAS System은 java 로 구현되어 있다. 따라서 데이터베이스를 접근하는 방법

은 모두 Jdbc Driver를 통해서 접근을 하게 되며, 각각 데이터베이스에서 제공

하는 Jdbc를 기반으로 NTAS System 내부적으로 jdbc를 재 구현해 놓았다. 일

차적으로는 데이터베이스 밴더에서 제공하는 Jdbc가 반드시 필요하다.

4.8.1 Database Pool

NTAS System은 DB Connection Pool을 관리한다.

데이터베이스에 하나의 Connection은 내부적으로 아주 복잡한 매커니즘을 갖고

있다. 즉 하나의 Connection을 시도하고 연결하기까지는 많은 리소스와 성능에

데이터베이스 관리 메커니즘


영향을 미친다는 것이다. 그래서 데이터베이스에 접근고자 할경우마다

Connection을 맺고 사용후에 다시 close를 하게 된다면 데이터베이스 시스템에

큰 무리를 주는 결과가 될 것이다. 물론 접속횟수가 많지 않다면 부담이 없겠지

만, NTAS System과 같이 많은 Client를 기준으로 설계된 시스템에서는 그러한

방법은 불가능하다. 이러한 문제를 해결하기 위해 Database Pool을 사용하는

것이다.

Pool은 미리 DB Connection을 필요한 만큼 연결을 해놓고, 접속을 계속 유지시

켜 놓는다. DB 처리가 필요할 경우 Pool에서 connection을 가져와서 처리후 다

시 pool에 반납한다. 반납된 이 connection은 또다시 다른 곳에서 사용이 된다.

즉 필요한 만큼의 connection 확보 및 유지와 connection을 재활용하는 메커니

즘으로 해석하면 되겠다.

4.8.2 리소스 관리

java는 리소스 관리가 필요가 없다고 한다. 즉 필요한 만큼 사용을 하고난 다음

에 지나가면 gabage collector가 알아서 리소스를 메모리에서 해제를 해주기 때

문이다. 하지만 database에 관련된 리소스 관리는 java 에서 말하는 그러한 리

소스 관리와는 차이가 있다

개발자가 프로그램 개발시에 ‘4.8.1 Database Pool’ 에서 언급을 했듯이

Connection은 한번 사용하고 버리는 것이 아니기 때문이다. 그래서 Connection

과 관련된 statement들도 리소스에 영향을 주게 된다. 실제 프로젝트에서도 이

문제 때문에 골치를 앓은 경험이 있을 것이다. pool에서 Connection 가져와서

사용후에는 반드시 반납을 해야한다. 그렇지 않고 사용한뒤 그냥 둔다면 나중에

pool에는 connection이 하나도 남지 않게 될 것이다. 일반적으로 다른 미들웨어

에서도 이러한 문제를 해결하기 위해 나름대로의 정책을 정해서 구현을 하고 있

지만, 밴더마다 조금씩 다르게 구현되어 있다.

NTAS System 에서의 정책은 사용자가 리소스에 전혀 고려하지 않도록 하는 것

으로 되어 있다. 즉 Connection을 얻어와서 statement를 만들고, 데이터베이스

처리를 한후 close나 다른 리소스 해제/반납에 대한 구현을 전혀 할 필요가 없

다는 것이다. 이 소스 해제/반납에 대해서는 NTAS System내부에서 자동으로 관

리를 해주게 된다.

4.8.3 Two Phase Commit

이기능의 활용목적은



1. 이미 분리되어 있는 DB의 데이터를 접근하게 될경우 각각의 DB Update를

하나의 Transaction으로 바라보게 하기 위한 목적이다.

2. DB의 부하분산을 목적으로 관련성이 없는 테이블을 물리적으로 분리된 DB

에 각각 배치해서 처리 부하를 경감시키기고 또한 이때 분리된 DB에 각각

Update를 했을경우 하나의 Transaction으로 바라보게 하기 위한 목적이다.

Two Phase Commit은 위의 경우에 사용된다. 하지만, 이 행위는 NTAS System

내부적으로 행해지므로 개발자는 이러한 행위에 대한 지시를 전혀 할 필요가 없

다. 단지 data source를 통해 데이터베이스를 사용하면 된다.

4.9 세션관리 메커니즘

논리적 Session의 기능은 기본적인 Client 세션기능과 사용자 정의 기능 2가지

로 크게 구분될 수 있다. Client 세션기능은 기본 기능으로 이미 구현이 되어 있

다. 이기능은 Servlet과 같은 Session기능과 동일 하다. Client별로 임시 저장데

이타를 관리하는 기능이며, attribute를 넣고 빼는 기능이다. 프로그램적으로 접

근하는 기능은 Programming Guide를 참조하라. 또한가지의 기능도 사용자 정

의 세션기능인데, 비즈니스로직을 구현하는 방법과 유사하게 구현하면 된다.

administration guide스를 관리하는 daemon 프로세스와 서비스를 담당하는 ntas engine...

Documents