Locust로 실제 EC2 서버 부하 테스트 해보기 (xlarge 인스턴스)

 

응답시간 3초 이상이면 고객 이탈 확률이 급증한다.

 

 

위 인용구는 구글 애드센스의 조사결과 발표 내용이다. 그만큼 사이트를 운영할 때 응답시간은 중요하다. 

출처 : 2015년 라드웨어 분석 자료

 

1999년의 전자 상거래 사이트의 최적 로드 시간이 8초고 2010년이 3초이므로, 2025년 현재 고객의 요구치는 더 높을 것이다. 개발한 사이트의 응답시간을 측정할 수 있는 툴을 사용해보고 싶었다. 

왜 Locust인가?

locust는 설치와 사용이 편리하고, 파이썬 스크립트로 작성을 하기 때문에 훨씬 빠르고 간편하게 부하 테스트를 해볼 수 있다. 웹 ui를 제공하는게 확실히 처음 입문하는 사람에게 편하게 다가온다. 

Locust 설치

 

Python 3.5 버전 이상 설치 후에 하자.

 

https://locust.io/#install

Locust.io

 

 

방화벽 해제

ufw 즉, 우분투 방화벽에 locust 기본 포트인 8089를 해제 (아래는 ssh로 할 때의 예시)

sudo ufw status
8089 포트가 없으면

sudo ufw allow 8089
추가해주고

sudo ufw status
로 확인

sudo ufw enable
질문 나오면 y 누르고 엔터(적용)

환경변수 추가

locust는 파이썬 기반으로 작동해서 파이썬이 있어야하고 기존에 파이썬이 안깔려 있어서 설치 후 시스템 환경 변수 편집 - 고급 - 환경 변수 - 시스템변수 - PATH 편집 - 새로만들기 - Python 설치 경로 추가  * 적용 안되면 컴퓨터 재시작

 

기본적으로 locust를 실행할 때, locustfile.py를 찾게 되어있어서 파일명을 맘대로 만들었다면 locust -f 옵션을 붙여서 실행해야한다. 

locust -f load_test.py

 

 

잘 실행된 화면 이제 localhost:8089로 접속할 수 있다.

스크립트 작성

from locust import HttpUser, task, between

class WebsiteUser(HttpUser):

    host = "{your_domain_url}"

    wait_time = between(1, 3)  # 요청 간격 (1~3초 랜덤)

    @task

    def test_api(self):

        """🔥 로그인 없이 호출 가능한 /api/test 부하 테스트"""

        response = self.client.get("/test", name="public_test_api")

        if response.status_code != 200:

            print(f"❌ 오류 발생: {response.status_code}")

 

테스트할 앱에 spring security를 쓰고 있는데 /api/test 경로를 jwt 토큰 없이도 가능하게 설정해놨다.

 

부하테스트 시작 

계속 api 요청이 들어오는 것을 확인할 수 있다. (backend 컨테이너에 로그가 계속 찍히는 모습)

 

chart로 들어가서 시각화된 정보를 보자.

 

Total Requests per Second는 Locust의 차트에서 나타나는 성능 지표로, 테스트 동안 서버가 처리한 전체 요청 수를 초당으로 나타낸다. 

Users랑 Ramp up을 늘려보았다. Users를 10으로 늘려보니 rps가 엄청 늘어간 것을 볼 수 있다. 

 

그러나 /api/test 경로는 아무 컨트롤러도 없는 의미없는 경로라 locust가 잘 작동하는지 확인하는 용이다.

 

부하테스트에서 의미찾기

시나리오를 정의하고

예시) 동시에 웹 페이지를 보는 100명의 사용자의 로드 시간이 5초를 초과하지 않는지?

이렇게 임계구역(시간)을 설정하고 이를 넘으면 실패로 보고 개선을 하면 좋을 것 같다.

실제 controller가 있는 get 요청을 보내보니 응답시간이 1.7초까지 튀는 모습을 볼 수 있다.

하지만 응답시간 만으로는 구체적으로 어느 부분에서 병목현상이 발생하는지 알기 어려우므로,

api 별로 테스트를 해보고 평균 응답시간이 긴 api를 분석해야겠다고 생각했다.

 

api 별로도 응답시간 등을 볼 수 있다. 보면 유저의 구독 리스트 조회하는데 Max값을 보면 최악의 경우 2.6초가 걸렸다. 중앙값, 95%, 99%, 평균, 최소, 최대을 종합적으로 판단하는 게 좋아보인다. 크롤링이 들어가는 부분이라 확실히 오래걸리는 것을 볼 수 있다. 

 

팀원으로부터 응답시간이 오래걸릴 것 같은 api를 테스트해봤으면 좋겠다고 요청받았다.

 

 

테스트할 api : /api/collections/shared/{sharedCollectionId}

매개변수 : sharedCollectionId

전송 시 헤더에 들어가야할 요소 : "accessToken": "{accessToken_Value}"

 

위를 기반으로 테스트할 파이썬 코드를 짜보자.

# 공유 컬렉션을 조회하는 API 호출

    @task(weight=10)

    def get_shared_collection(self):

        if self.access_token:

            headers = {

                "accessToken": self.access_token  # 로그인 후 얻은 accessToken을 헤더에 추가

            }

            shared_collection_id = 1  # sharedCollectionId는 1로 설정

            response = self.client.get(f"/collections/shared/{shared_collection_id}", headers=headers)

            # 응답 상태 코드 및 본문 출력

            print(f"Shared collection response status code: {response.status_code}")

            # print(f"Shared collection response body: {response.text}")  # 응답 본문 출력

            if response.status_code == 200:

                print("Successfully fetched shared collection.")

               

            else:

                print(f"Failed to fetch shared collection. Status code: {response.status_code}")

        else:

            print("Access token is not available. Login first.")

 

하지만 다른 분들의 글을 보니 하나의 노드에서만 트래픽을 발생시키는 경우에는 서버의 컴퓨팅 자원 한계로 인하여 대량의 트래픽을 생성하는 데 제약이 있다고 한다.
이러한 한계를 극복하기 위해 locust는 마스터-워커 구조를 제공하고 있고,
실습은 위에서 진행한 Rate Limiting 테스트를 여러 노드를 사용하여 부하를 넣는 방식으로 진행한다.