스트레스 테스트 툴(Artillery)로 성능 측정하기

LJH·2021년 5월 22일
0

DevOps 강의 (feat. Foo)

목록 보기
4/16

해당 내용은 Class101의 현직 대기업 개발자 푸와 함께하는 진짜 백엔드 시스템 실무! 강의를 기반으로 작성했습니다.

😀 목표

  • Artillery를 이용해서 부하테스트(Stress Test)

1. Node.js 다운로드

  • 이전에 node를 설치했었기 때문에 넘어간다.

    • 다운받고 싶다면 링크에서 다운받으면 된다.
  • 강의에서는 14.15.3 버전이고, 나는 현재 12.18.3 버전이다.
    이후 문제가 생긴다면 버전 업그레이드를 하자


2. Artillery 설치


3. Arillery 스크립트 작성 및 실행

  • 새로운 폴더를 만들고 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

    • 그래프 설명

      • 세로는 Latency(지연시간), 가로는 시간을 나타낸다.

      • max : 가장 오래걸린 요청 -> 응답 시간

      • p95 : 전체 HTTP 트랜잭션 중 가장 빠른 것부터 95%까지(거의 대부분의 트래픽이 여기에 포함된다.)

      • p50 : 전체 HTTP 트랜잭션 중 가장 빠른 것부터 50%까지(절반의 트래픽이 여기에 포함된다.)

      • min : 가장 빠르게 온 요청 -> 응답 시간

이외에도 p99를 많이 사용한다. 실제 벤치마크를 잴 때에도 p99, p95 그래프를 많이 그린다. p99는 거의 대부분의 트래픽이기 때문에 실제 애플리케이션의 성능에 가깝다.


4. 스트레스 늘리기

4-1. 가상 유저 1 → 4

  • Latency가 눈에띄게 증가했지만 정상적으로 모든 요청이 처리된걸 확인할 수 있다.

4-2. 가상유저 4 → 8

  • 155개의 요청이 타임아웃에러가 났다. 40초정도를 지나자 max Latency가 급증한다. 스케일 업을 통해 Latency가 얼마나 줄어드는지 확인해보자

5. 스케일 업

  • 기존 인스턴스는 cpu가 2개였다. 이제 cpu가 8개인 인스턴스를 만들어서 테스트해보자.
  • 서울리전은 제한이 있어서 기존 인스턴스를 삭제하고 다시만들어야한다.

  • 머신 유형에서 cpu8개, 8gb 메모리를 선택해주고 나머지는 이전과 동일하다.
    사진에서 보이진 않지만 아래 http, https 트래픽을 허용 체크해야한다.

  • ssh 접속 후 wget, java 설치 후 애플리케이션 가져와서 실행시킨다.
    이 과정은 이전 글에 있으니 생략한다.

  • 똑같이 60초동안 8명의 가상유저로 설정하고 진행했더니 타임아웃된 요청없이 모두 처리됐다.

방금 생성한 인스턴스는 비용이 비싸기때문에 꼭 삭제하자


6. 실무에서의 성능테스트 기준

이 방법은 사람마다 다를 수 있으므로 자신만의 방법을 만들자.

  1. 항상 예상 TPS보다 여유롭게 성능 목표치를 잡아라.

    • 만약 예상 TPS가 1000정도라면 트래픽이 튀는상황을 대비해 최소 3천~4천 정도로 여유롭게 인스턴스를 구성해야한다. 단 그 만큼 서버비용이 많이든다.
  2. API에 기대하는 Latency를 만족할 때까지 성능을 테스트해야한다.

    • 우선 단일 요청에 대한 Latency가 몇인지 확인해봐야한다.(artillery 스크립트 기준으로 가상 유저수를 1로 하라는 이야기)

    • 만약 단일요청에대한 Latency가 기대하는 Latency보다 높다면 이것은 스케일 아웃으로 해결할 수 없다.. 코드가 비효율적이거나 해당 API에서 실행되는 I/O가 병목인 경우가 많다.

    • 네트워크에서 Latency가 발생하는 경우도 있다.

처음으로 성능테스트 라는걸 해보았다. 해보면서 드는 생각은 기존에 만들었던 사이드프로젝트에서 글 조회시 다수의 쿼리가 발생해 성능최적화를 하다가 막혀서 포기했었는데
다시 시도해보고, 기존이랑 최적화 이후 성능테스트를 통해 비교해 보면 재밋을 것 같다!

스트레스 테스트 툴을 선택할 때는 두 가지 질문에 적합한 걸 선택하자.

1. 스트레스 테스트로 수집되는 지표 중 나에게 필요한 지표가 모두 있는가?
2. 테스트 스크립트로 내가 원하는 시나리오 대로 테스트해보기 쉬운가?

테스트 툴로는 nGrinder, Artillery, JMeter 등이 존재한다.
nGrinder는 Java 기반으로 스크립트 작성하는데 불편함이 있다고 한다.

0개의 댓글