1

Sytem Architecture

Eric LimAKAON

2/44

Ⅰ. 아키텍처 개요

Ⅱ. 아키텍처 물리 설계

Ⅲ. 아키텍처 구성도 ( 예 )

Ⅳ. 고려사항

Ⅰ. 아키텍처 개요

4

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

서비스 고 가용성 보장

아키텍처 확장성 보장

운영 관리 효율성

기술 제약사항

기술 요구사항

As-Is Unix

운영상의문제점

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

• DB 서버의 부하를 최대한 경감하는 방안 고려

• 수직 확장성이 높은 H/W 또는 분산 DB 검토

• UI 개발 TOOL• 미들웨어 기반 기술에 적합한 아키텍쳐 설계

• 개발 F/W 도입에 따른 개발 및 인터페이스 방식 검토

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

아키텍쳐 설계

• 장애 예방 ( 정기점검 , 유지보수 ) 을 위한 Planned Down Time 확보

• 트랜잭션 부하 폭증에 대한 대처방안 수립

• 대용량 트랜잭션 및 Storage 운영 관리에 적합한 서버 , Storage 물리설계

시스템 보안 강화

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

시스템 구축 시 고려 사항 아키텍처 설계 원칙

5

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

서비스 고가용성 보장

아키텍처 확장성 보장

운영관리 효율성

시스템 보안 강화

Multi-Tier 아키텍쳐 구성

하드웨어 확장성 아키텍쳐 확장성

장애 예방 서비스 Down

Time 최소화방안

비상 시스템 구성방안

성능 및 장애관리방안

트랜잭션 관리방안

정보 보호 전략 네트워크 보안 시스템 보안

피크타임 용량확보 대용량 배치 처리 부하 분산 최적화 DB 용량 경량화

아키텍처 설계 원칙 아키텍처 설계 방안

통합 백업관리방안

개발 관리 방안

아키텍처 설계 방안아키텍처 설계 원칙별로 구체적인 아키텍처 설계 방안을 수립함 .

6

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

• 배치업무는 장시간 수행되며 , 대부분의 시스템 자원을 사용하게 됨• OLTP 와 배치 전용 DB 노드를 물리적으로 분리하여 자원 경합 방지

• 전체적인 트랜잭션의 부하가 특정 Tier 나 노드에 부하가 집중되지 않고 , 서버간 균일한 부하 분산 되도록 구성• Load Balancing 기능 사용

• 데이터가 커지면서 어플리케이션의 성능 저하 및 데이터 백업에 소요되는 비용 증가• 거의 사용하지 않는 데이터는 아카이빙 시스템으로 이동• Master 성 데이터는 주 장비 , 통계성 데이터는 아카이빙에 배치• 이력 데이터는 기간별로 Cutting 필요

• TPMC (Transaction Per Minute type C) • http://www.tpc.org/• TPS (Transaction Per Second)

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

아키텍처 설계 방안

피크타임 용량확보

대용량 배치 처리

부하 분산 최적화

DB 용량 경량화

• Round Robin• Weight Round Robin• Least Connected• IP Hash• Response Time• Bandwidth

7

• WEB, AP, DB 서버의 3-Tier 로 구성 ( 권장 )• WEB, AP 서버의 경우 Scale Out 고려• DB 서버의 경우 , Scale Up 고려

• Scale-out : 시스템 유닛 증가를 통한 수평적인 확장 . 장비 대수를 늘림으로 성능향상 분산처리 /병렬처리가 주 목적 . 상대적으로 저렴하지만 분산처리 SW 및 아키텍처 필요• Scale-up : 시스템 내 CPU, Memory, Disk 등 파워 및 용량 확장을 통한 수직적인 확장 즉 , 장비 대수는 그대로 두고 부품만 추가하여 성능확장

아키텍처 확장성 보장

아키텍처 설계 방안

Multi-Tier 아키텍쳐 구성

하드웨어 확장성

8

• 기존 시스템들과의 연계 및 인터페이스 통제 /관리 필요• 다양한 형태로 접근되는 사용자의 접근 경로가 관리되지 않을 경우 , 성능 및 안정성에 많은 영향을 미침• 다른 시스템이 사용하고 있는 인터페이스 변경 또는 제거 시 타 시스템 장애 유발• 사용자의 접근 경로에 대한 단일화 및 트랜젝션 제어 필요

• 초기 구축 시점에 성능을 위한 튜닝 실시 - 데이터가 증가하고 기존 데이터가 변경됨 => 지속적 성능 관리 필요• 페이지별 응답속도 분석 , IO 성능 분석• 성능관리를 목표로 하는 Factor 를 선정하여 집게된 데이터를 체계적인 분석 필요

서비스 고가용성 보장

아키텍처 설계 방안

트랜잭션 통제 / 관리의 효율성

성능 관리 방안

통합 백업 관리

9

