모차세대 시스템의 WAS 아키텍쳐 Blue Print

OO 차세대 시스템

WAS Architecture Blue Print (DRAFT)  

2009-06-28

Oracle Korea Consulting

Principal Consultant

Byungwook Cho (byungwook.cho@oracle.com)

 

 

Overview

본 아키텍쳐는 OO 차세대 시스템을 위한 웹로직 구성 아키텍쳐이다. OO 아키텍쳐 요구 사항에 따라서 구성한 아키텍쳐로 다음과 같은 전제 조건을 기반으로 한다. Ÿ          웹로직을 중심으로 설계할것           클라이언트는 웹이 아닌 윈도우 애플리케이션을 사용한다.

   약 100개의 웹로직 인스턴스가 동시 운영 될것으로 예측된다.         총 업무는 A업무 (4개), B관리 (4개), C관리 (4개) 로 구성된다.Ÿ          하드웨어는 IBM P6 시리즈를 사용하며, 총 예상 CPU수는 52장이며, 하드웨어 가상화 기능을 제공한다. 

Architecture Principals

본 아키텍쳐의 설계 기본 원칙은 다음과 같다.

1. 안정성

장애가 발생하였을 때도 장애 업무 이외의 업무는 정상적인 수행이 가능해야 하며 타 업무로 그 영향을 전파해서는 안된다.

2. 확장성

비즈니스 상황에 따라서, 전체 시스템의 용량 (동시 사용자수)나 기능 (서비스 수)를 아키텍쳐의 변화 없이 쉽게 확장할 수 있어야 한다.

3.유연성

비즈니스 변화에 대해서 유연하게 대처할 수 있어야 한다.

 

Conceptual Architecture

위의 세가지 Principal을 기반으로 설계된 Conceptual Architecture는 다음과 같다.

Application Grid

애플리케이션 그리드의 개념은 여러 개의 하드웨어를 모아서 비즈니스 로직을 제공하는 단일된 형태의 애플리케이션 집합체이다. 외부에서 보기에는 하나의 애플리케이션 집합체로 보이며 단일 접속점 (End Point)을 가지지만 실제로 내부에는 여러 개의 애플리케이션이 분리된 하드웨어에 분리된 형태로 배포되어 있다.

 하드웨어 가상화 개념을 응용하여 그리드 내부에서 업무의 비중과 중요도에 따라서 하드웨어 자원을 동적으로 재 배정하여 자원 사용의 효율성을 극대화 한다.

 새로운 기능이 추가될 때 마다 컴포넌트를 애플리케이션 그리드에 꼽는 (PLUG IN)하는 개념으로 비즈니스 컴포넌트를 추가할 수 있으며, 애플리케이션 그리드의 Infrastructure에는 그리드를 관리하기 위한 운영,관리,모니터링 기능(이하 OAM) 이 구현되어 있기 때문에, 개발자는 비즈니스 로직에만 집중하여 개발한후 그리드에 배포하면 OAM은 Infrastructure에 의해서 관리된다.

 

애플리케이션 그리드 아키텍쳐는 계층에 따라서 하드웨어/미들웨어(웹로직)/웹서버 3개의 계층으로 나뉘어서 분리된다.

 

(1)   하드웨어 아키텍쳐

하드웨어는 IBM AIX 중에 가상화를 지원하는 하드웨어를 사용한다. 가상화는 하나의 하드웨어내에 있는 여러개의 CPU와 메모리를 분할하여 사용할 수 있는 기능이다. 즉 하나의 하드웨어 자원을 조각으로 나누어서 업무별로 할당이 가능하다.

 

