WAS vs TPM 아키텍처

1. WAS vs TPM 아키텍처

2. Ⅰ. 아키텍처 개요 Ⅳ. 온라인 업무 서버 아키텍처 Ⅱ. Presentation WAS 아키텍처 Ⅴ. 온라인 업무 서버 평가 항목 및 특징 Ⅲ. 프리젠테이션 WAS 평가 항목 및 특징 Ⅵ. 고려 사항

3. Ⅰ. 아키텍처 개요

4. 시스템 구축 시 고려 사항 아키텍처 설계 원칙 • 중점 고려사항을 기반으로 대규모 트랜잭션 성능 보장, 아키텍쳐 확장성 보장, 서비스 고가용성 보장, 운영관리 효율성, 시스템 보안 강화의 5가지 아키텍처 설계 원칙을 정의함. 아키텍처 설계 원칙 기술 제약 사항 • Planned/Unplanned Downtime 최소화 설계 • Hot Deployment 확보를 통한 가용성 확보 대규모 Transaction 처리 및 온라인 성능 보장 • DB 서버의 부하를 최대한 경감하는 방안 고려 • 수직 확장성이 높은 H/W 또는 분산 DB 검토 아키텍처 확장성 보장 기술 요구 사항 • UI 개발 TOOL • 미들웨어 기반 기술에 적합한 아키텍쳐 설계 • 개발 F/W 도입에 따른 개발 및 인터페이스 방식 검토 서비스 고 가용성 보장 As-Is Unix 운영상의 문제점 • 장애 발생을 감안한 용량 산정 • 데이터 손실없이 신속히 서비스를 복구할 수 있는 아키텍쳐 설계 운영 관리 효율성 • 장애 예방(정기점검,유지보수)을 위한 Planned Down Time 확보 • 트랜잭션 부하 폭증에 대한 대처방안 수립 시스템 보안 강화 • 대용량 트랜잭션 및 Storage 운영 관리에 적합한 서버, Storage 물리설계

5. 아키텍처 설계 방안 • 아키텍처 설계 원칙별로 구체적인 아키텍처 설계 방안을 수립함. 아키텍처 설계 원칙 아키텍처 설계 방안 대규모 트랜잭션 처리 및 온라인 성능 보장 DB용량 경량화 피크타임 용량 확보 대용량 배치 처리 부하 분산 최적화 아키텍처 확장성 보장 하드웨어 확장성 아키텍쳐 확장성 Multi-Tier 아키텍쳐 구성 장애 예방 서비스 Down Time 최소화 방안 비상 시스템 구성 방안 서비스 고가용성 보장 운영관리 효율성 개발 관리 방안 트랜잭션 관리 방안 성능 및 장애관리 방안 통합 백업관리 방안 시스템 보안 강화 정보 보호 전략 네트워크 보안 시스템 보안

6. 아키텍처 물리설계 원칙 (1/3) • 비기능 요건과 TA 물리설계 원칙을 기반으로 서버와 스토리지 기본 구성을 설계함. 아키텍처 물리 설계 원칙 비기능 요건 서버 물리 설계 • 성능을 고려한 적정 성능 여유율 • 노드 구성에 따른 용량 산정 방법 • 장애를 고려한 용량 산정 용량 및 성능 요건 서버 용량 산정 방법 • 가용성 요건을 고려한 노드 구성 • Tier별 노드 구성 노드 구성 방안 가용성 요건 • 네트워크 보안을 고려한 배치 • 데이터 트래픽을 고려한 Zone구성 네트워크 배치 방안 보안 요건 스토리지 물리 설계 • 성능을 고려한 적정 성능 여유율 • RAID 구성 방안 • 장애를 고려한 용량 산정 용량 산정 방법 네트워크 요건 • 가용성 요건을 고려한 노드 구성 • 성능 향상 및 병목해결을 위한 노드 구성 • 용도별, 업무별, 중요도별 노드구성 노드 구성 방안

