<4D F736F F D20B0F8B0F8BACEB9AE20C1A4BAB8BDC3BDBAC5DB20BFEBB7AEBBEAC1A420B1E2BCFA20B9D720C7C1B7B9C0D3BFF6C5A920BFACB1B85F20C0CCA1A6>

Transcription

1 NCA IV RER / 정보시스템용량산정기술및프레임워크연구 (H/W 규모산정을중심으로 ) A Study on Hardware Sizing Technique And Framework for Information Systems (Focus on H/W sizing) 수탁기관 : 광주대학교 한국전산원

2 NCA IV RER / 정보시스템용량산정기술및프레임워크연구 -H/W 규모산정을중심으로 - A Study on Hardware Sizing Technique And Framework for Information Systems - Focus on H/W sizing 수탁기관 : 광주대학교 한국전산원

3 제출문 한국전산원장귀하 본보고서를 정보시스템용량산정기술및프레임워크연구 의최종 연구개발결과보고서로제출합니다 년 10 월 8 일 수탁기관 : 광주대학교연구책임자 : 나종회 ( 광주대학교교수 ) 참여연구원 : 최광돈 ( 한세대학교정보기술학부 ) 류해리 ( 성균관대학교정보통신공학부 ) 김지훈 ( 광주대학교 e-비즈니스학부 ) 최점기 ( 광운대학교경영학부 ) 진동욱 ( 광운대학교경영학부 ) 과제관리자 : 이헌중 ( 한국전산원지식정보기술단정보화표준팀 ) 이승한 ( 한국전산원지식정보기술단정보화표준팀 ) i

4 요약문 1. 제목 정보시스템용량산정기술및프레임워크연구 2. 연구개발의목적및중요성 현대사회에서는한국가의경제, 사회, 정치, 문화등제반분야의경쟁력이정보기술의효과적활용에따른정보화수준과이를가능하게하는정보통신산업의발전에의해좌우되고있다. 이에따라세계각국이국가경쟁력제고를위해국가적차원에서정보화촉진정책을추진하고있으며우리나라도지속적인경제성장과국가의경쟁력강화및선진화를이루어선진국대열에진입하기위해서국가사회의정보화를최우선과제로삼고있다. 따라서정부는효율적인정보화추진이 21세기국가발전과국제사회에서의주도권확보에필수불가결한요소임을인식하고정부부처를비롯한공공부문에있어서업무생산성이나대국민서비스향상등의목적으로정보시스템구축에대규모투자를지속적으로추진하고있다. 정보시스템은 mainframe에서 C/S 시스템, Internet, Intranet 시스템환경으로발전하면서시스템구성의복잡성과사용대상의확대로인해시스템성능및용량관리의중요성이점점크게부각되고있다. 정보시스템성능및용량관리의실패는막대한비용과인력의낭비를초래하고업무생산성을저하시키며대국민서비스에악영향을끼친다. 정보시스템성능및용량관리는정보시스템에대한불신을초래할수있는품질관리의매우중요한요소로서정보시스템자원도입시이를체계적으로산정하는것이매우중요하다. 그러나한국전산원에서실시한공공부문의통합정보시스템환경조사결과에따르면, 공공부문의정보시스템자원의활용률이매우저조하며해당기관의업무량을고려한 i

5 장비도입이이루어지지못한것으로파악되었다. 이는정보시스템에대한 성능개선과도입을위한명확한규모산정기준의미비에서그원인을 찾을수있다 한편, 정보시스템의용량은업무의성격, 업무증가율, 사용자사용빈도, 구축기술등을전체적으로고려하여산정해야하므로, 용량적정성의옳고그름을판단하는것은어려운일이다. 실제로시스템구축사업에서 H/W가차지하는비중이전체프로젝트비용의 50% 에서많게는 90% 를차지함에도불구하고, 그동안시스템구축을추진하는기관혹은시스템공급자의주관적방법으로정보시스템의자원규모를산정함으로써실제요구되는정보시스템자원이과다또는과소산정되는경우가발생하기도하였다. 이로인해서정보화예산편성혹은시스템감사시정보시스템자원에대한적정성여부의논란이끊이지않고있다. 또한, 시스템자원산정의객관성이결여되어불필요한장비를도입하는경우가발생하기도하며, 시스템도입시규모의과다산정으로시스템도입후정보시스템자원활용도저하의현상을보임으로써정보화예산의낭비를초래하기도한다. 따라서정보시스템개발부분에서 소프트웨어사업대가의기준 을준용하고있는것처럼정부가추진하는각종정보화사업추진시, 사업계획서의정보시스템자원관련부문용량산정의적정성판단기준을마련할필요성이제기되고있는상황이다. 따라서국가차원에서정보시스템의용량산정을체계화하고절차별세부기준과적용방법을표준화하여객관적인용량산정을위한절차수립이요구되고있다. 용량산정프레임워크는공공기관에서의시스템도입및시스템증설시정확하고편리한시스템용량산정방법을제공하여야할것이며, 정보시스템의용량산정의지침개발후의활용도를높이기위해서는공공기관및시스템공급자등현업의적극적인참여와이들의현실을반영한실질적인지침이제시될필요가있다. ii

6 3. 연구개발의내용및범위 본연구에서수행하고자하는주요한연구개발의내용과범위는다음과 같다. 정보시스템신규도입및성능향상을위한기술연구와관련표준화방향제시조사 용량산정식고도화와관련하여현재제시된용량산정항목및적용값 ( 보정계수, 여유율등 ) 에대해현업의의견수렴을통한적정성검증 적용사례를통해적용값의범위를객관화하여정확한값을도출 시스템유형에따른용량산정프레임워크제시 실제업무에적용할수있는세부적인적용지침제시 용량산정지침의적용을위한용량산정프레임워크적용예시 4. 연구결과 연구보고서 - 국내용량산정방식및사례조사 - 국외선진사례조사 용량산정방식및사례 용량산정을위한표준화 용량산정항목및지표 - 용량산정프레임워크및세부지침 - 용량산정프레임워크적용예시 - 용량산정로드맵제시 용량산정지침 iii

7 5. 활용에대한건의 정보화사업예가산정, 정보시스템감리및감사에참조기준활용 공공부문정보시스템용량산정방법으로활용가능 정책과제및정보화시행계획검토시기초자료로활용 ISP사업에시스템의용량산정지침을활용 6. 기대효과 국가정보화를추진하면서경험하는서버용량산정노하우를 반영하여지속적으로보완하면, 결과적으로 정보시스템구축시 용량산정기준 으로발전가능 공공부문의정보시스템의신규도입과성능향상을위해시스템용량산정및표준화된프레임워크를제공함으로써, 객관적인기술분석이가능하여정보시스템의적정한선정과평가가이루어질수있다. 궁극적으로정보화투자에대한성과를높일수있을것으로기대 - 적정한기술및장비도입으로장비가동률을개선하여, 불필요한정보시스템운영비용을감소 - 용량산정자료를전자적으로저장 / 제공하여산정기준의완성도를점차적으로제고하고사용자의편리성을제공 iv

8 Summary Interest about information infrastructure construction is decayed socially according to arrival of information age, and various information systems is constructed for efficient business processing, customer service improvement in public sector. According to subjective method of performance improvement for information system of public sector and engine that propel information system construction because it is no definite hardware sizing guidelines for introduction or system caterer, is calculating resources scale of information system. Is situation that problem of excess of scale or reduction sizing is happening, and is causing various kinds problem that is waste of information budget and service decline thereby. Specially, is causing many controversies by absence of these guidelines despite is important guidelines of information system auditing or information system of information business budget heart of public sector. Therefore it is need to developing hardware sizing guidelines for information system that is applied to information programs. v

9 Contents Chapter 1. Introduction Purpose and necessities Contents and scope Research methods Chapter 2. Definition of Terminology Chapter 3. Roadmap for H/W Sizing Definition of H/W sizing Objective of roadmap for H/W sizing Structure of roadmap for H/W sizing Chapter 4. Concept and trend of H/W Sizing Overview of H/W sizing Case and trend of H/W sizing Trend of system performance measurement Reference architecture for H/W sizing Chapter 5. Guidelines for H/W Sizing Overview of guidelines Procedures of H/W sizing Method of H/W sizing Case of H/W sizing Chapter 6. Method of system construction Overview of system construction H/W sizing tool Repository for H/W sizing Chapter 7. Conclusions References Appendix vi

10 목차 제 1 장연구개요 제 1 절연구의목적및필요성 제 2 절연구의내용및범위 연구개발의목표 연구개발의내용 제 3 절연구수행방법 연구개발추진체계 연구개발추진전략 제 2 장용어정의 제 3 장 H/W 용량산정을위한로드맵 제 1 절 H/W 용량산정의정의 제 2 절로드맵목적 제 3 절로드맵구성 H/W 용량산정식연구 정보화전략계획수립과 H/W 용량산정식연구 성능평가에따른 H/W 용량산정식연구 지식 / 정보데이터베이스화시스템구축 제도정비연구 제 4 장 H/W 용량산정개념및현황 제 1 절용량산정개요 용량산정개념 용량산정절차 제 2 절용량산정현황및사례 국내 H/W 용량산정현황 H/W 용량산정에대한기존연구 H/W 용량산정사례 제 3 절시스템성능향상을위한기술동향 TPC 성능기준 vii

11 2. SPEC 성능기준 제 4 절용량산정을위한참조아키텍처 제 5 장 H/W 용량산정지침 제 1 절개요 지침의필요성 지침의적용범위 용량산정의대상 제 2절용량산정절차 용량산정시일반적고려사항 용량산정의절차 제 3 절 H/W 용량산정방식 CPU 메모리 디스크 제 4 절용량산정사례 개요 용량산정 제 6 장시스템화방안 제 1 절시스템화의개요 제 2 절용량산정도구 기존용량산정도구 제안된 EXEL 계산식 제 3 절용량리포지토리구축 자료축척및활용체계 용량리포지토리시스템구성 제 7 장결론 참고문헌 부록 viii

12 그림목차 [ 그림 1-1] 연구개발의목적 [ 그림 1-2] 연구추진체계 [ 그림 3-1] H/W용량산정과제간상호연관관계 [ 그림 3-2] H/W 용량산정로드맵 [ 그림 3-3] 정보화전략계획의수립단계 [ 그림 3-4] 엔터프라이즈아키텍처의구성요소 [ 그림 3-5] 응답시간의정의 [ 그림 3-6] 성능에영향을미치는시스템자원 [ 그림 4-1] 용량산정절차및내용 [ 그림 4-2] WAS 및 DB서버용량산정을위한 IT 아키텍처 [ 그림 4-3] WAS 용량산정을위한 IT 아키텍처 [ 그림 4-4] HVWS의패턴다이어그램 [ 그림 4-5] HVWS의결과치 [ 그림 4-6] TPC-C의시뮬레이션구성도 [ 그림 4-7] TPC-W의시뮬레이션구성도 [ 그림 4-8] SPECweb99의벤치마킹구성도 [ 그림 4-9] SPECjbb2000의벤치마킹구성도 [ 그림 4-10] 계층별컴포넌트 [ 그림 4-11] 일반적인다계층웹사이트아키텍처 [ 그림 5-1] 정보화사업추진단계및주체별적용범위 [ 그림 5-2] 용량산정과정 [ 그림 5-3] 용량산정을위한시스템개념도 [ 그림 6-1] EXCEL계산식의메인화면 [ 그림 6-2] CPU 용량산정화면 [ 그림 6-3] 메모리용량산정화면 [ 그림 6-4] HVWS의비즈니스패턴입력화면 [ 그림 6-5] HVWS의소프트웨어입력화면 [ 그림 6-6] HVWS의계산결과출력화면 [ 그림 6-7] HVWS의그래프결과출력화면 [ 그림 6-8] OLTP서버의용량산정화면 ix

13 [ 그림 6-9] WEB/WAS 서버의용량산정화면 [ 그림 6-10] 메모리용량산정화면 [ 그림 6-11] 디스크용량산정화면 [ 그림 6-12] 용량산정자료축척및활용체계 [ 그림 6-13] 용량산정리포지토리시스템구성 x

14 표목차 [ 표 1-1] 참여주체별역할 [ 표 3-1] 정보화전략계획수립세부활동내역 [ 표 3-2] CPU 용량산정항목과연관된 ISP 산출물 [ 표 3-3] 업무에따른처리량 [ 표 3-4] 성능평가조건메트릭스 [ 표 4-1] 용량계획과시스템규모산정의정의 [ 표 4-2] CPU 산정기준비교 [ 표 4-3] 웹서버의 CPU 산정근거 [ 표 4-4] DB서버의 CPU 산정근거 [ 표 4-5] 웹서버의메모리산정근거 [ 표 4-6] DB서버의메모리산정근거 [ 표 4-7] 웹서버의시스템디스크산정근거 [ 표 4-8] DB서버의시스템디스크산정근거 [ 표 4-9] DB서버의데이터디스크산정근거 [ 표 4-10] 용량산정을위한성능기준치 [ 표 4-11] 시스템별성능비교치 [ 표 5-1] WEB/WAS를위한기초자료조사항목 [ 표 5-2] OLTP를위한기초자료조사항목 [ 표 5-3] 작업부하별적용성능기준치 [ 표 5-4] OLTP 산정항목및보정치 [ 표 5-5] 데이터베이스크기가중치 [ 표 5-6] 어플리케이션복잡도보정치 [ 표 5-7] 사용자복잡도보정치 [ 표 5-8] 어플리케이션구조보정치 [ 표 5-9] 어플리케이션부하보정치 [ 표 5-10] WEB/WAS 산정항목및보정치 [ 표 5-11] 메모리산정항목및보정치 [ 표 5-12] 디스크산정항목및보정치 [ 표 5-13] WAS를위한기초자료조사결과 [ 표 5-14] DB서버를위한기초자료조사결과 xi

15 [ 표 5-15] WAS서버의 CPU 산정근거 [ 표 5-16] DB서버의 CPU 산정근거 [ 표 5-17] WAS서버의메모리산정근거 [ 표 5-18] DB서버의 CPU 산정근거 [ 표 5-19] WAS서버의시스템디스크산정근거 [ 표 5-20] DB서버의시스템디스크산정근거 [ 표 5-21] DB서버의데이터디스크산정근거 [ 표6-1] 용량자료축척을위한단계적접근방법 [ 표 6-2] 리포지토리의기능및제공정보 [ 표 6-3] 리포지토리의수집정보 xii

16 제 1 장연구개요 제 1 절연구의목적및필요성 정보화시대의도래에따라사회적으로정보인프라구축에대한관심이고조되고있으며, 효율적인업무처리, 고객서비스개선등을위해다양한정보시스템이구축되고있다. 공공기관의정보시스템에대한성능개선과도입을위한명확한규모산정기준이없어서정보시스템구축을추진하는기관혹은시스템공급자의주관적방법에따라정보시스템의자원규모를산정하고있다. 이로인하여규모의과다혹은축소산정등의문제가발생하고있으며, 정보화예산의낭비와서비스저하라는여러가지문제를야기하고있는상황이다. 특히, 공공부문의정보화사업예산심의과정이나정보시스템에대한감리시중요한판단기준임에도불구하고이러한기준의부재로인하여많은논란을야기하고있다. 따라서국가정보화사업에실제적으로업무에적용가능한정보시스템용량산정프레임워크및기준을개발할필요가있다. 국가정보화비전달성 정보화투자성과극대화 공공부문정보화사업적용 정보시스템용량산정프레임워크개발 [ 그림 1-1] 연구개발의목적 1

17 따라서, 본과제를통해서공공부문정보화투자와관련하여시스템의투자예산의적정한산출에있어서실질적으로적용가능한 정보시스템용량산정기술연구와프레임워크및지침의개발 을수행하고자한다. 이는궁극적으로정보화사업에개발된프레임워크의적용을통해서정보화사업투자예산을효율적으로산정하고집행함으로써정보화사업투자에대한성과를극대화하여국가정보화의비전을달성할수있도록할것이다. 2

18 제 2 절연구의내용및범위 1. 연구개발의목표 국내의경우 S/W의개발분야와달리 H/W의용량산정에대한연구는매우부족한실정이며공공부분의전체정보화사업에포괄적으로적용할수있는기준이나지침은전무한실정이다. 그러나 2002년한국전산원에서는정보화사업을대상으로사업검토와예산조정에활용될수있도록 H/W 용량산정을위한자체기준을마련하고 2002년도및 2003년도정보화사업을대상으로적용하고있다. 그러나한국전산원의기준역시전체공공부문의정보화사업에범용적인지침으로서의적용하는데는한계를가지고있으며, 제시된용량산정식에대한검증미흡으로인하여실제 H/W 용량산정과관련한다른자료와차이가존재할수있다. 따라서본연구는기존연구결과를바탕으로추가적인연구를수행함으로써공공부문정보화사업과관련된 H/W 용량산정을위한지침을마련하고자한다. 2. 연구개발의내용 본연구를통해서수행하고자하는주요한연구내용은다음과같다. 1 정보시스템신규도입및성능향상을위한기술연구와관련표준화방향제시 2 H/W 용량산정을위한사례및지표조사 - 국내외용량산정사례분석 - 보정계수, 여유율등에대해현업의의견수렴을통한적정성검증 - 적용사례를통해적용값의범위를객관화하여정확한값을도출 3 H/W 용량산정프레임워크및지침제시 - 실제업무에적용하기위한세부적인적용지침제시 - 용량산정지침의적용을위한용량산정프레임워크적용예시 3

19 위연구내용을수행하기위하여다음과같이정보시스템신규도입및성능향상을위한기술연구와관련표준화방향제시, H/W 용량산정을위한사례조사 / 지표설정및검증, 용량산정프레임워크및지침제시, H/W 용량산정을위한시스템화방안제시등 3단계로나누어수행하며, 세부적인내용은다음과같다. 1 정보시스템신규도입및성능향상을위한기술연구와관련표준화 방향제시 성능평가와관련한국제규격 (ISO/IEC), TPC(Transaction Processing Performance Council), SPEC(Standard Performance Evaluation Corporation) 등민간비영리단체및학계에서수행하는벤치마크테스트의내용등을중심으로문헌조사를통해서정보시스템신규도입및성능향상을위한기술과관련표준화대상을분석한다. TPC : 성능테스트와관련된대표적인단체로원래 DBMS에대해성능을테스트하기위해 1988년 8월설립되고 IBM, FUJITSU등 23개사가회원으로가입된비영리단체이다. TPC에서실시하는성능시험은신뢰성과내구성테스트를모두포함해실시하고있으며독립감사를거쳐야하는매우엄격한검증과정을거친다. TPC 가실시하고있는성능테스트의종류는 TPC-A, TPC-B, TPC-C, TPC-D, TPC-H, TPC-R, TPC-W 등다양한종류가있으나현재 TPC-A와 TPC-B, TPC-D는사용하고있지않다. TPC가성능테스트를위해중요하게여기는변수는웹환경에서얼마나많은데이터를처리할수있느냐는것이다. 특히, TPC-C는온라인트랜잭션처리 (OLTP) 시스템의성능과확장성을측정하기위한산업표준벤치마크테스트로여겨지고있으며, 실제로 IT 전문가들은 TPC-C가실질적인 OLTP 시스템성능을나타내는유효한지표라고인정하고있다. SPEC : 1988 년 11 월에설립되어현재 HP, 썬마이크로시스템즈 4

20 등 60개이상의시스템업체가컨소시엄형태로참여하고있으며시스템성능테스트에있어서권위를인정받고있다. SPEC의벤치마킹테스트중가장권위있는벤치마크테스트는 CPU 성능테스트이다 2 H/W 용량산정을위한사례및지표조사 용량산정현황및사례를분석하고기존연구결과에서제시한용량산정항목및세부적인지표를설정한다. 현행공공부문정보시스템평가대상사업은 1997년부터 2002년도까지 6년간 173개이다. 그중 2002년도 (2001년도사업실적 ) 정보화사업평가대상은 10개분야 75개이었다. 정해용 (2002) 은정보시스템지향대상 ( 내부지향, 고객지향 ) 과정보시스템의영향범위 ( 응용업무 / 정보인프라 ) 정도를이용하여공공부문의정보시스템을고객지향응용업무, 고객지향정보인프라, 내부업무응용업무, 내부운영정보인프라 4가지유형으로구분하는평가모형을제시하였다. 이모형에따라정보시스템용량산정지표가상이할것이라고판단되어각각의유형에맞는사례조사를할계획이다. 사례조사분석을통하여유형별로항목및지표와계수를구하고자한다. 3 용량산정프레임워크및지침제시와용량산정프레임워크의시스템 화방안제시 시스템유형별용량산정을위한전체적인프레임워크를제시하며용량산정절차, 주요반영요소및절차별세부적인기능, 용량산정방식그리고용량산정을위한 Input/Output 산출물을제시하며최종적으로시스템을통한용량산정의객관성을확보할수있도록용량산정프레임워크의시스템화방안을제시한다. 5

21 제 3 절연구수행방법 1. 연구개발추진체계 본연구는광주대학교가주도하여수행하며 H/W 용량산정기준은문헌적인접근보다는경험에근거한실질적인접근이중요한요소이므로객관성과신뢰성을확보하기위하여 H/W벤더, SI업체, 사용자그룹등이해당사자들을중심으로전문가협의회를구성하여적극적인참여를유도하며, 추가적인검증을위하여별도의자문위원회를구성운영함으로써연구의실질적인효과를높이고자한다. [ 그림 1-2] 연구추진체계 한편, 본연구와관련된참여주체별역할을정리하면다음과같다. 6

