성능 테스트 vs 부하 테스트 vs 스트레스 테스트
1) 성능 테스트
특정 상황에서 시스템의 구성 요소가 어떻게 수행되는지 확인하기 위한 테스트이다.
광범위한 의미를 가지고 있는데 성능테스트(Performance Test)는 부하테스트 중 하나의 관점, 즉 성능적 관점만 측정하겠다는 뜻이 담겨 있다.
해당 시스템 혹은 어플리케이션의 성능을 측정한다함은 점진적인 부하량 증가 과정에서 더 이상 단위시간당 최대 처리량(TPS)이 증가하지 않을 때,
그 때의 수치를 측정하고 그 수치를 해석하는 과정을 의미한다.
성능테스트의 일반적인 목적은 현재의 시스템 혹은 어플리케이션이 최대로 수용가능한 동시단말사용자수가 몇 명인지,
혹은 목표로 정한 성능이 도출되지 않을 때 병목지점이 어딘지를 밝히고 목표성능을 획득하기 위해 무엇을 시정해야하는지를 찾아내기 위함이다.
성능테스트 과정에서 매우 중요한 부분은 목표성능을 설정하고 그러한 목표성능을 확인/측정하기 위해
향후 시스템 운영 중에 실제로 발생할 접속사용자의 호출패턴이 어떠하냐를 분석/추정하는 과정이 반드시 필요하고,
이를 근간으로 점진적 부하를 발생시켜야 의미있는 성능테스트 결과를 도출할 수 있다.
그렇지 않을 경우 성능테스트가 자칫 스트레스테스트로 끝나고 만다.
2) 부하 테스트
적절한 부하를 발생시켜 통계적으로 의미있는 수치를 측정하는 테스트이다.
발생시키는 부하는 실제 시스템에 적용될 예상 트래픽이어야 한다.
부하테스트의 두 가지 중요한 목적 중 하나는 장시간 서비스 가능 여부를 확인하는 신뢰성(reliability) 테스트와
두 번째는 성능 테스트(Performance Test)이다.
버퍼 오버플로우, 메모리 leak, 메모리 오류등의 문제를 밝혀내기 위한 것이다.
시스템을 구성하는 DB, HW 등 모든 요소가 갖는 한계를 찾아서 장래의 부하를 대응하기 위함이다.
특정된 비즈니스 시나리오 상에서 예상되는 동시 접속자 수가 최대인 것을 골라서 테스트한다.
예) 수강 신청하는 인원이 어느정도 예상되는지 알고 싶은 경우
3) 스트레스 테스트
시스템이 과부하 상태에서 어떻게 작동하는지를 검사한다.
시스템의 실패를 확인하고 모니터링하는 과정이 정상적으로 이루어지는지 확인한다.
부가적으로 장애 조치와 복구 절차가 효과적이고 효율적인지 판단하는 것도 중요하다.
스트레스 테스트 시의 부하(일련의 들어오는 요청)는 이처럼 시스템 리소스의 한계점을 시험하려는 의도이기 때문에,
다분히 의도적으로 왜곡되는 경향이 있으며, 향후 실제 접속자에 의해 발생하는 부하량 패턴과는 거리가 멀 수도 있다.
어느 부분을 테스트 해야 할까?
Application
- TPS(Transaction Per Second)
- 응답 시간(Response Time)
Middleware
- Message Queue
- RabbitMQ
- Database
- MySQL(slow query, Index)
- Web Server
- Apache(Network outbound io (bandwidth))
- Tomcat(Idle Thread)
Infra
- CPU
- Memory(Swapping)
- Disk IO(파일 시스템)
- Network IO(고용량의 파일이나 이미지 전송에서 병목)
테스트 결과에서 어떤 데이터를 확인해야 할까?
TPS (Transaction per second)
- DB: 초당 트랜잭션 (커밋이나 롤백이 일어나는 횟수)
- web server: 테스트를 위해 정의한 행위의 횟수
Latency At Intervals
요청으로부터 응답을 받아내기 까지 걸리는 시간
Concurrent users
해당 웹 서비스에 동시에 접속할 수 있는 유저의 수를 의미한다.
RPS (Request per second)
1초에 처리할 수 있는 요청의 최대 개수를 의미한다.
QPS(Queries per second)라고도 부른다.
서버의 환경, HTTP의 요청 타입, 컨텐츠의 캐싱 여부 등에 따라서 달라진다.
artillery에서 확인할 부분
Latency
Latency는 지연시간이라는 의미이다. 그래프의 세로는 지연시간(Latency), 가로는 시간을 의미한다.
0으로 갈수록 HTTP 트랜잭션 (요청 → 응답까지의 과정을 HTTP 트랜잭션이라고 한다.)
1회당 요청 → 응답까지 짧은 시간 안에 왔다는 것이다.
그러나 이 시간은 네트워크 시간 + 애플리케이션에서 처리하는 시간이 포함되어 있기 때문에 0에 가깝게 낮추는 것은 어렵다.
그래프 보는 법
-
max: 가장 오래 걸린 요청 → 응답 시간
-
p95: 전체 HTTP 트랜잭션 중 가장 빠른 것부터 95%까지 (대부분의 트래픽)
-
p50: 전체 HTTP 트랜잭션 중 가장 빠른 것부터 50%까지 (절반의 트래픽)
-
min: 가장 빠르게 온 요청 → 응답 시간
-
이 외에 p99도 많이 사용하는데 거의 모든 트래픽을 의미하기 때문에
TPS 측정
TPS는 arrivalRate로 측정할 수 있다.
대부분의 경우 스트레스 테스트는 목표로 하는 TPS가 고정되어 있고 그 TPS를 맞춰야 하기 때문에
TPS를 고정 시킨 상태에서 코드나 인프라를 수정하면서 목표로 하는 TPS가 안정적인지 보면 된다.
성능 향상을 위해 유의미하게 봐야 하는 내용은 가급적 스트레스 테스트를 길게 해봐야 한다는 것이고
실제 유저들의 패턴과 비슷하게 시나리오를 작성해 테스트해야 한다는 것이다.