7개 Project대상 LoadRunner Cloud적용을 통한 VUH사용 관련 Lessons Learned

몇 해 전, 한 임원분의 면담 요청으로 테스트 업무에 관한 이야기를 약 30분 정도 나눌 기회가 있었습니다. Cloud 및 Testing관련 조직을 담당하시면서 성장 방향성을 고민하셨던 예전의 경험을 들려주시면서, 해당 시기에 ‘Cloud기반 테스트 자동화 환경’ 구축과 관련하여 직접 검토해 보셨던 본인의 생각을 공유해 주셨습니다.

면담을 마치고 나오면서, 제 머릿 속에는 ‘그러면, 성능 테스트 영역에서는, Cloud기반 테스트 환경을 구축한다면 과연 어떤 형태가 될까?’라는 궁금증이 계속 머릿속을 맴돌았습니다.

최근 몇 년간은 COVID-19로 인해 테스트 관련 Global최신 동향을 오프라인에서 직접 눈으로 파악하고 선진 발표사례 등을 통해 궁금증을 해소할 수 있는 ‘STARWEST같은 Testing Conference의 참여’가 아직까지는 수월한 환경은 아니지만, 온라인 관점에서 바라본다면 예전에 비해서는 최신정보에 대한 접근 환경이 많이 좋아진 것은 사실입니다.

회사 내에서 Gartner Report를 열람할 수 있는 계정을 전사 기획부서를 통해 쉽게 제공 받을 수 있고, Performance Engineering Report 또는 World Quality Report와 같은 수준높고 정제된 통계정보들도 온라인에서 직접 얻기도 쉬운 편입니다. 해당 문서들에서 제공하는 다양한 정보들을 통해 과거와 현재의 기술동향들을 하나씩 정리해나가기만 해도 의미있는 자료들로 정리될 수 있기 때문에, 그 과정에서 확보한 다양한 개념들은 여기 Tech Blog에 대부분 요약하여 올려놓은 바 있습니다.

위와같은 기술동향 조사 과정들이, 다시 현실세계의 업무로 돌아가면 기존의 업무체계에서 벗어나지 못한 채로 반복적인 관행을 유지하는 경우도 많은게 사실이겠지만, 단순히 기술동향 분석으로만 끝나버리지 않도록 소속 담당 팀장님께서 업무 과제로 적극 추진해 주시고, Micro Focus Korea 및 Ibiware측에서도 적극적인 기술지원을 해 주셔서, 우선적으로 LoadRunner Enterprise(舊 Performance Center) 제품을 당사 Cloud환경에 올려놓고, K카드사 Project를 대상으로 시범적용해 본 후 그 확장 가능성을 타진해보는 귀중한 기회를 가진바 있습니다.

과제 차원에서 LoadRunner Enterprise제품의 시범적용이 종료된 이후에도, 연속적인 홍성진 매니저님의 추진력있는 LoadRunner Cloud 및 Developer 제품에 대한 기술 분석, PJT시범적용 및 전사확산으로 이어지는 일련의 과정들을 통해, 아래와 같이 올해에만 벌써 7건의 사내/외 Project들을 대상으로 LoadRunner Cloud 제품을 직접 적용해 보는 집중적인 경험을 하게 되면서, Tool에 대한 이해와 경험을 점차 넓혀갈 수 있게 되었습니다.

[‘22년 적용 Project List]

• S사 I포럼 사이트 개편 Project
• A사 Cloud전환 Project
• S사 차세대 OSS Project
• S사 Expense Cloud전환 Project
• S사 MIS Cloud전환 Project
• T사 통합IT시스템구축 Project
• N사 차세대시스템 구축 Project

1. Cloud기반 성능테스트 환경

LoadRunner Cloud제품을 접하기 이전에도, 이미 ‘Cloud기반’ 성능테스트는 종종 진행된 바 있습니다. LoadRunner Solution과 Vuser License는 기존과 동일하게 특정 서버(or 노트북)에 두고, 부하발생서버만 Cloud서버에 설치한 후 Port Open을 통해 연동하여 부하발생 및 모니터링을 수행하는 방식이었습니다.