22 [ 표 1-1] 참여주체별역할구분 역할 비고 위탁연구수행 - 국내외현황조사및문헌조사 과제수행기관 ( 광주대학교 ) - 용량산정항목및지표제시 - 용량산정프레임워크및지침개발 연구사업비관리 연구결과보고 ( 월간, 중간, 최종 ) 위탁과제관리 과제관리기관 ( 한국전산원 ) 연구자료제공및연구방향제시 설문조사를위한창구제공 ( 필요시 ) 용량산정프레임워크및지침을위한워크샵개최 ( 필요시 ) 10 명내외의학계, 업계, 공공부문전문 용량산정전문가협의회용량산정자문위원회 가로구성된용량산정전문가협의회를운영하며, 연구결과검토수행 ( 월 2회 ) 용량산정프레임워크개발내용, 고려사항, 향후방향성에대한자문제공 용량산정전문가협의회와별도로학계의전문가 6인으로구성된자문위원회구성 프레임워크제시후자문수행 2. 연구개발추진전략 본연구에서는전술한연구목표와연구내용을수행하기위해서다음과 같은추진전략에따라연구를수행한다. 7

23 1 용량산정프레임워크개발 - 용량산정관련문헌및실제사례를중점적으로분석하여정보시스템용량산정을위한공식및절차, 지침개발 - 용량산정전문가협의회및학계전문가로구성된자문협의회의자문을받아작업수행 2 용량산정전문가협의체구성및운영 - 용량산정에대한지침은직접적인이해당사자인한국전산원, 정보화추진기관 ( 사용자그룹 ), 시스템솔루션업체 (SI업체및 H/W 벤더등 ) 이될수있음. 관련이해당사자들의의견을충분히수렴하여, 현실적이고적용가능한지침서작성 - 10명내외의학계, 업계, 공공부문전문가로구성된용량산정전문가협의회를구성하고이를정기적으로운영 ( 월 2회개최 ) - 용량산정전문가협의회를통해서용량산정프레임워크개발내용, 고려사항및향후방향성등에대한자문수행 - 용량산정연구결과물에대한품질을보장하기위해용량산정협의회와별도로학계의전문가 6인으로구성된자문위원회구성및운영 ( 프레임워크제시후시행 ) 8

24 제 2 장용어정의 Cache : 최근에접근한데이터를저장하고있는작은고속의기억장치이며나중에동일한데이터에다시접근할때접근속도를높이기위한것이다. 캐싱기술은프로세스와메모리접근에가장많이적용되어왔지만, 네트워크를통해서접근할수있는데이터의지역사본을저장하는데도사용되어왔다. Cache Server : Cache기능을인터넷에응용한기술로서모든사용자들이자주이용할만한웹페이지, FTP 및기타파일들을저장하고있다가이들페이지에대한요청이있는경우요구되는인터넷에가서찾지않더라도쉽게만족시킬수있도록하기위한서버이다 CGI(Common Gateway Interface) : 사용자가제공한정보를웹서버스 크립트를통해서프로세싱하기위한프로토콜이다. Client : 사용자와상호작용하고사용자인터페이스를실행하며, 사용자질의어나트랜잭션으로부터서버로전송되는한개이상의요청을생성하며, 적절한프로세스간통신메카니즘을이용하여요청을서버로전송하고서버로부터결과를수신하여사용자에게제시하는프로세스이다. C/S(Client/Server) : 응용프로그램에의해서수행되는작업을두가지프로세스-클라이언트와서버-로분리되는개념을기반으로하고있다. 서버는클라이언트로부터요청을수신하고그결과를클라이언트로전송한다. DBMS(Database Management System) : 사용자가데이터베이스를생 성하고유지해주기위한프로그램의집합이다. CPU(Central Processing Unit) : 중앙처리장치를말하며, 흔히프로세 서라고한다. 9

25 Hardware Sizing( 하드웨어규모산정 ) : 주어진작업부하를위한시스 템형상이결정되는베이스라인을제공하는것이다. Mail server( 메일서버, 우편서버 ) : 전자우편서비스를제공하는컴퓨 터시스템. 즉, 전자우편을전달받거나다른시스템으로전자우편을전 달할수있는기능을가지고있다. Memory ( 보조기억장치 ) : 일반적으로메모리는컴퓨터의작업영역을말하는것으로, 이러한메모리는사용자가응용프로그램을사용시, 중앙처리장치가사용자가지정한작업을수행하는동안필요한프로그램과자료등을보관해두는장소이다. NAS (Network Attached Storage) : NAS 는네트워크에접속되도록특 화된파일서버이다. 이것은 Ethernet 이나 TCP/IP 와같은전형적 LAN 프로토콜을사용한다. Network : 한대혹은그이상의컴퓨터를연결하여근거리나원거리 통신을제공하고서로연결된요소들간의데이터등을전송하는통신망 이다. RAID(Redundancy Arrays of Inexpensive Disks) : 중대형컴퓨터의보조기억장치로서장애발생요인을최대로제거한고성능의무정지대용량저장장치이다. 여러개의하드디스크를하나의가상디스크로구성하는대용량저장장치구축이가능하며, 다수의하드디스크의데이터를분할하여병렬전송함으로써전송속도를향상시킨다. 또한, 시스템가동중에디스크에물리적손상이발생되어도시스템정지없이새디스크로교체하면서원래의데이터를복구할수있다. RAID는데이터가용성과총저장용량을증가시키며여러물리적디스크에대한데이터를적절히분산시킴으로써효율성을높이는것이다. 10

26 SAN(Storage Area Network) : SAN은스토리지시스템을연결해별도의네트워크를구성하는방식으로스토리지전용 LAN을별도로구성하는것이라고볼수있다. LAN이 Local Area Network의약자인점을감안하면 SAN 역시스토리지시스템끼리연결해놓은자체네트워크이라는점을이해할수있다. 즉, 별도의데이터전달통로를통해스토리지시스템에액세스하기때문에일반네트워크소통량에영향을받지않고신속한데이터액세스가가능하다. SPEC(Standard Performance Evaluation Corporation) : 표준화된벤치 마킹을개발하고검토결과를공개하는컴퓨터산업벤더들로구성된단 체이다. SPECweb : SPEC 이시스템의웹서버로서의역할능력을측정하기위 해서개발된표준벤치마크이다. SQL(Standard Query Language) : 관계데이터베이스정의하고접근하 기위한표준언어이다. TPC(Transaction Processing Performance Council) : 트랜잭션프로세 싱과데이터베이스벤치마킹을정의하기위하여설립된비영리단체이 다. Transaction( 거래 ) : 데이터파일의내용에영향을미치는모든거래이 다. 입고, 출고, 판매, 반품, 입출금, 정정, 손실등의모든행위이다. WAS(Web Application Server) : 웹이탄생한이래, 주로데이터베이스 조회나일반적인비즈니스로직에대한처리를위해다양한언어로개발 된인터넷 / 인트라넷환경의소프트웨어를지칭한다. Web server( 웹서버 ) : 웹서비스를제공할수있는환경을구축하기 위해사용되는소프트웨어. 즉, 원격지에있는다른사람들이웹브라우 11

27 저를통해웹정보를이용할수있도록해준다. 따라서, 웹서비스를제 공하려면, 웹서버를사용해웹사이트를구축해야한다. Wide Area Network( 광역통신망 ) : 일반적으로 WAN이라는약자로표현되는광역통신망은지방과지방, 국가와국가또는대륙과대륙등과같이지리적으로완전하게떨어져있는장거리지역사이를연결하고있는통신망이다. Workload( 작업부하 ) : 주어진시간안에컴퓨터시스템이처리해야하 는작업의양과작업의성격이다. Throughput ( 처리량 ) : 요청이시스템을떠나는비율 ( 단위시간당출발 개수로측정 ) 이다. Protocol ( 프로토콜 ) : 컴퓨터가특히네트워크를통해서상호작용하는 방식을기술하는공식적인규칙의집합이다. Proxy Server( 프록시서버 ) : 클라이언트에대해서는서버를대신하고서버에대해서는클라이언트를대신하는에이전트역할을수행하는특수한종류의웹서버이다. 일반적으로프록시서버의접근속도가느리거나접근비용이더비싼다른서버들상에서가용한항목들의캐쉬로사용된다. Peak traffic rate ( 피크트래픽율 ) : 피크사이트트래픽과평균사이트 트래픽사이의비율이다. 12

28 제 3 장 H/W 용량산정을위한로드맵 제 1 절 H/W 용량산정의정의 개략적인시스템아키텍처와응용업무를기반으로시스템에요구되는 성능요구사항이제시되었을때, 그것을 H/W 요구사항으로변환하는것을 H/W 용량산정이라고부른다. 제 2 절로드맵목적 H/W 용량산정을위한로드맵이란정보화를추진하는기업이나 SI 업체, H/W 벤더사등의당사자들에게체계적이고효율적으로 H/W 용량산정을 할수있는지침을제시하는것을목적으로한다. 13

29 제 3 절로드맵구성 H/W 용량산정을위한과제로산정식을구성하는항목과지표값에대한 H/W 용량산정식연구, 산정식의지표값정확성확보를위한정보화전략계획수립과 H/W 용량산정식연구, 성능평가에따른 H/W 용량산정식연구, 지식 / 정보 DB 시스템구축, 제도정비연구등 5가지를제안한다. 이들을 H/W 용량산정과관련시켜간단하게설명하면다음과같다. 먼저, 공공부문의정보화사업과관련하여기존에적용하고있는 H/W 용량산정기준을보완하여범용적으로활용할수있는 H/W 용량산정프레임워크를제시한다. 그중가장중요한 H/W 용량산정식을도출하고이를구성하는항목과지표들을도출한다. 금번과제에서연구되는내용이다. H/W 용량산정에있어서적절한용량산정항목및정확한지표설정이매우중요하다. 왜냐하면, 선정된항목이나지표값에따라용량산정결과가큰차이를나타낼수있기때문이다. 특히, 지표값을보다정확하게산출하는방법에대한연구가필요하다. 일반적으로용량산정시에는정보화전략계획수립결과나구축할정보시스템분석설계서를참고한다. 그러나, 참고할자료가없는경우에는질의서를이용한다. 질의서는충분히정의된자료를근거로하지않고응답자의경험과개략적인수치를이용하기때문에용량산정의정확성이낮다. 그러므로보다정확한용량산정을위해서는용량산정항목과지표에관련된내용을포함하는정보화전략계획수립보고서나정보시스템분석설계서를활용해야한다. 따라서, 다음에는정보화전략계획수립과 H/W 용량산정식에관한연구가이루어져야한다. 다음으로는성능평가에따른 H/W 용량산정식에관한연구를통하여용량산정항목에대한검증이필요하다. 현재는 H/W 용량산정시일정한가정을토대로항목과지표값을적용하고있다. 이를토대로시스템을선정하고개발, 설치, 운영한다. 그러나, 운영환경하에서성능평가를하여도입시예상한성능지표값과차이를분석하여 H/W 용량산정시적용된항목과지표값의타당성을검증할수있을것으로생각된다. 따라서, 성능평 14

30 가에따른 H/W 용량산정식에대한검토및조정에대한연구가필요하다. 또한, 지식 / 정보 DB 시스템구축이필요하다. 현재추진하고있는정보화사업과연계하여각사업에서발생하는지식을데이터베이스화하고, 지식화할수있는시스템을구축해야한다. 정보시스템을도입하는기관의정보화전략계획수립자료, H/W 용량산정관련자료, 성능평가항목과성능평가결과지표, 차이분석등의결과를데이터베이스화하여용량산정식에매우중요한항목과지표값적용의정확성을높이는데유용한분석자료로활용될수있게한다. 또한관련기관이나업체에게 Know-How 뿐만아니라, Know-Where 정보도공유할수있게한다. 위에서설명한 H/W 용량산정과관련된정보화전략계획수립, 용량산정 식도출, 성능평가, 지식 / 정보 DB 화간의상호연관관계를도식화하면 [ 그 림 3-1] 과같다. [ 그림 3-1] H/W 용량산정과제간상호연관관계 앞에서설명한 H/W 용량산정과관련된정보화전략계획수립, 용량산정식도출, 성능평가, 지식 / 정보 DB화과제와앞에서설명하지않은제도정비를포함한 H/W 용량산정로드맵은 [ 그림 3-2] 와같다. 추가된제도정비는 H/W 용량산정을보다정확하게구축할수있도록관련지식 / 정보를데이터베이스화할수있도록자료를제공하도록하는제도와공공부문의 15

31 정보화사업을평가하는조직에보다정확한자료제공과의사소통을위한 장치를마련하기위한것이다. [ 그림 3-2] H/W 용량산정로드맵 로드맵에나타난년차별과제와그목표를설명하면다음과같다. 먼저 2003년에는용량산정항목및지표값, 산정식을도출하는과제를수행하고, 2004년에는지표값의정확성을확보하기위한정보화전략계획수립과정을연구하고, 보다정확한산정식을도출하기위해변경이필요한항목과지표값을확인하기위한성능평가과제를수행한다. 2005년에는지식 / 정보데이터베이스화시스템을구축하고, H/W 용량산정을보다체계적으로할수있는제도를연구한다. 아래에서는 H/W 용량산정과관련된용량산정식도출, 정보화전략계획 수립, 성능평가, 지식 / 정보 DB 화, 제도정비등을설명한다. 1. H/W 용량산정식연구 H/W 용량산정식과제는금번연구의주된내용으로제 4 장이후에기술 될내용이다. 연구될내용을간략히기술하면다음과같다. 용량산정관 16

32 련문헌및실제사례를중점적으로분석하여정보시스템용량산정식및 절차를개발한다. 이는용량산정전문가협의회및학계전문가로구성된 자문협의회의자문을받아작업을수행한다. 2. 정보화전략계획수립과 H/W 용량산정식연구 아래에서는정보화전략계획 (ISP; Information Strategy Planning, 이하 ISP) 에대하여간략하게살펴보고, ISP 와 H/W 용량산정항목과의관계를 알아본다. 한국전산원의 ISP 수립지침에서는국내. 외정보화전략계획수립방법론 을비교. 검토하여 ISP 에서반드시수행하여야할항목을포함하고있으며, 아래 [ 그림 3-3] 과같은 3 단계로정리하였다. [ 그림 3-3] 정보화전략계획의수립단계 정보화전략계획수립을위한단계별주요내용및세부활동내역은다음 과같다. 정보화계획수립준비단계 : 조직의특성과환경, 요구사항에맞 17

33 는정보화계획을수립하기위해프로젝트의목표를파악하고, 프 로젝트의범위및접근방법을결정한다. 정보화기본계획수립단계 : 조직의경영전략과정보요건을분석 하고조직의전반적인현황을파악한후정보와정보기술을활용 할정보시스템구조를설정한다. 정보화실행계획수립단계 : 정보화기본계획에따라실행항목을 도출하고각각에대한비용 / 효과및자원요건을분석한후우선순 위를설정하여세부일정계획을작성한다. 정보화전략계획수립을위한단계별주요산출물및세부주요작업은다 음과같다. 범위정의및편성시에프로젝트추진계획서, 추진조직도, 일정및자원계획서, 작업계획서를작성한다. 업무및환경분석시에경영전략분석서, 외부환경분석서, 내부환경분석서, 정보화목적을작성한다. 현황평가활동에서는응용시스템목록, 파일 / 데이터베이스목록, 장비 / 소프트웨어목록, 조직및관리관행, 현황평가 / 분석서를작성한다. 정보기술전략수립단계에서는정보기술전략보고서, 정보기술구축요소기술을파악한다. 정보시스템구조정의시에는데이터구조, 응용시스템구조, 기술구조, 조직구조를파악한다. 정보화실행계획수립단계에서는상기산출물을통합하여데이터및응용시스템구축계획, 시스템구조구축계획, 조직계획, 이행계획, 실행계획을작성한다. 이상을정리하면 [ 표 3-1] 과같다. 18

34 [ 표 3-1] 정보화전략계획수립세부활동내역단계활동산출물주요작업 정보화계획수립준비정보화기본계획수립정보화실행계획수립 - 프로젝트추진계획서범위정의 - 추진조직도및편성 - 일정및자원계획서 - 작업계획서 - 경영전략분석서업무및 - 외부환경분석서환경분석 - 내부환경분석서 - 정보화목적 - 응용시스템목록 - 파일 / 데이터베이스목록 현황평가 - 장비 / 소프트웨어목록 - 조직및관리관행 - 현황평가 / 분석서정보기술 - 정보기술전략보고서전략수립 - 정보기술구축요소기술 정보시스 - 데이터 / 응용시스템구조템구조 - 기술구조정의 - 조직구조 - 프로젝트목적정의 - 범위및접근방법정의 - 프로젝트팀편성 - 프로젝트일정및자원계획수립 - 경영전략검토 - 외부환경 ( 산업환경, 경쟁자 ) 분석 - 내부환경 ( 업무프로세스및조직구조 ) 분석 - 조직의정보화목적수립 - 현행데이터및응용시스템파악 - 현행정보기술및자원분석 - 현행정보서비스조직및관리관행분석 - 현황평가를통한문제점의식별및사용자요구사항의수집 - 정보기술동향분석 - 정보시스템구축전략도출 - 정보시스템구축요소기술정의 - 데이터및응용시스템구조개발 - 기술구조개발 - 조직구조의개발 - 데이터및응용시스템구축계획수 - 데이터및응용시스템립정보화구축계획 - 시스템구조구축계획작성실행계획 - 시스템구조구축계획 - 조직계획작성수립 - 조직계획 - 이행계획작성 - 이행, 실행계획 - 실행계획수립 최근정보화전략계획수립과유사한개념으로엔터프라이즈아키텍처가있는데, 이를 조직의목표, 그목표를달성하기위해필요한정보, 그목표를수행하는데필요한기술, 변화하는기업목표에대응하기위해필요한새로운기술의구현으로전환하는과정등을정의해둔전략적 19

35 내용물 이라고정의한다. 엔터프라이즈아키텍처의구성요소는 [ 그림 3-4] 에서와같이크게네가지로구분한다. 첫째, 비즈니스아키텍처는조직의미션, 비전, 목표를달성하기위한업무를파악하고표현한다. 둘째, 정보아키텍처는업무절차에서활용되는정보및데이터를분석하고어떠한정보가어느곳에서필요한지를표현한다. 셋째, 어플리케이션아키텍처는업무절차를지원하기위한정보를파악하고관리하는활동을표현한다. 마지막으로기술아키텍처는정보기술의특성및가용성과하드웨어, 소프트웨어, 네트워크등의구성요소를표현한다. [ 그림 3-4] 엔터프라이즈아키텍처의구성요소 특히기술아키텍처는업무시스템과데이터저장소요건, 정보기술의업무에대한영향, 기술환경의수준, 정책, 추세분석등을토대로업무시스템체계를지원할수있는새로운기술환경즉, 하드웨어, 소프트웨어, 네트워크구성요소들의구성방안을표현한다. 기술아키텍처는성능수준을달성하기위한핵심구성요소중의하나이기때문에정보아키텍처와어플리케이션아키텍처에서서비스수준, 볼륨 ( 평균과최대 ), 증가율, 시점제약등을파악하여야한다. 엔터프라이즈아키텍처와정보화전략계획수립의내용들을살펴보면 기술구조혹은기술아키텍처는데이터구조, 응용시스템구조를토대로 작성된다는것이다. 즉, 기술구조는데이터구조와응용시스템구조를 20

36 수용하기위한것이다. 기술구조는 S/W, N/W, H/W 구성요소를정의하기때문에 H/W 용량산정을위해서는이를결정하는데이터구조및응용시스템구조에대한내용을참조하여야한다. OLTP용 H/W 중 CPU 용량산정항목과관련되는정보화전략계획의산출물을관련지어보면 [ 표 3-2] 와같다. [ 표3-2] 를살펴보면대부분의용량산정항목값들이정보화전략계획수립시산출될수있다고판단된다. 그러나시스템의안정된운영을위한여유율보정항목은어느단계에서찾아야하는지알기어렵다. Peak Time 보정값도조직의사용자업무와사용하는응용업무및데이터등을모두고려하여야산출할수있는것으로보여진다. [ 표 3-2] CPU 용량산정항목과연관된 ISP 산출물 항목입력값범위값의차이정보화전략계획산출물 동시사용자수 조직구조 트랜잭션처리수 3~7 4 조직및응용구조 기본 TPMC보정 20%~30% 10% 데이터및응용구조 Peak Time보정 20%~30% 10% 조직및데이터, 응용구조 ( 복잡 ) 데이터베이스크기보정 20%~30% 10% 데이터구조 어플리케이션복잡도보 정 10%~20% 10% 응용구조 사용자복잡성보정 1~ 조직구조 어플리케이션구조보정 1~ 응용구조 어플리케이션부하보정 1~ 데이터및응용구조 네트워크보정 10% 10% 기술구조 클러스터보정 30%~50% 20% 기술구조 여유율보정 20%~50% 30% 특별히값의차이가크다고생각되는동시사용자수, 트랜잭션처리수, 21

