Download
1 / 26
500 likes | 1.66k Views
Sytem Architecture. Eric Lim AKAON. Ⅳ. 고려사항. Ⅰ. 아키텍처 개요. Ⅱ. 아키텍처 물리 설계. Ⅲ. 아키텍처 구성도 ( 예 ). Ⅰ. 아키텍처 개요. 시스템 구축 시 고려 사항. 아키텍처 설계 원칙. 중점 고려사항을 기반으로 대규모 트랜잭션 성능 보장 , 아키텍쳐 확장성 보장 , 서비스 고가용성 보장 , 운영관리 효율성 , 시스템 보안 강화의 5 가지 아키텍처 설계 원칙을 정의함. 아키텍처 설계 원칙. 기술 제약 사항.
E N D
Sytem Architecture Eric Lim AKAON
Ⅳ. 고려사항 Ⅰ. 아키텍처 개요 Ⅱ. 아키텍처 물리 설계 Ⅲ. 아키텍처 구성도 (예)
시스템 구축 시 고려 사항 아키텍처 설계 원칙 • 중점 고려사항을 기반으로 대규모 트랜잭션 성능 보장, 아키텍쳐 확장성 보장, 서비스 고가용성 보장, 운영관리 효율성, 시스템 보안 강화의 5가지 아키텍처 설계 원칙을 정의함. 아키텍처 설계 원칙 기술 제약 사항 • Planned/Unplanned Downtime 최소화 설계 • Hot Deployment 확보를 통한 가용성 확보 대규모 Transaction 처리 및 온라인 성능 보장 • DB 서버의 부하를 최대한 경감하는 방안 고려 • 수직 확장성이 높은 H/W 또는 분산 DB 검토 아키텍처 확장성 보장 기술 요구 사항 • UI 개발 TOOL • 미들웨어 기반 기술에 적합한 아키텍쳐 설계 • 개발 F/W 도입에 따른 개발 및 인터페이스 방식 검토 서비스 고 가용성 보장 As-Is Unix 운영상의 문제점 • 장애 발생을 감안한 용량 산정 • 데이터 손실없이 신속히 서비스를 복구할 수 있는 아키텍쳐 설계 운영 관리 효율성 • 장애 예방(정기점검,유지보수)을 위한 Planned Down Time 확보 • 트랜잭션 부하 폭증에 대한 대처방안 수립 시스템 보안 강화 • 대용량 트랜잭션 및 Storage 운영 관리에 적합한 서버, Storage 물리설계
아키텍처 설계 방안 • 아키텍처 설계 원칙별로 구체적인 아키텍처 설계 방안을 수립함. 아키텍처 설계 원칙 아키텍처 설계 방안 대규모 트랜잭션 처리 및 온라인 성능 보장 DB용량 경량화 피크타임 용량 확보 대용량 배치 처리 부하 분산 최적화 아키텍처 확장성 보장 하드웨어 확장성 아키텍쳐 확장성 Multi-Tier 아키텍쳐 구성 장애 예방 서비스 Down Time 최소화 방안 비상 시스템 구성 방안 서비스 고가용성 보장 운영관리 효율성 개발 관리 방안 트랜잭션 관리 방안 성능 및 장애관리 방안 통합 백업관리 방안 시스템 보안 강화 정보 보호 전략 네트워크 보안 시스템 보안
아키텍처 설계 방안 대규모 트랜잭션 처리 및 온라인 성능 보장 피크타임 용량 확보 • 성능을 고려한 적정 성능 여유율 • 노드 구성에 따른 용량 산정 방법 • 장애를 고려한 용량 산정 • TPMC (Transaction Per Minute type C) • http://www.tpc.org/ • TPS (Transaction Per Second) • 배치업무는 장시간 수행되며, 대부분의 시스템 자원을 사용하게 됨 • OLTP와 배치 전용 DB노드를 물리적으로 분리하여 자원 경합 방지 대용량 배치 처리 • 전체적인 트랜잭션의 부하가 특정 Tier나 노드에 부하가 집중되지 않고, 서버간 균일한 부하 분산 되도록 구성 • Load Balancing 기능 사용 • Round Robin • Weight Round Robin • Least Connected • IP Hash • Response Time • Bandwidth 부하 분산 최적화 • 데이터가 커지면서 어플리케이션의 성능 저하 및 데이터 백업에 소요되는 비용 증가 • 거의 사용하지 않는 데이터는 아카이빙 시스템으로 이동 • Master성 데이터는 주 장비, 통계성 데이터는 아카이빙에 배치 • 이력 데이터는 기간별로 Cutting 필요 DB용량 경량화
아키텍처 설계 방안 아키텍처 확장성 보장 Multi-Tier 아키텍쳐 구성 • WEB, AP, DB 서버의 3-Tier로 구성 (권장) • WEB, AP 서버의경우 Scale Out 고려 • DB 서버의 경우, Scale Up 고려 • Scale-out : 시스템 유닛 증가를 통한 수평적인 확장. 장비 대수를 늘림으로 성능향상 • 분산처리/병렬처리가 주 목적. 상대적으로 저렴하지만 분산처리 SW 및 아키텍처 필요 • Scale-up : 시스템 내 CPU, Memory, Disk 등 파워 및 용량 확장을 통한 수직적인 확장 • 즉, 장비 대수는 그대로 두고 부품만 추가하여 성능확장 하드웨어 확장성
아키텍처 설계 방안 서비스고가용성 보장 트랜잭션 통제/관리의 효율성 • 기존 시스템들과의 연계 및 인터페이스 통제/관리 필요 • 다양한 형태로 접근되는 사용자의 접근 경로가 관리되지 않을 경우, 성능 및 안정성에 많은 영향을 미침 • 다른 시스템이 사용하고 있는 인터페이스 변경 또는 제거 시 타 시스템 장애 유발 • 사용자의 접근 경로에 대한 단일화 및 트랜젝션 제어 필요 성능 관리 방안 • 초기 구축 시점에 성능을 위한 튜닝 실시 • - 데이터가 증가하고 기존 데이터가 변경됨 => 지속적 성능 관리 필요 • 페이지별 응답속도 분석, IO 성능 분석 • 성능관리를 목표로 하는 Factor를 선정하여 집게된 데이터를 체계적인 분석 필요 통합 백업 관리
아키텍처 설계 방안 운영관리 효율성 보장 장애 예방 • 하드웨어 장비의 이중화 구성을 통한 Single Point of Failure 방지 • 스토리지 복제 기술 등을 이용한 데이터 손실 방지 • Clustering 기술을 통해자동으로 Fail Over 가능하도록 설계 • 운영자 실수나 장애 예방을 위한 사전 인프라 테스트 환경 구성 • 정기적인 점검을 통한 장애 예방 (daily/weekly check list) 서비스 Down Time 최소화 방안 • Planned Down Time • - OS upgrade, 대규모 Application Upgrade, 장애 예방을 위한 정기점검, Storage 증설 등 • unPlanned Down Time • - 이중화된 서버/스토리지 부품의 동시 장애, DBMS 장애, 네트워크 장애 등 • Down Time 요소를 명확히 정의하고, 이에 따른 예방 대책 강구 (운영매뉴얼 : 긴급복구 SOP) • 천재지변과 같은 상황으로 시스템 자체의 운영이 불가능할 경우 별도의 원격지에 이를 대비할 수 있는 비상 시스템 구축 고려 • 비상 시스템으로의 전환 절차 • 주 업무시스템의 정상 복구 이후 변경/추가된 데이터에 대한 정합성 확인 비상 시스템 구성 방안
아키텍처 물리설계 • 1-Tier 구성 : 하나의 머신에 웹기반 아키텍처 요소를 모두 포함하는 구성
아키텍처 물리설계 • 2-Tier 구성 : 웹 기반 아키텍처 요소를 두개의 머신에 배치하는 구성 방식. • 웹 서버와 WAS를 하나의 머신에 배치하고 DBMS를 나머지 머신에배치하는 방법. • 웹서버를 별도의 머신에 배치하고 나머지 WAS와 DBMS를 다른 머신에 배치하는 방법. • 경우에 따라 머신과 머신 사이에 방화벽을 설정할 수 있다.
아키텍처 물리설계 • 3-Tier 구성 : 웹 서버, WAS, DBMS 를 모두 다른 머신에 배치하여 구성하는 방식
아키텍처 물리설계 • 대규모 3-Tier 구성 : 로드 발란스를 이용하여 3-Tier 구성을 확장하는 구성 방식. 웹 시스템의 사용자가 많은 엔터프라이즈 어플리케이션일 경우 대부분 대규모 3-Tier 구성을 이용하고 있다.
아키텍처 물리설계 • 시스템 구성 요건에 따라 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 와 비즈니스 로직을 분리하지 못할 경우 • 제안된 인증 사용자만 시스템 접근일 경우 • 데이터 및 비즈니스 로직이 유출되더라도 보안상 문제가 없을 경우 • 사내 시스템이거나 인증된 외부기관 과의 전용선을 통한 시스템간 인터페이스
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 시스템
고려사항 웹서버이중화 데이터 동기화 • 공유 스토리지 (NAS/NFS)를로컬 머신에 붙여서 데이터 공유 • 별도의 파일 서버로 분리 • DB나 Memcached 활용 Load Balancing • 전단에 L4(ELB)를 두어 로드밸런싱 • DNS에 웹서버 IP들을 등록하여 부하 분산 • ZooKeeper 활용 Session 공유 • 공유스토리지 이용 : 서버의 특정 디렉토리를 공유스토리지로 사용하여 Session 저장 (write 효율성 떨어짐) • DBMS 활용 : 세션 정보를 DBMS에 저장 (DB서버 부하) • Load Balacing : IPHashing 방식 적용 • Cookie 활용 : Seesion으로관리할 데이터를 암호화하여 Cookie에 저장
고려사항 DB 확장 Replication • 1 Master & possibly multiple slaves • Master에서 Slave로 데이터 복제 • Master (write), Slave(read) • Read transaction의 scale out을 통한 부하 분산용 Partitioning • Horizontal partitioning splits one or more tables by row, usually within a single instance of a schema and a database server. • Partition은 저장할 데이터를 분할하여 관리함으로써 보다 빠른 데이터처리를 할 수 있도록 도와 준다. • 하나의 큰 테이블을 사용할 경우, 인덱스도 커지고 query 성능이 나오지 않을 때 사용 Sharding • 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. • 테이블 사이즈가 크고 WritingQuery가 많은 경우
고려사항 Replication
고려사항 Partitioning
고려사항 Sharding
참고자료 • 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
