카테고리 없음

서버 성능을 테스트하기 위한 부하테스트

scsi to. 2025. 1. 4. 20:57

 

    프로젝트가 마무리에 다가오고 있어서 서버의 성능을 테스트해보기로 했습니다. 실제 환경과 최대한 비슷하게 테스트를 하기 위해 Naver Cloud를 이용하여 서버와 클라이언트 각각 EC2를 만들어서 클라이언트에서 서버로 요청을 받는 방식으로 테스트 하였습니다. 

 

A. 성능 테스트의 종류 (SK C&C, DCube-Team Merlin)

 

Goverment Digital Product, Singapore

1. 부하테스트(Load Test)

  • 유저의 수와 초당 API 요청등을 증가시키며 시스템의 임계점(Peak Load) 을 찾기 위한 테스트입니다. 
  • 부하 상황에서 시간이 지남에 따라 성능을 확인하는 것으로 어플리케이션이 장시간의 부하 상황에서 어떤 퍼포먼스를 보여주는지 테스트 합니다.  
  • 30-1시간 정도 진행 됩니다. 

2. 스모크 테스트(Smoke Test) 

  • 1-3명 정도의 최소한의 부하를 주어 시스템이 정상적으로 작동하는지 확인한다. 
  • 성공은 어플리케이션이 추가 테스트를 할 준비가 되었다는 의미입니다. 
  • CI/CD와 통합되어 정기적으로 테스트 하는데 사용할 수도 있습니다.

3. 스트레스 테스트(Stress Test)

  • 임계점을 넘은 상황에서 어플리케이션이 깨지는지 회복할 수 있는지를 테스트 합니다.
  • Peak Load 의 2배 정도의 부하를 줍니다.

4. 내구성 테스트 (Endurance Test)

  • 장기간 걸쳐 메모리 누수등의 결함이 없는지 테스트 합니다.
  • 8시간이상 장시간 테스트 합니다.

5. 최고 과부하 테스트(Sppike Test)

  • 특별한 이벤트 상황등에서 시스템의 갑작스러운 부하상황을 테스트 합니다.
  • 스크립트를 이용해 갑작스럽게 부하가 몰리는 상황을 만들어 냅니다. 

6. 중단점 테스트(Break Point Test)

  • 동시 사용자수(Concurrent Users)를 점진적으로 증가 시켜서 시스템 장애 시점을 판단합니다. 

B. 성능 테스트 지표 

  • 가장 간단하게 Latency와 Throughput를 지표로서 사용하여 현 상황을 진단해보려고 합니다. 
  • 그러나 상황에 따라 여러가지 지표(Metric)를 사용할수 있습니다. 
    • System Metrics - CPU Usage, Memory Usage, Disk I/O
    • Application Metrics - Response Rate, Error Rate, Throughput
    • Infrastructure Metrics - Server uptime, Resource Allocation, Virtual Machine Performance
    • Network Metrics - Bandwidth usage, Packet loss, Latency
    • Security Metrics - 실패란 Login 시도, 취약점

1. Latency

  • 작업에 걸리는 시간입니다.
  • 패킷이 목적지에 도달하고 회신 받기까지의 시간입니다.
  • 클수록 느리다는 뜻으로 적을수록 좋습니다.

2. Throughput

  • 시간당 처리량입니다.
  • 클수록 처리량이 많다는 뜻으로 클수록 좋습니다.
  • RPS(Request per Second) : 초당 처리되는 HTTP요청입니다. 
  • TPS (Transaction per Second): 데이터 베이스와 관련해서 초당 처리되는 트랜잭션입니다

C. 테스트 프로그램 종류

JMeter, K6, nGrinder중에서 고민을 했습니다. 각각 장단점을 따져 보았고 익숙하게 사용가능하고 확장이 쉬운 K6로 선택하기로 하였습니다. 

JMeter nGrinder  K6
-1. JVM에서 동작
-2.  각 사용자별 스레드를 할당하기에 많은 리소스 필요
-3. 많은 문서
-4.  GUI 사용가능

 -1.  JVM에서 동작