37 사용자복잡성보정, 어플리케이션부하보정, 여유율보정항목에주의를기울여야할것으로보여진다. 왜냐하면, 상기항목들의값에따라그결과값이크게달라질수있기때문이다. 따라서, 주관적판단이아닌객관적인자료들을근거로항목값을구하도록해야한다. 그렇게하기위해서는정보화전략계획수립결과물에용량산정항목과관련된객관적인자료들을최대한포함되도록해야한다. 용량산정항목과관련된자료들이수집되도록하고, 자료들을지표화하는산정방법을찾아내는정보화전략계획수립과 H/W 용량식에대한연구가필요하다. 3. 성능평가에따른 H/W 용량산정식연구 H/W 용량을산정할때부터즉, 계획할때부터, 목표로하는컴퓨터시스템의성능지수를정의하고그에따른성능요구사항을명확히하여야한다. 이를토대로 H/W의용량이산정되어야한다. 또한운영중원하는성능이충족되는지측정하여야하는데시스템을구성하는자원들간에상호영향을미쳐성능에영향을줄수있다. 따라서, 영향을미치는자원들간의상관관계분석과성능을측정하는방법론과필요한도구들에대한연구가필요하다. 그리고, 구축된목표개발시스템과도입된 H/W 시스템의조건에따라성능평가결과가다르게나올수있기때문에성능평가조건의적정성에대한연구도필요하다. 아래에서는상기한내용들을각각설명한다. 3.1 컴퓨터시스템성능지수정의 일반적으로한컴퓨터시스템이다른컴퓨터시스템보다빠르다고할때의의미는무엇일까? 컴퓨터사용자는프로그램수행시간이다른컴퓨터에비해서적게걸릴때빠른컴퓨터라고말한다. 반면에컴퓨터센터관리자는한시간에더많은작업을수행했을때다른컴퓨터보다빠르다고말한다. 즉, 컴퓨터사용자는응답시간 ( 또는수행시간, 경과시간으로불린다 ) 의감소에관심이있는반면에, 컴퓨터센터관리자는 22

38 처리량을증가시키는데관심이있다. 일반적으로사용되는성능지수를 정의하고설명하면다음과같다. 1) 응답시간 응답시간에는태스크를완전히끝내기위한디스크접근, 메모리접근, 입출력활동, 운영체제오버헤드등모든것이다포함된다. 또한, 사용자요구시간과시스템응답사이의시간간격을의미하며 [ 그림 3-5] 에서보는바와같이두가지의정의가가능하다. 즉, 사용자요구가끝난시간에서부터시스템이응답을시작한시간까지 ( 정의 1) 또는시스템이응답을완료한시간까지 ( 정의 2) 로정의한다. 응답시간과관련된성능지수로배치시스템에서는배치작업이시스템에들어가서출력이완료될때까지의시간을나타내는회수시간 (turnaround time ) 이있다. [ 그림 3-5] 응답시간의정의 사용자요구시간과이에대한시스템의실행시작시간사이를나타내는반응시간 (reaction time) 이있다. 예를들면, 시분할시스템에서사용자의마지막키입력과첫번째할당받은유저프로세스수행사이의간격이반응시간이된다. 2) 처리량 23

39 처리량은시스템이단위시간당처리할수있는작업량이다. 처리량은시스템관리자가관심을갖는사항이다. 업무종류에따라처리요소의예를보면아래 [ 표 3-3] 과같다. [ 표3-3] 업무에따른처리량 업무종류 배치처리 대화식시스템 CPU 네트워크 트랜잭션프로세싱시스템 사용자성능율 처리량 초당처리한 job 개수 초당요구갯수 MlPS, MFLOPS 초당패킷수 (packets per second) 초당비트수 (bits per second) tps (transaction per second) 사전에정의된사용자당작업부하처리율 3) 자원이용율 자원이용율은시스템이사용자의작업을처리하면서주어진자원이이용된시간이다. 즉, 전체시간대비주어진자원이이용된시간비를나타낸다. 자원이사용되지않은시간을유휴시간 (idle time) 이라한다. 프로세서와같은자원은항상이용되든가아니면유휴상태이므로프로세서자원이용율은의미가있다. 하지만메모리와같은자원은주어진시간에단지일부만이사용되므로, 메모리이용율은일정시간동안에사용된평균값으로측정된다. 자원이용율은시스템관리자가관심을가지고살펴보아야하는사항이다. 작업부하가균형을이루어모든자원이균등하게이용되도록주의를기울여야한다. 4) 신뢰성 신뢰성은오류가일어날확률로서에러확률이나에러사이의 평균시간으로나타낸다. 24

40 5) 가용성 가용성은사용자들의요구를서비스하는데시스템이이용가능한시간비를의미한다. 시스템이가용하지않은시간을고장시간 (downtime) 이라하고시스템이가용한시간을가동시간 (uptime) 이라한다. 평균가동시간은통상 MTTF (Mean Time To Failure, 평균수명 ) 로더잘알려져있다. 3.2 성능요구사항 성능분석자가당면하는문제는시스템에요구되는성능요구사항을 작성하는일이있다. 아래의예는성능요구사항을작성하는전형적인 문장이다. 시스템은프로세싱과메모리효율이좋아야한다. 신속한대민업무를위하여온라인서비스가요구된다. 데이터의일관성및무결성을보장하는 DBMS 이어야한다. 부서간효율적인정보교환및공동활용을위한강력한통신기능및접속기능이요구된다. 신속한정책결정을위한자료처리로일괄처리기능이필요하다. 이러한성능요구사항은다음과같은문제를한가지이상가지고있다. 1 불명확성 : 명백한숫자가기술되지않았다. 낮고, 높고, 드물고, 극단적으로작고등과같은정성적인단어가사용되었다. 2 측정의어려움 : 요구사항을만족시키는지, 시스템을측정하고검증할방법이없다. 3 정량화의어려움 : 요구사항이숫자로기술되었다면받아들일수있는수준으로작성되어야한다. 요구사항을정량화하려는시도가, 너무나비현실적으로작성되어받아들일수없는경우가있다. 25

41 4 실현의어려움 : 요구사항이너무높게책정되어달성가능성이없는 경우가발생된다. 5 완벽하지않음 : 모든가능한결과를기술하지않았다. 3.3 성능에영향을미치는시스템자원 정보시스템의성능에영향을주는요소는컴퓨터시스템의하드웨어, 운영체제및시스템파라미터, 데이터베이스관리시스템 (DBMS), 응용 프로그램, 그리고운영환경으로볼수있다. 응용프로그램 DBMS 운영환경 운영체제및시스템파라미터 하드웨어 [ 그림 3-6] 성능에영향을미치는시스템자원 정보시스템에과부하현상이발생하면이러한성능영향요소중어느부분에문제가있는지를분석하여시스템의성능을개선시켜야한다. 데이터베이스내의정보를검색하거나데이터베이스에정보를저장하는데있어서편리하고도효율적인환경을제공하는 DBMS 의성능에따라정보시스템의성능도좌우될수있다. 디스크배열, 시스템구조등의운영환경에따라서도성능이좌우될수있다. 성능분석을통하여시스템의병목지점이 CPU, 메모리, 또는입출력처리기인지를확인하여조치를취해야한다. 동일한하드웨어또는소프트웨어를이용하여정보시스템을서비스하면서도시스템파라미터조정, 하드웨어의구성조정, 또는응용프로그램운영환경조정을통하여 26

42 성능부하를상당히경감할수있다. 이렇게성능에관계되는여러가지요소를조정하는것을시스템튜닝이라한다. 시스템튜닝은컴퓨터시스템에과부하현상이발생하여처리속도가떨어지거나응답시간이늦어질때보통수행하게된다. 이러한시스템튜닝을하기위해서는운영하고있는시스템의운영체계에대한전반적인지식이필요하며, 여러가지유틸리티를이용하여시스템을감시 (Monitoring) 하고분석하는방법을알아야한다. 3.4 성능관리방법론과도구의필요 OLTP 정보시스템환경에서는성능향상을위하여일반적으로데이터베이스에서성능저하를유발하는문제점을확인하고, 문제에대한원인분석을통해개선방안을도출하고튜닝한다. 인터넷을기반으로하는웹환경에서도어플리케이션성능문제의대부분은데이터베이스성능에기인한다는것은사실이지만, 이제어플리케이션성능에서데이터베이스성능이차지하는중요도가이전처럼절대적이던시대는지나가고있다. 향후에는데이터베이스성능은양호한반면, J2EE 와같은웹어플리케이션정보시스템환경이어플리케이션성능의주류를이룰것이다. 따라서향후성능관리는서버시스템자원, 프로그램, 데이터베이스, 네트워크등과같은다양한자원사용현황을연계해어플리케이션서비스에대한엔드-투-엔드관리를하나로통합된관계로관리할수있는체계로구축되어야한다. 이에따라성능관리분야도데이터베이스에전적으로의존하던과거와는달리, 어플리케이션튜닝및 IT 자원전체를아우르는전산자원튜닝으로발전해야할것이다. 그러나, 구체적으로아래와같은문제가발생하면그원인과적절한대안을제시하기가쉽지않기때문에체계적인방법론과도구가필요하다. 저성능의원인이무엇인가? 느린원인이데스크탑 PC, 네트워크, CPU, 어플리케이션, 입출력, DBMS 때문인가? 27

43 응답시간을최대한향상시키기위해무엇을변경해야하는가? 더넓은대역폭인가? 어플리케이션튜닝을해야한가? 더많은 CPU 가필요한가? 어떤어플리케이션의기능, 데이터베이스질의가성능문제를일으키는가? 네트웍지연의근본원인이무엇인가? 정보시스템과데이터베이스의규모와복잡성이확대될수록인간이할수있는한계성때문에효과적인방법론과도구는성능관리를위해필수적으로필요하다. 도구의선정에있어서전체사용자가사용하는트랜잭션을연관성있게분석하기위한툴의통합과정및정교한분석을제공하는솔루션을선택하는것이중요하며, 이보다더욱중요한것은기술지원능력을보유한업체선정이다. 3.5 성능평가조건의적정성 성능을평가하기위해서는성능평가조건이타당한지목표개발시스템과 H/W 시스템간의상황도살펴보아야한다. [ 표 3-4] 는가로축에목표시스템이적정하게구축되었는가, 혹은적게구축되었는가, 많이구축되었는가로구분하고, 세로축은도입한 H/W 시스템이적정한지, 큰지, 적은지를구분하여성능을판정한성능평가조건매트릭스이다. 성능평가조건매트릭스의성능유형을살펴보면적정한성능, 높은성능, 낮은성능, 판단불가의네가지가있다. 적정한성능이되도록목표시스템을구축하고이에적정한 H/W 시스템이도입되면좋으나다른결과를보이면그원인을파악해야한다. 일반적으로목표개발시스템은적정하게구축되었다고가정하고성능의결과에따라 H/W 시스템이적절한지를판단한다. 그러나, 반대로도입된 H/W 시스템은적정하나목표개발시스템이적정하지않아서다른결과가나올수도있다. 높은성능을보인경우를예를들어살펴보자. 목표 28

44 시스템은적정하게개발되었으나, 높은사양의 H/W 시스템이도입된경우는 H/W 용량산정관련자의잘못된계산일수있다. 그러나, H/W 시스템은적정하게도입되었으나, 목표시스템이적게개발되어높은성능을보일수있다. 이때는개발업체의잘못일수있다. 마찬가지로낮은성능을보일경우에도그원인을분석해야할것이다. 이때목표개발시스템과도입된 H/W 시스템의적정, 대, 소를구분하고판단할수있는기준도마련하여야한다. [ 표 3-4] 성능평가조건매트릭스 4. 지식 / 정보데이터베이스화시스템구축 어떤기관이나회사에서도정보시스템구축과관련하여 H/W의적정용량을산정하는것은결코쉬운일이아니다. 적정용량의 H/W를선정하는원칙이있다고하더라도업종별로회사별로그결과는다다르다. 아무리큰규모의장비를도입했다하더라도개발된어플리케이션의문제로성능이나오지않을수도있고튜닝을해야할상황도발생한다. 따라서적정용량을산정하기위한참고, 혹은근거자료들이매우필요하다. 이를위해서는동종업계의유사규모사이트에서실제로운영되는시스템의용량들을파악한자료들이필요하다. 이자료들이축적되면유사사업에서의시스템규모를판단하고업종별로분석하여관련자들을설득할수있는 29

45 객관적인정보로이용될수있다. 따라서, 경영환경변화와급속한기술발전으로인한시스템의노후화를 고려하여각시스템에대한아래와같은자료를 3 년치정도를수집하여 저장하도록한다. 정보화전략계획수립자료 1, 2, 3차년도의시스템개발계획포함 년차별응용시스템개발계획및각시스템별조직인원, 사용자현황 년차별응용시스템개발계획및업무량증가율근거와가정 년차별데이터베이스개발계획 정보화전략계획자료에근거한년차별성능예상치 ( 구축완료시점, 1년후, 2년후, 3년후 ) 업무특성에따른월별, 요일별, 일별, 시간대별업무폭주시예상치 용량산정을위한기초자료 OLTP대 Batch의업무비율 Peak시시간당트랜잭션건수 각항목의계수에대한근거자료 용량산정도출과정 H/W기종에대한 TPC, SPEC의테스트결과물 도입한시스템의사양근거 ( 응용시스템, 데이터베이스, 네트워크, 업무의특성과이를반영한시스템아키텍처 ) 성능평가의자료 계수화된성능요구사항 monitoring tool을사용한성능치 도입된시스템사양 업무량증가와년차별신규업무증가등을고려한 H/W 30

46 upgrade(cpu 및메모리, i/o board) 실적등 상기자료외에도앞서서연구된 H/W 용량산정과관련된내용을포함하여야한다. 또한축적된자료를참고자료로활용할수있도록하며, 시스템도입계획과성능평가결과간의차이분석을하며, 그원인과결과를항목및계수화조정작업에반영할수있는시스템개발이필요하다. 5. 제도정비연구 정부에서지원하고있는정보화지원사업의경위와기관들의역할, 사업관리방법을먼저설명한후 H/W 용량산정과관련된제도정비연구방향을제시하고자한다. 1995년 8월정부는국가사회정보화를체계적으로추진하기위해정보화추진체계등에관한사항을규정한정보화촉진기본법을제정하여 1996년 1월부터시행하였고, 이법률에따라 1996년 4월에국가사회정보화촉진을위한기본계획과주요사업등을종합조정하는최상위기구로서정보화추진위원회를발족시켰다. 정보통신부는국가전반의정보화를촉진하고정보통신기반의원활한구축과이용촉진을위하여국가기관, 지방자치단체, 기타공공기관이추진하는정보화사업을지원하고있다. 지원대상사업은정보화촉진사업, 지역정보화지원사업, 선도응용시범사업등으로다양화된사업형태를갖추고있다. 이러한정보화지원사업은 1994년부터 2002년까지각부문의정보화사업에 3,446억원을투입하여 328개과제의개발을지원해왔다. 앞으로의정보화촉진사업의추진방향은인터넷보급 확산등양적확충단계를넘어서국가사회전반의제도개선과업무방식의혁신을통해생산성제고등성과중심의정보화를추진해나갈계획이다. 이는지속적으로많은과제발굴과정보시스템개발을위한예산을지원해야함을의미하고있는것이다 년정보화추진위원회에서 정보화평가계획 이확정되면서 정보화부문에대한평가가시행되기시작하였다 년도에는그간의 31

47 경험과환경의변화를감안하여 국가정보화평가계획 이새로이수립되어정보화추진위원회에서심의, 확정됨으로써이새로운평가계획에의거하여현재평가가시행되고있다. 이계획에의하면, 소요자금이크거나사회경제적파급효과가큰사업에대해서는 중점평가 대상사업으로선정하여평가하도록하였다. 평가를시행하는데있어그평가기준과평가항목등을포함한전반적인평가에대한지침서로는정보통신부에서발간한 정보화사업평가편람 을활용하고있다. 평가편람에서제시하고있는평가의기준과항목은크게효과성평가와집행평가로구분되는데 H/W 용량산정프레임워크와일부관계가있을것으로판단된다. 정보화촉진기본법제11조, 제27조및동법시행규칙제5조에의하여정보통신부가시행하는정보화지원사업의원활한수행과효율적관리를위해필요한세부사항을정보화지원사업관리요령및지침에정하고있으며, 정보화촉진기본법제10조에의해설립된한국전산원은정보화관련정책을개발하여정보화촉진기본계획및시행계획의수립 시행을지원하고, 공공기관의정보자원관리와정보화사업에대한평가 감리업무를수행하고관련제도의운영을뒷받침하고있다. 정부에서지원하고있는정보화사업이보다효율적으로추진되기위해서는본 H/W 용량산정과관련된용량산정식도출, 정보화전략계획수립, 성능평가, 지식 / 정보 DB화연구에서도출된결과를정보화지원사업관리요령및지침에서요구하고있는과제신청서, 사업계획서, 제안요청서, 제안서작성지침, 계약서, 완료보고서에반영하고수정해야한다. 즉, H/W 용량산정과관련된항목및내용을관련자료및보고서에추가하거나보완해야한다. 예를들면 H/W 용량산정과관련된항목및내용이분석, 설계, 구현, 설치, 시험등각단계별산출물의어느곳에어떻게반영되고표현되어야하는지를연구하여야한다. 또한반영할수있는체제를마련하여야한다. 특히 H/W 용량산정의고도화를위한지식 / 정보화 DB 화시스템구축과 관련하여정보화지원사업의추진과관리를하는한국전산원의역할, 정보화 32

48 지원사업대상과제를주관하여수행하는주관기관, 정보화과제를통해구축될시스템을운영하는운영기관, 정보화과제의수행을위한시스템구축및서비스개발을책임지고수행하는법인인시스템공급자들의역할이정의되어야하며, 정보화지원사업관리요령및지침에어떻게반영할것인가를연구하여야한다. 33

49 제 4 장 H/W 용량산정개념및현황 제 1 절용량산정개요 1. 용량산정개념 용량계획 (Capacity planning) 과시스템규모산정혹은용량산정이라는용어가혼용되어사용되고있다. 이들간에는어떠한차이가있을까? 여기에서용량계획과시스템규모산정그리고용량산정에대한개념을정의한다. 우선, 용량계획이라함은개략적인시스템아키텍처와응용업무를기반으로시스템에요구되는성능요구사항과성능을결정하기위한계획으로이해할수있다. 일반적으로이러한용량계획은다음과같은사항을다룬다. 클라이언트어플리케이션의형태 이들응용들에접근하는사용자의수 클라이언트어플리케이션의동작특성 서버시스템에대응하는오퍼레이션의형태 서버시스템에접속하는동시접속자의수 서버시스템에의해서수행되어져야하는피크율 피크타임하에서의여유율등 이에반해서기본적인용량과성능요구사항이제시되었을때, 그것을 시스템요구사항으로변환하는것을시스템규모산정이라고부른다. 일반적으로이러한시스템규모산정시에결정하는요소는다음과같다. 서버컴퓨터의 CPU 의형태나수 34

50 서버컴퓨터의디스크서브시스템의크기나형태 서버컴퓨터의메모리크기이를정리하면용량계획과시스템규모산정은다음표와같이정의할수있다. [ 표 4-1] 용량계획과시스템규모산정의정의 구분정의비고 용량계획 (Capacity planning) 시스템의아키텍처와응용기반을전제로용량요구사항과성능을결정하는것으로구성할시스템의용량산정을위한계획 시스템규모산정 (System Sizing) 실제업무와응용을기반으로수학적인방법론을사용하여도입하고자하는시스템의용량을계산하는것 위의정의에서보듯이시스템규모산정은실제업무와응용을기반으로수학적인방법론을사용하여도입하고자하는시스템의용량을계산하는것으로시스템의아키텍처와응용기반을전제로용량요구사항과성능을결정하는용량계획과차이가있으며일반적으로사용하는용량산정의경우, 용량계획보다는시스템규모산정을의미하므로본연구에서는용량산정과시스템규모산정을동일한의미로사용한다. 2. 용량산정절차 공공부문정보화사업에있어서시스템규모산정은첫째, 공공기관에서정보화사업을입안, 예산을요청하는시점, 그리고배정된예산을토대로사업발주를하는시점에주로이루어진다. 이두가지경우에있어서정확한용량산정을위해서는사전에충분한용량계획이수립되어야한다. 그러나정보화사업의실행전에전반적인사업에대한정보화전략계획 (ISP) 이수립되어져있어야하겠지만대부분의정보화사업이그렇지않은현실이다. 35

51 한편용량산정의기본적인절차는용량데이터의수집, 규모산정그리고 검토단계등으로구성되며세부적인내용은아래그림과같다. [ 그림 4-1] 용량산정절차및내용 위그림에서용량산정의범위는앞에서정의한바와같이규모산정단계에해당한다. 즉, 규모산정의전제조건을설정하고규모의유형을결정하며, 보정계수를결정하며산정식에따라규모를산정하는것이다. 그러나앞서언급한바와같이정보화전략계획을전제로하지않은용량산정결과의정확성을높이기위해서규모산정이전의수립단계인용량데이터의수집단계를포함하여본연구에서는용량산정의범위로규정한다. 36

52 제 2 절용량산정현황및사례 1. 국내 H/W 용량산정현황 정보화시대의도래에따라사회적으로정보인프라구축에대한관심이고조되고있으며, 효율적인업무처리, 고객서비스개선등을위해다양한정보시스템이구축되고있다. 공공기관의정보시스템에대한성능개선과도입을위한명확한규모산정기준이없어서정보시스템구축을추진하는기관혹은시스템공급자의주관적방법에따라정보시스템의자원규모를산정하고있다. 이로인하여규모의과다혹은축소산정등의문제가발생하고있으며, 정보화예산의낭비와서비스저하라는지적이빈번히발생하고있다. 공공기관의정보인프라의도입과관련한이러한논쟁의주요대상은정보시스템의 CPU산정과관련된부분이다. 이는메모리나디스크와같은기억장치는 H/W 기술발전에따라전체시스템도입비용에서차지하는비중이작아지고있는추세이며, CPU에비해산정방식이객관화될수있으므로상대적으로논란이덜한편이다. 그러나 CPU의경우용량산정을위한산정방식과 CPU의성능을평가하기위한기준이일원화되어있지않으며, CPU의처리능력에따라서버장비의가격이많은차이를갖게되기때문이다. 한편, 공공기관들은국내의정보시스템의 CPU용량산정시국제적인공신력을갖고있으며, 하드웨어및소프트웨어의트랜잭션처리능력을평가하는기관인 TPC의 tpmc를사용하고있는추세이다. 이러한주요원인은공공기관의사용자들의성향에기인한것으로대부분이 tpmc에친숙함에따라 H/W를발주하는시점에서내부적인용량산정을통해서제안하는 H/W의용량은 tpmc를기반으로하고있다. 그러나 tpmc를기반으로한 H/W용량산정및성능평가에는많은논란을일으키고있다. 그이유는다음과같다. 37

