slide1 n.
Download
Skip this Video
Download Presentation
WAS vs TPM 아키텍처

Loading in 2 Seconds...

play fullscreen
1 / 45

WAS vs TPM 아키텍처 - PowerPoint PPT Presentation


  • 215 Views
  • Uploaded on

WAS vs TPM 아키텍처. Ⅰ. 아키텍처 개요. Ⅳ. 온라인 업무 서버 아키텍처. Ⅱ. Presentation WAS 아키텍처. Ⅴ. 온라인 업무 서버 평가 항목 및 특징. Ⅲ. 프리젠테이션 WAS 평가 항목 및 특징. Ⅵ. 고려 사항. Ⅰ. 아키텍처 개요. 시스템 구축 시 고려 사항. 아키텍처 설계 원칙.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'WAS vs TPM 아키텍처' - jules


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide2

Ⅰ. 아키텍처 개요

Ⅳ. 온라인 업무 서버 아키텍처

Ⅱ. Presentation WAS 아키텍처

Ⅴ. 온라인 업무 서버 평가 항목 및 특징

Ⅲ. 프리젠테이션 WAS 평가 항목 및 특징

Ⅵ. 고려 사항

slide4

시스템 구축 시 고려 사항

아키텍처 설계 원칙
  • 중점 고려사항을 기반으로 대규모 트랜잭션 성능 보장, 아키텍쳐 확장성 보장, 서비스 고가용성 보장, 운영관리 효율성, 시스템 보안 강화의 5가지 아키텍처 설계 원칙을 정의함.

아키텍처 설계 원칙

기술 제약

사항

  • Planned/Unplanned Downtime 최소화 설계
  • Hot Deployment 확보를 통한 가용성 확보

대규모 Transaction 처리 및 온라인 성능 보장

  • DB 서버의 부하를 최대한 경감하는 방안 고려
  • 수직 확장성이 높은 H/W 또는 분산 DB 검토

아키텍처 확장성 보장

기술 요구

사항

  • UI 개발 TOOL
  • 미들웨어 기반 기술에 적합한 아키텍쳐 설계
  • 개발 F/W 도입에 따른 개발 및 인터페이스 방식 검토

서비스 고 가용성 보장

As-Is Unix

운영상의

문제점

  • 장애 발생을 감안한 용량 산정
  • 데이터 손실없이 신속히 서비스를 복구할 수 있는 아키텍쳐 설계

운영 관리 효율성

  • 장애 예방(정기점검,유지보수)을 위한 Planned Down Time 확보
  • 트랜잭션 부하 폭증에 대한 대처방안 수립

시스템 보안 강화

  • 대용량 트랜잭션 및 Storage 운영 관리에 적합한 서버, Storage 물리설계
slide5
아키텍처 설계 방안
  • 아키텍처 설계 원칙별로 구체적인 아키텍처 설계 방안을 수립함.

아키텍처 설계 원칙

아키텍처 설계 방안

대규모 트랜잭션 처리 및 온라인 성능 보장

DB용량 경량화

피크타임 용량 확보

대용량 배치 처리

부하 분산 최적화

아키텍처 확장성 보장

하드웨어 확장성

아키텍쳐 확장성

Multi-Tier 아키텍쳐 구성

장애 예방

서비스 Down Time 최소화 방안

비상 시스템 구성 방안

서비스 고가용성 보장

운영관리 효율성

개발 관리 방안

트랜잭션 관리 방안

성능 및 장애관리 방안

통합 백업관리 방안

시스템 보안 강화

정보 보호 전략

네트워크 보안

시스템 보안

slide6
아키텍처 물리설계 원칙 (1/3)
  • 비기능 요건과 TA 물리설계 원칙을 기반으로 서버와 스토리지 기본 구성을 설계함.

아키텍처 물리 설계 원칙

비기능 요건

서버

물리 설계

  • 성능을 고려한 적정 성능 여유율
  • 노드 구성에 따른 용량 산정 방법
  • 장애를 고려한 용량 산정

용량 및 성능 요건

서버 용량

산정 방법

  • 가용성 요건을 고려한 노드 구성
  • Tier별 노드 구성

노드 구성 방안

가용성 요건

  • 네트워크 보안을 고려한 배치
  • 데이터 트래픽을 고려한 Zone구성

네트워크

배치 방안

보안 요건

스토리지

물리 설계

  • 성능을 고려한 적정 성능 여유율
  • RAID 구성 방안
  • 장애를 고려한 용량 산정

용량 산정 방법

네트워크 요건

  • 가용성 요건을 고려한 노드 구성
  • 성능 향상 및 병목해결을 위한 노드 구성
  • 용도별, 업무별, 중요도별 노드구성

노드 구성 방안

