SK(주) C&C’s TECH BLOG

World Quality Report(2022-23) 소개 (2)

2022-11-24T00:00:00+09:00

이전 글에 이어, Quality & Testing 관련 현재 트랜드 및 주요 내용에 대해 계속 살펴보도록 하겠습니다.(출처: “World Quality Report 2022-23” )

3. CURRENT TRENDS IN QUALITY ENGINEERING & TESTING

3) Quality Infrastructure Testing and Provisioning

테스트 환경관리(Test Environment Management)는 World Quality Report의 설문조사에서 항상 중요한 영역이었습니다.

용어 참고. 테스트 환경관리(Test Environment Management)

테스트 환경 관리는 각 테스트 환경을 IT PJT, DevTest Community 및 전체 S/W Development Lifecycle에 사용할 수 있도록, 적절한 거버넌스 및 서비스를 통해 테스트 환경*을 이해하고 해당 지식을 적용하는 기능입니다.

*IT 및 테스트 환경에는 다음이 포함될 수 있습니다.

Development Environments, for development

System Testing Environments, for isolated system tests

Integration Testing Environments, to check connectivity

User Acceptance Test Environment, for business sign-off

Performance Testing Environment, for performance tests

Source: https://www.testenvironmentmanagement.com/tem-101/

올해에는 테스트 환경 프로비저닝(Test Environment Provisioning)이 어떻게 적용되고 있는지, 그리고 Non-production환경의 Cloud Provisioning이 어떻게 도약하고 있는지에 대해 분석했습니다.

용어 참고. 프로비저닝(provisioning)

프로비저닝(provisioning)은 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것을 말합니다. 서버 자원 프로비저닝, OS 프로비저닝, 소프트웨어 프로비저닝, 스토리지 프로비저닝, 계정 프로비저닝 등이 있습니다. 수동으로 처리하는 ‘수동 프로비저닝’과 자동화 툴을 이용해 처리하는 ‘자동 프로비저닝’이 있습니다.

Source: https://ko.wikipedia.org/wiki/

용어 참고. Non-production Environment

Non-Production Environment란 S/W가 상용 목적으로 사용되지 않고 있는, Development, Staging, Quality Assurance과 같은 환경들을 의미합니다.

Source: https://www.lawinsider.com/dictionary/non-production-environment

점점 더 많은 환경과 애플리케이션들이 Cloud로 이동함에 따라, Cloud Testing은 S/W Development Lifecycle에서 더 큰 위치를 차지하고 있습니다. 그래서, 이번 장에서는 Cloud Testing의 현 상태과 적용 수준에 대해 조사했습니다.

Test environment provisioning on cloud

점점 더 많은 Workload들이 Cloud로 옮기고 있음에 따라, 조직들이 Non-production환경에 대해 Cloud에서 Provisioning하고 있는 비율이 어느 정도인지 물어봤습니다.

용어 참고. 워크로드(Workload)

클라우드 워크로드란 무엇입니까?

클라우드 워크로드는 클라우드 리소스에서 실행할 수 있는 특정한 애플리케이션, 서비스, 기능 또는 특정한 작업량입니다. 가상 머신, 데이터베이스, 컨테이너, Hadoop 노드 및 애플리케이션이 모두 클라우드 워크로드로 간주됩니다.

Source: https://www.dell.com/ko-kr/dt/learn/cloud/cloud-workloads.htm

그 결과는 명백한 진전을 보여주고는 있지만, 아직까지도 전체 조직의 거의 절반 정도는 Non-production환경 중 최대 25% 정도까지만 Cloud에서 Provisioning하고 있는 것으로 나타났습니다.

전체 조직의 나머지 49%는 Non-production환경의 50% 이상을 Cloud에서 보유하고 있습니다. 이러한 Non-production환경의 Cloud 적용은, Cloud환경에서 평균 23%의 Testing이 수행되고 있다고 답변한 지난해 설문조사와 비교하면 긍정적인 추세를 보여주고 있습니다.

Non-production Workload를 Cloud로 옮기는 추세가 증가하고 있다는 사실을 알게된 이후, 우리는 Non-production환경을 위한 Cloud Platform전략에 대해서도 살펴봤습니다. 그 결과, 현재 많은 조직들(44%)이 Hybrid(On-premises plus Single Cloud Provider) 환경 전략을 사용하고 있었습니다.

조직들 중 약 38%는 Multi-cloud전략을 수립하고 있습니다. 또한, 응답자의 평균 30%가 테스트 환경을 Multi-premise(on-premises plus multi-cloud provider)모델로 전환하는 것에 대해 심각하게 고민하기 시작했습니다.

이 데이터는 Non-production환경을 Cloud로 전환하는 작업이 아직 완료되지 않았음을 보여주고 있습니다. 이러한 Non-production환경에 대한 Multi-cloud 및 Multi-premise전략은 재해 복구, 보안 및 비용 효율성에 긍정적인 영향을 미치기 때문에, 적용이 점차 증가할 것으로 예상하고 있습니다.

Automation of test environment provisioning

Non-production환경을 Cloud로 옮길 때 가장 큰 이점은, Cloud Solution을 통한 테스트 환경 Provisioning 자동화가 훨씬 쉬워진다는 것입니다.

우리는 테스트 환경 Provisioning 자동화를 위해 조직들이 사용하고 있는 자동화 도구들을 조사했습니다. 그 결과, 사용 가능한 다양한 옵션들이 고르게 분포되어 있었습니다.

응답자의 41%는 오픈소스(Open-source Option)와 함께 상용 자동화 도구(Commercial Off-the-shelf Tooling)를 혼합한 Hybrid Tooling Strategy를 적용하고 있었습니다. Cloud-native Tooling이나 사내개발 자동화 도구(In-house Supplier-Built Tooling)의 경우에도 비슷한 수준의 선호도를 보이고 있다는 점을 확인했습니다.

이번 분석에서 눈에 띄는 한 가지 전략은, 조직들이 모든 계란을 한 바구니에 담을 준비가 되어 있지는 않다는 것입이다. 따라서, 현재는 여러 자동화 도구를 혼합하여 사용하는 전략이 수행되고 있습니다. 이를 통해, 많은 조직들이 자동화 도구를 적용함에 있어 균형 잡힌 접근 방식을 취하고 있음을 알 수 있습니다. 이 분야에는 많은 새로운 자동화 도구들이 적용되고 있기 때문입니다.

Cloud and infrastructure testing

조직들이 Cloud에 더 많은 환경들을 구축함에 따라, Cloud Testing의 중요성 또한 점점 더 커질 것으로 예상됩니다. Cloud Testing을 통해 조직들은 Cloud환경 및 애플리케이션의 확장성(Scalability), 성능(Performance), 보안(Security), 신뢰성(Reliability), 재해 복구(Disaster Recovery), 상호 운용성(Interoperability) 및 멀티 테넌시(Multi-tenancy)를 검증합니다.

애플리케이션이 Cloud로 옮겨질 때, 애플리케이션의 기능적 측면과 비기능적(Non-functional) 측면을 테스트하여, 요구하는 전체적인 기능과 성능을 유지하고 있는지에 대해 보장할 수 있어야 합니다.

올해 설문 조사에서는, 조직들이 Development Lifecycle의 일부로서 Cloud 및 Infra Testing을 포함하고 있는지 물어보았습니다. 전체 응답자의 약 96%가 Cloud Testing이 현재 Testing Lifecycle의 일부로 포함되어 있다고 언급했으며, 57%는 대부분의 PJT에서 Cloud Testing을 포함하고 있으며, 39%는 적어도 일부 PJT에서 Cloud Testing을 포함하고 있다고 답변했습니다.

이것은 S/W Development Lifecycle에 Cloud Testing 역량을 포함하는 추세가 상승하고 있음을 보여주는 긍정적인 결과입니다. 이러한 추세를 지속하면서, Cloud Testing 및 Infrastructure Testing을 S/W Development Lifecycle의 필수 단계로 포함할 것을 강력하게 권장합니다.

우리는 향후 몇년간은 Cloud Testing이 받아들여지고 적용이 증가하는 트랜드가 계속될 것으로 보고 있으며, 이전에 비해 Cloud Testing 및 Infrastructure Testing에 참여하는 조직들도 확실히 늘어나고 있습니다. 이는 Cloud 적용이 점차 증가함에 따라, 잠재적인 보안 및 성능 이슈에 대한 관심도 증가하기 때문에, 점점 더 높은 관련성을 가지게 될 것 입니다.

Cloud testing strategy

Cloud Testing의 중요도가 점차 높아질수록, 조직들이 PJT에 대한 Cloud Testing전략을 수립하는 데 얼마나 성숙되어 있는지 이해하는 것도 중요합니다. 이번 설문조사에서 Cloud Testing전략은 아직 효과적이지 않으며, 성숙될 필요가 있는 것으로 나타났습니다. 응답자의 절반(50%)이 Cloud Testing전략이 약간 효과적(Only Somewhat Effective)이라고 언급한 반면, 37%는 중간정도로 효과적(Moderately Effective)이라고 언급했습니다.

이같은 결과는, 대부분의 조직들이 전반적으로 가지고 있는 Cloud Testing의 개념 및 Cloud Testing관련 자동화 수준이 초기 단계에 머물러있다는 신호입니다. 이러한 관찰을 통해 얻을 수 있는 핵심은, 조직들이 전체적인 Cloud 적용 전략에 부합하는 End-to-end Cloud & Infrastructure Testing전략 수립을 시작하는 것이 시급하다는 것입니다.

Automation of cloud testing

또한, 우리는 조직에서 Cloud Testing 자동화를 적용하는 접근방식과 Cloud Testing 자동화에 사용하는 도구의 유형에 대해서도 조사했습니다. 응답자의 약 33%는 Cloud Testing을 위한 자동화 도구 선정에 대해, PJT별 의사결정에 전적으로 따른다(Project-specific Decision)라고 대답했습니다. Open-source를 선호하는 경우도 동일한 비율(33%)로 답변하였으며, 31% 정도가 Cloud기반 자동화 도구(Cloud-native Tooling)를 선호하고 있다고 답변하였습니다.

What should organizations focus on?

전반적으로, Test Environment Management에 대한 긍정적인 동향을 확인할 수 있었습니다.

보다 많은 조직들이 테스트 환경을 Cloud(Multi-cloud 또는 Multi-premise Model)로 이동하고 있습니다.
조직들은 테스트 환경 Provisioning 자동화를 위해, Cloud 자동화 도구(Cloud-native Tools), 상용 자동화 도구(Commercial off-the-shelf Tools)또는 사내개발 자동화 도구(In-house Built Tools)에 이르기까지, 자동화 도구들을 혼합하여 사용하고 있습니다.

Test Environment Management 및 Provisioning 관련 권장 사항은 다음과 같습니다.

테스트 환경을 위한 Multi-premise(on-premises plus multi-cloud provider) 전략을 신속하게 적용하여, 비용 효율성(Cost Efficiency), 보안성(Security), 중복성(Redundancy) 및 데이터 복구 옵션(Data Recovery Options)을 개선해야 합니다.
테스트 환경 Provisioning을 위한 Hybrid전략으로, 상용 및 오픈 소스 자동화 도구의 최대 활용을 위한 Intelligent Integration(특정 기능 사용자 지정 포함)을 고려할 수 있습니다.
Non-production workload환경의 효율적인 설계 및 아키텍처를 통해, Non-production workload를 Cloud로 이동하는 비용-편익(Cost-benefit) 트랜드를 더욱 활용해야 합니다.

4) Test Data Provisioning and Data Validation

Test data provisioning strategies

올해는 조직들이 어떤 Test Data Provisioning전략을 사용하고 있는지 조사했습니다. 분명한 결과는 많은 조직(41%)들이 여전히 Test Data Provisioning에 있어, PJT중심의 접근 방식을 사용한다는 것입니다. 조직들의 31%가 전사적 Test Data Provisioning전략을 수립했지만, 효율적으로 구현하는 데 어려움을 겪고 있는 것으로 나타났습니다. 응답자의 20%만이 전사적으로 완벽하게 구현된 Test Data Provisioning전략을 가지고 있다고 답했습니다.

조직들은 현재 속해있는 지역의 규정을 살펴보고 전사적인 Test Data Provisioning전략을 신속하게 수립해야 합니다. 여기에는 보안에 대한 적절한 초점도 포함되어야 합니다.

Provisioning of test data into CI/CD pipelines

조직들은 안전한 Test Data에 대해 On Demand Provisioning을 고려하고 있지만, Test Data Pipeline이 CI/CD Pipeline과 통합되는 것은 아직도 먼 이야기입니다. 49%의 조직에서 Test Data Provisioning Process가 자동화되어 있지만, 이러한 자동화는 전체 CI/CD Pipeline 자동화와는 독립적으로 운영되고 있습니다. 42%의 조직에서 Test Data의 ‘Manual Provisioning’은, CI/CD Pipeline과 Test Data Provisioning을 통합하는 데 있어 여전히 가장 큰 장벽 중 하나입니다. 응답자의 거의 1/3(31%)은 Test Data를 CI/CD Pipeline에 통합하는 것이 종종 간과되고 있다고 생각합니다.

이 분석을 통해 얻을 수 있는 주요 시사점(Key Takeaway)은, 조직들이 Test Data Provisioning 자동화를 CI/CD Pipeline의 필수 요소로 고려해야 한다는 것입니다. 우리는 Value Stream Management 관련 Tooling이, Test Data Provisioning을 CI/CD Pipeline에 통합하는 데 도움이 될 수 있다고 생각합니다. 이러한 접근 방식은 Cloud기반 Non-production환경에 올바른 Test Data를 구현하는 데도 도움이 될 수 있습니다.

Data validation approaches

Business의 의사결정을 위한 데이터 사용이 증가함에 따라, 데이터의 정확성과 Quality에 대한 검증이 매우 중요해지고 있습니다.

설문 조사에서 응답자의 46%가 현재 데이터 검증을 매우 중요한 기능으로 보고 있으며, 44%는 이 분야가 앞으로 매우 중요해질 것이라는 데 동의하는 것으로 나타났습니다. 데이터 검증에서 기대되는 Benefit에 대한 질문에서, 응답자의 89%는 강력한 데이터 검증 역량이 시간 및 자원 측면에서 효율성을 향상시킬 뿐만 아니라, Business 의사결정을 개선하는 데 있어 중요한 도움이 될 것이라는 데 동의했습니다.

이와 유사한 수준에서, 88%의 응답자가 강력한 데이터 검증 역량이 고객 만족도 및 통찰력의 정확성에 직접적인 영향을 미치고 있으며, 이 기능이 Business 수익성을 높이는 데 도움이 될 것이라는 데 동의하였습니다. 효과적인 데이터 검증이 Business성과에 매우 중요하다는 확신이 압도적으로 많습니다.

What should organizations focus on?

Test Data Provisioning에 대한 올해의 설문 조사에서 관찰한 주요 내용은 다음과 같습니다.

언제든지 Test Data에 접근할 수 있도록, Cloud기반 전사 Test Data Management전략을 채택하는 경향이 증가하고 있습니다.
많은 조직들은 여전히 Test Data의 On-premise복사본에 편향된 전략을 적용하고 있습니다.
CI/CD Pipeline과 통합된 Test Data Provisioning Process 자동화는 여전히 대부분의 조직에서 성숙될 필요가 있습니다.

5) Quality and Sustainable IT

Introduction

지속 가능한 컴퓨팅(Sustainable Computing)을 홍보하기 위해 가장 잘 알려진 프로그램 중 하나는 30년 전(1992년)의 사례입니다. 미국 환경보호청(US Environmental Protection Agency)이 주관한 자발적 참여 프로그램으로, 컴퓨터 기기의 에너지 효율 가시성을 장려하는 ‘Energy Star’ Labeling Program으로 불렸습니다.

Source: https://www.efficiencyvermont.com/products-technologies/electronics/computers-monitors

이후 IT 지속가능성(IT Sustainability)은 탄소 배출에 대한 집중적인 관심에서부터, 보다 광범위한 환경, 사회 및 거버넌스 측면(ESG Framework)까지 부각되었습니다. 지속가능성(Sustainability)은 조직들이 지구와 사회 전반에 어떠한 해도 끼치지 않고 운영을 지속할 수 있는 능력과 연관이 있습니다. 대부분의 조직들은 이러한 임무를 목표와 일정이 명확하게 정의된 실행 단계로 전환해왔습니다.