53 첫째, CPU의용량을산정하기위한산정기준의상이함이다. [ 표 4-2] 에서제시한바와같이 CPU 용량산정을위한 H/W벤더혹은 SI업체의산정항목이나지표혹은보정치가상이하다는점이다. 특히, 지표나보정치의경우용량산정을수행하는시스템설계자의경험에따라부여하는값이달라질수있으며, 동일한시스템환경에대해서많은차이를보일수있다. [ 표 4-2] CPU 산정기준비교 기준치구분항목 NCA A사 B사 1 동시사용자수반영반영반영 2 분당트랜잭션수반영반영 3 기본TPC 1.2( 소규모 )~ 1.3( 대규모 ) 고려하지않음 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.5 고려하지않음 11 클러스터보정 1.2( 단순 ) ~ 1.5( 복잡 ) 1.3 ~ 2 12 여유율 1.2 ~ ~ 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 성능평가를위해서는막대한비용이지출되기때문이다. 즉비용및기타 38

54 문제로인하여모든장비라인업에대하여 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, 메모리, 디스크의용 량산정방식은다음과같다. 39

55 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 용량산정과관련한다른자료와차이나는부분이적지않다. 따라서용량산정항목들이공공부문정보화 40

56 사업과관련하여적정한가검토하여산정항목과지표를보다객관화하고, Web기반시스템과관련하여 TPC-C를적용하는것은적정하지않으므로 Web 혹은 WAS의용량산정에 TPC-W, SPECWeb 등의적용방안을마련할필요가있다. 금번연구에서는기존연구의문제점을보완하고공공부문정보화사업의 H/W 용량산정시실질적인지침으로활용될수있도록용량산정식고도화와관련하여용량산정항목및적용값에대한적정성을검증하고, 적용사례를통한적용값의범위를객관화하고, 정확한값이도출되도록한다. 그리고정보기술환경변화에따른 Web 환경에대한 H/W 용량산정의정확성을확보하는차원에서 Web/WAS에대한용량산정방식을아울러제안하고자한다. 41

57 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 42

58 의비율 50% 을사용한다. 웹서버를위한세부산정식은다음과같다 웹서버용량산정 = 동시사용자 * 100/SPECweb96 Class 1,2,3 비율 * 평 균세션수 * 네트워크보정 * Peak Time 보정 * 시스템여유율 다음은웹서버를위한세부산정식을적용하여실제산정과정을보이고있다. 산정결과, 웹서버의프로세스는약 1,927ops의성능을요구하고있다. [ 표 4-3] 웹서버의 CPU 산정근거 구분산정근거산정내역 동시사용자수 * ( 매3년사용자동시증가율 (30%))* Web 사용자비사용자율 (60%) * SPECweb96 Class 비율 250 * (1.3 * 1.3 * 1.3) * 0.6 * 1.5 = 329 * 1.5 = 494 명 Ops/ Sec 동시사용자수 * 세션수 (3)/ 명 * 여유율 (30%) 494 * 3 * 1.3 = 1,927 Ops/Sec - DB 서버 : DB 서버의경우, OLTP 를위한성능지표인 TPC 의 TPC-C 를적용하였으며, 세부적인산정식은다음과같다. DB Server 용량산정 = 트랜잭션처리수 * 최번시간트랜잭션 * 트 랜잭션복잡도 * 네트워크보정율 * Peak Time 보정율 * 시스템부하 율 * 시스템여유율 * 트랜잭션증가율 위의세부산정식을적용하여실제산정과정을보이고있으며, 산정 결과 DB 서버의프로세스는약 6,088 tmpc 의성능을요구하고있 다. 43

59 [ 표 4-4] DB 서버의 CPU 산정근거 구분산정근거산정내역 일트랜잭션처리수 사용자수 * 개인입력건수 / 일 *( 매3년사용자 증가 보정율 (30%)) 1,500 * 3 *(1.3 * 1.3 * 1.3 )=9,887 건 / 일 일일업무집중시간 트랜잭션복잡도 응답시간보정 Peak 시보정율 일일처리량의 70% 을 4 시간사이처리가정분당트랜잭션 TPC 와트랜잭션복잡성차이 (1.5 배 ) LAN/WAN 을통한클라이언트응답시간보정 (1.5 배 ) Peak Time 시이를위한 6 배의보정율적용 9,887 * 0.7 /4 / 60 = 29 건 /Min 29 * 1.5 = 44 건 /Min 44 * 1.5 = 66 건 /Min 66 * 6 = 396 건 /Min 시스템부하율 OS(50%), 기타시스템소프트웨어 (SQL Server 40%, Vaccine 40%) I/O 부하율입 / 출력을위한부하율 70% 396 * 1.5 * 1.4 * 1.4 = 1,164 건 /Min 1,164 * 1.7 = 1,979 건 /Min 시스템여유율 트랜잭션증가율 40% 정도의시스템여유율적용 3년간 트랜잭션 증가율 적용 (30%) 1,979 * 1.4 = 2,771 건 /Min 2,771 * 1.3 * 1.3 * 1.3 = 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% 로가정 44

60 - 웹서버 : 웹서버의메모리용량산정을위해서산정항목은 OS 사용량 과어플리케이션영역과시스템여유율을사용하였으며세부적인산정 식은다음과같다. 웹서버메모리의용량산정 = OS 사용량 + 어플리케이션영역 + 시 스템여유율 위의식을적용하여산출한결과웹서버메모리총용량은약 958MB 정도를요구하는것으로산출되었으며세부적인산정내용은다음과같 다. [ 표 4-5] 웹서버의메모리산정근거 구분산정근거산정내역 동시 사용자 동시사용자 * 증가보정율 (30%) * 3 년 250 * 1.3 * 1.3 * 1.3 = 549 명 OS 용량 Web 서버 용량 Windows NT Kernel ( 기본 OS+ 서비 64MB + 64MB + (549 * 스 ) + 기타유틸리티 (RAID 포함 ) + ( 동 50KB * 0.4) = 시사용자 / 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 서버용량 + Transaction 서버용량 ) 의 20% ( ) * 0.2 = 160MB - DB 서버 : DB 서버의메모리용량산정을위해서산정항목은 OS 사용 량과 DBMS 영역과시스템여유율을사용하였으며세부적인산정식은 다음과같다. DB 서버메모리의용량산정 = OS 사용량 + DBMS 영역 + 시스템여유율 45

61 위의식을적용하여산출한결과 DB 서버메모리총용량은약 825MB 정도를요구하는것으로산출되었으며세부적인산정내용은 다음과같다. [ 표 4-6] DB서버의메모리산정근거구분산정근거산정내역 동시사용자 OS 용량 DB 용량 동시사용자 * 증가보정율 250 * 1.3 * 1.3 * 1.3 = 549명 (30%) * 3년 Windows NT Kernel ( 기본 OS+ 서비스 ) + 기타유틸리티 (RAID 64MB + 64MB = 128MB 포함 ) SQL Server Database 서비스 (5,490 * 0.05) + (549 * 데이터와인덱스량의 5% 부하 50KB) = = 559MB 량 + 동시사용자 시스템여유율 (OS 영역 + DB 영역 ) 의 20% ( ) * 0.2 = 138MB 디스크부문 디스크의용량산정은시스템디스크부문과데이터를위한데이터디스크로나누어산정방식을달리한다. 제시한구조에서의웹서버에대해서는시스템디스크용량만산정하며, DB서버의경우는시스템디스크와데이터디스크를산정하고있다. 세부적인산정식은다음과같다. DB 시스템디스크 = OS 사용량 + DBMS 사용량 + 어플리케이션사용량 + SWAP 사용량 + 시스템여유율 데이터디스크 = 총데이터량 + 데이터증가율 + RAID 적용율 + 여유율 - 웹서버 : 위의식에따라웹서버의시스템디스크산정결과필요용량은 약 8.4GB 정도이며세부적인산정내용은다음과같다. 46

62 [ 표 4-7] 웹서버의시스템디스크산정근거 구분산정근거산정내역 시스템 S/W 사용량 Windows NT + 어플리케이션 ( 응용프로그램 ) 500MB + 1GB = 1.5GB SWAP 공간서버메모리의 2 배적용 2048MB * 2 = 4,096MB 여유율성능향상위한공간 50% (1, ,096) * 0.5 = 2,798MB - DB 서버 : DB 서버의시스템디스크산정결과필요용량은약 5.4GB 정 도로산정되었으며세부적인산정내용은다음과같다. [ 표 4-8] DB 서버의시스템디스크산정근거 구분산정근거산정내역 시스템 S/W 사용량 Windows NT + DBMS( 데이터 0.5GB + 1GB = 1.5GB 베이스관리도구를포함 ) SWAP 공간서버메모리의 2 배적용 1024 * 2 = 2,048MB 여유율성능향상위한공간 50% (1, ,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 * ,490 = 증가분 RAID 5 적용 3.2 배 + 기존데이터 데이터디스크의 20% (Parity 영역 ) 7, ,490 = 13GB 13 * 1.2 = 15.6GB 여유율 성능향상을위한여유공간 40% 15.6 * 1.4 = 21.84GB 47

63 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 아키텍처 48

64 WAS(web application server) 용량산정 WAS는 J2EE기반의어플리케이션을운영한다고가정하였으며, CPU 산정기준은 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 의벤치마킹결과를 토대로용량을산정하는데, 이러한용량산정은일반적으로용량산정식을 49

65 적용하고있지는않다. 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% 로가정한다면다음과같은용량산정결과를보여준다. 50

66 [ 그림 4-4] HVWS 의패턴다이어그램 [ 그림 4-5] HVWS 의결과치 51

67 [ 그림 4-5] HVWS 의결과치 ( 계속 ) 위의용량산정추정치는초당방문자수 30 명, 동시사용자수 70 명일경우를기준으로 CPU 사용율을 50% 를계속유지한다고가정했을때의시스템의성능및상태를나타낸수치이다. CPU 사용율의변화에따라초당방문자수및동시사용자수는감소또는증가하게된다. 최소응답시간항목은아주적은작업부하가걸리는상태에서초당방문자수도매우적을경우의시스템의응답시간을나타낸다. 52

68 제 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 참조정보 따라서본절에서는 TPC 와 SPEC 의성능평가기술을중심으로 살펴보고자한다. 53

69 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( 현금자동입출금기 ) 을 사용하고있는은행의입출금시스템이다. 54

70 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 의경우데이터량과트랜잭션종류를실업무환경에적용시키기가 55

71 어려워실제용량산정에적용하기는상당한어려움이따른다. 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 캐시들, 이미지서버들그리고데이터베이스서버등의다른기능을수행하는서버들로구성되어있다. 56

72 [ 그림 4-7] TPC-W 의시뮬레이션구성도 한편, 다른 TPC 벤치마크들과달리, TPC-W는다양한서버들에대한성능데이터를만들어내기위해서시험후원자를필요로한다. TPC-W의적용범위를밝혀냄으로써, 복잡한전자상거래환경에서각각의서버들이어떻게동작하는지에대한정보를얻을수있다. TPC-W의장점은시뮬레이트된전자상거래작업부하내에서특정전자상거래서버들의성능특성들을결정할수있다는것이다. 2. SPEC 성능기준 SPEC는 1988년 11월에설립된이래 HP, 썬마이크로시스템즈등주요시스템업체가컨소시엄형태로참여하고있으며시스템성능테스트에있어서권위를인정받고있다. SPEC의벤치마킹테스트중가장권위있는벤치마크테스트는 CPU 성능테스트이다 SPEC95 57

73 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 에서발전한것으로작업부하는여러회사의 홈페이지를서비스하는웹서비스제공자에접근하는경우를 58

74 시뮬레이션하는것으로각각의홈페이지는작은아이콘으로부터용량이큰문서나이미지등으로구성된다. 테스트에사용되는웹서버의개수에제한이없으며, DBMS를고려한테스트가아니며, 서버와클라이언트로구성되어있는단순한웹환경에서의테스트를위한것이다. 또한, LAN환경에서의테스트이고, WAN까지를고려한테스트가아니며, 서버가처리할수있는최대동시연결 (Connection) 수가결과이다. [ 그림 4-8] SPECweb96 의벤치마킹구성도 한편 SPEC 에서는 SPECWeb99 는시스템규모산정툴로디자인된것이 아니므로, 서버용량산정을위한목적으로는사용하지말것을권장하고 있다. 59

75 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와테스트를위해서사용한다. 소프트웨어벤더는해당회사의 60

76 JVMs, JIT, garbage collector, thread구현의효율성을테스트하기위한목적으로사용하여야함을권고하고있다. 한편, 이러한 SPECjbb2000 의단점으로는고객의실제환경에서는반드시고려되어야하는네트워크환경 (LAN 및 WAN 환경 ), 분산된데이터베이스환경, 메인프레임및다른시스템과의연동, 디스크 I/O 에대한고려, DBMS 와의연결등이누락되어있으며, 다음표에서와같이벤치마킹실시시점에따라성능치가달라진다는점이다. 이는성능평가의객관성에영향을미치는요소로 SPECjbb2000 성능평가의신뢰성을저하시킴에따라 H/W 벤더들에있어서의성능평가의논쟁거리로작용하고있다. [ 표 4-11] 시스템별성능치비교 구분 성능치 (http ops/sec) 발표일자 A 사 ( 서버동일사양, JAVA Version 및 PATCH 적용 ) 118, , , / / /08 B 사 ( 서버동일사양, JAVA PATCH 적용 ) 157, , / /01 61

77 제 4 절용량산정을위한참조아키텍처 현대적인정보시스템의아키텍처는그림과같이세개의계층으로구성되어있다. E-비즈니스와같은웹기반응용부문은 3-계층 (three-tier) 아키텍처로구성될수도있다. 프리젠테이션계층이라고도하는계층1은웹서비스와의사용자인터페이스를구현한다. 브라우저를이용한 HTML이나 XML 에대한해석을통해서웹사용자는데이터를입력하고, 데이터를편집하고정보를수신한다. 이동전화나 PDA와같은이동통신장치들에서웹서비스에접근할수있는새로운인터페이스를이용할수있다. 어플리케이션계층이라고도하는비즈니스로직계층은어플리케이션로직을구현하기위한규칙들을캡슐화한다. 프리젠테이션계층과데이터서비스로부터비즈니스로직의분리는어플리케이션에새로운수준의자율성을제공하여어플리케이션의건전성 (robustness) 를더욱강화한다. 웹기반어플리케이션의경우, 이러한중간계층도자바애플릿과 Active X컨트롤과같이브라우저에의해서표시되는컴포넌트들을갖고있다. 데이터서비스계층은신뢰성, 안정성, 가용성을보장하는메커니즘에의해서관리되는영속적데이터로구성되어있다. 데이터베이스서버와메인프레임은데이터계층의컴포넌트의예이다. 프리젠테이션비즈니스로직데이터서비스 사용자입력수집 표준인터페이스제공 비즈니스서비스접근제공 데이터처리규칙포함 어플리케이션비즈니스로직정의 비즈니스기능을비즈니스객체상의동작으로사상 데이터저장 데이터의오류와불일치방치 메임프레임데이터베이스접근제공 [ 그림 4-10] 계층별컴포넌트 62

78 분산형시스템에서, 미들웨어는클라이언트와서버사이의통합을가능하 게하는소프트웨어로간주된다. 인터넷에서사용되는미들웨어로는 HTTP, SSI, CORBA 가있다. DMZ 계층1 계층2 계층3 (2) (3) FW FW 인터넷 R FW (1) 로드밸런서 R FW 라우터 웹서버 어플리케이션데이터베이스 서버 서버 ( 메인프레임등 ) 방화벽 LAN1 LAN2 LAN3 LAN4 [ 그림 4-11] 일반적인다계층웹사이트아키텍처 웹사이트는기본적으로전체시스템아키텍처중에서어플리케이션계층과데이터계층을구현하는것을말한다. 다음그림은로드밸런서, 계층1의웹서버, 계층 2의어플리케이션서버, 계층3의데이터서버로구성된 3-계층 e-비즈니스사이트를보여준다. 이러한다양한요소들은 LAN, 라우터, 방화벽을통해서상호연결되어있다. 방화벽은패킷의네트워크간전송을방지하도록설정할수있는특수한종류의라우터이다. 이것은중요한내부 63

79 서버를외부의공격으로부터보호하는데중요한역할을한다. 다음그림의요청의흐름은다음과같다. 요청은사이트를인터넷에연결하는라우터를통해서로드밸런서에도착한다. 로드밸런서는어떤웹서버가그요청을수신해야하는지결정한다. 외부에서접근할수있는영역은 DMZ(demilitarized zone) 라고한다. 방화벽1은계층1의어떤웹서버도외부로부터차단된채오직로드밸런서로부터만요청을수신하게한다. 웹서버는요청을어플리케이션서버로송신한다. 방화벽2는웹서버에의해서만어플리케이션서버에접속하게한다. 마지막으로, 어플리케이션서버가데이터베이스서버에서데이터를가져와야하는경우, 그러한요청은방화벽3을통해서전송된다. 다계층아키텍처는확장성, 가용성, 보안성, 메인프레임에상주하는레거시데이터와의통합이라는이점을얻는것을목표로하고있다. 보안성은어플리케이션서버와데이터베이스에대한접근을위에서설명한바와같이웹서버에만한정하는방화벽을사용하여향상시킬수있다. 사용자에대한보완성도 SSL과 TLS와같은인증프로토콜을이용하여제공할수있다. 확장성과가용성은각계층에서다중서버를이용하여확보할수있다. 또한, 로드밸런싱메커니즘은전반적인성능향상에이용될수있다. 64

80 제 5 장 H/W 용량산정지침 제 1 절개요 1. 지침의필요성 정보화시대의도래에따라사회적으로정보인프라구축에대한관심이고조되고있으며, 효율적인업무처리, 고객서비스개선등을위해다양한정보시스템이구축되고있다. 이러한정보시스템은 H/W, S/W, 사람으로구성되며, 이중 H/W는공급업자혹은시스템구축자등에따라용량산정적용항목및적용비율을경험적으로적용하기때문에부정확한용량이산정되는경우가많이발생한다. 업무의성격, 업무증가율, 사용자사용빈도, 구축기술등을전체적으로고려하여 H/W용량을산정해야하므로, 시스템구축사업에서 H/W용량적정성의옳고그름을판단하는것은어려운일이다. 시스템구축사업에서 H/W가차지하는비중이전체프로젝트비용의적게는 50% 에서많게는 90% 을차지함에도불구하고, 그동안이부분은사업자나장비업체에의존적이고, 상대적으로소홀한분야로많은관심을갖지않았다. 이와같은이유로실제요구되는하드웨어의각구성요소가사업자나장비업체에의해과다또는과소산정되는경우가발생하여도마땅히개선할수있는방법이없었다. 따라서공공부문정보화사업에서의기획자 ( 공공기관 ), 구축자 (SI사업자및장비업체 ) 등이 H/W자원의도입을검토할경우참고할수있는 H/W 용량산정지침을작성하였다. 본지침은 TPC( 와 SPEC ( 의다양한업무유형별성능기준을토대로국내 SI기업 (SDS, LG-CNS, HIT) 및장비업체 (IBM, SUN, Fujitsu) 의 H/W 산정기준을참조하여전문가그룹의토의를거쳐확정하였으며, 시스템구축비용중가장중요한 CPU, 메모리, 디스크용량산정에대해소개하고자한다. 2. 지침의적용범위 65

81 본지침은공공부문정보화사업을대상으로사업기획시장비도입을위한대략적인소요예산의산출을위해서혹은 SI업체의 H/W 부문제안시의 H/W 규모산정을위한기준지침으로활용될수있다. 현행제시된지침은신규도입되는 H/W를전제로작성되었으며, 따라서기존시스템에대한용량확장을위한지침으로활용하는것은바람직하지않다. 한편, 신규도입시스템에적용되는경우, [ 그림 5-1] 에서와같이정보화사업의수행전반에대해서적용가능하며, 사업을기획 / 발주하는주관기관, 시스템공급자, 감리기관등에서본지침을활용하여용량을산정할수있다. 우선, 주관기관에서는정보화사업을입안하는시점과세부사업계획의수립시에 H/W 규모산정이반드시필요하므로이를적용할수있다. 또한, 개발사업자는제안서를작성하여 H/W를제안하는시점과실제시스템사업자로선정된개발과정중아키텍처설계시본지침을적용할수있다. 한편, 감리기관의경우, 필요시감리시점에 H/W 용량산정의적정성을검증하는차원에서본지침을참조할수있을것이다. 범례 ) [ 그림 5-1] 정보화사업추진단계및주체별적용범위 66

82 3. 용량산정의대상 본지침에서의용량산정대상이되는 H/W는 PC나기타주변장비가아닌메인프레임급서버를의미한다. 이러한하드웨어구성분야는여러가지가있지만시스템가격및성능측면에서가장중요한세분야를용량산정분야로정의한다. CPU : 해당업무를처리하기위한 CPU 용량을계산한후, 적정한성능을지닌서버기종을선정한다. 메모리 : CPU 용량산정에따른서버구성방안에의거하여, 서버별 시스템소프트웨어, 응용프로그램등의메모리사용량을산정한다. 디스크 : CPU 용량산정에따른서버구성방안에의거하여, 서버별 OS, 시스템소프트웨어, DB 의데이터, DB 의 Archive 및 백업영역등의디스크사용량을산정한다. 67

83 제 2 절용량산정절차 1. 용량산정시일반적고려사항 일반적으로시스템구성검토는업무분석이제대로이루어지지않은프로젝트초기에수행된다. 이때문에실제로작업부하를정확히예측하는것은불가능하다. 따라서필연적으로용량산정을위해서는다양한보정치를사용한다. 업무조사가많이이루어지거나이미전산화되어있던업무에대한용량산정을한다면이러한보정작업은별로의미가없겠지만신시스템구성시업무분석이이루어지지않은상태라면실제구현시추가로발생될작업부하에대해서예상후보정작업을수행해야만한다. 또한용량산정시사전에고려되어야할사항들이있는데, 그것들을나열하면다음과같다. 1 장기적으로시스템을단계적으로구축하는가? 일반적으로업무전산화수행시전년도의업무량을기준으로용량산정을수행하므로실제로시스템이도입되는시점에있어서는시스템자원이부족해질수있다. 또한 CPU의증설이불가한시스템을도입하거나 CPU 의증설만으로는요구성능으로 Upgrade가불가한경우는추후시스템과부하가발생하므로장기적인시스템증설계획인가를확인해야한다. 2 기종별각종 Slot 수가적정한가? 서버는대형, 중형, 소형컴퓨터등벤더에서판매하는각기종마다주변장치설치를위한 Slot수의제약이있다. 그러나시스템구성에따라추가적으로슬롯이필요할수가있다. 예를들면, Clustering 시스템을구성할경우, Heart Beat를점검하기위한인터페이스슬롯이추가적으로필요하다. 시스템구성을고려하지않고장비를도입하면, Interface Card가부족하여시스템구성자체가불가능할수있다. 또한 CPU, 메모리, Main Board 등주요자원의확장 Slot도고려해야한다. 68

84 3 장비설치요건이맞는가? 하드웨어의모든장비는자신만의독특한설치요건을가지고있다. 하나의디스크어레이는속도향상과장애대처를위해두개의인터페이스를가진다거나, 메모리분야에있어서필수적으로 Pair로구성되는경우가많다. 이경우초기시스템도입시사이즈가작은모듈로메모리를구성하면확장의어려움에처하기쉽다. 4 시스템설치전략에맞는용량인가? 업무량분석을통한용량산정을기반으로실제하드웨어용량은기타시스템구성정책에의해가중치가부여된다. 만일시스템백업을위해클러스터링시스템을구성한다면대응서버의 CPU와메모리의여유율을더한용량을가져야할것이며, 디스크미러링을수행한다면디스크양의두배가필요하게될것이다. 시스템용량산정수행시에는이러한변수가많이존재하기때문에철저한검토가필요하다. 2. 용량산정절차 전사적시스템선정을위한용량산정절차는 [ 그림 5-2] 에서제시한바와같다. 시스템구축방향및기초자료조사 기초자료및업무분석 구성요소별용량산정 산정결과검증및완료 [ 그림 5-2] 용량산정과정 시스템구축방향및기초자료조사단계에서는향후구축될전체시스템에 대한아키텍처구성및정보흐름을파악하여모델을설정하고기초자료및 69

85 업무분석을통해서기본적인업무부하와보정계수를결정하며, 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시간) - 년간접속자증가율 70

86 [ 표 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 트랜잭션량 예상연간트랜잭션증가율 온라인업무량 검색, 갱신, 삽입, 삭제별레코드크기 및전체건수, 인덱스합치건수등 배치업무량 온라인업무에대한배치업무비중 배치업무구분 대량배치기준으로데이터건수및 길이 71

87 [ 표 5-2] OLTP를위한기초자료조사항목 ( 계속 ) 데이터베이스 데이터크기 ( 초기, 1년차, 2년차, 3년차및 3년차이후데이터증가율 ) 데이터중이미지, 사운드, 텍스트파일의비율 인덱스테이블의초기크기및 3년내크기 테이블크기의구성 - 열의평균바이트수데이터백업 데이터백업 데이터백업서버의운영여부 백업장치의접속패턴 백업데이터량운영시간 운영시간 (7X24) 네트워크속도 네트워크속도 2.2 기초자료및업무분석 필요시신규추가업무량과각업무별연관성및복잡도분석을수행하며, 기초자료및업무분석결과를통해서각업무별예상부하를결정하고이를합산하여기준부하 ( 예를들어, 기초 TPM) 를산정한다. 한편기초자료및업무분석시고려하여야할요소는다음과같다. 비즈니스를지원하기에적당하도록비즈니스요구사항을가능한반영한다. 응용업무의각트랜잭션타입, 특성, 가중치를조사한다. 응용업무에서처리하는트랜잭션의데이터처리흐름과처리량, 패턴을감안한다. 온라인업무와배치처리업무는구분해서분석한다. 요구시간, 처리볼륨 ( 데이터, 트랜잭션 ), 복잡성을분석한다. 타시스템과의연관관계를고려하여파생되는트랜잭션볼륨과데이터볼륨, 처리방법등을조사한다. 현재의용량과향후시스템서비스를개시한후업그레이드없이 72

88 사용할기간을감안하여필요용량을사전확보해야한다. 확장시에는확장대상업무, 시기, 부서, 사용자수, 데이터볼륨을감안하여확장방안을세운다. 시스템에탑재될시스템소프트웨어가무엇인지확인하고, 요구되는 CPU, 메모리, 디스크요구량을조사하여반영한다. 이때여러종류의소프트웨어가탑재되었을때시스템서비스에영향을미치는요소를평가하고이를다음의용량산정에반영한다. 2.3 구성요소별용량산정 업무분석자료를기반으로각종보정계수를설정한후어플리케이션의 구현모델에따라적절한용량산정모델을선택하여구성요소별로 용량산정을수행한다.( 세부산정기준및산정식은 3 절참조 ) 2.4 산정결과검증및완료 용량산정항목에따라용량산정을완료한후과거유사프로젝트 경험치를적용하여필요시재조정한후용량산정을완성한다. 73

89 제 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] 에서와같이산정방식을다르게적용한다. 74

90 1.2 OLTP 또는 OLTP & Batch 어플리케이션 고려사항 OLTP 또는 OLTP & Batch 어플리케이션을위한서버의용량산정을위해서 tpmc 추정에는여러가지방법이있으며현재까지공통적으로사용되는기준은존재하지는않는다. 그이유는어떤형태의서비스를제공하는시스템인지, 어떤형태의시스템아키텍처를사용하는지, 어떤기종을사용하는지등에따라다양한방법이존재할수있으며, 특히신규시스템인경우이와같은내용이외에업무내용이상세히분석되어야적정 tpmc 를산정할수있다. 그러나일반적인시스템의경우사용자수, 트랜잭션, 각종보정값등을고려하여적정용량을산정한다. 산정항목및보정치 본지침에서는 tpmc 추정을위한기준항목을 [ 표 5-4] 와같이 11개로구성한다. 각항목의입력값의범위는산정식의적용시해당값의적용범위를나타내며, 일반값은 default 값으로일반적으로적용하는값을말한다. 따라서용량산정을수행하는수행자가임의로주어진입력값의범위내에서적용이가능하다. 한편, 서버의 CPU 산정결과에큰영향을미치는요소로는동시사용자수와어플리케이션복잡도보정, 사용자복잡성보정, 어플리케이션구조보정, 어플리케이션부하보정으로동시사용자수의산정에는신중한접근필요하며, 어플리케이션복잡도보정, 사용자복잡성보정, 어플리케이션구조보정, 어플리케이션부하보정의경우적용대상업무에대한상세한분석이선행되지않으면, 각항목의입력값에대한적용이쉽지않으므로일반적인값을적용하는것을권고한다. 75

91 [ 표 5-4] OLTP 산정항목및보정치항목입력값범위일반값내용 - 동시에발생하는처리건수의 30% 동시사용자수 - 동시사용자수는접속사용자의 40% 트랜잭션처리수 기본 TPMC 보정 3( 단순 )~ 7개 ( 복잡 ) 20( 소규모 )~ 30%( 대규모 ) 접속사용자는전체사용자의 70% 1 명이 1 분동안발생한트랜잭션수 1.2 시스템규모에따라보정 Peak Time 보정데이터베이스크기보정어플리케이션복잡도보정사용자복잡성보정어플리케이션구조보정어플리케이션부하보정네트워크보정클러스터보정 20( 단순 )~ 30%( 복잡 ) 1.2 업무가폭주하는경우고려하여보정 표참조 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%( 대규모 ) 정도를적용한다. 76

92 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 ~ , , 주 ) Columns: Number of Rows of the biggest table( 단위 : 백만 ) Rows: Database Size of in Gbytes 어플리케이션복잡성보정 : 어플리케이션복잡성테이블은어플리케 77

