DevOps를 위한 Performance Engineering 적용 방향성

아래 기술된 내용은 Gartner에서 2018년 발간한 보고서인 “Adopt a Performance Engineering Approach for DevOps” 내용을 기반으로, Performance Engineering 관련 Global 기술 동향을 정리하였습니다. 필요한 부분만 요약정리 하였기 때문에, 전체 자료가 필요하신 경우 아래의 원문을 참고하시기 바랍니다.

Source: https://www.gartner.com/doc/reprints?id=1-6K7GZW6&ct=190423&st=sb

“애플리케이션 리더들은 기술부채(Technical Debt)를 줄이고 애플리케이션의 성능위험(Performance Risk)를 완화해야 합니다. 또한, 생산성 높은 S/W 개발 조직을 구축하기 위해 “Shift Left”와 “Shift Right”가 결합된 형태의 Performance Engineering Approach를 적용해야 합니다.” - By Gartner Analysts Joachim Herschmann

Overview

Key Challenges

• IT조직들은 비즈니스에서 요구되는 애플리케이션의 성능 기대수준, 특히 애플리케이션 속도, 확장성 및 품질에 대한 needs를 만족시키기 위해 노력하고 있습니다.

• 많은 성능 이슈들의 근본적인 원인이 Architecture가 가진 결함으로 추적될 수 있지만, Architecture 설계 이슈를 해결하는 것은 매우 어려우며 많은 비용 또한 발생합니다.

• 성능관련 문제(Performance-related challenges)들이 성능테스트 수행 자체만으로는 해결되기 어려운데, 이는 성능테스트가 실 사용자 경험까지는 고려하지 않기 때문입니다.

Recommendations

DevOps에 기반하여 Bimodal Enterprises를 지원하는 애플리케이션 리더들은 다음에 대한 책임이 있습니다.

• ‘선제적 성능 품질 전략’(a proactive performance quality strategy)을 적용하기 위해 성능에 대한 명확 요구사항을 만들고, 성능목표 달성 및 사용자 기대 만족여부를 검증하기 위한 Test Cases를 생성해야 합니다.

• 성능 테스트를 CI/CD Process에 통합하여 지속적인 성능테스트 체계를 구현해야 합니다.
• 상용환경 및 실 사용자로부터의 성능정보를 활용함으로써 Feedback Loop를 구축해야 합니다.

참고. Bimodal Enterprises

2014년 Gartner는 Enterprise CIO를 위한 처방으로, 새롭고 혁신적인 IT Model을 도입했습니다. Bi-Modal IT Model의 정의는 “a Combination of Old and Modern IT Practices”입니다.

Bi-Modal IT Model은 한 모드는 ‘Stability’에 초점을 맞추고, 다른 한 모드는 ‘Agility’에 초점을 맞추는 것으로, 두 가지가 구분되지만 일관된 IT Delivery 모드로 관리되는 Practice입니다. 첫 번째 모드는 Safety와 Accuracy에 초점을 둔 전통적이고 순차적인 모드입니다. 두 번째 모드는 Speed와 Agility를 강조하는 탐색 및 비선형 모드입니다.

Gartner가 이 Model을 공식화 한 주요 목적은, IT를 조직화하고 기업 내 다양한 ​​사업부서의 빠르게 증가하는 요구 사항을 만족시키기 위한 것이었습니다. 이에 대한 전체적인 정의는 다음 그림에서 볼 수 있습니다.

Source: sodalessolutions

Strategic Planning Assumptions

2020년까지, DevOps initiatives는 기업들의 50%가 Frameworks 및 Open-Source Tools를 활용하여 Continuous Testing을 구현하도록 할 것입니다.

2021년까지, 애플리케이션 개발을 위해 ‘Performance Engineering Approach’를 채택한 조직들은, 고객 만족도와 비즈니스 성과 모두에서 그렇지 않은 경쟁사를 능가하게 될 것입니다.

