[지디넷코리아]인터넷 환경에서 폭발적으로 증가된 사용자의 수는 기업에 기회와 위기를 동시에 안겨주게 되었다. 기회는 온라인 시장(Online Market)이란 새로운 시장이 생겨났다는 것이다. Amazon, E-bay, Yahoo등과 같은 기업들은 새로운 시장에서 고수익을 창출하고 있다.

이전까지 시스템의 존재가 사업을 지원하는 성격에서인터넷을 결합하여 새로운 사업유형 자체로서 진화하였다. 위기는 폭발적으로 증가된 사용자에게 안정적인 서비스를 제공할 수 있어야 하는데 실제적으로 많은 어려움이 따른다는 것이다.

Online Market을 기반으로 하는 기업에서는 시스템의 안정적인운영이야 말로 기업의 생존을 가능하게 하는 최소한의 조건이다. 이런 가운데 자연스럽게 시스템의 안정적인 운영을 판정하는 성능테스트 및 부하테스트의 중요성이 더욱 더 부각되기 시작하였다.

현재는 LG CNS등 대기업을 중심으로 성능테스트를 전담으로 수행하는 전문팀을 운영하고 있으며, 성능결함이나 리스크를 미리 식별하여 제거함으로써 안정적인 시스템의 오픈을 보장할 수 있는 품질활동이 꾸준히 수행되고 있다.

성능테스트가 의미하는 것
TTA용어 사전에 따르면 성능테스트란 개발된 시스템이나 시스템 구성요소(component) 또는 소프트웨어 프로그램이 주어진 환경 하에서 응답속도, 처리량, 처리속도 등의 항목에 대하여 요구되어진 목표치를 달성하는지를 확인하는 시험이다.

일반적으로 성능테스트는 통합테스트가 완료되고, H/W, 애플리케이션 (Application), 아키텍처 (Architecture) 등 모든 구성요소들이 통합된 후, 오픈 직전의 운영환경과 동일한 환경에서 수행되는 최종성격의 테스트이다.

즉 운영환경에서 발생이 예상되는 부하를 시스템에 적용하였을 때, 고객이 요구한 목표 성능을 달성하는지를 확인하고, 성능이 미달하는 경우 그 원인 및 병목구간을 파악하는 테스트이다. 성능테스트는 앞서 기술한 바와 같이 그 중요성이 커지고 있는 반면, 수행이 쉽지 않다는 특성을 가지고 있다.

우선 성능에 영향을 미치는 요소가 상당히 많고 다양하다.

어떤 서버(CPU, Memory, Disk) 사양을 선택하였는지, 그 위에 어떤 아키텍처(OS, Web서버, WAS, DB)를 채택하였는지, 애플리케이션을 어떻게 구현하였는지, 각종 파라미터 (Parameter)를 어떻게 설정하였는지, 부하를 어떤 방식으로 발생시키는지, 주위 시스템들과의 인터페이스 (Interface), 데이터의 양 등에 따라 성능테스트 및 결과에 지대한 영향을 미친다.

또한 성능테스트를 수행시 적절한 가정 및 시나리오를 수립하지 않으면, 이에 따라 성능테스트의 품질 및 비용에 많은 차이를 나타낸다.

성능테스트 수행은 리얼환경을 모델로 테스트를 수행하기 때문에, 많은 가정과 제약사항이 발생하게 마련이다. 특히 많은 가정과 제약사항이 발생하는 부분은 대상업무(Application)의 선정 및 부하량(Workload)산정이다.

본 글에서는 우선 성능테스트 수행시 측정대상업무(Application)를 선정하는 방안을 집중적으로 고찰해 보며, 부하량의 선정에 대한 글은 추후에 준비할 예정이다.

성능테스트 대상업무의 선정
성능테스트에서 대상업무의 선정이 중요한 이유는 시스템의 모든 변수가 고정 (Fix) 되었다고 가정하였을 때, 성능테스트 대상업무가 얼마나 시스템 전체를 대표할 수 있는 업무가 선정되느냐에 따라 성능테스트의 결과는 천차만별로 차이가 날 수 있기 때문이다. 즉, 명확한 기준을 가지고 업무를 선정하지 않는 경우는 성능테스트의 신뢰성이 크게 저하된다.