93 이션또는트랜잭션의성격과해당어플리케이션에관계된주요테이블의개수에의한비중치를나타낸다. 어플리케이션의유형은서로다른부하를주며, 테이블의수도부하에상당한영향을미치게된다. 특히분석적인어플리케이션에관계된테이블이많은경우조인 (Join) 등의부하가급격히증가된다. 어플리케이션복잡성테이블에사용된어플리케이션은주로 MIS 업무를중심으로한것이다. 어플리케이션복잡성보정을위한구체적인수치는 [ 표 5-6] 과같다. 한편, 정확한업무예측의어려움으로인해이러한복잡도보정치를적용할수없거나개략적인적용을수행하고자하는경우, 일반값인 1.1을적용할수있다. 사용자복잡성보정 : 사용자복잡성테이블은접속사용자 (Connection Users) 와동시사용자 (Con current Users) 의규모에따른비중치를나타내며세부적인적용기준은다음표와같다. 접속사용자는해당어플리케이션을사용할수있는사용자를말하며, 트랜잭션발생유무에는관계하지않는다. 동시사용자는실제로시스템에접속하여트랜잭션을발생시키는, 즉업무를수행하는사용자이다. 접속사용자의증가에따라가중치를조정하는것은새로이접속요청을할수있는가능성을고려한것이다. 실제시스템의부하증가는접속요청시에매우증가되기때문이다. 따라서동일한동시사용자수환경도접속가능사용자의수에따라가중치를차등적용하게된다. 한편, 보정치를적용하기어렵거나개략적인적용을수행하고자하는경우, 일반값인 1을적용할수있다. [ 표 5-6] 어플리케이션복잡도보정치 종류 테이블개수 비고 응용의형태 단순검색 단순갱신 단순 Trx 유형 보통 Trx 유형 복잡 Trx 유형 분석작업

94 [ 표 5-7] 사용자복잡도보정치 크기 접속사용자수 ,000 3,000 5,000 5,000+ 비고 동시 사용 자 1, 수 1, [ 표 5-8] 어플리케이션구조보정치 항목 Direct User Connection Front-End Server 사용 Appl. Logic 포함 Database Only Appl. Logic 포함 Database Only ~ ~ ~ ~ ~ ~ ~ 주 ) 행 : 어플리케이션구성방법, 열 : 요구되는응답시간 (Seconds) 어플리케이션구조보정 : 어플리케이션구조보정은어플리케이션로직을동일서버에포함하는지의경우와요구되는응답시간에따른비중치를말한다. Direct User Connection은 2-Tier Client/Server 구성과같이 DB 업체또는표준화된 DB 접근미들웨어를사용하는것으로상위의네트웍계층에서동작하므로부하가증가한다. Front-End Server의사용은 3-Tire Client/Server 구성과같이 User Connection의부하를감소시켜주며, 특별한부하발생가능성이적기때문에가중치를 1이하로적용한다. 응답시간은최종사용자의입장에서본것으로서버와사용자간의네트웍지역을감안하여가중치를조정하도록한다. WAN이포함된환경은동일한응답성을얻기위하여는시스템의처리가빨라야하므로가중치를높게 79

95 결정해야한다. 한편, 보정치를적용하기어렵거나개략적인적용을 수행하고자하는경우, 일반값인 1 을적용할수있다. 어플리케이션부하보정 : 추가적인로드테이블은온-라인작업을수행하는 Peak time에배치작업등을수행하여야하는경우의비중치를말한다. 정해진온-라인업무외에부가적인작업이처리되는경우그에필요한처리능력을보정하는단계이다. 즉배치성업무 ( 리포팅, 백업등 ) 나외부시스템을사용하는경우등이해당된다. 한편, 보정치를적용하기어렵거나개략적인적용을수행하고자하는경우, 일반값인 1을적용할수있다. [ 표 5-9] 어플리케이션부하보정치 크기 동일한데이터 서로다른 데이터 비고 None 1 1 Light Normal Heavy 3 2 Job 내용이명확한경우가중치를 사용하지않고파악된부하량 (tpmc 기준 ) 을가산 주 ) 행 : 배치작업과온 - 라인작업이동일한데이터테이블을사용한경우와 그렇지않은경우, 열 : 배치작업의부하 (Light < 10Min, Normal < 30Min, Heavy > 30Min) 네트워크보정 : 네트워크대역폭으로인해응답시간이지연되는것을 CPU 처리로보완하기위한것으로 10% 정도를적용한다. 클러스터보정 : 2대의시스템이하나의클러스터로구성될때, 하나의시스템에장애가발생하면남아있는시스템이장애가발생된시스템의응용프로그램을모두수행하고, 사용자들을접속하게된다. 이경우시스템의예비율이없으면업무가가중되어정상적인운영이어렵게되므로이에대한예비율을두어야한다. 일반적으로상대시스템의 100% 를두어야하지만, 이는비경제적이고비효율적이므로 80

96 약 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 값으로일반적으로적용하는값을말한다. 따라서용량산정을수행하는수행자가임의로주어진입력값의범위내에서적용이가능하다. 81

97 [ 표 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% 정도를적용한다. 82

98 시스템여유율 : 예기치못한업무의증가및시스템의안정된운영 을위한보정으로 30 ~ 50% 정도적용한다. 사용자당 Operation 수 : 사용자당 operation 수는사용자한사람이 분당발생시키는 operation 수로서기초자료조사시이를확인하나 확인이불가능할경우, 통상 10 개정도로가정한다. 산정식 OPS = 동시사용자수 * 어플리케이션 Interface 부하보정 * Peak Time 부하보정 * 시스템여유율 * 사용자당 operation 수 2. 메모리 고려사항 메모리의용량산정방법은 CPU에비해훨씬단순하다. 시스템별로프로그래밍언어, 쓰레드사용등여러메모리점유를줄이기위한전략에따라용량산정방법이조금씩차이가있으며, 메모리용량산정은시스템에서구동되는프로세스의수와그프로세스가사용하는메모리양이큰영향을준다. 따라서시스템의용도와구조를바탕으로하여메모리용량을산정한다. 산정항목및보정치 메모리산정을위한항목은 [ 표 5-6] 에서와같이 6개로구성되어있다. 각각의입력값의범위는산정식의적용시해당값의적용범위를나타내며, 일반값은 default 값으로일반적으로적용하는값을말한다. 따라서용량산정을수행하는수행자가임의로주어진입력값의범위내에서적용이가능하다. 83

99 [ 표 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의사용에필요한사용자당메모리를지칭한다. 이러한사용자당필요메모리는어플리케이션의구현형태에따라사용자별로서비스하기위해요구되는메모리, 미들웨어를적용할때는이에따른시스템구현특성과서비스하기위해요구되는메모리, 사용자나어플리케이 84

100 션프로세스별데이터입출력을하기위해필요한메모리, 각벤더의 DBMS 에특성에따라요구메모리등을감안하여계산한다. 일반적인 값으로 0.3MB 를적용한다. 버퍼캐쉬 (Buffer Cache) : Disk I/O 횟수를줄이기위한버퍼캐쉬크 기는시스템운영자의요구에의해정해지는데일반적으로전체필요메 모리량의 20% ~ 30% 정도로적용한다. 클러스터보정 : 시스템을서로다른업무를수행하는클러스터링구 조로구성할경우, 다른서버의업무를수행할경우를보정하는것으로 30 ~ 70% 정도적용한다. 여유율 : 시스템의성격및업무의증가에따라시스템을안정적으로 운영하기위하여 20 ~ 50% 를보정한다. 산정식 메모리 = { 시스템영역 + 시스템관리자영역 + 사용자당필요메모리 * 사용자수 } * 버퍼캐쉬 * 클러스터보정 * 여유율 3. 디스크 고려사항 디스크용량산정시가장중요한고려요소는데이터백업방안이다. 백업정책에의해 Disk 요구량은큰차이를가지기때문에데이터의중요도를고려하여상황에적절한백업정책을수립할필요가있다. 데이터백업을수행하기위한방법과도구는여러가지가존재하는데일반적으로시스템자체적으로백업정보를보관하면서테이프와같은보조기억장치를사용하는이중백업정책을가지는경우가많다. 만일은행업무와같이데이터의신뢰성과안정성이절대적으로필요한경우라면 85

101 디스크미러링과같은시스템 Full 백업방안도유용할것이다. 본연구에서는디스크용량에포함되는백업요소로 DBMS에서제공되는 Archive 백업과하드웨어적인 RAID 디스크사용에의한백업만을포함한가장일반적인용량산정방안을기술한다. 산정항목및보정치 [ 표 5-12] 디스크산정항목및보정치 항목 입력값범위 일반값 내용 시스템OS 영역 - 운영체제및시스템소프트웨어등을위한영역 응용프로그램영역 - 미들웨어 및 응용소프트웨어 영역 데이터베이스영역 - 데이터베이스설치영역 ( 선택적 ) 상용 S/W 영역 - 기타유틸리티를위한영역 SWAP 영역 메모리 - swapping을위한작업공간 *2 여유율 20% ~ 50% 안정적인 시스템구성을 위한 공간 백업영역 - 데이터와데이터변경내역을 기록하기위한공간 RAID 여유율 20% ~ 50% - Disk가도입될경우패리티영역 시스템운영체제영역 : OS, 시스템 S/W, Super User 등을위한영 역 응용프로그램영역 : 서버용어플리케이션 Program 크기 데이터베이스영역 : DB 영역은다음세부항목의합계로결정된다. 다만인덱스의크기는시스템별인덱스정책에따라보정범위가가변적이다. - 실자료공간 ( 건수 * 건수별데이터사이즈 * 보관기간 ) 86

102 - 예비용데이터공간 ( 실데이터공간의 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 영역 * 여유율 87

103 제 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 규모산정을위한세부적인자료는앞서언급한업무분석과정을통 해서도출되었으며, 이를기초자료조사결과표에정리하면다음과같다. 88

104 [ 표 5-13] WAS를위한기초자료조사결과 항목 설명 조사결과 시스템용도및서비스형태 1) 웹페이지만제공 2) 트랜잭션이빈번하지 3) 트랜잭션이빈번한웹서비스 (DB연계) 않은웹서비스 (DB연계) 3) 트랜잭션이빈번한웹서비스 (DB연계) 시스템의구성형태 1) Single tire 2) 2-tire 3) 3) 3-tire 3-tire 접속자수 - 평균접속자수 (24시간기준 ) - 최고접속자수 (1시간) - 년간접속자증가율 1,000명 500명 년증가율 30% ( 증가율감안 3년필요 ) 사용율 - 동시사용자수 - 사용자당 Operation 수 - 이미지파일과사운드파일의크기 - 웹페이지크기 - 허용응답시간 동시사용자 250명 3건 / 분 5K 3초 ~ 5초 네트워크속도 네트워크속도 100Mbps 업무중요도및긴급도 - 중요도 ( 상, 중, 하 ) - 긴급도 ( 상, 중, 하 ) 중요도 : 상 긴급도 : 상 백앤드상호작용의형태 1) Read only 2) Update 3) OLTP 3) OLTP SSL 사용여부 미사용 [ 표 5-14] DB 서버를위한기초자료조사결과 항목설명조사결과 시스템구축형태 1) Single System 2) HA System 3) 병렬구성 사용자수 - 전체사용자수 - 동시사용자의비율 - 동시사용자당평균질의수 (1일) - 가동시간중 Peak-time의시간 - 년간사용자증가율 1) Single System 1,000명 25% 3건 ( 분당 ) 4시간 30% 89

105 [ 표 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 서버에대해서는시스템디스크뿐만아니라백업을위한데 이터디스크에대한용량산정을아울러수행하였다. 90

106 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 용량을산정하기위해서는동시사용자수, 트랜잭션 91

107 처리수, 기본 tpmc 보정, Peak Time 보정, CPU 부하보정, 어플리케이션복잡도보정, 사용자복잡성보정, 어플리케이션구조보정, 어플리케이션부하보정, 네트워크보정, 클러스터보정, 여유율등을고려하는데세부적인산정근거와산정내용은 [ 표 5-16] 과같다. 특히, 서버의 CPU 산정결과에큰영향을미치는요소로는동시사용자수와어플리케이션복잡도보정, 사용자복잡성보정, 어플리케이션구조보정, 어플리케이션부하보정으로동시사용자수의산정에는신중한접근필요하며, 어플리케이션복잡도보정, 사용자복잡성보정, 어플리케이션구조보정, 어플리케이션부하보정의경우적용대상업무에대한분석이선행되지않으면해당항목에대한적용이쉽지않으므로일반적인값을적용하였다. [ 표 5-16] DB 서버의 CPU 산정근거 항목산정근거산정내역 동시사용자수 동시사용자 * 증가율 (30%)*3 년 - 250*1.3*1.3*1.3=549 명 트랜잭션처리수기본 TPMC보정 Peak Time 보정데이터베이스크기보정어플리케이션복잡도보정사용자복잡성보정 사용자 1인이분당발생시키는트랜잭션의수로단순작업이므로 3으로가정시스템규모가크기않으므로소규모인 20% 적용업무가폭주하는경우고려하여보정으로 20%( 단순 ) 적용일반값으로적용 3건 / 분

108 [ 표 5-16] DB 서버의 CPU 산정근거 ( 계속 ) 항목산정근거산정내역 어플리케이션구조보 1 정 어플리케이션부하보 1 정 네트워크보정 클러스터보정 네트워크대역폭으로인한지연보완 10% 적용클러스터환경에서장애발생시를위한보정이므로 1적용 여유율보정 시스템의안정된운영을위한 보정으로 30% 적용 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] 와같다. 93