2021년까지, ‘Digitalized Business Processes’를 관리하기 위한 needs가 점점 더 증가함에 따라, 기업들은 지난 2017년 5% 였던 APM기반 비즈니스 애플리케이션 모니터링 적용 수준을 20%까지 증가시킬 것입니다.

Introduction

What You Need to Know

모바일, 웹, 클라우드, 소셜 및 몰입형 컴퓨팅 시나리오의 보급이 확산됨에 따라 애플리케이션 품질에 대한 최종 사용자의 기대치 또한 높아졌습니다. 품질을 구성하는 개념 또한 훨씬 넓어졌습니다. 여기에는 전반적인 사용자 경험(Overall User Experience), QoS(Quality of Service), 가용성(Availability) 및 성능(Performance)이 포함됩니다. ISO/IEC 25010(S/W 품질에 대한 국제 표준)은 품질특성을 이해하기 위한 템플릿을 제공하고, 성능효율성(performance efficiency)을 ‘the Top-level Non-Functional Domains’의 하나로 포함합니다.

참고. ISO/IEC 25010

품질 모델은 소프트웨어 제품의 속성을 평가할 때 고려해야 할 품질 특성(Quality Characteristics)을 결정합니다. 다양한 이해 관계자의 요구사항(기능, 성능, 보안, 유지보수성 등)은 제품 품질을 특성 및 부특성으로 분류하는 품질 모델에서 정확하게 표현됩니다.

ISO / IEC 25010에 정의된 제품 품질 모델은 다음 그림에 표시된 8 가지 품질 특성으로 구성됩니다.

Source: ISO25010

많은 조직들이 여전히 품질에 대한 전체적인 관점(a Holistic View of Quality)을 가지고 있지 않습니다. 비기능 요구사항은 종종 적절하게 포착되지 않기 때문에, QA 프로세스에서는 주로 기능 요구사항을 언급합니다. 이렇게 되면, S/W가 몇가지 기본적인 기능 품질 목표를 만족시킨다는 것은 보증할 수 있지만, 사용자나 비즈니스의 품질 기대를 만족시키기에는 충분하지 않은 상황이 됩니다.

성능은 애플리케이션의 가장 핵심적인 비기능 특성 중 하나입니다. 일반적으로 기능적 결함은 비교적 적은 노력으로 다소 빠르게 수정할 수 있습니다. 성능에 영향을 미치는 설계 결함은, 애플리케이션의 다른 부분에 있는 많은 기능들에도 영향을 미치기 때문에 수정하기가 휠씬 더 어렵습니다.

이러한 ‘Architectural or Structural Defects’은 일반적으로 기술부채의 주요 원인 중 일부가 됩니다. 이러한 이슈들을 예방하기 위해서는, 애플리케이션 리더들이 애플리케이션 개발을 위한 ‘Performance Engineering Approach’를 적용해야 합니다. 애플리케이션 개발에 대한 ‘a Holistic Performance Engineering Approach’의 핵심요소는 다음과 같습니다.

• 성능 요구사항 정의(Defining performance requirements)
• 성능 최적화 설계(Performance optimized design)
• 성능을 염두에 둔 코딩(Coding with performance in mind)
• CI Process의 일부로서 지속적 성능 테스트(Continuous performance testing as part of the CI process)
• 상용환경에서의 테스트(Testing in production)
• 실사용자 모니터링을 포함한 성능 모니터링(Performance monitoring, including real-user monitoring (RUM))

이러한 Best Practices를 적용하면, 애플리케이션 성능 및 상용 시스템의 동작을 개선하는데 도움이 됩니다. 또한, 부하 테스트 시나리오 및 전체적인 ‘Performance Engineering Parameters’를 조정하는데 있어, 결정적인 최종 사용자 경험을 더 잘 이해하는데 도움이 됩니다. 더불어, 이러한 요소들은 ‘a Closed-Loop System’을 구성하여, DevOps Toolchain의(그림 1) 일부로서 중요한 성능 지표에 대한 지속적인 정보를 제공합니다.

