성능테스트

Krosa·2024년 11월 3일

Jmeter K6 load test locust nGrinder test

성능테스트

서비스 API 를 생성한 개발자 중에, 부하테스트를 하고자하는 분들을 위해, 해당 글을 작성하였습니다. 해당 페이지를 읽고 나시면, 성능테스트의 개념, 성능테스트 도구의 종류에 대해 이해하실 수 있습니다.

성능테스트의 개념

다중사용자 지원 능력을 평가하는데 흔히 세 가지 유형의 성능 테스트(성능, 부하, 스트레스)가 수행됩니다. 성공적인 성능 테스트는 데이터베이스, 네트워크, 소프트웨어, 하드웨어 등과 관련 될 수있는 대부분의 성능 문제를 예측해야 합니다.

성능테스트의 종류들

자료마다 다른 정의. 약간 다른 뉘앙스. 다른 접근.

best common to Graph

	성능 테스트	부하 테스트	스트레스 테스트
도메인	부하 및 스트레스 테스트의 상위 집합	성능 테스트의 하위 집합	성능 테스트의 하위 집합
범위	매우 넓은 범위 하위 집합 - {부하 테스트, 스트레스 테스트, 용량 테스트, 볼륨 테스트, 내구성 테스트, 스파이크 테스트, 확장 성 테스트 및 안정성 테스트 등}	성능 테스트에 비해 범위가 좁다. 볼륨 테스트 및 내구성 테스트를 포함한다.	성능 테스트에 비해 범위가 좁다. soak 테스트 및 스파이크 테스트를 포함한다.
주요 목표	애플리케이션 성능을 벤치 마크 및 표준에 맞춘다.	시스템의 상한선을 식별하려면 앱의 SLA를 설정하고 시스템이 과부하 볼륨을 처리하는 방법을 확인한다.	과부하에서 시스템이 작동하는 방식과 장애로부터 복구하는 방식을 테스트하면서 알아낸다. 앱이 기본적으로 예기치 않은 트래픽 급증에 다운되지 않도록 대비한다.
부하 제한	임계치 이전과 초과된 경우 모두 검사	임계치 이전까지 검사	임계치를 초과한 경우 검사
학습된 속성	리소스 사용량, 안정성, 확장성, 리소스 사용량, 응답 시간, 처리량, 속도 등	과부하 수준에서 최대 성능, 서버 처리량, 응답 시간 (임계치 값 미만), H/W 환경의 적절성, 처리 할 수 있는 사용자 앱 수, 부하 분산 요구 사항 등	대역폭 용량, 응답 시간 이상의 안정성 (임계치 값 초과)
얻은 결과	런타임 팽창, 최적화 범위, 속도, 지연 시간, 처리량 등과 관련된 문제를 포함한 모든 성능 버그. 기본적으로 – 성능과 관련된 모든 것!	부하 분산 문제, 대역폭 문제, 시스템 용량 문제, 응답 시간 부족, 처리량 문제 등	과부하, 과부하 상황에서의 데이터 손상 문제, 속도 저하, 메모리 누수 등의 보안 허점

다양한 정의의 성능테스트

성능 테스트 유형에 대한 정의를 정확히 이해해 보고자, 여러 자료들을 비교해가며 하나씩 짚어서 읽어가다 보면, 예상과 달리 그 정의하고 있는 용어와 매핑되는 내용들이 조금씩 다른 것을 보게 됩니다. 예를 들어, 성능 테스트 유형에 대해서도 아래의 경우와 같이 ‘Baseline Testing’이라는 용어를 시작으로, 그 ‘부하량’과 ‘기간’ 등의 정도에 따라 성능 테스트 유형을 정의하는 경우도 있습니다.

성능 테스트 유형’에 대한 기본적인 이해를 가질 수 있도록, 일반적으로 성능 테스트에는 어떠한 종류들이 있는지, 그리고 각각은 대략적으로 어떤 차이점을 가지고 성능 업무에 적용되고 있는지에 대해 몇가지 자료들을 중심으로 살펴봄으로써, 성능테스트가 수행되는 다양한 형태들에 대한 기본적인 이해를 돕고자 합니다.

