게임 옥션 서버

Locust를 사용한 API 성능테스트

KimGeonWoo 2024. 1. 23. 08:45

프로젝트를 개발하며 API가 정상적인 처리, MyBatis,Redis,RabbitMQ등의 연동들을 확인 할 수 있었습니다.

개발 도중 해당 API를 사용하는 사용자들의 수가 증가함에 따라 데이터 송신 및 응답속도 등이 기대한 수치만큼 나오는지에 대한 확인이 필요했었습니다. 이러한 이유로 성능테스트를 하게 되었으며, Gatling, JMeter, Locust 등 다양한 성능테스트 중 Locust를 사용해 보았습니다.

이번 포스팅에서는 성능테스트란 무엇인지, 성능테스트의 결과에 따른 리팩토링을 했던 과정을 작성하겠습니다.

 

성능테스트

  • 소프트웨어 또는 시스템의 성능, 안정성, 확장성 등을 측정하고 평가하기위해 사용하는 프로세스.
  • 특정 부하 조건에서 어떻게 작동한는지와 ㅅ성능이 어떠한지 그리고 어떠한 한계까지 견딜 수 있는지 확인하기 위해 사용한다.
  • 부하테스트, 지속성 테스트, 스트레스 테스트, 최고 부하 테스트 등의 각각의 다양한 조건과 목표를 목적으로 하는 테스트 종류들이 있다.
    • 부하 테스트(Load Test) : 특정한 수의 부하를 제한된 시간을 두어서 웹 어플리케이션에 이상이 없는지 확인하는 테스트
    • 스트레스 테스트(Stress Testing) : 부하의 임계점을 찾고, 장애상황에서의 시스템의 반응을 보고 잘 복구된는지  확인하기위해 점진적으로 부하를 올리면서 진행하는 테스트
    • 최고 부하 테스트(Peat Test) : 순간적으로 감당할 수 없을 만큼의 부하를 주며, 시스템이 제대로 동작하고 회복하는지 확인하는 테스트.
    • 지속성 테스트 (Endurance Test) : 오랜 시간동안 부하를 주어 시스템이 얼마만큼의 시간동안 정상적으로 작동할 수 있는지 확인하는 테스트.

 

 

Locust

성능 테스트를 하기위한 오픈소스 부하테스트 툴로 시스템이 처리할 수 있는 동시 사용자 수를 파악하거나 서버에서 지원하는 초당 요청 수 (ResponsePerSecond,RPS)를 파악하기위해 사용하는 성능테스트 도구

  • Python을 사용하여 API 테스트 코드를 작성할 수 있다.
  • 구현이 쉬워서 작은 규모의 프로젝트에 테스트하기 적합하다.
  • 설치와 실행이 간편하며, 대시보드를 통해 테스트를 모니터링이 가능하다.

JMeter vs Gatling vs Locust

  • Locust : 
    • Python를 사용하여 코드 기반으로 테스트 시나리오를 정의할 수 있다.
    • 진입장벽이 낮으며 간편하게 다수의 동시 사용자를 시뮬레이션 하기에 적합하다.
    • 대규모 또는 복잡한 시나리오를 처리하기에는 JMeter 또는 Gatling보다 부적합하다.
  • JMeter :
    • GUI를 제공하여 테스트 계획 및 모니터링을 직관적으로 확인할 수 있다.
    • Java 기반의 성능 테스트 도구이다
    • 다양한 프로토콜 및 플러그인을 가지고 있다
    • 많은 리소스를 소비하여 대규모 테스트 시 높은 부하를 발생할 수 있다.
    • 다른 성능테스트 툴에 비해 많은 기능을 가지고 있으므로 초기 진입장벽이 다른 성능테스트 툴에 비해 높다.
  • Gatling : 
    • 비동기식 이벤트 중심 아키텍처에 중점을 맞추고 있다. 웹 어플리케이션 또는 마이크로서비스 아키텍처에 적합하다.
    • Scala기반의 DSL(Domain-Specific Language)를 사용하여 시나리오를 작성할 수 있다.
    • HTTP 기반의 프로토콜에 중점을 두고 있으며, JDBC,SMTP 등 프로토콜에 대한 성능테스트는 다른 툴에 비해 부적합하다.

3가지의 대표적인 성능테스트 툴을 비교해보았습니다.

그 중 Locust를 선택한 이유는 진입장벽이 낮아 초기 접근하기가 쉬우며, 또한 코드 기반으로 테스트 시나리오를 정의할 수 있었습니다.