Sustainable Quality Engineering은 지속가능한 IT(Sustainable IT)를 달성하도록 돕는 Quality Engineering입니다. Quality가 높을수록 자원 낭비를 줄이고 효율성을 높일 수 있습니다. 보다 넓은 관점에서 볼 때, Business를 운영하면서 Sustainable Practices에 초점을 맞추고 있는 조직들은, Quality에 집중하지 않을 수 없습니다. “Shifting Quality Left”는 새로운 개념이 아니며, 효율성을 높일 수 있는 유일한 지속 가능한 방법입니다. 간단히 말해서, Quality 없이는 지속가능성(Sustainability)이 없습니다!

이번 장의 목표는 조직들이 어떻게 Quality Framework와 자동화 도구들을 활용하여, Sustainable IT로 나아가기 위한 더 높은 Sustainability을 추진하고 있는지에 대해 보다 자세히 살펴보는 것입니다.

The role of quality within sustainable IT is still evolving

조직들이 Sustainable IT 전략의 일환으로 Sustainable Quality Engineering을 활용할 때 얻을 수 있는 Benefit을 순위로 매긴다면, 명확하게 우세한 항목이 있다고 말하기는 어렵습니다. ‘Brand Value’와 ‘Loyalty’는 Quality Engineering이 기여할 수 있는 가장 큰 Benefit으로 간주되지만, 다른 Benefit에 대해서는 크게 리딩하지 못하고 있습니다.

설문 조사에서도 동일한 관점이 반영되어 있습니다. 82% 이상의 조직들이 Quality Engineering이 Sustainable IT의 ‘사회적(Social)인 측면’에 가장 큰 영향을 미칠 것이라고 생각하기 때문입니다. 이는 Sustainable IT에 포함된 Quality Engineering이 ‘Brand Value’에 대해 가장 큰 Benefit을 제공하고 있다는 의견과 일치합니다. 72%의 조직만이 Quality가 Sustainable IT의 ‘환경적(Environmental)인 측면’에도 기여할 수 있다고 생각합니다. 조직이 환경적으로 지속 가능하려면, 가용자원을 최적화하여 사용하는 방법을 학습해야 합니다. Quality는 이것을 달성하는 방법에 대해 보다 강력한 전략적인 초점을 제시해 줍니다. Quality는 Sustainable IT를 추진하기 위한 전략의 핵심 부분이 되어야 합니다.

Teams don’t test for sustainability attributes consistently

Team들이 테스트하고 있는 Sustainability의 속성은 무엇인지, 그리고 얼마나 자주 테스트하는지에 대한 질문에 대해, 결과는 전반적으로 거의 비슷한 수준을 보이고 있습니다. 조직들은 Team들이 모든 속성들을 테스트하지만, 가끔씩만 테스트한다고 보고하고 있습니다. 이러한 조직들 중 얼마나 많은 수가 Sustainability 목표를 채택했는지에 대한 맥락에서 이 결과 데이터를 고려해야 하지만, 데이터들이 Team에 대한 특정 패턴이나 중점 영역을 가리키고 있지는 않습니다. Quality Engineering 활동은 모든 Sustainability 속성에 동일하게 분산되어 있는 것으로 보이며, 이는 올바른 방향으로 나아가는 단계처럼 느껴집니다.

What are the tactical benefits of quality towards sustainable IT?

단기적으로 Quality가 Sustainable IT에 가져올 수 있는 Tactical Benefits에 대해 질문을 받은 조직들은, 흥미롭게도 Cloud Environment, Test Optimization 및 Resource Efficiency를 언급하고 있습니다. Application Performance와 Customer Experience는 마지막을 차지했습니다. 이 설문 결과는, 앞서 살펴본 바 있는 Quality가 주는 환경적(Environmental)인 영향도는 높지 않지만, Brand Value에 끼치는 영향도는 높다라고 답변했던 이전의 설문 결과와 다소 모순이 되는 답변입니다.

우리는 Resource Efficiency를 개선하는 유일한 방법은 Quality를 높이는 것이며, 이는 조직들이 탄소 배출량을 줄이는 데 직접적인 영향을 끼친다는 데 동의합니다. Quality Focus 또한 Sustainable IT가 모든 측면(인간, 사회 및 환경)에서 구현하는 것을 정의, 측정 및 통제하는 전반적인 Maturity Framework를 개선하는 데 도움이 될 것입니다.

Where do we go from here?

설문조사의 주요 결과를 살펴보는 동안, 우리는 수학자 Abraham Wald가 제안한 것과 같은 “생존 편향(Survival Bias)””을 고려할 필요가 있었습니다.

Source: https://en.wikipedia.org/wiki/Survivorship_bias

그는 돌아오는 항공기들이 총알에 맞은 곳을 도표로 그려서, 군용기의 어느 부분에 철갑(Armor)이 더 많이 필요한지 분석하고 있었습니다. 그가 분석하는 동안, 그는 가장 많이 타격을 입은 구역을 강화하는 것에 초점을 맞추는 대신, ‘손상되지 않은 구역을 강화’하는 데 초점을 맞추었습니다. 해당 구역들이 손상되지 않은 한 항공기들이 기지로 다시 돌아올 수 있다는 것을 잘 이해하고 있었기 때문입니다.

데이터는 Quality와 Sustainable IT 사이의 관계에서 일부 측면만을 보여주지만, “생존 편향(Survival Bias)” 또는 데이터가 직접적으로 보여주지 않는 것을 고려할 때, 더 큰 그림이 그려질 수 있습니다. Quality가 Sustainable IT의 목표를 주도하는 데 보다 효과적으로 사용될 수 있는 여지가 많습니다. “Sustainable Quality Gate”를 구축하는 수준까지 진행 상황을 측정, 통제 및 정량화하기 위해서는, 일관된 Framework가 필요합니다.

이것은 전략적인 Quality Focus 없이는 가능하지 않습니다. Quality없이 지속 가능한 것은 없습니다. 우리는 Quality와 Sustainable IT 간의 연결이 앞으로 강화될 것이라고 굳게 믿고 있으며, 앞으로도 지속 가능한 IT가 발전할 것으로 기대하고 있습니다.

6) Quality Engineering for Emerging Technologies

Introduction

모든 기술은 해당 기술의 수명을 결정하는 TLC(Technology Life-cycle)라고 불리는 명확한 궤적을 따릅니다. 어떤 기술은 수명이 길고 시간에 따라 약간의 변화가 있는 반면, 어떤 기술은 수명이 매우 짧습니다. 이것은 기술의 발전을 분석하는데 있어 흥미로운 요소입니다.

Emerging Technology를 위한 Quality Engineering에 대해 살펴볼 때, 두 가지 차원을 고려할 필요가 있습니다. 첫 번째 차원은 이러한 신기술이 현실 세계의 Use Case로 구현될 때 Quality의 역할입니다. 이들은 어떻게 테스트해야 할까요? 기존 자동화 도구와 Framework를 적용할 수 있을까요? Quality는 이러한 구현의 성공을 보장하는 데 있어, 중심적인 역할을 할 것입니다.

두 번째 차원은 Emerging Technology가 Quality Engineering Practice에 미치는 영향입니다. 우리는 이전에 인공지능(AI)과 같은 특정 기술이 Quality Engineering에 미치는 영향을 자세히 살펴봤습니다. 보다 많은 Emerging Technology들이 꾸준히 미래에 대한 연관성을 가지고 있습니다.

따라서, 혁신을 따라가기 위해서는 Emerging Technology와 Quality 사이의 2차원적인 관계를 연구하는 것이 흥미로울 뿐만 아니라 필수적입니다. 이번 장에서는 어떤 Emerging Technology들이 조직차원의 전략에서 본질적인 부분이며, Quality Engineering에서 가장 큰 영향을 미치고 있는 것은 무엇인지, Quality Engineering practice를 적용하기 위해 어떤 변화가 필요한지 이해하려고 시도할 것입니다.

Technological big bets for the future

우리는 Quality Engineering 측면에서 살펴보기 전에, Emerging Technology 조직들이 미래를 위해 어떤 영역에 도전하고 있는지 알고 싶었습니다. 대부분의 조직들은 미래를 위한 Decentralization 테마에 도전하고 있는 것으로 보입니다. 설문 응답자의 80% 이상이 IT전략의 우선순위로 Blockchain과 Web 3.0을 꼽았습니다. 우리는 금융 영역을 초월하여 계약 관리, 디지털 자산, NFT(Non-Functible Token) 등으로 넘어가는 모든 Blockchain기반 애플리케이션을 관찰했습니다. Web 3.0은 여전히 정의중에 있으며, 그것이 의미하는 바에 대해 보편적으로 인정되는 정의는 아직 없지만, 동일한 Decentralization 테마 및 Blockchain과 관련이 있습니다.

Impact on quality engineering as a discipline

Emerging Technology가 Quality Engineering에 어떤 영향을 주고 있을까요? 설문 조사 결과는 대부분의 응답자가 Emerging Technology를 통해 원활한 사용자 경험을 주도하고, 테스트 환경 및 데이터 관리에 있어 도약(Leaps)할 수 있도록 도와주길 기대한다는 점에서 아주 흥미롭습니다. Blockchain과 Web 3.0에 우선순위를 두는 것은, 전통적으로 테스트 환경과 데이터를 관리하는 방식에 변화를 가져올 것입니다. 테스트 환경과 데이터를 관리하기 위해 더 적게 통제하고 분산시키는 방법은, 현재의 과제들 중 일부를 해결할 수 있습니다. 그러나, 이것은 새로운 복잡성을 야기할 것입니다.

Is quality engineering still relevant for the future of technology?

그렇다면, Emerging Technology에 대한 Quality Engineering전략이 없을 때의 Risk는 무엇이 있을까요? 응답자의 96%가 Cyber-attacks을 가장 큰 Risk로 선정하였는데, Cyber-attacks의 위협이 대부분의 리더들을 밤을 지새게 만드는 요인으로 보입니다. 비슷한 수준에서 응답자의 92%가 Business 성장 전략과 어긋나게 된다는 답변을 선택한 반면, 91%는 Quality Engineering을 갖추지 못한데 따르는 Risk로서 Emerging Technology 구축비용의 증가를 선택했습니다. 이는 전통적인 우려 사항이지만, 현실 세계의 Use Case로 Emerging Technology를 구현하는 데 있어, Quality가 중심적인 역할을 한다는 강력한 증거이기도 합니다.

7) Value Stream Management

Introduction

Quality & Test Function에 대해 기대하는 것 중 하나는, S/W Development Process에서 Business 및 최종 사용자가 예상하는 Value를 제공하고 있는지 확인하고 보장하는 것입니다.

하지만, 실제로는 많은 Team과 조직들이 Value 성과를 가시화하고 관리가능 하도록 만들어 내기 위해 고군분투하고 있습니다.

올해 우리가 살펴본 새로운 트랜드 중 하나는 가치흐름관리(Value Stream Management)이며, 이것이 얼마나 널리 퍼져 있는지, 어떻게 사용되고 있는지, 그리고 이를 중심으로 어떤 트랜드가 전개되고 있는지에 관한 것입니다.

용어 참고. Value Stream Management

가치 흐름 관리(Value Stream Management)는 IT에서 Business에 이르기까지 S/W의 Value, Flow 및 Quality를 개선하기 위해 검증된 접근 방식입니다.

핵심적으로, Value Stream Management는 SDLC의 거시적 관점을 제공합니다. 조직이 여러 부서 간에 숨겨진 사일로(silos), 장애물, Risk지점 및 비효율성을 발견할 수 있도록 지원합니다. 일단 발견되면, 이러한 Team은 이러한 문제를 해결하고 각 개발 단계에서 고객의 Value를 극대화하는 데 집중할 수 있습니다.

Source: https://valueedge.microfocus.com/what-is-vsm/

Value outcome of quality assurance and test activities

항상 그렇듯이, 우리는 경영층(Senior Management)에게 Quality & Test Activity를 위한 가장 중요한 목표가 무엇인지 물어보았습니다. 이 질문의 결과는 Quality & Test Function에서 조직들이 기대하는 Value가 무엇인지를 나타내고 있습니다.

Business Assurance(Business 성장 및 성과 지원) 및 End-user Satisfaction이 가장 중요한 목표로 꼽혔습니다. 지난해 2위 안에 들던 Quality at Speed 달성 관련 목표는 전반적인 결과에서는 낮아졌지만, 성숙도 높은 자동화기반 Agile Team을 보유하고 있다고 밝힌 기업들은, 이러한 작업 방식을 채택하기 이전의 다른 기업들에 비해, 속도감 있게 Quality를 향상시키는데 더욱 집중하고 있다고 답변했습니다.

우리가 인터뷰한 대부분의 조직에서는 ‘결함을 찾는 것(Finding Faults)’이 업무의 우선순위가 아님을 보여주고 있는데, 이것이 표준적인 기대가 되고 있음을 나타내고 있습니다.

Business value

Quality & Test Function에 대한 가장 중요한 기대 중 하나가 Business 성과와 Value를 보장하는 것이라면, Business 성과에 대한 기대에 맞추어 조정하는 것이 중요합니다. 이를 더 잘 이해하기 위해, 우리는 조직들이 가장 Value있다고 생각하는 것들이 무엇인지 조사했습니다. 우리는 응답자들에게 조직에 가장 큰 Value를 가져다 준다고 생각하는 세 가지 중점 영역을 평가하도록 요청함으로써 이를 수행했습니다.

브랜드 이미지(Brand Image), 신뢰성(Reliability), 고객 유지율(Customer Retention)이 Top 3에 올랐습니다.

이 질문의 결과는 조직마다 다르겠지만, 조직을 위해 이 질문을 하는 것은 Value Stream Management를 향한 올바른 방향으로 나아가는 한 단계입니다.

일단 조직에 필요한 Key Target Value를 알게 되면, Value Stream Mapping 및 Value Stream Management를 통해, 조직이 Value 성과를 보다 효과적이고 지속적으로 관리할 수 있습니다.

Value stream mapping

우리는 응답자들에게 현재 Value Stream Mapping 개념을 사용하고 있는지 물었습니다. 응답자의 대다수(60%)가 거의 매번 이 방식을 사용하고 있다고 답변하였습니다.

Value Stream Mapping은 고객에게 전달하는 재료(Material) 및 정보 흐름 프로세스의 현 상태를 분석하는 Lean Process입니다.

중요한 것이 무엇인지 확인하고, 각 단계에서 시간과 부하(Time and Loads)를 파악하면, 정보가 어디로 이동하는지 알 수 있으며, 낭비요소를 제거하거나 줄이고, 효율성을 개선하기 위한 결정을 내릴 수 있습니다.

Value Stream Mapping 및 사용 방법에 대한 국제 표준은 없지만, 그 원칙은 잘 알려져 있고 Lean Approach로 이해될 수 있습니다. 이 영역에서 자동화 도구들을 더 많이 사용하고 이해함에 따라, 우리는 Value Stream Mapping 점수를 비교하여 어떤 것이 고객 또는 투자자에게 최고의 Value를 제공하는지 확인하는 데 사용될 것으로 기대하고 있습니다.

What should organizations focus on?

Value Stream Management 및 Value Stream Mapping은 조직과 Team이 S/W개발의 실제 Value 성과를 보다 효과적으로 제어할 수 있도록 지원하는 중요한 개념입니다. 우리의 설문조사는 Value 성과에 대한 조직의 기대가 시간이 지남에 따라 발전한다는 것을 보여줍니다. 우리는 또한 Quality Engineering 및 Testing Activity가 Value Stream을 평가, 측정 및 관리하는 데 중요한 역할을 한다는 것을 알게 되었습니다.

World Quality Report에서는 다음과 같은 권장 사항을 제공하고 있습니다.

IT PJT의 Business 목적과 목표가 모든 Team 구성원 및 이해관계자에게 정의되어 있고 명확한지 확인합니다.
Business Owner 및 Project Owner와 함께 Testing & Quality Activity에서 기대하는 Value 성과를 정의합니다.
각 PJT의 Business 목표와 연결된 구체적이고 측정 가능한 Value Indicator를 정의합니다.
Quality 및 Test 결과가 이러한 Value Indicator와 연결되고 관련이 있는지 확인합니다.
이해관계자와 Team 구성원이 Value Indicator의 진행상황 및 발전을 지속적으로 볼 수 있는 Value Dashboard를 구현합니다.