slide7
아키텍처 물리설계 원칙 (2/3)
  • 시스템 구성 요건에 따라 3-Tier, 2-Tier, 1-Tier 아키텍쳐 구조로 구성할 수 있으며, 3-Tier 아키텍쳐를 권고함.

권고안

3 – Tier 아키텍쳐

2 – Tier 아키텍쳐

1 – Tier 아키텍쳐

Presentation서버,AP서버,DB서버 3대 이상 구성

AP서버, DB서버 2대 이상 구성

AP/ DB서버 1대 이상 구성

아키텍쳐 구조

Presentation서버

AP서버

DB서버

AP/DB서버

AP서버

DB서버

데이터

데이터

UI 로직

비즈니스 로직

UI + 비즈니스 로직

비즈니스 로직 + 데이터

  • 대용량 OLTP 업무
  • 데이터 및 비즈니스 로직 유출 방지 용이.
  • 물리적 노드수가 최소 3개 이상 필요
  • Tier간 네트워크 트래픽 발생.
  • 일반 OLTP 업무
  • 비즈니스 로직 유출이 발생할 수 있음.
  • 물리적 노드수가 최소 2개 이상 필요.
  • AP와 DB서버간 네트워크 트래픽 발생
  • UI 로직이 없는 인터페이스 G/W 업무
  • 데이터 및 비즈니스 로직이 유출 가능.
  • 물리적 노드수가 최소 1개로 구성 가능
  • Tier간 네트워크 트래픽 없음.

특징

설계

가이드

  • 아키텍쳐 기본 권고안
  • 높은 수준의 보안이 요구될 경우
  • 대용량 온라인 트랜잭션 처리 업무
  • 성능 및 확장성이 보장되어야 할 경우
  • 비즈니스 로직이 유출되더라도 보안상 문제가 없을 경우
  • UI 와 비즈니스 로직을 분리하지 못할 경우
  • 제안된 인증 사용자만 시스템 접근일 경우
  • 데이터 및 비즈니스 로직이 유출되더라도 보안상 문제가 없을 경우
  • 사내 시스템이거나 인증된 외부기관 과의 전용선을 통한 시스템간 인터페이스
slide8
아키텍처 물리설계 원칙 (3/3)
  • 노드 구성은 가용성 요건, 용량, 확장성, 성능을 고려하여 노드 수와 노드 클러스터링 방식을 정의함.

설계 권고 안

  • 가용성 요건과 처리 용량을 기반으로 단일 노드, 멀티 노드 구성.
  • DB 서버는 노드 수를 최소화할 수 있도록 노드 구성.
  • 대용량 트랜잭션 용량은 Active-Active 클러스터링 방식 권고.
  • 피크타임과 평상시 부하 편차가 클 경우 자원 활용성을 고려하여 Active-Active 클러스터링 방식 권고.
  • 업무 특성 및 솔루션 아키텍쳐 검토후 가장 안정적인 구성안 정의
slide9

BATCH 서버

PROFRAME

On-Demand

배치

fork

서비스

Entry

서비스

I/F 서비스

fork

I/F 서비스

WMQ

TPM

대용량 배치

Control-M/Agent

Veritas Cluster SVR

HPUX 11i v2

논리 아키텍처 구성도 (예)

User Channel

Web Zone

AP Zone

DB Zone

AP 서버

AP 서버

AP 서버

AP 서버

PRESENTATION 서버

FrameWork

기타 배치

PRESENTATION 서버

PROFRAME

기타 배치

PRESENTATION 서버

PROFRAME

기타 배치

PROFRAME

PRESENTATION 서버

기타 배치

DB 서버

PRESENTATION 서버

Client

Entry

서비스

DB I/O

PRESENTATION 서버

Entry

서비스

DB I/O

DB 서버

서비스

Entry

서비스

대용량 배치

DB I/O

Web Server

서비스

WAS-TPM 모듈oB

WAS

WAS-TPM 연계

Entry

WAS

WAS-TPM 모듈

서비스

대용량 배치

DB I/O

서비스

WAS-TPM 모듈oB

DB 서버

대용량 배치

WAS

WAS-TPM 모듈

서비스

WAS-TPM 모듈oB

대용량 배치

WAS

WAS-TPM 모듈

Load Balance

WAS-TPM 모듈oB

DB 서버

WAS

WAS-TPM 모듈

WAS-TPM 모듈oB

JSP

WAS

WAS-TPM 모듈

JSP

JSP

tpcall

JSP

Twins911 Green

JSP

Control-M/Agent

Servlet

Control-M/Agent

JSP

Control-M/Agent

Twins911 Green

Servlet

Control-M/Agent

Servlet

Http

Twins911 Green

Servlet

Reporting Page

Servlet

TPM

Servlet

DBMS

TPM

SQL*Net

TPM

Reporting Page

