0 Sytem Architecture Eric Lim AKAON

1/44 Ⅰ. 아키텍처 개요 Ⅱ. 아키텍처 물리 설계 Ⅲ. 아키텍처 구성도 ( 예 ) Ⅳ. 고려사항

Ⅰ. 아키텍처 개요

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

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

5 성능을 고려한 적정 성능 여유율 노드 구성에 따른 용량 산정 방법 장애를 고려한 용량 산정 배치업무는 장시간 수행되며, 대부분의 시스템 자원을 사용하게 됨 OLTP 와 배치 전용 DB 노드를 물리적으로 분리하여 자원 경합 방지 전체적인 트랜잭션의 부하가 특정 Tier 나 노드에 부하가 집중되지 않고, 서버간 균일한 부하 분산 되도록 구성 Load Balancing 기능 사용 데이터가 커지면서 어플리케이션의 성능 저하 및 데이터 백업에 소요되는 비용 증가 거의 사용하지 않는 데이터는 아카이빙 시스템으로 이동 Master 성 데이터는 주 장비, 통계성 데이터는 아카이빙에 배치 이력 데이터는 기간별로 Cutting 필요 TPMC (Transaction Per Minute type C) TPS (Transaction Per Second) 대규모 트랜잭션 처리 및 온라인 성능 보장 아키텍처 설계 방안 피크타임 용량 확보 대용량 배치 처리 부하 분산 최적화 DB 용량 경량화 Round Robin Weight Round Robin Least Connected IP Hash Response Time Bandwidth

6 WEB, AP, DB 서버의 3-Tier 로 구성 ( 권장 ) WEB, AP 서버의 경우 Scale Out 고려 DB 서버의 경우, Scale Up 고려 Scale-out : 시스템 유닛 증가를 통한 수평적인 확장. 장비 대수를 늘림으로 성능향상 분산처리 / 병렬처리가 주 목적. 상대적으로 저렴하지만 분산처리 SW 및 아키텍처 필요 Scale-up : 시스템 내 CPU, Memory, Disk 등 파워 및 용량 확장을 통한 수직적인 확장 즉, 장비 대수는 그대로 두고 부품만 추가하여 성능확장 아키텍처 확장성 보장 아키텍처 설계 방안 Multi-Tier 아키텍쳐 구성 하드웨어 확장성

7 기존 시스템들과의 연계 및 인터페이스 통제 / 관리 필요 다양한 형태로 접근되는 사용자의 접근 경로가 관리되지 않을 경우, 성능 및 안정성에 많은 영향을 미침 다른 시스템이 사용하고 있는 인터페이스 변경 또는 제거 시 타 시스템 장애 유발 사용자의 접근 경로에 대한 단일화 및 트랜젝션 제어 필요 초기 구축 시점에 성능을 위한 튜닝 실시 - 데이터가 증가하고 기존 데이터가 변경됨 => 지속적 성능 관리 필요 페이지별 응답속도 분석, IO 성능 분석 성능관리를 목표로 하는 Factor 를 선정하여 집게된 데이터를 체계적인 분석 필요 서비스 고가용성 보장 아키텍처 설계 방안 트랜잭션 통제 / 관리의 효율성 성능 관리 방안 통합 백업 관리

8 하드웨어 장비의 이중화 구성을 통한 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 최소화 방안 비상 시스템 구성 방안

Ⅱ. 아키텍처 물리설계

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

11 아키텍처 물리설계 2-Tier 구성 : 웹 기반 아키텍처 요소를 두개의 머신에 배치하는 구성 방식. 웹 서버와 WAS 를 하나의 머신에 배치하고 DBMS 를 나머지 머신에배치하는 방법. 웹서버를 별도의 머신에 배치하고 나머지 WAS 와 DBMS 를 다른 머신에 배치하는 방법. 경우에 따라 머신과 머신 사이에 방화벽을 설정할 수 있다.

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

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

14 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 아키텍쳐를 권고함. 권고안

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

16/44 아키텍처 구성도 ( 예 ) Web Zone AP ZoneDB Zone User Channel Client Load Balance PRESENTATION 서버 WAS JSP Servlet Reporting Page HPUX 11i v2 trbTiTAN PRESENTATION 서버 WAS JSP Servlet Reporting Page HPUX 11i v2 trbTiTAN PRESENTATION 서버 WAS JSP Servlet Reporting Page HPUX 11i v2 trbTiTAN PRESENTATION 서버 WAS JSP Servlet Reporting Page HPUX 11i v2 trbTiTAN PRESENTATION 서버 WAS JSP Servlet Reporting Page HPUX 11i v2 trbTiTAN PRESENTATION 서버 WAS JSP 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 대용량 배치 WMQ I/F 서비스 HPUX 11i v2 Veritas Cluster SVR 서비스 fork BATCH 서버 FrameWork 서비스 TPM Entry On-Demand 배치 Control-M/Agent 대용량 배치 EAI 모듈 I/F 서비스 UNIX 서비스 fork Cluster File System Control-M 서버 Job Control Server UNIX Job Controlr 채널통합 서버 UNIX 솔루션 미정 TP ADAPTOR 고객센터 Legacy 시스템 유 / 무선 채널 시스템 채널통합서버 UNIX MCI 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 Http tpcall SSO Agent

17/44 아키텍처 구성도 ( 예 )

Ⅳ. 고려사항

19 고려사항 공유 스토리지 (NAS/NFS) 를 로컬 머신에 붙여서 데이터 공유 별도의 파일 서버로 분리 DB 나 Memcached 활용 웹서버 이중화 데이터 동기화 전단에 L4(ELB) 를 두어 로드밸런싱 DNS 에 웹서버 IP 들을 등록하여 부하 분산 ZooKeeper 활용 Load Balancing 공유스토리지 이용 : 서버의 특정 디렉토리를 공유스토리지로 사용하여 Session 저장 (write 효율성 떨어짐 ) DBMS 활용 : 세션 정보를 DBMS 에 저장 (DB 서버 부하 ) Load Balacing : IP Hashing 방식 적용 Cookie 활용 : Seesion 으로 관리할 데이터를 암호화하여 Cookie 에 저장 Session 공유

20 고려사항 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 가 많은 경우

21 고려사항 Replication

22 고려사항 Partitioning

23 고려사항 Sharding

24 참고자료 WAS vs TPM 아키텍처 : tmaxsoft.wikispaces.com/file/view/WAS_vs_TPM_ 아키텍처.ppt 안정적인 정보 서비스를 위한 시스템 아키텍처 : Web 기반 아키텍처 :

25 감사합니다.