그림 1. Elements of Performance Engineering

Analysis

성능 요구사항 명시화를 통한 ‘선제적 성능 품질 전략’ 적용

성능 요구사항은 애플리케이션의 성능 목표를 정의하고 있으므로, 모든 프로그램에서 필수적입니다. 이것은 아키텍쳐 관련 의사결정을 지원하기 위한 Design Specifications를 제공합니다. 또한, 애플리케이션의 Technical Specifications를 결정하고, 다양한 이해관계자들에게 Scalability Characteristics를 전달하는데 도움을 줍니다.

이해관계자의 구성에는 비즈니스, 사용자 및 Application Architects, Infrastructure Architects, Developers, Testers and Support Teams와 같은 IT인력의 다양한 역할이 포함됩니다. 그들 모두는 성능 요구사항에 대해 이해하고 동의함으로써, 애플리케이션 구축 시 ‘Scalability 관련 제약사항’에 대해 서로간의 입장을 분명히 할 수 있습니다.

비즈니스, 사용자 및 IT인력들은 모두 각 시스템 속성에 대한 성능 목표 수준에 대한 열망(aspirations), 바램(desires) 및 의견(opinions)을 확실하게 가지고 있습니다. 그림 2에서는 애플리케이션의 주요 이해관계자와 성능관련 품질 특성이 나열되어 있습니다.

그림 2. Stakeholders and Quality Characteristics Related to Performance

그러나, 이렇게 자주 상충되는 관점들은 종종 포착되지 않고, 현실적으로는 암묵적인 상태로 남아있습니다. 많은 조직들이 기능적인 관점에서만 품질을 고려하고 있습니다. ‘Performance Efficiency’와 같은 비기능 속성은 고려 대상이 아닌 것으로 보여지기도 합니다.’

‘Performance Efficiency Requirement’는 예를 들면, “5천명의 Concurrent Users를 지원하기 위해, 가용한 시간의 99% 수준에서 0.5초의 평균 응답성능을 지원해야 한다”라든지, “1천명의 Concurrent Users에 대해 초당 1백 페이지를 오류율 0.5% 미만으로 처리해야 한다”와 같은 형태로 기술됩니다.

이들은 중요한 품질 요구사항임에도 종종 고려되지 않고 있습니다. 결과적으로, 애플리케이션은 성능은 염두에 두고있지 않은 채로, 요구되는 기능(the Desired Functionality)만을 제공한다는 주요 목표를 가지고 개발됩니다.

이것은 추가적인 결과를 낳게 됩니다. ‘Performance Efficiency’와 같은 비기능적 속성들은 전체 시스템이 가진 특성입니다. 따라서, 일련의 ‘Sprint Deliverables’는 달성된 비기능적 속성을 가진 채로 시작될 수 도 있겠지만, 코드의 양, 사용자의 수 및 트랜잭션의 복잡도가 점차 증가함에 따라 비기능적 속성들은 감내할 수 있는 수준을 벗어나 버립니다. 따라서, 어떤 Sprint도 기능적인 품질저하를 일으키는 “결함”을 제공하고 있지 않음에도, Solution 전체적으로는 Architecture와 Design에서 모두 결함을 가지고 있게 될 것입니다.

어설프게 정의된 성능 요구사항은 일반적으로 다른 방식으로 해석될 수 있으므로, 관련 당사자간의 모호성과 소송가능성을 유발할 수 있습니다. 아래 표 1은 ‘Good and Bad Performance Requirements’의 예시를 제공합니다. Good requirements는 Test Cases를 도출하는데 사용할 수 있는 명확한 측정지표를 가지면서, 알아보기 쉽고, 모호하지 않으며, 예상되는 동작에 대해 실행 가능하며 측정가능한 설명을 제공합니다. Bad requirements는 본질적으로 아날로그 식이며, 예상되는 동작이나 테스트 방법에 대한 명확한 설명이 없습니다.