첫번째로 살펴볼 자료는, 성능 테스트 유형에 대해 사용자의 부하발생 패턴별로 시각화하여 차이점을 비교하고 있는 DCube’s Practices 자료입니다.

DCube’s Practice

Web Performance Testing — DCube’s Practices https://medium.com/singapore-gds/web-performance-testing-dcubes-practices-fbbc20606000

그래프의 Y축은 가상사용자(Virtual Users), X축은 지속 시간(Test Time)을 각각 나타내고 있으며,
사용자의 증가, 유지, 감소 등 부하패턴 변화에 따라 각각의 테스트 유형을 구분지어 비교하고 있습니다.
참고로, 성능 테스트 Tool에서는 이러한 그래프와 유사하게 Workload를 설계하여 사용하고 있습니다. 예를 들어, 500명의 가상사용자(Virtual Users)를 이용한다면, 5분간 500명 증가(Ramp Up), 10분간 부하지속(Steady State), 1분간 부하 감소(Ramp Down) 등과 같은 형태로 설계하여 실제 부하를 발생시키고 있습니다.

Load Test (most common out of the five)= 부하테스트

It verifies the system performance under the predetermined peak load, and this peak load is typically simulated and sustained for an hour. This test ensures the system can handle peak hour traffic at an acceptable performanc

사전에 결정된 Peak시점의 부하 상황에서 시스템의 성능을 검증하는 것으로, Peak Load는 일반적으로 1시간동안 유지됩니다.
 이 테스트는 적정한 성능으로 Peak Hour Traffic을 감당할 수 있는지 확인합니다.

Stress Test= 스트레스 테스트

A verification on the system performance during extremely high load which is way above the peak load (a common practice is to use twice the peak load). It checks if the system will crash or remain usable and whether it recovers gracefully when the load goes back to normal.

Peak Load보다 훨씬 높은 부하 상황에서 시스템의 성능을 검증합니다.(일반적으로는 Peak Load의 2배를 사용합니다.) 

이러한 상황에서 시스템이 장애가 발생하는지 또는 사용 가능한 상태로 유지되는지, 
그리고 부하가 정상 수준으로 돌아갈 때 우아하게(gracefully) 복구되는지 체크합니다.

Endurance Test=내구성테스트

A prolonged test to verify system stability over periods of 8 hours or more in order to sniff out issues like memory leakage that surface over longer time.

장기간에 걸ㅁ쳐 나타나는 메모리 누수와 같은 이슈들을 감지하기 위해, 8시간 이상의 기간에 걸쳐 시스템의 안정성을 확인하는 장기적인 테스트입니다.

Spike Test=스파이크 테스트

Spike Test simulates the unique scenario of sudden high usage of the system. This is relevant for situations like a popular product launch (e.g. iPhone) or big sales (e.g. Singles’ Day). The script is configured to synchronize multiple threads to perform a step simultaneously.

시스템의 갑작스러운 사용량 급증에 대한 독특한 시나리오에 대해 시뮬레이션합니다. 
이것은 인기있는 제품 출시(e.g. iPhone) 또는 Big Sales(e.g. Singles’ Day)와 같은 상황과 관련이 있습니다.

Breakpoint Test =브레이크 포인트 테스트

This test determines the point of system failure by gradually increasing the number of simulated concurrent users. After the test, a graph can be plotted to observe the point the system becomes unusable, which is the breakpoint of the system.

동시단말 사용자(concurrent users)의 수를 점진적으로 증가시켜서, 시스템의 장애 지점을 결정합니다.
 테스트 이후, 시스템을 사용할 수 없게 되는 지점,
 즉 시스템의 중단점(the breakpoint of the system)을 관찰하기 위해 그래프를 그릴 수 있습니다.

정리해 보면, DCube’s Practices에서 단순하게 구분짓고 있는 다섯가지 성능테스트 유형은 다음과 같이 요약할 수 있습니다.

