nGrinder 이용한 서버 성능 테스트

목차:

1. 사용 이유
2. nGrinder란
3. nGrinder vs 다른 툴
4. 내용, 성과

 

 

사전지식:

https://choibulldog.tistory.com/61

서버 성능 테스트의 종류와 필요 지식

1. 사용 이유

북클럽 프로젝트를 공개할 시점이 됐다. 

그래서 내 서버가 대략 어느정도 규모의 트래픽을 감당 가능한지 알고싶었다.

내 서버의 성능을 알고 있어야 나중에 사람들이 많아져도 대응할수 있기 때문이다.

 

.

.

.

 

사실 나는 aws 프리티어에 beanstalk을 사용하고, 

우리 서비스가 엄청 잘될 가능성도 낮기 때문에 필수적으로 nGinder를 사용할 필요는 없다고 생각하지만,

호기심 해소, 학습 등등에도 도움이 될것같아서 사용해 보았다. 

 

2. nGrinder란

네이버에서 grinder라는 오픈소스를 이용해 만든 성능 측정 프로그램이다.

 

특징:

1. 웹 UI를 이용해 편리함

2. 서버에 부하를 일으키고 통계 생성 

3. groovy, Jython를 이용해 테스트 시나리오 작성

4. 국내에서 많이 사용함

 

 

아키텍처

 

Controller, Agent, Target이 있다.

 

Controller:

- 이름처럼 테스트를 명령한다

- 웹 인터페이스 생성

- 통계 표시

 

Agent:

- 명령에 따른 Target 서버에 대한 부하 생성

 

Target:

- 테스트할 대상 서버

 

 

공식적으로 Controller, Agent는 다른 머신에서 구동시키는것을 권장한다.

그래야 자원을 각각의 역할에만 온전히 사용할수 있기 때문이다.

 

3. nGrinder vs 다른 툴

서버 성능 테스트용 툴은 많다.

nGrinder, loadrunner, JMeter, Gatling, vegeta, Wrk 등등...

이중에서 유료인것, 잘 안쓰이는것을 제외하니

nGrinder, JMeter가 남았었다.

 

nGriner를 선택한 이유는

1. 화면이 심플하고 사용하기 좋아보였다.

2. 예약을 통해 주기적인 테스트 가능

3. 코드로 쉽게 테스트 시나리오 작성 가능

 

등등이다.

 

단점도 있었는데,

위에서 말한대로 Controller, Agent를 다른 머신에서 실행하는게 권장된다는 것이다.

 

난 돈이 없어서 그렇게 못하고 그냥 한군데에서 실행했다... 그래서 정확도가 좀 떨어질 것이다.

 

 

4. 내용, 성과

 

이런 화면 보니까 너무 신기했다

 

 

내가 작성한 테스트 시나리오:

 

1. 로그인

2. 내 서제에서 책 목록 조회

3. 선택한 책의 게시글 목록 조회

 

책, 장문을 포함한 게시글은 각각 20개 정도 저장되있고,

가상 유저 20명, 50명으로 나눠 5분간 테스트 한 결과이다.

 

(다양한 테스트 시나리오를 작성하고 세부 설정을 다르게 해가다 보면 더 좋은 테스트를 할 수 있을것이다.)

 

 

가상 유저수 20명

 

가상 유저 수 50명

 

 

TPS는 별 차이 없었지만, 평균 테스트 시간이 크게 차이났다.

게시글 목록 조회를 요청한지 평균 2초가 지나서야 내용이 보인다면 매우 답답할 것이다.

 

테스트를 통해 얻은 결과를 기반으로 유저가 늘어난다면 scale out, 캐시 도입 등을 고려해야 할 것이다. 물론 그 전 서버 애플리케이션에서 비효율적인 로직이 있다면 발견하고 개선해야 할 것이다. (apm인 pinpoint를 활용하는것 고려)

 

 

 

.

.

. 

정리하자면

 

한 사용자가 책 5권과 책에 대한 이미지가 포함된 장문의 기록을 각각 5개씩 가질 때를 가정하고 테스트한 결과 가상 유저 수 20명 정도가 평균 테스트 시간 약 0.8초로 서버에 무리 없는 최대 사용자 수이며,  50명일때는 약 2초로 20명일 때보다 2.5배 오래 걸리는 것을 확인하였다.

 

응답 속도 개선을 위해 시나리오와 관련된 코드들을 살펴본 결과 발견한 문제와 해결방법이다.

 

1. Java 래퍼클래스의 오토 언박싱 - 기본타입으로 변경

2. DB 설계상 서로 거리가 먼 테이블 이용 조회 시 지나치게 많은 join 발생 - 반정규화

3. Fetch Join을 통한 N+1 문제 해결

 

수정 후 다시 테스트해본 결과 서버에서 최대 가상유저 40명 정도까지는 수정 전의 가상유저 20명일 때와 비슷한 성능을 보이며 무리 없이 처리할 수 있도록 개선된 것을 확인하였다.

이 경험을 통해 실무에서의 성능 개선 과정을 조사하고 일부 실천해보았기에 유익하고 재미있다고 느꼈고, 서버의 대략적 성능을 궁금해하는 팀원들에게도 정보를 제공할 수 있어 뿌듯했다.

 

 

 

 

 

 

 

참고:

https://github.com/naver/ngrinder

GitHub - naver/ngrinder: enterprise level performance testing solution

https://tech.madup.com/performance_test_tool/

서버 퍼포먼스 테스트 툴 사용후기

https://techblog.woowahan.com/2572/

결제 시스템 성능, 부하, 스트레스 테스트 | 우아한형제들 기술블로그