ORACLE RAC 10g

TPM

Reporting Page

trbTiTAN

Reporting Page

ORACLE RAC 10g

Reporting Page

Veritas Cluster SVR

Reporting Page

Veritas Cluster SVR

ORACLE RAC 10g

Veritas Cluster SVR

trbTiTAN

trbTiTAN

SSO Agent

UNIX

trbTiTAN

HPUX 11i v2

HPUX 11i v2

trbTiTAN

HPUX 11i v2

trbTiTAN

Cluster

File

System

UNIX

HPUX 11i v2

HPUX 11i v2

MC/SG

HPUX 11i v2

HPUX 11i v2

MC/SG

HPUX 11i v2

MC/SG

tpcall

BATCH 서버

UNIX

DB

HPUX 11i v2

FrameWork

Job Control Server

HPUX 11i v2

Control-M 서버

On-Demand

배치

fork

서비스

Entry

서비스

Job Controlr

Archive

Log

채널통합서버

채널통합 서버

tpcall

tpcall

I/F 서비스

fork

MCI

I/F 서비스

EAI 모듈

솔루션 미정

UNIX

TP ADAPTOR

UNIX

TPM

UNIX

대용량 배치

고객센터

Control-M/Agent

Load Balance

UNIX

유/무선 채널 시스템

EAI 서버

EAI Hub 서버

EAI

WMQi

UNIX

IBM AIX 4.3

Legacy 시스템

slide11

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

내부직원용

Web 서버

파트너용

Web 서버

WAS 아키텍처 옵션 정의

Option 2: 대상 사용자별 WAS

Option 3: 업무별 WAS

Option 1: 통합 WAS방식

권고안

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

내부직원용

Web 서버

파트너용

Web 서버

고객용

Web 서버

내부직원용

Web 서버

파트너용

Web 서버

파트너용

WAS

파트너용

WAS

통합 WAS

통합 WAS

고객용

WAS

고객용

WAS

내부

직원용

WAS

내부

직원용

WAS

PRM

WAS

PRM

WAS

CRM

WAS

CRM

WAS

PMS/CMS

WAS

PMS/CMS

WAS

클러스터링

클러스터링

클러스터링

클러스터링

클러스터링

클러스터링

클러스터링

신규 개발 업무 영역

솔루션 기반 구축 영역

신규 개발 업무 영역

솔루션 기반 구축 영역

신규 개발 업무 영역

솔루션 기반 구축 영역

업무

Logic

업무

Logic

업무

Logic

업무

Logic

업무

Logic

업무

Logic

업무

Logic

업무

Logic

업무

Logic

업무

Logic

업무

Logic

업무

Logic

  • 전체 어플리케이션의 업무 Logic을 하나의 통합된
  • WAS를 통해 제공
  • 통합 WAS를 통한 부하 분산
  • 장애 발생시 Fail-over를 처리할 수 있도록
  • Clustering으로 구성함
  • 업무 Logic을 제공하는 모든 어플리케이션
  • 서버와의 연계 구성이 가장 복잡함
  • 동일 업무에 대한 유사한 Presentation Logic을
  • 고객, 내부직원 및 파트너 간에 공유하게 되는 경우
  • 유리한 구조임
  • 전체 어플리케이션의 업무 Logic을 별도의
  • WAS를 통해 제공
  • 통합 WAS를 통한 부하 분산
  • 장애 발생시 Fail-over를 처리할 수 있도록
  • Clustering으로 구성함
  • 업무 Logic을 제공하는 모든 어플리케이션
  • 서버와의 연계 구성이 복잡함
  • 동일 업무에 대해 Presentation Logic이
  • 고객, 내부직원 및 파트너 간에 상이한 경우
  • 유리한 구조임
  • 전체 어플리케이션의 업무 Logic별로 별도의
  • WAS를 통해 제공
  • 통합 WAS를 통한 부하 분산
  • 장애 발생시 Fail-over를 처리할 수 있도록
  • Clustering으로 구성함
  • 업무 Logic을 제공하는 모든 어플리케이션
  • 서버와의 연계 구성이 비교적 단순함
  • 업무별로 Presentation Logic이
  • 다양하고 업무간 공통된 부분이 적은 경우
  • 유리한 구조임
was was
WAS 아키텍처 옵션 정의 - 통합 WAS방식
  • 통합 WAS 구성 방안은 Presentation Logic의 재사용성을 극대화하기 위한 방안으로, 사용자 그룹이나 대상 업무에 상관없이 논리적으로 하나의 WAS를 통해 서비스하도록 구성하는 방안임

업무 처리 방안

통합 WAS 구성

고객은 고객용 Web 서버를 통해 통합 WAS 클러스터 중 가용한 WAS를 사용하여 사용할 업무 Logic에 접근함