이상으로 World Quality Report(2022-23)에 대한 정리를 마치도록 하겠습니다.(참고로, 이후에 이어지는 내용은 ‘Sector Analysis’이며, 공공, 제조, 금융, 통신, 의료 등 영역별 분석을 담고 있습니다. 해당 내용은 이번 글에서 다루지 않고 있으므로, 전체 내용이 담긴 원문을 참조하여 주시기 바랍니다.)

감사합니다.

[끝]

World Quality Report(2022-23) 소개 (1)

2022-11-17T00:00:00+09:00

연이은 전사 대상 PJT 성능테스트 지원 대응으로 머릿속이 바쁘던 와중에, 다음 PJT로 들어가기 전 2주간 생각할 시간이 생겼습니다. 이때다 싶어, 따끈따끈한 올해의 ‘World Quality Report 2022-23’을 가져와서 한번 살펴보고, 주요 내용들을 여기 Tech Blog에 요약해 보고자 합니다.

World Quality Report 소개

2년전 Tech Blog를 통해 “Global QA & Testing 관련 기술 동향 분석”이란 글에서 World Quality Report를 소개해 드린 적이 있습니다. Performance Engineering영역을 포함하는 넓은 범위를 다루고 있으며, Quality & Testing영역 전반에 대해 분석하고 있는 연례 보고서라 할 수 있습니다.

Source: https://www.microfocus.com/en-us/assets/application-delivery-management/world-quality-report-2022-23

이 보고서의 발간 주체인 Capgemini(cf. 프랑스 파리에 본사를 둔 다국적 정보기술IT 서비스 및 컨설팅 기업), Sogeti(cf. Capgemini의 기술 및 엔지니어링 서비스 회사로, 15개국 약 300개 지점에 25,000여명의 직원을 둔 IT컨설팅 기업), 그리고 Micro Foucs가 함께 매년 World Quality Report를 각 사별 웹사이트에서 무료로 제공하고 있습니다.

특히, 전세계 1,750명의 CIO와 Senior Tech Leaders들을 대상으로한 설문조사를 기반으로 동향 보고서가 작성되고 있기 때문에, Global시장의 현재 흐름을 이해하고, 앞으로의 방향성을 찾아가는데 있어 도움을 줄 수 있는 자료라고 생각합니다.

Source: https://www.sogeti.com/explore/reports/world-quality-report-2021-22/

이번 글에서는, 2년전 우리가 살펴보았던 Quality & Testing관련 기술동향 대비, 올해에는 어떠한 부분들에 대해 더 강조점을 두고 있는지 살펴볼 수 있도록, 주요 내용 위주로 두개의 글로 나누어 요약해보고자 합니다. 전체 원문이 필요하신 경우, 위의 Micro Focus 링크를 참조하셔서 직접 다운로드 받으실 수 있습니다. 이제 함께 Global 기술동향을 살펴보러 가실까요!

1. Executive Summary

A NEW REALISM

COVID-19 Pandemic 이후로, 우리는 기술적인 진보를 향한 엄청난 추진력들에 대해 목격한 바 있습니다.

지난 2년 동안은, 그 어느때보다도 빠른 Digital Platform의 개발, 애플리케이션 환경의 현대화(Modernization of the Application Landscape), Cloud로의 전환, 그리고 Data분석 및 관리기술에 대한 투자 등을 그 특징으로 들 수 있습니다.

Machine Learning, AI Technology, 그리고 End-to-End Automation의 발전이 이러한 모든 개발과정을 지원하고 있습니다.

한편, 오늘날의 조직들은 COVID Pandemic보다 새롭고 잠재적인 도전(ex. 지정학적 불안정 요인, 공급망 붕괴, Domain별 숙련된 전문인력의 심각한 부족, 치솟고 있는 전세계 인플레이션 현상, 잠재적인 경제 불황, 환경 및 사회 이슈 등)에 직면해 있습니다. 변화가 우리에게 미치는 영향은 점점 커지고 있으며, 그 변화의 속도 또한 이전보다 더 빨라지고 있습니다.

이 모든 혼란 속에서도 한가지는 분명합니다. 성공을 유지하기 위해서는, 조직들은 변화에 대해 민감하게 대응해야 합니다. 또한, 고객의 Value를 창출하는데 있어 더욱 집중해야 합니다. 지속적인 변화가 요구됩니다. Value 창출 자체가 목표가 되어야 합니다. Agile Development 및 Digital Transformation은 IT의 지속적인 투자를 위한 Key Driver입니다. 이러한 모든 개발활동들은, IT Quality 및 S/W Testing의 지속적인 발전에 있어, 직접적인 영향을 끼치고 있습니다.

“The closer you look, the more you see”는 올해 World Quality Report의 테마입니다. 적절한 자동화 도구 및 자원에 대해 심층적으로 조사하고 활용함으로써, 우리는 IT솔루션이 고객에게 Benefit을 제공하고, 가치있는 성과를 달성할 수 있도록 지원하고 있는지를 파악할 수 있게 됩니다. 이것은 우리에게 있어 Quality Engineering의 본질이기도 합니다.

올해의 조사 결과에서, QA조직은 기존의 순수 S/W Testing에서 실제 Quality Engineering으로, Quality Assurance Function의 발전 및 전환이 그 어느때보다 필요하다는 사실을 분명히 보여주고 있습니다. 지역, 기술, Domain에 걸친 Subject Matter Experts(SMEs)들의 분석 참여 결과와, 조직별로 선별된 그룹들을 대상으로 진행된 심층 인터뷰 결과에서 이 사실을 뒷받침해주고 있습니다.

고객경험, 적기출시(Time to Market), 보안 및 비용문제는 Quality Assurance에서 핵심적인 목표가 되고 있습니다. 실제로, 많은 조직들이 개발에서 단순히 적기출시의 개선만을 추구하던 방향에서, 빠르게 품질 결과를 얻는(Quality Outcomes at Speed) 방향으로 전환해 가고 있습니다.

어떤 조직들은 역할을 Agile Quality Engineering에서 Site Reliability Engineering으로 전환하는 경우도 있습니다. Quality Expert & Team은 Agile Transformation과정에서 핵심적인 역할을 수행하고 있습니다.

심층 인터뷰 과정에서 한 조직은 이렇게 답변했습니다: “DevOps Transformation은 더 빨라져야 합니다. 그리고, 개발과 운영 사이에서 중심이 되는 이 작업을 수행하기에 적합한 위치에 있는 Quality Team이 주도적으로 리딩해 나가야 합니다.”

Quality Assurance에서 Quality Engineering으로 전환하기 위한, 6개의 필수적인 축(Six Essential Pillars)은 다음과 같습니다:

여러 Agile Team 전반에 걸친 품질활동에 대해, 적절한 조정(Orchestration of Quality Activities)이 필요합니다. QA의 역할을 Feature Team내에 포함하는 것이 증가 추세에 있지만, DevOps Team 지원을 위한 Quality Function이나 Quality Support Team 또한 명확히 증가하고 있습니다.
계획, 설계, 실행 및 지속적인 품질 모니터링에 이르기까지, 모든 Testing 유형 및 단계에 걸쳐 Quality 및 Test Activity들이 완벽하게 자동화되어야 합니다. 이러한 End-to-End Quality Automation은, IT개발 프로세스와 완전히 통합되어야 합니다.
Smarter Quality Technologies를 활용하여, Quality Expert가 프로세스 초기부터 품질에 대해 올바른 전략적 결정을 내릴 수 있도록 지원해야 합니다.
Test Infrastructure 및 Test Data Provisioning에 보다 관심을 기울여야 합니다.
잠재적인 품질 위반에 즉각적으로 대응할 수 있도록, 품질지표의 올바른 정의, 추적 및 모니터링이 필요합니다.
Business 프로세스 및 고객을 위한 Value 성과를 보장하기 위해, Quality Team의 Technological Skill 및 Domain Skill Level을 높여야 합니다. Quality Expert는 Testing 및 Engineering Skill에서부터 영역별 Business 전문 지식까지 Skill을 더욱 발전시키고, 자동화 도구 및 기술 플랫폼에 대한 지식을 늘려야 합니다.

이 외에도, 최근 World Quality Report의 설문조사 결과에서는, Quality Engineering에 잠재적인 영향을 주고 있는 2가지의 새로운 영역을 보여주고 있습니다.

‘Sustainable IT’가 올해 처음으로 World Quality Report의 설문조사 대상에 포함되어 진행되었습니다. 애플리케이션의 품질이 Sustainable IT와 직접적인 관계가 있다는 것에 대해서는 모두가 명확한 이해를 가지고 있지만, 많은 조직들에게는 여전히 새로운 주제로서 남아 있습니다. Sustainable Application을 위한 품질 속성이 무엇이며, 어떻게 이것을 효과적으로 측정하고 모니터링해야 하는지에 대해서는, 여전히 우리 대부분이 확인해야 할 사항입니다. 환경의식(Environmental Consciousness)은 이제 전략적인 측면에서도 필수적인 사항이며, Quality Team이 고려해야 할 추가적인 동인(Additional Driver)이자 주제가 될 것입니다.
‘VSM(Value Stream Management)’은 올해 설문조사에서 다루고 있는 또다른 새로운 영역입니다. 이 개념은 여러 분야에서 입지를 굳히고 있습니다. 여기에서 우리는 Business와 IT를 대상으로 S/W를 개발하고 제공하는 활동의 Value에 대해 관리, 통제 및 시각화하는 것을 목표로 하는 조직들을 볼 수 있습니다. 매우 유망한 시각화 도구들은, Quality Team의 순수한 기술적 검증영역에서부터, Business Value에 대한 성과를 보증하는데까지 도움이 될 수 있는 잠재력을 가지고 있습니다. 하지만 이러한 여정에 대해, 대부분의 조직들이 아직 시작하지도 않고 있다는 점이 이번 조사에서 드러나고 있습니다.

2. KEY RECOMMENDATIONS

1) Agile Quality Orchestration

Enterprise System을 포함한 Agile Development Program의 필수적인 부분으로서 Quality Engineer가 참여해야 합니다. Agile환경에서 Quality Engineers가 Technical Skill과 Business Skills을 적절히 제공하는 역량을 갖추는 것은 매우 중요합니다.
개발주기 전체에 대한 품질 지표를 반영하고 있는 측정항목(Metrics)들을 추적하고 모니터링해야 합니다. 예를 들어, “배포실패(Failed Deployments)”라는 측정지표는, Quality Across Team에게 전체를 보는 시각을 제공해줄 수 있습니다.

2) Quality Automation

요구사항과 스토리에 대해, 자동화 기반 접근법을 적용시켜야 합니다.
ROI로 정당화하기 보다는, 고객 및 Business에 최선의 Benefit을 제공하는 것에 초점을 맞추어야 합니다.
하나의 도구로 모든 것을 수행할 수는 없습니다. 업무별로 최고의 도구를 선정하고, 하나의 도구가 모든 일을 하지 않도록 해야 합니다.

3) Quality infrastructure testing and provisioning

Heterogeneous Software Delivery Pipelines을 구축하기 위해, Value Stream을 하나의 플랫폼으로 결합해야 합니다.
Cloud의 강력한 기능을 사용하여, Legacy Environment를 신속하게 구축해야 합니다.
Cloud 및 Infrastructure Testing을 통해, 애플리케이션의 신뢰성(Reliability)을 새로운 차원으로 강화해야 합니다.

4) Test Data provisioning and data validation

Non-Production Workload를 Cloud로 이동시키고 있는, 많은 조직들의 추세를 따라가야 합니다.
Cloud Testing을 전체 S/W개발주기의 한 부분으로 통합해야 합니다.
자동화 기반 데이터 프로비저닝(Data Provisioning) 증가 및 합성데이터 생성(Synthetic Data Generation)방식의 성장에 따른 이점을 활용해야 합니다.

용어 참고. What is test data provisioning?

“테스트 데이터 프로비저닝은 질서있고, 안전하게 자동화된 방식으로, 사용자가 테스트 데이터에 접근하고 사용할 수 있도록 하는 프로세스입니다.” (“Test data provisioning is the process of making test data accessible and available to users in an orderly, secure – and preferably automated – way.”)

Source: https://www.datprof.com/test-data-provisioning/

5) Quality and Sustainable IT

기존의 Quality Frameworks 및 자동화 도구를 개선/활용하여, ‘Sustainable Design Principles’을 달성해 가야 합니다. (ex. Architecture는 얼마나 모듈화되어 있고 재사용 가능한지, Programming Language Resource는 얼마나 집약적인지, Interfaces와 API Call수를 최적화할 수 있는지 등)
Transaction Level에서 환경 측면의 영향도(Environmental Impacts)에 대한 측정을 지원하기 위해, 애플리케이션 성능 모니터링 자동화도구를 커스터마이징해야 합니다.
“Green Quality Gates”을 구축하는 범위로까지 확장할 수 있도록, Sustainable IT의 사회적, 환경적, 경제적, 그리고 인간적 측면에 대해 측정하고, 통제하고, 정량화할 수 있는 일관된 프레임워크를 확보하기 위해, Sustainable IT를 위한 전략의 중심에 품질을 가져와야 합니다.

6) Quality engineering for emerging technology trends

조직들은 다음과 같이 자문해 볼 필요가 있습니다.:

Blockchain, Web 3.0 및 Cybersecurity관련 Quality Engineering Skills을 구축하는 것이, 해당 기술 구현의 성공에 중요할까요?
Physical 및 Digital World 사이의 원활한 사용자 경험을 테스트하려면, 어떤 역량이 필요할까요?
신기술의 성공적인 구현 및 확장을 지원하기 위해, Prototype단계에서부터 필요한 Quality Engineering전략에는 무엇이 있을까요?

7) Value stream management

Business Owner 및 Project Owner와 함께, Testing 및 Quality 활동에서 기대되는 Value 성과에 대해 확실하게 정의되어야 합니다.
각 PJT들이 Business 목표에 연동되는, 구체적이고 측정가능한 Value Indicator를 정의하고, Quality 및 Test 결과가 Value Indicator에 연결되어 연관성을 가지고 있는지 확인해야 합니다.
이해관계자와 Team 구성원들이 Value Indicator의 진척 및 개발을 지속적으로 관찰할 수 있도록, Value Dashboard를 구현해야 합니다.

3. CURRENT TRENDS IN QUALITY ENGINEERING & TESTING

1) Quality Orchestration in Agile Enterprises

Agile 및 DevOps는 오랫동안 존재해 왔으며, 여전히 진화하고 있습니다. 이에 대한 채택은 매년 증가하고 있으며, 고품질 S/W가 제공되는 방식의 발전에 기여하고 있습니다. 지난 10년 동안 Agile Practice는 성숙되어 왔으며, 더 새로운 Practice, Technology, Trend에 초점을 맞춰오면서 상당한 발전이 있었습니다. 이번 장에서는 이러한 동향들에 대해 살펴보겠습니다.

Agile quality at pace

Agile개발은 Business Needs를 신속하게 반영하기 위해, 모든 팀원들의 협업 노력을 통해, 유연성과 속도를 갖추게 하는 접근 방식이 필요합니다.

Agile에서 QA(Quality Assurance)는 유연성을 가지고 더 빠른 속도로 이동하면서도, 애플리케이션의 품질과 신뢰성을 동시에 보장하기 위해 매우 중요한 요소입니다. Agile QA는 Agile Enterprise의 가장 중요한 두 가지 품질 목표인 탁월한 고객 경험 및 Business성과를 보장하는 데 도움을 줍니다. 따라서, Agile QA는 Agile S/W 개발 프로세스의 필수적인 부분이 되어야 합니다.

Agile기반 기업들의 Quality Orchestration작업들은 계속적으로 상승하는 추세를 보이고 있습니다. Agile 및 DevOps가 채택되기 시작하면서, Quality Engineer의 Team구성 및 Skillset 측면에서 발전이 이루어지고 있습니다.

Agile Program에서는, Test Lifecycle 자동화, Agile team들간의 End-to-End Testing, Test환경 및 Data의 유연하고 간편한 Provisioning, Service Virtualization, CI/CD 통합과 같은 Quality Assurance Practice들이 보편적으로 잘 활용되고 있습니다.

