지난번 포스팅에서는 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)
- POC는 다음과 같은 내용을 제공해주기 때문에 중요한 필요조건이다.
- 타겟 어플리케이션에 대해 Performance test 툴의 기술 평가할 기회를 제공한다.
- 스크립팅 데이터 요구사항을 확인한다.
- 스크립팅 작업을 평가할 수 있게 한다.
- 타겟 어플리케이션에 대해 Performance test 솔루션의 능력을 증명한다.
그러면 이제 POC Checklist를 살펴보자.
Prerequisite
- 테스터와 고객이 POC의 성공이나 실패를 결정하는 데 동의할 수 있는 성공의 집합 또는 종료 기준이 되는 점을 정해야 한다. POC를 시작하기 전, 이에 대한 계약서를 작성해야 한다.
- 최소 사양의 하드웨어와 소프트웨어로 이루어진 standard build workstation이나 client platform을 사용해야 한다.
- 서버와 네트워크 모니터와 같은 application landscape(소프트웨어 어플리케이션을 배포하는 데 필요한 서버와 네트워크 인프라 스트럭쳐)에 필요한 모든 모니터링 소프트웨어 설치 권한이 있어야 한다.
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를 끝내는 마감날짜가 있어야 한다.
- 테스트를 수행하는데 내부 리소스와 외부 리소스중 무엇을 사용할지를 확인한다.
- 테스트 환경 설계를 합의한다. 테스트 환경은 실제 환경과 최대한 유사하게 만들어야 한다.
- 각 테스트 사이클 안에서 코드 프리즈 된 상태로 테스트 환경에 적용해야 한다.
Step 2: Test Environment Build
테스트 환경 구축은 다음과 같은 스텝으로 구성한다.
- 장비를 소싱하고, 환경을 구성하고 구축하기 위해 충분한 시간이 필요하다.
- 외부 시스템에 계정 링크를 넣어라. 외부링크는 Performance 바틀넥을 위한 주요 위치이기 때문에 절대 무시하면 안 된다.
Step 3: Transaction Scripting
아래의 트랜젝션들은 스크립트 되어야 한다.
- 트랜젝션 런타임 데이터 요구사항을 확인한다.
- 트랜젝션 인풋 데이터 요구사항을 확인하고 적용한다.
- 응답시간을 위한 별도의 모니터링을 위해 트랜젝션 점검 사항을 정한다.
- 싱글 유저와 멀티유저에 대해 트랜잭션 리플레이를 올바르게 하는 것을 보장하라. 그리고 리플레이할 때 무슨 일이 있었는지 확인하라.
Step 4: Performance Test Build
각 Performance 테스트에서 다음과 같은 포인트들을 고려하라.
- 베이스라인 테스트, 과부하 테스트 또는 soak 테스트인가? 전형적인 시나리오는 각 트랜젝션을 우선하는 베이스라인 테스트이다. 그리고 나서는 독립된 싱글 유저로서 최대 커런시 또는 처리량을 목표로 테스트하라. 독립테스트 하라. 그리고 모든 트랜잭션과 연결된 로드테스트부터 타겟 concurrency 까지 발생하는 모든 문제에 대해 대처하라.
- 스트레스 테스트가 아닌 이상 테스트 안에서 어떻게 "think time”과 "Pacing"을 각 트랜젝션에 대해 나타낼 것인지 결정하라.
Step 5: Performance Test Execution
테스트를 실행하고 모니터한다.
- 로드 인젝션 용량이 충분한지 확인하기 위하여 "dress-rehearsal" 테스트를 실행해본다.
- “이상적인" 응답시간 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 테스트와 스트레스 테스트를 포함한다.
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
'Newbie's Log' 카테고리의 다른 글
| UML(Unified Modeling Language)-Part 2 (0) | 2014.04.24 |
|---|---|
| Logstash와 Elasticsearch Performance Test -Logstash Performance Test (0) | 2014.04.18 |
| Maven에 대해 알아보자 #2 (0) | 2014.04.15 |
| UML(Unified Modeling Language)-Part 1 (0) | 2014.03.21 |
| RabbitMQ와 Redis를 활용한 프로그램 개발 2차 중간 보고 (0) | 2014.03.17 |
