무비위키 프로젝트에 멀티 프로세싱을 적용하고 성능을 테스트해보기 위해 artillery로 스트레스 테스트를 진행했다.
Artillery란?
오픈 소스 로드 테스트 도구로, 소프트웨어 애플리케이션의 성능과 신뢰성을 평가하기 위해 사용한다.
주로 웹 애플리케이션, 마이크로서비스, API 등 다양한 유형의 애플리케이션을 대상으로 테스트 가능하다.
Node.js로 작성되었으며, 사용자가 시나리오를 정의하고 해당 시나리오에 따라 애플리케이션에 부하를 가하는 방식으로 동작한다.
시나리오는 사용자의 요청과 동작을 정의하며, 테스트를 위해 다양한 유형의 요청을 생성하고, 트래픽을 모니터링하고, 성능 지표를 측정할 수 있다.
강력한 스트레스 테스트 기능을 제공한다. 여러 사용자 요청의 동시성, 요청 속도, 지연 시간, 에러 처리 등 다양한 시나리오를 테스트하여 애플리케이션의 성능 한계를 찾을 수 있다. 또한, 실제 사용자 행동을 모방하는 시나리오를 작성할 수 있어, 실제 환경에서 발생할 수 있는 트래픽 패턴을 테스트할 수 있다.
테스트 결과를 실시간으로 모니터링하고, 요약 보고서와 성능 그래프를 생성할 수 있습니다. 또한, Artillery는 클라우드 서비스와 통합하여 분산 테스트를 수행할 수 있으며, 다양한 플러그인과 확장성을 제공하여 사용자의 요구에 맞게 커스터마이징할 수 있다.
개발자와 QA 엔지니어, 성능 테스트 전문가 등을 위한 강력한 도구로, 애플리케이션의 성능 및 확장성을 검증하고, 병목 현상과 잠재적인 문제를 식별하는 데 도움을 준다.
Artillery의 특징
- HTTP(S), Socket.io, Websocket 등 다양한 프로토콜을 지원한다.
- 시나리오 테스트를 할 수 있다.
- JavaScript로 로직을 작성해서 추가할 수 있다.
- statsd를 지원해서 Datadog이나 InfluxDB 등에 실시간으로 결과를 등록할 수 있다.
- 풍부한 CLI 커맨드를 제공한다.
- 리포트 페이지를 따로 제공한다.
테스트 진행
Artillery 설치
npm i -D artillery
서버 실행 후 명령어 입력
로컬 서버 http://localhost:3001/movies/like에 100명의 가상 사용자가 각 50번의 요청을 보낸다.
그러므로 총 5000번의 요청이 들어간다.
npx artillery quick --count 100 -n 50 http://localhost:3001/movies/like
결과 예시
몇가지 항목만 살펴보자면,
http.codes.200은 코드 200이 응답된 횟수 즉 요청에 대한 응답이 성공한 횟수라고 보면 된다.
http.requests는 요청이 들어간 횟수이다.
http.response_time의
min은 응답 최고 속도, max는 응답 최저 속도, median은 응답 속도의 중간 값이고 단위는 밀리초이다.
http.responses는 에러코드를 포함한 응답 총 횟수이다.
환경 별 부하 테스트 결과
테스트 차수별로 가상 유저의 수를 100명씩 증가시켰고, 배포환경의 경우 3차까지 건너뛰고 4차 조건부터 테스트하였다.
로컬 싱글 프로세스 환경의 경우 요청 1만건까지는 소화했으나 1만 5천건을 모두 소화하지 못하고 일부 실패가 발생했다.
로컬 멀티 프로세스 환경의 경우 요청 1만 5천건까지 소화했으나 2만건을 모두 소화하지 못하고 일부 실패가 발생했다.
멀티 프로세스가 적용된 배포 환경의 경우 요청 2만건까지 소화했으나 2만 5천건을 모두 소화하지 못하고 일부 실패가 발생했다.
싱글 프로세스 (로컬) | 멀티 프로세스 (로컬) | 멀티 프로세스 (배포) | |
1차 가상유저 100, 요청 50, 총 request 5000 |
요청:5000, 성공:5000, 실패:0, min:202, max:3866, median:320 |
요청:5000, 성공:5000, 실패:0, min:200, max:3009, median:278 |
- |
2차 가상유저 200, 요청 50, 총 request 10000 |
요청:10000, 성공:10000, 실패:0, min:202, max:8654, median:478 |
요청:10000, 성공:10000, 실패:0, min:194, max:6095, median:354 |
- |
3차 가상유저 300, 요청 50, 총 request 15000 |
요청:8924, 성공:8800, 실패:124, min:202, max:9952, median:424 |
요청:15000, 성공:15000, 실패:0, min:194, max:9161, median:432 |
- |
4차 가상유저 400, 요청 50, 총 request 20000 |
- | 요청:13973, 성공:13850, 실패:123, min:194, max:10033, median:459 |
요청:20000, 성공:20000, 실패:0, min:181, max:8656, median:441 |
5차 가상유저 500, 요청 50, 총 request 25000 |
- | - | 요청:24167, 성공:24150, 실패:17, min:180, max:10029, median:478 |
결론
로컬 환경 기준으로 결과를 분석해봤을 때 멀티프로세스를 적용한 경우 확실히 더 많은 요청을 소화했다.
다만 응답 속도에서는 크게 유의미한 결과를 얻지 못했다.
배포 환경의 경우 로컬보다 성능이 좋아서 더 많은 요청을 소화했다.
배포 환경에서 싱글 프로세스도 테스트 해봤으면 더 좋았을텐데 아쉽다.
출처 및 참조
'Development > TIL' 카테고리의 다른 글
프로젝트 간단 소개 영상 제작 (0) | 2023.06.28 |
---|---|
스트레스 테스트2 (feat. 배포 서버 다운) (0) | 2023.06.27 |
Redis Sorted Set (Zset) (0) | 2023.06.21 |
Nest.js 클러스터링 (0) | 2023.06.21 |
비교 단위별 Diff 및 Patch 코드 동작 속도 측정 (0) | 2023.06.16 |