내부직원은 내부직원용 Web 서버를 통해 통합 WAS 클러스터 중 가용한 WAS를 사용하여 사용할 업무 Logic에 접근함

파트너는 파트너용 Web 서버를 통해 통합 WAS 클러스터 중 가용한 WAS를 사용하여 사용할 업무 Logic에 접근함

1

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

내부직원용

Web 서버

파트너용

Web 서버

2

웹서버

3

1

2

3

통합 WAS

통합 WAS

주요 특징

Presentation용

WAS

  • 논리적으로 하나의 Presentation 용 WAS를 두는 구성임
  • 모든 Presentation Logic을 논리적으로 동일한 WAS 상에서 수행함
  • 통합 WAS는 Active-Active로 클러스터링 구성하여, 부하를 분산하고 장애에 대응하므로, 전체 사용자에 대한 업무 부하가 각 WAS로 동일하게 분산되는 방식임
  • 고객, 내부직원, 파트너 등 모든 대상 사용자 그룹이 같은 Presentation Logic을 수행하는 경우 유리한 구조임

클러스터링

신규 개발 업무 영역

솔루션 기반 구축 영역

업무 Logic

서버

업무

Logic

업무

Logic

업무

Logic

업무

Logic

was was1
WAS 아키텍처 옵션 정의 - 대상 사용자별 WAS
  • 대상 사용자 별 WAS 구성방안은 고객, 내부직원 및 파트너 별로 별도의 Presentation 용 WAS를 구성하여, 각 사용자 그룹별로 업무 종류에 상관없이 통합 서비스 하도록 구성하는 방안임

업무 처리 방안

대상 사용자 별 WAS 구성

고객은 고객용 Web 서버를 통해 고객 WAS 클러스터 중 가용한 WAS를 사용하여 사용할 업무 Logic에 접근함

내부직원은 내부직원용 Web 서버를 통해 내부직원 WAS 클러스터 중 가용한 WAS를 사용하여 사용할 업무 Logic에 접근함

파트너는 파트너용 Web 서버를 통해 파트너 WAS 클러스터 중 가용한 WAS를 사용하여 사용할 업무 Logic에 접근함

1

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

내부직원용

Web 서버

파트너용

Web 서버

2

웹서버

3

1

2

3

파트너용

WAS

파트너용

WAS

고객용

WAS

고객용

WAS

내부

직원용

WAS

내부

직원용

WAS

주요 특징

Presentation용

WAS

  • 대상 사용자 그룹별로 논리적으로 하나의 Presentation용 WAS를 두는 구성임
  • 대상 사용자 그룹에 해당하는 모든 Presentation Logic을 논리적으로 동일한 WAS 상에서 수행함
  • 각 WAS는 Active-Active로 클러스터링 구성하여, 부하를 분산하고 장애에 대응하므로, 서비스해야 할 대상 사용자 및 사용 패턴에 따라 사용자 별 WAS 클러스터의 크기를 결정함
  • 동일 업무에 대한 Presentation Logic이 고객, 내부직원 및 파트너 간에 유사한 경우 유리한 구조임

클러스터링

클러스터링

클러스터링

신규 개발 업무 영역

솔루션 기반 구축 영역

업무 Logic

서버

업무

Logic

업무

Logic

업무

Logic

업무

Logic

was was2
WAS 아키텍처 옵션 정의 - 업무별 WAS
  • 업무별 WAS 구성방안은 CRM, PMS, CMS, PRM 등 차세대 영업계의 각 업무별로 별도의 Presentation용 WAS를 구성하여, 대상 사용자 그룹에 상관없이 통합 서비스 하도록 구성하는 방안임

업무 처리 방안

업무별 WAS 구성

고객은 고객용 Web 서버를 통해 사용할 업무 Logic과 연관된 WAS 클러스터 중 가용한 WAS를 사용하여 사용할 업무 Logic에 접근함

내부직원은 내부직원용 Web 서버를 통해 사용할 업무 Logic과 연관된 WAS 클러스터 중 가용한 WAS를 사용하여 사용할 업무 Logic에 접근함

파트너는 파트너용 Web 서버를 통해 사용할 업무 Logic과 연관된 WAS 클러스터 중 가용한 WAS를 사용하여 사용할 업무 Logic에 접근함

1

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

내부직원용

Web 서버

파트너용

Web 서버

웹서버

2

3

1

2

3

PRM

WAS

PRM

WAS

CRM

WAS

CRM

WAS

PMS/CMS

WAS

PMS/CMS

WAS

주요 특징

Presentation용