‘적정 부하’(=Peak 시점의 부하)를 유지하는 것을 Load Testing
‘적정 부하의 2배’를 유지하는 것을 Stress Testing
‘장시간 부하’를 유지하는 것을 Endurance Testing
‘순간적인 대량 부하’를 발생하는 것을 Spike Testing
‘부하를 점차 증가’시켜 임계점을 확인하는 것을 Breakpoint Testing

netsolutions's performance-testing

여기서는, Stress Testing의 정의가 ‘적정 부하의 2배’ 등의 예시로 단순화하여 설명되었지만, 원래의 의미는 좀 더 넓은 개념으로 사용되고 있습니다. 예를 들어, 아래 그림에서 부하 유형의 그래프들 중 사선으로 표시한 부분을 보면, Stress Testing에 대한 설명이 ‘Find the Performance Limits of the System’으로 되어 있어서, 앞서 언급된 Breakpoint Testing과 비슷한 의미로 사용되기도 합니다. 좀더 자세한 설명은 두번째 예시에서 참조하시기 바랍니다.

출처 : https://netsolutions.com/insights/performance-testing/

Soak Testing은 오랜 시간동안 대량 부하(huge volume of load) 상황에서, 애플리케이션의 성능을 측정하는데 사용되는 비기능 테스트의 한 유형입니다. 이 유형의 테스트에서 기본적으로 모니터링 되는 것은 시스템의 애플리케이션에 의한 메모리의 사용율입니다.

Why do Soak Testing?

시스템이 2시간 동안 사용될 때는 정상적으로 동작할 수 있지만, 동일한 시스템을 10시간 이상 사용하면 장애가 발생하거나 비정상적인 상황이 발생할 수 있습니다. 이러한 상황을 예측하기 위해 Soak Testing이 수행됩니다.

When to do Soak Testing?

빌드가 고객에게 배포되기 전에, 즉 특정 플랫폼에서 애플리케이션이 출시되기 전에 일련의 Load Tests가 수행된 이후, Soak Tesitng이 수행됩니다. 메모리 누수/ 메모리 손상 등과 같은 이슈가 발견되면 즉시 보고해야 합니다.

Source: guru99.com

Software Testing Class's performance-testing

Software Testing Class에서는 성능테스트(Performance Testing)의 주요 유형을 6가지로 정의하고 있습니다. 위에서 언급되었던 ‘Breakpoint Testing’이 빠지고, 여기서는 ‘Volume Testing’과 ‘Scalability Testing’이 추가되어 있습니다. 참고자료로 남깁니다.

https://www.softwaretestingclass.com/what-is-performance-testing/

1. Load Testing

Load Testing은 부하가 임계치(Threshold Value)에 도달할 때까지 시스템의 부하를 지속적으로 증가시키면서 시스템을 확인하는, Performance Testing의 한 유형입니다. 여기서 부하를 증가시킨다는 것은, 동시단말사용자(concurrent users)와 트랜잭션을 증가시키면서 테스트 중인 애플리케이션의 동작을 확인하는 것을 의미합니다. ‘Endurance testing’ 또는 ‘Volume testing’이라고 불리기도 합니다.

Load Testing의 주요 목적은 과부하 상태(under heavy load)에서 시스템이 잘 작동될 때, 응답시간과 애플리케이션의 지구력(staying power)을 모니터링하는 것입니다. Load Testing과 아래에 기술된 테스트들은 모두 비기능 테스트(NFT/ Non Functional Testing)에 속하며, 소프트웨어 애플리케이션의 비기능 요구사항을 테스트하기 위해 설계되었습니다.

Load Testing은 테스트중인 애플리케이션이 견딜 수 있는 부하의 양을 확인하기 위해 수행됩니다. ‘성공적으로 수행된 Load Testing’은 지정된 테스트 케이스가 할당된 시간동안 오류없이 수행된 경우에만 가능합니다.

2. Stress Testing

