지난번 포스팅에서는 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(소프트웨어 어플리케이션을 배포하는 데 필요한 서버와 네트워크 인프라 스트럭쳐)에 필요한 모든 모니터링 소프트웨어 설치 권한이 있어야 한다.

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

Posted by 알 수 없는 사용자
,