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

LJH·2021년 5월 22일
0

DevOps 강의 (feat. Foo)

목록 보기
4/16
post-custom-banner

해당 내용은 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 기반으로 스크립트 작성하는데 불편함이 있다고 한다.

post-custom-banner

0개의 댓글