이번 설문 조사에 따르면, Agile구현을 위한 주요 성공요인에는 인재 및 기술의 가용성, Business Focus 및 우선순위에 대한 이해, 조직 변화관리에 대한 경영진의 약속(Commitment) 및 지원 등이 포함됩니다.

Agile improves lead time to deliver, enables high quality software, and allows frequent deployments

Agile 및 DevOps는 다양한 방식으로 조직에 영향을 미치고 있습니다. 설문 조사 결과에 따르면, Agile 접근방식이 Time to Market, S/W Quality 및 예측 가능성을 크게 향상시킴으로써, 고객 경험의 개선을 이끌어내고 있음을 알 수 있습니다.

The “safe” bet for enterprise systems

최근부터 Enterprise System의 세계에서도 Agile Process의 채택이 시작되고 있습니다. Enterprise System은 복잡하고 핵심적인 비즈니스 프로세스를 실행하는 관계로, Agile Adoption Journey에 뒤늦게 참여했습니다.

올해 우리는 Enterprise System에서 활용되고 있는 가장 지배적인 Quality 및 Test Approach가 무엇인지에 대해 조사했습니다.

대부분의 팀(65%)은 자동화를 위해 Package-specific Tool을 사용하고 있고, 63%의 팀은 Sprint 인증을 위해 Pre-built Test Case Repository를 사용하고 있으며, 61%의 팀은 CI/CD 파이프라인에서 Testing을 Automatic Quality Gate와 통합하고 있습니다.

Quality engineers are an integral part of Agile teams

올해의 Data는 Agile Scrum Team내에 소속된 Quality Engineer의 존재감이 증가하고 있음을 보여주고 있습니다.

대부분의 IT 조직들이 평균적으로 Agile Team내에 30% 미만의 Quality Engineer를 보유하고 있음을 보여줍니다. 조직의 28%가 최대 36-45%의 Quality Engineer를 보유하고 있는 반면, 조직의 20%는 Agile Team내에서 16-25%의 Quality Engineer를 보유하고 있습니다.

What should organizations focus on?

Agile Quality Methods, Processes 및 Orchestration과 관련하여, 다음과 같은 6가지 권장사항이 있습니다:

Agile 개발 프로그램의 일부로서 Quality Engineer가 참여해야 합니다. Technical Skill 및 Business Skill이 적절히 혼합된 역량은, Agile에 속한 Quality Engineer에게 있어 매우 중요합니다. SEDT Role이 일반적이 되면서, Business Domain Knowledge는 필수적인 Skill이 되었습니다.
Continuous Testing자동화를 통해, CI/CD 프로세스 전반에 걸친 End-to-end Test Automation이 확장되고, 코드 품질이 개선됩니다. 이를 통해, Product Quality를 향상시키는 동시에, 품질 비용을 절감할 수 있습니다.
Automation Test가 일상적인 작업과 쉽게 통합될 수 있도록, 정기적인 CI 파이프라인의 일부로서 실행되고 있는지 확인해야 합니다.
Business Owner가 테스트 활동에 점점 더 많이 참여하고 있으므로, 테스트를 효과적으로 수행할 수 있는 적절한 자동화 도구와 프로세스를 보유하고 있는지 확인해야 합니다.
Enterprise System에 Package-specific tool을 사용하고, Agile Approach에 적합한 Pre-built Libraries를 사용하여 자동화 수준을 높여야 합니다.

2) Quality Automation

Introduction

테스트 자동화는 수십 년전부터 현재까지 우리와 함께 해왔고, 자동화 도구는 그동안 크게 발전해 왔습니다. 우리가 World Quality Report라는 렌즈를 통해 테스트 자동화를 들여다볼 때, 많은 가능성들을 확인할 수 있습니다. 그럼에도 불구하고, 조직들은 이들을 제대로 작동시키기 위해, 여전히 고군분투하고 있음을 알 수 있습니다.

테스트 자동화와 관련하여, 조직들이 직면하고 있는 가장 일반적인 두 가지 도전은 다음과 같습니다.

테스트 자동화가 항상 개발 프로세스에 자연스럽게 통합되고 있지는 않으며, 개발과 독립적인 별도의 테스트 활동으로 구성되어 있습니다.
Team들은 테스트 자동화 도구를 선정하는 데 있어서는 우선 순위를 두고 있지만, 적절한 테스트 자동화 계획 및 전략을 수립하는 것에 대해서는 잘 잊어버립니다.

테스트 자동화가 성공하려면, 적어도 잘 정의된 요구 사항, 적합한 전문가, 올바른 자동화 도구(종종 하나 이상의 도구) 및 충분한 품질의 테스트 데이터를 갖춘 안정적인 테스트 환경이 필요합니다.

Agile Approach가 개발 속도를 높이고 있기 때문에, 현재의 모든 조직들은 적절한 수준의 테스트 자동화가 필요합니다. 그러므로, 테스트 또한 보다 빠르게 수행되어야 하지만, 엄격함을 잃지는 말아야 합니다. 다시 말해서, 너무 많은 Manual Testing은 개발을 따라가지 못할 것입니다.

우리는 설문 응답자들에게 테스트 자동화에 대한 접근 방식을 결정하는 데 있어, 가장 중요한 것이 무엇인지 물었습니다. ROI가 높은 점수를 받을 것으로 예상했지만, 의외로 유지보수성이 1위를 차지했습니다. 즉, 자동화가 성공하기 위해서는, 이를 관리하고 발전시켜야할 Asset으로 고려할 필요가 있다는 사실을 보여주고 있습니다.

Business의 핵심 요구사항으로서, ‘새로운 기술을 적용할 때는 테스트가 필요하다’는 인식들이 있었습니다. Cloud로 전환되고 있는 지속적인 상황이 이러한 흐름에 일정부분 기여하고 있다고 생각합니다.

대부분 조직에서의 우선순위가, 자동화에 대한 기술적 ROI를 정당화하는 것보다는, Business Needs를 충족시키는 것이라는 점과, 조직 내에서 오고가는 대화 내용이 Test Tool비용이 얼마나 드는지보다는, Business에 얼마나 많은 Value를 제공하고 있는지로 바뀌고 있다는 사실을 이번에 확인하였습니다.

Test automation teams do not deliver well enough on promised benefits

자동화를 통해 기대했던 Benefit을 얻는 Team의 비율이 절반 정도밖에 되지 않는다는 점은 실망스러운 결과입니다. Agile Practice를 통해 CI/CD로 전환해온 오랜 변화에도 불구하고, CI/CD와 자동화간의 통합은 기대 이하의 수준이었습니다.

Why is this?

이것은 자동화 도구의 실패일까요? Open-source 및 Commercial Tool은 잘 구축되어 있습니다. 적어도 매일 매일 이 자동화 도구들을 사용하고 있는 사람들에게는, 이 도구들의 역량은 물론, 이들이 가진 한계 또한 이미 잘 알려져 있습니다.

핵심 질문은 다음과 같습니다. Solution의 모든 부분에 대해 확신을 가질 수 있습니까? 당신이 속한 Team이 약속된 Benefits을 제공하고 있더라도, 주어진 Modern IT World의 특성과 상호 연결된 Cloud / API 기반 환경의 복잡성을 고려할 때 일부분은 간과되었을 수 있습니다.

우리는 테스트 자동화 주제를 수년간 연구해 왔지만, 조직이 테스트 자동화를 제대로 작동시키기 위해 여전히 고군분투하고 있다는 사실은 실망스러운 결과입니다. 설문 조사 결과에 따르면, Agile프로세스가 성숙한 Team은 일반적으로 테스트 자동화 활동을 통해 더 많은 이점을 얻을 수 있습니다.

이와 관련한 메시지는 명확합니다: 올바른 프로세스, 명확한 기대, 잘 정의된 요구사항, 그리고 현대 사회에서 성공하기 위해 필요한 Benefit을 얼마나 자주 획득하고 있는지 확인할 수 있는 팀을 보유해야 합니다.

Where does automation give you the most benefit?

자동화는 Front-end를 테스트하거나, Unit Test에서 Drop Down을 테스트하는 것 이상의 것들을 제공할 수 있습니다. 몇 년 동안, Unit Testing과 Functional Testing이 자동화를 위한 노력에서 우위를 차지해 왔습니다.

이제 더 빠르게 구축하고, 데이터 볼륨을 확보하고, 환경을 구축하고, Code Quality Automation Solutions을 구축하여, 이 모든 영역에서 Value를 가져와야 합니다.

What should organizations focus on?

우리의 연구 결과는 Quality Automation Initiative의 Value를 증가시키기 위해, 다음과 같은 권장사항을 제공하고 있습니다.

Quality Automation Expert와 함께 초기부터 작업해야 합니다.
자동화는 요구사항이 생성되는 시점부터 시작되어야 하며, 요구사항과 스토리에 대해 Automation-first Approach를 적용해야 합니다.
자동화를 시작하기 전에, 자동화 요구사항에 대해 합의해야 합니다.
ROI를 정당화하기 보다는, 고객에게 최고의 Benefit을 제공하는데 초점을 맞춰야 합니다.
Tooling 및 Framework에 대해 정기적으로 리뷰해야 합니다.
최소 다음 3년을 위한 로드맵을 수립해야 합니다.
하나의 자동화 도구로는 모든 것을 할 수 없습니다. 업무별로 최선의 자동화 도구를 선정하십시오. 하나의 자동화 도구로 모든 것을 하려고 해서는 안됩니다.
사람에게 투자하십시오. 유니콘을 쫓는 것을 멈추고, Business를 아는 사람들과 함께 일해야 합니다.

변화에 따른 Benefit은 즉각적이지 않습니다. Project Pipeline을 통해 변화가 오고, 사고방식이 조정되고, 변화할 수 있도록 시간을 허용해야 합니다. 그렇게 할때, 자동화를 통해 약속한 Value가 제공될 수 있습니다. 절반 정도가 아닌 아닌, 대부분의 경우에 해당됩니다.

마지막으로, Sustainability는 IT뿐만 아니라 모든 분야에서 성장하고 있는 중요한 트랜드입니다. 우리는 지금 자동화가 어떻게 그것의 이점과 비용을 세상에 보여줄 수 있는지에 대한 생각을 시작할 필요가 있습니다. 자동화 테스트의 탄소 배출량(the carbon footprint)을 알고 계십니까? 조직에서 이에 대해 보고하기 위해, 시간이 얼마나 걸리고 있습니까? 이러한 질문을 받고있는 지금이, 어떻게 그리고 무엇을 할 준비가 되어 있는지에 대해 생각하기 시작할 시점입니다.

다음 글인 “World Quality Report(2022-23) 소개 (2)”에서는, 나머지 아래의 내용들에 대해 이어서 정리하도록 하겠습니다.

CURRENT TRENDS IN QUALITY ENGINEERING & TESTING

Quality Infrastructure Testing and Provisioning

Test Data Provisioning and Data Validation

Quality and Sustainable IT

Quality Engineering for Emerging Technologies

Value Stream Management

감사합니다.

[끝]

Performance CoE 개요

2022-11-11T00:00:00+09:00

지난번 글에서 잠시 언급드린 바 있는 ‘Performance CoE’(or Performance Testing CoE)의 개념과 관련하여, HP에서 2014년에 발간한 “HP Performance Engineering Best Practices Series For Performance Engineers and Managers”라는 자료가 기본적인 이해에 도움을 드릴 수 있을 것 같아, 이번 글에서 잠깐 소개하고 넘어 가고자 합니다.

Source: Micro Focus

이 가이드북은 전체적으로 아래 내용들에 대해 다루고 있습니다.

Introduction to Performance CoE
Build Successful CoE
Operate CoE Successfully
Get People for CoE Success
Conclusion

전체 분량이 62Pgae에 달하기 때문에, 관심을 가지면 좋을만한 기본적인 개념을 다루고 있는 1장의 주요 내용 위주로 정리해 보도록 하겠습니다.

1. Peformance CoE에 대한 소개

Performance Center of Excellence는 숙련된 IT 조직이 추구하는 접근방식이자 그 결과물이기도 합니다. 성능 테스트 체계를 운영하는 방법에는 여러가지가 있지만, 중앙 집중화된 형태로 절차에 기반하여 운영하는 방식이, 적은 시간의 투자로도 비즈니스의 성과를 크게 개선시키고 있다는 사실은, 그동안의 고객 경험을 통해 계속 증명되어 온 바 있습니다.

1) Peformance Engineering의 중요성

소프트웨어 공학은 S/W개발 프로세스를 통제하는 절차, 기법 그리고 자동화도구로 정의될 수 있으며, 생산성의 관점에서 고품질 S/W를 구현하는 기반을 제공합니다.

대부분의 소프트웨어 공학 방법론들은 개발일정 및 예산이 엄격하게 준수되는 상황 하에서, S/W가 ‘기능 요구사항’을 만족시키는 것을 보증하는데 초점을 맞추고 있습니다.

한편, ‘성능 요구사항’의 경우에는, 그 필요성이 점차 증가하고 있으면서도, 관리하기는 점점 더 어려워지는 현실에 처해 있습니다. 많은 경우에, 시스템의 성능이 개발주기에서 너무 늦은 시기에 평가되고 있습니다.

고품질 애플리케이션 제공에 대한 요구는 날이갈수록 높아지고 있지만, 개발일정은 빠듯하고, 조직들은 다양한 지역에 분산되어 있으며, 숙련된 직원들은 빈번히 이직하고 있는 현실의 상황에서, 애플리케이션 테스트는 더욱 쉽지 않은 상황이 되어가고 있습니다.

한 단위조직에서 적절한 기술을 확보하고 있다고 해도, 이러한 전문성이 전체의 조직까지 전파되기는 쉽지 않습니다. 여전히 많은 회사의 IT부서들에서 정보가 공유되지 않고 있으며, 공통의 프로세스가 없는 채로 일하고 있고, 성능에 대한 인식 또한 부족한 현실에 직면해 있습니다.

더 적은 자원으로 더 많은 일을 해야만 하는 현실에 직면해 있는 많은 조직들은, 테스트 관리방법론만 적용해오던 기존의 방식에서, 테스트 자원의 효과적인 관리를 지원하는 자동화 기반 테스트 관리 도구 환경으로 전환함으로써, 지역별로 분산되어 있는 다양한 프로젝트팀들을 효과적으로 지원하고 있습니다.

이러한 접근법의 하나로서 Performance CoE모델은, 전사조직을 아우르는 프로세스의 표준화, 품질, 일관성, 효과 및 효율성의 향상을 이끌어내고 있습니다.

Performance CoE는 일관성이 없는 자동화 도구들의 사용이나, 비효율적인 성능테스트 그리고 부정확한 분석 요소들을 제거하는 역할을 수행합니다. 또한, 애플리케이션 핵심 성능지표의 가시성을 제공하고, 모든 구성원들에게 정보를 공유함으로써 비즈니스 목표와 일치시키는 작업이 가능하도록 하는 중앙 플랫폼을 제공합니다.

2) 성능테스트가 아직 충분하지 않은 이유

만약 성능 테스트 전문가가 개별 프로젝트의 테스트 그룹에만 소속되어 있다면, 전사에서 개발되는 모든 애플리케이션들이 동일한 표준에 따라 적절하게 테스트 되고 있다는 것을 보증하기는 어렵습니다. 또한, 새로운 기술들이 출현하였을 때, 서로다른 조직에 속한 구성원들이 신기술을 지원하기 위해 요구되는 전문성을 모두 갖추기도 쉽지 않습니다.

많은 경우에, 각각의 PJT팀들은 개별팀원들이 선호하는 각자의 도구들을 사용하여 자체적인 성능 최적화 프로세스를 만들어냅니다. 그 결과, 관리되지 않는 워크플로우, 적용사례, 도구 및 기법들의 혼재하는 현상이 발생하게 됩니다. 결국, 문서화되기도 어렵고, 서로간에 통합되지도 않으며, 다른 PJT그룹으로 전파하기도 힘든 상황이 됩니다. 이러한 상황은 비효율적인 것 이상의 문제들을 불러오게 됩니다. 수행에 따른 복잡성 및 비용을 증가시키며, 구성원들이 Skill을 개발할 의욕마저 저하시킬 가능성이 있습니다.

