Transcript 한국생산성본부 교육 자료

Sytem Architecture
Eric Lim
AKAON
0
Ⅰ. 아키텍처 개요
Ⅱ. 아키텍처 물리 설계
Ⅲ. 아키텍처 구성도 (예)
Ⅳ. 고려사항
1/44
Ⅰ. 아키텍처 개요
아키텍처 설계 원칙
중점 고려사항을 기반으로 대규모 트랜잭션 성능 보장, 아키텍쳐 확장성 보장, 서비스 고가용성 보장,
운영관리 효율성, 시스템 보안 강화의 5가지 아키텍처 설계 원칙을 정의함.
시스템 구축 시 고려 사항
아키텍처 설계 원칙
기술 제약
사항
• Planned/Unplanned Downtime 최소화 설계
• Hot Deployment 확보를 통한 가용성 확보
• DB 서버의 부하를 최대한 경감하는 방안 고려
대규모 Transaction 처리
및 온라인 성능 보장
• 수직 확장성이 높은 H/W 또는 분산 DB 검토
기술 요구
사항
• UI 개발 TOOL
• 미들웨어 기반 기술에 적합한 아키텍쳐 설계
아키텍처 확장성 보장
• 개발 F/W 도입에 따른 개발 및 인터페이스 방식 검토
서비스 고 가용성 보장
As-Is
Unix
운영상의
문제점
• 장애 발생을 감안한 용량 산정
• 데이터 손실없이 신속히 서비스를 복구할 수 있는 아키
텍쳐 설계
• 장애 예방(정기점검,유지보수)을 위한 Planned Down
Time 확보
• 트랜잭션 부하 폭증에 대한 대처방안 수립
• 대용량 트랜잭션 및 Storage 운영 관리에 적합한 서버,
Storage 물리설계
3
운영 관리 효율성
시스템 보안 강화
아키텍처 설계 방안
아키텍처 설계 원칙별로 구체적인 아키텍처 설계 방안을 수립함.
아키텍처 설계 원칙
아키텍처 설계 방안
대규모 트랜잭션 처리
및 온라인 성능 보장
피크타임 용량
확보
대용량 배치 처리
부하 분산 최적화
아키텍처 확장성 보장
Multi-Tier
아키텍쳐 구성
하드웨어 확장성
아키텍쳐 확장성
서비스 고가용성 보장
장애 예방
서비스 Down
Time 최소화
방안
비상 시스템 구성
방안
운영관리 효율성
트랜잭션 관리
방안
성능 및 장애관리
방안
통합 백업관리
방안
시스템 보안 강화
정보 보호 전략
네트워크 보안
시스템 보안
4
DB용량 경량화
개발 관리 방안
아키텍처 설계 방안
대규모 트랜잭션 처리 및 온라인 성능 보장
피크타임 용량
확보
• 성능을 고려한 적정 성능 여유율
• 노드 구성에 따른 용량 산정 방법
• 장애를 고려한 용량 산정
• TPMC (Transaction Per Minute type C)
•
http://www.tpc.org/
• TPS (Transaction Per Second)
대용량 배치 처리
• 배치업무는 장시간 수행되며, 대부분의 시스템 자원을 사용하게 됨
• OLTP와 배치 전용 DB노드를 물리적으로 분리하여 자원 경합 방지
부하 분산 최적화
• 전체적인 트랜잭션의 부하가 특정 Tier나 노드에 부하가 집중되지
않고, 서버간 균일한 부하 분산 되도록 구성
• Load Balancing 기능 사용
DB용량 경량화
• 데이터가 커지면서 어플리케이션의 성능 저하 및 데이터 백업에
소요되는 비용 증가
• 거의 사용하지 않는 데이터는 아카이빙 시스템으로 이동
• Master성 데이터는 주 장비, 통계성 데이터는 아카이빙에 배치
• 이력 데이터는 기간별로 Cutting 필요
5
•
•
•
•
•
•
Round Robin
Weight Round Robin
Least Connected
IP Hash
Response Time
Bandwidth
아키텍처 설계 방안
아키텍처 확장성 보장
Multi-Tier
아키텍쳐 구성
하드웨어 확장성
• WEB, AP, DB 서버의 3-Tier로 구성 (권장)
• WEB, AP 서버의 경우 Scale Out 고려
• DB 서버의 경우, Scale Up 고려
• Scale-out : 시스템 유닛 증가를 통한 수평적인 확장. 장비 대수를 늘림으로 성능향상
분산처리/병렬처리가 주 목적. 상대적으로 저렴하지만 분산처리 SW 및 아키텍처 필요
• Scale-up : 시스템 내 CPU, Memory, Disk 등 파워 및 용량 확장을 통한 수직적인 확장
즉, 장비 대수는 그대로 두고 부품만 추가하여 성능확장
6
아키텍처 설계 방안
서비스 고가용성 보장
트랜잭션
통제/관리의
효율성
• 기존 시스템들과의 연계 및 인터페이스 통제/관리 필요
• 다양한 형태로 접근되는 사용자의 접근 경로가 관리되지 않을
경우, 성능 및 안정성에 많은 영향을 미침
• 다른 시스템이 사용하고 있는 인터페이스 변경 또는 제거 시
타 시스템 장애 유발
• 사용자의 접근 경로에 대한 단일화 및 트랜젝션 제어 필요
• 초기 구축 시점에 성능을 위한 튜닝 실시
성능 관리 방안
- 데이터가 증가하고 기존 데이터가 변경됨 => 지속적 성능 관리
필요
• 페이지별 응답속도 분석, IO 성능 분석
• 성능관리를 목표로 하는 Factor를 선정하여 집게된 데이터를
체계적인 분석 필요
통합 백업 관리
7
아키텍처 설계 방안
운영관리 효율성 보장
장애 예방
•
•
•
•
•
하드웨어 장비의 이중화 구성을 통한 Single Point of Failure 방지
스토리지 복제 기술 등을 이용한 데이터 손실 방지
Clustering 기술을 통해 자동으로 Fail Over 가능하도록 설계
운영자 실수나 장애 예방을 위한 사전 인프라 테스트 환경 구성
정기적인 점검을 통한 장애 예방 (daily/weekly check list)
• Planned Down Time
서비스 Down
Time 최소화
방안
비상 시스템 구성
방안
- OS upgrade, 대규모 Application Upgrade, 장애 예방을 위한 정기점검,
Storage 증설 등
• unPlanned Down Time
- 이중화된 서버/스토리지 부품의 동시 장애, DBMS 장애, 네트워크 장애 등
• Down Time 요소를 명확히 정의하고, 이에 따른 예방 대책 강구
(운영매뉴얼 : 긴급복구 SOP)
• 천재지변과 같은 상황으로 시스템 자체의 운영이 불가능할 경우 별도의
원격지에 이를 대비할 수 있는 비상 시스템 구축 고려
• 비상 시스템으로의 전환 절차
• 주 업무시스템의 정상 복구 이후 변경/추가된 데이터에 대한 정합성 확인
8
Ⅱ. 아키텍처 물리설계
아키텍처 물리설계
1-Tier 구성 : 하나의 머신에 웹기반 아키텍처 요소를 모두 포함하는 구성
10
아키텍처 물리설계
2-Tier 구성 : 웹 기반 아키텍처 요소를 두개의 머신에 배치하는 구성 방식.
웹 서버와 WAS를 하나의 머신에 배치하고 DBMS를 나머지 머신에배치하는 방법.
웹서버를 별도의 머신에 배치하고 나머지 WAS와 DBMS를 다른 머신에 배치하는 방법.
경우에 따라 머신과 머신 사이에 방화벽을 설정할 수 있다.
11
아키텍처 물리설계
3-Tier 구성 : 웹 서버, WAS, DBMS 를 모두 다른 머신에 배치하여 구성하는 방식
12
아키텍처 물리설계
대규모 3-Tier 구성 : 로드 발란스를 이용하여 3-Tier 구성을 확장하는 구성 방식. 웹 시스템의 사용자가
많은 엔터프라이즈 어플리케이션일 경우 대부분 대규모 3-Tier 구성을 이용하고 있다.
13
아키텍처 물리설계
시스템 구성 요건에 따라 3-Tier, 2-Tier, 1-Tier 아키텍쳐 구조로 구성할 수 있으며, 3-Tier 아키텍쳐를
권고함.
권고안
3 – Tier 아키텍쳐
Presentation서버,AP서버,DB서버
3대 이상 구성
아키텍쳐
구조
Presentation서버
UI 로직
특징
설계
가이드
2 – Tier 아키텍쳐
AP서버, DB서버 2대 이상 구성
1 – Tier 아키텍쳐
AP/ DB서버 1대 이상 구성
AP서버
DB서버
AP서버
DB서버
AP/DB서버
비즈니스 로직
데이터
UI + 비즈니스 로직
데이터
비즈니스 로직 + 데이터
• 대용량 OLTP 업무
• 데이터 및 비즈니스 로직 유출
방지 용이.
• 물리적 노드수가 최소 3개 이상
필요
• Tier간 네트워크 트래픽 발생.
• 일반 OLTP 업무
• 비즈니스 로직 유출이 발생할 수
있음.
• 물리적 노드수가 최소 2개 이상
필요.
• AP와 DB서버간 네트워크 트래픽
발생
• UI 로직이 없는 인터페이스 G/W
업무
• 데이터 및 비즈니스 로직이 유출
가능.
• 물리적 노드수가 최소 1개로 구성
가능
• Tier간 네트워크 트래픽 없음.
• 아키텍쳐 기본 권고안
• 높은 수준의 보안이 요구될 경우
• 대용량 온라인 트랜잭션 처리
업무
• 성능 및 확장성이 보장되어야 할
경우
• 비즈니스 로직이 유출되더라도
보안상 문제가 없을 경우
• UI 와 비즈니스 로직을 분리하지
못할 경우
• 제안된 인증 사용자만 시스템
접근일 경우
• 데이터 및 비즈니스 로직이
유출되더라도 보안상 문제가 없을
경우
• 사내 시스템이거나 인증된
외부기관 과의 전용선을 통한
시스템간 인터페이스
14
Ⅲ. 아키텍처 구성도 (예)
아키텍처 구성도 (예)
User Channel
Web Zone
AP Zone
AP
AP 서버
서버
AP 서버
AP 서버
FrameWork
기타 배치
PROFRAME
기타
배치
PROFRAME
기타
PROFRAME
기타배치
배치
대용량
대용량
배치
대용량
서비
대용량
서비
서비스
서비
서비
배치
서비스
서비
배치
서비
배치
스
스
스
스
스
스
ControlControlControlControlM/Agent
M/Agent
M/Agent
M/Agent
TPM
TPM
DBI/O
I/O
DB
tpcall
FrameWork
PROFRAME
fork
forkOn-Demand
On-Demand
서비스
서비스
배치
서비스
서비스
배치
I/F
I/F
I/F
fork
I/F fork
서비스
서비스
모듈
서비스 EAIWMQ
서비스
TPM
TPM
Control-M/Agent
Control-M/Agent
고객센터
Load Balance
유/무선 채널
시스템
tpcall
BATCH
BATCH서버
서버
대용량
대용량
배치
배치
Veritas Cluster SVR
UNIX
HPUX
11i v2
EAIHub
서버
EAI
서버
EAI
WMQi
UNIX
IBM
AIX 4.3
Legacy 시스템
16/44
SQL*Net
Cluster
File
System
Entry
Entry
솔루션MCI TP
미정 ADAPTOR
UNIX
UNIX
TPM
TPM
Veritas
Cluster SVR
Veritas
VeritasCluster
ClusterSVR
SVR
UNIX
HPUX
11i v2
HPUX
HPUX11i
11iv2
v2
tpcall
DB 서버
DB 서버
DB 서버
DB 서버
DBI/O
I/O
DB
tpcall
UNIX11i v2
HPUX
HPUX
11i
HPUX
11iv2
v2
HPUX
HPUX11i
11iv2
v2
채널통합서버
채널통합 서버
Entry
Entry
JSP
JSP
JSP
JSP
Servlet
Servlet
Reporting
Page
Servlet
Servlet
Servlet 연
Reporting
모모
Reporting
trbTiTAN
계
모모
Reporting
모
Page
듈듈
Reporting
모
Page
Reporting 듈모
모
Page
모
듈
듈
Page
모
듈
듈
Page
듈SSOtrbTiTAN
Agent
듈
trbTiTAN
듈
trbTiTAN
trbTiTAN
trbTiTAN
ServletJSP
Entry
Entry
WAS-TPM
oB
WAS-TPM
oB
WAS-TPM
oB
WAS-TPM
oB
WAS-TPM
Web Server oB
Http
Load Balance
Client
WAS-TPM
WAS-TPM
WAS-TPM
WAS-TPM
WAS-TPM
WAS-TPM
PRESENTATION 서버
PRESENTATION
서버
PRESENTATION
서버
PRESENTATION
서버
PRESENTATION
서버
PRESENTATION
서버
WAS
WAS
WAS
WAS
JSP
WAS
WAS
DB Zone
Job Control Server
Control-M 서버
Job Controlr
UNIX
Twins911 Green
Twins911 Green
Twins911 Green
DBMS
ORACLE RAC 10g
ORACLE RAC 10g
ORACLE RAC 10g
MC/SG
MC/SG
MC/SG
UNIX
HPUX 11i v2
HPUX 11i v2
DB
Archive
Log
아키텍처 구성도 (예)
17/44
Ⅳ. 고려사항
고려사항
웹서버 이중화
데이터 동기화
Load Balancing
Session 공유
• 공유 스토리지 (NAS/NFS)를 로컬 머신에 붙여서 데이터 공유
• 별도의 파일 서버로 분리
• DB나 Memcached 활용
• 전단에 L4(ELB)를 두어 로드밸런싱
• DNS에 웹서버 IP들을 등록하여 부하 분산
• ZooKeeper 활용
• 공유스토리지 이용 : 서버의 특정 디렉토리를 공유스토리지로
사용하여 Session 저장 (write 효율성 떨어짐)
• DBMS 활용 : 세션 정보를 DBMS에 저장 (DB서버 부하)
• Load Balacing : IP Hashing 방식 적용
• Cookie 활용 : Seesion으로 관리할 데이터를 암호화하여 Cookie에
저장
19
고려사항
DB 확장
Replication
Partitioning
Sharding
•
•
•
•
1 Master & possibly multiple slaves
Master에서 Slave로 데이터 복제
Master (write), Slave(read)
Read transaction의 scale out을 통한 부하 분산용
• 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가 많은 경우
20
고려사항
Replication
21
고려사항
Partitioning
22
고려사항
Sharding
23
참고자료
•
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
24
감사합니다.
25