제 1 장 H/W 용량산정개념및현황 제 1 절용량산정개요 1. 용량산정개념 용량계획 (Capacity planning) 과시스템규모산정혹은용량산정이라는용어가혼용되어사용되고있다. 이들간에는어떠한차이가있을까? 여기에서용량계획과시스템규모산정그리고용량산정에대한개념을정의한다. 우선, 용량계획이라함은개략적인시스템아키텍처와응용업무를기반으로시스템에요구되는성능요구사항과성능을결정하기위한계획으로이해할수있다. 일반적으로이러한용량계획은다음과같은사항을다룬다. 클라이언트어플리케이션의형태이들응용들에접근하는사용자의수클라이언트어플리케이션의동작특성서버시스템에대응하는오퍼레이션의형태서버시스템에접속하는동시접속자의수서버시스템에의해서수행되어져야하는피크율피크타임하에서의여유율등 이에반해서기본적인용량과성능요구사항이제시되었을때, 그것을 시스템요구사항으로변환하는것을시스템규모산정이라고부른다. 일반적으로이러한시스템규모산정시에결정하는요소는다음과같다. 서버컴퓨터의 CPU 의형태나수 1
서버컴퓨터의디스크서브시스템의크기나형태 서버컴퓨터의메모리크기 이를정리하면용량계획과시스템규모산정은다음표와같이정의할 수있다. [ 표 4-1] 용량계획과시스템규모산정의정의 구분정의비고 용량계획 (Capacity planning) 시스템규모산정 (System Sizing) 시스템의아키텍처와응용기반을전제로용량요구사항과성능을결정하는것으로구성할시스템의용량산정을위한계획 실제업무와응용을기반으로수학적인방법론을사용하여도입하고자하는시스템의용량을계산하는것 위의정의에서보듯이시스템규모산정은실제업무와응용을기반으로수학적인방법론을사용하여도입하고자하는시스템의용량을계산하는것으로시스템의아키텍처와응용기반을전제로용량요구사항과성능을결정하는용량계획과차이가있으며일반적으로사용하는용량산정의경우, 용량계획보다는시스템규모산정을의미하므로본연구에서는용량산정과시스템규모산정을동일한의미로사용한다. 2. 용량산정절차 공공부문정보화사업에있어서시스템규모산정은첫째, 공공기관에서 정보화사업을입안, 예산을요청하는시점, 그리고배정된예산을토대로 사업발주를하는시점에주로이루어진다. 이두가지경우에 있어서 정확한용량산정을위해서는사전에충분한용량계획이수립되어야한다. 그러나 정보화사업의 실행 전에 전반적인 사업에 대한 정보화 전략계획 (ISP) 이수립되어져있어야하겠지만 대부분의 정보화사업이 그렇지않은현실이다. 2
한편용량산정의기본적인절차는용량데이터의수집, 규모산정그리고 검토단계등으로구성되며세부적인내용은아래그림과같다. [ 그림 4-1] 용량산정절차및내용 위그림에서용량산정의범위는앞에서정의한바와같이규모산정단계에해당한다. 즉, 규모산정의전제조건을설정하고규모의유형을결정하며, 보정계수를결정하며산정식에따라규모를산정하는것이다. 그러나앞서언급한바와같이정보화전략계획을전제로하지않은용량산정결과의정확성을높이기위해서규모산정이전의수립단계인용량데이터의수집단계를포함하여본연구에서는용량산정의범위로규정한다. 3
제 2 절용량산정현황및사례 1. 국내 H/W 용량산정현황 정보화시대의도래에따라사회적으로정보인프라구축에대한관심이고조되고있으며, 효율적인업무처리, 고객서비스개선등을위해다양한정보시스템이구축되고있다. 공공기관의정보시스템에대한성능개선과도입을위한명확한규모산정기준이없어서정보시스템구축을추진하는기관혹은시스템공급자의주관적방법에따라정보시스템의자원규모를산정하고있다. 이로인하여규모의과다혹은축소산정등의문제가발생하고있으며, 정보화예산의낭비와서비스저하라는지적이빈번히발생하고있다. 공공기관의정보인프라의도입과관련한이러한논쟁의주요대상은정보시스템의 CPU 산정과관련된부분이다. 이는메모리나디스크와같은기억장치는 H/W 기술발전에따라전체시스템도입비용에서차지하는비중이작아지고있는추세이며, CPU 에비해산정방식이객관화될수있으므로상대적으로논란이덜한편이다. 그러나 CPU 의경우용량산정을위한산정방식과 CPU 의성능을평가하기위한기준이일원화되어있지않으며, CPU 의처리능력에따라서버장비의가격이많은차이를갖게되기때문이다. 한편, 공공기관들은국내의정보시스템의 CPU 용량산정시국제적인공신력을갖고있으며, 하드웨어및소프트웨어의트랜잭션처리능력을평가하는기관인 TPC 의 tpmc 를사용하고있는추세이다. 이러한주요원인은공공기관의사용자들의성향에기인한것으로대부분이 tpmc 에친숙함에따라 H/W 를발주하는시점에서내부적인용량산정을통해서제안하는 H/W 의용량은 tpmc 를기반으로하고있다. 그러나 tpmc 를기반으로한 H/W 용량산정및성능평가에는많은논란을일으키고있다. 그이유는다음과같다. 4
첫째, CPU 의용량을산정하기위한산정기준의상이함이다. [ 표 4-2] 에서제시한바와같이 CPU 용량산정을위한 H/W 벤더혹은 SI 업체의산정항목이나지표혹은보정치가상이하다는점이다. 특히, 지표나보정치의경우용량산정을수행하는시스템설계자의경험에따라부여하는값이달라질수있으며, 동일한시스템환경에대해서많은차이를보일수있다. [ 표 4-2] CPU 산정기준비교 구분 항목 기준치 NCA A 사 B 사 1 동시사용자수반영반영 2 분당트랜잭션수반영반영 3 기본 TPC 1.2( 소규모 )~ 1.3( 대규모 ) 고려하지않음 1.5 4 Peak Time 보정 1.2( 단순 ) ~ 1.3( 복잡 ) 1.3 반영 인트라넷, OLTP : 1.3 ~ 2 인터넷 : 3 5 CPU 부하보정 1.2( 작음 ) ~ 1.5( 큼 ) 고려하지않음데이터베이스크기 6 Application 복잡성 1.1( 단순 ) ~ 1.2( 복잡 ) 1.3 ~ 어플리케이션성격 7 사용자복잡성고려하지않음 1 ~ 4.5 고려하지않음 8 Application 구조고려하지않음 0.5 ~ 2.3 고려하지않음 9 Application Load 고려하지않음 1 ~ 3 고려하지않음 10 네트워크보정 1.1 1.3 ~ 1.5 고려하지않음 11 클러스터보정 1.2( 단순 ) ~ 1.5( 복잡 ) 1.3 ~ 2 12 여유율 1.2 ~ 1.5 1.3 ~ 1.5 클러스터부하 : 1.3 HA 클러스터구성환경 : 1.2 PDB 클러스터환경구성 : 1.4 시스템의 70% 범위내운용권장 1/0.7 = 1.43 둘째, 성능평가치의객관성과신뢰성에대한문제이다. H/W 벤더들중일부벤더들은 TPC 의성능기준을적용하고있지않으며, 장비제안시성능기준을적용하여이를 tpmc 값으로치환하거나공인 tpmc 값이아닌 H/W 벤더내부의추정 tpmc 값을제시하고있다. 또한비록공인 tpmc 성능기준을사용하는 H/W 벤더역시 H/W 장비별 tpmc 성능치는 TPC 의성능평가를통해서공식발표되지만그들의정책에따라모든제품에대해서 TPC 성능을평가하는것이아니므로모든시스템에대한 tpmc 값이제공되고있지못하고있는실정이다. 이러한원인은 TPC 성능평가를위해서는막대한비용이지출되기때문이다. 즉비용및기타 5
문제로인하여모든장비라인업에대하여 TPC 성능평가를하지 하고 있으며각사별정책 ( 우선순위 ) 이상이한관계로발표하지 않는 경우도 있다. 셋째, 정보시스템구축환경의변화에따라오늘날공공기관의업무시스템이배치를포함하는온라인트랜잭션처리업무에서웹기반의업무시스템으로변화함에따라이러한업무특성을감안한 H/W 용량산정의필요성이대두되고있으나대부분의 H/W 용량산정이기존의 TPC 의 tpmc 를기반으로산정되고있어업무의특성을정확히반영한용량산정으로볼수없어불합리하다는지적이일반적이다. 따라서위의 3 가지문제점중첫번째와세번째문제점은본 연구를통해서보완이가능하리라기대된다. 2. H/W 용량산정에대한기존연구 H/W 의용량산정과관련한기존연구는거의전무한실정이다. 기존연구중두드러진연구로한국전산원에서 2002 년자체연구과제의일환으로 H/W 용량산정에관한연구 를수행한바있다. 이연구에서는과거 TPC, 정보화사업의사례, 국내 SI 업체의산정기준을참조하여정보시스템구축비용중에서가장중요한 CPU, 메모리, 디스크의용량산정방식과절차를제시하고있는데장기적도입여부, 설치요건및설치전략, 확장성등의서버용량산정시고려사항을정의하고 CPU, 메모리, 디스크의용량산정방식과절차를제시하고있다. 사례로는, 제시된절차와방법에근거하여교육부의교육행정정보화사업과국세청의 HTS(Home Tax Service : 신고, 고지, 납부, 민원등국세관련대국민인터넷서비스 ) 등의정보화지원사업에대한서버용량사례를보여주고있다. H/W 용량산정에관한연구 의주요내용인 CPU, 메모리, 디스크의용 량산정방식은다음과같다. 6
tpmc 기반의 CPU 용량산정방법으로 tpmc 에영향을주는동시사용자수, 트랜잭션수, 기본 TPC 보정, 피크시, 여유율등보정계수및적용범위를제시하고있으며, CPU 용량산정식은아래와같다. CPU 용량 (tpmc) = 동시사용자수 * 트랜잭션수 * 기본 TPC 보정치 * Peak Time 보정치 * CPU 부하보정치 * 응용프로그램복잡도보정치 * 네트워크보정치 * 클러스터보정치 * 여유율보정치 메모리용량산정방법은시스템기본영역, 응용프로그램의크기, DBMS, 여유율등보정계수및적용범위를제시하고있으며, DB 서버를제외한메모리용량산정식은아래와같다. 메모리용량 (MB) = {OS 및기본영역 + 프로세스수 * 응용프 로그램보정치 } * 버퍼캐쉬보정치 * 클러스터보정치 * 여유 율보정치 디스크용량산정방법은시스템기본영역, S/W 영역, DB 영역, SWAP 영역, 여유율등보정계수및적용범위를제시하고있으며, 아울러다음과같은디스크용량산정식을제시하고있다. 내장디스크용량 (MB) = { 시스템 OS 영역 + 응용프로그램영역 + 상용소프트웨어영역 } * SWAP 영역 * 여유율보정치외장디스크용량 (MB) = {DB 영역 + 백업영역 } * RAID 영역 * 여유율보정치 한편, 해당보고서에서이미밝힌바와같이제시된보고서는한국전산원내에서정보화사업검토와예산조정에유용하게활용될수있도록하는차원에서작성되었기때문에 H/W 용량산정과관련한다른자료와차이나는부분이적지않다. 따라서용량산정항목들이공공부문정보화 7
사업과관련하여적정한가검토하여산정항목과지표를보다객관화하고, Web 기반시스템과관련하여 TPC-C 를적용하는것은적정하지않으므로 Web 혹은 WAS 의용량산정에 TPC-W, SPECWeb 등의적용방안을마련할필요가있다. 금번연구에서는기존연구의문제점을보완하고공공부문정보화사업의 H/W 용량산정시실질적인지침으로활용될수있도록용량산정식고도화와관련하여용량산정항목및적용값에대한적정성을검증하고, 적용사례를통한적용값의범위를객관화하고, 정확한값이도출되도록한다. 그리고정보기술환경변화에따른 Web 환경에대한 H/W 용량산정의정확성을확보하는차원에서 Web/WAS 에대한용량산정방식을아울러제안하고자한다. 8
3. H/W 용량산정사례 3.1 A 사사례 - 2tire 구조하에서의 WAS 와 DB 서버용량산정 기업내부의인트라넷시스템을구축하기위한 D 기업의 H/W 용량산정을위한사례를보이고있다. H/W 용량산정에영향을미치는 IT 아키텍처는 [ 그림 4-2] 와같이 WAS 서버와 DB 서버로이루어진 2- tire 이며전체사용자를 1,500 명, 동시사용자수를 250 명으로가정하였다. [ 그림 4-2] WAS 및 DB 서버용량산정을위한 IT 아키텍처 CPU 부문 CPU 의용량산정은서버의특성에따라웹서버와 DB 서버를다른방식으로산정한다. 우선웹서버의용량산정을위한성능지표로웹서버의성능을비교하기위한표준화된벤치마킹인 SPECweb96 를적용하고, DB 서버의경우 OLTP 를위한성능지표인 TPC 의 TPC- C 를적용하고있다. - 웹서버 : SPECweb96 은웹서버의성능을비교하기위한표준화된벤치마킹이며, 파일크기에따라웹서버의성능을비교하기위하여 4 개의 Class 로나눈다. 이중파일크기가 1 ~ 10KB 라가정하고 Class 1 9
의비율 50% 을사용한다. 웹서버를위한세부산정식은다음과같다 웹서버용량산정 = 동시사용자 * 100/SPECweb96 Class 1,2,3 비율 * 평 균세션수 * 네트워크보정 * Peak Time 보정 * 시스템여유율 다음은웹서버를위한세부산정식을적용하여실제산정과정을보 이고있다. 산정결과, 웹서버의프로세스는약 1,927ops 의성능을 요구하고있다. [ 표 4-3] 웹서버의 CPU 산정근거 구분산정근거산정내역 동시동시사용자수 * ( 매 3 년 250 * (1.3 * 1.3 * 1.3) * 0.6 * 1.5 증가율 (30%))* Web 사용자비사용자 = 329 * 1.5 = 494 명율 (60%) * SPECweb96 Class 비율 Ops/ 동시사용자수 * 세션수 (3)/ 명 494 * 3 * 1.3 = 1,927 Ops/Sec Sec * 여유율 (30%) - DB 서버 : DB 서버의경우, OLTP 를위한성능지표인 TPC 의 TPC-C 를적용하였으며, 세부적인산정식은다음과같다. DB Server 용량산정 = 트랜잭션처리수 * 최번시간트랜잭션 * 트 랜잭션복잡도 * 네트워크보정율 * Peak Time 보정율 * 시스템부하 율 * 시스템여유율 * 트랜잭션증가율 위의세부산정식을적용하여실제산정과정을보이고있으며, 산정 결과 DB 서버의프로세스는약 6,088 tmpc 의성능을요구하고있 다. 10
[ 표 4-4] DB 서버의 CPU 산정근거 구분산정근거산정내역 일트랜잭션처리수 사용자수 * 개인입력건수 / 일 *( 매 3 년사용자 증가 보정율 (30%)) 1,500 * 3 *(1.3 * 1.3 * 1.3 )=9,887 건 / 일 일일업무집 일일처리량의 70% 을 4 시간사 9,887 * 0.7 /4 / 60 = 중시간 이처리가정분당트랜잭션 29 건 /Min 트랜잭션복잡도 응답시간보정 TPC 와트랜잭션복잡성차이 (1.5 배 ) LAN/WAN 을통한클라이언트응답시간보정 (1.5 배 ) 29 * 1.5 = 44 건 /Min 44 * 1.5 = 66 건 /Min Peak 시보정율 시스템부하율 Peak Time 시이를위한 6 배의보정율적용 OS(50%), 기타시스템소프트웨어 (SQL Server 40%, Vaccine 40%) I/O 부하율입 / 출력을위한부하율 70% 시스템여유율 40% 정도의시스템여유율적용 66 * 6 = 396 건 /Min 396 * 1.5 * 1.4 * 1.4 = 1,164 건 /Min 1,164 * 1.7 = 1,979 건 /Min 1,979 * 1.4 = 2,771 건 /Min 트랜잭션 3 년간트랜잭션 증가율 적용 2,771 * 1.3 * 1.3 * 1.3 증가율 (30%) = 6,088 tmpc 메모리부문 메모리산정을위한권장용량은다음과같다. Windows NT Kernel : 64MB SQL Server Database 서비스 : 256MB Transaction Server 서비스 : 32MB Windows NT 사용자 1 명당 : 50KB SQL Server 사용자 1 명당 : 50KB RAID 적용 : 32MB C/S 사용자비율은 40%, Web 사용자비율은 60% 로가정 11
- 웹서버 : 웹서버의메모리용량산정을위해서산정항목은 OS 사용량 과어플리케이션영역과시스템여유율을사용하였으며세부적인산정 식은다음과같다. 웹서버메모리의용량산정 = OS 사용량 + 어플리케이션영역 + 시 스템여유율 위의식을적용하여산출한결과웹서버메모리총용량은약 958MB 정도를요구하는것으로산출되었으며세부적인산정내용은다음과같 다. [ 표 4-5] 웹서버의메모리산정근거 구분산정근거산정내역 동시사용자 OS 용량 Web 서버용량 250 * 1.3 * 1.3 * 1.3 동시사용자 * 증가보정율 (30%) * 3 년 = 549 명 Windows NT Kernel ( 기본 OS+ 서비 64MB + 64MB + (549 * 스 ) + 기타유틸리티 (RAID 포함 ) + ( 동 50KB * 0.4) = 128 + 11 시사용자 / C/S 사용자비율 (40%)) = 139MB 동시사용자 * Web 사용자비율 549 * 0.6 * 3 * 0.5 = 494MB (60%) * 평균세션수 (3) * 0.5MB Transaction 동시사용자 * 0.3MB 549 * 0.3 = 165MB 서버용량 시스템 (OS 용량 + web 서버용량 (139 + 494 + 165) * 0.2 여유율 + Transaction 서버용량 ) 의 20% = 160MB - DB 서버 : DB 서버의메모리용량산정을위해서산정항목은 OS 사용량과 DBMS 영역과시스템여유율을사용하였으며세부적인 산정식은다음과같다. DB 서버메모리의용량산정 = OS 사용량 + DBMS 영역 + 시스템여유율 12
위의식을적용하여산출한결과 DB 서버메모리총용량은약 825MB 정도를요구하는것으로산출되었으며세부적인산정내용은 다음과같다. [ 표 4-6] DB 서버의메모리산정근거 구분산정근거산정내역 동시사용자 OS 용량 DB 용량 동시사용자 (30%) * 3 년 * 증가보정율 250 * 1.3 * 1.3 * 1.3 = 549 명 Windows NT Kernel ( 기본 OS+ 서비스 ) + 기타유틸리티 (RAID 64MB + 64MB = 128MB 포함 ) SQL Server Database 서비스 + 256 + (5,490 * 0.05) + (549 * 데이터와인덱스량의 5% 부하 50KB) = 256 + 275 + 28 = 559MB 량 + 동시사용자 시스템여유율 (OS 영역 + DB 영역 ) 의 20% (128 + 559) * 0.2 = 138MB 디스크부문 디스크의용량산정은시스템디스크부문과데이터를위한데이터디스크로나누어산정방식을달리한다. 제시한구조에서의웹서버에대해서는시스템디스크용량만산정하며, DB 서버의경우는시스템디스크와데이터디스크를산정하고있다. 세부적인산정식은다음과같다. DB 시스템디스크 = OS 사용량 + DBMS 사용량 + 어플리케이션사용량 + SWAP 사용량 + 시스템여유율데이터디스크 = 총데이터량 + 데이터증가율 + RAID 적용율 + 여유율 - 웹서버 : 위의식에따라웹서버의시스템디스크산정결과필요용량은 약 8.4GB 정도이며세부적인산정내용은다음과같다. 13
[ 표 4-7] 웹서버의시스템디스크산정근거 구분산정근거산정내역 시스템 Windows NT + 어플리케이션 S/W 사용량 ( 응용프로그램 ) SWAP 공간서버메모리의 2 배적용 500MB + 1GB = 1.5GB 2048MB * 2 = 4,096MB 여유율성능향상위한공간 50% (1,500 + 4,096) * 0.5 = 2,798MB - DB 서버 : DB 서버의시스템디스크산정결과필요용량은약 5.4GB 정 도로산정되었으며세부적인산정내용은다음과같다. [ 표 4-8] DB 서버의시스템디스크산정근거 구분산정근거산정내역 시스템 S/W 사용량 Windows NT + DBMS( 데이터베이스관리도구를포함 ) SWAP 공간서버메모리의 2 배적용 0.5GB + 1GB = 1.5GB 1024 * 2 = 2,048MB 여유율성능향상위한공간 50% (1,500 + 2,048) * 0.5 = 1,774MB 또한, 산정결과 DB 서버의데이터디스크는약 21.8GB 정도를필요 로하며세부적인산정내용은다음과같다. [ 표 4-9] DB 서버의데이터디스크산정근거 구분산정근거산정내역 일별입력건수 * 데이터사이즈 (9,887 건 * 0.5KB = 4,943.5KB 데이터량 / 년 * 30( 일 ) * 12( 개월 ) * 1.3( 보정율 = 5MB) 30%) 5 * 30 * 12 * 1.3 = 2,340MB 데이터데이터량 / 년 * 데이터증가율 2,340 * 3.2 + 5,490 = 증가분 3.2 배 + 기존데이터 7,488 + 5,490 = 13GB RAID 5 적용 여유율 데이터디스크의 20% 13 * 1.2 = 15.6GB (Parity 영역 ) 성능향상을위한여유공간 40% 15.6 * 1.4 = 21.84GB 14
3.2 B 사사례 - WAS 용량산정 X 기업의채널통합데이터베이스서버를운영하기위한최적 용량산정과시스템구성, 시스템가용성향상을위한장애대응방안을 마련하기위해시스템용량산정을수행하였다. 한편, 시스템용량계획및구성의근거로써 SOATC(Sun Oracle Application Technology Center) 의 Oracle Database 벤치마크보고서와 Peak-time 의벤치마크보고서를참조하였다. 동시사용자수는 CPU, 접속자수는메모리용량산정에활용하였으며, 가용성, 성능, 확장성순으로우선순위를부여하고시스템여유율과기존서버의용량및성능을고려하여용량산정을하였다. 용량산정을위한대상시스템의아키텍처는다음과같이어플리케이션 Tire, 데이터베이스 tire 의 2tire 구조로이루어져있으며, 용량산정대상 은 WAS 서버와 DB 서버를대상으로하고있다 [ 그림 4-3] WAS 용량산정을위한 IT 아키텍처 15
WAS(web application server) 용량산정 WAS 는 J2EE 기반의어플리케이션을운영한다고가정하였으며, CPU 산정기준은 www.spec.org 의 SPECjbb2000 결과치를기준으로하였다. SPECjbb2000 은 server-side 의 JVM(JAVA Virtual Machine) 성능치를나타내며초당 operation 수를의미한다. 있다. 한편, WAS 의용량산정을위한전제조건으로는다음사항을제시하고 어플리케이션오버헤드 : 웹서버의프로세스, O/S 오버헤드및웹어플리케이션오버헤드를고려하여약 30% 추가산정 네트워크오버헤드 : TCP 와네트워크에대한오버헤드 10%(100base Ethernet) 여유율 : CPU 여유율 30% 추가메모리용량은 web/ap 서버의경우 CPU 당 2Gbmem 산정웹서버에접속한모든사용자가평균 10 번정도의비즈니스로직오퍼레이션을요구하는것으로가정 따라서, 다음에제시된 WAS 의용량산정을적용하여 10,000*1.3*1.1*1.3*10 (ops) = 185,900 ops/sec 로산정하였다. 웹서버용량산정 = 동시사용자 * 어플리케이션오버헤드 * 네트워크오버헤드 * 시스템여유율 * 사용자 1 인당평균비즈니스로직 오퍼레이션수 (ops) DB 서버용량산정 B 사의경우, DB 서버의용량산정은탑재하는 DBMS 의벤치마킹결과를토대로용량을산정하는데, 이러한용량산정은일반적으로용량산정식을 16
적용하고있지는않다. DB 서버의용량산정의전제조건으로 X 기업의채널통합 DB 서버는동시사용자 10,000 명을처리함을가정하였으며, 용량산정결과로서 10,000 명을지원할수있는 B 사의특정기종의 CPU 개수를제시하고있다. 즉, 1.2Ghz CPU 20 개 (10,000 명 /480) 를제시하고있으며, 이는시스템여유율 30% 와시스템은가용성을고려 HA 클러스터로구성하고, Fail-over 시성능 100% 보장을전제로한다. 3.3 C 사사례- 용량산정 Tool 을이용한용량산정 C 사에서는최신정보와툴을바탕으로고객의요구사항과비즈니스에맞는적합한서버용량제안에목적을두고자사직원또는비즈니스파트너를대상으로서비스를행하고있다. 이러한서비스내용은적절한하드웨어용량을산정하는것으로 C 사의특정플랫폼하에서의서버종류및 CPU 개수, 메모리용량 ( 최소사양 ), 디스크용량 ( 최소사양 ) 등을 WAS 전용의 HVWS(High Volume Web Site) 시뮬레이터를이용하여 S/W, H/W 전문가가협업하여결과검증후제공한다. A 자동차회사의 WAS 시스템의초당동시방문자수가 30 명이고동시사용자수는 70 명, 서비스형태는재고관리시스템이며, 적절한응답시간을제공 ( 비즈니스요구사항증가및기존시스템의통합, 향후업그레이드를수용할수있는시스템필요 ) 하여야하며, 시스템의구성이 3 Tier 구조이고 CPU 사용율이 Peak Time 시 50% 로가정한다면다음과같은용량산정결과를보여준다. 17
[ 그림 4-4] HVWS 의패턴다이어그램 [ 그림 4-5] HVWS 의결과치 18
[ 그림 4-5] HVWS 의결과치 ( 계속 ) 위의용량산정추정치는초당방문자수 30 명, 동시사용자수 70 명일경우를기준으로 CPU 사용율을 50% 를계속유지한다고가정했을때의시스템의성능및상태를나타낸수치이다. CPU 사용율의변화에따라초당방문자수및동시사용자수는감소또는증가하게된다. 최소응답시간항목은아주적은작업부하가걸리는상태에서초당방문자수도매우적을경우의시스템의응답시간을나타낸다. 19
제 3 절시스템성능향상을위한기술동향 일반적으로컴퓨터처리성능을나타내는단위로 MIPS(Million Instruction Per Second) 를사용하였으나 MIPS 는원래 OS 가없는하드웨어상에서업무용프로그램을직접실행하던때의척도로써현재와같은비즈니스상황에서는정보시스템의성능을평가하기위한기준으로적정하지않게되었다. 따라서 TPC 와 SPEC, BAPCO(Business Application Performance Corporation) 등의 3 종류의새로운성능평가기준이등장하게되었다. 오늘날 H/W 벤더및 SI 업체동향을살펴보면서버와메인프레임은 TPC 를, 워크스테이션은 SPEC 성능평가를많이사용하고있다. 또한국내의정부기관의경우정보시스템의용량산정을위한기준으로대부분이 TPC 의기준을적용하고있는실정이다. [ 표 4-10] 용량산정을위한성능기준치 구분 작업부하 적용서브시스템 TPC-C OLTP 또는 OLTP & Batch 어플리케이션 CPU, 메모리, 디스크, N/W, DB,UI 사용자 TPC-W SPECweb99 SPECjbb2000 웹 (Web) 서버어플리케이션 CPU, 메모리디스크, N/W, DB,UI 웹 (Web) 서버어플리케이션 CPU, 네트워크 웹 (Web) 서버어플리케이션 CPU, 네트워크 메트릭스 (Metrics) TpmC $/tpmc WIPS rate $/WIPS Operations per Second Operations per Second 참조정보 www.tpc.org www.tpc.org www.spec.org www.spec.org 따라서본절에서는 TPC 와 SPEC 의성능평가기술을중심으로 살펴보고자한다. 20
1. TPC 성능기준 TPC 는 1988 년 8 월에설립된세계최고의공신력을갖는하드웨어및소프트웨어의트랜잭션처리능력을평가하는독립기관으로서 RDBMS 의 OLTP 성능을평가하는가장공신력있는지표를제공하고있다. CPU 의트랜잭션처리용량은 TPC 에서지정하는몇가지의기준중에서해당하는업무에적합한기준을선택하고, 그기준에대한벤치마크결과치를기준으로산정한다. OLTP 시스템은 TPC-C 를기준으로한 CPU 용량산정을일반적으로사용하며, TPC-C 는 OLTP 시스템의성능을기본성능, 특정업무시스템의처리성능, DB 성능, 실시간처리성능, 복합데이터의처리성능등 5 가지측면에서평가하고있다. 서버와메인프레임의성능평가표준으로자리잡은 TPC 는 TPC-A, TPC-B, TPC-C, TPC-D, TPC-H, TPC-R, TPC-W 등의벤치마크테스트결과를발표하였다. 현재 TPC-A, TPC-B, TPC-D 는폐지되었고, WEB/WAS 와 OLTP 의성능벤치마킹기준은 TPC-C 와 TPC-W 이다. TPC-A TPC 에서처음으로만든가장단순한트랜잭션처리성능평가용벤치마크이며네트워크를포함한기본성능을평가한다. TPC-A 의업무내용은 ATM( 현금자동입출금기 ) 을사용하고있는은행의입출금시스템이다. TPC-B 네트워크를포함하지않으며 DBMS 의기본성능을평가하기위한것으로 TPC-B 의업무내용은 TPC-A 와마찬가지로 ATM( 현금자동입출금기 ) 을사용하고있는은행의입출금시스템이다. 21
TPC-C TPC-C 는 TPC-A 의응용프로그램이너무단순하여현실적이지않다는단점을해소하기위해등장한벤치마킹방법이다. TPC-C 는다양한크기와복잡도를가진서로다르면서도상호연관성이있는데이터베이스테이블에대해수행할수있는 5 개의서로다른트랜잭션유형을규정할수있고분당트랜잭션으로성능측정이가능하다. TPC- C 에서는 tpm(transaction Per Minute) 을단위로사용하고 tpmc 로나타낸다. 또한 TPC-C 는사용자의생각하는시간을고려하면서 OLTP 시스템에서성능상의임의성도도출해낸다. [ 그림 4-6] TPC-C 의시뮬레이션구성도 TPC-D Decision Support 어플리케이션을지원하기위한 TPC-D 는위의 세가지벤치마크보다훨씬복잡하여데이터처리를위한성능평가를 위한지표로 17 개의복잡한 Query 를기반으로평가한다. TPC-H TPC-H 는의사결정을지원하기위한벤치마크성능평가기준으로비즈니스지향적인비정규적병렬데이터처리에대한성능평가기준이다. TPC-H 의경우데이터량과트랜잭션종류를실업무환경에적용시키기가 22
어려워실제용량산정에적용하기는상당한어려움이따른다. TPC-R TPC-R 은 TPC-H 와유사하며차이점은정형화된대용량데이터 처리에대한질의로구성된것이다. TPC-W 인터넷상거래, 전자상거래환경을위해서버성능과가격을어떻게결정해야할까? SPECweb 과 TPC-C 등기존의가장주목할만한벤치마킹방법들은전자상거래서버들의성능향상을위해많은 H/W 벤더들에의해서참조되어왔다. 그러나이러한벤치마킹방법들은복잡한전자상거래작업부하환경을적절히표현하는데한계를가지고있다. 따라서 2000 년 2 월 TPC 는전자상거래환경을목표하는 TPC-W 벤치마킹방법을소개하였다. TPC-W 는웹사이트로부터제품을찾고구매하는고객들을시뮬레이션하는전자상거래작업부하를지정한다. 전자상거래솔루션을제공하기위하여작업부하들은수많은서버들 ( 웹서버, Web 캐시들, 이미지서버들그리고데이터베이스서버 ) 로구성되어있으며, 그들은실제전자상거래사이트가동작하는환경과매우유사하다. 이전의벤치마킹방법들은주로 1 개의특정서버를대상으로하는반면, TPC-W 벤치마킹방법에서는아래그림과같이웹서버, Web 캐시들, 이미지서버들그리고데이터베이스서버등의다른기능을수행하는서버들로구성되어있다. 23
[ 그림 4-7] TPC-W 의시뮬레이션구성도 한편, 다른 TPC 벤치마크들과달리, TPC-W 는다양한서버들에대한성능데이터를만들어내기위해서시험후원자를필요로한다. TPC-W 의적용범위를밝혀냄으로써, 복잡한전자상거래환경에서각각의서버들이어떻게동작하는지에대한정보를얻을수있다. TPC- W 의장점은시뮬레이트된전자상거래작업부하내에서특정전자상거래서버들의성능특성들을결정할수있다는것이다. 2. SPEC 성능기준 SPEC 는 1988 년 11 월에설립된이래 HP, 썬마이크로시스템즈등주요시스템업체가컨소시엄형태로참여하고있으며시스템성능테스트에있어서권위를인정받고있다. SPEC 의벤치마킹테스트중가장권위있는벤치마크테스트는 CPU 성능테스트이다 SPEC95 24
SPEC95 에는 SPECint95 와 SPECrate_int95, SPECfp95, SPECrate_fp95 등이있다. SPECweb96 SPECweb96 은 SPEC 이개발한벤치마킹방법으로서벤치마킹을위한환경은서버 H/W, 웹서버 S/W, 클라이언트로구성된다. 클라이언트들에서 SPECweb96 S/W 를사용서버측의부하를발생하여웹서버에접근하는 Web Browser 를시뮬레이션하는데작업부하는 0-1KB 를 35%, 1KB-10KB 를 50%, 10KB-100KB 14%, 그리고 100KB-1MB 를 1% 로발생시키며, NCSA, CommerceNet, Netscape 등의사이트에접근하는 Client 들에대한로그를기반으로요구하는파일사이즈, 빈도등을고려한다. 클라이언트의수는서버를포화상태로이르게할수있는구성이면되고, 자유로이선택하며서버처리능력이포화상태에이르고응답시간이급격히느려질때까지부하를점차증가시킨다. 서버의처리능력이포화상태에이르렀을때가웹서버가서비스할수있는최대 HTTP Operation 수를측정한다. 한편, SPECweb96 의한계로는 HTTP GET 만을테스트함으로써 POST, CGI Call, 보안기술등에대해고려하지않고있으며, HTTP 1.0 환경만을지원함으로써 Session 유지기능등을가지는 HTTP 1.1 은지원하지않고, 실제웹서비스환경인 WAN 환경에서의테스트가아니라는점이다. 따라서보다완벽한성능평가를위하여 SPECweb96 은 2000 년 2 월 SPECweb99 로대체되었다. SPECweb99 Specweb99 는 SPECweb96 에서발전한것으로작업부하는여러 회사의홈페이지를 서비스하는 웹 서비스 제공자에 접근하는 경우를 25
시뮬레이션하는것으로각각의홈페이지는작은아이콘으로부터용량이큰문서나이미지등으로구성된다. 테스트에사용되는웹서버의개수에제한이없으며, DBMS 를고려한테스트가아니며, 서버와클라이언트로구성되어있는단순한웹환경에서의테스트를위한것이다. 또한, LAN 환경에서의테스트이고, WAN 까지를고려한테스트가아니며, 서버가처리할수있는최대동시연결 (Connection) 수가결과이다. [ 그림 4-8] SPECweb96 의벤치마킹구성도 한편 SPEC 에서는 SPECWeb99 는시스템규모산정툴로디자인된것이아니므로, 서버용량산정을위한목적으로는사용하지말것을권장하고있다. 26
SPECjbb2000 SPECjbb2000 은 SPEC 이개발한벤치마킹방법으로서단일서버안에서 3-tier 환경 (Tier 1 : 클라이언트는 Thread 로 Simulation, Tier 2 : Business Logic 은 JAVA 를이용구성, Tier 3 : DB 는 JAVA Class 들을가지는 Binary Tree) 을이용하여 Simulation 하는벤치마킹방법이다. 한편, SPECjbb2000 의단위는 http ops/sec 을사용하며, 하나의 JVM 내에서테스트를실행하며, 실제네트워크에연결된클라이언트및 DBMS 가존재하는것이아니다. [ 그림 4-9] SPECjbb2000 의벤치마킹구성도 또한디스크 I/O 가없고, 네트워크 I/O 도없는것을가정하고있다. 이러한 SPECjbb2000 의결과는상대적인비교를목적으로사용하기보다, 하드웨어벤더는해당장비에서 JAVA 어플리케이션을수행할때의 Scalability 와테스트를위해서사용한다. 소프트웨어벤더는해당회사의 27
JVMs, JIT, garbage collector, thread 구현의효율성을테스트하기위한목적으로사용하여야함을권고하고있다. 한편, 이러한 SPECjbb2000 의단점으로는고객의실제환경에서는반드시고려되어야하는네트워크환경 (LAN 및 WAN 환경 ), 분산된데이터베이스환경, 메인프레임및다른시스템과의연동, 디스크 I/O 에대한고려, DBMS 와의연결등이누락되어있으며, 다음표에서와같이벤치마킹실시시점에따라성능치가달라진다는점이다. 이는성능평가의객관성에영향을미치는요소로 SPECjbb2000 성능평가의신뢰성을저하시킴에따라 H/W 벤더들에있어서의성능평가의논쟁거리로작용하고있다. [ 표 4-11] 시스템별성능치비교 구분 성능치 (http ops/sec) 발표일자 A 사 118,430 2001/10 ( 서버동일사양, JAVA 155,745 2002/05 Version 및 PATCH 적용 ) 183,694 2002/08 B 사 157,754 2001/10 ( 서버동일사양, JAVA 231,346 2002/01 PATCH 적용 ) 28
제 4 절용량산정을위한참조아키텍처 현대적인정보시스템의아키텍처는그림과같이세개의계층으로구성되어있다. E-비즈니스와같은웹기반응용부문은 3-계층 (three-tier) 아키텍처로구성될수도있다. 프리젠테이션계층이라고도하는계층 1 은웹서비스와의사용자인터페이스를구현한다. 브라우저를이용한 HTML 이나 XML 에대한해석을통해서웹사용자는데이터를입력하고, 데이터를편집하고정보를수신한다. 이동전화나 PDA 와같은이동통신장치들에서웹서비스에접근할수있는새로운인터페이스를이용할수있다. 어플리케이션계층이라고도하는비즈니스로직계층은어플리케이션로직을구현하기위한규칙들을캡슐화한다. 프리젠테이션계층과데이터서비스로부터비즈니스로직의분리는어플리케이션에새로운수준의자율성을제공하여어플리케이션의건전성 (robustness) 를더욱강화한다. 웹기반어플리케이션의경우, 이러한중간계층도자바애플릿과 Active X 컨트롤과같이브라우저에의해서표시되는컴포넌트들을갖고있다. 데이터서비스계층은신뢰성, 안정성, 가용성을보장하는메커니즘에의해서관리되는영속적데이터로구성되어있다. 데이터베이스서버와메인프레임은데이터계층의컴포넌트의예이다. 프리젠테이션비즈니스로직데이터서비스 사용자입력수집 표준인터페이스제공 비즈니스서비스접근제공 데이터처리규칙포함 어플리케이션비즈니스로직정의 비즈니스기능을비즈니스객체상의동작으로사상 데이터저장 데이터의오류와불일치방치 메임프레임데이터베이스접근제공 [ 그림 4-10] 계층별컴포넌트 29
분산형시스템에서, 미들웨어는클라이언트와서버사이의통합을가능하 게하는소프트웨어로간주된다. 인터넷에서사용되는미들웨어로는 HTTP, SSI, CORBA 가있다. 계층 1 DMZ 계층계층 3 (2) (3) 인터넷 (1) 로드밸런서 라우터 방화벽 LAN1 웹서버 어플리케이션데이터베이스 서버 서버 ( 메인프레임등 ) LAN2 LAN3 LAN4 [ 그림 4-11] 일반적인다계층웹사이트아키텍처 웹사이트는기본적으로전체시스템아키텍처중에서어플리케이션계층과데이터계층을구현하는것을말한다. 다음그림은로드밸런서, 계층 1 의웹서버, 계층 2 의어플리케이션서버, 계층 3 의데이터서버로구성된 3-계층 e-비즈니스사이트를보여준다. 이러한다양한요소들은 LAN, 라우터, 방화벽을통해서상호연결되어있다. 방화벽은패킷의네트워크간전송을방지하도록설정할수있는특수한종류의라우터이다. 이것은중요한내부 30
서버를외부의공격으로부터보호하는데중요한역할을한다. 다음그림의요청의흐름은다음과같다. 요청은사이트를인터넷에연결하는라우터를통해서로드밸런서에도착한다. 로드밸런서는어떤웹서버가그요청을수신해야하는지결정한다. 외부에서접근할수있는영역은 DMZ(demilitarized zone) 라고한다. 방화벽 1 은계층 1 의어떤웹서버도외부로부터차단된채오직로드밸런서로부터만요청을수신하게한다. 웹서버는요청을어플리케이션서버로송신한다. 방화벽 2 는웹서버에의해서만어플리케이션서버에접속하게한다. 마지막으로, 어플리케이션서버가데이터베이스서버에서데이터를가져와야하는경우, 그러한요청은방화벽 3 을통해서전송된다. 다계층아키텍처는확장성, 가용성, 보안성, 메인프레임에상주하는레거시데이터와의통합이라는이점을얻는것을목표로하고있다. 보안성은어플리케이션서버와데이터베이스에대한접근을위에서설명한바와같이웹서버에만한정하는방화벽을사용하여향상시킬수있다. 사용자에대한보완성도 SSL 과 TLS 와같은인증프로토콜을이용하여제공할수있다. 확장성과가용성은각계층에서다중서버를이용하여확보할수있다. 또한, 로드밸런싱메커니즘은전반적인성능향상에이용될수있다. 31
제 2 장 H/W 용량산정지침 제 1 절개요 1. 지침의필요성 정보화시대의도래에따라사회적으로정보인프라구축에대한관심이고조되고있으며, 효율적인업무처리, 고객서비스개선등을위해다양한정보시스템이구축되고있다. 이러한정보시스템은 H/W, S/W, 사람으로구성되며, 이중 H/W 는공급업자혹은시스템구축자등에따라용량산정적용항목및적용비율을경험적으로적용하기때문에부정확한용량이산정되는경우가많이발생한다. 업무의성격, 업무증가율, 사용자사용빈도, 구축기술등을전체적으로고려하여 H/W 용량을산정해야하므로, 시스템구축사업에서 H/W 용량적정성의옳고그름을판단하는것은어려운일이다. 시스템구축사업에서 H/W 가차지하는비중이전체프로젝트비용의적게는 50% 에서많게는 90% 을차지함에도불구하고, 그동안이부분은사업자나장비업체에의존적이고, 상대적으로소홀한분야로많은관심을갖지않았다. 이와같은이유로실제요구되는하드웨어의각구성요소가사업자나장비업체에의해과다또는과소산정되는경우가발생하여도마땅히개선할수있는방법이없었다. 따라서공공부문정보화사업에서의기획자 ( 공공기관 ), 구축자 (SI 사업자및장비업체 ) 등이 H/W 자원의도입을검토할경우참고할수있는 H/W 용량산정지침을작성하였다. 본지침은 TPC(www.tpc.org) 와 SPEC (www.spec.org) 의다양한업무유형별성능기준을토대로국내 SI 기업 (SDS, LG-CNS, HIT) 및장비업체 (IBM, SUN, Fujitsu) 의 H/W 산정기준을참조하여전문가그룹의토의를거쳐확정하였으며, 시스템구축비용중가장중요한 CPU, 메모리, 디스크용량산정에대해소개하고자한다. 2. 지침의적용범위 32
본지침은공공부문정보화사업을대상으로사업기획시장비도입을위한대략적인소요예산의산출을위해서혹은 SI 업체의 H/W 부문제안시의 H/W 규모산정을위한기준지침으로활용될수있다. 현행제시된지침은신규도입되는 H/W 를전제로작성되었으며, 따라서기존시스템에대한용량확장을위한지침으로활용하는것은바람직하지않다. 한편, 신규도입시스템에적용되는경우, [ 그림 5-1] 에서와같이정보화사업의수행전반에대해서적용가능하며, 사업을기획 / 발주하는주관기관, 시스템공급자, 감리기관등에서본지침을활용하여용량을산정할수있다. 우선, 주관기관에서는정보화사업을입안하는시점과세부사업계획의수립시에 H/W 규모산정이반드시필요하므로이를적용할수있다. 또한, 개발사업자는제안서를작성하여 H/W 를제안하는시점과실제시스템사업자로선정된개발과정중아키텍처설계시본지침을적용할수있다. 한편, 감리기관의경우, 필요시감리시점에 H/W 용량산정의적정성을검증하는차원에서본지침을참조할수있을것이다. 범례 ) [ 그림 5-1] 정보화사업추진단계및주체별적용범위 33
3. 용량산정의대상 본지침에서의용량산정대상이되는 H/W 는 PC 나기타주변장비가아닌메인프레임급서버를의미한다. 이러한하드웨어구성분야는여러가지가있지만시스템가격및성능측면에서가장중요한세분야를용량산정분야로정의한다. CPU : 해당업무를처리하기위한 CPU 용량을계산한후, 적정한성능을지닌서버기종을선정한다. 메모리 : CPU 용량산정에따른서버구성방안에의거하여, 서버별 시스템소프트웨어, 응용프로그램등의메모리사용량을산정한다. 디스크 : CPU 용량산정에따른서버구성방안에의거하여, 서버별 OS, 시스템소프트웨어, DB 의데이터, DB 의 Archive 및백업영역등의디스크사용량을산정한다. 34
제 2 절용량산정절차 1. 용량산정시일반적고려사항 일반적으로시스템구성검토는업무분석이제대로이루어지지않은프로젝트초기에수행된다. 이때문에실제로작업부하를정확히예측하는것은불가능하다. 따라서필연적으로용량산정을위해서는다양한보정치를사용한다. 업무조사가많이이루어지거나이미전산화되어있던업무에대한용량산정을한다면이러한보정작업은별로의미가없겠지만신시스템구성시업무분석이이루어지지않은상태라면실제구현시추가로발생될작업부하에대해서예상후보정작업을수행해야만한다. 또한용량산정시사전에고려되어야할사항들이있는데, 그것들을나열하면다음과같다. 1 장기적으로시스템을단계적으로구축하는가? 일반적으로업무전산화수행시전년도의업무량을기준으로용량산정을수행하므로실제로시스템이도입되는시점에있어서는시스템자원이부족해질수있다. 또한 CPU 의증설이불가한시스템을도입하거나 CPU 의증설만으로는요구성능으로 Upgrade 가불가한경우는추후시스템과부하가발생하므로장기적인시스템증설계획인가를확인해야한다. 2 기종별각종 Slot 수가적정한가? 서버는대형, 중형, 소형컴퓨터등벤더에서판매하는각기종마다주변장치설치를위한 Slot 수의제약이있다. 그러나시스템구성에따라추가적으로슬롯이필요할수가있다. 예를들면, Clustering 시스템을구성할경우, Heart Beat 를점검하기위한인터페이스슬롯이추가적으로필요하다. 시스템구성을고려하지않고장비를도입하면, Interface Card 가부족하여시스템구성자체가불가능할수있다. 또한 CPU, 메모리, Main Board 등주요자원의확장 Slot 도고려해야한다. 35
3 장비설치요건이맞는가? 하드웨어의모든장비는자신만의독특한설치요건을가지고있다. 하나의디스크어레이는속도향상과장애대처를위해두개의인터페이스를가진다거나, 메모리분야에있어서필수적으로 Pair 로구성되는경우가많다. 이경우초기시스템도입시사이즈가작은모듈로메모리를구성하면확장의어려움에처하기쉽다. 4 시스템설치전략에맞는용량인가? 업무량분석을통한용량산정을기반으로실제하드웨어용량은기타시스템구성정책에의해가중치가부여된다. 만일시스템백업을위해클러스터링시스템을구성한다면대응서버의 CPU 와메모리의여유율을더한용량을가져야할것이며, 디스크미러링을수행한다면디스크양의두배가필요하게될것이다. 시스템용량산정수행시에는이러한변수가많이존재하기때문에철저한검토가필요하다. 2. 용량산정절차 전사적시스템선정을위한용량산정절차는 [ 그림 5-2] 에서제시한바와 같다. 시스템구축방향및기초자료조사 기초자료및업무분석 구성요소별용량산정 산정결과검증및완료 [ 그림 5-2] 용량산정과정 시스템구축방향및기초자료조사단계에서는향후구축될전체시스템에 대한아키텍처구성및정보흐름을파악하여모델을설정하고기초자료및 36
업무분석을통해서기본적인업무부하와보정계수를결정하며, H/W 구성요소별용량을산정하며, 용량산정항목에따라용량산정을완료한후과거유사프로젝트경험치를적용하여재조정한후용량산정을완성하는등의과정을거친다. 2.1 시스템구축방향및기초자료조사 공공부문에있어서의정보화사업의 H/W 용량산정을위해서는다음의기초자료가반드시필요한데, 정확한기초자료의확보를위해서는고객과의협의를통한업무분석과시스템구축방향설정이선행되어야한다. 따라서용량산정을위한첫번째단계로전체시스템에포함되는대략의서버개수, 어플리케이션아키텍처 (2-Tier, 3-Tier), 통신환경등을파악하며, 서버의개략적인업무성격과정보흐름을파악한다. 이러한서버의개략적인업무성격과정보흐름을파악하기위해서업무사용자를대상으로한 [ 표 5-1] 과 [ 표 5-2] 의양식에따라용량산정을위한기초자료를조사한다. 이는향후시스템용량산정의기본적인자료로활용되므로정확하게작성되어야하며, 작업부하의특성에따라 OLTP( 혹은배치작업을포함하는 OLTP), WEB/WAS 등서버의 CPU 용량산정을달리하므로서버별로업무특성을감안하여작성한다. [ 표 5-1] WEB/WAS 를위한기초자료조사항목 항목 설명 비고 시스템용도및 1) 웹페이지만제공 서비스형태 2) 트랜잭션이빈번하지않은웹서비스 (DB 연계 ) 3) 트랜잭션이빈번한웹서비스 (DB 연계 ) 시스템의구성형태 1) Single tire 2) 2-tire 3) 3-tire 접속자수 - 평균접속자수 (24 시간기준 ) - 최고접속자수 (1 시간 ) - 년간접속자증가율 37
[ 표 5-1] WEB/WAS 를위한기초자료조사항목 ( 계속 ) 항목설명비고사용율 - 동시사용자수 - 사용자당 Operation 수 - 이미지파일과사운드파일의크기 - 웹페이지크기 - 허용응답시간 네트워크속도 네트워크속도 업무중요도및긴급도 - 중요도 ( 상, 중, 하 ) - 긴급도 ( 상, 중, 하 ) 백앤드상호작용의형태 - Read only - Update - OLTP SSL 사용여부 [ 표 5-2] OLTP 를위한기초자료조사항목항목설명비고시스템구축형태 1) Single System 2) HA System 3) 병렬구성사용자수 전체사용자수 동시사용자의비율 동시사용자당평균질의수 (1 일 ) 가동시간중 Peak-time 의시간 년간사용자증가율 트랜잭션수 년간트랜잭션량 1 일평균트랜잭션량 Peak-time 트랜잭션량 예상연간트랜잭션증가율 온라인업무량 검색, 갱신, 삽입, 삭제별레코드크기 및전체건수, 인덱스합치건수등 배치업무량 온라인업무에대한배치업무비중 배치업무구분 대량배치기준으로데이터건수및 길이 38
[ 표 5-2] OLTP 를위한기초자료조사항목 ( 계속 ) 데이터베이스 데이터크기 ( 초기, 1 년차, 2 년차, 3 년차및 3 년차이후데이터증가율 ) 데이터중이미지, 사운드, 텍스트 파일의비율 인덱스테이블의초기크기및 3 년내 크기 테이블크기의구성 - 열의평균바이트수 데이터백업 데이터백업 데이터백업서버의운영여부 백업장치의접속패턴 백업데이터량 운영시간 운영시간 (7X24) 네트워크속도 네트워크속도 2.2 기초자료및업무분석 필요시신규추가업무량과각업무별연관성및복잡도분석을수행하며, 기초자료및업무분석결과를통해서각업무별예상부하를결정하고이를합산하여기준부하 ( 예를들어, 기초 TPM) 를산정한다. 한편기초자료및업무분석시고려하여야할요소는다음과같다. 비즈니스를지원하기에적당하도록비즈니스요구사항을가능한반영한다. 응용업무의각트랜잭션타입, 특성, 가중치를조사한다. 응용업무에서처리하는트랜잭션의데이터처리 흐름과 처리량, 패턴을감안한다. 온라인업무와배치처리업무는구분해서분석한다. 요구시간, 처리볼륨 ( 데이터, 트랜잭션 ), 복잡성을분석한다. 타시스템과의연관관계를고려하여파생되는트랜잭션볼륨과데이터볼륨, 처리방법등을조사한다. 현재의용량과향후시스템서비스를개시한후업그레이드없이 39
사용할기간을감안하여필요용량을사전확보해야한다. 확장시에는확장대상업무, 시기, 부서, 사용자수, 데이터볼륨을감안하여확장방안을세운다. 시스템에탑재될시스템소프트웨어가무엇인지확인하고, 요구되는 CPU, 메모리, 디스크요구량을조사하여반영한다. 이때여러종류의소프트웨어가탑재되었을때시스템서비스에영향을미치는요소를평가하고이를다음의용량산정에반영한다. 2.3 구성요소별용량산정 업무분석자료를기반으로각종보정계수를설정한후어플리케이션의구현모델에따라적절한용량산정모델을선택하여구성요소별로용량산정을수행한다.( 세부산정기준및산정식은 3 절참조 ) 2.4 산정결과검증및완료 용량산정항목에따라용량산정을완료한후과거유사프로젝트 경험치를적용하여필요시재조정한후용량산정을완성한다. 40
제 3 절 H/W 용량산정방식 1. CPU 1.1 CPU 의성능기준 H/W 용량산정을위해서는시스템의아키텍처와작업부하의특성을고려한산정이이루어지는것이바람직하다. 작업부하의특성에따라서버의 CPU 용량산정을 OLTP( 혹은배치작업을포함하는 OLTP), WEB/WAS 등으로구분하여 CPU 의용량산정을달리한다. OLTP 혹은배치를포함하는 OLTP 워크로드를위해서 TPC-C 기준의 CPU 용량산정방법을사용한다. TPC 는 RDBMS 의 OLTP 성능을평가하는가장공신력있는자료로알려져있다. 한편, 현대적인정보시스템의아키텍처에서웹기반응용부문은 3-계층아키텍처로구성되는것이일반적이므로, 웹환경을위한웹서버의경우성능기준치를 SPECweb99 로 WAS 시스템의경우 SPECjbb2000 을적용한다. [ 표 5-3] 작업부하별적용성능기준치 OLTP 또는웹 (Web) 서버구분 OLTP & Batch 어플리케이션어플리케이션 WAS(Web Application System) 성능기준 TPC-C SPECWeb99 SPECjbb200 메트릭스 TpmC Operations Operations (Metrics) per Second per Second 따라서, 본지침에서는각각의작업부하에따른시스템선정을위한성능평가기준및 CPU 의용량산정대상은작업부하특성에따라 1) OLTP 또는 OLTP & Batch 어플리케이션, 2) 웹서버, 3) WAS 로구분하여 [ 표 5-3] 에서와같이산정방식을다르게적용한다. 41
1.2 OLTP 또는 OLTP & Batch 어플리케이션 고려사항 OLTP 또는 OLTP & Batch 어플리케이션을위한서버의용량산정을위해서 tpmc 추정에는여러가지방법이있으며현재까지공통적으로사용되는기준은존재하지는않는다. 그이유는어떤형태의서비스를제공하는시스템인지, 어떤형태의시스템아키텍처를사용하는지, 어떤기종을사용하는지등에따라다양한방법이존재할수있으며, 특히신규시스템인경우이와같은내용이외에업무내용이상세히분석되어야적정 tpmc 를산정할수있다. 그러나일반적인시스템의경우사용자수, 트랜잭션, 각종보정값등을고려하여적정용량을산정한다. 산정항목및보정치 본지침에서는 tpmc 추정을위한기준항목을 [ 표 5-4] 와같이 11 개로구성한다. 각항목의입력값의범위는산정식의적용시해당값의적용범위를나타내며, 일반값은 default 값으로일반적으로적용하는값을말한다. 따라서용량산정을수행하는수행자가임의로주어진입력값의범위내에서적용이가능하다. 한편, 서버의 CPU 산정결과에큰영향을미치는요소로는동시사용자수와어플리케이션복잡도보정, 사용자복잡성보정, 어플리케이션구조보정, 어플리케이션부하보정으로동시사용자수의산정에는신중한접근필요하며, 어플리케이션복잡도보정, 사용자복잡성보정, 어플리케이션구조보정, 어플리케이션부하보정의경우적용대상업무에대한상세한분석이선행되지않으면, 각항목의입력값에대한적용이쉽지않으므로일반적인값을적용하는것을권고한다. 42
[ 표 5-4] OLTP 산정항목및보정치 항목입력값범위일반값내용 - 동시에발생하는처리건수의 30% 동시사용자수 - 동시사용자수는접속사용자의 40% 트랜잭션처리수 기본 TPMC 보정 3( 단순 )~ 7 개 ( 복잡 ) 20( 소규모 )~ 30%( 대규모 ) 접속사용자는전체사용자의 70% 1 명이 1 분동안발생한트랜잭션수 1.2 시스템규모에따라보정 Peak Time 보정 20( 단순 )~ 1.2 업무가폭주하는경우고려하여보 30%( 복잡 ) 정 표참조 1.3 트랜잭션이처리하는데이터크기데이터베이스크기 - 데이터베이스크기보정 - 테이블의레코드수 표참조 1.1 프로그램의복잡한정도에따라적어플리케이션용복잡도보정 - 트랜잭션종류, 테이블수 사용자복잡성보정 표참조 1 - 접속사용자수 - 동시사용자수 어플리케이션구조보정 표참조 1 - 요구응답시간 - 어플리케이션구성방법 (2~3tier) 어플리케이션부하보정 표참조 1 BMT 가아닌실제사용자운영환경보정 네트워크보정 10% 1.1 네트워크대역폭으로인한지연보완 클러스터보정 30( 단순 )~ 1 클러스터환경에서장애발생시를 50%( 복잡 ) 위한보정 여유율보정 20 ~ 50% 1.3 시스템의안정된운영을위한보정 같다. 한편, 각각의기준항목에대한세부적인정의및적용의범위는다음과 기본 TPC : TPC 에서제공하는 tpmc 수치는최적의환경에서측정하 는것으로실제상황에맞게보정을해주어야하며, 시스템규모에 따라 20( 소규모 ) ~ 30%( 대규모 ) 정도를적용한다. 43
Peak Day & Peak Time : 업무의효율화와성능에의한정확하고도즉각적인결과값을얻기위해서업무가과중한시간대에시스템이원활하게운영되어야목적을달성할수있으므로 Peak Time 을기준으로하여시스템을산정한다. 시스템은일반적으로평상시보다 Peak Time 에약 20 ~ 30% 정도과중한로드를받게되므로이를고려하여가중치를적용한다. 데이터베이스크기 : 데이터베이스크기에따라가중치는 DB 에속한가장큰테이블의레코드건수와전체 DB 의볼륨을고려하여결정한다. 같은크기의 DB 경우에는건수가많은쪽이, 같은건수라면 DB 볼륨이큰쪽이큰가중치를갖게되며, 증가량의비율건수는 50% 단위증가로크기는 10% 증가단위로설정하였다. 그러나실제업무시스템에대한세부적인분석을근거로정확한값이도출되지않을경우, 가중치의적용이어려우므로용량산정자는일반값인 1.3 을적용한다. [ 표 5-5] 데이터베이스크기가중치 크기 ~ 0.3 ~ 1 ~ 3 ~ 10 ~ 30 ~ 100 ~ 300 ~ 300+ 1 1 1.5 2 3 1.1 1.7 2.2 10 1.2 1.8 2.4 3 3.6 30 1.3 2 2.6 3.3 4 100 1.4 2.2 2.9 3.6 4.4 5.1 5.8 300 4 4.8 5.6 6.4 7.5+ 1,000 5.3 6.2 7 8.5+ 1,000+ 7.0+ 8.5+ 10.0+ 주 ) Columns: Number of Rows of the biggest table( 단위 : 백만 ) Rows: Database Size of in Gbytes 어플리케이션복잡성보정 : 어플리케이션복잡성테이블은어플리케 44
이션또는트랜잭션의성격과해당어플리케이션에관계된주요테이블의개수에의한비중치를나타낸다. 어플리케이션의유형은서로다른부하를주며, 테이블의수도부하에상당한영향을미치게된다. 특히분석적인어플리케이션에관계된테이블이많은경우조인 (Join) 등의부하가급격히증가된다. 어플리케이션복잡성테이블에사용된어플리케이션은주로 MIS 업무를중심으로한것이다. 어플리케이션복잡성보정을위한구체적인수치는 [ 표 5-6] 과같다. 한편, 정확한업무예측의어려움으로인해이러한복잡도보정치를적용할수없거나개략적인적용을수행하고자하는경우, 일반값인 1.1 을적용할수있다. 사용자복잡성보정 : 사용자복잡성테이블은접속사용자 (Connection Users) 와동시사용자 (Con current Users) 의규모에따른비중치를나타내며세부적인적용기준은다음표와같다. 접속사용자는해당어플리케이션을사용할수있는사용자를말하며, 트랜잭션발생유무에는관계하지않는다. 동시사용자는실제로시스템에접속하여트랜잭션을발생시키는, 즉업무를수행하는사용자이다. 접속사용자의증가에따라가중치를조정하는것은새로이접속요청을할수있는가능성을고려한것이다. 실제시스템의부하증가는접속요청시에매우증가되기때문이다. 따라서동일한동시사용자수환경도접속가능사용자의수에따라가중치를차등적용하게된다. 한편, 보정치를적용하기어렵거나개략적인적용을수행하고자하는경우, 일반값인 1 을적용할수있다. [ 표 5-6] 어플리케이션복잡도보정치 종류 테이블개수 10 20 30 40 비고 응용의형태 단순검색 0.6 0.7 0.8 0.9+ 단순갱신 1 1.2 1.5 2.0+ 단순 Trx 유형 1.3 1.7 2.2 3.0+ 보통 Trx 유형 1.5 2.1 2.9 3.0+ 복잡 Trx 유형 1.7 2.6 3.8 5.7+ 분석작업 4.5+ 9.0+ 18.0+ 35+ 45
[ 표 5-7] 사용자복잡도보정치 크기 접속사용자수 100 300 1,000 3,000 5,000 5,000+ 비고 동시사용자수 30 1 1.1 1.2 100 1.2 1.3 1.5 300 1.6 1.7 1.9 500 2 2.2 2.4 3.0+ 1,000 2.4 2.6 2.9 3.5+ 1,000 3.2 3.5+ 4.5+ + [ 표 5-8] 어플리케이션구조보정치 항목 Direct User Connection Front-End Server 사용 Appl. Logic 포함 Database Only Appl. Logic 포함 Database Only 3 1.3 ~ 2.3 1.2 ~ 1.5 0.9 ~ 1.2 0.8 ~ 1.1 5 1.1 ~ 1.5 1 0.7 ~ 0.8 0.6 ~ 0.7 5+ 1 0.8 0.6 0.5 주 ) 행 : 어플리케이션구성방법, 열 : 요구되는응답시간 (Seconds) 어플리케이션구조보정 : 어플리케이션구조보정은어플리케이션로직을동일서버에포함하는지의경우와요구되는응답시간에따른비중치를말한다. Direct User Connection 은 2-Tier Client/Server 구성과같이 DB 업체또는표준화된 DB 접근미들웨어를사용하는것으로상위의네트웍계층에서동작하므로부하가증가한다. Front- End Server 의사용은 3-Tire Client/Server 구성과같이 User Connection 의부하를감소시켜주며, 특별한부하발생가능성이적기때문에가중치를 1 이하로적용한다. 응답시간은최종사용자의입장에서본것으로서버와사용자간의네트웍지역을감안하여가중치를조정하도록한다. WAN 이포함된환경은동일한응답성을얻기위하여는시스템의처리가빨라야하므로가중치를높게 46
결정해야한다. 한편, 보정치를적용하기어렵거나개략적인적용을 수행하고자하는경우, 일반값인 1 을적용할수있다. 어플리케이션부하보정 : 추가적인로드테이블은온-라인작업을수행하는 Peak time 에배치작업등을수행하여야하는경우의비중치를말한다. 정해진온-라인업무외에부가적인작업이처리되는경우그에필요한처리능력을보정하는단계이다. 즉배치성업무 ( 리포팅, 백업등 ) 나외부시스템을사용하는경우등이해당된다. 한편, 보정치를적용하기어렵거나개략적인적용을수행하고자하는경우, 일반값인 1 을적용할수있다. [ 표 5-9] 어플리케이션부하보정치 크기 동일한데이터 서로다른 데이터 비고 None 1 1 Light 1.7 1.3 Normal 2 1.5 Heavy 3 2 Job 내용이명확한경우가중치를 사용하지않고파악된부하량 (tpmc 기준 ) 을가산 주 ) 행 : 배치작업과온 - 라인작업이동일한데이터테이블을사용한경우와 그렇지않은경우, 열 : 배치작업의부하 (Light < 10Min, Normal < 30Min, Heavy > 30Min) 네트워크보정 : 네트워크대역폭으로인해응답시간이지연되는것을 CPU 처리로보완하기위한것으로 10% 정도를적용한다. 클러스터보정 : 2 대의시스템이하나의클러스터로구성될때, 하나의시스템에장애가발생하면남아있는시스템이장애가발생된시스템의응용프로그램을모두수행하고, 사용자들을접속하게된다. 이경우시스템의예비율이없으면업무가가중되어정상적인운영이어렵게되므로이에대한예비율을두어야한다. 일반적으로상대시스템의 100% 를두어야하지만, 이는비경제적이고비효율적이므로 47
약 30%( 단순 ) ~ 50%( 복잡 ) 까지의예비율을두어시스템장애시 지속적이고도, 즉각적인서비스를가능하게하기위한보정치이다. 시스템여유율 : 예기치못한업무의증가및시스템의안정된운영을 위한보정으로 20 ~ 50% 정도적용한다. 산정식 tpmc = 동시사용자수 * 트랜잭션처리수 * 기본 tpmc 보정 * Peak Time 보정 * CPU 부하보정 * 어플리케이션복잡도보정 * ( 사용자복잡성보정 * 어플리케이션구조보정 * 어플리케이션부하보정 ) * 네트워크보정 * 클러스터보정 * 여유율보정 1.3 WEB/WAS 고려사항 WEB/WAS 서버의용량산정을위해서 ops 추정은 tpmc 추정방식에비해상대적으로간단하게산정될수있다. tpmc 가 11 개의항목을사용하는데비하여 WEB 과 WAS 서버의경우에는어플리케이션 Interface 부하보정치와 Peak Time 부하보정치, 시스템여유율등 3 개의항목만을사용하여산정하도록정의하였으며 tpmc 에비해상대적으로업무분석이않된경우에도산정이가능하다. 산정항목및보정치 WEB/WAS 서버의용량산정에서는 6 개의항목으로구성되어있다. 각각의입력값의범위는산정식의적용시해당값의적용범위를나타내며, 일반값은 default 값으로일반적으로적용하는값을말한다. 따라서용량산정을수행하는수행자가임의로주어진입력값의범위내에서적용이가능하다. 48
[ 표 5-10] WEB/WAS 산정항목및보정치 항목 입력값범위 일반값 내용 총사용자수 전체사용자 동시사용자수 총사용자 총사용자의 5% 를 동시 의 5% 사용자로가정 어플리케이션 10% 1.1 서버가타서버와통신하게 인터페이스 되는데 이때 부하보정 인터페이스에서 발생하는 부하율 Peak Time 20% ~ 30% 1.2 갑자기많은접속으로인해 부하보정 부하가 발생하는 것을 해결하기위한부하율 시스템여유율 30% ~ 50% 1.3 시스템의 안정된 운영을 위한 보정으로 업무의 중요도나 긴급도를 감안하여적용 사용자당 Operation 10 사용자당 operation 수는 수 사용자 한 사람이 분당 발생시키는 operation 수로서 통상 10 개으로 정의 한편, 각각의기준항목에대한세부적인정의및적용의범위는다음과 같다. Peak Time 부하보정 : 업무의효율화와성능에의한정확하고도즉각적인결과값을얻기위해서업무가과중한시간대에시스템이원활하게운영되어야목적을달성할수있으므로 Peak Time 을기준으로하여시스템을산정한다. 시스템은일반적으로평상시보다 Peak Time 에약 20 ~ 30% 정도과중한로드를받게되므로이를고려하여가중치를적용한다. 어플리케이션인터페이스부하보정 : 서버가타서버와통신하게되 는데이때인터페이스에서발생하는부하율로서 10% 정도를적용한다. 49
시스템여유율 : 예기치못한업무의증가및시스템의안정된운영 을위한보정으로 30 ~ 50% 정도적용한다. 사용자당 Operation 수 : 사용자당 operation 수는사용자한사람이 분당발생시키는 operation 수로서기초자료조사시이를확인하나 확인이불가능할경우, 통상 10 개정도로가정한다. 산정식 OPS = 동시사용자수 * 어플리케이션 Interface 부하보정 * Peak Time 부하 보정 * 시스템여유율 * 사용자당 operation 수 2. 메모리 고려사항 메모리의용량산정방법은 CPU 에비해훨씬단순하다. 시스템별로프로그래밍언어, 쓰레드사용등여러메모리점유를줄이기위한전략에따라용량산정방법이조금씩차이가있으며, 메모리용량산정은시스템에서구동되는프로세스의수와그프로세스가사용하는메모리양이큰영향을준다. 따라서시스템의용도와구조를바탕으로하여메모리용량을산정한다. 산정항목및보정치 메모리산정을위한항목은 [ 표 5-6] 에서와같이 6 개로구성되어있다. 각각의입력값의범위는산정식의적용시해당값의적용범위를나타내며, 일반값은 default 값으로일반적으로적용하는값을말한다. 따라서용량산정을수행하는수행자가임의로주어진입력값의범위내에서적용이가능하다. 50
[ 표 5-11] 메모리산정항목및보정치 항목 입력값범위일반값 내용 시스템영역 OS, DBMS 엔진, 미들웨어엔진, 기타유틸리티등의소요공간 시스템관리자영역 관리자수시스템을운영할때시스템관리자가 *0.5MB 활용하는영역 사용자당필요메모리 0.3MB 어플리케이션, 미들웨어, DBMS 의사용에필요한사용자당 버퍼캐쉬 20% ~ 30% 1.2 클러스터보정 30%~70% 1.3 상대방메모리크기를고려한예비율 여유율 20% ~ 50% 1.3 예기치못한상황및확장에대한여유율 시스템영역 : OS, DBMS 엔진, 미들웨어엔진, 기타유틸리티등의소요공간을계산하여적용하는항목으로 DB 라이센스수, 사용어플리케이션에따라차등적용한다. - 운영체제 - 네트워크데몬소요공간 - DBMS(DB 라이센스수 * 0.6MB) - 미들웨어엔진, GIS 엔진등 - 기타유틸리티어플리케이션 시스템관리자영역 (Telnet, Shell Daemon) : 시스템을운영할때시스템관리자가활용하는영역을감안하여용량산정에반영한다. 시스템관리자수와관리자가사용할데몬수를계산하는데일반적으로관리자수 * 0.5MB 를적용한다. 사용자당필요메모리 : 사용자당필요메모리는어플리케이션, 미들웨어, DBMS 의사용에필요한사용자당메모리를지칭한다. 이러한사용자당필요메모리는어플리케이션의구현형태에따라사용자별로서비스하기위해요구되는메모리, 미들웨어를적용할때는이에따른시스템구현특성과서비스하기위해요구되는메모리, 사용자나어플리케이 51
션프로세스별데이터입출력을하기위해필요한메모리, 각벤더의 DBMS 에특성에따라요구메모리등을감안하여계산한다. 일반적인값으로 0.3MB 를적용한다. 버퍼캐쉬 (Buffer Cache) : Disk I/O 횟수를줄이기위한버퍼캐쉬크 기는시스템운영자의요구에의해정해지는데일반적으로전체필요메 모리량의 20% ~ 30% 정도로적용한다. 클러스터보정 : 시스템을서로다른업무를수행하는클러스터링구 조로구성할경우, 다른서버의업무를수행할경우를보정하는것으로 30 ~ 70% 정도적용한다. 여유율 : 시스템의성격및업무의증가에따라시스템을안정적으로 운영하기위하여 20 ~ 50% 를보정한다. 산정식 메모리 = { 시스템영역 + 시스템관리자영역 + 사용자당필요메모리 * 사용자수 } * 버퍼캐쉬 * 클러스터보정 * 여유율 3. 디스크 고려사항 디스크용량산정시가장중요한고려요소는데이터백업방안이다. 백업정책에의해 Disk 요구량은큰차이를가지기때문에데이터의중요도를고려하여상황에적절한백업정책을수립할필요가있다. 데이터백업을수행하기위한방법과도구는여러가지가존재하는데일반적으로시스템자체적으로백업정보를보관하면서테이프와같은보조기억장치를사용하는이중백업정책을가지는경우가많다. 만일은행업무와같이데이터의신뢰성과안정성이절대적으로필요한경우라면 52
디스크미러링과같은시스템 Full 백업방안도유용할것이다. 본연구에서는디스크용량에포함되는백업요소로 DBMS 에서제공되는 Archive 백업과하드웨어적인 RAID 디스크사용에의한백업만을포함한가장일반적인용량산정방안을기술한다. 산정항목및보정치 [ 표 5-12] 디스크산정항목및보정치 항목입력값범위일반값내용 시스템 OS 영역 - 운영체제및시스템소프트웨어 등을위한영역응용프로그램영역 - 미들웨어및응용소프트웨어영역데이터베이스영역 - 데이터베이스설치영역 ( 선택적 ) 상용 S/W 영역 SWAP 영역 - 기타유틸리티를위한영역 메모리 - swapping 을위한작업공간 *2 여유율 20% ~ 50% 1.3 - 안정적인시스템구성을 백업영역 위한공간 - 데이터와데이터변경내역을 기록하기위한공간 RAID 여유율 20% ~ 50% - Disk 가도입될경우패리티영역 시스템운영체제영역 : OS, 시스템 S/W, Super User 등을위한영 역 응용프로그램영역 : 서버용어플리케이션 Program 크기 데이터베이스영역 : DB 영역은다음세부항목의합계로결정된다. 다만인덱스의크기는시스템별인덱스정책에따라보정범위가가변적이다. - 실자료공간 ( 건수 * 건수별데이터사이즈 * 보관기간 ) 53
- 예비용데이터공간 ( 실데이터공간의 30%) - 인덱스및키용실데이터공간 (1+2 의 60%) SWAP 영역 : 시스템장애시의 Dump 역할수행과메모리대용의효율적인 Swapping 을수행하기위한작업공간으로, 일반적으로주기억장치의요구량의 2 배로산정한다. 여유율 : 안정성있는시스템구성을위해디스크여유율을가지는것이바람직하다. 업무분석의실수로디스크요구량이과소산정되거나고려하지못하여돌발적인사태에대비해서일반적으로전체필요디스크량의 20%~50% 정도를여유율로산정하는데기본적인값으로는 30% 를산정하는것이일반적이다. 백업영역 : 백업영역은백업정책에의하여결정되는데일반적으로데이터와데이터의변경내역정보를가지는 Archive 형태로보관한다. Archive 파일은실제데이터와 Log, 보관기간에의해전체사용영역이결정되는데, 백업파일을이중으로관리하기위해 Archive File 자체에대한백업을수행할수도있다. RAID 여유율 : RAID 여유율은 RAID 디스크가도입될경우데이터 보호를위한패러티영역으로사용되는공간을가산적용하며, RAID1 의경우, 50% 를 RAID5 의경우 20% 로산정한다. 산정식 시스템디스크 = { 시스템운영체제 + 응용프로그램 + SWAP 영역 } * 여유율 데이터디스크 = { 데이터영역 + 백업영역 } * RAID 영역 * 여유율 54
제 4 절용량산정사례 1. 개요 1.1 시스템개요 A 기관에서는 2 년계획으로인트라넷을기반으로하는통합 MIS 를구축하고자하였다. 우선내부전산실및일선부서업무담당자를중심으로하여통합 MIS 시스템구축을위한테스크포스팀을구성하고 1 개월간의작업을통해서내부업무에대한분석을수행하고시스템구성방향등에대한개략계획을작성하였다. 이계획의개략적인시스템구성은다음그림과같다. [ 그림 5-3] 용량산정을위한시스템개념도 한편, 이계획에따라세부적인예산을결정하기위해서 S/W 개발부문과 H/W 부분으로나누어프로젝트비용을산출하고자하였다. 특히, 통합 MIS 시스템을위한 H/W 부문은위의그림에서와같이 WAS 서버, DB 서버및백업장비만을신규로도입하고자하였다. 따라서 H/W 도입을위한 H/W 규모산정의대상은이두장비를대상으로하였다. 1.2 기초자료조사결과 H/W 규모산정을위한세부적인자료는앞서언급한업무분석과정을통 해서도출되었으며, 이를기초자료조사결과표에정리하면다음과같다. 55
[ 표 5-13] WAS 를위한기초자료조사결과 항목설명조사결과 시스템용도및 1) 웹페이지만제공 3) 트랜잭션이빈번한웹서비스형태 2) 트랜잭션이빈번하지서비스 (DB 연계 ) 않은웹서비스 (DB 연계 ) 3) 트랜잭션이빈번한 웹서비스 (DB 연계 ) 시스템의구성형태 1) Single tire 2) 2-tire 3) 3-tire 3) 3-tire 접속자수 - 평균접속자수 1,000 명 (24 시간기준 ) 500 명 - 최고접속자수 (1 시간 ) 년증가율 30% - 년간접속자증가율 ( 증가율감안 3 년필요 ) 사용율 - 동시사용자수 동시사용자 250 명 - 사용자당 Operation 수 3 건 / 분 - 이미지파일과 사운드파일의크기 - 웹페이지크기 5K - 허용응답시간 3 초 ~ 5 초 네트워크속도네트워크속도 100Mbps 업무중요도및긴급도 - 중요도 ( 상, 중, 하 ) 중요도 : 상 - 긴급도 ( 상, 중, 하 ) 긴급도 : 상 백앤드상호작용의 1) Read only 3) OLTP 형태 2) Update 3) OLTP SSL 사용여부 미사용 [ 표 5-14] DB 서버를위한기초자료조사결과 항목설명조사결과 시스템구축형태 1) Single System 2) HA System 3) 1) Single System 병렬구성 사용자수 - 전체사용자수 1,000 명 - 동시사용자의비율 25% - 동시사용자당평균질의수 (1 일 ) 3 건 ( 분당 ) - 가동시간중 Peak-time 의시간 4 시간 - 년간사용자증가율 30% 56
[ 표 5-14] DB 서버를위한기초자료조사결과 ( 계속 ) 항목 설명 조사결과 트랜잭션수 - 년간트랜잭션량 사용자 1 인당 - 1 일평균트랜잭션량 트랜잭션수 : - Peak-time 트랜잭션량 3 건 /( 분당 ) - 예상연간트랜잭션증가율 30% 온라인 - 검색, 갱신, 삽입, 삭제별레코드 업무업무량 크기및전체건수, 인덱스합치건수등 배치업무량 - 온라인업무에대한배치업무비중 9 : 1 - 대량배치기준으로데이터건수및길이 데이터베이스 - 데이터 크기 ( 초기, 1 년차, 2 년차, 년간증가율 30% 3 년차및 3 년차이후데이터증가율 ) - 데이터중이미지, 사운드, 텍스트 1: 1 : 8 파일의비율 - 인덱스테이블의초기크기및 3 년 60% 내크기 - 테이블크기의구성 평균 300K - 열의평균바이트수 450byte 데이터백업 - 데이터백업서버의운영여부 미운영 - 백업장치의접속패턴 RAID-5 - 백업데이터량 20G 운영시간 - 운영시간 (7X24) 7X24 네트워크속도 - 네트워크속도 100Mbps 2. 용량산정 H/W 에대한용량은서버 (WAS, DB 서버 ) 별, CPU, 메모리, 디스크를 대상으로하며, DB 서버에대해서는시스템디스크뿐만아니라백업을 위한데이터디스크에대한용량산정을아울러수행하였다. 57
2.1 CPU WAS 서버 WAS 서버의 CPU 용량을산정하기위해서는동시사용자수, 사용자당오퍼레이션수, 어플리케이션인터페이스부하보정, 피크타임부하보정, 시스템여유율등을사용하며, 세부적인산정근거와산정내용은 [ 표 5-15] 와같다. 한편, 시스템의안정된운영을위한보정치인시스템여유율의경우 30% 를적용하는것이일반적이나기초자료조사결과업무의긴급도및중요도가높으므로 40% 적용하여산정하였으며, 어플리케이션인터페이스부하보정, 피크타임부하보정은일반값을적용하였다. 최종적으로 WAS 서버의 CPU 용량은위의산정항목을모두곱한값 (549*3*1.1*1.2*1.4) 으로약 3046ops 를요구한다. [ 표 5-15] WAS 서버의 CPU 산정근거 항목 산정근거 산정내역 동시사용자수 동시사용자 * 증가율 (30%) * 3 년 250*1.3*1.3*1.3 =549 명 어플리케이션 서버가타서버와통신하게 1.1 인터페이스 되는데이때인터페이스에서 부하보정 발생하는부하율로 10% 적용 Peak Time 갑자기많은접속으로인해 1.2 부하보정 부하가 발생하는 것을 해결하기위해부하율로 20% 적용 시스템여유율 시스템의안정된운영을위한보정치로업무의중요도및긴급도가높으므로 40% 적용 1.4 사용자당 사용자당 operation 수는 3 Operation 수 사용자 한 사람이 분당 발생시키는 3 개로가정 DB 서버 DB 서버의 CPU 용량을산정하기위해서는동시사용자수, 트랜잭션 58
처리수, 기본 tpmc 보정, Peak Time 보정, CPU 부하보정, 어플리케이션복잡도보정, 사용자복잡성보정, 어플리케이션구조보정, 어플리케이션부하보정, 네트워크보정, 클러스터보정, 여유율등을고려하는데세부적인산정근거와산정내용은 [ 표 5-16] 과같다. 특히, 서버의 CPU 산정결과에큰영향을미치는요소로는동시사용자수와어플리케이션복잡도보정, 사용자복잡성보정, 어플리케이션구조보정, 어플리케이션부하보정으로동시사용자수의산정에는신중한접근필요하며, 어플리케이션복잡도보정, 사용자복잡성보정, 어플리케이션구조보정, 어플리케이션부하보정의경우적용대상업무에대한분석이선행되지않으면해당항목에대한적용이쉽지않으므로일반적인값을적용하였다. [ 표 5-16] DB 서버의 CPU 산정근거 항목산정근거산정내역 동시사용자수 트랜잭션처리수 기본 TPMC 보정 Peak Time 보정 데이터베이스크기 보정 어플리케이션 복잡도보정 동시사용자 * 증가율 (30%)*3 년 - 250*1.3*1.3*1.3=549 사용자 1 인이분당 발생시키는트랜잭션의수로 단순작업이므로 3 으로가정 시스템규모가크기않으므로 소규모인 20% 적용 업무가폭주하는경우고려하 여보정으로 20%( 단순 ) 적용 명 3 건 / 분 1.2 1.2 일반값으로적용 1.3 사용자복잡성보정 1 1 59
[ 표 5-16] DB 서버의 CPU 산정근거 ( 계속 ) 항목산정근거산정내역 어플리케이션구조보정어플리케이션부하보정네트워크대역폭으로인한지네트워크보정연보완 10% 적용클러스터환경에서장애발생클러스터보정시를위한보정이므로 1 적용시스템의안정된운영을위한여유율보정보정으로 30% 적용 1 1 1.1 1 1.3 한편, DB 서버의 CPU 용량은산정항목을모두곱한값 (549*3*1.2*1.2*1.3* 1.1* 1.3) 으로약 4408tpmC 를요구한다. 2.2 메모리 메모리산정을위해서다음과같이기초자료가조사되었다고가정한다. - Windows NT Kernel : 64KB - SQL 서버데이터베이스서비스 : 256MB - Transaction 서버서비스 : 32MB - Windows NT 사용자 1 인당 : 0.5MB - SQL 서버 1 인당 : 0.5MB - RAID 적용 : 32MB WAS 서버 WAS 서버의메모리용량을산정하기위해서는동시사용자수, 시스템 영역, 시스템관리자영역, 사용자당필요메모리, 버퍼캐쉬, 클러스터보정, 여유율등을계산하여야하며, 산정근거와산정내용은 [ 표 5-17] 와같다. 60
[ 표 5-17] WAS 서버의메모리산정근거 항목 산정근거 산정내용 동시사용자 동시사용자 * 증가율 (30%)*3 년 - 시스템영역 OS, DBMS 엔진, 미들웨어- 250*1.3*1.3*1.3=549 64MB + 32MB+ 32MB 명 엔진, 기타유틸리티등의 =128MB 소 요공간 : 기본 OS+ 서비스 ( 트 랜잭션 )+ 기타유틸리티 (RAID 시스템관리자영역 관리자수 *0.5MB - 0.5MB *2 명 = 1MB 사용자당필요메모리어플리케이션, 미들웨어,- 549 * 0.5MB= 274.5MB DBMS 의사용에필요한사용 버퍼캐쉬 일반적인값 20% 로적용 1.2 클러스터보정 상대방메모리크기를고려한 1.3 예비율로 30% 적용 여유율 예기치못한상황및확장에대한여유율로 30% 적용 1.3 WAS 서버의메모리크기는 ( 시스템영역 + 관리자영역 + 사용자당필요 )* 버퍼캐쉬 * 클러스터보정 * 여유율, 즉 (128+1+ 274.5)*1.2*1.3*1.3 로계산되며, 산정결과 WSA 서버의시스템디스크크기는약 818MB 정도를필요로한다. 따라서메모리확장단위를감안하여 1024 MB 로선정한다. DB 서버 WAS 서버의메모리용량을산정하기위해서는동시사용자수, 시스템영역, 시스템관리자영역, 사용자당필요메모리, 버퍼캐쉬, 클러스터보정, 여유율등을계산하여야하며, 산정근거와산정내용은 [ 표 5-18] 과같다. 한편, WAS 서버의메모리크기는 ( 시스템영역 + 관리자영역 + 사용자당필요 )* 버퍼캐쉬 * 클러스터보정 * 여유율, 즉 (384+1+ 274.5)*1.2*1.3*1.3 로계산되며, 산정결과 WAS 서버의시스템디스크크기는약 1,337MB 정도를필요로한다. 따라서메모리확장단위를감안하여 2,048 MB 로선정한다. 61
[ 표 5-18] DB 서버의 CPU 산정근거 항목 산정근거 산정내용 동시사용자 동시사용자 * 증가율 (30%)*3 년 - 250*1.3*1.3*1.3=549 명 시스템영역 OS, DBMS 엔진, 미들웨어 - 64MB + 288MB(32 엔진, 기타유틸리티등의소요 MB+256MB)+ 32MB 공간 : 기본 OS+ 서비스 ( 트랜잭 =384MB 션및데이터베이스 )+ 기타유 틸리티 (RAID 포함 ) 시스템관리자영역관리자수 *0.5MB - 0.5MB *2 명 = 1MB 사용자당필요메모리 DBMS 의 사용에 필요한- 549 * 0.5MB= 274.5MB 사용자 당 메모리로 사용자 *DB 필요메모리로산출 버퍼캐쉬 일반적인값 20% 로적용 1.2 클러스터보정 상대방 메모리크기를 고려한 1.3 예비율로 30% 적용 여유율 예기치못한상황및확장에 1.3 대한여유율로 30% 적용 2.3 디스크 데이터베이스서버의디스크는시스템디스크와데이터디스크로나누어 산정한다. WAS 서버 WAS 서버의시스템디스크를용량산정항목과산정근거, 산정내역은 [ 표 5-19] 와같다. WAS 서버의시스템디스크의크기는 ( 시스템 OS 영역 + 응용프로그램영역 + SWAP 영역 )* 여유율, 즉 (500+1,000+2,048)*1.3 로계산되며산정결과 WAS 서버의시스템디스크크기는약 4.6GB 정도를필요로한다. 62
[ 표 5-19] WAS 서버의시스템디스크산정근거 항목 산정근거 산정내역 시스템 OS 영역 WindowNT 500MB 응용프로그램영역 응용프로그램 1GB SWAP 영역 서버메모리의 2 배적용 2,048MB 여유율 성능향상공간 30% 적용 1.3 DB 서버 - 시스템디스크 데이터베이스서버의시스템디스크용량산정항목과산정근거, 산정 내역은다음의표와같다. [ 표 5-20] DB 서버의시스템디스크산정근거 항목산정근거산정내역 시스템 OS 영역 WindowNT 응용 S/W 영역 DBMS 500M 1GB SWAP 영역서버메모리의 2 배적용 4,096MB 여유율성능향상공간 30% 적용 1.3 데이터베이스서버의시스템디스크의크기는 ( 시스템 OS 영역 + 응용 S/W 영역 + SWAP 영역 )* 여유율, 즉 (500+1,000+4,096)*1.3 로계산되며산정결과데이터베이스서버의시스템디스크크기는약 7.2GB 정도를필요로한다. - 데이터디스크 데이터베이스서버의데이터디스크를용량산정항목과산정근거, 산정내역은 [ 표 5-21] 과같다. 한편데이터베이스서버의데이터디스크의크기는 (DB 영역 + 백업영역 )*RAID 영역 * 여유율, 즉 11,102MB*1.2*1.3 로계산되며, 산정결과데이터베이스서버의시스 63
템디스크크기는약 17.3GB 정도를필요로한다. [ 표 5-21] DB 서버의데이터디스크산정근거 항목산정근거산정내역 DB 영역 - 실자료공간 ( 건수 * 건수별 - 실자료건수 : 9,887 건 / 일데이터사이즈 * *0.5K*30 일 *12 월 *3 년 보관기간 ) = 5,338MB - 예비용데이터공간 ( 실 - 예비용데이터공간 : 데이터공간의 30%) 5,338MB*0.3 = 1,601MB - 인덱스및키용실데이터 - 인덱스및키용실 공간 (1+2 의 60%) RAID 영역 RAID-5 적용 1.2 데이터 여유율성능향상공간 30% 적용 1.3 공간 :(5,338MB+1,601MB) *0.6 =4,163MB - DB 영역 : 5,338MB+ 1,601MB + 4,163MB = 11,102MB 64
제 2 절용량산정도구 일반적으로 H/W 벤더들은시스템구성을위한용량산정및성능평가를위한간단한도구를보유하고있다. 따라서기존 H/W 벤더들의용량산정을위한도구를검토해시스템화방안을제시하는것이바람직할것으로보인다. 따라서본절에서는한국전산원의 2002 년 H/W 용량산정관련연구 결과로제시된 EXCEL 계산식과 IBM 의 High volume Web site Simulator(HVWS) 의특성과기능을중심으로살펴보았다. 1. 기존용량산정도구 한국전산원 EXCEL 계산식 한국전산원의 EXCEL 계산식은 2002 년자체연구로진행된 H/W 용량산정관련연구 의결과로서 TPC-C, 국내 SI 기업의용량산정방법, 정보화사업사례를통해나름대로의기준안을마련하고마련된기준안을적용하여 CPU 와메모리의용량산정 EXCEL 계산식을만든것이다. 이것은서버의용량산정을보다간단히수행해볼수있도록작성되었으며, 제공된 EXCEL 계산식은값의변화와적용비율에따른결과값을즉시확인해볼수있도록하여서버의환경변화와요구조건에맞는적정한서버를선택하고판별하는데도움을주고자하였다. 다음은 EXCEL 계산식의메인화면을보여주고있다. 65
[ 그림 6-1] EXCEL 계산식메인화면 H/W 용량산정에서는 CPU 와메모리용량산정을수행해볼수있도록되어있으며, CPU 용량산정의경우는계산된용량 (tpmc) 에따른서버의벤더별제품및가격을확인해볼수있도록하고있다. [ 그림 6-2] CPU 용량산정화면 66
[ 그림 6-3] 메모리용량산정화면 CPU 의용량산정에있어서입력값에해당하는각셀당도움말을제공하고최종 tpmc 값이얻어지면결과값을통해최근의벤더별서버제품사양및가격대를확인해서관련사업의적정한서버용량산정뿐만아니라예산부분에있어서도검토가쉽게이루어질수있도록하였다. IBM 사의 High volume Web site Simulator(HVWS) IBM 사의 High volume Web site Simulator 는분석적큐잉모델 (Analytical queueing model) 로서사용자가정의한다양한워크로드를갖는웹사이트의성능을추정하기위해만들어졌다. 이모델의결과는 H/W 구성요소의산정을위한가이드라인으로서사용될수있다. 절대적인성능결과치를이모델에서제공하지는않으며, 추정된구성요소에는백업장비와같은서버는포함하지않고있다. 따라서이를적용하는사람이필요로하는서버를추가적으로고려함으로써포함시킬수는있다. 작업부하에대한실제성능은많은변수들간의복잡한상호작용에의해서영향을받는데이러한변수를전부포함하여모델화되지는않았다. 왜냐하면이모델의결과가벤치마킹이나상세한응용의검토를대체할수없기때문이다. 67
한편, 이시뮬레이터의입력은시뮬레이션하고자하는비즈니스형태와각사용자별상호작용의형태를정의하고각트랜잭션에대한 think time 을추정하기위한비즈니스패턴영역과응답시간및동시사용자수등과같은성능목표치를제시하는목표그리고적용하고자하는서버의수와형태를기술하는 H/W 토폴로지영역, 마지막으로운영체제, 데이터베이스, 백그라운드운용소프트웨어등을명시하는 S/W 영역으로구성되어있다. [ 그림 6-4] HVWS 의비즈니스패턴입력화면 68
[ 그림 6-5] HVWS 의소프트웨어입력화면 이러한각각의영역에세부적인값을지정하고결과버튼을누르면, 결과를보여주는데이러한결과는 [ 그림 6-6] 와 [ 그림 6-7] 에서보는바와같이계산결과와그래프결과치등두가지형태로되어있다. 계산결과는전체요약 (Over all), 평균응답시간 (Min Response time), 이용율 (Utilization), 메모리 ( 메모리 ) 등을보여주며, 그래프결과치는다양한관점에서가시화된결과를보여준다. [ 그림 6-6] HVWS 의계산결과출력화면 69
[ 그림 6-7] HVWS 의그래프결과출력화면 2. 제안된 EXCEL 계산식 HVWS 와같이 H/W 벤더들이제공하는용량산정도구는자사의특정제품에기반해서제시된업무부하를성능관점에서시뮬레이션하는도구들이대부분으로일반적인용량산정의관점보다는개략적인성능모델링혹은성능평가를위한도구의성격을가지고있다. 따라서특정제품에기반하지않고성능을시뮬레이션하는도구를제시하는것은매우어려운일이다. 특히, 본연구를통해서제시된용량산정지침은 H/W 산정을위한방법과같이업무부하에바탕을둔계산적인방식으로성능모델보다는정량적인결과치를보이는계산식의적용이합리적이다. 따라서본과제에서는서버의용량산정을보다간단히수행해볼수있도록제시된용량산정기준에따라기존한국전산원의 EXCEL 계산식을개선하여제시하였 70
다. 제시된 EXCEL 계산식에서의산정대상은 CPU(OLTP, WAS/WEB), 메모리, 디스크등으로구분하고있으며세부적인산정식은 [ 그림 6-8] ~ [ 그림 6-11] 에서와같다. 각각의산정대상에서입력값에해당하는각셀당도움말을제공하고있으며, 입력값이변경됨에따라자동으로값들이산출되도록구성되어있다. [ 그림 6-8] OLTP 서버의용량산정화면 [ 그림 6-9] WEB/WAS 서버의용량산정화면 71
[ 그림 6-10] 메모리용량산정화면 [ 그림 6-11] 디스크용량산정화면 72
제 3 절용량리포지토리구축 1. 자료축척및활용체계 용량산정을위한자료수집체계구축의 1 차적인목표는용량산정용리포지토리구축 / 운영을통해현재제시된용량산정식을보다견고하게하기위해서는많은용량산정자료를바탕으로보정치나여유율의값을보완할수있도록해야한다. 이를위해서지속적인용량산정자료축척이필요하다. 이와같은목적을달성하기위해용량산정을위한자료의축척및활용을위한개념적인체계는 [ 그림 6-12] 와같다. 정보 리포지토리 공공기관한국전산원용량산정기준개정위원회 [ 그림 6-12] 용량산정자료축척및활용체계 이러한용량산정자료의원활한축척을위해서는공공기관의적극적인참여를전제로하여야한다. 그러나이는현실적으로쉽지않은일이다. 따라서사용자들의적극인참여를유도할수있는방안과강제할수있는방안이동시에고려되어야한다. 따라서이러한측면에서용량자료의축척을위해서는단계적인접근방법을제시하면 [ 표 6-1] 과같다. 용량자료의축척은크게 2 단계로나누어수행할수있는데, 우선, 1 단계 ( 도입단계 ) 에서는한국전산원이수행하고있는정보화지원사업을 대상으로용량산정정보를축척하여성과를확인하고, 확대운영단계인 2 단계에서는 제도적인 보완을 통해서 공공기관의 정보시스템 도입장비의성능평가 등과 연계하여 전체 공공기관의 참여를 73
유도하는것이바람직할것이다. 이러한자료의축적은앞서언급한 바와같이장기적인관점에서추진되어야, 필요시제도적인접근을 통해서의무화하는방안을고려할필요가있다. [ 표 6-1] 용량자료축척을위한단계적접근방법단계적용대상및범위비고 1 단계 ( 도입단계 ) 한국전산원이수행하고있는정보화지원사업을대상으로용량산정정보를축척 2 단계공공기관의정보시스템도입장비의법적 / 제도적강제 ( 확대운영단계 ) 성능평가등과연계하여전체공공기성을갖도록규정 관으로확대운영 하는것이필요 2. 용량리포지토리시스템구성 용량산정을위한리포지토리시스템은웹시스템을기반으로한국전 산원내부에용량산정포털사이트를구축하여서비스를제공한다 한국전산원 [ 그림 6-13] 용량리포지토리시스템구성 74
공공기관및민간의사용자들의적극적인활용을위하여용량산정을위한리포지토리는단순히용량산정정보의축척만을목적으로하는것은아니며, 제시된기준에따른용량산정기능을제공함은물론용량산정을위한기준, TPC 및 SPEC 등국제성능평가기관의서버에대한성능평가치, 각종용량산정에자료등을제공하도록한다. [ 표 6-2] 리포지토리의기능및제공정보 구분 내용 주요기능 제공정보 - 용량산정계산기능 - 자료분석기능 - 통계기능등 - TPC 및 SPEC 등국제성능평가기관의서버에대한성능평가치 - 각종용량산정자료 - 관련사이트정보등 한편, 이러한용량산정에수집자료로는용량산정을수행하는기관정보, 사업정보, 용량산정기초정보, 정보화전략계획수립정보, 성능평가자료등이다. 사업정보는정보화계획수립자료를입력하는경우에는불필요하다. [ 표 6-3] 리포지토리의수집정보 수집정보 내용 기관정보 기관명, 연락처등기관기초정보 사업정보 사업명, 사업기간, 사업개요, 사업추진형태 ( 자체 / 외부 위탁 ), 사업비, H/W 비용등사업정보 75
[ 표 6-3] 리포지토리의수집정보 ( 계속 ) 용량산정 시스템구축형태 정보 사용자수 트랜잭션수온라인업무업무량배치업무량데이터베이스데이터백업운영시간네트워크속도등 정보화전 1, 2, 3 차년도의시스템개발계획포함 략계획수 년차별응용시스템개발계획및각시스템별조직인원, 립자료 사용자현황년차별응용시스템개발계획및업무량증가율근거와가정년차별데이터베이스개발계획정보화전략계획자료에근거한년차별성능예상치 ( 구축완료시점, 1 년후, 2 년후, 3 년후 ) 업무특성에따른월별, 요일별, 일별, 시간대별업무폭주시예상치 성능평가 계수화된성능요구사항 의자료 monitoring tool 을사용한성능치 도입된시스템사양 업무량증가와년차별신규업무증가등을고려한 H/W upgrade(cpu 및메모리, i/o board) 실적등 상기자료외에도앞서서연구된내용을포함하여야하며, 저장된자료를참고자료로활용할수있도록시스템을개발하여야한다. 또한, 시스템도입계획과성능평가결과간의차이분석을하며, 그원인과결과를항목및계수화조정작업에반영할수있는시스템개발이필요하다. 76
참고문헌 [1] 김성근외 1, 2002, Enterprise Architecture 의필요성및추진방안, Information Systems Review 제 4 권제 2 호 [2] 정보통신부, 2003 정보화에관한연차보고서. [3] 정보통신부, 2001, 정보화지원사업관리요령. [4] 정인수외 2, 2001 건설산업의지식관리체계로드맵, 한국전자거래학회지 [5] 정해용, 2002, 공공부문정보시스템의통합적평가모형, 광운대박사학위논문 [6] 한국전산원, 2002, H/W 용량산정관련연구 [7] 한국전산원, 2001a, 정보기술아키텍처이용방안연구 [8] 한국전산원, 2001b, 정보화지원사업관리지침 [9] 한국전산원, 2000, 국가정보화평가추진모델개발 [10] 한국전산원, 1994, 용량산정도구개발및성능측정보고서 [11] 한국전산원, 1993, 주전산기 II(Ticom) 의성능관리에관한연구 [12] Compaq, 2001, Sizing a thin client Server Computing Solution Deploying Compaq ProLiant DL series Servers. [13]Daniel A. Menascé, 1998, Capacity Planning for Web Performance: metrics, models, and methods, Prentice Hall [14] Dell, 2001, Sizing Lotus Domino server for poweredge 6400. [15] IBM, 1999, Capacity Planning for web application. [16] IBM, 2000, Web application deployment: A practical approach to capacity planning. [17] Jon Direccks, 1999, Memory sizing : Can you have too much of a good thing?. [18] Kimberly Keeton and David A. Patterson, 2000, Toward a Simplified database workload for computing Architecture evaluations [19] Key2Web, 2001, Scalability & Availability Analysis. [20] Microsoft, 2001, Microsoft Small Business Sever Capacity Planning. [21] Microsoft, 1999, Capacity Model for Internet Transactions, MSR-TR-99-18. 77
[22] Randy Johnson, 1995, Performance monitoring and capacity planning, ITworld. [23] Rich Schiesser, 2002, Ten tip for effective capacity planning. [24] SIC competence Center, 2001, PAMS Sizing Questionnaire [25] Sun, 1999, Sun server scalability and sizing guide. [26] Sun, 1998, The Solaris Memory System. [27] Tim R. Norton, 1997, Simalytic Hybrid Modeling : Planning the Capacity of Client/Server Application. [28] Waston, 2003, Why your CPU capacity Not Match your vendor s Estimate. [29] William S. Cool, 1998, Client/Sever Capacity Planning Why and How. [30] www.ideasinternational.com [31] www.spec.org [32] www.tpc.org