WAS

  • 대상 업무군 별로 논리적으로 하나의 Presentation용 WAS를 두는 구성임
  • 대상 업무군에 대한 모든 Presentation Logic을 논리적으로 하나의 WAS에서 수행함
  • 각 WAS는 Active-Active로 클러스터링 구성하여, 부하를 분산하고 장애에 대응하므로, 각 업무에서 처리해야 할 업무의 양에 따라 업무별 WAS 클러스터의 크기를 결정함
  • 업무 별로 Presentation Logic이 다양하고 업무간 공통되는 부분이 적은 경우 유리한 구조임

클러스터링

클러스터링

클러스터링

신규 개발 업무 영역

솔루션 기반 구축 영역

업무 Logic

서버

업무

Logic

업무

Logic

업무

Logic

업무

Logic

slide16

평가 항목

시나리오

성능

II

운영 성능

2

  • 운영 시 성능 보장을 위한 지원 방안은?

III

안정성

장애 대응

3

  • 장애 발생 가능성 및 장애에 대한 대응 방안은?

사용자 지원

I

사용자 인터페이스

1

구성

IV

  • 고객, 내부직원 및 파트너에 대한 사용자 인터페이스 지원 방안은?

4

웹 서버 구성

  • 고객, 내부직원 및 파트너 용 각 웹 서버에 대한 구성 방안은?

업무 서버 구성

5

  • 각 업무 Logic을 제공하는 업무 서버에 대한 구성 방안은?
WAS 아키텍처 평가 항목
  • 주요 평가 항목 별 차세대 영업계 운영상에서 발생할 수 있는 시나리오를 가정하여 각 WAS 아키텍처 Option의 지원 역량을 평가함
was 1 5
WAS 아키텍처 항목별 평가(1/5)

1

사용자 인터페이스

고객, 내부직원 및 파트너에 대한 사용자 인터페이스 지원 방안을 비교

사용자

was 2 5
WAS 아키텍처 항목별 평가(2/5)

2

운영 성능

운영 시 성능 보장을 위한 지원 방안을 비교

성능

was 3 5
WAS 아키텍처 항목별 평가(3/5)

3

장애 대응

장애 발생 가능성 및 장애에 대한 대응 방안을 비교

안정성

was 4 5
WAS 아키텍처 항목별 평가(4/5)

4

웹 서버 구성

고객, 내부직원 및 파트너 용 웹 서버와 WAS에 대한 연계 구성 방안 비교

구성

was 5 5
WAS 아키텍처 항목별 평가(5/5)

5

업무 서버 구성

각 WAS 클러스터와 업무 서버간 연계 구성 방안 비교*

구성

* 업무별로 업무 Logic 지원을 위한 서버가 별도 존재한다고 가정함

slide22
WAS 아키텍처 항목별 평가 종합

3가지 WAS 아키텍처에 대해 종합하면 다음과 같음

slide23
WAS 아키텍처 평가 종합
  • 고객에게 사용자 인터페이스를 제공하면서 내부 직원 및 파트너에게는 업무상의 편의성을 제공할 수 있는 사용자 인터페이스를 제공하기 위해 사용자 별 WAS 구성이 다소 우위에 있는 것으로 판단됨
slide24
WAS 논리 아키텍처
  • 사용자 그룹별로 특화된 사용자 인터페이스를 제공하기 위해서 고객, 내부 직원, 파트너 등 사용자 그룹 별로 별도의 WAS 클러스터를 통해 Presentation Logic을 지원함
  • 아키텍처 특징
  • 고객, 내부직원, 사용자 별로 별도의 WAS 클러스터 구성
  • 각 사용자 그룹을 지원하는 웹 서버와 연계 구성
  • 사용자 그룹별로 지원해야 하는 업무에 대해 업무 서버 연계 구성
  • 각 사용자 그룹에서 지원될 사용자 수 및 사용 패턴에 따라 각 WAS 클러스터의 크기 결정

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

고객용

Web 서버

내부직원용

Web 서버

파트너용

Web 서버

웹 서버

파트너용

WAS

파트너용

WAS

고객용

WAS

고객용

WAS

내부

직원용

WAS

내부

직원용

WAS

Presentation용

WAS

클러스터링

클러스터링

클러스터링

신규 개발 업무 영역

솔루션 기반 구축 영역

업무 Logic

서버*

업무

Logic

업무

Logic

업무

Logic

업무

Logic

* 업무 Logic 지원 서버에 대한 구성은 구축 시 달라질 수 있음

slide26
업무서버 아키텍처 구성 방안 (1/4)

Option 2: WAS + TPM (Cluster)

Option 3: WAS + TPM (Dedicated )

Option 1: WAS방식

WAS서버 Cluster

Presentation

WAS서버 Cluster

Presentation

WAS

WAS

WAS

Presentation

Presentation

Presentation

TP서버

TP서버

TP서버

TP서버

TP서버

TP서버

TP서버

TP서버

TP서버

Biz Logic

J2EE/EJB

Biz Logic

J2EE/EJB