시스템의 전체업무(혹은 대상화면)가 적은 경우는 대상업무 선정에 크게 문제가 되지는 않는다. 적은 경우는 대부분의 업무를 대상으로 선정하여도 크게 무리가 가지 않는다.

그러나 대상업무가 1,000개 이상 되는 대형 시스템인 경우 과연 어떤 기준으로 몇 개의 업무를 대상으로 성능테스트를 수행해야 하는지 고민하게 된다.

고객의 입장에서는 성능테스트의 대상업무도 단위 테스트와 같이 모든 업무를 대상으로 하고 싶기도 하겠지만, 전체 업무를 대상으로 수행하는 경우 발생하는 비용과 일정의 지연은 고객 입장에서도 쉽게 받아들이기는 어렵다.

효율적이고 효과적으로 대상을 선정하기 위해서는 Pareto의 법칙(80/20법칙)에 따라 적절한 기준을 가지고 샘플링 (Sampling)을 해야 한다. 그럼 어떤 구체적인 기준을 가지고, 업무를 선정할 것인가? 선정기준을 논하기 위해 우선 성능테스트의 특성을 알아보면 도움이 될 것이다.

성능테스트는 크게 3가지의 특성을 가지고 있다.

첫째, 고객의 요구사항을 중심으로 테스트가 수행된다. 즉 성능테스트에서 고객이 자신들의 비즈니스를 수행하는데 시스템의 성능이 충분하다는 것을 확신할 수 있어야 한다.

둘째, 성능테스트는 단위나 통합과 같은 기능중심의 테스트가 아닌 비기능 중심의 테스트이다. 즉, 기능적으로 중요한 업무라고 해서 선택이 되는 것이 아니라, 비록 기능적으로 크게 중요하지 않다고 해도 시스템 전체적인 성능에 영향을 미칠 수 있는 업무는 대상으로 선정이 되어야 한다.

셋째는 100% 통합된 시스템 환경에서 테스트를 실시한다. H/W, 아키텍처, 애플리케이션 등이 모두 통합된 환경이며, 이들 구성원들이 통합되어 적정한 성능을 나타내고 있다는 것을 확인해야 한다.

위와 같은 특성을 반영하여 선정기준을 나타내면 크게 3가지 관점으로 볼 수 있다.

첫째는 고객의 비즈니스 관점, 둘째는 애플리케이션 관점, 셋째는 아키텍처 관점이다. 고객의 비즈니스 관점에서 제일 먼저 고려해야 할 선정기준은 대상업무의 사용빈도이다. 즉 많은 사용자가 사용하는 업무로 은행의 예를 들면 출금과 같은 업무로 많은 사용자가 전국에서 동시에 자주 사용하는 업무이다.

이와 같이 많은 트랜잭션(Transaction)을 발생시키는 업무를 선정하는 것이 필요하며, 여기에서 한 가지를 더 고려해야 할 것은 사용빈도가 일정한 것 보다는 사용빈도가 피크(Peak)시 몰리는 경향의 업무를 우선적으로 선택해야 한다는 것이다.

대부분의 시스템은 업무의 특성에 따라 고유의 피크 시간 (Peak Time)이 있고 피크의 주기와 집중도는 시스템마다 다양하다.

제조실행시스템(MES: Manufacturing Execution System)은 생산라인에서 일정하게 트랜잭션이 발생하여 피크가 거의 없지만, 철도청의 승차권 발매시스템은 주말에 주기적으로 피크를 발생시키며, 특히 구정과 추석에는 폭발적인 량의 트랜잭션이 발생한다.

사용빈도가 많이 발생하는 업무 중 피크시 사용빈도가 높은 업무는 반드시 성능테스트 대상 업무로 지정하여 성능을 검증해야 한다.

A은행의 예를 들어 사용빈도 기준으로 분석하면, A은행에서는 2004년 4월 한달간 약 2,400여개의 업무가 발생하였으며, 총 거래건수는 약 1억건이 발생하였다.

