Introduce to Performance test(4/5)
Updated:
안녕하세요!
지난번 포스트에서는 성능테스트 분석 단계의 Workload Modeling에 대해 살펴보았습니다.
전체 포스트는 아래와 같으며 이번 포스트에서는 네번째인 ‘설계 단계’에 대해 알아보겠습니다.
- 성능테스트 개요
- 사전점검 및 계획단계
- 분석 단계
- 설계 단계
- 실행 및 보고 단계
성능테스트 설계 단계에서는 분석 단계에서 검토한 내역을 바탕으로 테스트 구간/시나리오 및 케이스, 제약조건, 테스트 수행 상세 절차를 기술합니다.
시스템 분석을 통해 도출된 대상업무, 성능 목표를 기준으로 시스템의 특성에 따른 테스트 시나리오를 선정하게 되는데 On-Premise와 Cloud는 검증 항목이 다른 만큼 일부 다른 시나리오로 구성됩니다.
또한 설계 단계에서는 본격적인 성능테스트 수행 준비작업도 같이 진행하게 되는데요, 선정된 대상업무를 기준으로 테스트 자동화 툴 Script를 작성하고 필요 시 기초 데이터 및 테스트 데이터를 생성(또는 생성 요청)하며 부하 발생기(VM 혹은 노트북) 설치, 모니터링 자동화 툴 설치, 방화벽 해제 등 테스트 수행을 위한 제반 환경을 구축합니다.
성능테스트 설계서 작성
설계서 작성 단계에서는 테스트 시나리오/케이스 작성 및 제약조건, 수행절차를 정의합니다.
이때 분석단계에서 정의된 항목을 검토하여 각 시나리오/케이스 작성에 참조하며 작성된 설계서는 고객과 공유하여 검증 항목이 빠진것은 없는지 확인합니다.
1. 테스트 시나리오
시나리오는 기능테스트 시나리오와는 다른 형태의 시나리오 입니다.기능 테스트에서는 일련의 업무 흐름에 따른 단위 업무별 시나리오를 기준으로 작성하지만 성능테스트용 시나리오는 시스템의 안정성, 응답성, 구간별 특성등을 감안하여 선정하게 되며, 다음의 테스트 종류를 시스템 특성에 맞게 시나리오로 선정합니다.
A. Performance Test(Load Test)
성능테스트 대상 업무에 대해 산정된 기준 부하를 부여하였을 때 품질 목표, 요구사항정의서/명세서, 고객의 요구사항 등의 성능목표 만족 여부를 검증합니다.
[Performance Test 부하모델]
- 주요 검증항목
- 응답시간
- 시스템 자원(CPU, Memory, Disk 등)
- 처리량(TPS, Throughput 등)
- 테스트 방식
- Workload Modeling을 통해 산정된 Peak시점의 부하를 선정된 대상업무 전체로 Ramp-up – Duration – Ramp-down의 순서로 시뮬레이션 하여 Duration 동안의 성능 지표를 분석합니다.
B. Stress Test
성능테스트 대상 업무에 대해 부하를 일정 비율로 증가시켜 시스템 한계점 이상의 과부하를 발생하였을 때 수용 가능한 시스템의 최대 성능 및 사용자를 파악하고, 병목구간 및 부족한 자원이 무엇인지 확인합니다.
[Performance Test 부하모델]
- 주요 검증항목
- 병목구간 식별
- 응답시간
- 시스템 자원(CPU, Memory, Disk 등)
- 처리량(TPS, Throughput 등)
- 테스트 방식
- 시스템에 과 부하를 지속적으로 증가시켜 더 이상 시스템 처리건수가 증가되지 않는 시점을 확인합니다.
C. Volume Test
볼륨 테스트는 특정 양의 데이터로 응용프로그램을 테스트합니다. 대량의 데이터를 전송함으로 인해 발생할 수 있는 영향도 위주의 시나리오로 많은 사용자가 노래 파일을 다운받거나 온라인 스트리밍 영상을 감상하거나 대량의 데이터를 업로드 하는 방식으로 테스트를 수행합니다.
- 주요 검증항목
- 병목구간 식별
- 데이터 손실 여부
- 시스템 자원(CPU, Memory, Disk, Network Traffic 등)
- 처리속도(TPS, Throughput 등)
- 테스트 방식
- Workload Modeling을 통해 산정된 Peak시점의 부하를 선정된 대상업무 전체로 Ramp-up – Duration – Ramp-down의 순서로 시뮬레이션 하여 대량의 데이터 전송이 미치는 영향도를 분석합니다.
D. Fail-over Test
이중화 된 서버를 대상으로 기준부하를 부여한 상태에서 서버를 순차적으로 정지/기동하였을 때 부하가 정상 분배되는지, Fail-over/back 되는지 여부를 검증합니다. Fail-over는 장비 설치 단계에서 미리 단위 업무를 통해 정상 수행 여부를 검증하지만 부하가 지속적으로 발생하는 실시간 부하 환경에서 확인하는 것이 더욱 정확합니다.
[Fail-over 시 서버 자원 추이]
- 주요 검증항목
- Error 발생여부
- Load Balancer의 Load-Balancing 적정성 검증
- A서버 정지 시 B서버 정상 서비스 여부
- 테스트 방식
- Workload Modeling을 통해 Peak시점의 부하량을 산정하여 Ramp-up – Duration – Ramp-down의 순서로 부하를 시뮬레이션하되 Duration의 시간을 길게 주고 Duration 동안 대상 서버를 순차적으로 정지/기동하여 측정합니다.
E. Auto-Scaling Test(Cloud 전용)
Cloud의 주요한 기능인 Auto-scaling 기능 검증 및 설정 최적화를 위한 시나리오로 POD의 구성 목적과 서비스 기동 시간등을 감안하여 Scale-out/in 조건을 설정하여 Auto-scaling 기능을 검증합니다. Stress Test 시나리오도 이 테스트에서 검증이 가능합니다.
[POD의 Scale-out/in 그래프]
- 주요 검증항목
- Error 발생여부
- Auto-scaling 기능
- POD별 시스템 자원(CPU, Memory 등)
- 테스트 방식
- Workload Modeling을 통해 Peak시점의 부하량을 산정하여 Ramp-up – Duration – Ramp-down의 순서로 부하를 시뮬레이션 합니다. 이때 POD의 구동시간과 부하량을 감안하여 각각의 단계를 최소 20분 이상으로 설정하여 수행합니다.
F. Deployment Test(Cloud 전용)
Cloud의 장점인 무중단 배포를 위한 테스트 시나리오로 Deployment 방식에 따라(Blue-green / Rolling) 배포로 인한 오류여부를 검증합니다.
[Deployment(Rolling-Update) 그래프]
- 주요 검증항목
- Error 발생여부
- 무중단 배포 기능
- POD별 시스템 자원(CPU, Memory 등)
- 테스트 방식
- 부하를 지속하여 지속구간 동안 배포를 수행, 오류 발생여부를 확인합니다.
G. Spike Test
대량의 부하가 순간적으로 발생하는 경우를 상정한 테스트 시나리오로 학사 수강신청/휴양림 예약과 같이 일정 시간을 기준으로 사용량이 급증하는 시스템을 테스트하는 시나리오입니다.
- 주요 검증항목
- 예약 가능한 수량 초과 여부
- Error 발생여부
- 시스템 자원(CPU, Memory 등)
- 테스트 방식
- 자동화 도구의 rendezvous 기능을 통해 동 시간대에 시스템에 접속할 수 있도록 설정합니다.
2. 테스트 케이스
테스트 시나리오별 상세 케이스를 작성합니다. 케이스는 다음의 항목들을 감안하여 선정하되 필요한 경우 시나리오별 N개의 케이스가 작성될 수 있습니다.
- 고객 요구사항 파악
- 시나리오 수행 목적 및 목표 기술
- 부하 생성, 지속, 감소 방법
- 측정 항목 파악
- 케이스 별 테스트 구간 식별
- 점검 항목에 대한 예상결과 도출
3. 제약조건 확인
테스트 환경 및 구성 특성을 감안하여 제약조건을 기술합니다.
테스트는 실제 운영 환경의 부하 상황을 가정하여 목표를 세우고 가상의 사용자를 통해 테스트를 수행하나 실 운영과는 부하량이 다를 수 있습니다. 아래의 항목들을 참고하여 제약조건을 확인합니다.
- 테스트 환경
- 자동화 툴에 의해 테스트가 진행되므로 시스템을 사용하는 사용자가 분산된 환경 하에서의 테스트를 재현할 수 없으므로 대상 서버의 성능만을 평가하게 되며, 네트워크의 특성에 의해 발생할 수 있는 응답시간의 지연 사항이 발생하지 않도록 조치하고 테스트를 수행합니다.
- 테스트 분석 및 자동화 툴
- TO-BE 업무의 부하량 산정 기초 데이터가 충분하지 않아 가정된 조건에서 산정된 경우가 있으므로, 실제 운영 환경에서 발생하는 부하량과 테스트에서 산정한 부하량에 차이가 발생할 수 있습니다.
- 테스트 대상 업무는 선정 기준에 따라 고객 및 프로젝트의 합의에 의해 선정되었고, 부하 테스트의 경우, 전체 업무 중 선정된 업무만을 대상으로 프로젝트에서 산정한 상대적 비율에 의거하여 테스트 부하를 분배합니다.
- 성능 테스트 도구에 의하여 측정되는 응답 시간은 Transaction 발생 후 Response로 오는 데이터가 Client의 해당 어플리케이션까지 도착하는데 걸린 시간으로 화면에 보여지는 시간(Presentation Time)은 제외된 응답 시간입니다.
- 향후 Open 이후 시스템의 결함을 효과적으로 측정하기 위하여 적정 수준의 Data가 서버에 Load 되어 있어야 합니다.
4. 수행절차 정의
수행절차는 TimeSchedule과 같습니다. 각 시나리오/케이스의 순서와 수행 시간을 정하고 시나리오별 필요 엔지니어와 세부 역할을 정의하여 엔지니어의 불필요한 대기시간을 줄이고 관계 기관의 협조 시간을 미리 정의합니다.
자동화 툴 Script 작성
실제 테스트를 위한 준비작업을 수행합니다.
분석단계에서 선정된 대상업무를 기준으로 작성하되 세션이 끊기지 않도록 세션처리를 하여 업무별로 작성합니다. 이때 스크립팅 이후부터는 소스 Freezing을 하도록 개발팀에 전달할 필요가 있습니다. 그렇지 않다면 테스트 수행시점에 재 스크립팅을 하게되는 불상사가 생길 수 있습니다.
[SilkPerformer Script 화면]]
테스트 데이터 준비
성능테스트 수행 시 DB에 충분한 데이터가 존재해야 합니다. 오픈 초기 데이터가 거의 없는 상태에서 부하를 발생할때와 충분한 데이터 있는 상태에서의 결과는 큰 차이가 있습니다. 아래의 조건을 확인하여 임시 데이터라도 충분히 준비하도록 합니다. 다만, 데이터 적재가 어려울 경우 제약조건에 해당 내용을 기술하는것이 좋습니다.
- 오픈 후 일정 시점의 데이터 증가분 분석 후 목표 시점 설정
예) 오픈 후 6개월~1년 후 예상치 - 무결성 데이터 적체
- 선행 업무에 따른 데이터 이용 시 사전 생성 가능 여부 확인
- 조회: DB Buffer Cache에 따른 부하 상쇄효과 방지를 위해 조건별 데이터 적재
- 입력: 소진성 데이터의 경우 테스트 수행 횟수 이상의 대량 데이터 준비
- 수정: DB DeadLock이 발생하지 않도록 테스트 유저만큼 데이터 준비
테스트 환경 구축
테스트 수행을 위한 환경 구축을 준비합니다. 부하를 발생시키는 부하발생기와 서버 모니터링을 위한 도구 설치가 이에 속합니다.
1. 부하발생기
자동화 도구는 다수의 부하발생기를 준비하여 이를 통해 부하를 부여하게 되는데 테스트 목표 부하량에 따라 부하발생기 개수를 결정하고 준비합니다. 일반적으로 부하발생기 1대당 100~200User가 적정 합니다.
부하발생기는 테스트 대상 서버와 가장 가까운 위치에 노트북/데스크탑/VM등에 설치하여 Network 병목을 배제하여야 하며 Controller-Agent-대상서버간 방화벽 해제가 필요합니다.
Cloud 환경에서는 동일 Region 위치에 설치하는것이 좋습니다.
물론, 테스트 시나리오 상 원격지의 별도 Region을 통해 부하를 부여하는것도 가능하나 이는 Network Bandwidth, 방화벽, WAF, DDOS, Hub 등 확인할 부분이 많아지게 됩니다.(사실, 이런 장비들의 구간 모니터링이 어렵다 보니 Traffic 제한이 발생할 경우 해당 위치를 찾을 수 없어 테스트를 실패하는 경우도 많습니다.)
[부하발생기의 역할]]
2. 모니터링 도구 설치
부하발생 구간에 대한 모니터링 도구를 설치합니다.
이러한 도구들을 통해 실제 병목이 발생하는 구간과 대상을 식별할 수 있습니다.
WAS(POD)는 
, 
, 
등 Middleware 모니터링 도구를, DB는 Deacon 등의 도구를 통해 모니터링할 수 있습니다.
끝마침
이로써 Introduce to Performance test의 네 번째 포스팅을 마쳤습니다. 설계 단계는 시나리오를 통해 테스트 수행 방법을 결정짓고 자동화 스크립트 및 환경을 구성하여 실제 테스트 수행을 위한 준비 단계에 속합니다.
감사합니다.