'The Art of Application Performance Testing'에 해당되는 글 2건

  1. 2014.04.17 "The Art of Application Performance Testing"을 읽고 나서...part2
  2. 2014.03.17 "The Art of Application Performance Testing"을 읽고 나서...part1

지난번 포스팅에서는 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 알 수 없는 사용자
,

입사 후 교육과정의 하나였던 "The Art of Application Performance Testing"이라는 책을 읽은 후, 개발자라면 한 번쯤은 읽어보면 좋은 내용이라고 생각되어 이 책을 주제로 두 번에 걸쳐서 포스팅하겠다.




일단 이 책은 원서였고, 초보 개발자의 눈에는 기술된 용어 자체가 무슨 뜻인지 모르는 것들이 너무 많아서 책이 무슨 말을 하는지 파악하기가 힘들었다. 하지만 책을 다 읽고 난 후에 내 머릿속에 남은 것은 퍼포먼스

테스팅을 절대로 무시하면 안 되는 단계라는 것이었다.

먼저 이 책을 읽고 난 초보 개발자 레벨에서 소감을 얘기하자면,


    • 퍼포먼스 테스팅은 프로그램의 질을 향상해준다.

    • 프로그램 성능을 뒷받침해주는 자료가 된다

    • 사용자의 프로그램 사용 만족도를 올려준다.


다시 말해 퍼포먼스 테스팅은 프로그램을 안정적이게 만들어주고 사용할 때 편하게 해줌으로써 사람들이 믿고 쓰게 되는 동시에 그 프로그램을 만든 회사의 로열커스터머가 발생할 수 있다고 생각했다. (예를 들자면 애플 제품만 사용하는 사람들이라든지, 아니면 애플을 매우 사랑하는 사람들이라든지)


이 책에서 제시한 체크리스트들을 통하여 퍼포먼스 테스팅 가이드라인을 잡는 데 도움이 될 수 있는 내용을 소개하고자 한다.


I.왜 퍼포먼스 테스트를 하는가?


이 책의 저자는 "퍼포먼스를 위한 테스팅의 중요함은 고려해볼 사항이 아닌 어플리케이션을 만드는 과정 일부로서의 가치를 지니고 있다." 라고 말하고 있다. 즉, 퍼포먼스 테스트는 선택이 아닌 필수가 되어야 한다는 것이다. 그러면 왜 우리는 퍼포먼스 테스트를 해야 하는가? 답은 간단하다. 뛰어난 성능을 보여주는 어플리케이션은 기업에 이윤을 창출해 주기 때문이다.

퍼포먼스 테스트의 종류는 크게 서비스 지향적 측정(유용성과 응답 시간)과 효율 지향적 측정(처리량과 이용률)으로 나눌 수 있다. 서비스 지향적 측정이라 함은 "사용자에게 서비스를 얼마나 잘 제공하는가?" 라고 정의할 수 있고, 효율 지향적 측정은 "자원을 얼마나 잘 활용하는가?" 라고 정의 할 수 있다.


퍼포먼스 테스팅은 이 두가지의 큰 틀 안에서 퍼포먼스 테스팅 전, 하는 도중, 그리고 하고 나서의 단계로 구분 지을 수 있다.


그러면 이제 퍼포먼스 테스팅을 하기 전에 고려할 사항에 대하여 이야기해 보겠다.



II. 효과적인 어플리케이션 퍼포먼스 테스트의 기초     성능 요구 사항을 확실히 하는 단계.



효과적인 어플리케이션 퍼포먼스 테스트를 위하여 새로운 프로젝트에 대해 우리는 다음의 사항에 대하여 질문해야 할 것이다.

    • 사용자들이 어디에 배치되어야 하는가? 그리고 그들이 어플리케이션에 어떻게 연결되어야 하는가?

    • 어플리케이션을 배포 했을 때 얼마나 많은 사용자가 존재하는가? 6개월 후? 12개월 후? 2년 후에는 어떠한가?


위의 질문에 대한 답은 다음과 같은 질문으로 이어 진다.

    • 각각의 어플리케이션 계층을 위하여 얼마나 많은 서버의 스펙이 필요한가?

    • 어떤 종류의 네트워크 인프라 스트럭쳐를 준비해야 하는가?


물론 이러한 질문들에 대하여 즉시 답할 필요는 없지만, 가능성과 퍼포먼스라는 두 가지의 중요한 관점을 미리 생각해야 할 것이다.

퍼포먼스 테스팅 계획을 구성할 때 많은 요소에 대하여 고려해야 하겠지만, 이 책의 저자는 다음과 같은 항목들을 중요하게 짚고 넘어가야 한다고 기술하였다.


1. 적절한 테스팅 툴 선택

적합한 성능 테스트 툴을 고른다.

테스팅 툴 설계 (자동화 테스팅툴들은 다음과 같은 구성을 가지고 있다.)

    • 스크립팅 모듈

    • 테스트 매니지먼트 모듈

    • 로드 인젝터

    • 분석 모듈