-2. 스레드에 리소스 (코루틴 - 비동기/이벤트)
-3. 한국어 지원
- GUI. 사용 가능

 - 1. 테스트 실행중 실시간 모니터링 가능
- 2. 자바스크립트와 API를 통한 간단한 스크립트 작성
-3. K6 Cloud를 통한 부산 테스트 가능
-4. 메모리를 적게 사용하고 효율인 CPU사용으로 

 

1. 설치의 편의성

   

    필요시 클라이언트 서버를 늘려가며 테스트를 해야 하는데 JMeter와 nGrinder는 자바도 같이 설치하여야 해서 설치가 조금 더 까다롭다고 생각했습니다.

 

2. 스크립트의 편의성

 

    이미 자바스크립트에 어느정도 익숙하기에 XML이나 GUI로 스크립트를 해야하는 JMeter보다 K6가 사용하기 편리하다고 생각되었습니다. nGrinder도 자바 언어와 비슷한 groovy를 사용하지만 웹인터페이스의 도움을 받아야해서 CLI로 동작가능한 K6가 개인적으로는 러닝커브가 적었습니다.

 

3. 성능차이

출처: grafana Lab

    성능을 비교했을때 K6가 서버 대수를 늘리지 않고 더 많은 동시 요청자수를 만들수 있습니다. 메모리 사용량도 5-6배 차이가 나고 성능을 비교한 차트에서도 K6가 JMeter보다 많은 RPS생성이 가능하며 Latency도 낮습니다. (Grafana Lab, Tate 김용태님) 또한, 스크립트가 아닌 GUI사용시 오버헤드가 나타나 실제 상황과 같지 않은 환경에서 테스트를 하게 됩니다. 

 

D. 적용

  • 우선 BreakPoint Test 적용하여 시스템의 임계점을 파악하고 20분정도 지속시켜서 Peak Load 상황에서 시스템이 어떻게 반응하는지 Load Test를 진행 하였습니다.
  • K6가 이론적으로 13600 RPS까지 보낼수 있다고 하지만 비용상 성능이 낮은 서버를 써서인지 테스트 결과 800-100 VUS(동시요청자 수) 정도면 에러가 생겨서 두개의 클라이언트 서버에서 조금씩 VUS를 늘려가며 BreakPoint Test를 실행했습니다.
  • 결과
    • 1000VUS에 다다르자 처음 160 TPS -> 120 TPS로 줄며 처리량이 감소했지만 이후 회복하였습니다.
    • 이 이상의 부하를 주면 이후 4시 1분 30초쯤의 결과 처럼 TPS도 급격히 줄었습니다. Latency는 특이하게 늘지 않고 오히려 시스템이 점차 멈추어 버렸습니다. 
    • 이후 임계점인 1000 VUS에서 20분정도 더 부하 테스트를 진행하였고 160 TPS에서 300 ms속도를 유지하였습니다. 
    • 결론: 1000명의 동시접속자가 있는 상황에서 160TPS의 처리량과 300ms의 Latency가 임계점으로 확인되었습니다. 

 

출처

bitkunst님의 K6-성능 테스트 유형

Web Performance Testing — DCube’s Practices by Team Merlin(Goverment Digital Product, Singapore)

SK C&C - 성능 테스트 유형 알아보기 

Seongwon님 성능테스트, 부하테스트, 스트레스 테스트..무엇이 다를까?

월급쟁이부자들 - 월급쟁이부자들의 부하테스트를 위한 k6 도입기

문한성님 Throughput과 Latency

우아한 기술 블로그 - 결제 시스템 성능, 부하, 스트레스 테스트

Tate 김용태님의 k6 vs JMeter, 어느 성능 테스트 도구를 써야 할까?

Grafana Lab - Open source load testing tool review: 2020

govl6113님 - 성능테스트 (부하테스트 도구 비교) - jmeter, k6, ngrinder, locust