ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 부하테스트
    카테고리 없음 2022. 9. 22. 22:22

    프로젝트를 진행하면서 팀원들끼리 "우리 서버 터지는거 아냐?"라는 말을 많이 했다. 특히 데모데이 전날에 우리 서비스 서버가 어느정도 요청까지 처리할 수 있는지 감이 없어서 많아야 몇십명이 들어올 데모데이 전날에는 불안하기도 했다.

    이번에 스레드 풀 설정 및 최적화에 관해 학습 및 테스트를 해보며 부하테스트도 같이 알아봤다.

    부하테스트 툴 선정

    부하테스트 툴을 선정하는데 JMeter, nGrinder, k6 중에서 고려를 했다.

    k6의 경우 결과 시각화를 하려면 유료로 서비스를 쓰거나 CLI로 쓰고 그라파나와 결합을 해야했다. 또 자바스크립트로 테스트를 작성해야해서 거부감을 갖는 팀원도 있었다.

    JMeter는 레퍼런스가 많았지만 인터페이스가 그렇게 쓰기 좋지 않은 것 같다는 생각을 했다. 또 nGrinder 스크립트가 Groovy로 편하고 디테일하게 설정이 가능해서 nGrinder를 선택했다.

    설치 및 실행

    이전에는 AWS에서 Controller와 Agent를 하려고 했다. 하지만 우리가 쓸 수 있는 인스턴스에서 보안규칙 때문에 포트번호의 개수가 매우 제한적이었다. 또 EC2의 성능도 좋지 않아서 로컬에서 Controller와 Agent를 설치해서 진행하려 한다.

    $ mkdir ngrinder
    $ cd ngrinder
    $ wget https://github.com/naver/ngrinder/releases/download/ngrinder-3.5.5-p1-20210531/ngrinder-controller-3.5.5-p1.war
    • Controller 실행
    nohup java -jar ngrinder-controller.war > nohup.out 2>&1 &

    디폴트 포트 번호가 8080

    • Controller를 실행한 포트 번호로 브라우저 주소창에 http://localhost:[포트번호]/login를 입력하면 아래와 같은 화면을 확인할 수 있고, 초기 아이디와 패스워드는 admin admin이다.

    https://velog.velcdn.com/images%2Fhellonayeon%2Fpost%2F1e64c157-9785-4ca5-aaf2-87a46ce989aa%2Fimage.png

    • Agent 설치

    사이트에 로그인 한 후 메뉴에서 admin > Download Agent를 클릭하면 Agent 압축 파일이 다운로드 되고, 완료 후에 압축을 풀어준다.

    tar -xvf ngrinder-agent-3.5.5-p1-localhost.tar
    • Agent 실행
    $ ./run_agent.sh

    API 호출 테스트

    API 호출을 테스트하기 위해서는 Script를 작성해야한다. 어떤 REST API로 요청을 보낼 것인지 설정해준다.

    https://velog.velcdn.com/images%2Fhellonayeon%2Fpost%2F607cf09b-d558-49ee-a9ad-9fa75671c09f%2Fimage.png

    Validation을 통해 Groovy로 작성한 테스트 코드를 실행시키며, 테스트 결과를 통해 요청이 정상적으로 날아갔는지 확인할 수 있다.

    테스트 시 환경 설정 방법

    nGrinder 공식 문서 참고

    Agent: 말 그대로 Agent의 수. 일반적인 로컬에서 테스트를 실행할 경우 1이 고정값인 것 같다. 아마 도커나 쿠버네티스를 통해 가상환경을 만들어준다면 Agent를 여러개로 설정할 수 있을 것 같다.

    Processes: 한 Agent에 얼마나 많은 worker process를 쓸지이다. 그리고 이 process들은 또 스레드들을 가지게 된다

    Vuser per agent: 프로세스 수 * 스레드 수가 각 agent당 가상 사용자의 수가 된다.

    Duration: 말 그대로 얼마나 오래 테스트가 지속될지 정하는 것이다. 어느 블로그의 말을 따르면 어느정도 길게 확보해줘야 의미있는 평균치가 나온다고 한다.

    Ramp-up: Ramp-up을 체크하면 프로세스 수가 점진적으로 늘어난다. 점진적인 부하를 테스트하고 싶을 때 쓰면 될 것 같다.

    TPS: 단위 시간당 처리하고 있는 요청 건수. 보통 TPS 그래프를 보면 증가하다가 더 이상 증가하지 않는 지점 (Saturation Point)가 생긴다. 이 이후 지점부터는 사용자가 몰리면 TPS는 크게 변하지 않는 상태에서 응답 시간이 길어지게 되는 것이다.

    테스트 예시

    이렇게 테스트를 하면 가상 사용자 1000명을 기준으로 테스트를 진행한 것이다. 평균 TPS가 632정도 나왔는데, 이는 초당 처리 가능한 요청 수를 나타낸다.

    테스트 성공률이 100%로 높은데, 이러면 사용자를 더 높게 설정해서 진행해도 좋다.

    높게 해서 TPS가 확실히 떨어지고 지연시간이 늘어나고 에러 발생확률이 올라간다면 그때는 로드밸런싱 등을 해주면 좋다.

    참고

    프로메테우스, 그라파나를 이용한 모니터

    서버 성능테스트, 클릭 한 번으로 끝내볼 수 있을까?

    ngrinder - 소개

    JMeter을 이용해서 웹서버 성능 테스트하기

    설치와 사용법 정리

Designed by Tistory.