"The Art of Application Performance Testing"을 읽고 나서...part2

지난번 포스팅에서는 Performance test를 왜 하고, 하기 전에 고려해야 할 사항에 관해 이야기했었다. 이번에는 이 책의 핵심 부분을 이야기하겠다.

핵심 부분은 크게 두 가지로 나뉜다.

1. Performance test의 진행 과정에 대한 체크리스트.

2. Performance test 결과에 대해 효과적인 root-cause 분석을 도와주는 체크리스트.

이번 포스팅에서는 이 체크리스트들을 소개하겠다.

Performance test의 과정

먼저 Performance test는 아래와 같은 구성으로 진행된다.

Step 0. The Proof of Concept (POC) Step 1. Pre-Engagement Requirement capture Step 2. Test environment Build Step 3. Transaction Scripting Step 4. Performance Test Build Step 5. Performance Test Execution Step 6. Analyze Results, Report, Retest

Step 0. The Proof of Concept (POC)

Performance test 시작할 때 우리는 마구잡이로 테스트를 실행하지 않을 것이다. 일단 Performance test 대상이 생기면 테스트에서 요구되는 사항부터 확인해야 한다. 그러므로 Performance test에 앞서 POC 확인을 해야 한다.

• POC는 다음과 같은 내용을 제공해주기 때문에 중요한 필요조건이다.
• 타겟 어플리케이션에 대해 Performance test 툴의 기술 평가할 기회를 제공한다.
• 스크립팅 데이터 요구사항을 확인한다.
• 스크립팅 작업을 평가할 수 있게 한다.
• 타겟 어플리케이션에 대해 Performance test 솔루션의 능력을 증명한다.

그러면 이제 POC Checklist를 살펴보자.

Prerequisite

• 테스터와 고객이 POC의 성공이나 실패를 결정하는 데 동의할 수 있는 성공의 집합 또는 종료 기준이 되는 점을 정해야 한다. POC를 시작하기 전, 이에 대한 계약서를 작성해야 한다.
• 최소 사양의 하드웨어와 소프트웨어로 이루어진 standard build workstation이나 client platform을 사용해야 한다.
• 서버와 네트워크 모니터와 같은 application landscape(소프트웨어 어플리케이션을 배포하는 데 필요한 서버와 네트워크 인프라 스트럭쳐)에 필요한 모든 모니터링 소프트웨어 설치 권한이 있어야 한다.

어플리케이션에 POC의 기간을 위한 단독 접근이 이상적이다.

어플리케이션에 친숙한 사람(전문사용자)와 만나서 유용성에 대한 질문에 대답해주어야 한다.

타겟 어플리케이션을 위해 적어도 두 세트의 login credential이 있는지 확인한다.

2세트를 요구하는 이유는, 많은 operation은 1명이 사용할 때와 그 이상의 사용자가 있을 때 각각 다르게 행동하기 때문이다. 그러므로 POC를 다수의 사용자가 사용할 수 있게 해야 한다.

POC를 위해 2개의 샘플 트랜젝션을 기준으로 사용하게 한다. 한가지 트랜젝션은 간단한 read-only 작업이어야 하고, 다른 한가지는 타겟데이터 저장소를 업데이트하는 복잡한 트랜젝션이어야 한다. 이것들은 transaction replay 작업을 정확하게 해준다.

Process

이 리스트는 POC가 추후 테스트를 위한 확실한 근거를 제공하게 하는 데 도움이 된다.

• 각 샘플 트랜젝션의 두 개의 인스턴스를 기록하고 가장 편리한 방법을 사용하여 그것들의 다른 점을 비교하라.
• (Windiff를 사용하는 것이 하나의 방법이 될 수 있다.) Performance Test 툴은 이 가능성을 준비해야 할 것이다.
• 입력데이터와 런타임 데이터 요구사항과 더불어 스크립트에 필요한 모든것을 수정후 각 트랜젝션은 단일사용자와 다중 사용자 모드에서 리플레이가 일치하는지 확인하라.
• 모든 데이터베이스 엄데이트들이 예상대로 일어나는지 확인하고 트랜젝션에 대한 리플레이 로그에 에러가 없는 것 또한 확인하라. POC 에서 스크립트 수정 시 메모리 누수나 다른 불필요한 수행들이 없게 하라.

Deliverable