Stress Testing은 CPU, Memory, Disk Space 등과 같은 하드웨어 자원이 충분하지 않을 때, 소프트웨어의 안정성을 확인하는 Performance Testing의 한 유형입니다. Stress Testing의 기본 개념은 시스템의 오류를 확인하고, 어떻게 시스템이 정상적으로 복구되는지를 살펴보는 것입니다.

“To determine or validate an application’s behavior when it is pushed beyond normal or peak load conditions.”

Stress Testing은 시스템 하드웨어 자원에서 처리할 수 없는 많은 수의 동시단말사용자(concurrent users)/프로세스로 소프트웨어에 부하를 주는 Negative Testing입니다. 이 Testing은 피로시험(Fatigue testing)으로도 알려져 있습니다.

Stress Testing의 기본 개념은 시스템의 장애를 확인하고 시스템이 어떻게 정상적으로 복구되는지를 주시하는 것입니다. 이러한 품질 특성을 회복성(recoverability)이라고 합니다.

3. Spike testing

Spike testing은 Stress Testing의 Subset입니다. 테스트 대상 시스템에 대해, 상용 운영환경에서 예상되는 부하 이상의 Workload를 짧은 기간동안 반복적으로 증가시킬 때 나타나는 성능 특성을 검증하기 위해 수행합니다.

4. Endurance testing

Endurance testing은 시스템의 동작을 확인하기 위해, 장기간에 걸쳐 예상되는 부하량에 기반하여 시스템을 테스트 하는 것을 포함합니다. 예를 들어, 시스템이 3시간동안 작업을 수행하도록 설계되었다면, 동일 시스템이 6시간동안 지속되어도 시스템이 지구력을 유지하는지를 확인하는 것입니다. 가장 일반적인 테스트 케이스는 메모리 누수, 시스템 장애 또는 무작위적인 동작(random behavior)과 같은 시스템의 동작을 확인하기 위해 수행됩니다. 때때로, Endurance testing은 ‘Soak testing’이라고도 합니다.

5. Scalability Testing

Scalability Testing은 사용자 부하, 트랜잭션 수, 데이터 볼륨 등과 같은 비기능 측면에서 확장할 수 있는 역량을 판단하기 위한 소프트웨어 애플리케이션 테스트입니다. 이 테스트의 주요 목적은 더이상 확장(Scaling)하지 못하도록 막는 ‘시스템의 Peak’가 무엇인지 확인하는 것입니다.

6. Volume testing

Volume testing은 처리해야 할 많은 양의 데이터를 가진 애플리케이션의 효율성을 확인하기 위한 테스트입니다. 이 테스트의 주요 목표는 다양한 Database Volumes 하에서 애플리케이션의 성능을 모니터링 하는 것입니다.

성능테스트 기본 동작방식

ngrinder 를 통해, 기본적으로 성능테스트가 어떻게 동작하는지 확인해봅시다.

https://github.com/naver/ngrinder/wiki/Architecture#general-architecture

웹 애플리케이션을 서비스하기 전에 서버가 얼마나 많은 사용자를 수용할 수 있는지 요청을 전송해봄으로써 서버의 성능을 측정해볼 수 있다.

nGrinder는 Controller와 Agent로 이루어져 있다.

✔️ Controller
  ├── 성능 측정을 위한 웹 인터페이스 제공
  ├── 테스트 프로세스 조정
  ├── 테스트 통계를 수집하고 표시
  └── 스크립트 수정 기능 제공

✔️ Agent
  ├── 에이전트 모드에서 실행할 때 대상 시스템에 부하를 주는 프로세스 및 스레드를 실행
  └── 모니터 모드에서 실행 시 대상 시스템 성능(CPU/메모리) 모니터링

✔️ Agent
  ├── 성능 측정에 사용할 Agent 개수
  └── Agent를 여러개로 구성하고 싶은 경우 클라우드 서비스 이용하기
      └── 여러개의 인스턴스를 생성해서 Agent 설치하기