109 [ 표 5-17] WAS서버의메모리산정근거 항목 산정근거 산정내용 동시사용자 동시사용자 * 증가율 (30%)*3년 - 250*1.3*1.3*1.3=549명 시스템영역 OS, DBMS엔진, 미들웨어엔- 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서버의메모리크기는 ( 시스템영역 + 관리자영역 + 사용자당필요 )* 버퍼캐쉬 * 클러스터보정 * 여유율, 즉 ( )*1.2*1.3*1.3로계산되며, 산정결과 WSA서버의시스템디스크크기는약 818MB 정도를필요로한다. 따라서메모리확장단위를감안하여 1024 MB로선정한다. DB 서버 WAS서버의메모리용량을산정하기위해서는동시사용자수, 시스템영역, 시스템관리자영역, 사용자당필요메모리, 버퍼캐쉬, 클러스터보정, 여유율등을계산하여야하며, 산정근거와산정내용은 [ 표 5-18] 과같다. 한편, WAS서버의메모리크기는 ( 시스템영역 + 관리자영역 + 사용자당필요 )* 버퍼캐쉬 * 클러스터보정 * 여유율, 즉 ( )*1.2*1.3*1.3로계산되며, 산정결과 WAS서버의시스템디스크크기는약 1,337MB 정도를필요로한다. 따라서메모리확장단위를감안하여 2,048 MB로선정한다. 94

110 [ 표 5-18] DB서버의 CPU 산정근거 항목 산정근거 산정내용 동시사용자 동시사용자 * 증가율 (30%)*3년 - 250*1.3*1.3*1.3=549명 시스템영역 OS, DBMS엔진, 미들웨어엔- 64MB + 288MB(32 진, 기타유틸리티등의소요공간 : 기본 OS+ 서비스 ( 트랜잭 MB+256MB)+ 32MB =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 정도를필요로한다. 95

111 [ 표 5-19] WAS서버의시스템디스크산정근거 항목 산정근거 산정내역 시스템 OS 영역 WindowNT 500MB 응용프로그램영역 응용프로그램 1GB SWAP 영역 서버메모리의 2배적용 2,048MB 여유율 성능향상공간 30% 적용 1.3 DB 서버 - 시스템디스크 데이터베이스서버의시스템디스크용량산정항목과산정근거, 산정 내역은다음의표와같다. [ 표 5-20] DB서버의시스템디스크산정근거 항목 산정근거 산정내역 시스템OS 영역 WindowNT 500M 응용S/W 영역 DBMS 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로계산되며, 산정결과데이터베이스서버의시스 96

112 템디스크크기는약 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%) 데이터 공간 :(5,338MB+1,601MB) *0.6 =4,163MB - DB 영역 : 5,338MB+ 1,601MB + 4,163MB = 11,102MB RAID 영역 RAID-5적용 1.2 여유율 성능향상공간 30% 적용

113 제 6 장시스템화방안 제 1 절시스템화의개요 용량산정을위한시스템화는크게 2가지관점에서추진되는것이필요하다. 먼저단기적인관점에서는제시된용량산정기준에따라용이한계산이이루어지도록용량산정도구를제시하는것이며, 장기적인관점에서는용량산정을위한기준을보완과공공부문정보시스템의성능평가를위한용량산정에대한구체적인데이터를수집보관하는리포지토리 (Repository) 를구축하고이를운영하고갱신하는체계이다. 한편이들에대한세부적인내용은다음과같다. 용량산정을위한도구개발 제시된기준에용량산정결과를확인할수있도록프로그램화하여제시함으로써용량산정을수행하는사람이간단히사용할수있도록하는데그목적을두고있다. 이러한도구의작성은사용자의편리성을감안하여작성되는것이필요하다. 따라서도구를분석하여도구화방안을제시한다. 용량산정을위한리포지토리운영 앞서 3장에서언급한바와같이어떤기관이나회사에서도해당사업과관련하여 H/W의적정용량을산정하는것은결코쉬운일이아니다. 적정용량의 H/W를산정하는원칙은있지만업종별로회사별로다르다. 아무리큰규모의장비를도입했다하더라도개발된어플리케이션의문제로성능이나오지않을수도있고튜닝을해야할상황도발생한다. 적정용량산정도반드시근거가있어야한다. 이를위해서는동종업계의유사규모사이트에서실제로운영되는시스템의용량들을파악하는것이필요하다. 이를근거로해당사업에서의시스템규모를판단해야되며또한동종업계분석으로다른사람들을설득할수있는객관적인 98

114 자료도확보하기위함이다. 현재제시된용량산정식을보다견고하게하기위해서는많은용량산정자료를바탕으로보정치나여유율의값을보완할수있도록하여야하며, 따라서이를위해지속적으로관련자료를축척하는것이필요하다. 이러한자료의축적은장기적인관점에서추진되는것이바람직하며, 필요시제도적인접근을통해서의무화하는방안이제시될필요가있다. 99

115 제 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 계산식의메인화면을보여주고있다. 100

116 [그림 6-1] EXCEL 계산식 메인 화면 H/W 용량산정에서는 CPU와 메모리 용량산정을 수행해 볼 수 있도록 되어있으며, CPU 용량산정의 경우는 계산된 용량(tpmC)에 따른 서버의 벤 더별 제품 및 가격을 확인해 볼 수 있도록 하고 있다. [그림 6-2] CPU 용량산정 화면 101

117 [ 그림 6-3] 메모리용량산정화면 CPU의용량산정에있어서입력값에해당하는각셀당도움말을제공하고최종 tpmc 값이얻어지면결과값을통해최근의벤더별서버제품사양및가격대를확인해서관련사업의적정한서버용량산정뿐만아니라예산부분에있어서도검토가쉽게이루어질수있도록하였다. IBM 사의 High volume Web site Simulator(HVWS) IBM사의 High volume Web site Simulator는분석적큐잉모델 (Analytical queueing model) 로서사용자가정의한다양한워크로드를갖는웹사이트의성능을추정하기위해만들어졌다. 이모델의결과는 H/W 구성요소의산정을위한가이드라인으로서사용될수있다. 절대적인성능결과치를이모델에서제공하지는않으며, 추정된구성요소에는백업장비와같은서버는포함하지않고있다. 따라서이를적용하는사람이필요로하는서버를추가적으로고려함으로써포함시킬수는있다. 작업부하에대한실제성능은많은변수들간의복잡한상호작용에의해서영향을받는데이러한변수를전부포함하여모델화되지는않았다. 왜냐하면이모델의결과가벤치마킹이나상세한응용의검토를대체할수없기때문이다. 102

118 한편, 이시뮬레이터의입력은시뮬레이션하고자하는비즈니스형태와각사용자별상호작용의형태를정의하고각트랜잭션에대한 think time 을추정하기위한비즈니스패턴영역과응답시간및동시사용자수등과같은성능목표치를제시하는목표그리고적용하고자하는서버의수와형태를기술하는 H/W 토폴로지영역, 마지막으로운영체제, 데이터베이스, 백그라운드운용소프트웨어등을명시하는 S/W 영역으로구성되어있다. [ 그림 6-4] HVWS 의비즈니스패턴입력화면 103

119 [ 그림 6-5] HVWS 의소프트웨어입력화면 이러한각각의영역에세부적인값을지정하고결과버튼을누르면, 결과를보여주는데이러한결과는 [ 그림 6-6] 와 [ 그림 6-7] 에서보는바와같이계산결과와그래프결과치등두가지형태로되어있다. 계산결과는전체요약 (Over all), 평균응답시간 (Min Response time), 이용율 (Utilization), 메모리 ( 메모리 ) 등을보여주며, 그래프결과치는다양한관점에서가시화된결과를보여준다. [ 그림 6-6] HVWS 의계산결과출력화면 104

120 [ 그림 6-7] HVWS 의그래프결과출력화면 2. 제안된 EXCEL 계산식 HVWS와같이 H/W 벤더들이제공하는용량산정도구는자사의특정제품에기반해서제시된업무부하를성능관점에서시뮬레이션하는도구들이대부분으로일반적인용량산정의관점보다는개략적인성능모델링혹은성능평가를위한도구의성격을가지고있다. 따라서특정제품에기반하지않고성능을시뮬레이션하는도구를제시하는것은매우어려운일이다. 특히, 본연구를통해서제시된용량산정지침은 H/W 산정을위한방법과같이업무부하에바탕을둔계산적인방식으로성능모델보다는정량적인결과치를보이는계산식의적용이합리적이다. 따라서본과제에서는서버의용량산정을보다간단히수행해볼수있도록제시된용량산정기준에따라기존한국전산원의 EXCEL 계산식을개선하여제시하였 105

121 다. 제시된 EXCEL계산식에서의산정대상은 CPU(OLTP, WAS/WEB), 메모리, 디스크등으로구분하고있으며세부적인산정식은 [ 그림6-8] ~ [ 그림 6-11] 에서와같다. 각각의산정대상에서입력값에해당하는각셀당도움말을제공하고있으며, 입력값이변경됨에따라자동으로값들이산출되도록구성되어있다. [ 그림 6-8] OLTP 서버의용량산정화면 [ 그림 6-9] WEB/WAS 서버의용량산정화면 106

122 [ 그림 6-10] 메모리용량산정화면 [ 그림 6-11] 디스크용량산정화면 107

123 제 3 절용량리포지토리구축 1. 자료축척및활용체계 용량산정을위한자료수집체계구축의 1차적인목표는용량산정용리포지토리구축 / 운영을통해현재제시된용량산정식을보다견고하게하기위해서는많은용량산정자료를바탕으로보정치나여유율의값을보완할수있도록해야한다. 이를위해서지속적인용량산정자료축척이필요하다. 이와같은목적을달성하기위해용량산정을위한자료의축척및활용을위한개념적인체계는 [ 그림 6-12] 와같다. 용량산정정보 축적 리포지토리 활용 용량산정기준개선 공공기관한국전산원용량산정기준개정위원회 [ 그림 6-12] 용량산정자료축척및활용체계 이러한용량산정자료의원활한축척을위해서는공공기관의적극적인참여를전제로하여야한다. 그러나이는현실적으로쉽지않은일이다. 따라서사용자들의적극인참여를유도할수있는방안과강제할수있는방안이동시에고려되어야한다. 따라서이러한측면에서용량자료의축척을위해서는단계적인접근방법을제시하면 [ 표 6-1] 과같다. 용량자료의축척은크게 2단계로나누어수행할수있는데, 우선, 1단계 ( 도입단계 ) 에서는한국전산원이수행하고있는정보화지원사업을대상으로용량산정정보를축척하여성과를확인하고, 확대운영단계인 2단계에서는제도적인보완을통해서공공기관의정보시스템도입장비의성능평가등과연계하여전체공공기관의참여를유도하는것이바람직 108

124 할것이다. 이러한자료의축적은앞서언급한바와같이장기적인관점 에서추진되어야, 필요시제도적인접근을통해서의무화하는방안을 고려할필요가있다. [ 표6-1] 용량자료축척을위한단계적접근방법 단계 적용대상및범위 비고 1단계 ( 도입단계 ) 한국전산원이수행하고있는정보화지원사업을대상으로용량산정정보를축척 2 단계 ( 확대운영단계 ) 공공기관의정보시스템도입장비의 성능평가등과연계하여전체공공기 관으로확대운영 법적 / 제도적강제성을갖도록규정하는것이필요 2. 용량리포지토리시스템구성 용량산정을위한리포지토리시스템은웹시스템을기반으로한국전 산원내부에용량산정포털사이트를구축하여서비스를제공한다 한국전산원 [ 그림 6-13] 용량리포지토리시스템구성 109

125 공공기관및민간의사용자들의적극적인활용을위하여용량산정을위한리포지토리는단순히용량산정정보의축척만을목적으로하는것은아니며, 제시된기준에따른용량산정기능을제공함은물론용량산정을위한기준, TPC 및 SPEC 등국제성능평가기관의서버에대한성능평가치, 각종용량산정에자료등을제공하도록한다. [ 표 6-2] 리포지토리의기능및제공정보 구분 내용 주요기능 제공정보 - 용량산정계산기능 - 자료분석기능 - 통계기능등 - TPC 및 SPEC 등국제성능평가기관의서버에대한성능평가치 - 각종용량산정자료 - 관련사이트정보등 한편, 이러한용량산정에수집자료로는용량산정을수행하는기관정보, 사업정보, 용량산정기초정보, 정보화전략계획수립정보, 성능평가자료등이다. 사업정보는정보화계획수립자료를입력하는경우에는불필요하다. [ 표 6-3] 리포지토리의수집정보 수집정보 내용 기관정보 기관명, 연락처등기관기초정보사업정보 사업명, 사업기간, 사업개요, 사업추진형태 ( 자체 / 외부위탁 ), 사업비, H/W 비용등사업정보 110

126 [ 표 6-3] 리포지토리의수집정보 ( 계속 ) 용량산정 정보 시스템구축형태 사용자수 트랜잭션수 온라인업무업무량 배치업무량 데이터베이스 데이터백업 운영시간 네트워크속도등 정보화전 략계획수 립자료 1, 2, 3차년도의시스템개발계획포함 년차별응용시스템개발계획및각시스템별조직인원, 사용자현황 년차별응용시스템개발계획및업무량증가율근거와 가정 년차별데이터베이스개발계획 정보화전략계획자료에근거한년차별성능예상치 ( 구축완료시점, 1년후, 2년후, 3년후 ) 업무특성에따른월별, 요일별, 일별, 시간대별업무폭주시예상치 성능평가 의자료 계수화된성능요구사항 monitoring tool 을사용한성능치 도입된시스템사양 업무량증가와년차별신규업무증가등을고려한 H/W upgrade(cpu 및메모리, i/o board) 실적등 상기자료외에도앞서서연구된내용을포함하여야하며, 저장된자료를참고자료로활용할수있도록시스템을개발하여야한다. 또한, 시스템도입계획과성능평가결과간의차이분석을하며, 그원인과결과를항목및계수화조정작업에반영할수있는시스템개발이필요하다. 111

127 제 7 장결론 본연구는국가차원에서정보시스템의용량을체계화하고절차별세부기준과적용방법을표준화하여객관적인용량산정을위한절차수립이요구됨에따라향후체계적인용량산정연구를수행하기위한전반적인로드맵의제안과아울러용량산정을위한프레임워크및산정방식을개발함으로써공공기관에서의시스템도입시정확하고편리한시스템용량산정방법을제공할수있게되었다. 본연구의주요한내용으로는용량산정연구를위한로드맵을제시하였으며, 국내외의용량산정을위한기준및사례를조사하여용량산정식을제안하였으며, 제시된용량산정항목 ( 보정계수및여유율포함 ) 과적용값에대해서현업전문가를통한의견수렴을거쳐적정성을검증하여최종적으로항목과적용값의범위를도출하였으며, 실제업무에적용을위한세부적인적용지침을제시하였다. 또한용량산정과관련된시스템화방안을아울러살펴보았다. 본연구결과를통해서공공부문의정보시스템의신규도입과성능향상등에시스템용량산정및표준화된평가기준을제공함으로써, 객관적기술분석을가능하게하여정보시스템의적정한선정과평가가이루어질수있으며궁극적으로정보화투자에대한성과를높일수있을것으로기대된다. 다만, 본연구에서제시한정보화용량산정방식은신규도입시스템을전제로하고있으며, 따라서시스템증설을위한경우에적용이가능한용량산정에대한추가적인작업이이루어져야할것으로판단된다. 더욱이용량산정식을고도화하기위해서는단기적으로델파이기법등을적용하여관련이해당사자및전문가를대상으로한추가적인검증과정이필요할것으로판단되며, 시스템도입계획과성능평가결과간의차이분석을하며, 그원인과결과를항목및계수화조정에반영하는작업을수행할필요가있을것으로생각된다. 112

128 용량산정을위한중요성에비추어볼때, 장기적인관점에서앞서언급한용량산정식고도화를위한항목과지표값에객관화작업을비롯하여용량산정식의지표값정확성확보를위한정보화전략계획수립연관성분석및성능평가에따른 H/W 용량산정방식, 지식 / 정보 DB 시스템구축, 제도정비등의추가적인연구가지속적으로수행될필요가있다. 113