아래의 내용은 POC의 결과와 신뢰성을 가진 후속 프로젝트에 접근하기 위한 기준이다

• POC의 결과는 Performance Test 툴의 성공적인 스크립팅과 어플리케이션 트랜젝션 리플레이를 위하여 기술적으로 적합한 go/no-go 평가가 되어야 한다.
• Performance 테스트 프로젝트를 위한 likely data 요구사항에 샘플 트랜젝션과 통찰력을 얻기 위하여 입력데이터와 런타임 데이터 요구사항을 확인해야 한다.
• 정밀한 리플레이와 어플리케이션 트랜잭션 스트립트를 하려는 일반적인 소요시간을 보장하기 위하여 모든 스크립트 변경 요구를 확인해야 한다.
• 만약 이것이 판매 사이클의 일부라면, 고객을 감동을 주고, 모든 합의된 성공기준에 부합하고, 판매 종료까지 잘해야 한다.

Performance Test Execution Checklist

스크립팅 Performance Test 트랜잭션 : 트랜잭션 한 개에 반나절 할당다음은 활동기간 설정 가이드 라인이다.

• Performance Test 세션 또는 시나리오를 만들고 검증: 보통 1~ 2일 할당
• Performance Test 실행 : 최소 5일 할당
• 데이터 콜렉션 (그리고 소프트웨어 제거) : 하루 할당

이제 본격적인 Performance Test를 위한 Checklist를 소개하겠다.

Step 1: Pre-Engagement Requirements Capture

• 배포날짜가 예정되어있고 Performance Test를 끝내는 마감날짜가 있어야 한다.
• 테스트를 수행하는데 내부 리소스와 외부 리소스중 무엇을 사용할지를 확인한다.
• 테스트 환경 설계를 합의한다. 테스트 환경은 실제 환경과 최대한 유사하게 만들어야 한다.
• 각 테스트 사이클 안에서 코드 프리즈 된 상태로 테스트 환경에 적용해야 한다.

테스트 환경은 다른 사용자 활동에 영향을 주지 않아야 한다. Performance 테스트 실행 중에 아무도 테스트 환경을 건드리지 말아야 한다. 그렇지 않으면 테스트 실행과 결과에 나쁜 영향을 줄 수 있다.

Performance Test를 위하여 적절한 툴과 리소스를 사용 가능하여야 한다.

모든 팀멤버가 툴과 익숙해지도록 적절한 트레이닝을 받아야 한다.

리소스, 타임라인, 그리고 마일스톤을 포함한 고급수준 계획을 개발한다.

관련된 타임라인, 자세한 시나리오와 테스트 케이스, 워크로드 그리고 환경 정보를 포함한 세세한 Performance Test 계획을 설정한다.

계획대로 일이 진행되지 않는 경우를 대비하여 일정이나 성능 목표를 충족하지 않는 것에 대한 위험평가를 포함하여야 한다.

Step 2: Test Environment Build

테스트 환경 구축은 다음과 같은 스텝으로 구성한다.

• 장비를 소싱하고, 환경을 구성하고 구축하기 위해 충분한 시간이 필요하다.
• 외부 시스템에 계정 링크를 넣어라. 외부링크는 Performance 바틀넥을 위한 주요 위치이기 때문에 절대 무시하면 안 된다.

테스트 환경에 어플리케이션이 제대로 배포가 되었는지 확인하라.

Performance test 툴 환경을 설정 및 배포하라. Performance test 솔루션 환경을 제대로 설정 및 설치하였는지 확인하라.

KPI 모니터링 툴 환경을 설정 및 배포하라. 이 과정은 Performance test 솔루션이나 독립된 툴 셋의 일부일 수 있다. 두 가지 경우 모두 원하는 결과정보를 제대로 구성하게끔 확인하라.

Step 3: Transaction Scripting

아래의 트랜젝션들은 스크립트 되어야 한다.

• 트랜젝션 런타임 데이터 요구사항을 확인한다.
• 트랜젝션 인풋 데이터 요구사항을 확인하고 적용한다.
• 응답시간을 위한 별도의 모니터링을 위해 트랜젝션 점검 사항을 정한다.
• 싱글 유저와 멀티유저에 대해 트랜잭션 리플레이를 올바르게 하는 것을 보장하라. 그리고 리플레이할 때 무슨 일이 있었는지 확인하라.