Clear and Explicit Performance Requirements	Unclear and Ambiguous Requirements
애플리케이션은 초당 20개의 주문을 송부하는 5천명의 Concurrent Users에 대해 초당 100페이지를 처리할 수 있어야 하며, 페이지의 수준별 응답시간은 다음과 같다. 단순 페이지의 경우 0.5초 미만, 중간 복잡도를 가진 페이지의 경우 1초 미만, 높은 복잡도를 가진 페이지의 경우 5초 미만, 오류율은 0.5% 미만	The application should be fast.
배치 프로그램은 10분동안 500,000 records를 처리해야 하며, 서버에서 다른 작업이 동시 실행되지 않는 상태에서 75% 미만의 자원사용율을 유지해야 한다.	The reporting application must be able to process the daily bookings.
Peak Workload 시점의 Infrastructure 자원사용율은 CPU 50% 및 Memory 75% 수준을 초과하지 않아야 한다.	The application should support the peak workloads of the past.
애플리케이션은 10대의 서버 구성환경에서 5만명의 Concurrent Users를 지원할 수 있어야 하며, 가용 시간의 98.5% 수준에서 0.1초의 평균응답시간 및 0.1% 미만의 오류율을 제공해야 한다.	The application should support 50,000 users.

표 1. Examples of Good and Bad Performance Requirements

성능 요구사항은 애플리케이션의 주요 특성을 정의하고 있기 때문에, 성능 자체는 Microservices Architecture 또는 Model-View-Controller 패턴을 사용하여 애플리케이션을 구축하기로 결정하는 것과 같은 방식으로, 하나의 ‘설계목표(Design Goal)’로서 다뤄져야 합니다. 우리가 ‘New Epic’이 비즈니스에 중요한지 이유를 묻는 시점에, 성능이 모든 이해 관계자들에게 어떤 영향을 미칠지에 대해서도 함께 질문해야 합니다. 성능 요구사항 관리는 지속적인 프로세스 입니다. 성능은 처음부터 가장 중요한 요구사항(an Overarching Requirement)이 될 필요가 있으며, 미리 실패에 대한 준비가 되어 있어야 합니다.

성공의 열쇠는 시작부터 의미있는 성능 요구사항을 정의하기 위해 Business와 Project Team이 협업하는 것입니다. 모든 관련 이해관계자들의 초기 참여는 성능 요구사항이 이해할 수 있고 동의할 수 있는 합리적인 수준임을 확신함으로써, 개발중에도 성능이 고려될 수 있도록 합니다. 이것은 도구, 방법론, 프랙티스, 플랫폼 및 자원을 사용하여 작업을 추적하는데 도움이 됩니다. 성능은 개발자, 테스터 또는 운영팀만의 책임은 아닙니다. 이것은 모든 사람의 책임이며, “Performance First”는 모든 이해 관계자에게 목표(mantra)가 되어야 합니다.

Recommendations

• 처음부터 비즈니스, 사용자 및 IT팀의 주요 이해관계자를 참여시킴으로써, 성능이 개발을 위한 가장 중요한 요구사항임을 확인합니다.
• 성능관련 기준을 포함하여 기능 요구사항을 강화하고, Tests를 작성할 수 있도록 정확하고 측정가능한 성능목표를 기술함으로, 성능을 명확한 요구사항으로 만듭니다.

Implement Continuous Performance Testing

전통적으로 팀들은 프로세스 후반에 성능 테스트를 적용해왔습니다. 테스트 단계에 와서 뒤늦게 성능을 고려하는 스타일은 팀들이 피해야 할 Anti-pattern입니다. Software Development Life Cycle (SDLC)의 후반 단계가 될 때까지 테스트를 연기하면, 발견된 문제를 해결하는데 필요한 공수는 크게 증가한다는 것이 이미 잘 알려져 있습니다. 이것은 성능 관련 결함일 때 훨씬 더 심각한 의미를 가지게 됩니다.