하지만, 부하발생서버만 Cloud기반으로 구성하였다고 해서 ‘Cloud기반 테스트 자동화 환경’이라고 하기 어려웠던 이유는, 성능테스트 Solution이 여전히 특정 장비에 묶여있는 관계로, 다양한 PJT 사용자가 쉽게 접근해서 사용하기는 여전히 쉽지 않았기 때문입니다.

이번 글을 통해 소개해 드리고자 하는 LoadRunner Cloud 사용 경험은, 기존의 일하는 방식과 비교하여 확연히 차별화되는 부분들은 어떤 것이 있는지에 대한 사용자 관점의 이야기입니다. Micro Focus가 제공하는 소개자료에서 장점으로 거론되는 요소들이 실제로는 어떤 의미인지 잘 와닿지 않았던 부분들에 대해, 실제 7개의 Project환경에 직접 적용해보면서 경험으로 이해하게 된 부분을 포함하고 있습니다.

이후 내용의 구성은, 실제 적용 과정에서 겪었던 상황들에 대해 질문과 답변의 형식으로 구성하여 정리해 보도록 하겠습니다.

2. LoadRunner Cloud사용관련 질문과 답변들

질문 1) LoadRunner Cloud의 VUH의 소진방식은 기존의 VUD와는 어떻게 다른가요?

VUD(Virtual User Day)는 이름처럼 1일(24시간)만 사용가능한 License입니다.

LoadRunner에서 License Key등록을 하고, 하단의 ‘VUDs will begin at’에 시간을 오전 09시라고 설정해 놓은 후, LoadRunner Controller에서 부하발생 버튼을 클릭하고 테스트를 시작하였다면, 24시간 후인 다음날 오전 09시 이후부터는 해당 License를 더이상 사용할 수 없습니다.

예를들어, Project에서 막상 성능테스트를 시작해보니 시스템 준비가 완벽히 되어있지 않다는 사실을 깨닫게되어, 부하발생한지 10분만에 테스트를 종료하고 License를 더이상 사용하지 않았더라도, 이렇게 1번이라도 시작되었다면 설정된 시작 시점부터 24시간 동안만 제한적으로 사용이 가능한 License입니다.

물론, 1,000VUD를 구매하였는데 실제로는 최대 500VUD까지만 부하에 사용하였다면, 나머지 소진되지 않은 500VUD는 남아있어서 추후에 사용가능합니다. 시간만 지정할 뿐 날짜는 지정하지 않기 때문에, 사용하지 않은 수량은 계속 사용이 가능합니다.(ex. 기존에는 VUD를 전사 조직에서 대량으로 일괄 구매하여 License를 특정 노트북에 등록해놓고, PJT별로 지원하면서 License를 소진하는 방식으로 사용하였음)

한편, LoadRunner Cloud의 VUH(Virtual User Hour)의 소진방식에 대한 계산식은 아래와 같습니다.

VUH = Vusers * Test execution time in seconds/3,600

※ Test execution time includes the test duration, the duration of all the ramp ups, the duration of all the tear downs, the paused time, and the actual delayed start.

Source: https://admhelp.microfocus.com/lrc/en/2022.10/Content/Storm/lp_License.htm

이해를 돕기 위해 조금 더 자세히 설명해보면, VUH는 ‘실제 부하발생에 소요된 시간에 대해서만 소진’되는 방식인데, 이러한 방식의 차이로 인해 실제 VUH로 성능테스트를 해보면 소진되는 량은 생각보다 체감이 크지 않습니다.

예를들어, VUH 라이선스로 부하발생시키는 작업에 대해, 다음과 같은 일정으로 총 5회(적정부하 3회, 2배부하 1회, Fail Over 1회)의 테스트를 수행했다고 가정해 보겠습니다.

2022년 11월 4일 성능/부하 테스트 수행

장소: N사 16층 회의실

시간: 10시~17시(총 7시간)