[그림1] A은행 시간별 거래 발생 추이 (X축:시간, Y축:거래건수(단위: 천))

피크 시간을 분석한 결과 [그림1]에서 보여주는 바와 같이 오후4시경에 피크 시간이 발생하며, 이때의 거래발생종류 및 건수를 분석한 결과 [그림2]와 같이 Pareto의 법칙과 유사한 형태의 그림을 나타내고 있다.

[그림2] A은행 상위 32개업무의 발생 비율 및 누적비율 (X축:업무, Y축:발생비율 및 누적발생비율)

또한 거래 발생비율별로 업무수 및 비율을 분석한 결과 아래 표와 같이 업무비율로 볼 때 1%이상의 거래발생 비율을 갖는 업무는 전체 약 2,458건의 업무 중 15건에 불과했으나, 발생건수는 전체의 절반에 가까운 47%를 나타내고 있다. 0.5%이상의 거래는 37개로 전체거래의 1.5%에 불과하나, 발생건수는 전체의 57%에 달한다.

여기서 대상업무의 범위를 발생빈도에 따라 어디까지 선정할 것인가에 대해서 절대적으로 정의할 수는 없다.

[표1] A은행의 거래발생별업무수 추이

발생누적건수의 약 80%를 기준으로 하는 경우약 127개의 업무를 대상으로 성능테스트를 실시하게 된다. 거래발생비율을 기준으로 0.5%이상의 업무를 대상으로 하는 경우37개의 업무를 대상으로 성능테스트를 실시한다. 범위를 어느 선까지 할지는 시스템의 특성, Criticality, 비용 및 개발일정에 따라 적절히 결정해야 한다.

애플리케이션 관점에서의 선정기준
애플리케이션 관점에서 고려해야 할 선정기준은 애플리케이션 구성의 복잡성이다. 구성이 복잡한 업무는 로직의 구성이 복잡해지면서, 많은 부하를 발생시킬 수 있다.

특히 로직의 복잡성이 증가함에 따라 결함이 생길 수 있는 확률이 증가하며, 결함이 생기는 경우 불필요한 로직이 수행되거나, 무한 루프가 실행되면서 불필요한 부하를 발생시킬 수 있다. 또 고려되어야 할 기준은 많은량의 데이터를 생성시키거나, 업데이트 (Update)하는 업무이다.

이런 업무들은 DB에 많은 부하를 주기 때문에, 시스템 전체적으로 성능의 저하를 일으킬 수 있기 때문에 반드시 고려되어야 한다.

예를 들면 LDC 패널 (Panel)을 생산하는 MES시스템에서 하나의 Lot이 150개의 Cell로 이루어져 있다. 초기에 Cell정보가 생성되는 업무인 경우 1개의 Lot이 입력되고, 150개의 Cell의 정보가 한번에 생성되기 때문에 DB에 150개의 입력 (Insert)작업이 수행된다.

이와 같은 작업은 시스템 전체적으로 성능에 영향을 미칠 수 있기 때문에 역시 고려가 되어야 한다.

애플리케이션 관점에서 하나 더 고려해야 할 것은, 네트워크 (Network)에 부하를 많이 발생시키는 업무이다. B물류시스템은 업무와 관련하여 많은 량의 코드 및 컴포넌트 (Component)들을 로컬 (Local)의 클라이언트 PC에 저장하여 사용하는 특성을 가지고 있다.

[그림3] B물류시스템의 응답시간 지연현상

이 코드와 컴포넌트들은 주기적으로 업데이트가 일어나며, 클라이언트 PC에서는 시스템에 Login시 클라이언트 PC내의 버전이 최신버전 인지를 확인하고 아닌 경우, 최신 버전의 컴포넌트를 다운 받게 되어있다.

이 컴포넌트들의 사이즈가 약 1M 바이트이며, 네트워크의 대역폭(Bandwidth)은 2M bps로 로그인 수행시 많은 네트워크의 부하가 발생하였다. 이 경우 1M byte의 컴포넌트를 다운로드 받는 데 약 5초가 소요되며, 동시에 3명이 함께 로그인을 하는 경우는 15초까지 응답시간이 증가된다.