129 참고문헌 [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 [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

130 [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] [31] [32] 115

131 부록 H/W 용량산정지침 ( 안 ) 한국전산원

132 - 목차 - 1. 지침의개요 지침의목적 지침의적용범위 지침의구성 용량산정개념및대상 용량산정의개념 용량산정의대상 용량산정의성능기준 용량산정의절차 용량산정시일반적고려사항 세부절차 H/W 요소별용량산정방식 CPU OLTP 또는 OLTP&Batch 어플리케이션 WEB시스템 /WAS 메모리 디스크 용량산정사례및계산식 사례의개요 기초자료조사결과 용량산정예 EXCEL 계산식 지침의개요 i

133 1.1 지침의목적 정보화시대의도래에따라사회적으로정보인프라구축에대한관심이고조되고있으며, 효율적인업무처리, 고객서비스개선등을위해다양한정보시스템이구축되고있다. 이러한정보시스템은 H/W, S/W, 사람으로구성되며, 이중 H/W 는공급업자혹은시스템구축자등에따라용량산정적용항목및적용비율을경험적으로적용하기때문에부정확한용량이산정되는경우가많이발생한다. 업무의성격, 업무증가율, 사용자사용빈도, 구축기술등을전체적으로고려하여 H/W용량을산정해야하므로, 시스템구축사업에서 H/W용량적정성의옳고그름을판단하는것은어려운일이다. 시스템구축사업에서 H/W가차지하는비중이전체프로젝트비용의적게는 50% 에서많게는 90% 을차지함에도불구하고, 그동안이부분은사업자나장비업체에의존적이고, 상대적으로소홀한분야로많은관심을갖지않았다. 이와같은이유로실제요구되는하드웨어의각구성요소가사업자나장비업체에의해과다또는과소산정되는경우가발생하여도마땅히개선할수있는방법이없었다. 따라서공공부문정보화사업에서의기획자 ( 공공기관 ), 구축자 (SI사업자및장비업체 ) 등이 H/W자원의도입을검토할경우참고할수있는 H/W 용량산정지침을작성하였다. 본지침은 TPC( 와 SPEC( 의다양한업무유형별성능기준을토대로국내 SI기업 (SDS, LG-CNS, HIT) 및장비업체 (IBM, SUN, Fujitsu) 의 H/W 산정기준을참조하여전문가그룹의토의를거쳐확정하였으며, 시스템구축비용중가장중요한 CPU, 메모리, 디스크용량산정에대해소개하고자한다. 1.2 지침의적용범위 본지침은공공부문정보화사업을대상으로사업기획시장비도입을위한 대략적인소요예산의산출을위해서혹은 SI 업체의 H/W 부문제안시의 H/W 규모산정을위한기준지침으로활용될수있다. 현행제시된지침은신규 2

134 도입되는 H/W 를전제로작성되었으며, 따라서기존시스템에대한용량확장을 위한지침으로활용하는것은바람직하지않다. 한편, 신규도입시스템에적용되는경우, [ 그림 1] 에서와같이정보화사업의수행전반에대해서적용가능하며, 사업을기획 / 발주하는주관기관, 시스템공급자, 감리기관등에서본지침을활용하여용량을산정할수있다. 우선, 주관기관에서는정보화사업을입안하는시점과세부사업계획의수립시에 H/W 규모산정이반드시필요하므로이를적용할수있다. 또한, 개발사업자는제안서를작성하여 H/W를제안하는시점과실제시스템사업자로선정된개발과정중아키텍처설계시본지침을적용할수있다. 한편, 감리기관의경우, 필요시감리시점에 H/W 용량산정의적정성을검증하는차원에서본지침을참조할수있을것이다. 범례 ) [ 그림 1] 정보화사업추진단계및주체별적용범위 1.3 지침의구성 3

135 본지침은 1 장의개요를포함하여, 2 장의용량산정개념및대상, 3 장의 용량산정절차, 4 장의 H/W 요소별용량산정방식그리고 5 장의용량산정사례 등총 5 장으로구성되어있다. 우선, 2 장에서는용량산정의개념정리및용량산정의대상이되는 H/W 구성요소를설명하고있으며, 마지막으로용량산정을위한서버별 (OLTP 서버, 웹서버, WAS 등 ) 성능기준을제시하고있다. 3장에서는용량산정시일반적인고려사항과용량산정의절차를기술하고있으며, 4장에서는 CPU, 메모리, 디스크등 H/W 구성요소별용량산정시고려사항과용량산정식및세부기준값을제시하였고, 마지막으로 5장에서는특정시스템을대상으로한산정사례와용량산정을위한시스템적인도구를제시하였다. 4

136 2. 용량산정의개념및대상 2.1 용량산정의개념 용량계획 (Capacity planning) 과시스템규모산정혹은용량산정이라는용어가혼용되어사용되고있다. 이들간에는어떠한차이가있을까? 여기에서용량계획과시스템규모산정그리고용량산정에대한개념을정의한다. 우선, 용량계획이라함은개략적인시스템아키텍처와응용업무를기반으로시스템에요구되는성능요구사항과성능을결정하기위한계획으로이해할수있다. 일반적으로이러한용량계획은다음과같은사항을다룬다. 클라이언트어플리케이션의형태 이들응용들에접근하는사용자의수 클라이언트어플리케이션의동작특성 서버시스템에대응하는오퍼레이션의형태 서버시스템에접속하는동시접속자의수 서버시스템에의해서수행되어져야하는피크율 피크타임하에서의여유율등 이에반해서기본적인용량과성능요구사항이제시되었을때, 그것을시스템 요구사항으로변환하는것을시스템규모산정이라고부른다. 일반적으로이러한 시스템규모산정시에결정하는요소는다음과같다. 서버컴퓨터의 CPU 의형태나수 서버컴퓨터의디스크서브시스템의크기나형태 서버컴퓨터의메모리크기 이를정리하면용량계획과시스템규모산정은다음표와같이정의할수있다. 5

137 [ 표 1] 용량계획과시스템규모산정의정의 구분정의비고 용량계획 (Capacity planning) 시스템의아키텍처와응용기반을전제로용량요구사항과성능을결정하는것으로구성할시스템의용량산정을위한계획 시스템규모산정 (System Sizing) 실제업무와응용을기반으로수학적인방법론을사용하여도입하고자하는시스템의용량을계산하는것 위의정의에서보듯이시스템규모산정은실제업무와응용을기반으로수학적인방법론을사용하여도입하고자하는시스템의용량을계산하는것으로시스템의아키텍처와응용기반을전제로용량요구사항과성능을결정하는용량계획과차이가있으며일반적으로사용하는용량산정의경우, 용량계획보다는시스템규모산정을의미하므로본지침에서는용량산정과시스템규모산정을동일한의미로사용한다. 2.2 용량산정의대상 본지침에서의용량산정대상이되는 H/W 는 PC 나기타주변장비가아닌 메인프레임급서버를의미한다. 이러한하드웨어구성분야는여러가지가 있지만 시스템가격및성능측면에서가장중요한세분야를용량산정분야로 정의한다. CPU : 해당업무를처리하기위한 CPU 용량을계산한후, 적정한성능을지닌서버기종을선정한다. 메모리 : CPU 용량산정에따른서버구성방안에의거하여, 서버별시스템소프트웨어, 응용프로그램등의메모리사용량을산정한다. 디스크 : CPU 용량산정에따른서버구성방안에의거하여, 서버별 OS, 시스템소프트웨어, DB의데이터, DB의 Archive및백업영역등의디스크사용량을산정한다. 6

138 2.3 용량산정성능기준 H/W 용량산정을위해서는시스템의아키텍처와작업부하의특성을고려한산정이이루어지는것이바람직하다. 작업부하의특성에따라서버의 CPU 용량산정을 OLTP( 혹은배치작업을포함하는 OLTP), WEB/WAS 등으로구분하여 CPU의용량산정을달리한다. OLTP 혹은배치를포함하는 OLTP 워크로드를위해서 TPC-C 기준의 CPU 용량산정방법을사용한다. TPC는 RDBMS의 OLTP 성능을평가하는가장공신력있는자료로알려져있다. 한편, 현대적인정보시스템의아키텍처에서웹기반응용부문은 3-계층아키텍처로구성되는것이일반적이므로, 웹환경을위한웹서버의경우성능기준치를 SPECweb99로 WAS시스템의경우 SPECjbb2000을적용한다. [ 표 2] 작업부하별적용성능기준치 구분 OLTP 또는 OLTP & Batch 어플리케이션 웹 (Web) 서버어플리케이션 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] 에서와같이산정방식을다르게적용한다. 7

139 3. H/W 용량산정절차 3.1. 용량산정시일반적고려사항 일반적으로시스템구성검토는업무분석이제대로이루어지지않은프로젝트초기에수행된다. 이때문에실제로작업부하를정확히예측하는것은불가능하다. 따라서필연적으로용량산정을위해서는다양한보정치를사용한다. 업무조사가많이이루어지거나이미전산화되어있던업무에대한용량산정을한다면이러한보정작업은별로의미가없겠지만신시스템구성시업무분석이이루어지지않은상태라면실제구현시추가로발생될작업부하에대해서예상후보정작업을수행해야만한다. 또한용량산정시사전에고려되어야할사항들이있는데, 이는다음과같다. 2 장기적으로시스템을단계적으로구축하는가? 일반적으로업무전산화수행시전년도의업무량을기준으로용량산정을수행하므로실제로시스템이도입되는시점에있어서는시스템자원이부족해질수있다. 또한 CPU의증설이불가한시스템을도입하거나 CPU의증설만으로는요구성능으로 Upgrade가불가한경우는추후시스템과부하가발생하므로장기적인시스템증설계획인가를확인해야한다. 2 기종별각종 Slot 수가적정한가? 서버는대형, 중형, 소형컴퓨터등벤더에서판매하는각기종마다주변장치설치를위한 Slot수의제약이있다. 그러나시스템구성에따라추가적으로슬롯이필요할수가있다. 예를들면, Clustering 시스템을구성할경우, Heart Beat를점검하기위한인터페이스슬롯이추가적으로필요하다. 시스템구성을고려하지않고장비를도입하면, Interface Card가부족하여시스템구성자체가불가능할수있다. 또한 CPU, 메모리, Main Board 등주요자원의확장 Slot도고려해야한다. 8

140 3 장비설치요건이맞는가? 하드웨어의모든장비는자신만의독특한설치요건을가지고있다. 하나의디스크어레이는속도향상과장애대처를위해두개의인터페이스를가진다거나, 메모리분야에있어서필수적으로 Pair로구성되는경우가많다. 이경우초기시스템도입시사이즈가작은모듈로메모리를구성하면확장의어려움에처하기쉽다. 4 시스템설치전략에맞는용량인가? 업무량분석을통한용량산정을기반으로실제하드웨어용량은기타시스템구성정책에의해가중치가부여된다. 만일시스템백업을위해클러스터링시스템을구성한다면대응서버의 CPU와메모리의여유율을더한용량을가져야할것이며, 디스크미러링을수행한다면디스크양의두배가필요하게될것이다. 시스템용량산정수행시에는이러한변수가많이존재하기때문에철저한검토가필요하다. 3.2 세부절차 전사적시스템선정을위한용량산정절차는 [ 그림 2] 에서제시한바와같다. 시스템구축방향및기초자료조사 기초자료및업무분석 구성요소별용량산정 산정결과검증및완료 [ 그림 2] 용량산정과정 시스템구축방향및기초자료조사단계에서는향후구축될전체시스템에대한 9

141 아키텍처구성및정보흐름을파악하여모델을설정하고기초자료및업무분석을통해서기본적인업무부하와보정계수를결정하며, H/W 구성요소별용량을산정하며, 용량산정항목에따라용량산정을완료한후과거유사프로젝트경험치를적용하여재조정한후용량산정을완성하는등의과정을거친다. 가. 단계 1 : 시스템구축방향및기초자료조사 공공부문에있어서의정보화사업의 H/W 용량산정을위해서는다음의기초자료가반드시필요한데, 정확한기초자료의확보를위해서는고객과의협의를통한업무분석과시스템구축방향설정이선행되어야한다. 따라서용량산정을위한첫번째단계로전체시스템에포함되는대략의서버개수, 어플리케이션아키텍처 (2-Tier, 3-Tier), 통신환경등을파악하며, 서버의개략적인업무성격과정보흐름을파악한다. 이러한서버의개략적인업무성격과정보흐름을파악하기위해서업무사용자를대상으로한 [ 표 3] 과 [ 표 4] 의양식에따라용량산정을위한기초자료를조사한다. 이는향후시스템용량산정의기본적인자료로활용되므로정확하게작성되어야하며, 작업부하의특성에따라 OLTP( 혹은배치작업을포함하는 OLTP), WEB/WAS 등서버의 CPU 용량산정을달리하므로서버별로업무특성을감안하여작성한다. [ 표 3] WEB/WAS를위한기초자료조사항목항목 설명 비고 시스템용도및서비스형태 1) 웹페이지만제공 2) 트랜잭션이빈번하지않은웹서비스 (DB연계) 3) 트랜잭션이빈번한웹서비스 (DB연계) 시스템의구성형태 1) Single tire 2) 2-tire 3) 3-tire 접속자수 - 평균접속자수 (24시간기준 ) - 최고접속자수 (1시간) - 년간접속자증가율 사용율 - 동시사용자수 - 사용자당 Operation 수 - 이미지파일과사운드파일의크기 - 웹페이지크기 10

142 - 허용응답시간네트워크속도네트워크속도업무중요도및긴급도 - 중요도 ( 상, 중, 하 ) - 긴급도 ( 상, 중, 하 ) 백앤드상호작용의형태 - Read only - Update - OLTP SSL 사용여부 [ 표 4] OLTP를위한기초자료조사항목항목 설명 비고 시스템구축형태 1) Single System 2) HA System 3) 병렬구성 사용자수 전체사용자수 동시사용자의비율 동시사용자당평균질의수 (1일) 가동시간중 Peak-time의시간 년간사용자증가율 트랜잭션수 년간트랜잭션량 1일평균트랜잭션량 Peak-time 트랜잭션량 예상연간트랜잭션증가율 온라인업무량 검색, 갱신, 삽입, 삭제별레코드크기및 전체건수, 인덱스합치건수등 배치업무량 온라인업무에대한배치업무비중 배치업무구분 대량배치기준으로데이터건수및길이 데이터베이스 데이터크기 ( 초기, 1년차, 2년차, 3년차및 3년차이후데이터증가율 ) 데이터중이미지, 사운드, 텍스트파일의 비율 인덱스테이블의초기크기및 3년내크기 테이블크기의구성 11

143 - 열의평균바이트수 데이터백업 데이터백업 데이터백업서버의운영여부 백업장치의접속패턴 백업데이터량 운영시간 운영시간 (7X24) 네트워크속도 네트워크속도 나. 단계 2 : 기초자료및업무분석 필요시신규추가업무량과각업무별연관성및복잡도분석을수행하며, 기초자료및업무분석결과를통해서각업무별예상부하를결정하고이를합산하여기준부하 ( 예를들어, 기초 TPM) 를산정한다. 한편기초자료및업무분석시고려하여야할요소는다음과같다. 비즈니스를지원하기에적당하도록비즈니스요구사항을가능한반영한다. 응용업무의각트랜잭션타입, 특성, 가중치를조사한다. 응용업무에서처리하는트랜잭션의데이터처리흐름과처리량, 패턴을감안한다. 온라인업무와배치처리업무는구분해서분석한다. 요구시간, 처리볼륨 ( 데이터, 트랜잭션 ), 복잡성을분석한다. 타시스템과의연관관계를고려하여파생되는트랜잭션볼륨과데이터볼륨, 처리방법등을조사한다. 현재의용량과향후시스템서비스를개시한후업그레이드없이사용할기간을감안하여필요용량을사전확보해야한다. 확장시에는확장대상업무, 시기, 부서, 사용자수, 데이터볼륨을감안하여확장방안을세운다. 시스템에탑재될시스템소프트웨어가무엇인지확인하고, 요구되는 CPU, 메모리, 디스크요구량을조사하여반영한다. 이때여러종류의소프트웨어가탑재되었을때시스템서비스에영향을미치는요소를평가하고이를다음의용량산정에반영한다. 12

144 다. 단계 3 : 구성요소별용량산정 업무분석자료를기반으로각종보정계수를설정한후어플리케이션의구현 모델에따라적절한용량산정모델을선택하여구성요소별로용량산정을 수행한다.( 세부산정기준및산정식은 4 장참조 ) 라. 단계 4 : 산정결과검증및완료 용량산정항목에따라용량산정을완료한후과거유사프로젝트경험치를 적용하여필요시재조정한후용량산정을완성한다. 13

145 4. H/W 요소별용량산정방식 4.1. CPU OLTP 또는 OLTP & Batch 어플리케이션 가. 고려사항 OLTP 또는 OLTP & Batch 어플리케이션을위한서버의용량산정을위해서 tpmc 추정에는여러가지방법이있으며현재까지공통적으로사용되는기준은존재하지는않는다. 그이유는어떤형태의서비스를제공하는시스템인지, 어떤형태의시스템아키텍처를사용하는지, 어떤기종을사용하는지등에따라다양한방법이존재할수있으며, 특히신규시스템인경우이와같은내용이외에업무내용이상세히분석되어야적정 tpmc를산정할수있다. 그러나일반적인시스템의경우사용자수, 트랜잭션, 각종보정값등을고려하여적정용량을산정한다. 나. 산정식 tpmc = 동시사용자수 * 트랜잭션처리수 * 기본 tpmc 보정 * Peak Time 보정 * CPU 부하보정 * 어플리케이션복잡도보정 * ( 사용자복잡성보정 * 어플리케이션구조보정 * 어플리케이션부하보정 ) * 네트워크보정 * 클러스터보정 * 여유율보정 다. 산정항목및보정치 본지침에서는 tpmc 추정을위한기준항목을 [ 표 5] 와같이 11개로구성한다. 각항목의입력값의범위는산정식의적용시해당값의적용범위를나타내며, 일반값은 default 값으로일반적으로적용하는값을말한다. 따라서용량산정을수행하는수행자가임의로주어진입력값의범위내에서적용이가능하다. 한편, 서버의 CPU 산정결과에큰영향을미치는요소로는동시사용자수와 14

146 어플리케이션복잡도보정, 사용자복잡성보정, 어플리케이션구조보정, 어플리케이션부하보정으로동시사용자수의산정에는신중한접근필요하며, 어플리케이션복잡도보정, 사용자복잡성보정, 어플리케이션구조보정, 어플리케이션부하보정의경우적용대상업무에대한상세한분석이선행되지않으면, 각항목의입력값에대한적용이쉽지않으므로일반적인값을적용하는것을권고한다. [ 표 5] OLTP 산정항목및보정치 항목 입력값범위 일반값 내용 동시사용자수 -동시에발생하는처리건수의 30% -동시사용자수는접속사용자의 40% 접속사용자는전체사용자의 70% 트랜잭션처리수기본 TPMC보정 Peak Time 보정데이터베이스크기보정어플리케이션복잡도보정사용자복잡성보정어플리케이션구조보정어플리케이션부하보정 3( 단순 )~ 1명이 1분동안발생한트랜잭션수 7개 ( 복잡 ) 20( 소규모 )~ 1.2 시스템규모에따라보정 30%( 대규모 ) 20( 단순 )~ 1.2 업무가폭주하는경우고려하여보정 30%( 복잡 ) 표참조 1.3 트랜잭션이처리하는데이터크기 - 데이터베이스크기 - 테이블의레코드수 표참조 1.1 프로그램의복잡한정도에따라적용 - 트랜잭션종류, 테이블수 표참조 1 - 접속사용자수 - 동시사용자수 표참조 1 - 요구응답시간 - 어플리케이션구성방법 (2~3tier) 표참조 1 BMT가아닌실제사용자운영환경 보정 네트워크보정 10% 1.1 네트워크대역폭으로인한지연보완 30( 단순 )~ 1 클러스터환경에서장애발생시를위한클러스터보정 50%( 복잡 ) 보정여유율보정 20 ~ 50% 1.3 시스템의안정된운영을위한보정 한편, 각각의기준항목에대한세부적인정의및적용의범위는다음과같다. 15

147 기본 TPC : TPC 에서제공하는 tpmc 수치는최적의환경에서측정하는것 으로실제상황에맞게보정을해주어야하며, 시스템규모에따라 20( 소규 모 ) ~ 30%( 대규모 ) 정도를적용한다. Peak Day & Peak Time : 업무의효율화와성능에의한정확하고도즉각적인결과값을얻기위해서업무가과중한시간대에시스템이원활하게운영되어야목적을달성할수있으므로 Peak Time을기준으로하여시스템을산정한다. 시스템은일반적으로평상시보다 Peak Time에약 20 ~ 30% 정도과중한로드를받게되므로이를고려하여가중치를적용한다. 데이터베이스크기 : 데이터베이스크기에따라가중치는 DB에속한가장큰테이블의레코드건수와전체 DB의볼륨을고려하여결정한다. 같은크기의 DB 경우에는건수가많은쪽이, 같은건수라면 DB 볼륨이큰쪽이큰가중치를갖게되며, 증가량의비율건수는 50% 단위증가로크기는 10% 증가단위로설정하였다. 그러나실제업무시스템에대한세부적인분석을근거로정확한값이도출되지않을경우, 가중치의적용이어려우므로용량산정자는일반값인 1.3을적용한다. [ 표 6] 데이터베이스크기가중치 크기 ~ 0.3 ~ 1 ~ 3 ~ 10 ~ 30 ~ 100 ~ 300 ~ , , 주 ) Columns: Number of Rows of the biggest table( 단위 : 백만 ) Rows: Database Size of in Gbytes 16

148 어플리케이션복잡성보정 : 어플리케이션복잡성테이블은어플리케이션또는트랜잭션의성격과해당어플리케이션에관계된주요테이블의개수에의한비중치를나타낸다. 어플리케이션의유형은서로다른부하를주며, 테이블의수도부하에상당한영향을미치게된다. 특히분석적인어플리케이션에관계된테이블이많은경우조인 (Join) 등의부하가급격히증가된다. 어플리케이션복잡성테이블에사용된어플리케이션은주로 MIS 업무를중심으로한것이다. 어플리케이션복잡성보정을위한구체적인수치는 [ 표 7] 과같다. 한편, 정확한업무예측의어려움으로인해이러한복잡도보정치를적용할수없거나개략적인적용을수행하고자하는경우, 일반값인 1.1을적용할수있다. [ 표 7] 어플리케이션복잡도보정치 종류 테이블개수 비고 응용의형태 단순검색 단순갱신 단순 Trx 유형 보통 Trx 유형 복잡 Trx 유형 분석작업 사용자복잡성보정 : 사용자복잡성테이블은접속사용자 (Connection Users) 와동시사용자 (Con current Users) 의규모에따른비중치를나타내며세부적인적용기준은다음표와같다. 접속사용자는해당어플리케이션을사용할수있는사용자를말하며, 트랜잭션발생유무에는관계하지않는다. 동시사용자는실제로시스템에접속하여트랜잭션을발생시키는, 즉업무를수행하는사용자이다. 접속사용자의증가에따라가중치를조정하는것은새로이접속요청을할수있는가능성을고려한것이다. 실제시스템의부하증가는접속요청시에매우증가되기때문이다. 따라서동일한동시사용자수환경도접속가능사용자의수에따라가중치를차등적용하게된다. 한편, 보정치를적용하기어렵거나개략적인적용을수행하고자하는경우, 일반값인 1을적용할수있다. 17

149 [ 표 8] 사용자복잡도보정치 크기 접속사용자수 ,000 3,000 5,000 5,000+ 비고 동시사용자수 , , 어플리케이션구조보정 : 어플리케이션구조보정은어플리케이션로직을동일서버에포함하는지의경우와요구되는응답시간에따른비중치를말한다. Direct User Connection은 2-Tier Client/Server 구성과같이 DB 업체또는표준화된 DB 접근미들웨어를사용하는것으로상위의네트웍계층에서동작하므로부하가증가한다. Front-End Server의사용은 3-Tire Client/Server 구성과같이 User Connection의부하를감소시켜주며, 특별한부하발생가능성이적기때문에가중치를 1이하로적용한다. 응답시간은최종사용자의입장에서본것으로서버와사용자간의네트웍지역을감안하여가중치를조정하도록한다. WAN이포함된환경은동일한응답성을얻기위하여는시스템의처리가빨라야하므로가중치를높게결정해야한다. 한편, 보정치를적용하기어렵거나개략적인적용을수행하고자하는경우, 일반값인 1을적용할수있다. 어플리케이션부하보정 : 추가적인로드테이블은온-라인작업을수행하는 Peak time에배치작업등을수행하여야하는경우의비중치를말한다. 정해진온-라인업무외에부가적인작업이처리되는경우그에필요한처리능력을보정하는단계이다. 즉배치성업무 ( 리포팅, 백업등 ) 나외부시스템을사용하는경우등이해당된다. 한편, 보정치를적용하기어렵거나개략적인적용을수행하고자하는경우, 일반값인 1을적용할수있다. 18

150 [ 표 9] 어플리케이션구조보정치 항 목 Direct User Connection Appl. Logic Database 포함 Only Front-End Server 사용 Appl. Logic Database Only 포함 ~ ~ ~ ~ ~ ~ ~ 주 ) 행 : 어플리케이션구성방법, 열 : 요구되는응답시간 (Seconds) [ 표 10] 어플리케이션부하보정치 크기 동일한 데이터 서로 다른 데이터 비고 None 1 1 Light Normal Heavy 3 2 Job 내용이명확한경우가중치를 사용하지않고파악된부하량 (tpmc 기준 ) 을가산 주 ) 행 : 배치작업과온 - 라인작업이동일한데이터테이블을사용한경우와 그렇지않은경우, 열 : 배치작업의부하 (Light < 10Min, Normal < 30Min, Heavy > 30Min) 네트워크보정 : 네트워크대역폭으로인해응답시간이지연되는것을 CPU 처리로보완하기위한것으로 10% 정도를적용한다. 클러스터보정 : 2대의시스템이하나의클러스터로구성될때, 하나의시스템에장애가발생하면남아있는시스템이장애가발생된시스템의응용프로그램을모두수행하고, 사용자들을접속하게된다. 이경우시스템의예비율이없으면업무가가중되어정상적인운영이어렵게되므로이에대한 19

151 예비율을두어야한다. 일반적으로상대시스템의 100% 를두어야하지만, 이는비경제적이고비효율적이므로약 30%( 단순 ) ~ 50%( 복잡 ) 까지의예비율을두어시스템장애시지속적이고도, 즉각적인서비스를가능하게하기위한보정치이다. 시스템여유율 : 예기치못한업무의증가및시스템의안정된운영을위한 보정으로 20 ~ 50% 정도적용한다 WEB 시스템 /WAS(Web Application System) 가. 고려사항 WEB/WAS 서버의용량산정을위해서 ops 추정은 tpmc 추정방식에비해상대적으로간단하게산정될수있다. tpmc가 11개의항목을사용하는데비하여 WEB과 WAS 서버의경우에는어플리케이션 Interface 부하보정치와 Peak Time 부하보정치, 시스템여유율등 3개의항목만을사용하여산정하도록정의하였으며 tpmc에비해상대적으로업무분석이않된경우에도산정이가능하다. 나. 산정식 OPS = 동시사용자수 * 어플리케이션 Interface 부하보정 * Peak Time 부하보정 * 시스템여유율 * 사용자당 operation 수 다. 산정항목및보정치 WEB/WAS 서버의용량산정에서는 6개의항목으로구성되어있다. 각각의입력값의범위는산정식의적용시해당값의적용범위를나타내며, 일반값은 default 값으로일반적으로적용하는값을말한다. 따라서용량산정을수행하는수행자가임의로주어진입력값의범위내에서적용이가능하다. 20