• 적정부하테스트: 1,000Vuser, 20분, 1회
• 테스트 중단 및 튜닝(1시간)
• 적정부하테스트: 1,000Vuser, 20분, 1회
• 테스트 중단 및 튜닝(1시간)
• 점심식사 1시간
• 적정부하테스트: 1,000Vuser, 20분, 1회
• 2배부하테스트: 2,0000Vuser, 30분, 1회
• 테스트 중단 및 튜닝(1시간)
• Fail-Over테스트: 1,0000Vuser, 60분, 1회
• Wrap Up Meeting 및 종료 1시간

VUH의 사용량을 기준에 따라 계산해 보면 다음과 같습니다.

VUH = 1,000명 x 20분 x 3회 + 2,000명 x 30분 + 1,000명 x 60분

= 1,000명 x 1시간 + 1,000명 x 1시간 + 1,000명 x 1시간

= 1,000VUH + 1,000VUH + 1,000VUH

= 3,000VUH

위와 같은 성능/부하테스트의 경우에는 1,000VUH를 3시간 수량만큼만 구입한다면, 즉 3,000VUH(=1,000VUH x 3hour)로 수행이 가능한 규모가 됩니다.(물론, 추가적인 테스트 수행 상황을 고려하여, VUH의 규모산정은 다소 여유있게 가져갈 필요가 있습니다.)

만약, 위 테스트를 VUD로 진행했다면 Max User기준으로 2,000VUD를 구입해야 했겠지만, VUH의 경우에는 최소로 3,000VUH만 구매해도 됩니다.(‘22년 10월 현재 기준, 1VUH당 $0.3수준인 것을 감안하면, 부가세를 고려하더라도 비용적인 측면에서 상당한 PJT비용절감 효과가 발생합니다.)

한편, VUD에서는 부하발생을 중단하고 튜닝 후 재개하는 미사용 시간도 24시간이 소진되는 과정에 포함되어버리는 단점이 있었지만, VUH는 Tool을 통해 실제 부하를 발생한 시간만큼만 차감되므로, 경제적인 방식의 성능/부하테스트가 가능해집니다.

실제 LoadRunner Cloud에서는 License Information이라는 메뉴 제공을 통해, 각 Test Scenario 수행별로 몇명의 Vuser를 사용했는지, 그때의 부하시간은 얼마였는지, 해당 Project에서 소진된 총 VUH License는 어느 정도인지 등의 통계정보 현황을 아래와 같이 자동계산하여 제공해 주고 있습니다.

질문 2) License는 언제까지 사용가능한가요?

최근 1~2년 사이에 고객 및 PJT 대상으로 성능테스트 계획/설계서 및 결과서 리뷰 시간을 가져보면, 특히 결과 보고하는 시점에 공통적으로 문의하시는 내용들이 있습니다.

A PJT

“금번 성능테스트가 종료된 이후에도 PJT 자체적으로 동일한 부하를 발생시켜보는 성능 점검이 가능할까요?”

B PJT

“Cloud 설정을 바꿔가면서, 이에 따른 영향도를 확인하고 싶은데, 성능팀에서 철수하신 이후에도 자체적으로 Auto Scaling Test 및 Fail-Over Test를 위한 부하를 줄 수 있는 방법이 있을까요?

C PJT

“금번 성능테스트 기간 중에 아직 개발되지 않은 기능들이 있는데, 다음달 해당기능이 개발되면 이번과 같은 부하 상황에서 해당 기능의 성능이 어떠한지 함께 확인해 보고 싶은데 가능할까요?”

D PJT

“개발 진척 상황상 하루에 성능테스트를 몰아서 하기는 어렵고, 시나리오별로 날짜를 정해서 1달 정도 시간을 가지면서 진행하고 싶은데 어떻게 하면 좋을까요?”

질문들이 조금씩 다른 것 같지만, 결국은 PJT에서 License를 계속 사용할 수 있는지에 대한 궁금증들입니다.

기존에 VUD License를 쓰던 시절에는, 다음과 같은 답변을 드릴 수 밖에 없었습니다.

“PJT에서 추가로 1,000VUD를 구입해야하는데, License 유효기간인 24시간이 지나면 소진되기 때문에 PJT 자체적으로 편하게 쓰시기에는 부담이 있으실 것 같습니다.”

하지만, VUH License의 유효기간은 아래에서 보시는 바와 같이 구입시점 기준 1년입니다. (메뉴 위치: Tenant Management > License > Summary)