또한 웹 페이지를 통해 성능 테스트에 대한 실시간 모니터링이 가능하였으며 리소스가 다른 성틍테스트 툴에 비해 상대적으로 적어서 어플리케이션 전체가 아닌 특정 API에 대한 성능테스트에 적합하다고 판단했습니다.

 

 

 

Locust 성능테스트 모니터링

기존의 게임 옥션서버에서 Redis를 연동한 상품 조회 API의 성능 테스트 과정입니다.

상품 조회 API에서 Redis를 사용하여 캐싱을 하였지만 현재는 조회 과정에서 Redis를 사용하지 않는 이유를 설명하기 전에 Locust를 사용한 성능테스트를 먼저 알아보겠습니다..

 

※ Redis를 연동 및 입찰 API

 

Redis를 적용한 상품조회 API

 

Statistics

  • Requests : 성능테스트를 진행하는 동안 전송된 요청의 수
  • % lie Response Time : 백분율의 비율이 해당 값보다 낮은 응답시간을 갖는다
  • Average Response Time : 모든 요청시간의 평균 값
  • Current RPS : 초당 요청 수의 값
  • Current Failures : 테스트 중 실패한 요청의 수 (응답한 HttpStatus가 200이 아닌 경우)

 

Charts

Total Request per Second

  • RPS : 테스트하는 API에서 1초마다 응답할 수 있는 수
  • Faulures/s : 테스트하는 API에서 실패한 요청의 수

ResponseTime (ms)

  • 95th percentile : 요청의 95%이상의 평균 응답 시간(ms)
  • 50th percentile : 요청의 50%이상의 평균 응답 시간(ms)

Number of Users

  • Users : 테스트시 요청을 가하는 사용자의 수

 

Redis를 적용한 상품 조회 API의 성능테스트 결과로는 평균 응답시간이 서버가 운영되는 시간이 점차 증가할수록 1.5초까지 점차 증가하는것을 확인하였습니다.

현재 적용중인 상품 조회 API의 구조는 Redis에 Key값이 저장되어있는지에 대해 확인하기위해 풀 스캔하는 구조로 되어있으며, 이로인해 응답시간이 지연되었다고 생각합니다.

이에 대해 해결방법으로 Redis의 Key 설정시 ID:상품명:시간(00~24) 와같이 상세하게 분할하여 사용하거나 Redis의 expire를 사용하여 제한시간을 낮추는 등의 리팩토링을 먼저 실시했습니다.

이에 대한 결과로는 리팩토링 전과 비슷한 성능을 보여주었으며, 조회 필터링에 따라 데이터 캐싱이 추가적으로 되기때문에 Redis 제외하는것이 좋다고 판단되었습니다.

이러한 이유로 상품 조회 API에서는 Redis를 제외하였으며 MyBatis를 연동한 Mapper에서 동적쿼리와 JOIN문을 사용하여 카디널리티를 낮추는 리팩토링을 하였습니다.

 

리팩토링 후 성능테스트 

 

리팩토링 적용 후 사용자의 수가 5000일 경우 RPS가 500~600의 평균 값으로 상승되었으며, 응답시간 또한 0.5초 이하로 응답하게 되었습니다.

 

결과

Locust 성능 테스트 툴을 사용하여 사용자들의 수와 증가하는 값에 따라 결과값을 모니터링할 수 있었으며, 리팩토링 과정을 통해 기존의 API보다 많은 RPS와 빠른 응답속도를 보장할 수 있게 되었습니다.

 

느낀점

이번 성능테스트는 많은 프로젝트를 모듈화 하지 않은 하나의 프로젝트를 사용하였기에 접근성이 낮고 모니터링을 통해 사용성이 높은 Locust를 사용하여 성능테스트를 하였습니다.

이번 포스팅에서는 성능테스트들의 종류들에 대해 알 수 있었으며 현재 시나리오를 작성한 성능테스트에서는 포스팅을 하지않았지만 부하테스트, 스트레스 테스트, 인듀어 테스트를 적용해보았으며, 이로인해 각각 API의 성능 보장 및 리팩토링을 해야하는 개선점을 쉽게 파악할 수 있었습니다.

 

출처 및 참고내역

서버 성능 테스트의 종류와 필요 지식 — 최불독의 머릿속 (tistory.com)

Locust로 서버 성능 테스트하기. Locust란? | by 박재성 | Medium

https://softwaretestingsapiens.medium.com/locust-vs-jmeter-vs-gatling-932bf73ad88c