기능 요구사항 명세와의 편차에서 발생하는 기능 결함은 코드 변경관리를 통해 수정될 수 있습니다. 이는 기능 오류와 관련된 특정 코드 요소로 제한됩니다. 하지만, 성능과 같은 비기능 요구사항에서의 편차는 종종 애플리케이션의 근본적인 재설계 및 재구현을 통해 해결될 필요가 있습니다. “Shift Left” Approach를 적용하면 이러한 편차 및 관련 결함을 조기에 탐지하고, 전체적인 품질을 개선하며, 납기(Delivery) 속도를 극대화할 수 있습니다.

초기에 자주 테스트함으로써, 개발팀과 이해관계자들은 현재의 코드 품질을 인지할 수 있고, 개발주기동안 정보에 입각한 결정을 내릴 수 있게 됩니다. 초기에 자주 테스트하는 이점을 얻기 위해서는, Performance Test Suites을 가능한 자주 실행해야 합니다. Automation은 이러한 노력에 없어서는 안될 요소이며, On-premises 또는 SaaS-based Performance Testing Tools는 성능 병목지점을 확인하고 성능 이슈를 해결하는데 필요한 데이터를 제공합니다.

Example vendors/tools that can assist in performance testing practices:

• Micro Focus — LoadRunner, StormRunner Load and Silk Performer
• Neotys — Neoload
• IBM — Rational Performance Tester
• Tricentis — Tricentis Flood
• CA Technologies — BlazeMeter
• RadView — WebLOAD
• SmartBear — LoadComplete
• Eggplant — Eggplant Performance
• Parasoft — Parasoft SOAtest
• Apache JMeter
• The Grinder
• Locust
• Tsung

지속적인 성능테스트(Continuous performance testing)는 단지 성능 테스트 도구의 사용만을 의미하는 것은 아닙니다. 이는 테스트 데이터 및 환경 셋업, 테스트 수행, 결과 보고 및 분석을 포함하는 전체 프로세스에 대한 자동화를 의미합니다. CI Engines은 개발자가 성능 문제를 일으키는 코드를 제출하면 바로 성능테스트가 실행되고 성능 이슈들이 나열되는 탁월한 매커니즘을 제공합니다.

Tests는 사람과의 상호작용없이 효율적으로 실행되어어야 하며, 대시보드 또는 Integrated Development Environment (IDE)의 선택을 통해 보고받을 수 있어야 합니다. Trending Data는 애플리케이션 코드에 주입된 아키텍처 결함(Architectural Flaws)의 위치를 조기에 제공함으로, 개별 테스트 결과보다 더 중요한 역할을 수행합니다. 만약 성능이 크게 저하되면 이슈가 해결될때까지 Deployment가 중지됩니다. 성능 저하가 탐지될 때 오류가 확인되도록 CI 시스템에 스크립트를 프로그래밍하면, 팀이 Release를 위태롭게 하는 Showstoppers가 되기 전에 성능문제를 포착할 수 있게 됩니다.

다른 방법으로는, 이러한 테스트는 종종 “Canary” Test를 사용하여 수행됩니다. 이 테스트에서는 적은 수의 서버들이 신규 S/W로 업그레이드 된 후 면밀하게 모니터링 됩니다. 만약, 변경사항이 초기 서버들의 성능, 안정성 또는 지연시간에 영향을 미치는 경우, Canary Servers는 S/W가 업데이트되고 정상적으로 작동될 때까지 사용에서 제외되거나 Rolled Back 됩니다. Canary Servers가 사전에 정의된 기간동안 성공적으로 실행되면 나머지 서버들도 점진적으로 업데이트 됩니다.

Recommendations:

