sytem architecture
DESCRIPTION
Sytem Architecture. Eric Lim AKAON. Ⅳ. 고려사항. Ⅰ. 아키텍처 개요. Ⅱ. 아키텍처 물리 설계. Ⅲ. 아키텍처 구성도 ( 예 ). Ⅰ. 아키텍처 개요. 시스템 구축 시 고려 사항. 아키텍처 설계 원칙. 중점 고려사항을 기반으로 대규모 트랜잭션 성능 보장 , 아키텍쳐 확장성 보장 , 서비스 고가용성 보장 , 운영관리 효율성 , 시스템 보안 강화의 5 가지 아키텍처 설계 원칙을 정의함. 아키텍처 설계 원칙. 기술 제약 사항. - PowerPoint PPT PresentationTRANSCRIPT
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
감사합니다 .