Biz Logic

J2EE/EJB

A

B

C

A

B

C

A

B

C

A

A

B

B

C

C

DB서버

DB서버

DB서버

DB서버

DB서버

DB서버

DB서버

DB서버

DB서버

RAC Clustering

RAC Clustering

RAC Clustering

  • TP Monitor를 사용하지 않고 WAS에서 비즈니스 로직 처리를 동시 수행
  • 비즈니스 유연성 / 차세대 요건(SOA/ESB기반)에 적합한 구조
  • WAS서버는 트랜잭션 및 Presentation을 모두 담당(J2EE/EJB, JTA/JTS/JDBC)
  • 새로운 환경에서 비즈니스 로직 재 개발 필요
  • WAS의 대용량 트랜잭션 처리 성능 검증 필요
  • J2EE/EJB의 Transaction용 배치사례는 많으나 금융/통신 기간계 적용 사례 적음
  • TP서버와 WAS서버를 분리
  • WAS에서 Presentation을 TP에서 트랜잭션을 처리함
  • 대용량 처리의 안정성과 웹 서비스 및 차세대 요건에 유연한 혼합형 점진적 구조
  • TP서버를 업무 구분 없이 Clustering 구성
  • TP,DB서버 장애에 대해 최적의 유연한 구조
  • TP서버당 많은 리소스 필요
  • DB서버 활용률 높음
  • AP서버 1대만 기동 시에도 업무 연속가능
  • TP 서버를 업무별로 별도 구성하여 이중화
  • 업무별 모듈 구현 및 업무별 유지보수 적합.
  • 클러스터 구성 대비TP서버당 상대적으로 적은 리소스 필요
  • DB서버 TP서버의 업무별 Unbalance
  • 2대의 동일업무 TP 서버 장애 시 업무 중단
slide27
업무서버 아키텍처 구성 방안 (2/4)
  • WAS 구성 방안은 Transaction 및 Business Logic에 대한 관리를 WAS 상에서 EJB/JTS/JTA 기반으로 처리하는 구조로, TPM 기반의 프로그램에 대한 재사용 없이 SOA/ESB/개방형 웹 서비스 지향으로 신규 전면 구축함

WAS 방식

업무 처리 방안

업무별 WAS 구성이나 통합 업무용 WAS Cluster구성이 가능. (상세 WAS구성은 WAS 구성 Option에 준함)

업무 Logic을 EJB기반에서 Object/Container Base로 구현하며 트랜잭션은 JTS/JTA에서 처리, JSP/Servlet이 Presentation Layer를 처리함.

1

WAS

WAS

WAS

2

Presentation

JSP/Servlet

Presentation

JSP/Servlet

Presentation

JSP/Servlet

Biz Logic

J2EE/EJB

Biz Logic

J2EE/EJB

Biz Logic

J2EE/EJB

...

주요 특징

JTS/JDBC

JTS/JDBC

JTS/JDBC

  • J2EE 기반 업무 재개발이 요구됨
  • 기존 Client-Server Native 프로세스 1:1 Mapping방식이 아닌 Thread방식에 의해 업무 처리
  • 수직적 여러 계층의 기능을 통합한 것으로 다중화 및 부하 분산, Thread 관리/모니터링의 기술 최적화 요구됨
  • 시스템 계층구조, 부하분산 구조를 단순화하여 단일서버 처리
  • 프로세스 손실 시 영향 큼( 1 Process Multi-Thread방식)
  • 차세대 웹 서비스/SOA기반 관점 Infra구축 용이
  • 금융/통신 분야 WAS기반 대량 Transaction/조회 성능 검증 필요
  • WAS솔루션에서 Business Logic변경에 대한 Hot Deploy 제공

DB서버

DB서버

DB서버

RAC Clustering

slide28
업무서버 아키텍처 구성 방안 (3/4)
  • TP Cluster 구성 방안은 트랜잭션 제어와 업무 로직을 TP서버에서 처리하고 Presentation부분을 WAS에서 처리하도록 분리한 Multi-Tier구조 상에서 업무 구분 없이 모든 TP서버를 동일하게 구성하는 구조임

업무 처리 방안

WAS + TPM (Cluster) 방식

대량 Transaction 등의 Online 업무를 위한 DB를 위해 TP 서버를 별도로 구성

여러 업무를 개별 TP서버상에 동시에 탑재하여 부하를 분산하는 구조로 각각의 TP서버는 업무 Dependency가 없음.

TP서버,DB서버의 자원 활용도 측면에서 최적화된 구조임.

1

WAS서버 Cluster

Presentation + JSP/Servlet

2

3

TP서버

TP서버

TP서버

주요 특징

...

B

C

A

B

C

A

B

C