• Performance Testing Tools를 사용하여 Performance Engineering Activities를 자동화하고, 이를 CI/CD process에 통합합니다.
• Build의 성능을 검증하기 위해 코드가 대상 환경에 배포되면, 짧은 기간에 바로 작동될 수 있는 기능별 성능 테스트 작업을 Build합니다.
• 각 Build에 대한 성능 측정지표 및 분석을 자동화하고, 의미있는 방법으로 시각화합니다. 이를 통해 개발 초기에 가능한 성능 문제를 식별하여 전체 테스트 프로세스를 보다 Agile하게 만들 수 있습니다.

상용환경 및 실 사용자의 성능정보를 활용하는 Feedback Loop 수립

CI/CD Process의 일부로서의 성능 테스트는 성공적인 Performance Engineering Practice의 중요한 요소입니다. 하지만, 애플리케이션 동작 성능의 변화 패턴에 맞게 지속적으로 조정하는 것 만으로는 충분하지 않습니다. “Shift Right” Strategy의 일부로서 Performance Monitoring은 다른 중요한 요소입니다. 이것은 부하 테스트 시나리오 및 전체 Performance Engineering Parameters를 조정하는데 중요한 상용 시스템의 동작 및 최종 사용자 경험을 이해하는데 도움이 됩니다. 이들은 함께 Closed-Loop System을 구성하고, 중요한 Performance Indicators에 대한 지속적인 정보를 제공합니다.(그림 3. 참조)

그림 3. Feedback Loop

시스템 및 최종 사용자의 성능을 모니터링하는 기능은 APM 기술과 사용자 모니터링 피드백 도구에 모두 포함되어 있습니다. 전통적인 Web Analytics Vendors는 고객 방문, 장치 및 디지털 채널 전반에 걸친 360도 View를 제공하고 있습니다. APM 도구는 모니터링을 용이하게 하여 다음 세가지 주요 Functional Dimensions를 만족시킵니다.

• DEM(Digital experience monitoring, 디지털 경험 모니터링) - 웹 및 모바일 기반 최종 사용자 모두를 위한 Real-user monitoring (RUM) 및 Synthetic Transaction Monitoring (STM)
• ADTD(Application Discovery, Tracing and Diagnostics, 애플리케이션 검색, 추적 및 진단) - 주로 문제 해결에 초점을 둔 일련의 프로세스
• AIOps(Artificial intelligence for IT operations, IT운영을 위한 AI) for applications - 성능 및 이벤트 패턴을 자동으로 발견하고 성능 이상 원인(또는 Root Cause)을 감지

APM 도구를 포함하는 Performance Engineering Approach를 통해 애플리케이션이 실환경에서 어떻게 수행되는지 더 잘 평가하고, 사용자에게 중요할 수 있는 이슈들을 찾아낼 수 있게 됩니다. APM도구의 데이터는 문제 식별 및 분리, 그리고 애플리케이션의 사용율 및 성능 패턴을 이해하는데 필수적입니다. 또한, 개발 및 배포주기동안 S/W의 영향도를 보다 잘 측정할 수 있도록 지원합니다.

Example vendors/tools that can assist in application performance monitoring:

• Cisco — AppDynamics
• Dynatrace
• New Relic
• CA Technologies
• IBM
• Riverbed
• Microsoft
• Oracle
• Stackify
• Eggplant
• Prometheus
• Sensu
• TICK Stack (Telegraf, InfluxDB, Chronograf, Kapacitor)

Recommendations:

• 각 Use Case에 대한 Acceptable Service Levels과 애플리케이션의 Degradation Policies를 정의합니다.
• Performance Monitoring Tools를 사용하고 이를 CI/CD Process에 통합하여 성능 모니터링을 자동화합니다.
• 각 Build의 성능 이슈에 대한 Root Cause Analysis의 지속적인 적용을 통해 성능 병목현상을 제거합니다.

[END]