하드웨어 아키텍쳐 구성시에, 작은 하드웨어 여러 개를 사용하는 것보다, 가상화가 가능한 큰 하드웨어를 사용하는 것이 유리하다. 일반적인 국내 차세대 시스템의 경우 오픈후에, 안정화 기간을 거치면 통상적으로 CPU 평균 사용률이 40% 이하로 제대로 구성된 아키텍쳐에서는 20~30%대로 사용되는 경우가 많다. 반대로 부하가 몰리는 서버의 경우 CPU 사용률이 70~80%까지 육박하는 경우도 있다. 이러한 경우, CPU나 메모리 자원에 대한 효율적인 분할을 하기 위해서는 하드웨어를 물리적으로 옮겨서 새로 소프트웨어 시스템을 설치해야 하는데, 이 과정은 많은 시간과 검증 작업을 요구하며 또한 소프트웨어 라이센스 측면에서 문제를 유발할 수 있다. (하드웨어 추가는 소프트웨어 라이센스의 추가 구매를 의미한다.)

 이런 비효율성은 반대로 가상화를 지원하는 하드웨어를 사용했을 때 쉽게 해결된다.  업무의 부하량에 따라서 동적으로 CPU 자원을 재할당 하여 업무 부하에 적절하게 대응할 수 있고 CPU 재할당의 경우에도 별도의 하드웨어 작업(CPU를 빼서 다른 서버에 옮기는등의)이 없이 소프트웨어적인 설정만으로도 가능하기 때문에, 변경에 대한 영향도를 최소화 할 수 있다.

 

(2)   웹로직 구성 아키텍쳐

웹로직 구성상에 있어서는 다음과 같은 원칙을 따른다.

업무당 하나의 웹로직 도메인을 사용하며,하나의 도메인은 여러 개의 클러스터를 가질 수 있으며, 각 클러스터는 여러 개의 Managed Server로 구성된다. 각 Managed Server에는 1개 이상의 업무 애플리케이션이 배포될 수 있다.

 

1) 서버 분리를 통한 장애 전파성 제거

자바 기반의 장애 특성은 턱시도와 같은 TP Monitor와 다르게 모든 업무가 하나의 프로세스에서 돌아가는 특징을 가지고 있다. 이로 인해서 장애가 발생할 경우, 같은 프로세스에서 돌고 있는 다른 업무에도 영향을 줄 수 있다. (TP Monitor의 경우 업무별-SERVER로 프로세스가 나뉘어져서 기동되기 때문에 장애가 다른 업무에 전파되지 않고 국지화될 수 있는 장점을 가지고 있다.) 이와 같은 문제를 해결하기 위해서 WAS에서 여러가지 Work Manager나 Thread Pool 분리와 같은 여러가지 기능을 제공하는데, 이 역시도, 메모리 과사용이나 CPU 과 사용등에 대한 문제에서는 자유로울 수 없다.

 

가장 올바른 아키텍쳐 설계 방안은 TP Monitor와 같은 원리로, 업무별로 Manager Server를 분리하여 장애시 타 업무에 대한 장애 전파성을 제거하는 것이다.

 

2) 관리 포인트 증가에 대한 해결 방법

단 Managed Server를 업무별로 분할하여 운영할 경우, 그 만큼 많은 Managed Server가 운영되게 되고, 이는 관리 포인트의 증가로 귀결된다. 이런 관리상의 문제점을 해결하기 위해서, 웹로직을 클러스터링 기능을 사용할 수 있다. 클러스터링에서는 여러 개의 Managed Server가 있더라도 클러스터 단위로 configuration을 반영할 수 있는 기능이 있기 때문에, Managed Server의 수가 증가하더라도 실제로는 클러스터의 단위로 관리를 할 수 있기 때문에 관리에서 오는 복잡도를 감소 시킬 수 있다.

 

3) 클라이언트를 통한 상태 관리

업무별로 Managed Server를 나누는 경우 발생하는 문제점중의 하나가 Managed Server간에 Session이나 상태 정보가 공유가 안되는 문제점을 가지고 있다. 그러나 고객의 아키텍쳐 설계의 Assumption은 윈도우 클라이언트 기반의 Rich Client를 사용하기 때문에, 상태나 사용자 정보를 클라이언트에서 관리하도록 설계하여 서버간의 정보 공유를 서버에서 클라이언트로 이관함으로써 이를 극복할 수 있다.

 