성능테스트 수행 후 VUH가 아직 남아있다면, 구입 후 1년 이내에는 PJT에서 원하는 일자와 시간에 자유롭게 부하를 발생시킬 수 있습니다.

예전 일부 PJT에서는 VUD가 24시간이 지나면 소진되기 때문에, 성능테스트를 아침 9시부터 다음날 아침 9시까지 종일 진행하자고 요구하는 Case도 있었던 점을 감안하면, LoadRunner Cloud의 VUH 방식은 성능 테스트 수행 당사자가 본연의 업무에만 집중할 수 있도록, License차원의 불필요한 제약들은 과감히 풀어버린 합리적인 방식이라고 생각합니다.

질문 3) LoadRunner Cloud를 PJT에서 사용하려면 별도 설치가 필요한가요?

LoadRunner Professional(舊 LoadRunner)이나 Silk Performer와 같은 On Premise기반 성능테스트 도구들을 통해 부하를 발생시키려면, 다음 두가지 환경의 설치가 필요했습니다.

• Controller : License기반 부하발생/모니터링
• Agent : 부하발생서버

  

하지만, LoadRunner Cloud의 경우 1) Controller는 LoadRunner Cloud 웹페이지에 로그인하여 바로 사용할 수 있으며, 2) Agent는 부하발생시마다 자동으로 미리 지정한 Cloud Region(ex. AWS 서울Region 등)에 자동으로 생성 및 연동해주고 종료 시 폐기해 주기 때문에, ‘설치’없이 바로 부하발생 서비스를 사용할 수 있습니다.

물론, 부하발생 Script 작성을 위해서는 VuGen을 Local PC에 설치하여 Scripting 작업이 필요하지만, VuGen는 무료도구이고 성능테스트 환경 구성과는 상관이 없기 때문에 논외로 한다면, PJT에서는 별도의 성능테스트 환경 설치 없이 VUH License만 있으면 바로 부하발생이 가능하다고 볼 수 있습니다.

참고로, 성능테스트 수행과정에서 LoadRunner Cloud에 Upload된 Script들은 각 PJT별로 삭제되지 않고 유지되기 때문에, (Application의 Source변경이 발생하지 않았다면) Script의 재사용이 가능합니다.

재미있는 점은, 우리가 앞서 살펴보았던 VUH의 비용 안에는, Vuser 자체에 대한 비용뿐만 아니라, Cloud서버를 Agent로 구성하여 쓰는 비용(ex. AWS 서울 Region등)이 모두 포함되어 있는 Total Cost란 점입니다.

우리가 기존에 Cloud기반 부하발생환경을 구성할 때, PJT에서 부하발생용 Cloud서버(ex. 8core 16Gb 8대)를 별도로 (구입) 준비하여, 해당서버에 일일히 Agent프로그램을 깔고 방화벽 해제하여 연동구성하는 작업을 진행했던 점을 생각해 보면, 서버비용뿐만 아니라 부하발생환경에 소모되는 기간(보안이슈 고려 1주일 내외)도 획기적으로 절감할 수 있는 환경으로 변해가고 있음이 분명합니다.

질문 4) 가상사용자를 늘려서 테스트 가능할까요?

적정 부하에 대한 성능테스트를 수행했을 때 결과가 잘 나오게 되면, 고객이나 PJT에서 더 많은 사용자 부하상황에서도 시스템이 잘 처리하는지를 확인해 보고싶다는 요구사항을 가끔씩 추가로 내기도 합니다.

이럴때, VUD의 경우 1,000VUD를 구입하였다면 Max 1,000명까지만으로 부하발생이 제한되겠지만, VUH의 경우 ‘사용량’만큼 소진되는 방식이기 때문에, 요구사항 변화에 대응하여 사용자를 늘리는 것이 생각보다 어렵지 않습니다.

예를 들어, VUH 구입을 위한 규모산정 시 1,000명의 동시사용자로 5시간 테스트를 수행하는 계획을 세우고, 총 5,000VUH를 구입했다고 가정해 보겠습니다.