7. 아키텍처 물리설계 원칙 (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 와 비즈니스 로직을 분리하지 못할 경우 • 제안된 인증 사용자만 시스템 접근일 경우 • 데이터 및 비즈니스 로직이 유출되더라도 보안상 문제가 없을 경우 • 사내 시스템이거나 인증된 외부기관 과의 전용선을 통한 시스템간 인터페이스

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

9. 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 시스템

10. Ⅱ. Presentation WAS 아키텍처

11. 고객용 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이 • 다양하고 업무간 공통된 부분이 적은 경우 • 유리한 구조임

12. 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 … …

13. 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 … …

14. 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 … …

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

16. 평가 항목 시나리오 성능 II 운영 성능 2 • 운영 시 성능 보장을 위한 지원 방안은? III 안정성 장애 대응 3 • 장애 발생 가능성 및 장애에 대한 대응 방안은? 사용자 지원 I 사용자 인터페이스 1 구성 IV • 고객, 내부직원 및 파트너에 대한 사용자 인터페이스 지원 방안은? 4 웹 서버 구성 • 고객, 내부직원 및 파트너 용 각 웹 서버에 대한 구성 방안은? 업무 서버 구성 5 • 각 업무 Logic을 제공하는 업무 서버에 대한 구성 방안은? WAS 아키텍처 평가 항목 • 주요 평가 항목 별 차세대 영업계 운영상에서 발생할 수 있는 시나리오를 가정하여 각 WAS 아키텍처 Option의 지원 역량을 평가함

17. WAS 아키텍처 항목별 평가(1/5) 1 사용자 인터페이스 고객, 내부직원 및 파트너에 대한 사용자 인터페이스 지원 방안을 비교 사용자

18. WAS 아키텍처 항목별 평가(2/5) 2 운영 성능 운영 시 성능 보장을 위한 지원 방안을 비교 성능

19. WAS 아키텍처 항목별 평가(3/5) 3 장애 대응 장애 발생 가능성 및 장애에 대한 대응 방안을 비교 안정성

20. WAS 아키텍처 항목별 평가(4/5) 4 웹 서버 구성 고객, 내부직원 및 파트너 용 웹 서버와 WAS에 대한 연계 구성 방안 비교 구성

21. WAS 아키텍처 항목별 평가(5/5) 5 업무 서버 구성 각 WAS 클러스터와 업무 서버간 연계 구성 방안 비교* 구성 * 업무별로 업무 Logic 지원을 위한 서버가 별도 존재한다고 가정함

22. WAS 아키텍처 항목별 평가 종합 3가지 WAS 아키텍처에 대해 종합하면 다음과 같음

23. WAS 아키텍처 평가 종합 • 고객에게 사용자 인터페이스를 제공하면서 내부 직원 및 파트너에게는 업무상의 편의성을 제공할 수 있는 사용자 인터페이스를 제공하기 위해 사용자 별 WAS 구성이 다소 우위에 있는 것으로 판단됨

24. 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 지원 서버에 대한 구성은 구축 시 달라질 수 있음

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

26. 업무서버 아키텍처 구성 방안 (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 서버 장애 시 업무 중단

27. 업무서버 아키텍처 구성 방안 (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

28. 업무서버 아키텍처 구성 방안 (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

29. 업무서버 아키텍처 구성 방안 (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

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

31. 구성별 평가 항목 (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에서 적용된 사례가 있는가?

32. 구성별 평가 항목 (2/8) 1 대용량 트랜잭션 대용량 Transaction 및 Query를 안정적으로 처리하기 위한 방안 비교 안정성

33. 구성별 평가 항목 (3/8) 2 대용량 트랜잭션 대용량 Transaction 및 Query를 고성능으로 처리하기 위한 방안 비교 성능

34. 구성별 평가 항목 (4/8) 3 고가용성 Failover 부하분산 트랜잭션의 업무별 부하 분산 방법과 AP서버,DB서버 장애에 대한 가용성을 확보하기 위한 방안 비교 가용성

35. 구성별 평가 항목 (5/8) 4 웹 서비스 지원 및 SOA 개방형 웹 서비스를 지원하기 위한 웹 연계 방안과 SOA/ESB기반 Infra에 대한 적합성 등을 비교 확장성

36. 구성별 평가 항목 (6/8) 5 업무 Logic 재 활용성 개발 전/후 업무 Logic 재활용성에 대한 비교 유연성

37. 구성별 평가 항목 (7/8) 5 개발 및 운영 비용 개발 시 / 운영 시 비용에 대한 검토 비용

38. 구성별 평가 항목 (8/8) 6 국내외 구축사례 대용량 트랜잭션의 해당 방식에 대한 국,내외 구축 사례를 비교 검토 구축사례

39. 분산 아키텍처 구성 사례 • WAS + TP Cluster구조의 채택은 아래의 사례 및 근거로 뒷받침될 수 있음 대형 OLTP 기간계 도입 사례 • 대형 통신/금융사의 기간계 OLTP 업무(고객/Billing등)에 J2EE 기반으로만 High-end OLTP Transaction 서버를 구축한 사례는 거의 없음 • 차세대 / 신규 시스템 구축 시에도 대용량 OLTP 구축은 성능 및 안정성 면에서 도입 사례 다수

40. 종합 - 분산 아키텍처 구성 방안 • 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

41. Ⅵ. 참고 사항

42. 온라인 업무 서버 아키텍처 참고 사항 1 Research 기관 권고 및 예상 • Gartner는 대용량 집중 트랜잭션(Ultra-High End)과 실시간 기업 환경(RTE)에서 어플리케이션 서비스 품질(QoS)을 보장하기 위해 J2EE + TPM의 혼합형이 대세를 이룰 것으로 예측함

43. 온라인 업무 서버 아키텍처 참고 사항 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

44. 온라인 업무 서버 아키텍처 참고 사항 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.