상용환경 배포 계획을 세울 때, 많은 회사들이 개발 프로세스 후반에 대상 시스템의 성능 테스트를 수행하고 있습니다. 그 결과, 성능이슈들의 발견 및 해결이 충분히 되지 않은 채, 시스템의 환경설정 최적화가 미흡한 상태에서 상용배포가 이루어지는 경우가 많으며, 이때 성능개선에 사용되는 자동화 도구들 또한 서로 이질적이어서 협업을 이뤄내기도 쉽지 않습니다.

3) CoE의 정의

Center of Excellence라는 용어가 어느 회사에서나 널리 사용되는 조직명칭은 아닙니다. 어떤 곳에서는 역량센터(Competency Center), 테스트센터(Central Testing), 애플리케이션 테스트 센터(Application Testing Center), 또는 단순히 테스트그룹(Testing Group)으로 부르기도 합니다.

하지만, Center of Exellence라는 용어 자체는 성능테스트 분야 뿐만 아니라, 관련 서적에서도 사용하고 있는, 비즈니스 환경에서 가장 인기있는 용어이기도 합니다.

Industry Analyst Firm에서 근무하는 Voke의 연구에서는, PCoE에 대한 정의를 다음과 같이 인용하고 있습니다.

Performance CoE는 비즈니스 요구사항을 만족시키기 위해, 애플리케이션의 성능을 검증하고 향상시키는데 초점을 맞춘 내부역량센터(Internal Competency Center)입니다.

이 조직은 성능 최적화 프로세스를 지원하기 위한 관리 및 자동화 플랫폼을 제공할 뿐만 아니라, 조직이 CoE모델에서의 성능 검증 및 최적화의 중요성을 이해할 수 있도록 하기 위한 컨설팅 및 지원 서비스를 제공합니다.

Performance CoE를 통해, PJT팀들은 전문성, 자동화도구 및 CoE가 구축해 놓은 Best Practice 등 모든 것을 활용할 수 있습니다.

이 모델이 가지는 장점은 다음과 같습니다.

중앙 집중화 기반 인프라 및 전문지식

Test Lab, 자동화 도구, 성능전문가 및 Best Practice가 통합되어 있어, 모든 PJT팀들이 단일 접점을 통해 편리하게 이용할 수 있으며, 고가의 License자원을 중복적으로 확보할 필요가 없습니다.

전사 테스트 조직이 점차 많은 지식을 쌓아감에 따라, 조직 전반적으로도 이득을 얻게 됩니다. 전사 테스트 조직이 테스트 수행 및 분석의 효율성을 지속적으로 개선함으로써, 보다 높은 수준의 테스트 수행 및 품질향상이 활발히 일어날 수 있게 됩니다.
보다 빠르고 더나은 프로세스

표준화된 자동화도구 및 프로세스는 일관성, 비용절감, 강화된 프로세스의 빠른 구현을 가능하게 합니다. 개별 테스트 그룹이나 테스트 장비별로 각각 시나리오와 스크립트를 유지보수하는 대신, 공유하고 재사용하기 쉽도록 자료를 중앙화할 수 있습니다. 이를 통해, 테스트를 생성하는 시간을 줄일 수 있게 되어, 보다 효율적인 테스트를 할 수 있도록 지원합니다.
비즈니스 관점

Performance CoE모델은 성능을 시스템이나 컴포넌트 관점이 아닌, 비즈니스 및 최종사용자 관점에서 측정합니다.

시스템을 테스트하는 활동이 집중화되어 있을 때, 보다 테스트 장비를 사용하기 쉬워지며, 24X7 Testing이 가능하게 되어 효율적으로 사용할 수 있습니다.
실용적이고 달성 가능한 목표

Performance CoE를 구축하는 것은 달성 가능한 목표입니다. 작게 시작할 수 있으며, 기존 리소스를 활용하면서, 가치가 인정될 때 확장하면 됩니다. 시간이 지남에 따라 경영진이 가치를 인식하게 되면서, 인적자원, 서비스, 그리고 역량을 반복적으로 확장할 수 있습니다. CoE가 정확하게 구현되었다면, 그 가치는 증명될 것입니다.

일반적으로, Performance CoE는 TCO(Total Cost of Ownership)를 줄이면서 성능과 가용성을 개선할 수 있으며, 조직에 기여하는 최고의 구성원들을 확보할 수 있습니다.

CoE를 구성하는 요소들이나 테스트 그룹의 중앙집중화가 효율성 개선에 기여한다는 것에 반론의 여지는 없습니다. 그러나, 대부분의 개선이 ‘조직구조의 변화’에 의해서만 발생하고 있는 것은 아니며, ‘Best Practice의 축적’과 ‘조직차원의 행동변화’에 따른 영향도 큰 것이 사실입니다.

4) CoE Phases

PCoE를 발전시키는 것은 지속적인 프로세스의 과정이므로, 회사의 현재 성숙 수준(Maturity Level)을 이해하고, 테스트 그룹의 위치를 평가하는 것이 중요합니다. 조직이 ‘생산성의 극대화’를 달성하기위한 여정을 이제 막 시작한 상태라 하더라도, 프로세스를 전체적으로 조망하면서 다음 단계로의 계획을 수립하는데 도움을 얻을 수 있습니다.

Manual Testing

이 단계는 가장 기본적인 테스트의 유형입니다. 자동화 도구를 사용하지 않고 있습니다. 애플리케이션의 성능을 검증하기 위한 활동이 가끔씩 이루어지기 때문에, 상용환경에는 시스템 차원의 성능이슈들이 항상 존재하고 있습니다.

Project Testing

이 단계는 실제 자동화기반 테스트 환경으로 가는 첫단계로 설명될 수 있습니다. 각 부서별로 수행되며, 해당 부서가 사용하는 애플리케이션에 한정됩니다. 각 부서는 각자의 성능테스트 도구와 라이선스를 개별 구매하고, 자체적인 수행절차와 인프라를 이용해 성능테스트를 수행합니다. 각 그룹간에 지식은 공유되지 않으며, 비즈니스 고객과 직접적인 접점이 없는 개발자에 의해 성능테스트가 수행되기 때문에, 애플리케이션의 목표와 중요성에 대한 시각은 가지지 않은 채로 성능테스트가 진행됩니다.

성능 테스트는 다음과 같은 사유로 인해 그 성과가 제한됩니다:

테스트 인프라 및 라이선스의 재사용 불가
성능 전문가 및 기술에 대한 재사용 불가
비즈니스 목표에 맞게 수행을 조정하는 방안 부재

Standardization

이 단계는 진정한 Performance CoE로 가는 첫 단계입니다. 어떤 조직이 H/W자산과 S/W라이선스가 결합된 상태로 전환을 추진하고자 한다면, 그 이유는 성능테스트를 위한 실환경 수준의 인프라를 구축하고 관리하는데 엄청난 비용이 든다는 것을 잘 이해하고 있기 때문입니다.

만약 비즈니스 라인별로 Test Lab이 존재한다면, 이 비용은 중복적으로 발생하게 됩니다. 반면, 정확한 성능테스트 환경을 구축하는데 실패하게 되면, 그 결과는 상당히 치명적일 수 있습니다.

Performance CoE는 성능테스트 수행에 사용되는 S/W와 H/W를 통합하기 위한 촉매제 역할을 수행할 수 있으며, 자산의 효율적 사용과 운영/유지보수 비용 절감을 통해, 전체적인 비용 절감 효과를 가져올 수 있습니다. 여기서 CoE는 조직의 전체 비즈니스를 대상으로 인프라를 제공하고, 사용자를 지원하는 역할에 초점을 맞춘 부서의 역할을 제공합니다.

하지만, 이 시점에서도 조직은 성능 테스트 엔지니어의 Skill Sets를 개발하고, 지식을 공유하는 것에 대한 중요성을 여전히 인식하지 못하고 있습니다. PJT팀과 경영층은 Performance CoE의 장점을 이제 인지하기 시작하고 있으며, CoE는 보다 광범위한 성능 이슈들을 다룰 수 있도록 확장되어 가게 됩니다.

Centralization

이 단계는, 다양한 S/W개발 및 배포주기별로 성능 테스트 팀이 보다 깊게 참여하는 단계입니다.

여기서 Performance CoE팀은 테스트 계획, 스크립트 작업, 수행 등을 포함하는 실제적인 성능 테스트 서비스를 제공합니다.

일반적으로, 대부분의 비즈니스 조직들은 자체적으로 성능테스트 관련 지식, Best Practice 및 프로세스를 사용하는데 한계를 가지고 있지만, CoE모델은 성능 테스트 전문가의 경험과 조언에 대해 쉽게 접근하여 활용할 수 있도록 지원합니다.

CoE는 전문영역이면서 희소성을 가지는 Performance Engineering의 지식에 대해 육성할 수 있는 기회를 제공합니다. 구성원들이 다양한 비즈니스 및 IT 환경에서 문제들을 해결함으로써, 각각의 Architecture가 작동하는 방식에 대한 이해 수준을 높일 수 있게 됩니다.

이러한 모든 것들은 재능있는 구성원들을 확보하고, 계속 유지하는데 추가적인 요소로 작용합니다.

Performance Authority

CoE가 최고수준의 단계로 올라가게 되면, ‘Performance Authority’가 되어 애플리케이션 개발, 배포, 운영의 일상적인 부분에 모두 포함되어, 성능 및 비용효율성에 초점을 맞춘 조직 문화에 기여하는 형태로 변화하게 됩니다.

‘Performance Authority’모델 하에서는, 전반적인 성능 향상에 초점을 맞춘 일관된 프로세스를 거치지 않고 상용환경으로 바로 넘어가는 애플리케이션이란 더이상 존재하지 않게 됩니다.

Performance Authority에서는 아래의 기본원칙에 대해 지원하고 있습니다:

Support

Performance CoE는 비즈니스 조직들을 대상으로 성능 서비스 또는 성능 전문가를 지원합니다.
Guidance

표준, 방법론, Best Practice, 자동화 도구 및 지식공유 사이트 등을 통한 가이드를 제공합니다.
Shared Learning

공유기반 학습을 장려하기 위해, 교육훈련 및 인증, 역량 평가, 팀 구축 및 공식적인 역할 부여등을 제공합니다.
Measurements

CoE는 결과에 대한 측정지표의 사용을 통해, 조직의 가치를 입증하고 산출물을 정당화해야 합니다. 측정은 CIO 및 비즈니스 가시성에 있어 기초가 됩니다.
Governance

자원(비용, 인력 등)을 효율적으로 활용하고, 모든 잠재력을 현실화시키는 것은 CoE의 중요한 기능 중 하나입니다. 이를 통해, 조직은 가장 가치있는 PJT에 투자할 수 있게 되고, 서비스 제공 규모에 맞게 규모의 경제를 달성하게 됩니다.

이러한 원칙들이 올바르게 구현될 때, 보다 효과적인 CoE가 구축될 수 있으며, 전체적인 고객만족에도 기여할 수 있게 됨으로, 조직차원의 SLA(Service Level Agreements)를 초과 달성할 수 있게 됩니다.

이상으로 PCoE에 대한 소개 글인 “HP Performance Engineering Best Practices Series For Performance Engineers and Managers” 내용 중 1장에 대한 요약 정리를 마치도록 하겠습니다. 추가적으로 더 궁금하신 사항이 있는 경우, 위에 안내해드린 출처 링크를 통해 해당 자료의 전문을 참조하시기 바랍니다.

감사합니다.

[끝]

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

2022-11-04T00:00:00+09:00

몇 해 전, 한 임원분의 면담 요청으로 테스트 업무에 관한 이야기를 약 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이 오거나, 건강 측면에서 무리가 와서 즐거움보다는 심리적인 부담으로 다가올 수 있기 때문에, 갑자기 추워진 요즘 날씨에 모두들 감기 조심하시고, 부디 건강하게 겨울을 맞이하시길 바라면서 이번 글을 마치도록 하겠습니다.

감사합니다.

[끝]

Self Service를 위한 VuGen에 대한 관점의 전환

2022-09-08T00:00:00+09:00

이번 글에서는, 홍성진 매니저님의 최근 글인 “Integration of Loadrunner Cloud and VUGEN“에서 잠깐 언급하신 ‘VuGen’과 관련하여, PJT팀이 Self Service를 시작하기 위해 필요한 관점의 전환에 대해 정리해 보고자 합니다. VuGen 자체의 전문적인 사용방법은 홍성진 매니저님이 추후 연재하실 예정(!)이므로, 여기서는 ‘관점의 변화’ 측면에서 간단히 정리해 보도록 하겠습니다.

1. LoadRunner VuGen 사용자가 적은 이유

VuGen은 ‘Virtual User Generator’의 약자로, LoadRunner에서 부하발생을 위한 Script를 작성하기 위한 도구입니다.

성능테스트 시장점유율 1위이며, 다른 성능 테스트 도구 대비 사용자 측면에서 매우 편리한 기능을 제공하는 완성형 도구임에도 불구하고, 아직까지도 VuGen을 이용하여 Script를 작성하고 LoadRunner기반 성능 테스트를 수행할 수 있는 인력이 드문 현실은 어떤 이유들 때문일까요?

이 궁금증을 풀기 위해, 우선 과거로부터 현재까지 LoadRunner와 관련하여 어떠한 이슈와 변화들이 있었는지에 대해 간단히 살펴보겠습니다.

2. 기존 Lock Key방식의 License가 가져온 이슈들

기존에는 LoadRunner를 구입하면, 그 구성요소로서 VuGen, Controller, Analysis 3개의 Applicaion이 1Set의 제품으로 제공 및 설치 되었습니다. 이때 적용되는 License가 특정 서버 또는 특정 노트북에 한정되어 물리적인 Lock Key 방식으로 묶이게 되기 때문에, 성능 테스트 담당자 외에 다른 구성원들이 쉽게 접근하기는 구조적으로 어려운 도구였던 것이 사실입니다.

한편, 일부 회사(ex. 금융, 통신 등)에서는 Permanent License를 구입하여 내부망 서버에 LoadRunner 제품을 설치한 후, 원격데스크톱 접속으로 접근하도록 하여, 회사 내 여러 PJT팀들이 License를 공유하는 방식으로 사용하기도 했습니다. 하지만, 이 경우에도 하나의 License를 동시에 사용하는 것은 불가능한 구조이기 때문에, 한 날짜에 두 팀이 성능테스트를 해야 한다면, 한 팀은 주간에, 다른 팀은 야간에 밤을 새서 해야만 하는 상황이 발생하게 됩니다.

PJT 상황 때문이 아닌, 단지 Tool License 사용제약 이슈로 인해, 시스템 Open 막바지 시점에 바쁜 엔지니어들이 성능테스트를 위해 야간과 새벽에 근무해야 하는 비효율적인 상황들이, 과거부터 근 20여년이 지난 현재까지도 간간히 발생하고 있습니다.

3. PJT현장에서의 학습 기회 제한

위와 같이, 전사차원의 성능 테스트 도구가 있음에도, License가 특정 서버 또는 특정 노트북에 종속되게 되면, PJT 현장의 구성원들 입장에서는 해당 도구를 써 볼 수 있는 기회가 제한되는 상황이 발생하게 됩니다.

PJT 개발자 입장에서 보면, 성능테스트 단계에서 LoadRunner기반 성능테스트 수행 상황을 자주 접하고, 성능테스트 담당자와 함께 계획/설계 단계에 긴밀히 협업하여 Script 작성을 지원하고, 밤낮으로 성능 테스트를 수행하는 횟수가 점차 늘어감에도 불구하고, 직접 Script를 작성해보고 테스트를 수행해볼 수 있는 기회는 거의 없는 것이 사실입니다.

HP에서 LoadRunner ‘Community Edition’이라는 이름으로 뒤늦게 50Vuser까지 All Protocol에 대해 무료로 사용해볼 수 있는 Full Version이 제공 되었음에도, PJT에서 이미 LoadRunner는 ‘좋은건 알지만 비싸서 써보지는 못하는 도구’로서의 이미지가 굳혀진 터라, 개발자 입장에서는 쉽게 접할 수 있는 오픈소스도구인 JMeter 등에 먼저 관심이 가게되는 것은 어쩌면 당연한 결과였는지도 모릅니다.

그 결과, LoadRunner를 사용하여 성능테스트를 수행할 수 있는 사람은 전사조직의 몇몇 성능테스트 담당자 아니면 외부 벤더의 성능테스트 전문가 정도로 유지되다 보니, 2000년대 초중반부터 LoadRunner를 학습하고 성능테스트를 수행해온 그 당시 2~30대의 전문인력들이 현재까지 그 명맥을 이어오고 있을 뿐, 회사 내외부를 살펴보더라도 신규 인력이 학습을 통해 LoadRunner기반 성능전문인력으로 새롭게 성장하여 나타나는 경우는 보기 드문 상태가 된 것 같습니다.

