프로젝트를 진행하면서 성능 테스트 툴을 알아보고 있습니다,
기능은 만들 수 있지만, 올바르게 동작하는지, 성능은 문제 없는지, 애플리케이션의 성능에 대한 고민과 테스트를 해본적이 없어 관련 학습이 필요하였습니다.
- 기능의 목적 중 사용자에게 좋은 경험을 주기 위해선 신속하고 안정성이 있어야 합니다.
성능, 부하, 스트레스 테스트의 개념이 언뜻 비슷해 보이지만 세가지의 개념이 다른것을 알게 되었습니다.
개념을 제대로 알지 못하면, 목적에 맞게 진행하는지 알 수 없고 정확한 테스트가 어렵기 때문에 이 개념들을 정리해보려 합니다.
어느(Where) 부분을 테스트 해야 할까요?
Application
- TPS(Transaction Per Second)
- 응답 시간(Response Time)
Middleware
- Message Queue
- RabbitMQ
- Kafka
- Database
- MySQL, PostgreslSql(slow query, Index)
- Redis
- Web Server
- Apache(Network outbound io (bandwidth))
- Tomcat(Idle Thread)
- Netty
Infra
- CPU
- Memory(Swapping)
- Disk IO(파일 시스템)
- Network IO(고용량의 파일이나 이미지 전송에서 병목)
성능 테스트 (Performance Test)
성능 테스트는, 시스템이 특정 상황에서 어떤 성능을 보이는지 확인하기 위해 수행되는 테스트이다.
성능 테스트를 통해 시스템 자원의 사용량, 확장성, 신뢰성과 안정성도 검증할 수 있다.
성능 테스트는 시스템의 결함을 찾는 것이 아니기 때문에 성공과 실패의 개념으로 결과를 분석하지 않는다.
예를 들면, 특정 시나리오 상황에서의 API의 평균 처리 속도를 파악하는 테스트가 성능 테스트로 볼 수 있다.
성능 테스트는 가장 큰 범위이며 그림을 보면 다른 테스트들이 포함되어있는것을 알 수 있다.
성능 테스트의 목표
- 애플리케이션의 결함을 찾는 목적이 아닌 벤치마크의 설정을 목표로 한다.
- 성공과 실패의 개념으로 분석하지 않으며 현재 시스템의 정확하고 객관적인 데이터를 확보하여 성능에 대한 현재 상황을 이해하는것을 목표로 한다
벤치마크란?
벤치마크는 컴퓨팅에서 특정 오브젝트에 대해 일반적으로 수많은 표준 테스트와 시도를 수행함으로써 오브젝트의 상대적인 성능 측정을 목적으로 컴퓨터 프로그램을 실행하는 행위이다.
성공적인 성능 테스트는 데이터베이스, 네트워크, 소프트웨어, 하드웨어 등과 관련된 대부분의 성능 문제를 예상하여야 한다.
- 특정 시나리오 상황에서의 API 평균 처리 속도를 파악하는 테스트
- 특정 부하에서 응답성 및 안정성 측면에서 시스템이 어떻게 동작하는지 측정하기 위한 비기능 테스트이다.
- 확장성, 신뢰성 및 리소스 사용과 같은 시스템의 다른 품질 속성을 조사, 측정, 검증할 수 있다.
부하 테스트 (Load Test)
임계 값 한계에 도달하는 순간까지 시스템의 부하를 지속적으로 증가하면서 진행하는 테스트이다.
volume test
또는 endurance test
라고도 한다.
보통 LoadRunner 등의 테스트 도구를 활용해서 다양한 부하 시나리오를 설정하고, 강도를 지속적으로 증가하면서 결과를 확인한다.
발생시키는 부하는 실제 시스템에 적용될 예상 트래픽이어야 한다.
부하 테스트의 목표
- 부하 테스트의 목적은 부하를 증가시키면서 생기는 다양한 시스템의 한계를 찾아내는 것이 목표
- Web Server, Database, Infra등 모든 요소의 한계를 찾아서 미래에 발생할 부하에 대비하는 것이 목표
- 버퍼 오버플로우, 메모리 누수, JVM의 Garbase Collection 동작 확인, DB 병목점 확인 등
- 각 상황에서의 최대 상한 값을 확인해서 각각의 시나리오에 대한 계획을 세우는 것이 최종 목표이다.
- 서비스 오픈 이벤트를 대비한 최대 부하 확인, 무료 경품 이벤트로 인한 시스템 부하 대비 등을 위해 진행하는 테스트로 적절하다.
- 수강신청 인원 예상 테스트
스트레스 테스트 (Stress) 테스트
시스템이 과부하 상태에서 어떤 동작을 보이는지 확인하는 테스트이다.
과부하 상태에서 모니터링 도구는 정상적으로 동작하는지, 시스템의 Failover는 적용되는지, SPoF 혹은 보안 상의 문제가 존재하는지 등을 확인한다.
스트레스 테스트의 목표
- 시스템의 충돌 후 로그, 보고서 등을 분석하여 애플리케이션의 동작을 정의하는 것
- 과부하 상태에서 모니터링 도구는 정상적으로 동작하는지
- 시스템의 Failover는 적용되는지, 장애 조치와 복구 절차가 효과적이고 효율적인지
- SPoF 혹은민감한 정보나 보안상의 문제가 노출되지 않는지
- 시스템의 실패를 확인하고 모니터링하는 과정이 정상적으로 이루어지는지
스트레스 테스트(Stress Test)
시스템이 과부하 상태에서 어떤 동작을 보이는지 확인하는 테스트이다. 과부하 상태에서 모니터링 도구는 정상적으로 동작하는지, 시스템의 Failover는 적용되는지, SPoF 혹은 보안 상의 문제가 존재하는지 등을 확인한다. 예를 들면, 시스템 과부하 상태에서 모니터링의 알림이 잘 오거나 시스템의 Auto Scaling 계획이 잘 동작하는지 등을 확인하는 테스트로 적절하다.
성능, 부하, 스트레스 테스트 비교
성능 테스트 | 부하 테스트 | 스트레스 테스트 | |
---|---|---|---|
도메인 | 부하 및 스트레스 테스트의 상위 집합 | 성능 테스트의 하위 집합 | 성능 테스트의 하위 집합 |
범위 | 매우 넓은 범위 하위 집합 - {부하 테스트, 스트레스 테스트, 용량 테스트, 볼륨 테스트, 내구성 테스트, 스파이크 테스트, 확장 성 테스트 및 안정성 테스트 등} |
성능 테스트에 비해 범위가 좁다. 볼륨 테스트 및 내구성 테스트를 포함한다. |
성능 테스트에 비해 범위가 좁다. soak 테스트 및 스파이크 테스트를 포함한다. |
주요 목표 | 애플리케이션 성능을 벤치 마크 및 표준에 맞춘다. | 시스템의 상한선을 식별하려면 앱의 SLA를 설정하고 시스템이 과부하 볼륨을 처리하는 방법을 확인한다. | 과부하에서 시스템이 작동하는 방식과 장애로부터 복구하는 방식을 테스트하면서 알아낸다. 앱이 기본적으로 예기치 않은 트래픽 급증에 다운되지 않도록 대비한다. |
부하 제한 | 임계치 이전과 초과된 경우 모두 검사 | 임계치 이전까지 검사 | 임계치를 초과한 경우 검사 |
학습된 속성 | 리소스 사용량, 안정성, 확장성, 리소스 사용량, 응답 시간, 처리량, 속도 등 | 과부하 수준에서 최대 성능, 서버 처리량, 응답 시간 (임계치 값 미만), H/W 환경의 적절성, 처리 할 수 있는 사용자 앱 수, 부하 분산 요구 사항 등 | 대역폭 용량, 응답 시간 이상의 안정성 (임계치 값 초과) |
얻은 결과 | 런타임 팽창, 최적화 범위, 속도, 지연 시간, 처리량 등과 관련된 문제를 포함한 모든 성능 버그. 기본적으로 – 성능과 관련된 모든 것 |
부하 분산 문제, 대역폭 문제, 시스템 용량 문제, 응답 시간 부족, 처리량 문제 등 | 과부하, 과부하 상황에서의 데이터 손상 문제, 속도 저하, 메모리 누수 등의 보안 허점 |
참조
'테스트' 카테고리의 다른 글
Springboot PSQLException: Unterminated dollar quote started at position $$ 해결방법 (0) | 2023.09.09 |
---|---|
JMH (Java Microbenchmark Harness) (0) | 2023.05.11 |
Apache JMeter를 사용해보자 (4) | 2023.04.24 |
SpringBoot 테스트시 초기 SQL 데이터 삽입 - Test SQL (0) | 2023.01.28 |
MockMvc 테스트시 andExpect(jsonpath())를 이용한 검증방법 (2) | 2023.01.25 |