이때 한 네트워크에서 작업을 하는 일반 업무 수행자는 비록 본인이 주고받는 데이터량이 100K 바이트(혼자 사용시 응답시간 0.5초)로 크지 않다고 해도, 다른 3명의 사용자에 의해 영향을 받아 응답시간이 15초까지 함께 증가할 수가 있다. 이는 각 사용자의 데이터가 전송시 패킷(Packet)으로 나누어져 순서가 섞여서 전송되는 특성이 있기 때문이다.

즉, 네트워크에 부하를 주는 업무는 병목을 유발시키면서 다른 사용자의 응답속도를 급격히 증가하는 등 전체적인 시스템 성능에 영향을 미치는 상황이 발생할 수 있다.

[그림4] C물류 시스템 아키텍처 구성도

아키텍처 관점에서의 선정기준
마지막으로 아키텍처 관점에서 선정기준으로 고려해야 할 사항은 부하경로를 모두 검증할 수 있도록 업무를 선정해야 한다는 것이다.

위 그림은 C물류 시스템의 아키텍처 구성도를 나타낸 것으로 사용자는 크게 물류시스템사용자, WMS(Warehouse Management System) 사용자, 운영자, 외부시스템 인터페이스(Interface)이며, 물류시스템은 내부, 외부로 사용자의 위치에 따라 부하경로가 분리되어 있다.

C물류의 시스템 부하경로를 분석하면, 아래와 같이 10개의 부하전달 경로를 발견할 수 있다. 발생빈도를 측정한 결과 물류시스템의 트랜잭션 90%를 내부사용자가 발생시킨다.

[표2] C물류 시스템 부하경로

이 경우 부하는 ③이나 ④로 집중이 된다. 발생빈도를 기준으로 업무를 선정하는 경우 빈도가 적은 ①은 배재가 되나, ①의 경로인 [4]->[9]->[16]상의 아키텍처 성능을 검증해야 하기 때문에 발생빈도가 적을지라도 대상에 포함시켜야 한다.

예를 들어 [9]->[16]번 사이의 Weblogic이 잘못 설정되어 사용을 하지 않는 경우에도 DB Connection을 일정량 유지하여 [12],[13]의 원활한 DB Connection을 방해할 수 있으며, 이는 내부사용자들의 응답속도를 증가시키거나, 트랜잭션의 Fail을 발생 시킬 수 있다.

그렇기 때문에 구간별로 병목이 없는지 모든 부하경로가 검증 될 수 있도록 업무가 선정되어야 한다. 또한 하나의 경로 안에서도 업무가 세분화가 되는 경우는 세분화 시켜서 업무를 선정해야 한다.

예를 들면 [2]->[5]->[10]->[12]의 경우, Web화면에서 DB를 사용하는 경우 [2]부터[12]까지 부하가 전달되지만, Web화면에서 간단한 Image만을 끌어오는 경우는 Web Server인 iPlanet까지만 부하가 전달된다. 그렇기 때문에 ③, ⑤이 각각 분리되어 테스트를 수행할 필요가 있다.

이와 같이 부하구간별로 세분화하여 테스트를 수행하면, 문제가 발생하는 경우 병목 및 원인 파악이 용이하기 때문에 문제 해결시간을 단축할 수 있다. 비록 일반사용자가 실행시키는 업무는 아니지만 부하경로 중 잊지 말아야 할 것이 두개 더 있는데 첫번째가 Batch작업이다.

Batch는 주로 야간에 수행이 되지만, 업무의 특성에 따라 주간에도 수행되는 경우가 있다. 특히 Batch Job은 대량의 Data를 처리해 부하를 많이 발생시키기 때문에 주간에 수행되는 Batch Job은 업무 선정에 반드시 고려가 되어야 한다. 두번째는 외부시스템에서 발생시키는 작업이다.

최근 EAI(Enterprise Application Integration)를 통해 외부 Interface를 전달하는 경우가 많으며, 트랜잭션을 발생시키는 경우와 단순히 DB에 Insert 및 Update를 수행하는 경우로 크게 나눌 수 있다. 이 두 경우 모두 대량의 부하를 발생시키기 때문에 반드시 고려가 되어야 한다.