4. Agile 개발 팀을 위해 탄생한 LoadRunner Cloud

LoadRunner Cloud는 아주 새로운 제품은 아닙니다. 지난 2014년 7월에 HP에서 새로운 Cloud기반 성능테스트 도구로서 ‘StormRunner Load’라는 이름으로 먼저 출시된 바 있습니다.

출시 당시의 기사를 잠깐 살펴보면 다음과 같습니다.

HP refreshes Performance Testing Suite with StormRunner Load for Agile app development teams

By Jamie Hinks published September 16, 2014

HP는 Agile 개발 팀이 간단하고 직관적이며 확장 가능한 Cloud 플랫폼을 사용하여, 애플리케이션 제공 및 품질을 가속화할 수 있도록 설계된 새로운 소프트웨어 솔루션으로서 성능 테스트 제품군을 업데이트했습니다.

HP StormRunner Load라고 불리는 이 솔루션은 LoadRunner 및 Performance Center를 포함하는 기존 성능 테스트 제품군에 합류하여 테스트를 크게 개선하는 데 특히 중점을 둡니다.

“기업이 애플리케이션과 솔루션을 Cloud로 계속 마이그레이션함에 따라, 사용자 수 증가에 따른 애플리케이션 프로그램의 성능이 저하되지 않도록 해야 합니다.”라고 HP Software의 애플리케이션 제공 관리 총괄 관리자인 Raffi Margaliot은 말했습니다.

“HP StormRunner Load는 Agile 팀이 확장 가능한 고성능 클라우드 기반 최신 앱을 제공하는 동시에, HP에 대한 기존 투자를 활용할 수 있도록 특별히 설계되었습니다.”

StormRunner Load는 앱을 개발할 때 더 스마트한 테스트 기술을 사용하려는 Agile 개발 팀을 지원하기 위해 노력하고 있습니다. 이를 통해 팀은 솔루션 간에 테스트 스크립트를 재사용하고 StormRunner Load를 사용하여 동적으로 확장할 수 있습니다.

Source: https://www.itproportal.com/2014/09/15/hp-refreshes-performance-testing-suite-stormrunner-load-agile-app-development-teams/

StromRunner Load 출시의 목적은 위의 기사에서 강조하고 있듯이, Agile팀이 Cloud기반 성능테스트 환경에서 빠르게 성능측정을 수행하고, 고품질의 애플리케이션을 출시할 수 있도록 지원하는데 그 목적이 있음을 알 수 있습니다.

문제는, Agile 환경하의 PJT 개발팀 입장에서는 기존의 LoadRunner조차도 아직 익숙하지 않은 도구이기 때문에, ‘Scalable, High-Performing Cloud-based Modern Apps’ 개발을 돕기위한 성능테스트 도구로서 StormRunner Load가 제시되더라도, 신속하게 이 Tool을 적용할 준비는 전혀 되어있지 않았다는 점입니다.

이런 상황을 근본적으로 개선하기 위한 방향으로서, 2020년 Micro Focus는 지난번 우리가 함께 살펴본 바 있는 LoadRunner Family “re launch”를 추진하게 된 것이 아닌가 생각이 듭니다.

5. VuGen과 LoadRunner Cloud

우리가 그동안 살펴 보았듯이, LoadRunner Cloud는 더이상 특정 회사 내부망의 서버나 전사 성능테스트 조직이 보유한 특정 노트북에 License가 종속되어 존재하지 않습니다.

PJT에서 Cloud기반으로 구동되는 LoadRunner Cloud를 사용하고 싶다면, 원하는 시간에 웹 브라우저로 바로 접속하여, 부하발생하고 싶은 국가와 지역을 선택하여 바로 부하를 줄 수 있습니다.

부하 발생 및 실시간 모니터링하는 Controller와, 수행 결과를 바로 분석할 수 있는 Analysis의 기능들이 모두 LoadRunner Cloud로 통합되었기 때문에, 이제 남아있는 것은 VuGen입니다.

기존에는 VuGen, Controller, Analysis가 LoadRunner라는 하나의 제품으로 구성되어 있었다면, 이제는 VuGen과 LoadRunner Cloud로 두개의 역할만이 구분되어 사용됩니다.

비용 측면에서도, Vugen은 무료로 다운로드 받아 사용 가능하기 때문에 Script 작성과 사전 Tool 검증은 부담없이 수행하고, LoadRunner Cloud에서 실제 부하발생이 시작되고 끝나는 시간동안에 대해서만 발생하는 부하 비용(ex. $0.3/VUH)을 고려하면 됩니다.

6. Self Service, 변화의 시작

개발자가 ‘본인이 만든 애플리케이션’을 대상으로 성능 Script를 작성하는 것은, 제 3자인 성능테스트 담당자가 짧은 시간동안 구조를 익히고 Script를 작성하는 것보다 훨씬 쉽고 효율적입니다. Script 작성을 위해 필요했던 성능 테스트 담당자와 개발자간의 회의 및 질의과정이 Self Service를 통해 상당부분 단축될 수 있습니다.

단위 업무별 성능 측정 및 개선 작업이 사전에 Self Service로 이루어진다면, 성능 테스트 단계에서는 남아있는 주요 성능이슈들을 모아 종합적인 관점에서 성능테스트 전문 조직과 함께 측정 및 최적화하는 마지막 과정을 효과적으로 수행할 수 있게 됩니다.

정리하면, PJT 개발자 입장에서 VuGen을 통해 부하를 발생하고자 하는 대상 업무의 Script 작성이 가능한 단계로 넘어올 수만 있다면, 바로 대상 시스템의 성능을 측정하고 결과를 확인하는 환경은 이미 준비되어 있다는 것을 LoadRunner Cloud는 말해주고 있습니다. 이러한 Cloud기반 환경에서, ‘관점의 변화를 통한 Self Service의 시작’은 생각보다 멀리있지 않은 것 같다는 생각을 하며 이번 글을 마칩니다.

감사합니다.

[끝]

JEUS Bug에 의한 OutOfMemoryError 현상 - WAS Troubleshooting 사례(3)

2022-09-02T00:00:00+09:00

JEUS Bug에 의한 OutOfMemoryError 현상 - WAS Troubleshooting 사례(3)

OO 업무시스템은 총 6대의 JEUS instance를 clustering 구성해 운영중인데, 간헐적으로 원인을 알 수 없는 OutOfMemoryError가 발생하며 JEUS Instance가 Hang-up이 걸린다고 한다.

문제 발생시점이나 패턴에서는 어떠한 규칙성도 찾을 수가 없는 상황에서, Hang-up이 발생할 때까지 마냥 기다릴 수는 없는 노릇이다.
그렇다면 남아있는 관련 로그만을 통해 Root Cause를 밝혀내고 개선할 수 있을까?

차근차근 알아보도록 하자…

원인 파악을 위한 첫걸음 - Thread dump 분석

앞선 포스트에서 언급했듯이 Java 쓰레드 덤프는 모든 JVM 관련 issue를 파악하기 위한 기본이 된다.
이번에도 역시 문제발생 시점의 Thread dump를 가장 먼저 분석해 보도록 하자.

아래는 AIX Javacore 파일에서 OutOfMemoryError 발생 시점과 발생할 당시의 Heap Memory 상태를 나타내는 부분을 발췌한 것이다.

위 로그를 보면 Javacore가 생성된 이벤트가 “Dump Event systhrow (00040000) Detail java/lang/OutOfMemoryError”라고 나오는 걸 보아 해당 dump가 OOME가 발생할 때 생성된 것임을 확인할 수 있다.

또한 dump 생성 시점의 Heap Memory 상태를 보여 주는 MEMINFO 부분을 보면 설정된 전체 Heap 2GB 중에 실제로 사용중인 메모리는 약 470MB 뿐이고 나머지 약 1.5GB가 Free Memory인 것을 알 수 있다.

전체 Heap Memory(2GB)의 약 75%(1.5GB)가 Free Memory로 남아 있는 상황에서 OutOfMemoryError가 발생한다?

뭔가 이상하다… 앞 뒤가 맞지 않는다…

Memory 사용 추이 분석 - GC Log 분석

Heap 덤프와 GC log는 JVM의 모든 Memory 관련 issue를 파악하기 위한 기본이 된다.

앞 서 Thread dump를 분석하였으니 이번에는 OutOfMemoryError가 지속적인 메모리 누수에 의한 것인지, 아니면 일시적인 대용량 메모리 요청에 의한 것인지를 판단하기 위해 GC Log를 분석해 보자.

OutOfMemoryError가 발생하기 前 약 3일간의 메모리 사용추이를 검토한 결과, 지속적인 Memory Leak 등의 현상은 보이지 않았다.
(그도 그럴것이 OOME 발생 당시에도 1.5GB의 여유 공간이 남아 있었지 않은가…)
즉, 이번 OOME는 Application에서 특정 트랜잭션을 처리할 때 순간적으로 1.5GB 이상의 대용량 메모리를 요청하여 memory allocation failed가 발생한 것으로 유추할 수 있다.

도데체 어떤 업무를 처리하는데 한꺼번에 1.5GB가 넘는 메모리가 필요하단 말인가…
Application의 업무 처리 로직이 잘 못 된 것인가…?

GC Log의 추가적인 분석을 통해 대용량 메모리 할당을 요청한 트랜잭션을 추적해 보도록 한다.

GC Log의 아래 부분을 해석해 보자.

일단 태그 시작이 allocation-unsatisfied 이다. 메모리 할당에 실패했다는 뜻이다.
그 뒤로 threadId가 나온다. 이 Id로 Thread dump에서 해당 트랜잭션을 찾을 수 있으리라…
연이어 bytesRequested가 나오는데 2,013,331,464 byte… 즉 1024*1024 byte가 1GB이니 무려 약 1.9GB이다.

이 넘이 범인(?)임에 틀림없으렸다!!

Thread dump와 GC Log의 교차 분석

이번에는 위 GC Log에서 발견한 threadId로 Thread dump에서 더 많은 정보를 얻어보도록 하자.

Thread dump의 아래 부분을 분석해 보자.

threadId로 추적된 마지막 라인을 보면, 1.9GB의 메모리를 요청한 object class는 “0x0000000030028500” 이며 memory space id(주소)는 “0x0000010010734B30” 이나 최종적으로 NULL을 리턴받았다는 것을 알 수 있다.(즉 memory를 할당받지 못함)

또한 object class id를 추적해 보면 대용량 메모리를 요청한 object는 아래와 같이 “B”(bytecode 표기로 byte를 의미) 타입으로 byte 자료형임을 알 수 있다.

마지막으로 해당 thread가 수행중이었던 작업을 살펴 보면 아래와 같다.

Stacktrace 내용으로 알 수 있듯이 1.9GB 메모리를 요청한 Class/Method는 JEUS 엔진에서 사용되는 내부 모듈이며 정확히는 다음과 같다.

LoginInformation.readLoginInformation() (144라인)

그렇다면 이것은 JEUS 엔진 자체의 Bug 인가…?
지금까지 밝혀진 내용만으로도 충분히 가능성이 있지만, 좀 더 확실하게 접근하기 위해 소스 코드도 분석해 보자.

JEUS 엔진 내부 코드 분석 - class 역 컴파일

문제가 된 jeus 내부 모듈(LoginInformation.java)을 역컴파일해서 java 소스를 검토한 결과, 아래와 같이 144 라인에서 scope를 표현하기 위한 byte 자료형태의 memory를 요청하고 있었다.

자~ 지금까지 분석한 내용을 정리하면 다음과 같다.

FACT !!

문제 당시 1.5GB 이상의 여유로운 free memory가 존재했었음에도 OOME가 발생됨

특정 트랜잭션 하나가 한 번에 1.9GB의 memory를 요청하였음

1.9GB를 요청한 자료형은 byte 형태임

대용량 메모리를 요청한 Job은 JEUS 내부 모듈인 LoginInformation.java 임

이를 토대로 필자가 내린 결론은 다음과 같다.

전문가 판단 !!

scope 정보를 나타내는 문자열은 몇 글자 안될 것임.
(scope 종류 : page, request, session, application)
(기껏해야 영문자 20 글자 이내? → 20 byte 정도 필요)

scope 정보를 보관하는 LoginInformation class (this.scope 변수)가 1.9GB 크기의 메모리를 요청하는 것은 매우 비 이성적임

LoginInformation class는 JEUS 내부 모듈이므로 JEUS Bug로 판단되며, 이에 대한 Tmax社의 해명이 필요함

이러한 결론을 내리고 과정과 결과를 정리하여 Tmax사에 이슈를 제기하였다.

Tmax社의 회신 내용 - JEUS Bug 인정

몇일 지나 최종적으로 받은 Tmax社의 회신 내용은 다음과 같았다.
(결론부터 말하자면 자사 제품에 Bug가 있었으니, 패치를 적용해 달라… 였다.)

Tmax 회신 내용
[ims171988] inquiry about OOM on JEUS Login Manager.

Jeus의 Session Manager 중복 로그인 기능 수행시 송신측에서 크게 설정한 byte array에 대해 수신측에서 정상적으로 deserialize 하지 못하는 이슈가 발생할 수 있습니다.
수신측에선 deserialize 을 정상적으로 수행하지 못하면 비정상적으로 큰 byte array을 new 요청하기 때문에 이럴 경우 OOM이 발생합니다.
이에, 송신측에서 필요한 byte array 만 송신 할수 있도록 내부 로직이 개선된 부분 패치를 제공하오니 적용 후 효과를 검증하시기 바랍니다.

결과적으론 제공받은 패치를 적용하여 문제가 깨끗이 해결되었으나, 해당 운영팀은 그동안 오픈 후 수개월간 본인들의 잘못없이 원인불명의 장애로 마음고생이 심했으리라…

심심한 위로를 표하고 싶다…

끗~

Loadrunner Cloud의 부하발생기

2022-08-30T00:00:00+09:00

대부분의 성능테스트 도구는 부하발생기(Load Generators)를 필요로 합니다. Controller 1대만으로는 대량 부하 상황에 자원 병목으로 인해 목표한 부하를 발생시키기 어렵기 때문입니다. 이에 부하발생기를 통해 부하를 분산해 원활한 테스트를 진행할 수 있도록 환경을 구성해야 합니다.

아래 영상은 AWS Marketplace에 등록된 LoadRunner Cloud 설명 영상이며, 여기서도 부하발생기에 대해 설명하고 있습니다.

1. 부하발생기의 변화

최근 Cloud로 환경이 변화함에 따라 기존에 사용하던 부하발생기(Load Generators)는 LoadRunner Cloud에서 어떻게 변했을까요? 아래의 그림을 보시기 바랍니다.

이 그림은 CSP社인 AWS MarketPlace에 등록된 LoadRunner Cloud의 구성도입니다.

구성도의 AWS Cloud Test run load Environment 구획을 보시면 Region별 부하발생기가 여러 대 구성된 것을 보실 수 있습니다. 실제로 여러 대 구성된 것이 아니고, 여러 국가의 Region을 선택하면 부하량에 따라 부하발생기가 선택한 Region에 자동으로 1기 이상 생성하고 부하를 발생하게 됩니다.

LoadRunner Cloud 화면에서는 이 Region을 선택할 수 있습니다.

그림과 같이 Load Tests > Distribution > Edit Locations 메뉴를 통해 부하발생기가 생성될 Region을 선택할 수 있습니다. 물론, 여러 Region을 선택할 수 있으며, 각 Region에서 동시에 부하를 발생해 국가별 테스트도 수행할 수 있습니다.

예전에 부하발생기는 어떻게 환경을 구축했을까요? 기존 부하발생기를 활용한 환경의 경우, On Premise 환경(노트북/데스크탑)과 같이 별도의 장비를 여러대 준비해 프로그램을 설치하고 서버실 L4/L2/Backbone에 연결하고 방화벽 해제 작업등을 통해 부하발생 환경을 구축했습니다. 반면 LoadRunner Cloud의 경우, 이런 복잡한 과정 없이 테스트 시작 시 자동으로 부하발생기가 생성되고 테스트 종료 후 자동으로 삭제되어 부하발생기 환경 구성으로 인한 준비시간을 줄일 수 있게 됐습니다.