152 [ 표 11] 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% 정도를적용한다. 21

153 시스템여유율 : 예기치못한업무의증가및시스템의안정된운영을 위한보정으로 30 ~ 50% 정도적용한다. 사용자당 Operation 수 : 사용자당 operation 수는사용자한사람이 분당발생시키는 operation 수로서기초자료조사시이를확인하나확인이 불가능할경우, 통상 10 개정도로가정한다. 4.2 메모리 가. 고려사항 메모리의용량산정방법은 CPU에비해훨씬단순하다. 시스템별로프로그래밍언어, 쓰레드사용등여러메모리점유를줄이기위한전략에따라용량산정방법이조금씩차이가있으며, 메모리용량산정은시스템에서구동되는프로세스의수와그프로세스가사용하는메모리양이큰영향을준다. 따라서시스템의용도와구조를바탕으로하여메모리용량을산정한다. 나. 산정식 메모리 = { 시스템영역 + 시스템관리자영역 + 사용자당필요메모리 * 사용자수 } * 버퍼캐쉬 * 클러스터보정 * 여유율 다. 산정항목및보정치 메모리산정을위한항목은 [ 표 12] 에서와같이 6개로구성되어있다. 각각의입력값의범위는산정식의적용시해당값의적용범위를나타내며, 일반값은 default 값으로일반적으로적용하는값을말한다. 따라서용량산정을수행하는수행자가임의로주어진입력값의범위내에서적용이가능하다. 22

154 [ 표 12] 메모리산정항목및보정치 항목입력값범위일반값내용 시스템영역 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를적용한다. 사용자당필요메모리 : 사용자당필요메모리는어플리케이션, 미들웨어, D BMS의사용에필요한사용자당메모리를지칭한다. 이러한사용자당필요메모리는어플리케이션의구현형태에따라사용자별로서비스하기위해요구되는메모리, 미들웨어를적용할때는이에따른시스템구현특성과서비스하기위해요구되는메모리, 사용자나어플리케이션프로세스별데이터입출력을하기위해필요한메모리, 각벤더의 DBMS에특성에따라요구메모리등을 23

155 감안하여계산한다. 일반적인값으로 0.3MB 를적용한다. 버퍼캐쉬 (Buffer Cache) : Disk I/O 횟수를줄이기위한버퍼캐쉬크기는시 스템운영자의요구에의해정해지는데일반적으로전체필요메모리량의 20% ~ 30% 정도로적용한다. 클러스터보정 : 시스템을서로다른업무를수행하는클러스터링구조로 구성할경우, 다른서버의업무를수행할경우를보정하는것으로 30 ~ 70% 정 도적용한다. 여유율 : 시스템의성격및업무의증가에따라시스템을안정적으로운영 하기위하여 20 ~ 50% 를보정한다. 4.3 디스크 가. 고려사항 디스크용량산정시가장중요한고려요소는데이터백업방안이다. 백업정책에의해 Disk 요구량은큰차이를가지기때문에데이터의중요도를고려하여상황에적절한백업정책을수립할필요가있다. 데이터백업을수행하기위한방법과도구는여러가지가존재하는데일반적으로시스템자체적으로백업정보를보관하면서테이프와같은보조기억장치를사용하는이중백업정책을가지는경우가많다. 만일은행업무와같이데이터의신뢰성과안정성이절대적으로필요한경우라면디스크미러링과같은시스템 Full 백업방안도유용할것이다. 본연구에서는디스크용량에포함되는백업요소로 DBMS에서제공되는 Archive 백업과하드웨어적인 RAID 디스크사용에의한백업만을포함한가장일반적인용량산정방안을기술한다. 24

156 나. 산정식 시스템디스크 = { 시스템운영체제 + 응용프로그램 + SWAP 영역 } * 여유율 데이터디스크 = { 데이터영역 + 백업영역 } * RAID 영역 * 여유율 다. 산정항목및보정치 [ 표 13] 디스크산정항목및보정치 항목입력값범위일반값내용 시스템 OS 영역 응용프로그램영역 -운영체제및시스템소프트웨어등을위한영역 - 미들웨어및응용소프트웨어영역 데이터베이스영역 - 데이터베이스설치영역 ( 선택적 ) 상용 S/W 영역 - 기타유틸리티를위한영역 SWAP 영역 메모리 - swapping을위한작업공간 *2 여유율 20% ~ 50% 안정적인시스템구성을위한공간 백업영역 - 데이터와 데이터 변경 내역을 기록하기위한공간 RAID 여유율 20% ~ 50% - Disk가도입될경우패리티영역 시스템운영체제영역 : OS, 시스템 S/W, Super User 등을위한영역 응용프로그램영역 : 서버용어플리케이션 Program 크기 데이터베이스영역 : DB 영역은다음세부항목의합계로결정된다. 다만인덱스의크기는시스템별인덱스정책에따라보정범위가가변적이다. - 실자료공간 ( 건수 * 건수별데이터사이즈 * 보관기간 ) - 예비용데이터공간 ( 실데이터공간의 30%) - 인덱스및키용실데이터공간 (1+2의 60%) 25

157 SWAP 영역 : 시스템장애시의 Dump 역할수행과메모리대용의효율적인 SWAPping 을수행하기위한작업공간으로, 일반적으로주기억장치의요구량 의 2 배로산정한다. 여유율 : 안정성있는시스템구성을위해디스크여유율을가지는것이바람직하다. 업무분석의실수로디스크요구량이과소산정되거나고려하지못하여돌발적인사태에대비해서일반적으로전체필요디스크량의 20%~50% 정도를여유율로산정하는데기본적인값으로는 30% 를산정하는것이일반적이다. 백업영역 : 백업영역은백업정책에의하여결정되는데일반적으로데이터와데이터의변경내역정보를가지는 Archive 형태로보관한다. Archive 파일은실제데이터와 Log, 보관기간에의해전체사용영역이결정되는데, 백업파일을이중으로관리하기위해 Archive File 자체에대한백업을수행할수도있다. RAID 여유율 : RAID 여유율은 RAID 디스크가도입될경우데이터보호를위한패러티영역으로사용되는공간을가산적용하며, RAID1의경우, 50% 를 RAID5의경우 20% 로산정한다. 26

158 5. 용량산정사례및계산식 5.1 사례의개요 A기관에서는 2년계획으로인트라넷을기반으로하는통합 MIS를구축하고자하였다. 우선내부전산실및일선부서업무담당자를중심으로하여통합 MIS시스템구축을위한테스크포스팀을구성하고 1개월간의작업을통해서내부업무에대한분석을수행하고시스템구성방향등에대한개략계획을작성하였다. 이계획의개략적인시스템구성은다음그림과같다. [ 그림 3] 용량산정을위한시스템개념도 한편, 이계획에따라세부적인예산을결정하기위해서 S/W개발부문과 H/W 부분으로나누어프로젝트비용을산출하고자하였다. 특히, 통합 MIS 시스템을위한 H/W 부문은위의그림에서와같이 WAS서버, DB서버및백업장비만을신규로도입하고자하였다. 따라서 H/W도입을위한 H/W 규모산정의대상은이두장비를대상으로하였다. 5.2 기초자료조사결과 H/W 규모산정을위한세부적인자료는업무분석과정을통해서도출되었으며, 이를기초자료조사결과표에정리하면다음과같다. 27

159 [ 표 14] WAS를위한기초자료조사결과 항목 설명 조사결과 시스템용도및 1) 웹페이지만제공 3) 트랜잭션이 빈번한 웹 서비스형태 2) 트랜잭션이빈번하지않은 서비스 (DB연계) 웹서비스 (DB연계) 3) 트랜잭션이빈번한웹서비스 (DB연계) 시스템의구성형태 1) Single tire 2) 2-tire 3) 3-tire 3) 3-tire 접속자수 - 평균접속자수 (24시간기준 ) - 최고접속자수 (1시간) - 년간접속자증가율 1,000명 500명 년증가율 30% ( 증가율감안 3년필요 ) 사용율 - 동시사용자수 - 사용자당 Operation 수 - 이미지파일과사운드파일의크기 - 웹페이지크기 - 허용응답시간 동시사용자 250명 3건 / 분 5K 3초 ~ 5초 네트워크속도 네트워크속도 100Mbps 업무중요도및긴급도 - 중요도 ( 상, 중, 하 ) - 긴급도 ( 상, 중, 하 ) 중요도 : 상 긴급도 : 상 백앤드상호작용의형태 1) Read only 2) Update 3) OLTP 3) OLTP SSL 사용여부 미사용 [ 표 15] DB 서버를위한기초자료조사결과 항목설명조사결과 시스템구축형태 1) Single System 2) HA System 3) 병렬구성 사용자수 - 전체사용자수 - 동시사용자의비율 - 동시사용자당평균질의수 (1일) - 가동시간중 Peak-time의시간 - 년간사용자증가율 1) Single System 1,000명 25% 3건 ( 분당 ) 4시간 30% 28

160 [ 표 15] DB서버를위한기초자료조사결과 ( 계속 ) 항목 설명 조사결과 트랜잭션수 - 년간트랜잭션량 사용자 1인당 - 1일평균트랜잭션량 트랜잭션수 : - Peak-time 트랜잭션량 3건 /( 분당 ) - 예상연간트랜잭션증가율 30% 온라인업무업무량 - 검색, 갱신, 삽입, 삭제별레코드크기및전체건수, 인덱스합치건수등 배치업무량 - 온라인업무에대한배치업무비중 9 : 1 - 대량배치기준으로데이터건수및길이 데이터베이스 - 데이터크기 ( 초기, 1년차, 2년차, 3년차및 3년차이후데이터증가율 ) 년간증가율 30% - 데이터 중 이미지, 사운드, 텍스트 1: 1 : 8 파일의비율 - 인덱스테이블의초기크기및 3년내크기 60% - 테이블크기의구성 평균 300K - 열의평균바이트수 450byte 데이터백업 - 데이터백업서버의운영여부 미운영 - 백업장치의접속패턴 RAID-5 - 백업데이터량 20G 운영시간 - 운영시간 (7X24) 7X24 네트워크속도 - 네트워크속도 100Mbps 5.3 용량산정예 H/W 에대한용량은서버 (WAS, DB 서버 ) 별, CPU, 메모리, 디스크를대상으로 하며, DB 서버에대해서는시스템디스크뿐만아니라백업을위한데이터디스크 에대한용량산정을아울러수행하였다. 가. CPU WAS 서버 29

161 WAS 서버의 CPU 용량을산정하기위해서는동시사용자수, 사용자당오퍼레이션수, 어플리케이션인터페이스부하보정, 피크타임부하보정, 시스템여유율등을사용하며, 세부적인산정근거와산정내용은 [ 표 16] 과같다. 한편, 시스템의안정된운영을위한보정치인시스템여유율의경우 30% 를적용하는것이일반적이나기초자료조사결과업무의긴급도및중요도가높으므로 40% 적용하여산정하였으며, 어플리케이션인터페이스부하보정, 피크타임부하보정은일반값을적용하였다. 최종적으로 WAS서버의 CPU 용량은위의산정항목을모두곱한값 (549*3*1.1*1.2*1.4) 으로약 3046ops를요구한다. [ 표 16] WAS서버의 CPU 산정근거 항목 산정근거 산정내역 동시사용자수 동시사용자 * 증가율 (30%)*3년 - 250*1.3*1.3*1.3=549명 어플리케이션인터페이스부하보정 Peak Time 부하보정시스템여유율사용자당 Operation 수 서버가타서버와통신하게 1.1 되는데이때인터페이스에서발생하는부하율로 10% 적용갑자기많은접속으로인해 1.2 부하가발생하는것을해결하기위해부하율로 20% 적용시스템의안정된운영을위한 1.4 보정치로업무의중요도및긴급도가높으므로 40% 적용사용자당 operation 수는 3 사용자한사람이분당발생시키는 3개로가정 DB 서버 DB 서버의 CPU 용량을산정하기위해서는동시사용자수, 트랜잭션처리수, 기본 tpmc 보정, Peak Time 보정, CPU 부하보정, 어플리케이션복잡도보정, 사용자복잡성보정, 어플리케이션구조보정, 어플리케이션부하보정, 네트워크보정, 클러스터보정, 여유율등을고려하는데세부적인산정근거와산정내용은 [ 표 17] 과같다. 특히, 서버의 CPU 산정결과에큰영향을미치는요소로는동시사용자수와어플리케이션복잡도보정, 사용자복잡성보정, 어플리 30

162 케이션구조보정, 어플리케이션부하보정으로동시사용자수의산정에는신중한접근필요하며, 어플리케이션복잡도보정, 사용자복잡성보정, 어플리케이션구조보정, 어플리케이션부하보정의경우적용대상업무에대한분석이선행되지않으면해당항목에대한적용이쉽지않으므로일반적인값을적용하였다. [ 표 17] DB서버의 CPU 산정근거항목 산정근거 산정내역 동시사용자수 동시사용자 * 증가율 (30%)*3년 - 250*1.3*1.3*1.3=549명 트랜잭션처리수 사용자 1인이분당발생시키는트랜잭션의수로단순작업이므로 3으로가정 3건 / 분 기본 TPMC보정 시스템규모가크기않으므로소 1.2 규모인 20% 적용 Peak Time 보정 업무가폭주하는경우고려하여 1.2 보정으로 20%( 단순 ) 적용 데이터베이스크기 일반값으로적용 1.3 보정 어플리케이션 1 복잡도보정 사용자복잡성보정 1 어플리케이션구조보정 1 어플리케이션부하보정 1 네트워크보정 네트워크대역폭으로인한지연 1.1 보완 10% 적용 클러스터보정 클러스터환경에서장애발생시를 1 위한보정이므로 1적용 여유율보정 시스템의안정된운영을위한보 1.3 정으로 30% 적용 한편, DB 서버의 CPU 용량은산정항목을모두곱한값 (549*3*1.2*1.2*1.3* 1.1* 1.3) 으로약 4408tpmC 를요구한다. 나. 메모리 31

163 메모리산정을위해서다음과같이기초자료가조사되었다고가정한다. - Windows NT Kernel : 64KB - SQL 서버데이터베이스서비스 : 256MB - Transaction 서버서비스 : 32MB - Windows NT 사용자 1인당 : 0.5MB - SQL 서버 1인당 : 0.5MB - RAID 적용 : 32MB WAS 서버 WAS 서버의메모리용량을산정하기위해서는동시사용자수, 시스템영역, 시 스템관리자영역, 사용자당필요메모리, 버퍼캐쉬, 클러스터보정, 여유율등을 계산하여야하며, 산정근거와산정내용은 [ 표 18] 와같다. [ 표 18] WAS서버의메모리산정근거항목 산정근거 산정내용 동시사용자 동시사용자 * 증가율 (30%)*3년 - 250*1.3*1.3*1.3=549명 시스템영역 OS, DBMS엔진, 미들웨어엔- 64MB + 32MB+ 32MB 진, 기타유틸리티등의소요 =128MB 공간 : 기본 OS+ 서비스 ( 트랜잭션 )+ 기타유틸리티 (RAID 포함 ) 시스템관리자영역 관리자수 *0.5MB - 0.5MB *2명 = 1MB 사용자당필요메모리 어플리케이션, 미들웨어, DBMS- 549 * 0.5MB= 274.5MB 의사용에필요한사용자당메모리 버퍼캐쉬 일반적인값 20% 로적용 1.2 클러스터보정 상대방메모리크기를고려한예 1.3 비율로 30% 적용 여유율 예기치못한상황및확장에대한여유율로 30% 적용 1.3 WAS 서버의메모리크기는 ( 시스템영역 + 관리자영역 + 사용자당필요 )* 버 퍼캐쉬 * 클러스터보정 * 여유율, 즉 ( )*1.2*1.3*1.3 로계산되며, 산 32

164 정결과 WSA 서버의시스템디스크크기는약 818MB 정도를필요로한다. 따 라서메모리확장단위를감안하여 1024 MB 로선정한다. DB 서버 WAS서버의메모리용량을산정하기위해서는동시사용자수, 시스템영역, 시스템관리자영역, 사용자당필요메모리, 버퍼캐쉬, 클러스터보정, 여유율등을계산하여야하며, 산정근거와산정내용은 [ 표 19] 와같다. 한편, WAS서버의메모리크기는 ( 시스템영역 + 관리자영역 + 사용자당필요 )* 버퍼캐쉬 * 클러스터보정 * 여유율, 즉 ( )*1.2*1.3*1.3로계산되며, 산정결과 WAS서버의시스템디스크크기는약 1,337MB 정도를필요로한다. 따라서메모리확장단위를감안하여 2,048 MB로선정한다. [ 표 19] DB서버의 CPU 산정근거항목 산정근거 산정내용 동시사용자 동시사용자 * 증가율 (30%)*3년 - 250*1.3*1.3*1.3=549명 시스템영역 OS, DBMS엔진, 미들웨어엔진,- 64MB + 288MB(32 기타유틸리티등의소요공간 : 기 본 OS+ 서비스 ( 트랜잭션및데이터 MB+256MB)+ 32MB =384MB 베이스 )+ 기타유틸리티 (RAID 포 함 ) 시스템관리자영역 관리자수 *0.5MB - 0.5MB *2명 = 1MB 사용자당필요메모리 DBMS의사용에필요한사용자당- 549 * 0.5MB= 274.5MB 메모리로사용자 *DB필요메모리로 산출 버퍼캐쉬 일반적인값 20% 로적용 1.2 클러스터보정 상대방메모리크기를고려한예비1.3 율로 30% 적용 여유율 예기치못한상황및확장에대1.3 한여유율로 30% 적용 33

165 다. 디스크 데이터베이스서버의디스크는시스템디스크와데이터디스크로나누어산정 한다. WAS 서버 WAS 서버의시스템디스크를용량산정항목과산정근거, 산정내역은 [ 표 20] 과같다. WAS서버의시스템디스크의크기는 ( 시스템OS 영역 + 응용프로그램영역 + SWAP 영역 )* 여유율, 즉 (500+1,000+2,048)*1.3로계산되며산정결과 WAS서버의시스템디스크크기는약 4.6GB 정도를필요로한다. [ 표 20] WAS서버의시스템디스크산정근거 항목 산정근거 산정내역 시스템 OS 영역 WindowNT 500MB 응용프로그램영역 응용프로그램 1GB SWAP 영역 서버메모리의 2배적용 2,048MB 여유율 성능향상공간 30% 적용 1.3 DB 서버 - 시스템디스크 데이터베이스서버의시스템디스크용량산정항목과산정근거, 산정내역 은다음의표와같다. [ 표 21] DB서버의시스템디스크산정근거 항목 산정근거 산정내역 시스템OS 영역 WindowNT 500M 응용S/W 영역 DBMS 1GB SWAP 영역 서버메모리의 2배적용 4,096MB 여유율 성능향상공간 30% 적용

166 데이터베이스서버의시스템디스크의크기는 ( 시스템OS 영역 + 응용S/W영역 + SWAP 영역 )* 여유율, 즉 (500+1,000+4,096)*1.3로계산되며산정결과데이터베이스서버의시스템디스크크기는약 7.2GB 정도를필요로한다. - 데이터디스크 데이터베이스서버의데이터디스크를용량산정항목과산정근거, 산정내역은 [ 표 22] 와같다. 한편데이터베이스서버의데이터디스크의크기는 (DB영역 + 백업영역 )*RAID영역* 여유율, 즉 11,102MB*1.2*1.3로계산되며, 산정결과데이터베이스서버의시스템디스크크기는약 17.3GB 정도를필요로한다. [ 표 22] DB서버의데이터디스크산정근거 항목 산정근거 산정내역 DB 영역 - 실자료공간 ( 건수 * 건수별 - 실자료건수 : 9,887건 / 일 데이터사이즈 * 보관기간 ) *0.5K*30일*12월*3년 - 예비용 데이터 공간 ( 실 = 5,338MB 데이터공간의 30%) - 인덱스및키용실데이터 - 예비용데이터공간 : 5,338MB*0.3 = 1,601MB 공간 (1+2의 60%) - 인덱스 및 키용 실 데이터공간 :(5,338MB+1,601MB) *0.6 =4,163MB - DB 영역 : 5,338MB+ 1,601MB + 4,163MB = 11,102MB RAID 영역 RAID-5적용 1.2 여유율 성능향상공간 30% 적용

167 5. 4 Excel 계산식 서버의용량산정을보다간단히수행해볼수있도록작성한 Excel 계산식은앞 서제시된기준안을적용하여 CPU 와 Memory 의용량산정 Excel 계산식을만들게 되었다. 제시된 EXCEL계산식에서의산정대상은 CPU(OLTP, WAS/WEB), 메모리, 디스크등으로구분하고있으며세부적인산정식은 [ 그림4] ~ [ 그림 7] 에서와같다. 각각의산정대상에서입력값에해당하는각셀당도움말을제공하고있으며, 입력값이변경됨에따라자동으로값들이산출되도록구성되어있다. [ 그림 4] OLTP 서버의용량산정화면 36

168 [ 그림 5] WEB/WAS 서버의용량산정화면 [ 그림 6] 메모리용량산정화면 [ 그림 7] 디스크용량산정화면 37