2020 State of Performance Engineering report: (3) Practices of performance engineering
Updated:
Chapter 3: Practices of performance engineering
이번 Chapter는 여러분의 동료들(Peers)이 무엇을 하는지 보여주는 것과 함께, 방법론을 개선하고 강화(Enhancement)하기 위한 영역을 식별하는데 도움을 주는 것을 목표로 하고 있습니다.
Performance engineering is demanding
Application Performance는 간단히 정의하자면, 컴퓨터 시스템에 의한 작업 실행 기간(Duration)과 시스템이 처리할 수 있는 부하(Load)와 관련이 있습니다.
우리는 Performance Engineering의 최종 목표가, 단지 최종 사용자 경험을 이해하기 위한 것이 아니라, Application Performance의 다양한 측면을 지속적으로 만족시킬 수 있다는 것을 보증하는데 있다고 믿고 있습니다. 이러한 측면에는 신뢰성(Reliability), 가용성(Availability), 확장성(Scalability), 가동시간(Uptime), 응답성(Responsiveness), 속도(Speed) 등이 포함됩니다.
참고. 클라우드컴퓨팅서비스 품질·성능에 관한 기준(용어의 정의)
“가용성”이란 클라우드컴퓨팅서비스가 장애 없이 정상적으로 운영되는 능력을 말한다.
“응답성”이란 클라우드컴퓨팅서비스 이용자의 요청에 따라 얼마나 빨리 응답하는 가에 대한 능력을 말한다.
“확장성”이란 클라우드컴퓨팅서비스 이용자의 요청에 따라 자원의 양을 할당할 수 능력을 말한다.
“신뢰성”이란 클라우드컴퓨팅서비스 제공자가 클라우드컴퓨팅서비스를 정상적으로 운영할 수 있는 능력을 말한다.
Source: https://www.law.go.kr/
시장 지향 애플리케이션(Market-facing Applications)의 경우, 애플리케이션의 상태와 연관된 텔레메트리(Telemetry)는 비즈니스 목표와 기능 사용에 대한 달성여부와 관련이 있어야 합니다. Telemetry는 트래픽(Traffic), 세션길이(Session Length), 신규 계정 전환(New Account Conversion), 동시사용자수(Number of Active Users), 예약(Bookings), 반품율(Return Rate) 등을 포함합니다.
기업은 구성원, 프로세스 및 기술에 대한 투자가 부여하는 도전적인 규모에 당혹감을 느낄 수 있지만, 지속적으로 투자를 유지해야 합니다.
“34% identify the lack of suitable tools as a key challenge”
적절한 자동화 도구를 선정하는 문제는, 2000년대 초반 이후로 계속 되풀이되는 관심사였습니다. 자동화 도구가 부족하다는 구성원들의 인식(Perception)은, 이들이 수행하기 원하는 테스트를 처리하는데 도움을 주는, 자동화 도구들을 식별하기 위한 생각과 역량을 제한해 버릴지도 모릅니다. 라이선스 자동화 도구와 오픈소스 자동화 도구 모두가 실제로 꽤 인상적인 수준의 다양성을 가지고 있기 때문에, 이러한 인식(Perception)은 시대에 뒤떨어진 생각일 수 도 있습니다.
거의 모든 자동화 도구들이, 다양한 조건 속에서 작동하는 Cloud 및 On-premises Machines 환경 하에서, 적절한 사용자 부하를 생성하는 역량을 갖추고 있습니다. 추가적으로, 자동화 도구들은 Web Application Performance를 분석하고, 이슈를 정확히 집어(Pinpoint Issues)내어, 병목현상(Bottlenecks)을 식별해낼 수 있습니다. 많은 자동화 도구들이 무료 평가판을 제공하고 있기 때문에, 도구에 대해서는 쉽게 평가해 볼 수 있습니다.
Load Testing Tools를 차별화하는 요소들은, 지원 프로토콜 범위(the range of protocols they support), 테스트 설계 단계의 자동화 및 단순화 역량(the ability to automate and simplify the test design phase), 그리고 실사용자 행동 시뮬레이션(the simulation of real-user behaviour) 등을 포함합니다. 다른 차별화 요소들은 근본원인분석 속도(the speed to root cause analysis)와 전체 자동화 환경에서의 통합(the integration within the entire toolchain)을 포함합니다. Code가 진화함에 따라, 성능테스트 스크립트의 유지보수를 최소화해주는 역량 또한 상당한 이점입니다.
시스템이 복잡할수록 자동화 도구 도입에 보다 많은 투자가 요구되는 상황에서는, 효과적인 자동화 도구와 스킬을 획득하기 위한 과정이, 규모가 작은 회사일수록 더 복잡하다는 사실을 인지하고 있습니다. 비록 그렇다 하더라도, 우리는 방법론과 이에 요구되는 스킬들보다는, 자동화 도구가 좀 더 수월한 주요 과제라고 여전히 믿고 있습니다.
많은 응답자들이 강력한 Performance Engineering을 확보하는데 있어 강력한 장애물들 중 하나로, 지식이 풍부한 전문가의 부족을 체감하고 있습니다.
Performance Engineers의 역할과 책임은, 설계 가이드라인의 정의, 개발자와 협업을 통한 설계 및 코드리뷰, 배포 전후 성능 테스트, 그리고 상용환경에서의 시스템 행동 모니터링을 포함합니다. SDLC(software development lifecycle) 전체에 걸친 Performance Testing은 다음 그림에서 표현되고 있습니다.
“30% consider the lack of skills as the greatest impediment”
Skills에 대해 기대하는 범위는 숨이막힐 정도로 넓습니다. 예를 들어, Performance Engineers는 Networking, Databases, Storage 등의 한계를 이해하는 것 뿐만 아니라, 아키텍처적인 의사결정 및 구성 논의에 참여해야 할 필요도 있습니다. 이들은 또한 전체적인 재난복구전략의 일환으로 비즈니스 연속성 계획에 기여하고, 변화를 예측하기 위해 비즈니스와 협력하고, Cloud 인프라 및 환경설정에 지식이 있으며, 상용환경 텔레메트리(Telemetry)에 대해 선제적으로 적용해야할 수도 있습니다.
The performance engineering agenda is packed with must-do activities
Performance Engineers의 역할은 테스팅과 튜닝에 집중하던 것에서, Application Performance의 전체 Lifecycle에 초점을 맞추어 회사의 열망을 이끄는 위치(the position of driving the ambition for the company)로 진화해오고 있습니다. 아래의 차트는 각각의 주요 활동에서 소요된 시간을 보여주고 있습니다.
시간의 18%는 비즈니스 팀들과 소통하는데 사용됩니다. 이것은 역량이 성숙하다는 강력한 신호이지만, 지속적인 협업보다는 여전히 프로젝트 개발주기 마지막 단계의 한 지점에서의 소통으로만 진행되는 경우가 일반적입니다.
기업들은 자신의 시장에 대해, 그들의 경쟁자가 누구인지, 그리고 대표하는 고객들이 누구인지 잘 알고 있습니다. 이 모든 것은 Performance Engineering과 연관이 있습니다. 따라서, 비즈니스와 기술팀 모두가 사용자 페르소나(User Persona), 사용자 흐름(User Flows), 역량 및 요구사항(Capabilities and Requirements), 그리고 시간이 지남에 따라 이들이 어떻게 진화하는지에 대해 협력하여 업무를 수행할 수 있습니다. 물론, 비즈니스는 구체적이고, 시의적절하며, 의미있는 피드백을 제공하는 것이 필요합니다.
Performance Engineering은 여전히 노동 집약적인 상태로 남아있으며, 12%의 시간을 새로운 테스트 설계에 사용하고, 16%의 시간을 기존 테스트 스크립트들을 업데이트하고 유지보수하는데 사용합니다. 출시주기(the release cadence)가 가속화됨에 따라, 스크립트를 생성하고 업데이트해야 할 필요성은 더욱 빈번하게 발생할 것입니다. 테스트 스크립트가 최신 상태로 유지되고, 테스트와 동일한 속도로 적용될 필요가 있습니다.
Performance Testing은, 만약 이들의 역할이 스크립트를 수작업으로 편집하고 업데이트하는 것에 있다면, (프로젝트 팀에) 인질처럼 붙잡혀 있게되는 위험에 처할 수도 있습니다. 뿐만 아니라, 스크립팅에 소비되는 많은 시간과 에너지는, 보다 전략적이고 가치있는 업무를 위해 사용할 수 있는 시간들을 줄어들게 만듭니다.
보다 역량있고 도움을 주는 자동화 도구를 선정하는 것은, 테스트 스크립트 유지보수에 필요한 시간을 크게 줄여줄 수 있습니다. Code 변경 이해 및 재작성이 필요없는 스크립트 업데이트 지원 등과 같이 Engineers를 지원하는 역량들은, Performance Engineers가 테스트 스크립트를 생성하고 업데이트하는것 보다는, 테스트 결과를 분석하는데 보다 많은 시간을 할애할 수 있도록 도와줍니다.
Performance Testing은, Component에서부터 전체 시스템 차원의 Load Tests까지, 전체 Lifecycle에 걸쳐 배포 속도를 지원하기 위해, Continuous Delivery Pipelines와 통합될 필요가 있습니다.
15%의 시간은 performance tests의 자동화에 사용됩니다. 개발자에게 회귀(Regressions)에 대한 초기 Feedback Loop 및 가시성을 제공하는 것은 중요합니다. 여기에는 Build Process 동안 주요 Components를 테스트하고, Project Maintenance를 자동으로 처리하고, Load Policy를 정기적인 모니터링을 통해 수집된 관찰결과에 근거하여 지속적으로 적용하는 능력이 포함됩니다. 이러한 활동은 기능 테스트의 자동화와는 크게 다릅니다.
모든 유형의 Performance Tests가 전체적인 자동화에 적합한 것은 아닙니다. Intense, Long-running, Large-scale, End-to-end Performance Testing은 Core CI/CD Process의 바깥에 위치하는 것이 더 적합할 수 있습니다. 우리는 이 주제에 대한 보다 깊이있는 연구를 통해 내년 보고서에서 다룰 예정입니다.
Performance Monitoring은 신뢰기반 문화의 핵심 요소입니다. 이러한 모니터링 활동은 대부분 상용환경에서 수행됩니다.(20%의 시간)
- App이 적절하지 않은 상황하에서 보여주는 기능과 성능
- 시스템의 다양한 구성요소(e.g. network, memory)
- 최종 사용자의 행동(e.g. usage patterns, flows)
- 최종 사용자의 정서와 피드백
우리는 모니터링이 전체 Lifecycle에 걸쳐 확장되어야 하며, Application Performance와 관련된 모든 활동에 종합적인 가시성(Comprehensive Visibility)을 가지고 있어야 한다고 믿습니다. 모니터링은 Shift-left Culture 속에서 자리잡고 있습니다. 이것은 상용전 환경(pre-production)에서 사용되는 아키텍처의 다양한 구성요소들이 어떻게 사용되는지에 대해, 개발자에게 확실한 이해를 제공할 수 있습니다. 이것은 계획된 변경, DB 쿼리 최적화, 그리고 시스템 설정값 튜닝의 영향을 예측하는데 매우 유용합니다.
The urgency to increase team awareness
응답자의 71%는 자신의 조직이 상용화 이전에 테스트를 수행하고, 성능 이슈들을 찾는 업무를 상당히 잘 수행하고 있다고 답변했습니다. 우리는 몇몇 구성원들이 이렇게 대답을 한 이유가, 상용화 이전에 실제로 많은 성능 이슈들을 찾을 수 있었다는 명확한 근거가 있어서라기 보다는, 테스트가 정확하게 수행되길 원하는 희망사항 때문에 이러한 답변을 선택한 것은 아닌지 의심하고 있습니다.
우리의 경험상, Performance Engineering(및 관련 주제들)이 실제로 무엇을 포함하고 있는지에 대해 너무 낮은 이해수준을 보이고 있습니다. Peformance는 Performance Testers에게만 맡기기에는 너무 중요합니다. 종종 Performance Engineering은 비즈니스 관련 권고사항을 제공하는것 보다는, 기술중심의 것으로 간주되곤 합니다. 잘 수행만 된다면, 이것은 장기적인 생존과 지속가능성을 모두 지원할 수 있게 되며, 한두명의 전문가보다는 모두에게 중요한 문제가 됩니다.
Performance Engineering에 대한 가장 효과적인 접근방식은, 가능한 빠르게 요구사항 단계(Shift-Left)부터 시작하는 것입니다. 그러나, 기본적인 수준의 성능 요구사항을 얻으려고 노력할때 조차도, 많은 프로젝트와 팀들이 어려움을 겪을 수 있습니다. 너무나도 많은 회사들이, 종종 그들의 성공에 대한 측정지표로서, 현재 시스템의 ‘Poor Performance’만 걱정하는 패턴에 빠지고 있습니다. 예를 들면, “현재 시스템만큼 빨라야합니다”, 또는 “현재 시스템보다 나쁘지 않아야 합니다”와 같은 접근입니다. 이러한 접근법으로 인해 매년 많은 팀들이 걱정하고 실망하는 반복적인 흐름을 보여주고 있습니다.
비즈니스 생존능력의 본질을 구성하는 한 부분으로서 System Performance의 엄청난 성장을 고려할 때, 상용화 이전에 우수성을 확보하기 위한 방안으로, 정확하고 신뢰할만한 Performance Tests를 수행하는 조직의 역량에 대해 평가하고 있다는 답변을 응답자의 12%만이 했다는 점에 우리는 실망했습니다.
Test environments are failing performance engineering
“33% of respondents face difficulties in reproducing a test environment that mirrors production”
종종 대표성 부족(the lack of representability), 비현실적인 요구사항(unrealistic requirements), 그리고 인프라팀과의 협업 부족으로 문제들이 발생합니다. 테스트 환경은 정확하게 상용환경을 복제할 필요는 없지만, 유사한 특성을 가질 필요는 있습니다. Cloud Infrastructure는 이제 대표적인 상용환경의 재현을 가능하게 합니다.
Recommendation: 주문 가능한 일관된 환경에 의존하는 능력(The ability to rely on consistent environments being available on-demand)은 Agile Performance Engineering을 위한 기본 요구사항입니다. 이것은 DevOps가 종종 요구하는 변화의 빠른 속도 속에서, 생명력을 유지하는 Performance를 가능하게 합니다.
많은 팀들이 인프라 제공관리의 복잡도를 감소시키기 위해, 구성관리 자동화 도구를 사용하고 있습니다. 이들은 정확하고, 쉽고, 신뢰할만한 테스트 환경 구성을 위해, 동일한 자동화 도구 및 상용환경과 동일한 구성정보를 사용할 수 있습니다. 이를 통해, 특정 테스트 환경을 위한 구성에서 근본적인 비교우위를 가질 수 있습니다. 동일한 자동화 도구와 소스를 사용함으로써 쉽게 식별하고, 체크하고 제어할 수 있습니다.
구성정보(configuration truth)의 단일 소스를 가지는 것은, 테스트 환경을 정확하고 자동으로 구성하고 운영하는데 사용될 수 있습니다. 빠르고 정확하게 적절한 테스트 환경을 On-demand로 구축하는 능력은, 신속한 실험과 혁신을 촉진시켜 줍니다.
Let’s flip our DevOps mindset around
OpsDev는 운영에서의 자동화 도구와 사례를 소프트웨어 개발 및 테스팅으로 가져오는 것입니다. 이것은 또한 개발팀이 상용환경에 배포하기 전에, 이들의 작업이 운영상의 영향이 있는지를 고려하는데 도움을 줄 수 있습니다. 우리가 앞에서 언급한 바와 같이, 상용환경에서 구성을 돕고 테스트 환경을 생성하기 위해 구성관리를 사용하는 것이 한 측면입니다. 상용환경과 테스트 환경에서 동일한 모니터링 자동화 도구를 사용함으로써, 개발자와 테스터가 자신의 소프트웨어가 어떻게 모니터링 되는지 바로 볼 수 있게 됩니다.
우리는 OpsDev를 개발과 테스팅 활동을 풍부하게 해줄 의도를 가진 반복적인 프로세스로 보고 있습니다. Performance Testing과 모니터링은 모두 독립적으로 가치있는 영역입니다. 그러나, 이 둘이 효과적으로 결합될 때 그 가치는 현저히 커지게 됩니다. 상용환경에서의 Performance 모니터링은 표준이 되어가고 있지만, 여전히 전체 프로젝트의 1/3 정도에만 적용되고 있습니다.
APM(Application Performance Management) 자동화 도구를 사용함으로써, 팀들이 기존 시스템의 실제 사용자의 행동을 이해하고, Performance Tests 수행 시 사용되는 객관적인 기준을 정의하는데 도움을 줍니다.
상용환경 모니터링 데이터는 애플리케이션 행동과 근본적인 상호작용에 대한 통찰력에 접근할 수 있도록 지원합니다. 사용패턴은 서로 다른 네트워크 연결에 기반하여 모델링할 수 있습니다. Google에서 출간한 연구에서 이러한 유형을 발견했는데, 네트워크의 Performance가 사용에 주요한 영향을 미칠 수 있습니다. Performance는 최종 사용자 관점에서 End-to-end Performance를 측정함으로써 Performance를 개선할 수 있습니다.
SQL breakdowns(execution plans), Infrastructure Components(CPU, disk, network, and memory), 그리고 Heap Size 등과 같은 상용환경의 기술적인 세부사항들은, 보다 정확한 테스트를 만드는 것을 촉진할 수 있습니다. 또한, 상용환경 정보를 소스로 사용하는 접근방식은, 다양한 Staging 환경 사이의 차이를 식별하는데 도움을 줄 수 있습니다.
모니터링 및 분석 자동화 도구는 다양한 상용전 단계(pre-production phases)에서 사용될 수 있습니다. 소프트웨어 개발주기 전체에 걸쳐 공통 모니터링 자동화 도구를 사용함으로써, 개발, 테스트, 그리고 운영 역할간의 공통 언어가 확립됩니다.
일부 회사들은 Performance Issues를 빠르게 파악하는 것을 돕기 위해 최종 사용자의 피드백을 모니터링합니다. 사용자에 의해 문제가 보고되었을 때, 회사들은 즉시 조사에 나설 수 있습니다. 동시에, 이들은 빠르고, 적절하며, 긍정적인 비즈니스 반응을 만들 수 있습니다. 예를 들어, 이들은 상황을 개선하기 위해 온라인 공지를 추가하고, 고객이 리포트한 문제에 접근할 수 있습니다. 사용자들은 자신의 피드백이 중요하다는 것을 인식하게 될 때 회사에 대해 호의적으로 바라보게 되는 경우가 많으며, 결국 모두가 이기는 상황이 됩니다.
내부 패키지 애플리케이션의 경우 일부 조직들은 비즈니스 이해관계자들의 인터뷰를, 서비스 관리 자동화 도구에 기록된 Incidents의 분석 내역과 결합하여 사용합니다. 곧, 모니터링 자동화 도구는 사용자의 잦은 클릭(Over-clicking) 또는 불만의 표시로 사용자 인터페이스를 새로고침(Refreshing)하는 행동 등을 감지할 수 있게 될 것입니다.
[다음 글에서 Chapter 4가 계속됩니다.]
Source: https://www.us.sogeti.com/explore/research/reports/state-of-performance-engineering/