성능 테스트 기법 (5) Estimating Concurrent Users
Updated:
이번 글에서는 Project의 성능 목표 수립 과정에서, 동시사용자(Concurrent User) 산정 시 알아두면 좋을 개념들과 각각의 연관관계, 그리고 간단한 도출 기법 등에 대해 정리해 보고자 합니다.
혹시, 성능 목표와 관련한 정확한 정의 및 용어, 프로세스, 도출 기법 등 Performance Engineering 전반적인 개념에 대해 궁금하셨다면, 홍성진Manager님(올해 6월부로 SK(주) C&C의 직급이 모두 Manager로 단일화 되었습니다.^^)의 “Introduce to Performance test” 1~3편을 숙독하시면 많은 도움이 되실 겁니다.
1. 동시 사용자에 대한 초창기 인식
SK(주) C&C에서 처음 성능 테스트를 시작했던 시점은 2004년입니다. LoadRunner를 도입하고, Tool에 대한 기본적인 사용법을 교육받은 후, 다음과 같은 기준으로 전사공지를 하고 지원을 시작하였습니다.
2004년 전사 성능 테스트 지원 기준(예시)
- 성능 테스트 도구: LoadRunner 7.8
- 무상 License 지원: 최대 300VUD(Virtual User Day)
- 300명 초과 라이선스는 1VUD당 1만원 PJT 부과
- 지원 기간: 1주(5일)
- 계획 1일, 설계 2일, 수행 1일, 결과작성/보고 1일
전사 차원의 성능 테스트 활성화를 위해서 R&D센터에서 사전 대량구매/보유하고 있던 소진성 LoadRunner VUD License를 최대 300VUD까지는 무상으로 지원하고자 했던 것인데, 대부분의 Project 반응은 “동시사용자 300명으로 성능 테스트 해주세요”였으며, 이것이 초창기의 성능 요구사항이기도 했습니다.
부하가 거의 없는 시스템이지만 성능 테스트 수행 결과에 대한 증빙(?)이 필요한 경우나, 고객 요구에 의해 임계 수준의 최대부하까지 발생시켜보고 싶은 경우에도 모두 ‘300VUD’를 요구했기 때문에, Project 투입 시점에 Workload Model에 기반한 ‘합리적인 수준’의 동시사용자수(Concurrent User) 산정 작업은, 총 5일간의 짧은 지원 일정 속에서도 성능 테스트 수행에 있어 중요한 기준이 될 수 밖에 없었습니다.
2. Project에서 동시사용자 수에 민감한 이유
지원 초창기의 시범적용 기간이 끝나고, VUD License 및 성능 전문인력에 대한 비용 부과가 시작된 이후부터 현재까지도, Vuser License에 대한 Project의 부담은 여전히 표출되고 있습니다. 고객이 LoadRunner Permanent(perpetual) License를 기보유하고 있는 경우에는 비용 부담없이 성능 테스트 인력만으로 진행이 가능하지만, 그렇지 않은 경우에는 Project 자체에서 License 구입이 필요하기 때문입니다.
고객사가 다양한 SI 회사의 경우, 선택 가능한 Vuser License 유형은 1) 24시간 제한으로 사용 가능한 VUD(Virtual User Days)와 2) 한달(또는 세달) 등의 기간 제한으로 사용 가능한 Term License 등이 있습니다.
1) VUD License
예를들어 1VUD당 비용이 1만원이라고 가정하면, 1,000VUD를 구매하기 위해서는 1천만원(1,000VUD x 10,000원)이 듭니다.(여기서의 기준 가격은 예시를 위한 것으로, 정확한 비용은 관련 업체 문의 필요) 앞서 말씀드린대로 VUD는 1일 소진성 License인 관계로, LoadRunner에서 1,000VUD에 대한 사용을 시작하였다면 해당 시점부터 24시간이 경과한 후에는 더 이상 쓸 수 없습니다.(단, 24시간 이내에서의 반복 수행횟수는 제한없음)
참고로, VUD License의 소진 방식에 대한 구체적인 이해를 돕기 위해, Micro Focus에서 제공하는 VUD 사용 Case별 설명을 아래와 같이 덧붙입니다.
Micro Focus > 지원 및 서비스 > 기술자료
What is a VUD license? and how does it work?
Answer: VUD라는 용어는 Virtual User Day를 의미합니다. Vuser수와 실행일 수의 곱은 VUD 수를 초과 할 수 없습니다.
예를 들어 총 2,000VUD License가 있는 경우:
1월 15일에 vuser 100명을 n번,
1월 16일에 vuser 200명을 n번,
1월 17일에 vuser 200명을 n번 실행했다면
1일 * 100VUD + 2일 * 200VUD = 500VUD를 사용한 것입니다.
만약, 하루에 2,000개의 Vuser를 n번 실행했다면, 하루가 지나면 VUD가 남아있지 않습니다.
Source: Micro Focus
2) 비용 발생 vs. 미발생 요소
참고로, LoadRunner는 아래와 같이 총 3개의 구성요소로 이루어져 있습니다.
- VuGen(Virtual user Generator): Script 작성
- Controller: Vuser 기반 부하발생, 모니터링, 결과수집 등
- Analysis: 수집된 결과 분석 편집 및 리포팅
다행히(?) LoadRunner Tool 자체는 LoadRunner 12.60 Community Edition 등을 다운로드 받은 후, 50Vuser 한도 내에서 모든 기능을 사용해 볼 수 있으며, 사용시 비용이 발생하지 않습니다.(단, Trial Version으로 공식 결과보고 작성 목적의 비즈니스 용도 사용은 제한하고 있음)
Script를 작성하고, 정상부하 발생여부 확인을 위해 몇명의 Vuser를 할당하여 돌려보고, 결과를 분석해서 리포팅하는 성능 테스트 대부분의 기간에서는 비용이 발생하지 않을 수 있습니다. 하지만, 실제 성능 테스트를 수행하는 당일에는, 목표 부하 발생을 위해 구입한 VUD License를 등록하여 사용하는 순간, 바로 VUD의 1일치 비용 발생이 확정되기 때문에, 비용에 대한 Project의 부담은 더 크게 느껴질 수 밖에 없다고 봅니다. (“License 하루 사용하는데 1천만원이 든다구요?”)
다행인 것은, 최근 자동화 도구들의 Cloud로의 전환 추세에 맞추어, LoadRunner에서도 ‘사용한 시간’ 만큼만 지불하는 방식의 Cloud기반 서비스를 제공하고 있다는 점이며, 기존의 VUD보다는 사용자 입장에서 보다 합리적인 방식의 부과 기준으로 점차 개선되고 있다고 보여집니다.
3. Virtual User와 동시 사용자간의 관계
위에서 살펴봤듯이 소진성 또는 Term License에 대한 비용부담 때문에, 성능 테스트 Tool에서 부하발생을 위해 필요한 Virtual User License의 구매 비용은 최소화하면서도, 부하 발생 효과는 최대화하고 싶어하는 것이 Project의 입장임을 알 수 있습니다. 하지만, 이러한 접근이 가능하기 위해서는, Virtual User를 통해 최대 어느 수준까지 부하 발생이 가능한지, 그리고 이에따른 제약사항은 어떤 것들이 있는지 등에 대해, Project 구성원들도 관련 개념들을 한번 정리해 볼 필요가 있습니다.
이해를 돕기 위해, 최근 성능 테스트 계획 수립시 목표 부하 설정과 관련하여, Project 인터뷰 시 전달받은 요구사항들을 살펴보도록 하겠습니다.
A Project - B 온라인 쇼핑몰 구축
고객 요구사항: “현재 우리가 구축하는 시스템은 외국인들의 구매를 위한 접속이 집중적으로 발생합니다. Peak 시점의 부하 수준은 COVID-19 이전 APM 기록을 기준으로 1,500TPS 정도까지 확인했으며, 성능 테스트 수행시 발생 부하도 APM 측정 기준으로 동일 수준의 부하 발생을 원합니다.”
Project 요구사항: “여러차례 성능 테스트 수행이 필요하기 때문에, LoadRunner License를 일회성 VUD로 구매하기는 어려울 것 같아서, 1달 사용이 가능한 Term License로 500Vuser를 구매했습니다.”
“고객 요구 부하 수준은 COVID-19 이전 수준의 Peak 시점인데, COVID-19 이후 사용자 감소를 고려해서 최초 제안사양 대비 시스템 수준을 30% 줄여 구성하는 것으로 고객이 이미 결정해 놓은 상황입니다.”
“COVID-19 이슈로 Open 후 부하가 많지 않을 것으로 예상되지만, 고객이 요구하는 APM 기준 1,500 TPS까지는 부하 발생이 필요합니다.”
이후 추가자료 요청 내역: 1,500TPS Peak 시점 Transaction Log(확인결과 미존재), 최근 Peak 시점 WEB Server Access Log, 성능 테스트 대상업무 선정, 목표 응답시간 및 부하비율 할당, Architecture 구성도 등
Project의 성능 Tool 적용 관련 요구사항을 종합해 보면, 500Vuser로 부하 발생을 하되, APM 기준으로는 1,500TPS가 나오도록 해달라는 것인데 이것은 어떤 의미로 해석하고 산정해야 할까요?
1) Vuser(Virtual User)의 의미
우선, Vuser 500명의 License를 구입하여 사용한다는 것은 어떤 의미인지 생각해 볼 필요가 있습니다. 이해를 돕기 위해 Micro Focus의 LoadRunner Vuser에 대한 설명을 잠시 확인해 보겠습니다.
About Vuser scripts
Overview: 성능 테스트를 수행하거나 모니터링할 때, 시스템에서 사용자의 실제 동작을 모방(Emulation)해야 합니다. Micro Focus 테스트 도구는 사용자가 시스템에서 동시에 작업하거나 시스템에 접속하는 환경을 Emulate합니다.
이 Emulation을 수행하기 위한 사람은 Virtual User(Vuser)로 대체됩니다. Vuser가 수행하는 작업은 일반적으로 Vuser Script에 기록됩니다.
Vuser Technology: VuGen(Virtual user Generator)을 사용하여, Client 애플리케이션에서 일반적인 비즈니스 프로세스를 수행하는 사용자를 기록함으로, Vuser Script를 개발할 수 있습니다. VuGen은 세션을 레코딩하는 동안 수행한 작업을 기록하는데, Client와 Server 간의 작업만 기록합니다.
VuGen은 Vuser Script를 기록 할뿐만 아니라 재생하기도합니다. VuGen에서 Script를 재생하는 것은 디버깅에 유용합니다. Vuser가 Server와 직접 통신할 때, Client Interface에 대한 시스템 자원은 필요하지 않습니다. 이를 통해 단일 Workstation에서 동시에 많은 수의 Vuser를 실행할 수 있으며, 몇 대의 테스트 머신만 사용하여 대규모 서버 부하를 Emulation할 수 있습니다.
Script를 통합하는 여러 Micro Focus제품에서 Vuser Script를 사용할 수 있는데, 한가지 방법은 LoadRunner Controller를 사용하여 시나리오에 추가하는 것 입니다. Controller에서 Vuser를 실행하는 동안 시스템의 응답에 대한 정보를 수집합니다. 테스트 실행 후 Analysis 도구를 사용하여 정보를 확인할 수 있습니다.
예를 들어, 100 명의 Vuser가 은행 ATM에서 동시에 현금을 인출 할 때, 서버가 어떻게 작동하는지 관찰 할 수 있습니다. 자세한 내용은 LoadRunner Controller Overview를 참조하십시오 .
우리가 Tech Blog에서 그동안 다뤄왔던 Script를 작성하는 과정은, Vuser가 다수의 사용자를 모방하여 부하를 발생하기 위해 필요한 준비 과정임을 위의 설명을 통해 이해할 수 있습니다. 다시 말하면, Virtual User는 사람을 대신하여 부하를 발생시키는 역할을 담당하는데, 이때 성능 테스트 대상 업무별로 작성된 Script를 사용하게 됩니다.
2) Vuser와 TPS의 관계
우리가 다음으로 살펴볼 것은 Vuser와 TPS가 어떤 연관관계에 있는지에 대한 것입니다. Project를 방문해 보면 의외로 해당 개념에 대해 이해하기 힘들다는 분들이 계셔서, 그림을 그려가며 설명을 해드리는 경우가 종종 있습니다.
우선 Vuser가 사용하는 자동화 Script 작성을 위해서는, Workload Modeling 과정(참고 글. Introduce to Performance test(3/5))에서 분석한 자료를 기반으로 ‘목표 TPS’를 산출하고, ‘대상 업무를 선정’하는 과정이 필요합니다. 고객과 개발팀의 대상업무 검토 및 합의과정을 통해, 성능 테스트 대상업무의 선정 및 각 업무별 부하비율이 결정되었다면, 성능 테스트 담당자는 해당 결과를 전달받아 Script 및 설계에 반영하게 됩니다.
하지만, 아직 ‘목표 TPS’가 산출되지 않은 시점이라도, Project에서 보유하고 있는 500Vuser를 가지고 어느정도의 TPS까지 발생시킬 수 있는 것인지 자체적으로 계산해 볼 수 있는데, 그 방법에 대해 간단히 설명해 보겠습니다.
예를 들어, 고객과 개발팀이 10개의 성능 테스트 대상업무(ex. 메인화면, 로그인,…)를 선정하였고, 각 업무별로 비율(ex. 검색 20%, 구매 5%, …)을 할당하여, 목표 응답시간(ex. 3초)과 함께 그 기준을 Project팀에 전달해 왔다고 가정해 보겠습니다.
해당 정보들만 가지고도, 500Vuser가 각 업무별로 어떻게 할당되는지, 할당된 Vuser는 어느정도의 TPS를 발생시킬 수 있는지, 그리고 각 업무들은 일정시간(ex. 10분)동안 얼마만큼의 건수를 처리해 내는지 등에 대해 미리 계산해 볼 수 있습니다.
부하레벨(Vuser 할당) 계산:
전체 업무 중 ‘메인화면’의 업무비율이 15%로 결정되었다면, 500Vuser의 15%인 75명의 가상 사용자를 ‘메인화면’ 업무에 할당하여 부하를 발생시키게 됩니다.
TPS 계산:
‘메인화면’ 업무의 목표 응답시간이 3초로 결정되었다면, 해당 처리량만큼의 부하를 발생하기 위해 (할당된) 75Vuser를 가지고 3초 단위의 서비스 요청 간격으로 ‘메인화면’에 부하를 주도록 설정할 수 있습니다.
이 조건을 기준으로 TPS를 계산해 보면, 동시사용자 75Vuser ÷ 목표 응답시간 3초 = 25TPS가 됩니다. 이러한 방식으로, 나머지 9개의 업무에 대해서도 TPS를 계산해보면, 해당 조건 하에서 500Vuser(서비스 요청 간격: 3초)로 발생시킬 수 있는 전체 TPS는 166.7TPS가 됩니다.
처리건수(10분) 계산:
‘메인화면’의 TPS는 초당 25건 처리하는 것으로 계산되었기 때문에, 10분간 처리건수는 25TPS x 600초 = 15,000건이 됩니다.
그런데, 고객은 APM 기준으로 1,500TPS 부하발생을 원하고 있고, 위의 계산에 따르면 제공된 500Vuser License로 부하 발생 가능한 TPS는 166.7TPS인데, 이들 사이의 관계를 어떻게 판단해야 할까요?
3) 동시사용자 수와 서비스 요청 간격
TPS에 대한 개념을 이해하기 위해, 우리가 추가적으로 살펴봐야 할 것은 ‘동시사용자’의 개념과 Vuser에서 ‘서비스 요청 간격’이 미치는 영향에 대한 부분입니다.
동시사용자:
동시사용자(Concurrent User)라는 용어에는 부하사용자(Active User)와 비부하사용자(Inactive User)가 포함되어 있습니다. 부하사용자(Active User)는 동시사용자 중 트랜잭션을 발생하여 결과를 기다리고 있는 사용자이고, 비부하사용자(Inactive User)는 동시사용자 중 트랜잭션 발생 조건을 입력하고 있거나 결과를 읽고 있는 사용자입니다.(참고 글. Introduce to Performance test(1/5))
위에서 언급했던 예시 상황은, 500명의 동시사용자(Concurrent User)가 10개의 업무를 대상으로 3초 간격으로 서비스 요청을 보내고 있는 부하 상황을 의미합니다.
그러면, 성능 Tool에서 TPS를 높이려면 어떻게 해야 할까요? 예상하신대로, ‘서비스 요청 간격’을 줄이시면 됩니다.
서비스 요청 간격:
아래 그림은, 지난 글에서 Silk Performer Workload 설정 화면에 대해 설명하면서 다루었던 내용의 일부입니다. 색이 칠해져 있는 부분을 자세히 보시면 Goal Session Time = Execution Time + Pacing Wait Time으로 구간의 의미를 표현하고 있습니다. 서비스 요청간격(Goal Session Time)은 실제응답시간(Execution Time)과 대기시간(Pacing Wait Time)의 합으로 구성되어 있음을 의미하고 있습니다.
예를들어, 서비스 요청간격(Goal Session Time)을 3초로 지정하고 실제응답시간(Execution Time)이 1초였다면, 3초 - 1초 = 2초를 대기(Pacing Wait Time)한 후 다음 요청을 보내게 됩니다.
만약, 서비스 요청간격(Goal Session Time)을 3초로 지정하였는데 실제응답시간(Execution Time)이 4초라면 어떻게 될까요? 3초 - 4초 = -1초이기 때문에, 성능 Tool은 대기시간(Pacing Wait Time) 없이 바로 다음 요청을 보내게 됩니다.
앞의 표에서 우리는 ‘서비스 요청 간격’을 목표 응답시간과 동일하게 3초로 설정했기 때문에 TPS가 166.7TPS가 산출되었지만, 만약 10개 대상업무 모두 서비스 요청 간격을 1초로 낮추어서 다시 TPS를 계산해 본다면, 500Vuser로 500TPS(동시사용자 500명 ÷ 서비스 요청 간격 1초 = 500TPS)의 부하를 발생시킬 수 있음을 알 수 있습니다.
이렇게 해서, 동일한 500Vuser를 가지고 서비스 요청 간격을 줄이는 것 만으로도, 기존 166.7TPS 대비 3배 수준의 부하를 증가하여 발생시킬 수 있다는 점은 확인했는데, 혹시 이러한 판단 과정에서 우리가 놓치고 있거나 추가적으로 고려해야 할 사항은 없을까요?
서비스 요청 간격 ≥ 응답시간:
서비스 요청 간격을 1초로 한다는 것에는, 대상 업무별 응답시간이 모두 1초보다는 빠르다는 전제가 깔려 있습니다. 목표 TPS를 500TPS로, 서비스 요청 간격을 1초로 설정하여 부하를 발생했는데 응답시간이 1초를 초과하고 있다면, TPS는 당연히 500TPS 이하로 떨어지게 되고 성능 테스트 결과는 Fail이 됩니다.
웹브라우저상에서 ‘메인화면’ 페이지를 한번 클릭해 봤을 때도 이미 3초 이상 나오고 있다면, 몇십배의 부하(ex. 75TPS)가 발생하고 있는 실제 성능테스트 상황에서 1초 이하로 나올 가능성은 없습니다.
하지만, 실제 Project 현장에서는 이러한 ‘단위 성능’ 에 대한 자체 확인과정이 간과되기 쉬우며, 현재 애플리케이션의 응답성능을 사전에 체크하지 않고, 개발팀이 임의로 목표 응답시간을 설정하는 경우가 종종 있습니다.
참고. 목표 처리건수의 현실 반영 여부 검토:
위의 표에서 우측 항목을 보시면, 성능 테스트 수행 시 대상 업무별로 10분간 처리되는 ‘처리건수’에 대해 별도로 계산하여 보여주고 있습니다.
‘결제’ 업무의 경우, 성능 테스트 수행 시 초당 25건씩 처리하도록 계산하였으므로, 10분 동안에는 총 1만5천건의 결제처리가 이루어지는 부하 수준임을 사전에 확인할 수 있습니다.
현실 상황에서 이 정도 규모의 ‘결제’ 처리가 실제 이루어지는 시스템인지에 대해서는 ‘처리건수’를 기준으로 다시한번 검토해 보고, 고객과 개발팀이 해당 업무 비율의 조정 여부를 검토함으로써 ‘현실적인’ 성능 테스트 설계를 구현할 수 있게 됩니다.
4. LoadRunner TPS와 APM TPS의 차이
위의 쇼핑몰 예에서, 고객은 APM 기준 1,500TPS를 원하고 있고, 우리는 10개의 목표응답시간이 1초 미만으로 유지된다면, 500Vuser를 가지고 500TPS까지는 부하를 발생시킬 수 있다는 것까지는 확인했습니다. 그런데, LoadRunner에서 말하는 TPS와 APM의 TPS는 어떤 차이가 있을까요?
이 부분에 대해서는, 홍성진Manager님의 잘 정리된 글을 참고해 보도록 하겠습니다.
2-1-2. WAS Transaction Log
WAS에서 바라보는 TPS(Transaction Per Second)는 WEB서버, 자동화 도구와는 관점이 다릅니다. https://cc.sk.co.kr/URL을 호출하면 페이지 안에서 다양한 호출이 발생합니다.
로그인 정보, 메인 이미지, 공지사항, 뉴스, 블로그 등등… 많게는 하나의 페이지에서 20~30개의 호출이 발생하게 되는데 WAS에서는 이를 각각 1개의 호출로 인식하기 때문에 자동화 툴 입장에서는 1TPS(자동화툴) = 20~30TPS(WAS)로 매치되므로 부하량 산출이 어려운게 사실입니다.
이 경우 담당자와 면밀한 회의를 통해 페이지별 주요한 Transaction을 도출하여 해당 Transaction의 호출 건수를 기준으로 산정하거나 목표 자체를 WAS TPS에 맞춰 부하량을 산정할 수 있습니다.
성능테스트를 수행할 때 TPS의 기준은 LoadRunner와 같은 성능 Tool에서 측정되는 ‘Business Transaction’을 기준으로 Count하는 것이 일반적이며, APM을 기준으로 하는 경우는 드뭅니다.
그 이유는, 고객 입장에서는 ‘메인화면’, ‘로그인’, ‘마이페이지’, … ‘결제’ 등의 업무가 얼마나 빠르게 처리되고 있는 지가 중요하기 때문이며, 성능 개선에 있어서도 고객이 체감할 수 있는 성능 목표 기준으로 서로간에 의사소통하는 것이 명확하기 때문입니다.
하지만, 위와 같이 고객 측에서 APM TPS 기준으로 소통하길 원한다면, 성능 테스트 대상업무별로 WAS 기준으로는 몇 개의 호출이 발생하고 있는지 추가적인 확인 작업이 필요합니다.
5. APM TPS를 LoadRunner TPS로 환산
성능 테스트 대상 업무별로 개발자의 지원을 받아, 각 업무별로 WAS를 호출하는 URL 수를 확인할 수 있다면, APM 목표 TPS에 맞게 부하를 주려면 어느정도의 Vuser가 필요한 것인지 미리 계산해 볼 수 있습니다.
아래의 표는 설명을 쉽게(!) 하기 위해, 열의 좌우 위치를 기존과 다르게 구성하였습니다.
우선, 10개 업무에 대한 비율은 이미 정해졌기 때문에, APM 기준 TPS를 각 업무별 비율에 따라 배분하는 작업은 바로 가능합니다. ‘메인화면’ 업무의 경우, 전체 APM TPS인 1,500TPS의 15%이므로, 225TPS가 됩니다.
개발자 확인 결과, ‘메인화면’에서 WAS를 호출하는 URL 갯수가 6개로 확인되었다면, LoadRunner 기준에서는 ‘메인화면’ 1번 호출하는 것이 1TPS가 되므로, 225TPS(APM) ÷ 6개(URL) = 37.5TPS로 Busniness Tranaction 기준 TPS를 도출할 수 있습니다. 동일한 방법으로, 나머지 9개에 대해서도 계산을 수행해 보면 다음과 같은 결론을 얻을 수 있습니다.
APM 기준 1,500TPS의 목표 부하를 위해서는, LoadRunner Business Transaction 기준 500TPS 부하 발생이 필요하며, 이때의 부하발생 조건은 다음과 같음
- 동시사용자: 500Vuser
- 서비스 요청 간격: 1초
- 평균 응답시간: 1초 이내
6. 마무리
결론만 놓고보면, 간단한 논리의 동시사용자(Concurrent User) 산정과 관련한 이야기로 보일 수도 있습니다. 하지만, 현실에서는 이 부분에 대해 사전에 충분히 고민하고 성능 목표 수립에 참여하는 Project팀과 아닌 팀간의 결과를 놓고 볼때는, 성능품질 수준에 있어 상당한 격차를 보이고 있는 것이 사실입니다.
성능테스트에 적극적이고 익숙한 Project 팀원들은, 사전에 자체적으로 As-Is Workload 자료를 수집하여 검토하고, 성능 테스트 설계서가 나오는 시점에 산출된 목표 TPS와 대상 업무별 부하비율 수준이 현실적인지 여부를 다시한번 꼼꼼하게 검토하여, 적극적인 조정 의견을 성능 담당자에게 피드백해 줍니다. 이런 경우, 성능 테스트 수행 과정도 매끄럽게 진행되지만, 수행 이전에 미리 목표 수준에 부합하도록 사전 튜닝을 수행하는 작업에 있어서도 개발팀이 적극적으로 참여하는 모습을 보게 됩니다.
반면, 통합테스트 단계에 성능 요청을 하였지만 아직 개발이 완료되지 않아 매우 바쁜 상황에 놓여있는 Project팀의 경우에는, 성능 목표 수립과 관련한 협의나 설계서 검토에 Project팀이나 개발팀 모두 소극적으로 대응하는 경우가 많고, 성능보다는 현재의 이슈 해결에만 몰입이 되어 있는 경우가 많습니다.
문제는, 후자의 경우 성능테스트 계획/설계서의 고객 검토가 끝나고 막상 성능 테스트 수행결과가 안좋은 결과로 나오게 되면, 계획/설계 단계에는 제대로 검토하지 않고 넘어갔던 성능 목표 수준을, 해당 시점에 하향 조정한 후 다시 진행하면 안되는지 문의하는 Project들을 가끔씩 만나게 됩니다. 이 과정에서 TPS, 동시사용자(Concurrent User), VUD, 부하비율 등의 요소 등이 목표 성능에 영향을 준다는 사실을 뒤늦게 깨닫고, 각각에 대한 개념이 무엇인지 관심을 가지고 물어보기도 합니다.
한편, 기존의 On-Premise에서 Cloud로 Project 환경이 전환되어감에 따라, 예전에는 전문가의 용량 산정에 기반하여 시스템을 설계하고 향후 몇년간 사용자 증가를 고려한 (충분한) H/W 구매를 하던 것에서, 이제는 필요하다고 판단되는 최소 수준의 Cloud 사양만 견적을 받아서 시스템 구현을 하는 경우를 종종 보게 됩니다. 이러한 경우, 성능 테스트 결과가 ‘서버 증설 필요’ 의견으로 귀결되더라도, 실제적으로는 고객과 Project팀 모두 쉽게 증설 결정을 내리지 못하는 경우도 있습니다.
이러한 현실적인 이슈들을 종합적으로 고려해 볼때, Project팀이 성능 테스트와 관련한 개념들을 잘 이해하고 고객 및 개발팀과 성능 목표 수준에 대해 적극적으로 의사소통하는 능력은, 개발되는 애플리케이션의 복잡도가 성능에 미치는 영향이나, Cloud 기반 시스템의 적정사양 검토 및 (필요시) 변경 의견을 피력하기 위해서도 역량 확보가 필요한 영역이라고 생각됩니다.
아무쪼록, 여기 Tech Blog의 글들이 Performance Engineering에 대해 관심을 가지고 관련 지식을 조금씩 넓혀 가는데 있어 조금이나마 도움이 될수 있길 바라면서, 이번 글을 마치도록 하겠습니다.
[끝]