A

  • 기존 C/C++ Base 코드 재 사용 보장
  • Client-Server 프로세스 1:1 Mapping방식의 자원 사용
  • TP Monitor에서 XA기반 2PC보장
  • 성능 및 확장성 보장
  • SOA 관점 Infra구축 시 Wrapper나 Service Bus중재 필요
  • 통신분야 등 대량 Transaction/조회 성능에 적합 검증된 구조
  • 업무 Logic 변경 시 Hot Deploy가 가능하나 제한적임
  • TP서버, DB서버의 장애에 대해 최대 유연한 구조
  • TP서버 별 탑재 프로세스가 많고 자원이 과다 필요
  • 다수 TP 서버의 동일 업무 수행으로 인한 DB상의 Lock 경쟁으로 인한 상대적인 성능상의 저하를 가져올 수 있음
  • TP서버 기동 등에서 무거운 구조이나 Failover 불필요한 구조

DB서버

DB서버

DB서버

RAC Clustering

slide29
업무서버 아키텍처 구성 방안 (4/4)
  • TP Cluster구성 방안은 트랜잭션 제어와 업무로직을 TP에서 처리하고 Presentation부분을 WAS에서 처리하도록 분리한 Multi-Tier구조 상에서 TP서버 별 업무를 별도 처리하도록 구성한 구조임

업무 처리 방안

WAS + TPM (Dedicated) 방식

대량 Transaction 등의 Online 업무를 위한 DB를 위해 TP 서버를 별도로 구성

업무별로 Transaction서버를 분리 이중화하여 구성

자원 활용 측면에서 업무별 Unbalance될 수 있음

1

WAS서버 Cluster

2

Presentation + JSP/Servlet

3

주요 특징

TP서버

TP서버

TP서버

TP서버

TP서버

TP서버

...

  • 기존 C/C++ Base 코드 재 사용 보장
  • Client-Server 프로세스 1:1 Mapping방식의 자원 사용
  • Presentation 및 Web Interface 와 트랜잭션 처리영역을 분리하여 Transaction처리의 성능 및 확장성 보장
  • SOA 관점 Infra구축 시 Wrapper나 Service Bus중재 필요
  • 통신분야 등 대량 Transaction/조회 성능에 적합 검증된 구조
  • 업무 Logic 변경 시 Hot Deploy가 가능하나 제한적임

A

A

B

B

B

B

DB서버

DB서버

DB서버

  • 구성 및 관리 , 확장 면에서 복잡
  • TP서버 별 탑재 프로세스 적고 자원 소요량 적음
  • DB Lock 경쟁으로 인한 성능 감소 부분 상대적으로 적음.
  • 2대의 동일 업무 TP 노드 장애 시에는 Fail-Over를 위한 별도 조치 필요(Migration)

RAC Clustering

slide31
구성별 평가 항목 (1/8)
  • 주요 평가 항목 별 차세대 시스템 운영상에서 발생할 수 있는 시나리오를 가정하여 업무 서버 아키텍처 Option의 지원 역량을 평가함

평가 항목

시나리오

안정성

I

1

대용량 트랜잭션

대용량 트랜잭션 및 Query에 대해 트랜잭션 안정성을 보장하기 위한 방안은?

성능

II

대용량 트랜잭션

2

대용량 트랜잭션에서의 성능을 지원하기 위한 방안은?

III

가용성

이중화 및 Failover구조, 부하분산

3

DB서버, AP서버 장애에 대비한 최적의 이중화 구조 및 Failover 방안은?

IV

확장성,유연성

웹 서비스 지원 및 SOA

4

개방형 웹/웹 서비스와 연동하기 위한 웹 확장 방안은?

5

업무 Logic 활용성,

업무 Logic의 재 활용성과 변경에 대한 유연성 확보 방안은?

비용

V

개발 및 운영 비용

6

개발 및 운영 시에 Cost최적화를 위한 방안은?

구축 사례

VII

국내외 구축 사례

7

국내외 대형 site에서 적용된 사례가 있는가?

slide32
구성별 평가 항목 (2/8)

1

대용량

트랜잭션

대용량 Transaction 및 Query를 안정적으로 처리하기 위한 방안 비교

안정성

slide33
구성별 평가 항목 (3/8)

2

대용량

트랜잭션

대용량 Transaction 및 Query를 고성능으로 처리하기 위한 방안 비교

성능

slide34
구성별 평가 항목 (4/8)

3

고가용성

Failover

부하분산

트랜잭션의 업무별 부하 분산 방법과 AP서버,DB서버 장애에 대한 가용성을 확보하기 위한 방안 비교

가용성

slide35
구성별 평가 항목 (5/8)

4

웹 서비스 지원

및 SOA

개방형 웹 서비스를 지원하기 위한 웹 연계 방안과 SOA/ESB기반 Infra에 대한 적합성 등을 비교