✔️ Vuser per agent
  ├── Agent 당 설정할 가상 사용자 수
  └── 동시에 요청을 날리는 사용자 수를 의미
  
✔️ Process / Thread
  └── 하나의 Agent에서 생성할 프로세스와 스레드 개수
  
✔️ Script
  ├── 성능 측정 시 각 Agent에서 실행할 스크립트
  └── 앞서 API 호출 과정에서 생성한 Script를 연결(.groovy)하거나 Github에서 가져올 수 있다.
  
✔️ Duration (HH:MM:SS)
   └── 성능 측정 수행 시간
  
✔️ Run Count
   └── 스레드 당 테스트 코드를 수행하는 횟수

✔️ Enable Ramp-Up
  └── 성능 측정 과정에서 가상 사용자를 점진적으로 늘리도록 활성화

✔️ Initial Count
  └── 처음 시작 시 가상 사용자 수
  
✔️ Initial Sleep Time
  └── 테스트 시작 시간
  
✔️ Incremental Step
  └── Process 또는 Thread를 증가시키는 개수
  
✔️  Interval
  └── Process 또는 Thread를 증가시키는 시간 간격

성능 테스트 도구 소개

k6

k6 소개

Grafana k6는 오픈소스 부하 테스팅 툴이다. 성능 테스트를 쉽게 수행할 수 있고, 엔지니어링 팀의 생산성을 향상 시킨다. k6를 이용하면 신뢰성 있고, 시스템의 성능테스트를 수행할 수 있다. 이를 통해 성능을 측정하고, 문제를 쉽게 해결할 수 있는 초석이됩니다.
- https://k6.io/
- https://github.com/grafana/k6

설치 방식

https://k6.io/docs/get-started/installation

k6의 특징

현존하는 도큐먼트 중에 가장 설명이 잘 되어있습니다.
cicd 를 공식 지원합니다.
Js 를 이용합니다.
평균 output 으로 결과가 나오지만, 그라파나를 활용해 대시보드를 구성가능합니다.

threadsholds 라는 임계값이라는 개념이 있어, 테스트 지표에 대해 정의하는 평균치에 대한 통과, 실패 기준이 있습니다.

해당 부분에 대한 예시입니다. 공식페이지에서 더 많은 옵션을 확인할 수 있습니다.

  thresholds: {
    // 90% of requests must finish within 400ms, 95% within 800, and 99.9% within 2s.
    http_req_duration: ['p(90) < 400', 'p(95) < 800', 'p(99.9) < 2000'],
    // During the whole test execution, the error rate must be lower than 1%.
    http_req_failed: ['rate<0.01'],
  },

Locust

Locust 소개

파이썬 기반 부하테스트 툴입니다.
- https://github.com/locustio/locust
- https://docs.locust.io/en/stable/installation.html

Locust의 특징

constant_throughput : tps 를 유지하게 노력합니다.
python 기반으로 보다 편리합니다.
또한, pip install locust 로 가능한 파이썬 라이브러리로, ncc 및 로컬 이식에 용이합니다.
ui 가 존재합니다. 에러 페이지, response time graph , 리퀘스트 보낸것을 확인 가능한 기본 대시보드를 제공합니다. 가상 유저와, spawn rate를 처음에 작성하라고 하는데, 초심자 입장에서 이해하기 어렵습니다. (다양한 성능테스트용으로는 좀 더 좋을지..)
도큐먼트 설명이 불친절합니다. 처음부터 끝까지 정독해야만, constant_throughput : tps 를 유지하게 노력 함. 이런 옵션들을 획득할 수 있습니다.
실패가 request 단건으로 존재합니다.

Apache JMeter

Apache JMeter 소개

성능 및 로드 테스트 애플리케이션을 측정하도록 설계된 오픈 소스 Java 애플리케이션입니다.

Apache JMeter의 특징