퍼포먼스 테스팅 툴은 다음에 소개되는 항목들을 포함해야 한다.

    • 툴 공급업체의 지원

    • 라이센싱 모델

    • Proof of Concept (POC)

    • 스크립팅 노력

    • 솔루션 VS 로드 테스팅 툴

    • 자체 제작 또는 아웃소스


2. 적절한 테스트 환경을 디자인

테스트 환경은 최대한 실제 환경과 유사하게 만든다.

    • 서버의 숫자와 사양

    • 대역폭과 네트워크 인프라스트럭처의 연결

    • 어플리케이션 계층의 숫자

    • 어플리케이션 데이터베이스의 크기 조정

테스트를 할 가상 환경 구비

테스트 가상환경에 대한 체크리스트

    • 서버 갯수

    • 로드 밸런싱 스트레티지

    • 하드웨어 목록

    • 소프트웨어 목록

    • 어플리케이션 구성 목록

    • 외부 링크


3. 현실적인 성능 목표를 설정

경영자와 그 외의 사람들간의 합의점 도출

핵심성능 목표 설정

    • 유용성 또는 가동시간

    • 동시성, 확장성, 그리고 처리량

    • 반응시간

    • 네트워크 사용률 (데이터 볼륨, 데이터 처리량, 데이터 에러 비율을 측정)과 서버 사용률(CPU사용률, 메모리 사용률 ,디스크 입출력, 디스크 공간을 측정)은 성능에 따른 용량의 지표에 사용될수 있다.


4. 퍼포먼스 테스트를 하기에안정적인 버전의 어플리케이션 준비


5. 코드 프리즈를 얻음


6. 비즈니스에 중요한 트랜잭션을 식별 및 스크립팅

트랜잭션 체크리스트

    • 탐색 경로에 대한 모호성이 없도록 각 실행 단계를 정의 및 문서

    • 모든 입력 데이터 요구사항과 예상되는 응답을 확인해야한다.    

    • 트랜잭션에 연관된 사용자의 타입을 결정한다.

    • 이 트랜잭션을 위한 커넥티비티 패스가 무엇인가?

    • 활성 트랜잭션일것인가 수동 트랜잭션일것인가?

트랜젝션 리플레이 검증

    • 단일 사용자 리플레이

    • 다중 사용자 리플레이


7.고품질의 테스트 데이터를 준비

인풋데이터 - 트랜젝션에 입력할 데이터

예) 자용자 자격증명, 검색 기준들, 관련 문서들

타겟 데이터 - 현실적인 분량의 유효 데이터를 이용하여 채울 수 있는 데이터.  

예) 사이징, 데이터 롤백

런타임 데이터 - 퍼포먼스 테스트를 실행할때 사용되는 데이터

데이터 시큐리티 - 보호되어야 할 데이터에 대한 툴을 사용


8. 정확한 퍼포먼스 테스트 디자인을 보장

각종 종류의 테스트를 만들어야 한다.

    • 베이스라인 테스트

    • 로드 테스트

    • 스트레스 테스트

    • 흡수 또는 안정성 테스트

    • 스모크 테스트

    • 아이솔레이션 테스트


9. 서버와 네트워크 모니터링 KPI를 식별함

제너릭 템플릿    

    • 프로세서 이용 비율

    • Top 10 프로세서

    • byte 단위의 사용 가능한 메모리

    • 초당 페이지 메모리

    • 물리 디스크: %디스크 타임

    • 네트워크 인터페이스 : 패킷 리시브드 에러

웹과 어플리케이션 서버 계층

    • IIS (Microsoft Internet Information Server)

    • Oracle application server (OC4J)

    • Oracle WebLogic (JRockit)

    • IBM WebSphere

    • JBOSS

데이터베이스 서버 계층

    • Microsoft SQL Server

    • Oracle

    • IBM DB2

    • MySQL

    • Sybase

    • Informix

메인프레임 계층

    • Strobe from Compuwave Corporation

    • Candle from IBM


10. 효과적인 퍼포먼스 테스트를위하여 충분한 시간을 할애

    • 비지니스 트랜젝션 식별과 스크립트하는 시간

    • 충분한 테스트 데이터 식별하고 만드는데 시간

    • 테스트 환경 도구 준비 시간

    • 퍼포먼스 테스트 준비하고 실행시키는데 들어가는 시간

    • 확인된 문제점을 해결하는 시간


우리는 이처럼 여러단계와 세세한 사항들이 퍼포먼스 테스트를 하기 위한 고려대상임을 알았다.

자, 이제 우리는 겨우 퍼포먼스 테스트를 시행하기 전 기초에 대해 준비가 되었다. 너무 많은 양의 준비가 필요하다고 생각되어지나? 어플리케이션의 운명을 좌우한다고 말할 수 있는 퍼포먼스 테스팅은, 이 많은 양의 준비과정을 거쳐 퍼포먼스 테스트를 좀더 효과적이고 짜임새 있게 만들어 준다.


그러면 다음 포스팅에서는 퍼포먼스 테스트의 과정과 결과 분석에 대하여 기술하도록 하겠다.



참고자료 : "The Art of Application Performance Testing" by Ian Molyneaux 



Posted by 알 수 없는 사용자
,