(3)   웹서버 아키텍쳐

1) Endpoint에 대한 Location Transparency 의 제공

본 아키텍쳐에서 웹서버는 Application Grid로의 End point를 단일화 시켜주는 중요한 역할을 한다. Grid내의 여러 개의 Managed Server의 주소로 클라이언트가 직접 접근하는 것이 아니라 업무별로 배정된, 웹서버라는 단일 접속점을 통해서 Grid내의 Managed Server로 접근할 수 있게 해준다. (이는 Grid내의 Managed Server의 수가 증가하거나 감소하더라도, 접속점에 대한 변경을 없게 하여 Location Transparency를 보장할 수 있게 한다.)

 

2) 유연한 배포 구조의 제공

본 아키텍쳐에서의 웹서버 구성은 하나의 업무에 대해서 두 이상의 웹서버와 하나의 L4를 사용하도록 구성되어 있는데, 이는 애플리케이션의 배포의 용이성을 제공하기 위해서이다.

WAS의 기능에 상관없이 애플리케이션 개발과정상의 실수에 의해서 REDEPLOY 과정에 많은 문제를 일으킬 수 있는데, 이로 인해서 가장 좋은 REDEPLOY 방법은 DEPLOY후 RESTART하는 것이 가장 좋은 방법이다. 그러나 이 경우 해당 업무가 일시적으로 정지될 수 있는 위험도를 가지고 있기 때문에, 이 다운 타임을 최소화할 수 있는 아키텍쳐 설계가 필요하다.

2개의 웹서버중 하나의 웹서버를 다운 시키면 L4에 의해서 반대쪽 웹서버로만 부하가 가게 되고, 웹서버가 다운 되었기 때문에, 그에 연결된 Managed Server들은 사용자로부터 REQUEST를 받지 않는 상태가 된다. 이 상태에서 애플리케이션을 재배포한후 서버들을 재기동 시킨후, 반대족 웹서버도 번갈아서 같은 방식으로 재기동을 하게 되면 운영중에도 가장 안전한 방법으로 업무에 대한 정지 없이 재배포가 가능하게 된다.

 

Application Grid OAM (Operation, Administration, Monitoring)

OAM 기능은 애플리케이션 그리드에 대한 운영,관리, 모니터링 기능을 제공하는 인프라이다. 비록 고객의 요구 사항에서는 웹로직만으로 구성하는 것을 요청했으나, 아키텍쳐의 완성도를 위해서 OAM 모듈에 대한 기능을 추가하였다.

 

Configuration 관리

고객의 요구사항중의 하나는 100개이상의 웹로직 인스턴스를 운영 및 관리해야 한다. 비록 클러스터링을 통해서 관리 포인트를 줄일 수 있는 형태로 설계했지만, 많은 인스턴스에 대한 Configuration 관리는 매우 도전적인 과제중의 하나이다.

Oracle 제품중에 ACC (Application Configuration Console)은 단일 Console을 통해서 여러 Managed 서버와 도메인 그리고 클러스터에 대한 관리를 가능하게 해주며, Configuration에 대한 이력관리등을 통해서 애플리케이션 그리드에 대한 하나의 관리 기능을 제공한다.

 

시스템 상태 모니터링

전체 그리드에서 시스템의 상태를 일목요연하게 볼 수 있는 기능이 필요하다. CPU 사용률, 애플리케이션 관점에서의 병목 구간, Thread 상태, 응답 시간등에 대한 모니터링 기능이 필요한데, 이는 APM (Application Performance Monitoring)을 통해서 가능하다.

 

업무별 상태 모니터링