문서수가 제일 많고, 다수의 플러그인을 가지고 있는데, 젠킨스와 비슷한 느낌이지 않나 싶습니다. 자바 공화국에서는 많이 쓰이고 있어보이는데요, 진입장벽이 높습니다. (그와 동시에 많은 블로그, 사용자문서를 가지고 있는 것이 장점. )
개구린 gui 를 가지고 있습니다. (물론 http 테스트는 가능합니다.)
vscode처럼 하나하나 다 공부해가면서 플러그인을 설치해야합니다.
녹화 기능이 있어, 스크립트를 작성하지 않아도 녹화 가능합니다.
junit - jmeter 연동이 가능합니다.
상위 에러 사유, response 사유, 바이트 처리량, 연결 시간, 지연 시간 모두 보여줍니다 . https://jmeter.apache.org/usermanual/generating-dashboard.html

Apache JMeter를 사용한 간단한 부하 테스트 예제

https://jmeter-plugins.org/?search=jpgc-casutg에 접속하여 신버전을 다운받습니다.
압축 해제 후 /apache-jmeter-5.4.3/lib 에 복사합니다.
Jmeter를 재실행하면 Stepping Thread Group이 추가된 것을 확인할 수 있습니다.

설정 값은 다음과 같습니다.

[ this group will start ] 해당 그룹에서 최대 생성되는 Thread 개수
[ Next, add ] 추가되는 Thread의 수 몇 개씩 더해질 것인가
[ threads every ] Thread 추가되는 시간 간격(s)
[ using ramp-up ] Thread가 추가되는데 걸리는 시간(s)
[ Then hold load for ] 최대 쓰레드가 유지되는 시간(s)
[ Finally, stop ] Thread가 몇 개씩 줄어들 것인가
[ threads every ] Thread가 줄어드는데 걸리는 시간(s)

NGrinder

NGrinder 소개

NHN의 1억 명 이상의 사용자를 보유한 대규모 시스템을 테스트하는 데 사용되는 검증된 솔루션입니다.
- https://github.com/naver/ngrinder
- 쉽게 시작하기 위해 참고 블로그 : https://1-7171771.tistory.com/155, https://velog.io/@hellonayeon/nGrinder-install-and-how-to-use-memo

NGrinder의 특징

python, groovy, jar 등을 제공합니다.
캐시효과 제거하기 : 여러 파라미터를 활용
input : agent 개수, vuser, 테스트 시간
허용가능한 tps 를 output 으로 정의해줍니다.

참고 문헌

ngrinder 시스템 아키텍처 blog : https://velog.io/@hellonayeon/nGrinder-install-and-how-to-use-memo
ngrinder 시스템 아키텍처 : https://github.com/naver/ngrinder/wiki/Architecture#general-architecture
부하테스트 개념 : https://loosie.tistory.com/821#%EB%B6%80%ED%95%98_%ED%85%8C%EC%8A%A4%ED%8A%B8_(Load_Test)
Web Performance Testing — DCube’s Practices https://medium.com/singapore-gds/web-performance-testing-dcubes-practices-fbbc20606000
https://engineering-skcc.github.io/performancetest/Performance-Testing-Terminologies/
locust architecture : https://locust.dev/docs/architecture

Krosa

이것저것합니다

이전 포스트

2024년 4분기의 시작, 글또 10기 다짐글

다음 포스트

성능테스트

성능테스트

성능테스트의 개념

성능테스트의 종류들

best common to Graph

다양한 정의의 성능테스트

DCube’s Practice

netsolutions's performance-testing

Software Testing Class's performance-testing

성능테스트 기본 동작방식

성능 테스트 도구 소개

k6

k6 소개

설치 방식

k6의 특징

Locust

Locust 소개

Locust의 특징

Apache JMeter

Apache JMeter 소개

Apache JMeter의 특징

Apache JMeter를 사용한 간단한 부하 테스트 예제

NGrinder

NGrinder 소개

NGrinder의 특징

참고 문헌

2024년 4분기의 시작, 글또 10기 다짐글

2024.09.19 Neural Magic Office Hour 에서 확인하는 vLLM 아키텍처

0개의 댓글