총 4회의 적정부하(1천명) 성능테스트 및 튜닝을 통해, 서버자원 및 응답성능이 최적화되었음을 확인하고, 남은 VUH를 이용해 2배 부하(2천명)와 4배부하(4천명)의 테스트를 1회씩 추가로 해보는 것을 고객이 뒤늦게 추가 요청하였다면, 이러한 요구의 대응이 가능할지, 그리고 이때 소진되는 License의 총량은 어떻게 될지 간단히 살펴보겠습니다.

VUH 사용량을 기준에 따라 계산해 보면 다음과 같습니다.

VUH

(a) 1,000명 x 30분 x 4회 = 2,000VUH

(b) 2,000명 x 30분 = 1,000VUH

(c) 4,000명 x 30분 = 2,000VUH

합계 = (a) + (b) + (c) = 5,000VUH

위의 예시와 같이, 원래는 1,000명의 동시사용자를 고려해서 License 구입을 진행했던 것이지만, 계획을 바꾸어 사용자를 늘리는 의사결정을 하더라도 VUH 방식에서는 유연하게 사용자를 증가하여 부하 발생이 가능함을 알 수 있습니다.

질문 5) 대형 PJT에서 VUH를 소규모 PJT로 나눠 사용가능한가요?

홍성진 매니저님이 LoadRunner Cloud제품의 세부 기능별 학습 및 Micro Focus측을 통한 계속적인 질의과정에서 확인한 재미있는 기능들 중 하나는 ‘Tenant Management’입니다.

우리가 앞서 잠깐 언급한 LoadRunner Enterprise도구는 소위 Performance Testing CoE(Center of Excellence)조직을 위한 중앙집중형 관리도구라고 볼 수 있는데, LoadRunner Cloud에도 이와 유사하게 관리적인 기능들을 제공하고 있다는 점을 적용과정에서 새롭게 확인하였습니다.

PJT명을 여러개 신규 생성하고, 필요한 만큼의 License 수량을 각각 할당하고, 접근 및 사용권한을 로그인 계정별로 다르게 부여해 줄 수 있는 기능들이 존재합니다.

예를 들어, A라는 하나의 차세대PJT에서 3개의 a,b,c파트가 각각 성능테스트를 별도로 수행하길 원한다면, 이에 대한 관리 및 지원이 즉각적으로 가능한 구조입니다. PJT명을 필요한만큼 생성하고, 각 PJT별로 License와 로그인 계정별 접근권한을 할당해주면 됩니다.

만약, 성능테스트 수행 중 a,b,c의 License 소진량이 달라 재배분이 필요한 경우가 발생하면, ‘Allocate licenses to project’ 화면에서 총 VUH 중 PJT별로 할당된 VUH 수를 다시 늘리거나 줄임으로서 License 총량을 필요에 따라 재배분해 줄 수도 있습니다.

3. 글을 마치면서..

익숙한 듯하면서도 익숙하지 않은 LoadRunner Cloud 제품과 VUH(Virtual User Hour)기반 License 방식에 대해 이해를 돕고자 설명을 하다보니, 처음에 예상했던 것보다 글이 길어진거 같아 이쯤에서 마무리하고자 합니다.

실제 사용하다보면, 상황에 따라 기술적인 지원이나 이해가 필요한 경우가 생기기 때문에, 이러한 경험들도 나중에 기회가 되면 추가적으로 정리해 보도록 하겠습니다.

혼자 일하는 것보다 함께 일하는 것이 좋고, 다양한 이해관계자들이 각자의 전문적인 관점에서 이슈 현상을 들여다보고 의견을 나누며 실질적인 개선을 해 나가는 과정들이, Performance Engineering이 가지는 매력이라고 생각합니다. 하지만, 일도 개인이 가진 에너지를 넘어서서 계속 진행되다보면 Burn Out이 오거나, 건강 측면에서 무리가 와서 즐거움보다는 심리적인 부담으로 다가올 수 있기 때문에, 갑자기 추워진 요즘 날씨에 모두들 감기 조심하시고, 부디 건강하게 겨울을 맞이하시길 바라면서 이번 글을 마치도록 하겠습니다.

감사합니다.

[끝]