• 하드웨어 장비의 이중화 구성을 통한 Single Point of Failure 방지• 스토리지 복제 기술 등을 이용한 데이터 손실 방지• Clustering 기술을 통해 자동으로 Fail Over 가능하도록 설계• 운영자 실수나 장애 예방을 위한 사전 인프라 테스트 환경 구성• 정기적인 점검을 통한 장애 예방 (daily/weekly check list)

• Planned Down Time - OS upgrade, 대규모 Application Upgrade, 장애 예방을 위한 정기점검 , Storage 증설 등• unPlanned Down Time - 이중화된 서버 /스토리지 부품의 동시 장애 , DBMS 장애 , 네트워크 장애 등• Down Time 요소를 명확히 정의하고 , 이에 따른 예방 대책 강구 ( 운영매뉴얼 : 긴급복구 SOP)

• 천재지변과 같은 상황으로 시스템 자체의 운영이 불가능할 경우 별도의 원격지에 이를 대비할 수 있는 비상 시스템 구축 고려• 비상 시스템으로의 전환 절차• 주 업무시스템의 정상 복구 이후 변경 /추가된 데이터에 대한 정합성 확인

운영관리 효율성 보장

아키텍처 설계 방안

장애 예방

서비스 Down Time 최소화

방안

비상 시스템 구성방안

Ⅱ. 아키텍처 물리설계

11

아키텍처 물리설계1-Tier 구성 : 하나의 머신에 웹기반 아키텍처 요소를 모두 포함하는 구성

12

아키텍처 물리설계2-Tier 구성 : 웹 기반 아키텍처 요소를 두개의 머신에 배치하는 구성 방식 . 웹 서버와 WAS를 하나의 머신에 배치하고 DBMS를 나머지 머신에배치하는 방법 .

웹서버를 별도의 머신에 배치하고 나머지 WAS와 DBMS를 다른 머신에 배치하는 방법 . 경우에 따라 머신과 머신 사이에 방화벽을 설정할 수 있다 .

13

아키텍처 물리설계3-Tier 구성 : 웹 서버 , WAS, DBMS 를 모두 다른 머신에 배치하여 구성하는 방식

14

아키텍처 물리설계대규모 3-Tier 구성 : 로드 발란스를 이용하여 3-Tier 구성을 확장하는 구성 방식 . 웹 시스템의 사용자가 많은 엔터프라이즈 어플리케이션일 경우 대부분 대규모 3-Tier 구성을 이용하고 있다 .

15

3 – Tier 아키텍쳐 2 – Tier 아키텍쳐 1 – Tier 아키텍쳐

아키텍쳐구조

Presentation 서버 AP 서버 DB서버

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

UI 로직 비즈니스 로직 데이터

AP 서버 DB서버

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

UI + 비즈니스 로직 데이터

설계가이드

특징

•대용량 OLTP 업무•데이터 및 비즈니스 로직 유출 방지 용이 .

•물리적 노드수가 최소 3 개 이상 필요

•Tier 간 네트워크 트래픽 발생 .

•아키텍쳐 기본 권고안•높은 수준의 보안이 요구될 경우•대용량 온라인 트랜잭션 처리 업무•성능 및 확장성이 보장되어야 할 경우

•비즈니스 로직이 유출되더라도 보안상 문제가 없을 경우

•UI 와 비즈니스 로직을 분리하지 못할 경우

•제안된 인증 사용자만 시스템 접근일 경우

•데이터 및 비즈니스 로직이 유출되더라도 보안상 문제가 없을 경우

•사내 시스템이거나 인증된 외부기관 과의 전용선을 통한 시스템간 인터페이스

•UI 로직이 없는 인터페이스 G/W 업무

•데이터 및 비즈니스 로직이 유출 가능 .

•물리적 노드수가 최소 1개로 구성 가능

•Tier 간 네트워크 트래픽 없음 .

•일반 OLTP 업무•비즈니스 로직 유출이 발생할 수 있음 .

•물리적 노드수가 최소 2 개 이상 필요 .

•AP 와 DB 서버간 네트워크 트래픽 발생

AP/DB 서버

AP/ DB 서버 1대 이상 구성

비즈니스 로직 + 데이터

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

권고안

Ⅲ. 아키텍처 구성도 ( 예 )

17/44

아키텍처 구성도 ( 예 )

Web Zone AP Zone DB ZoneUser Channel

Client

Load Balance

Load Balance

PRESENTATION 서버

WAS

JSP

WA

S-TPM

모듈

Servlet

WA

S-TPM

모듈oB

Reporting Page

HPUX 11i v2

trbTiTAN

PRESENTATION 서버

WAS

JSP

WA

S-TPM

모듈

Servlet

WA

S-TPM

모듈oB

Reporting Page

HPUX 11i v2

trbTiTAN

PRESENTATION 서버

WAS

JSP

WA

S-TPM

모듈

Servlet

WA

S-TPM

모듈oB

Reporting Page

HPUX 11i v2

trbTiTAN

PRESENTATION 서버

WAS

JSP

WA

S-TPM

모듈

Servlet

WA

S-TPM

모듈oB

Reporting Page

HPUX 11i v2

trbTiTAN