Step 4: Performance Test Build

각 Performance 테스트에서 다음과 같은 포인트들을 고려하라.

• 베이스라인 테스트, 과부하 테스트 또는 soak 테스트인가? 전형적인 시나리오는 각 트랜젝션을 우선하는 베이스라인 테스트이다. 그리고 나서는 독립된 싱글 유저로서 최대 커런시 또는 처리량을 목표로 테스트하라. 독립테스트 하라. 그리고 모든 트랜잭션과 연결된 로드테스트부터 타겟 concurrency 까지 발생하는 모든 문제에 대해 대처하라.
• 스트레스 테스트가 아닌 이상 테스트 안에서 어떻게 "think time”과 "Pacing"을 각 트랜젝션에 대해 나타낼 것인지 결정하라.

모든 트랜잭션은 얼마나 많은 로드 인젝터를 배포하고, 또 얼마나 많은 "virtual users”가 각 인젝션 포인트에 할당될 것인지 결정한다.

테스트는 특정 시간만큼 또는 처리할 데이터가 바닥나면 멈출 것인가? 아니면 특정 숫자만큼의 트랜잭션이 반복될 때까지 실행할 것인가? 혹은 사용자가 멈출 때까지 테스트를 실행할 것인가?

각각 다른 baud rates를 시뮬레이트 해야 하는가? 그렇다면  다른 baud rates가 요구됨을 확인하라. Performance test에 앞서서 실시한 모든 응답시간 예상 또는 용량 모델링은, 어플리케이션이 대역폭 제한에 어떻게 반응하는가에 대해 귀중한 통찰력을 줄 것이다.

이미 셋업된 서버와 네트워크 KPI들을 사용하기 위하여 어떤 런타임 모니터링을 구성해야 하는가?

Performance test 디자인에 영향을 줄 수 있는 모든 어플리케이션에 대해 고려하라.

Step 5: Performance Test Execution

테스트를 실행하고 모니터한다.

• 로드 인젝션 용량이 충분한지 확인하기 위하여 "dress-rehearsal" 테스트를 실행해본다.
• “이상적인" 응답시간 Performance 잡기 위하여 베이스라인 테스트를 실행한다.
• 로드 테스트를 수행한다. 이상적으로는 실행과 실행 사이에 타겟 데이터베이스내용을 다시 설정한다.

부하 테스트로 알려진 모든 문제를 찾아내기 위해 독립 테스트를 한다. 그러고 나서 개발자 또는 응용프로그램 공급업체에 결과를 제공한다.

고용량 트랜젝션 실행과 관련된 메모리 누수 그리고 문제점을 공개하기 위하여 (시간이 된다면) soak 테스트를 실행하라

추후 트랜젝션 크기와 응용프로그램 사용자의 증가를 고려하여, 데이터를 만들어내기 위한 과부하 테스트를 실행하라.

Performance와 관련 없는 모든 테스트를 수행한다.

Step 6 (Post-Test Phase): Analyze Results, Report, Retest

• Performance tests 프로젝트의 일부로 만들어진 모든 데이터를 캡쳐하고 백업하라.
• Performance 타겟과 테스트 결과를 비교하라. 이것은 프로젝트 성공과 실패를 결정해준다.
• 프로젝트 결과를 문서화 하라. 문서에는 모든 Performance tests에 대해 다루어야 한다.
• End User Experience(EUE) 모니터링을 위해 베이스라인 데이터로써 마지막 결괏값을 사용하라

여기까지는 Performance test를 수행할 때 고려해야 할 Checklist였다.

이제 Performance test를 수행 후 분석할 때 사용할 수 있는 Checklist를 소개하겠다.

결과값의 효과적인 root-cause 분석

Pre-Test Tasks

• 적절한 서버, 어플리케이션 서버, 그리고 네트워크 KPI들을 구성하였는지 확인하라.
• 서버에 설치와 에이전트 소프트웨어를 구성할 때 어려운 점이 없음을 확인하라.실행할 Performance test의 최종 혼합을 결정하라. 이 최종 혼합은 보통 베이스라인 테스트, 부하 테스트, 모든 에러가 발견된 독립 테스트, 그리고 soak 테스트와 스트레스 테스트를 포함한다.

인젝터로부터 어플리케이션에 접근할 수 있는지 확인해야 한다.