물론, 기존과 같이 On Premise 부하발생기도 사용이 가능합니다. 기존과 마찬가지로 노트북/데스크톱에 부하발생기를 설치한 후 해당 부하발생기의 IP를 등록하면 됩니다.

설정할 수 있는 메뉴 위치는 Load Tests > Distribution > On Premise 를 통해 접근이 가능하며, IP를 등록하면 됩니다. 단, 이 경우, Controller와 On Premise Load Generator간 방화벽은 반드시 확인해야 합니다.(TCP 54345 포트 오픈必)

2. LoadRunner Cloud Avaliable Region

현재 LoadRunner Cloud에서 사용 가능한 Region은 아래 표와 같습니다. AWS는 물론이고 Azure 및 GCP의 Region까지 사용 가능합니다. (2022.08.29일 기준)

No	Vendor	Vendor Region	Geographic area	Location
1	AWS	Middle East	Middle East	Bahrain
2	AWS	Africa	Africa	Cape Town
3	AWS	Europe	Europe	Dublin
4	AWS	Asia Pacific	Asia Pacific	Hong Kong
5	AWS	Europe	Europe	London
6	AWS	Europe	Europe	Milan
7	AWS	Canada	North America	Montreal
8	AWS	Asia Pacific	Asia Pacific	Mumbai
9	AWS	US East	North America	Ohio
10	AWS	Europe	Europe	Paris
11	AWS	Asia Pacific	Asia Pacific	Seoul
12	AWS	Europe	Europe	Stockholm
13	AWS	Europe	Europe	Frankfurt
14	AWS	US West	North America	N. California
15	AWS	US East	North America	N. Virginia
16	AWS	US West	North America	Oregon
17	AWS	South America	South America	Sao Paulo
18	AWS	Asia Pacific	Asia Pacific	Singapore
19	AWS	Asia Pacific	Asia Pacific	Sydney
20	AWS	Asia Pacific	Asia Pacific	Tokyo
21	Azure	West US	North America	California
22	Azure	UAE North	Middle East	Dubai
23	Azure	East Asia	Asia Pacific	Hong Kong
24	Azure	North Central US	North America	Illinois
25	Azure	North Europe	Europe	Ireland
26	Azure	UK South	Europe	London
27	Azure	Australia Southeast	Asia Pacific	Victoria
28	Azure	West Europe	Europe	Netherlands
29	Azure	Australia East	Asia Pacific	Nw South Wales
30	Azure	Japan West	Asia Pacific	Osaka
31	Azure	Brazil South	South America	Sao Paulo
32	Azure	South Central US	North America	Texas
33	Azure	Canada Central	North America	Toronto
34	Azure	East US	North America	Virginia
35	Azure	Switzerland North	Europe	Zurich
36	GCP(Beta)	Europe	Europe	London
37	GCP(Beta)	US West	North America	Oregon
38	GCP(Beta)	Asia Pacific	Asia Pacific	Sydney
39	GCP(Beta)	Asia Pacific	Asia Pacific	Tokyo
40	GCP(Beta)	US East	North America	Virginia

3. 부하발생기 설정

On Premise 부하발생기는 별도의 OS를 설치해 원격 접속하면 PC 설정 및 Host 등록 등 기타 설정을 직접 변경할 수 있습니다. 반면, Cloud 부하발생기는 자동으로 생성/종료되기 때문에 직접 설정을 변경하기 어렵습니다. 대표적으로 Hosts 등록입니다. 테스트를 수행하다 보면 테스트 대상 서버가 DNS 등록 전일 경우 Hosts 파일에 특정 IP와 URL을 등록한 후 접속해야 하는데 이를 위해 LoadRunner Cloud에서는 다음과 같은 작업을 통해 부하발생기에 hosts 설정을 부여할 수 있습니다.

A. hosts.add 파일 생성

B. 파일 내용 작성

# hosts.add
# Hosts 파일에 등록하는 방식과 동일하게 작성
192.168.0.1 testsystem.com
192.168.0.2 new-testsystem.com

C. 스크립트 폴더에 복사
각각의 스크립트 폴더에 hosts.add 파일을 복사합니다.
D. LoadRunner Cloud에 업로드
스크립트 폴더를 압축해서 LoadRunner Cloud에 직접 올리거나 VUGEN을 통해 통째로 업로드 합니다.

끝마침

여기까지 LoadRunner Cloud의 부하발생기에 대해 알아보았습니다. 부하발생기가 자동으로 생성/종료됨으로 인해 기존과는 비교할 수 없이 환경 구성이 쉬워졌습니다. 오늘 포스팅은 여기까지 하겠습니다.

감사합니다.

Integration of Loadrunner Cloud and VUGEN

2022-08-24T00:00:00+09:00

이 글을 보시기 앞서, 전성룡 매니저님께서 올리신 LoadRunner Cloud 구성요소 살펴보기편을 먼저 보시는 것을 권장합니다.

LoadRunner Cloud 제품으로 인해 우리는 이전보다 더 쉽고 빠르게 성능테스트 환경을 구축할 수 있게 되었습니다. 모든 환경이 Cloud에 구축이 되어 있으니 우리는 라이선스만 사서, 스크립트를 만들어 올리면 될 정도로 환경 구축이 쉬워졌습니다. 이전에는 어땠을까요? Controller 장비와 부하발생기 장비를 준비하고, 프로그램을 설치하고, 데이터센터에 반입해서 네트워크에 연결하고 방화벽 해제하는 등… 환경 준비에 많은 시간이 필요했습니다. 이에 비하면 Cloud 환경에서는 그저 숟가락만 얹으면 될 만큼 편해졌습니다.

VUGEN이 뭐지?

이전 포스트에서도 자주 언급되었던 VUGEN이 무엇일까요? Microfocus社에서는 VUGEN을 아래와 같이 설명하고 있습니다.

Micro Focus 테스트 도구는 사용자가 동시에 작업하거나 시스템에 액세스하는 환경을 에뮬레이트합니다. 이 에뮬레이션을 수행하기 위해 사람은 가상 사용자 또는 Vuser로 대체됩니다. Vuser가 수행하는 작업은 일반적으로 Vuser 스크립트에 기록됩니다. Vuser 스크립트를 만들기 위한 기본 도구는 VuGen이라고도 하는 Micro Focus Virtual User Generator입니다.

네. 그렇습니다. VUGEN(Virtual User Generator)은 성능테스트 수행을 위한 가장 기본이 되는 자동화 스크립트를 만들기 위한 기본 도구입니다.

이전에 DEVWEB(LoadRunner Developer)에 대한 소개 및 사용법을 포스팅 한 적이 있었습니다. DEVWEB 역시 자동화 스크립트 생성 도구이나, VUGEN의 기능을 축소하고 다양한 플랫폼에서 동작되도록 만들어진 도구입니다. 때문에 VUGEN의 주요 편의기능들이 빠진 상태입니다.

반면 VUGEN은 스크립트 작성을 위한 다양한 편의기능들이 포함되어 있는 소위 ‘근본 있는’ 자동화 스크립트 작성 도구입니다.

VUGEN에 대한 자세한 사용 방법은 차후 포스팅에서 알아보기로 하고, VUGEN에서 작성된 스크립트를 LoadRunner Cloud로 쉽게 업로드할 수 있는 방법에 대해 알려드리겠습니다.

먼저, 작업을 위해 VUGEN에서 한개 이상의 스크립트를 작성한 후 아래 작업 순서대로 진행합니다. 작업의 순서는 다음과 같습니다.

VUGEN Integrations

LoadRunner Cloud Authenticate

Login

Script Upload

etc..

1. VUGEN Integrations

VUGEN 메뉴 중 Integrations > LoadRunner Cloud 버튼을 클릭합니다. LoadRunner Cloud와의 통합을 위한 기능으로 Enterprise 제품에도 통합이 가능합니다.

2. LoadRunner Cloud Authenticate

Integration을 위해 아래의 정보를 입력한 후 Authenticate 버튼을 클릭합니다.

Login: LoadRunner Cloud의 로그인 계정 이메일을 입력합니다.
Password: LoadRunner Cloud의 로그인 패스워드를 입력합니다.
Tenant: 로그인 계정의 테넌트 숫자를 입력합니다.(본인의 테넌트를 잘 모르겠다면 LoadRunner Cloud 로그인 후 MyAccount > Support > GetService 버튼을 클릭해 본인의 Tenant를 요청하시기 바랍니다.)

이후 Authenticate 버튼을 클릭하여 정상적으로 인증이 완료되면 하단의 ‘Project’ 및 Login 버튼이 활성화 됩니다.

스크립트를 업로드 할 Project를 선택한 후 Login 버튼을 클릭하면 비로소 로그인 절차가 완료됩니다. 참고로, Project는 ‘Default Project’로 시작되며, 동일 계정에서 여러개의 Project를 사용하기 위해서는 별도의 절차를 거처야지만 등록이 가능합니다. 이는 차후 포스팅에서 알려드리겠습니다.

4. Script Upload

로그인 된 화면입니다. 여기서 사전에 만들어 놓은 스크립트를 업로드할 수 있습니다. 물론, 기존에 LoadRunner Cloud에 업로드한 스크립트를 다운로드 하거나, 바로 열어볼 수 있는 버튼도 있습니다. 참고로, 화면에 보이는 스크립트 리스트는 LoadRunner Cloud에 이미 업로드되어 있는 스크립트 리스트입니다. ※VUGEN에 한개 이상의 스크립트를 열어놓지 않을 경우 Upload Scripts 버튼이 비 활성화 됩니다. ‘Upload scripts’버튼을 클릭하면 아래와 같은 화면이 나타나게 됩니다.

단촐한 화면입니다. 업로드할 스크립트를 ‘Runtime Files’만 업로드 할 건지, ‘All files’ 전체 파일을 업로드 할 건지 선택합니다. 만약, 동일한 스크립트가 LoadRunner Cloud에 있을 경우 ‘Overwrite’ 할지 여부를 선택할 수 있습니다.

5. Etc…

이렇게 업로드 완료된 스크립트는 LoadRunner Cloud 화면에 리스트로 표기됩니다. 물론, LoadRunner Cloud 내에서도 바로 업로드 할 수 있는 기능이 있습니다(좌 상단의 ‘Upload 버튼’) 바로 업로드 하고 싶을 경우 스크립트 폴더를 통째로 .zip로 압축한 후 업로드 해도 됩니다.

여기서, 두가지 주의할 점이 있습니다.

A. 데이터파일

VUGEN에서 스크립트 작업 시 동적 데이터를 사용하기 위해 Correlation(Parameter) 처리한 변수들이 있을겁니다(ex. 로그인 계정, 검색어 리스트 등) 이러한 데이터 파일은 별도의 작업으로 업로드 해야 하며, 업로드 이후 각각의 스크립트와 연결하는 작업이 필요합니다. (MicroFocus社에 해당 내용에 대한 수정을 요청했습니다만, 언제 해줄지는 미지수 입니다..)

데이터 파일은 각각의 스크립트 폴더 내 데이터파일을 .zip로 압축 한 뒤 개별로 LoadRunner Cloud 화면의 Assets > Data Files > Upload 버튼을 클릭해 업로드 합니다.

업로드 된 파일은 아래와 같이 스크립트와 연결합니다.

B. Runtime Setting

스크립트가 업로드될 때 마다 LoadRunner Cloud에 사전에 업로드한 스크립트는 Runtime Setting이 업로드 스크립트의 기본 세팅으로 변경됩니다. 반드시 스크립트 업로드 이후에는 Runtime Settings을 확인한 후 수행해야 합니다.

끝마침

여기까지 VUGEN을 통해 LoadRunner Cloud에 스크립트 및 데이터 파일을 업로드 하는 방법을 알아보았습니다. LoadRunner Cloud가 아직 기능상 추가되야 할 점이 많고 사용자 측면에서 불편한 점이 없지않아 있지만, 차츰 나아질 것으로 기대하면서 오늘 포스팅은 여기까지 하겠습니다.

감사합니다.

Javax Activation Bug에 의한 WAS Hang 현상 - WAS Troubleshooting 사례(2)

2022-08-16T00:00:00+09:00

Javax Activation Bug에 의한 WAS Hang 현상 - WAS Troubleshooting 사례(2)

OO 홈쇼핑은 고객의 트랜잭션을 처리하기 위해 총 16대의 WebLogic instance를 clustering 구성해 놓았다.
문제는 16대의 WebLogic instance가 1~2일에 한 번씩 Hang-up 현상에 빠지며 서비스 장애를 일으키고 있는데, 아무도 정확한 원인을 파악하지 못해 오픈한지 10년째 WebLogic 재기동으로만 조치하고 있어 서비스 안정성이 불안정하다는 것이다.
과연 무엇이 문제이고 어떤 방법으로 해결할 수 있을지 같이 알아 보도록 하자.

원인 파악을 위한 로그 분석 - GC log, Heap 덤프

Java 쓰레드 덤프는 모든 JVM 관련 issue를 파악하기 위한 기본이 된다.
또한 Heap 덤프와 GC log는 JVM의 모든 Memory 관련 issue를 파악하기 위한 기본이 된다.
운영 담당자를 인터뷰해 본 결과, 장애 시점에 WebLogic log 상으로 OutOfMemoryError가 발생하며, 본인들이 Heap 덤프도 분석해 보았는데도 정확한 원인을 모르겠다는 것이다.

WebLogic log 상으로 OutOfMemoryError가 발생한다고 하니 일단 Memory 사용 추이를 GC log를 통해 알아 보기로 했다.

참고로, GC log는 WAS 기동 시 JAVA OPTIONS로 아래와 같은 설정을 추가하면 생성할 수 있다.

-Xlog:gc*:file=<gc_filename>

기존 에러시점에 생성된 GC log를 분석용 도구를 이용하여 그래프화 하였더니 아래와 같이 나타났다.

일반적으로 OutOfMemoryError가 발생하는 원인은 크게 2가지 유형으로 구분되어 진다.

첫 번째 유형은 지속적인 메모리 누수로 특정 프로그램에서 장시간에 걸쳐 메모리를 조금씩 잠식하여 최종적으로 OutOfMemoryError가 발생하는 것이며, 두 번째 유형은 대용량 데이터 조회 혹은 대용량 엑셀 다운로드 등 트랜잭션 처리에 Huge Memory가 필요한 Request가 수행되는 경우이다.

GC 그래프를 보면 시간이 지남에 따라 가용 Heap Memory가 점차 줄어들어 최종적으로 WAS가 Hang-up 상태에 빠진 것을 추정할 수 있어 이번 CASE에서는 OutOfMemoryError가 발생하는 유형이 전형적인 첫 번째 유형이었다.

대체적으로 이런 유형은 Heap 덤프 파일을 획득하여 분석해 보면 어느 프로그램에서 지속적인 메모리 누수가 발생하는지 알 수 있다.

운영 담당자에게 WAS 서버 Hang-up이 발생한 과거 3번의 Heap 덤프파일을 받아 분석해 보았다.
Heap 덤프 분석 결과, 아래와 같이 WebLogic Server 內 특정 모듈(RuntimeAccessImpl)에서 전체 Heap Memory의 약 57%(1GB)를 소모하고 있었다.

WebLogic Server 內 특정 모듈이 왜 이렇게 많은 Memory를 차지하고 있는지 추가분석을 진행하였더니, 아래와 같이 java.lang.Thread 객체가 배열형태로 약 670MB 메모리를 점유 중인 것이 파악되었다.

보통은 애플리케이션 개발자가 개발한 Java Class가 메모리를 점유한 모습이 나와야 하는데, 여기서는 WebLogic의 내부 모듈이 메모리를 왕창 점유한 모습이 나온 것이다. 그렇다면 이 것은 WebLogic Bug 인가….?

뭔가 추가적인 분석이 더 필요해 보인다…

Root Cause를 밝혀내기 위한 추가 로그 분석 - Java 쓰레드 덤프

메모리를 점유하고 있는 객체가 WebLogic 내부 모듈이라고 하여 WebLogic Bug로 단정지을 수 없어 해당 장애 시점의 Thread 덤프를 추가적으로 분석해 보았다.

분석 내용은 다음과 같다.

