해당 내용은 Class101의 현직 대기업 개발자 푸와 함께하는 진짜 백엔드 시스템 실무! 강의를 기반으로 작성했습니다.
😀 목표
- Artillery를 이용해서 부하테스트(Stress Test)
1. Node.js 다운로드
-
이전에 node를 설치했었기 때문에 넘어간다.
- 다운받고 싶다면 링크에서 다운받으면 된다.
-
강의에서는 14.15.3 버전이고, 나는 현재 12.18.3 버전이다.
이후 문제가 생긴다면 버전 업그레이드를 하자
2. Artillery 설치
-
https://artillery.io/docs/guides/getting-started/installing-artillery.html
-
위 링크에 설치법이 나와있다. 또한 사용법도 잘 나와있으니 참고하자
-
vscode에서 터미널을 열고 명령어를 입력한다.
npm install -g artillery
3. Arillery 스크립트 작성 및 실행
.png)
-
새로운 폴더를 만들고 vscode로 열어서 cpu-test.yaml 파일을 만들어준다.
-
해당 파일에 스크립트를 작성한다.
- 스크립트는 github에 올려놓으셨다.
3-1. 스크립트 설명
-
target : 인스턴스로 접속할 url을 적어주면 된다. http:// + 인스턴스 외부ip
-
duration : 성능을 측정하는 시간
-
arrivalRate : 매초 새로운 가상 유저를 만드는 수
3-2. 스크립트 실행
artillery.cmd run --output report.json ./cpu-test.yaml-
Cannot read property "config" of undefined
-
config를 찾을 수 없다는 에러가 났다.. node.js 버전때문인가 싶어서
삭제후 재설치 했지만 같은상황이다. -
문제는 폴더를 한글로 한것.. 개발 공부를 하면서 누구나 한번씩 겪었을 것이라 생각한다ㅋㅋ
잊을만하면 한번씩 하는 실수 ㅠㅠ 폴더명은 항상 영어로하자..
3-3. html파일로 결과 확인하기
-
결과가 json파일로 나오게 된다. 이걸 html파일로 열어보자
artillery.cmd report .\report.json.png)
.png)
-
그래프 설명
-
세로는 Latency(지연시간), 가로는 시간을 나타낸다.
-
max : 가장 오래걸린 요청 -> 응답 시간
-
p95 : 전체 HTTP 트랜잭션 중 가장 빠른 것부터 95%까지(거의 대부분의 트래픽이 여기에 포함된다.)
-
p50 : 전체 HTTP 트랜잭션 중 가장 빠른 것부터 50%까지(절반의 트래픽이 여기에 포함된다.)
-
min : 가장 빠르게 온 요청 -> 응답 시간
-
-
이외에도 p99를 많이 사용한다. 실제 벤치마크를 잴 때에도 p99, p95 그래프를 많이 그린다. p99는 거의 대부분의 트래픽이기 때문에 실제 애플리케이션의 성능에 가깝다.
4. 스트레스 늘리기
4-1. 가상 유저 1 → 4
.png)
.png)
.png)
- Latency가 눈에띄게 증가했지만 정상적으로 모든 요청이 처리된걸 확인할 수 있다.
4-2. 가상유저 4 → 8
.png)
.png)
.png)
- 155개의 요청이 타임아웃에러가 났다. 40초정도를 지나자 max Latency가 급증한다. 스케일 업을 통해 Latency가 얼마나 줄어드는지 확인해보자
5. 스케일 업
- 기존 인스턴스는 cpu가 2개였다. 이제 cpu가 8개인 인스턴스를 만들어서 테스트해보자.
- 서울리전은 제한이 있어서 기존 인스턴스를 삭제하고 다시만들어야한다.
.png)
-
머신 유형에서 cpu8개, 8gb 메모리를 선택해주고 나머지는 이전과 동일하다.
사진에서 보이진 않지만 아래 http, https 트래픽을 허용 체크해야한다. -
ssh 접속 후 wget, java 설치 후 애플리케이션 가져와서 실행시킨다.
이 과정은 이전 글에 있으니 생략한다.
.png)
.png)
.png)
- 똑같이 60초동안 8명의 가상유저로 설정하고 진행했더니 타임아웃된 요청없이 모두 처리됐다.
방금 생성한 인스턴스는 비용이 비싸기때문에 꼭 삭제하자
6. 실무에서의 성능테스트 기준
이 방법은 사람마다 다를 수 있으므로 자신만의 방법을 만들자.
-
항상 예상 TPS보다 여유롭게 성능 목표치를 잡아라.
- 만약 예상 TPS가 1000정도라면 트래픽이 튀는상황을 대비해 최소 3천~4천 정도로 여유롭게 인스턴스를 구성해야한다. 단 그 만큼 서버비용이 많이든다.
-
API에 기대하는 Latency를 만족할 때까지 성능을 테스트해야한다.
-
우선 단일 요청에 대한 Latency가 몇인지 확인해봐야한다.(artillery 스크립트 기준으로 가상 유저수를 1로 하라는 이야기)
-
만약 단일요청에대한 Latency가 기대하는 Latency보다 높다면 이것은 스케일 아웃으로 해결할 수 없다.. 코드가 비효율적이거나 해당 API에서 실행되는 I/O가 병목인 경우가 많다.
-
네트워크에서 Latency가 발생하는 경우도 있다.
-
처음으로 성능테스트 라는걸 해보았다. 해보면서 드는 생각은 기존에 만들었던 사이드프로젝트에서 글 조회시 다수의 쿼리가 발생해 성능최적화를 하다가 막혀서 포기했었는데
다시 시도해보고, 기존이랑 최적화 이후 성능테스트를 통해 비교해 보면 재밋을 것 같다!
스트레스 테스트 툴을 선택할 때는 두 가지 질문에 적합한 걸 선택하자.
1. 스트레스 테스트로 수집되는 지표 중 나에게 필요한 지표가 모두 있는가?
2. 테스트 스크립트로 내가 원하는 시나리오 대로 테스트해보기 쉬운가?
테스트 툴로는 nGrinder, Artillery, JMeter 등이 존재한다.
nGrinder는 Java 기반으로 스크립트 작성하는데 불편함이 있다고 한다.