이제까지 언급한 성능테스트 대상업무 선정시 고려해야 하는 기준을 정리하면, 아래와 같다.

1. 사용빈도가 높은 업무를 선정한다.
2. 특정시간(Peak)에 많이 사용되는 업무를 선정한다.
3. 업무 Logic이 길고 복잡한 업무를 선정에 고려한다.
4. 많은 량의 Data를 발생시키거나, Update하는 업무를 선정에 고려한다.
5. Network에 많은 부하를 발생시키는 업무를 선정에 고려한다.
6. 아키텍처 구성상의 부하경로를 모두 검증할 수 있도록 업무를 선정한다.
7. Online의 성능에 영향을 줄 수 있는 Batch업무를 선정에 고려한다.

성능테스트와 신뢰성
위와 같은 기준을 가지고 대상업무를 선정하다 보면 대상업무의 수가 계속 늘어나는 것을 발견할 수 있다. 대상업무의 개수가 늘어나면, 성능테스트의 결과에 대한 신뢰성이 증가하게 된다.

그러나 대상업무가 늘어남에 따라 테스트 비용 및 소요시간도 함께 늘어나게 된다. 아래 그래프는 성능테스트 대상이 증가함에 따라 성능테스트 기간, 비용의 증가 추이 및 이에 따른 Coverage증가를 함께 나타내고 있다.

[그림5] 대상거래의 증가에 따른 성능테스트 비용 및 일정증가 (X:대상업무(거래)개수, Y:소요일, 비용(백만원), COVERAGE)

성능테스트 수행시 성능테스트 툴을 사용한다는 가정하에 대상거래가 증가함에 따라 스크립트작성을 위해 일정시간(숙련된 테스터라는 가정하에 각 4시간)이 소요된다.

또한 테스트 시나리오나 테스트 케이스를 작성할 때 대상거래가 증가함에 따라 복잡성이 증가하며, 수행시간 역시 대상 업무를 모두 수행시키기 위해 일정 시간 증가하게 된다.

마지막으로 수행결과를 분석하는 데에도 복잡성의 증가로 인하여 시간이 증가하게 된다. 대상업무가 증가됨에 따라 10개의 업무를 대상으로 수행하는데 12일이 소요된 반면 200개의 업무를 대상으로 테스트를 수행하는 경우 154일이 소요되는 것으로 나타났다.

비용은 순수인건비(30만원/일)만을 반영하여 계산한 결과 10개를 대상으로 수행하는 경우 약 400만원이 소요되는 반면 200개를 대상으로 수행하는 경우 4,600만원의 비용이 추가로 투입되어야 한다.

그러나 10개의 업무가 전체 발생건수의 35%를 Cover하는 반면, 10개가 추가되면 11%추가, 그 다음 10개는 6%추가로 점점 Coverage Rate증가율은 떨어지는 것으로 나타났다.

즉, 너무 많은 대상업무는 비용대비 효과가 점점 떨어지기 때문에 적정한 선에서 대상업무 개수를 정해야 한다.

[그림6]Testing Cost Curve

[그림6]은 테스팅 비용곡선으로 테스팅 비용이 너무 낮으면, “Under” 테스트 수행으로 시스템의 실패 확율이 높아지면서 실패비용이 증가하게 되고, 너무 높게 테스팅 비용을 사용하는 경우는 “Over” 테스트로 불필요하게 테스팅 비용이 지출되게 된다.

손익분기점 (Break-Even Point)를 감안하여 대상거래의 개수를 적절하게 결정하는 것이 매우 중요하다. 그러나 쉽지않기 때문에 테스트 전문가의 냉철한 판단이 꼭 필요하다. @

참고문헌
[1] 한국인터넷백서, 2002년 정보통신부
[2] 2004년 국가 정보화 보고서, 2004년 정보통신부
[3] 한국정보통신 산업협회, 2004년 정보통신산업통계자료
[4] TTA 용어사전

이 글은 STA에서 발간하는 STEN Journal 2006 Vol. IV에서 자료를 제공하였습니다.