쓰레드 덤프를 살펴 보면 해당 덤프는 OutOfMemoryError가 발생된 상태에서 남겨진 쓰레드 덤프가 맞으며 Heap 메모리 정보를 보면 2GB가 할당되었지만, 현재 남아 있는 Free 영역은 24D7D0(=약 2MB) 뿐이 남아 있지 않음을 알 수 있다.

특이한 점은, 보통 JVM 內 전체 Thread 개수가 많아도 2~300 개 인데 반해, 본 쓰레드 덤프에는 Total 7,873개의 쓰레드가 존재하며 이로 인해, “Insufficient stack space for native stack collection” 오류가 발생했다는 점이다.

도데체, JVM 內에서 무슨 일을 하고 있길래 7천개가 넘는 어마무시한 Thread들이 생성이 되었을까…

Java Email API - DataHandler

7천개가 넘는 쓰레드가 무슨일을 하는지 살펴보니, 대부분이 “DataHandler.getInputStream”이라는 중복된 쓰레드 이름으로 다수 발견되었으며 아래 그림과 같이 Total 7,651개가 존재하였다.

“DataHandler”에 대해 검색해 보니 이메일 발송을 위해 사용되는 Class로 javax.activation의 package 형태로 제공되어 지는 것이었다.

아래는 javax.activation의 DataHandler Source Code의 일부분이다.

정상적인 경우라면 본문을 작성하자 마자 해당 Thread는 종료(Disapear)되어야 하나, 어떤 이유에서인지 본 시스템에서는 해당 Thread가 종료되지 못하고 계속 남아 Zombi Thread 化 되어 있는 것이 문제였다.

DataHandler Thread가 지속적으로 생성되어 종료되지 못하고 점차 누적 → 점진적 메모리 잠식 → 홈쇼핑 WAS Instance Hang-up

운영담당자도 몰랐던 사항 - 舊 버전의 모듈 사용

그렇다면 왜 이런 현상(DataHandler의 비정상 Zombi Thread)이 발생하는 걸까?

원인 파악을 위해 사용중인 javax.activation의 버전을 확인해 보다가 이상한 점을 발견했다. 동일한 javax.activation jar가 버전을 달리하여 2가지가 상존하고 있는 것이 아닌가…

버전 하나는 1.1.0이고 다른 하나는 1.4.5였다. 그 중에서 실제로 WebLogic에서 기동되고 있는 모듈(jar)은 1.1.0으로 매우 오래된 구형 버전인 것이다.

운영담당자에게 이러한 상황을 알려주니, 전혀 몰랐던 사항이며 당연히 최신 버전을 사용하고 있는줄 알고 있었다는 것이다.

그렇다면 추측컨데, 문제가 되고 있는 현상은 javax.activation의 오래된 구 버전에서 발생할 수 있는 Bug 가능성이 있으며 최신 업데이트 버전을 적용하여 해당 현상이 개선되는지 확인해 보면 명확한 Root Cause인지 판단할 수 있을 것으로 생각했다.

최신 버전으로의 적용은 WebLogic이 기동 시 기존에 있던 1.1.0 버전 대신 1.4.5 버전의 jar를 읽어들일 수 있도록 PRE CLASSPATH로 지정해 주는 방법을 사용하였다.

개선사항 적용 및 효과 검증 모니터링

OO 홈쇼핑은 현재 총 4대의 서버, 16개 WAS Instance(서버당 4 Instance)로 운영중이었다.

물론 운영서버 적용 전에 개발/검증서버에서 개선효과 및 기능검증을 완료하였으나 보다 보수적인 운영 안정성을 위해 시범적으로 1대 운영서버, 4개 WAS Instance를 대상으로만 개선내역을 반영하고 나머지 미적용한 3대와 비교해 보기로 하였다.

결과적으로, 개선사항 적용 후 주말(토,일) 동안 최신 버전의 javax.activation jar를 적용한 1대 서버(4대 WAS Instance)는 메모리 누수나 재기동 없이 원활한 서비스를 보인 반면, 개선 내역을 반영 안한 나머지 3대 서버는 기존과 동일한 메모리 누수 및 Hang-up 현상이 발생하여 평소와 마찬가지로 강제 재기동을 수행하였다.

아래 그래프처럼 메모리 사용량 추이 그래프로도 개선 전/후 효과를 확연하게 확인이 가능하였다.(메모리 누수 현상 제거됨)

끗~

LoadRunner Cloud 구성요소 살펴보기

2022-07-20T00:00:00+09:00

지난번 기술동향 글을 통해, Micro Focus의 LoadRunner Family “re launch” 최신 동향관 관련한 내용을 소개해 드린 바 있습니다.

그 이후로, SWAT의 홍성진 매니저님께서 신규 도구인 LoadRunner Developer와 LoadRunner Cloud 제품에 대한 실무적인 기능 분석 작업을 수행하셨으며, 그 결과, 실제 PJT 현장 적용까지 자연스럽게 이어지는 과정을 통해, 저 또한 해당 도구들을 학습하고 사용해볼 수 있는 기회를 가질 수 있었습니다.

LoadRunner Cloud 제품의 경우, 지난 6월 그룹사의 I프로젝트 대상으로 최초 적용이 진행된 바 있으며, 이번 7월에는 대외 사업인 A프로젝트를 대상으로 2번째 적용이 진행되었으며 두 과정 모두 함께 참여할 수 있었습니다.

라이선스 구매 과정에서 벤더를 통해 들은 바로는, Micro Focus Korea를 통해 LoadRunner Cloud 제품을 구입하여 PJT에 적용한 사례는 당사가 국내 최초라고 하니, 이번 과정들이 더 의미가 깊은 것 같습니다.

이번 글에서는, 2번의 적용 경험을 통해 접해 본 Micro Focus의 LoadRunner Cloud 제품에 대해 간단한 구조 소개를 해보고자 합니다.

1. LoadRunner Cloud 라이선스 구매 및 접속

1) 주문 처리 완료 메일 회신

LoadRunner Cloud 사용을 위한 라이선스 구매를 위해, 기존 LoadRunner 벤더사를 통해 구매를 진행하면 아래와 같이 1년간 사용가능한 라이선스 구매가 완료되었다는 메일과 함께 LoadRunner Cloud 접속 주소와 함께 접속을 위한 계정정보가 제공됩니다.

02-June-2022
Hello Sk C & C,
As with all great journeys, there's always a beginning: 
We're glad to inform your LoadRunner Cloud is ready to use!

Your order SOXXXXXXXX676 has been processed with the following information:
SKU:	SX-XXXX7
Description: LoadRunner Cloud Web Virtual User Hours per 1000	Subscription SaaS
Quantity: 12 	
From: 02-Jun-2022
To: 01-Jun-2023		
	
Let us guide you through your first steps in SaaS:
1. Log into MyAccount, follow the Getting Started tutorial.
2. Launch your LoadRunner Cloud solution from the landing page.

Here are some LoadRunner Cloud enablement resources we have for you
•	Your included LoadRunner Cloud foundation course
•	...

If you need any additional assistance please contact us, 
we will be glad to help.
We hope you enjoy your LoadRunner Cloud Service!
The Micro Focus SaaS Team
Thank you for your interest in Micro Focus Software. 
If you require help at any time, please contact our support center.             
© Copyright 2022 Micro Focus 

2) LoadRunner Cloud 사이트 접속

메일 본문에 있는 ‘My Account’ 부분을 클릭하면, LoadRunner Cloud를 접속할 수 있는 주소(https://home.saas.microfocus.com/myaccount/)로 연결됩니다.

3) LoadRunner Cloud Home 화면

제공받은 계정을 입력하여 로그인을 수행하면, 아래와 같이 LoadRunner Cloud Home 화면이 나타납니다.

기존에 LoadRunner를 사용하던 입장에서는 아래와 같은 기존의 Controller의 화면 구성과는 다소 다른 구조로 되어 있어, 어떻게 화면 네비게이션을 이동하면서 사용해야 할지에 대해 익숙해지는 시간이 어느정도 필요합니다.

2. LoadRunner Cloud의 화면 구조 이해

1) VuGen, Controller, Analysis 기능 매핑

기존의 LoadRunner는 아래의 세가지 구성요소로 되어 있습니다.

VuGen: Script 작성 및 디버깅
Controller: Workload 설계, 부하발생, 실시간 모니터링
Analysis: 수행 결과 분석 및 리포트

반면, LoadRunner Cloud의 화면 구성요소는 Home, Load Tests, Assets, Results로 크게 구분되어 있습니다.

LoadRunner Cloud의 경우, 기존 LoadRunner에서 VuGen이 수행하는 스크립트 작성 및 디버깅 기능은 제공하지 않습니다. 나머지 Controller의 기능과 Analysis 기능이 웹 화면상에서 통합적으로 제공되는 구조라고 이해하시면 됩니다.

2) VuGen - 성능 스크립트 작성

스크립트 작성은 기존과 동일하게 LoadRunner VuGen에서 작업을 수행하면 됩니다.

LoadRunner Professional Free Trial(https://www.microfocus.com/en-us/products/loadrunner-professional/free-trial)을 다운로드 받으시면, 50Vuser가 탑재된 Trial 제품을 쓸 수 있으므로, 이때 같이 설치되는 VuGen을 이용해 기존과 동일한 방법으로 Script를 작성하시면 됩니다.

3) Assets - 성능 스크립트 업로드

VuGen에서 스크립트 작성이 완료되면, 아래와 같이 Zip 파일로 만들어 업로드할 준비를 합니다.

LoadRunner Cloud 화면 상단의 메뉴들 중 “Asset”을 클릭하면, Zip파일로 준비된 스크립트를 업로드하는 기능을 제공합니다. “Upload” 버튼을 클릭하여 스크립트를 LoadRunner Cloud로 올려줍니다.

4) Load Tests - Workload Modeling

기존 LoadRunner Controller에서 Workload Modeling을 수행하는 기능은 “Load tests” 화면에서 진행됩니다.

수행하고자 하는 테스트 시나리오명을 작성한 후, 해당 이름을 클릭하면 Workload를 설정할 수 있는 화면으로 들어갑니다.

이 화면에서 Vuser 수, Ramp UP, Duration, Runtime Setting 등의 모든 주요 설정값들을 반영해 줄 수 있습니다.

화면 구성이 기존의 LoadRunner Controller의 화면과는 다르지만, 자세히 살펴보면 웹화면 상에서 최대한 불편함 없이 설정을 수행할 수 있도록 편리한 기능들이 제공되고 있습니다. 주요 기능들을 요약해보면 다음과 같습니다.

Add from Assets: 이전에 업로드한 스크립트의 추가 기능
Upload: 원하는 스크립트의 직접 업로드 기능
Download: 스크립트 수정 필요시 다운로드하여 편집
Duplicate: 선택된 스크립트를 복사하여 추가
Copy Scheduling: 설정 복사 후 나머지 스크립트에 일괄 반영
Runtime Setting: 기존과 동일한 부하 수행방식 설정 기능
Bulk Actions: 선택된 스크립트들의 항목별 일괄 수정 기능
Copy Runtime Setting: 설정 복사 후 나머지 스크립트에 일괄 반영

5) 부하발생서버 연결 - Distribution

LoadRunner Cloud의 경우, 이름 그대로 Cloud상에서 부하를 발생시키는 구조이기 때문에, 기존처럼 부하발생기를 연결해주는 작업이 아닌 부하가 발생하는 AWS Cloud의 Location을 지정해주는 작업을 Load Tests의 Distribution 메뉴에서 설정해주게 됩니다.

우리의 경우, Seoul(AWS) 리전을 선택하여 부하를 진행합니다. 만약, 서비스가 다국적 환경에서 진행된다면, Cloud Location을 해당 지역별로 여러개 설정하여 부하를 발생시키는 것도 가능합니다.

6) Run Test - Initializing load test

LoadRunner Cloud에서 부하 발생 준비가 완료되면, 우측 상단의 Run Test 버튼을 클릭하여 부하 발생을 시작할 수 있습니다.

LoadRunner Cloud는 이름 그대로 Cloud 상에서 모든 기능들이 구동하기 때문에, 초기 준비하는 시간이 몇 분 정도 소요되는데, 해당 진행상황을 아래와 같이 보여줍니다.

7) Run Test - Runs

준비작업이 완료되면 바로 부하가 시작되는데, 아래 화면과 같이 조금 복잡해보이는 화면구성을 가진 채로 부하가 시작됩니다.

기존 LoadRunner에 비해서는 조작 방법이 직관적이지 않아, 메뉴 사용방식을 익히는 시간이 필요하지만 한번 사용해보고 나면 방법 자체는 어렵지 않기 때문에, 본인이 보고자하는 모니터링 화면을 비교적 쉽게 구성하여 사용할 수 있습니다.

왼쪽 리스트에 보여지는 다양한 모니터링 항목들을 선택하여 오른쪽에 나타내고, 각 모니터링 항목들을 화면 분할 조정하여 대시보드를 구성하는 구조로 되어 있습니다.

8) Analysis - Results

수행이 끝나면 해당 결과는 Results 화면에 수행 결과가 누적되어 보관되고 있어, 결과를 바로 확인할 수 있습니다.

기존에는 Analysis를 통해 별도로 띄워서 보는 구조였던것에 반해, 여기서는 수행 후 바로 같은 화면에서 결과를 분석해 볼 수 있다는 점이 좀더 효율적인 것 같습니다.

3. 라이선스 사용이력 확인

기존 LoadRunner의 VUD(Virtual User Days)가 가지고 있는 비용 부담(ex. 1Vuser당 1만원대)과 시간 제약(24시간 후 소진)에 대한 대안으로서 LoadRunner Cloud를 고려하는 방향이기 때문에, 가장 궁금한 사항은 여기서의 라이선스 소진방식은 어떻게 처리될까 하는 부분이었습니다.

Settings > License Information으로 들어가보면, 아래와 같이 테스트 실행시마다 어느정도의 시간동안 라이선스를 사용했는지를 보여주는데, 체감되는 사용량 대비 소진되는 수준은 매우 적게 느껴집니다.

그 이유는, VUD의 경우 시작과 동시에 24시간이 계속 흐르는 구조이지만, LoadRunner Cloud의 경우에는 부하가 시작되어 종료되기까지 ‘부하발생한’ 시간 만큼만 계산하여 차감하는 방식으로 계산되기 때문입니다.

사용자 입장에서는, 라이선스에 대한 부담없이 여러번 수행할 수 있으며, 라이선스 만료기한도 발급일 기준 1년까지 길게 부여해 주기 때문에, VUD와 같이 만료시간 끝까지 24시간 내내 최대한 테스트하고자 밤을 새는 무리한 상황은 예방할 수 있습니다.

현재 수행하고 있는 프로젝트도, 매일 매일 업무시간중에 부하를 발생하고 수행 결과를 Wrap Up 하고 다음 날 또 진행하는 식으로, 수행 부담을 줄인 상태로 여러날에 걸쳐 수차례 반복적인 성능 테스트 진행하고 있는데, 이는 수행횟수와 기간에 따른 라이선스의 부담이 적기 때문에 가능한 것일 수 있습니다.

4. 마무리 글

이상으로 LoadRunner Cloud 제품에 대한 개략적인 기능들에 대해 살펴보았습니다. 기존 기술 동향에서도 살펴 보았듯이, 앞으로의 성능테스트는 SDLC에서 가급적 빠른 시기에 주요 기능들에 대해 성능테스트가 반복적으로 수행될 필요가 있으며, 이를 위한 접근성 좋은 자동화 도구가 다수 사용자들에게 적절하게 지원되는 것이 필요합니다.

이번 적용 경험을 통해 파악한 LoadRunner Cloud가 가진 장점들을 나열해보면 다음과 같습니다.

웹 기반으로 자동화 도구의 접근 및 사용자간 공유가 자유로움
부하발생서버 등 환경 구성을 위한 별도 준비 필요 없음
라이선스의 시간(기간) 제약 해소에 따른 업무 부담 완화
사용한 만큼만 차감되어 장기간 반복적인 성능 테스트에 적합
기존 LoadRunner 제품들간 스크립트 공유 활용 가능

프로젝트 지원 중에 해당 화면을 캡쳐하여 설명해주면 좋을 것 같다는 생각이 들어 다소 급하게 정리한 글이긴 하지만, LoadRunner Cloud에 관심있는 분들에게 궁금증을 해소해줄 수 있는 내용이 되었길 바라면서 이번 글을 마칩니다. 감사합니다.

[끝]