성능테스트는 시스템 구성 요소가 특정 상황에서 어떤 성능을 보이는지 확인하기 위해 수행되는 테스트이다. 제품의 반응 시간, 안정성, 확장성, 리소스 사용량 등을 통해 시스템의 한계와 필요한 리소스를 검증할 수 있다.
성능 테스트는 다음 그림처럼 부하 및 스트레스 테스트 등 모든 것을 포괄하는 상위 개념으로 매우 광범위하다. 성공적인 성능 테스트는 DB, SW, HW, 네트워크 등과 관련될 수 있는 대부분의 성능 문제를 예측해야 한다.
하루 평균 사용자가 10,000명일 때, 100명 동시 접속 테스트하기!
API 응답속도와 에러율을 분석하자
서버가 정상적인 트래픽에서 얼마나 잘 작동하는지 확인하는 테스트이다. 얼만큼의 트래픽을 처리할 수 있는지, 최대 부하에서도 잘 동작하는지, 응답 시간이 얼마나 걸리는지 등을 확인한다.
응답 시간(Response Time), 초당 처리량(TPS), CPU와 메모리 사용률이 주요 지표로 사용될 수 있다.
1초당 1000명씩 접속하는 트래픽을 걸어보자
서버가 몇 명까지 견디다가 죽을까?
CPU 사용률이 100%를 찍는 순간이 언제지?
서버가 최대 트래픽을 받을 때, 어디까지 버틸 수 있는지, 과부하가 걸렸을 때 어떻게 대처하는지 확인한다.
예를 들어, 2분 정도에 100개 요청 -> 300개 요청 -> 500개 요청 하는 식으로 천천히 요청 수를 늘리면서 CPU와 메모리 상태를 관찰한다. 또한 요청 수를 0으로 다시 내렸을 때의 리소스 변화도 주목해보자.
평수에는 10명 접속하는 서버에 갑자기 1,000명이 접속, 10초 후 다시 10명 접속한다면
서버가 급작스러운 트래픽 변화를 감당할 수 있을까?
짧은 시간 동안 트래픽이 폭증할 때, 서버가 버틸 수 있는지 확인하는 테스트이다.
쇼핑몰, 티켓 예매, 이벤트 사이트에서 특히나 중요하다.
CPU와 메모리 급증 여부, 트래픽 급증 후 정상 상태로 돌아오는 속도에 주목하자.
12시간 동안 100명 동시 접속 유지하기
24시간 동안 평균 트래픽 부하를 걸었을 때 성능 저하가 일어날까?
서버가 오랜 시간(시간 단위부터 일 수까지)동안 안정적으로 운영되는지 확인하는 테스트이다. 장기간 동작하면서 발생할 수 있는 메모리 누수, 스레드 누수, 성능 저하 등의 문제를 발견할 수 있다.
메모리 사용량 증가 여부, CPU 과부하 발생 여부, 장시간 실행 후 응답 속도 저하 여부에 대해 분석한다.
AWS EC2 Auto Scaling 설정 후, 동시 접숙자 수가 증가했다.
새로운 서버가 자동으로 추가되는지를 확인한다.
서버의 자동확장이 잘 동작하는지 확인하는 테스트이다. 시스템이 처리할 수 있는 최대 부하를 파악하고 용량 증설 및 하드웨어 확장성을 예측한다.
Auto Scaling 반응 속도와 서버 추가 후 응답 속도 개선 여부에 대해 파악한다.
부하 테스트란 성능 테스트의 하위 지합으로 임계치 한계에 도달할 때까지 시스템의 부하를 지속적으로 증가시켜 시스템을 테스트 하는 것이다.
부하 테스트에서 모니터링되는 속성에는 최대 성능, 서버 처리량, 다양한 부하 수준(중단 임계 값 미만)에서의 응답 시간, H/W 환경의 적절성, 성능에 영향을 주지 않고 처리할 수 있는 사용자 애플리케이션 수 등이 있다.
throughput과 latency는 시스템 성능 지표의 주요 메트릭이며 이 두가지 지표를 활용해 평가한다.
서버 또는 시스템이 일정 시간 동안 처리할 수 있는 요청(트랜잭션) 수를 의미한다. 쉽게 말해, 우리 서버가 초당 몇개의 요청을 처리할 수 있는지를 말한다.
1. TPS(Transactions Per Second)
초당 몇 개의 트랜잭션을 처리할 수 있는지
최대 TPS가 500이라면, 초당 500개의 트랜잭션 처리가 가능
2. RPS(Requests Per Second)
초당 몇 개의 HTTP 요청을 처리할 수 있는지
API 서버의 RPS가 1000이라면, 초당 1000개의 요청 처리가 가능
클라이언트가 요청을 보낸 후, 서버가 응답을 받기까지 걸리는 시간을 의미한다. Latency가 중요한 이유는
1. 평균 응답 시간
전체 요청의 평균 응답 시간
2. P95, P99(Percentile Latency, 백분위 지연 시간)
요청 중 95%는 300ms이하, 나머지 5%는 500ms 걸린다면 P95=300ms
3. TTFB(Time to First Byte)
서버가 첫 번째 바이트를 응답하기까지 걸리는 시간
4. RTT(Round Trip Time)
패킷이 오고 가는 데 걸리는 시간
테스트 대상 시스템은 부하가 집중되고 있는 상태
여러 하위 시스템으로 구성된 테스트일 때 각각의 하위 시스템에 개별적으로 부하를 주고 조사헤야 한다. 부하 테스트 중 특정 하드웨어 리소스가 과부하 상태가 되는 것이 좋은 부하 테스트이다.
병목 지점을 확인한 상태
시스템에 많은 요청을 보내는 테스트인 경우 일반 적으로 시스템의 어느 한 부분이 과부하 상태가 되어 이 부분으로부터 전헤의 Throughput을 결정하게 된다. 그러므로 항상 병목 구간이 어디인지를 의식하고 확인해야 한다. 병목 구간을 찾기 쉽게 테스트 방법을 준비하면 보다 효율적으로 테스트 할 수 있다.
부하 테스트 도구
모니터링 도구
프로파일링 도구
조건 1. 요청을 정확하게 시뮬레이션 한다.
Apache Bench를 사용하면 시나리오 기반 테스트가 불가능하다. 따라서 시나리오가 필요한 부하 테스트는 이러한 도구를 사용할 수 없다.
조건 2. 부하 정도를 조정 가능해야 한다.
클라이언트 동시 접속자 수, 요청 간격, 최대 Throughput 등을 조정하여 공격 강도를 조절해야 한다. 이러한 설정은 대부분의 테스트 도구에서 가능하다.
조건 3. 대상 시스템에 충분한 부하를 발생시켜야 한다.
대상 시스템의 성능 지표에 따라 사용할 수 있는 테스트 도구가 달라진다.
조건 4. 부하 테스트 도구, 설치, 장소 및 가동 장소를 선택할 수 있어야 한다.
부하 테스트 도구에 따라 기동할 수 있는 서버에 제약이 있을 수 있기 때문에 부하 테스트 서버를 설치하는 장소 제약이 있을 수 있다.
SaaS 서비스로 원격에 설치된 서버에서 부하를 주는 도구도 있지만 원격에서 부하를 주는 혀애는 대상 시스템에만 부하를 주기에는 어려워서 효율적인 부하 테스트를 하기엔 맞지 않다.
$ brew search jmeter // Home brew를 사용
$ jmeter
$ brew install k6 // Home brew를 사용
import http from 'k6/http';
import { sleep } from 'k6';
export let options = {
vus: 10, // 가상 사용자 수
duration: '30s', // 테스트 지속 시간
};
export default function () {
http.get('https://test.k6.io');
sleep(1); // 요청 간 1초 대기
}
$ k6 run test.js