PRESENTATION 서버

WAS

JSP

WA

S-TPM

모듈

Servlet

WA

S-TPM

모듈oB

Reporting Page

HPUX 11i v2

trbTiTAN

PRESENTATION 서버

WASJSP

WA

S-TPM

연계

Servlet

Web Server Reporting Page

UNIX

trbTiTAN

AP 서버PROFRAME

서비스

DB

I/O

TPM

Entry

서비스

HPUX 11i v2

Veritas Cluster SVR

대용량 배치

Control-M/Agent

기타 배치

AP 서버PROFRAME

서비스

DB

I/O

TPM

Entry

서비스

HPUX 11i v2

Veritas Cluster SVR

대용량 배치

Control-M/Agent

기타 배치

AP 서버PROFRAME

서비스

DB

I/O

TPM

Entry

서비스

HPUX 11i v2

Veritas Cluster SVR

대용량 배치

Control-M/Agent

기타 배치

AP 서버FrameWork

서비스

DB

I/O

TPM

Entry 서비스

UNIX

대용량 배치

Control-M/Agent

기타 배치

BATCH 서버PROFRAME

서비스

TPM

Entry

On-Demand 배치

Control-M/Agent대용량 배치

WMQI/F

서비스I/F

서비스

HPUX 11i v2Veritas Cluster SVR

서비스fork

fork

BATCH 서버FrameWork

서비스

TPM

Entry

On-Demand 배치

Control-M/Agent대용량 배치

EAI 모듈I/F

서비스I/F

서비스

UNIX

서비스fork

fork

ClusterFile

System

Control-M 서버Job Control Server

UNIX

Job Controlr

채널통합 서버

UNIX

솔루션 미정

TP ADAPTOR

고객센터

Legacy 시스템Legacy 시스템

유 /무선 채널 시스템

채널통합서버

UNIX

MCI

Load Balance

Load Balance

EAI Hub 서버WMQi

IBM AIX 4.3

EAI 서버EAI

UNIX

DB 서버

ORACLE RAC 10g

MC/SG

Twins911 Green

DB 서버

ORACLE RAC 10g

HPUX 11i v2

MC/SG

Twins911 Green

DB 서버

ORACLE RAC 10g

HPUX 11i v2

MC/SG

Twins911 Green

DB 서버

DBMS

UNIX

DB

Archive Log

SQL*Net

tpcall

tpcall

tpcall

Http

tpcall

SSO Agent

18/44

아키텍처 구성도 ( 예 )

Ⅳ. 고려사항

20

고려사항

• 공유 스토리지 (NAS/NFS) 를 로컬 머신에 붙여서 데이터 공유• 별도의 파일 서버로 분리• DB 나 Memcached 활용

웹서버 이중화

데이터 동기화

• 전단에 L4(ELB) 를 두어 로드밸런싱• DNS 에 웹서버 IP 들을 등록하여 부하 분산• ZooKeeper 활용

Load Balancing

• 공유스토리지 이용 : 서버의 특정 디렉토리를 공유스토리지로 사용하여 Session 저장 (write 효율성 떨어짐 )• DBMS 활용 : 세션 정보를 DBMS 에 저장 (DB 서버 부하 )• Load Balacing : IP Hashing 방식 적용• Cookie 활용 : Seesion 으로 관리할 데이터를 암호화하여 Cookie에 저장

Session 공유

21

고려사항

• 1 Master & possibly multiple slaves• Master 에서 Slave 로 데이터 복제• Master (write), Slave(read)• Read transaction 의 scale out 을 통한 부하 분산용

DB 확장

Replication

Partitioning

Sharding

• Horizontal partitioning splits one or more tables by row, usually within a single instance of a schema and a database server. • Partition 은 저장할 데이터를 분할하여 관리함으로써 보다 빠른 데이터처리를 할 수 있도록 도와 준다 .• 하나의 큰 테이블을 사용할 경우 , 인덱스도 커지고 query 성능이 나오지 않을 때 사용

• Divide the data between multiple tables in separate Data Instances• 애플리케이션 서버에서 샤딩 로직 구현하는 형태 , Spock Proxy, Gizzard 와 같은 middle tier 로 동작하는 형태 , nStore 나 MongoDB 와 같이 DB 자체에서 샤딩기능을 제공하는 형태로 나눌 수 있음• MongoDB Sharding - MongoDB supports an automated sharding/partitioning architecture, enabling horizontal scaling across multiple nodes.• 테이블 사이즈가 크고 Writing Query 가 많은 경우

22

고려사항

Replication

23

고려사항

Partitioning

24

고려사항

Sharding

25

참고자료•WAS vs TPM 아키텍처 : tmaxsoft.wikispaces.com/file/view/WAS_vs_TPM_아키텍처.ppt

•안정적인 정보 서비스를 위한 시스템 아키텍처 : www.b2en.com/etc2sInc/down.asp?par1=4&no=101&par2=1

•Web 기반 아키텍처 : http://hyeonstorage.tistory.com/106

26

감사합니다 .