시스템 상태 모니터링이 애플리케이션 관점(기술 관점)이라면 업무별 상태 모니터링은 비즈니스 관점에서 애플리케이션 그리드를 모니터링 하는 것이다.

 업무별 응답시간, 사용률, 장애율등을 Oracle BAM (Business Activity Monitoring)을 이용하여 그래프로 가시화 하여, 업무의 운용 상황을 한눈에 파악할 수 있도록 한다.

 

Features

Application Grid 아키텍쳐의 특징을 다시한번 정리해보면 다음과 같다.

 

장애 전파 방지 

Ÿ          Managed Server 분리를 통한 장애 전파 방지

업무별로 Managed Server를 분리하여, Dead Lock이나 Lock 경합으로 인한 장애 전파 또는 메모리 과사용으로 인하여 다른 업무에 영향을 주는 요인을 제거하였다.

Ÿ          하드웨어 자원 분리를 통한 장애 전파 방지

기존 WAS 아키텍쳐에서는 JAVA 프로세스를 분리하더라도, 실제 CPU나 메모리등의 하드웨어 자원을 공유해왔기 때문에, 한 프로세스가 CPU를 과점유하기 시작하면 정상적인 다른 프로세스에게도 영향을 줬다.

그러나 이 아키텍쳐에서는 업무에 따라서 하드웨어 자원을 분리하여 할당하기 때문에,특정 업무가 CPU를 과점유한다하더라도, 다른 업무용으로 배정된 CPU 자원을 사용할 수 없기 때문에, 하드웨어 자원 점유에 의한 장애 전파를 방지한다.

유연하고 최적화된 하드웨어 리소스 운영

Ÿ          Managed Server의 수 조정을 통한 자원 배분

시스템의 사용량이 늘어날 때, 사용량이 늘어난 업무에만 Managed Server의 수를 늘려서 하드웨어 자원의 사용을 최적화 할 수 있다. 반대로 사용량이 적은 업무의 경우 Managed Server의 수를 줄여서 잉여된 자원을 다른 업무에 배정하여 전체 Application Grid의 하드웨어 사용 효율성을 극대화 한다.

Ÿ          가상화를 통한 CPU 및 메모리에 대한 유연한 배분

해당 업무에 메모리 사용량이 높거나 CPU 사용량이 높을때는 하드웨어 가상화 기능을 통해서

메모리 크기 한계 극복

Ÿ          업무별 분리를 통한 메모리 사용성의 극대화

자바 애플리케이션은 구조상의 한계상 통상적으로 1.5GB의 메모리만이 사용가능하다. (최대 3G). 그래서 사용자 수가 늘어나는 경우에는 전체 부하를 여러 개의 인스턴스로 분산 시켜서 메모리 사용량을 낮추어야 하는데, 이 아키텍쳐에서는 간단하게 Managed Server의 수만 늘려주는 것만으로 메모리에 대한 부하를 손쉽게 분산 시킨다.

※       참고 : Managed Server 분리에도 불구하고, 더 많은 양의 메모리가 필요한 경우에는 Coherence Data Grid를 이용하여, 메모리 확장을 고려할 수 있다.

 

확장성 

Ÿ          웹서버를 이용한 Location Transparency의 제공

업무의 종류나 부하량 또는 사용자가 증가하는 것에 상관없이, 새로운 업무는 Application Grid에 추가로 배포될 수 있으며, 시스템의 용량도 하드웨어 증설만으로 큰 설정 변경 없이 손쉽게 증설이 가능하다. 시스템이 확장되더라도 Grid 밖에서 보기에는 동일한 End Point를 통해서 접근하는 것이기 때문에, 확장이 기존의 애플리케이션에 영향을 주지 않는다.

애플리케이션 배포의 유연성 

Ÿ          웹서버와 L4를 이용한 무정지 Clean redeploy 제공

앞서 설명한 바와 같이 L4와 2개 이상의 웹서버 구성을 통해서 가장 안전한 방법 (RESTART)으로 운영중 무정지 재배포를 지원한다.