Performance test 구성의 일부로써 Performance 타겟을 위한 모든 가능한 자동임곗값을 정하라.

Performance test 툴이 기능을 제공된다면, 트랜젝션 응답시간, 동시 가상 사용자 그리고 서버 또는 네트워크 KPI 측정기준 간의 자기상관을 구성하라.

KPI 모니터링의 일부 혹은 전부를 제공하는 타사 도구를 사용한다면 그 타사 도구들이 어떤 테스트를 실행하기 전에(이상적으로는 "dress-rehearsal"에 포함하여라) 제대로 구성되어있는지 확인해야 한다.

Tasks During Test Execution

• 로드 인젝터들이 부하가 걸리지 않도록 정기적으로 로드 인젝터의 Performance를 검토하라.
• 실행한 모든 테스트를 문서로 만들어라. 최소한 다음의 정보들을 기록하라.
• Performance test 실행 파일 이름과 실행한 날짜와 시간.
• 테스트가 구성에 대한 간략한 설명.
• 현재 테스트 실행과 관련된 결과물의 파일의 이름.
• Performance 테스트와 관련된 트랜젝션이 연관된 모든 인풋 데이터 파일.
• 테스트 중에 발생한 모든 문제에 대해 간략한 설명.

• 다음과 같은 점은 실행 중에 조심해야 할 사항들이다.
• 오류의 갑작스러운 출현을 주의하라. 소프트웨어 어플리케이션 배포하기 위해 서버와 네트워크 인프라스트럭처가 요구되는 환경 안에서 어떤 한계에 다다르게 되는 것이 종종 나타난다(데이터가 다 소진되거나 운영시스템의 디폴트 세팅이 간섭받는 것을 의미한다).
• 사용 가능한 서버 메모리의 지속적인 감소를 주의하라. 가상 사용자들이 활성사용자가 되면 사용 가능한 메모리가 점점 줄어들 것이다. 그러나 만약 모든 사용자가 활성사용자로 바뀌고 나서도 메모리가 줄어들면 그것은 메모리 누수다.

Post-Test Tasks

• 모든 테스트 실행에 관련된 모든 데이터를 모은다. 만약 데이터 모니터링을 하는데 타사 도구를 사용했다면 필요한 파일들을 보존해 놓으라.
• 모든 테스트 리소스들(스크립트, 인풋데이터 파일, 테스트 결과)에 대해 다른 저장소에 백업하라.
• 보고서는 사전 테스트 요구 사항 모으기 단계의 한 부분으로 설정 한 성과 목표에 결과를 대치해야 한다.

체크리스트가 포함되어 길고 긴 포스팅이 되었다.

Performance test는 기본적으로 복잡하고 어려운 기술이라고 말할 수 있다. 테스트 대상에 대해 기술적 뿐만 아니라 구조적으로도 잘 알고 있어야 수행할 수 있는 부분들이 많기 때문이다.

그래서 위에 기술된 체크리스트는, 좀 더 정밀한 Performance test를 수행하는 데 많은 도움이 된다.

사실 이 책 내용이 초심자에겐 읽기 어려운 책인 것 같다.

Junior 개발자로서 정확히 이해할 수 없었던 용어들이 많았고, 검증할 때 어떤 기술이 쓰이는지 알지 못했기 때문이다. 그럼에도 불구하고, "The Art of Performance Testing”은 한 번쯤은 읽어보기를 권장한다.

이 책은 나에게 Performance test의 개념에 대해 큰 그림을 보게 해 주었고, 어플리케이션 개발 후 성공적인 배포가 되려면 Performance test가 중요하다는 점을 알려준 책이었다.

아마 개발자로 일하면서 (그리고 그 후에 무슨 일을 접하더라도) 프로그램 배포 전에 “Performance test는 선택이 아니라 필수 과정이야!” 라는 외침이 머릿속 어딘가에 오래도록 남아있을 것 같다. 물론 Performance test를 할 수 없는 상황이 많겠지만, 훗날 내가 개발한 프로그램에 대해 Performance test를 위에서 언급된 부분 중에 한가지 이상 수행할 수 있다면 좋겠다.

이것으로써 "The Art of Application Performance Testing” 책에 대해 포스팅을 마치겠다. 

Reference :

"The Art of Application Performance Testing" by Ian Molyneaux