확장성

slide36
구성별 평가 항목 (6/8)

5

업무 Logic

재 활용성

개발 전/후 업무 Logic 재활용성에 대한 비교

유연성

slide37
구성별 평가 항목 (7/8)

5

개발 및

운영 비용

개발 시 / 운영 시 비용에 대한 검토

비용

slide38
구성별 평가 항목 (8/8)

6

국내외

구축사례

대용량 트랜잭션의 해당 방식에 대한 국,내외 구축 사례를 비교 검토

구축사례

slide39
분산 아키텍처 구성 사례
  • WAS + TP Cluster구조의 채택은 아래의 사례 및 근거로 뒷받침될 수 있음

대형 OLTP 기간계 도입 사례

  • 대형 통신/금융사의 기간계 OLTP 업무(고객/Billing등)에 J2EE 기반으로만 High-end OLTP Transaction 서버를 구축한 사례는 거의 없음
  • 차세대 / 신규 시스템 구축 시에도 대용량 OLTP 구축은 성능 및 안정성 면에서 도입 사례 다수
slide40
종합 - 분산 아키텍처 구성 방안
  • Mission Critical 업무
  • 대용량 거래 처리
  • 빠른 응답시간 보장
  • C/COBOL 기반 업무 개발
  • 고가용성 시스템

Client 단말(ex. Power Builder)

TP-Monitor

DBMS

  • Web 기반 시스템
  • 미래 지향적 시스템
  • 개발 생산성 향상
  • JAVA 기반
  • 성능 이슈 존재

Web Browser

or Rich Client

Web

Server

WAS

DBMS

  • Web 기반 시스템
  • 미래 지향적 시스템
  • Mission Critical 업무
  • C 기반 업무 개발
  • 고 성능/ 고 가용성

Web Browseror Rich Client

Web/WAS

TP-Monitor

DBMS

slide42

온라인 업무 서버 아키텍처 참고 사항

1

Research 기관 권고 및 예상

  • Gartner는 대용량 집중 트랜잭션(Ultra-High End)과 실시간 기업 환경(RTE)에서 어플리케이션 서비스 품질(QoS)을 보장하기 위해 J2EE + TPM의 혼합형이 대세를 이룰 것으로 예측함
slide43

온라인 업무 서버 아키텍처 참고 사항

1

Research 기관 권고 및 예상

  • 2008년까지 80% 이상의 대부분의 조직은 Multiple Type의 어플리케이션 기술기반으로 남아 있을 것임
  • 하나의 어플리케이션 기술 또는 Vendor가 비즈니스 소프트웨어 마켓을 지배하지 못함
  • 2009년까지 J2EE Platform이 복잡한 Enterprise-Computing 특성 (트랜잭션, 부하 분산, Fail-Over,클러스터링,분산환경)을 수용하며 급격히 진화하고 J2EE,MSAP는 비즈니스 Critical 업무에 사용되지만 최소40%의 New, Large Business Critical 어플리케이션은 아직도 Classic TPM을 필요로 할 것임) : J2EE/MSAP아키텍처는 기존 TPM의 가용성, Workload Balancing, Mixed Workload에 대한 Quality를 fully 만족시키지 못할 것임
  • 2009년 이후 까지 TPM은 실용적이고 진화하는 플랫폼으로 남아 있을 것임
  • Classic OLTP 어플리케이션은 Service Orientation, 변화에 대한 Agility, external app와의 Integration를 지원하는 방향으로 확장하고 있음
  • 2007년까지 선두 어플리케이션 플랫폼은 Event Driven, Service Oriented 형식의 BCA (Business Component Architecture)를 지원할 것임 (80%가능성)
  • SOA Only Architecture는 도입장점보다 많은 문제를 발생 시킬 수 있어 Event-Driven + SOA의 시너지 기반 BCA를 고려해야 함

Source : Gartner Predict 2005

slide44

온라인 업무 서버 아키텍처 참고 사항

2

업계 권고 사항

“ The telcos normally provide or you need to scale to handling 10's of thousands of transactions a second,

B’s TP Monitor is going to be a clear choice. Java application servers are just not regularly being used in those environments, at least not yet.

Most of the critical core enterprise systems like telecommunication billing systems, are implemented using C/C++ and TPM (or other native middleware like CICS) “

– T Engineering

.

Amdocs and Singleview are core telecommunication billing systems written on TPM in C/C++.

Maersk Sealand, the biggest shipping company in the world, new shipping application most of the worlds container booking s go through write their application using TP/C++

That's just one example of a major new application using TPM.

They evaluated TPM against WebLogic/WebSphere and chose TPM for better performance and scalability.

From the experience, WebLogic applications tend to be on the layer above this,

in creating an enterprise bus that integrates into the core systems and provides a single point of interface.