[python, server] Locust 부하테스트

서버 부하테스트

부하테스트 단계

1. 목표설정
2. 테스트 시나리오 정의
3. 부하 생성 도구 선택
4. 부하 테스트 실행
5. 결과 모니터링
6. 응답 시간 측정
7. 서버 용량 측정
8. 스케일링 테스트
9. 부하 테스트 결과 문서화
10. 성능 개선 및 문제 해결

---

목표

• n초로 설정해둔 기준 RT 가 증가하지 않는 선에서 최대 사용자 수 측정

테스트 시나리오

• 측정이 필요한 3개의 API에 Cache 를 제거하고 동일한 파라미터 값을 태워 요청 후 RT 측정
• User 수를 증가시키며 병목 현상이 일어나는 지점을 확인

TOOL 선택

* FastAPI 로 구축한 서버의 부하테스트를 위해 툴을 찾아보다가 locust 를 사용하기로 결정

* locust의 장점: 
1. ip 패키지로 쉽게 설치가 가능
2. python 스크립트를 사용하기 때문에 빠르고 간편하게 부하 테스트를 수행할 수 있다.
3. 웹 인터페이스를 지원해주기 때문에 테스트 진행과정을 시각화해서 볼 수 있다.

---

1. 설치

# install
$pip install locust

# 설치확인
$locust -V

2. locust 스크립트 작성

locustfile.py 에 필요한 코드 작성

from locust import HttpUser, task, between

class WebsiteUser(HttpUser):

    wait_time = between(3,7) # 3~7초 사이에 임의의 값으로 요청 대기
    data = ''
    header = {'access-token': ''}
    
    def on_start(self): # start
        print("Test Start")
        
    def on_stop(self): # end
        print("Test End")
         
    @task(2)
    def query_test(self):
        path = ""
        params = {'total_count': }
        self.client.post(path,  data=self.data, params=params, headers=self.header)
        
        
    @task
    def total_count_test(self):
        path = ''
        self.client.post(path, data=self.data, headers=self.header)
        
    @task
    def filter_test(self):
        path = ''
        self.client.post(path, data=self.data, headers=self.header)

* WebsiteUser 클래스는 부하테스트를 하면서 사용하게 될 유저의 객체를 생성하는데 사용됨.
* HttpUser 클래스를 상속받게 되는데 각 유저에게 client 속성을 부여하게 됨.
* 마치 실제 유저가 사용하듯이 http request 요청을 할 수 있음.

* @task 데코레이터로 수행될 task 를 정의할 수 있음.
* 여러개의 task가 존재할 경우 weight(가중치)를 줄 수 있는데 @task(n) 으로 n번만큼의 호출을 한다는 의미.

* wait_time 변수 값을 통해 요청 대기 시간을 임의로 3~7초로 부여함.

3. locust 실행

$locust

4. 웹에서 구동 확인

http://localhost:8089 으로 접속하면 하단의 화면을 확인할 수 있다.

* Number of users : 최대 동시접속 유저 수
* Spawn rate : 초마다 증가될 유저 수
-> 부하테스트를 수행할 때 초기에는 가상 사용자를 많이 생성하지 않고 시간이 지남에 따라 점진적으로 증가
-> 사용자 생성 속도를 조절하여 시스템에 부하를 천천히 증가시키기며 시스템의 성능 & 안정성 평가 가능
-> 어떤 수준에서 문제가 발생하는지 파악 가능
* Host : 테스트를 수행할 서버 주소

start swarming 버튼을 클릭하면 테스트 시작

* 최대 동시접속 유저수 : 300명
* 초마다 10명씩 증가
* 요청할 서버 주소

* chart 형태로 rps 를 확인할 수 있음.
* 설정한 최대 유저수인 300명이 접속해서 request를 요청했을 때의 부하정도를 확인할 수 있음.

---

결과분석

• RPS

  • 높은 RPS를 처리할 수 있는 서버 구성은 확장가능성이 높아지며, 시스템의 부하를 효과적으로 분산할 수 있음
  • 높은 RPS를 처리하는 서버는 일반적으로 빠른 응답시간을 제공할 가능성이 있음
  • 높은 RPS를 처리하는 서버 구성은 리소스를 효율적으로 사용할 수 있음

• RPS , RT 증가 --> 높은 부하를 처리중

• 특정 시점에서 User가 늘어나도 RPS가 늘지 않는 이유 (문제)

  • task가 서버에 get 요청을 할 때, response를 받지 않으면 task 가 끝났다고 판단하지 않기 때문에 다시 task 를 실행할 때까지 RT + wait_time 만큼 bloking이 된다.
  • RPS 는 'Request per seconds' 이며, response를 받지 못하면 request 를 날리지 못한다.
  • RPS가 유지되고 RT가 증가 --> API 서버쪽에서 병목이 발생하는지 확인해야함
    • 이 의미는 Request는 제대로 가는데 Response Time 이 늘어나는 것이기 때문
    • 서버 자원 부족, I/O 병목, 비효율쿼리, 네트워크 병목, 부하 분산 부족이 원인이 될 수 있음

• User가 늘어나도 RPS는 유지되고 RT도 유지된다 --> 부하를 효과적으로 처리하고, 안정적으로 운영중이다.