[Concept] API 성능테스트 (feat. nGrinder 를 이용한 성능 테스트)

성능테스트란?

---

쉽게 말하면 내가 만든 웹 서버(API)가 얼마나 많은 사용자들을 감당할 수 있는지 테스트하는 것을 말한다. 이외에도 두 가지 설계에 대해서 어떤 설계가 더 좋은 성능을 내는지 확인하기 위해서도 사용될 수 있다.

성능의 지표

---

성능을 판단하는 대표적인 지표로는 Throughput(처리량)과 Latency(지연시간)이 있다.

 

Throughput 은 시간당 처리량을 의미하고 TPS(Transaction per seconds), RPS(Request per seconds) 와 같은 세부항목이 있다. 이러한 수치들은 해당 서비스가 1초당 어느정도의 작업을 처리할 수 있는지 나타내기 때문에 높은 수치일수록 성능이 좋다고 말할 수 있다.

 

Latency 는 지연시간을 의미하고 이는 시스템이 클라이언트로부터 Request 를 받아서 Response 를 보내주기까지 걸리는 시간을 의미한다. 말 그대로 특정 작업을 얼마나 빨리 처리할 수 있는지 나타내는 성능 지표이다. Latency 는 당연히 낮은게 더 빨리 응답한 것이기 때문에 낮은 수치일수록 성능이 좋다고 말할 수 있다.

 

내가 설계한 시스템의 각 구간 TPS 와 Latency 가 위와 같을 때 전체 구간의 TPS 와 Latency 는 각각 얼마일까?

답은 Throughput : 500TPS, Latency : 350ms 이다.

 

모든 구간을 더한 Latency 와는 다르게 Throughput 즉, TPS 는 가장 낮은 구간이 전체 시스템의 성능이 되는 것을 확인할 수 있다.

 

이러한 흐름이 있을 때 중간에 좁은 통로 때문에 넓은 통로의 크기와는 상관없이 동일하게 차가 막히는 것과 동일한 이유이다. 이러한 좁은 통로를 병목구간이라고 하는데, Throughput 에는 이처럼 병목구간이 생겨 전체 시스템 성능에 영향을 미친다.

 

그래서 이처럼 다른 구간의 성능을 높이게 됐을 때 Latency 는 280ms 로 낮아지는 것에 반해 Throughput 은 여전히 500TPS 이다. 이러한 병목현상이 발생해 전체 시스템의 성능에 큰 영향을 미치는 구간을 Critical Path 라고 한다.

 

결국, 시스템 전체의 Throughput 을 향상시키기 위해서는 병목현상이 발생하는 Critical Path 를 찾아야 한다.

 

이처럼 병목현상이 발생하는 Critical Path 를 찾아서 성능향상을 시킨다면 전체 시스템의 Throughput 이 1000TPS 로 증가하게 된다. 하지만 Critical Path 는 없어지는 것이 아니라 다른 구간으로 이동하게 된다. 모든 구간의 Throughput 이 동일하지 않다면 항상 병목현상이 발생하기 때문이다.

 

이와 다르게 Latency 는 각 구간의 성능향상이 전체 시스템의 성능에 영향을 미친다. 전체 시스템의 Latency 는 각 구간의 Latency 의 합이기 때문에 당연한 결과이다.

TPS 에 대해서

---

위에서도 소개했지만 TPS 는 Transaction per second 의 약자로 초당 처리할 수 있는 Transaction 의 수를 의미한다. 즉, 처리량을 나타내는 성능지표이다.

 

위 그래프에서 보듯이 서비스를 이용하는 사용자가 증가하면 TPS 는 지속적으로 늘어난다. 하지만 어느 시점이 되면 아무리 사용자가 늘어나더라도 TPS 는 더 이상 늘어나지 않게 된다. 이러한 지점을 Saturation Point(포화지점)이라고 한다.

 

이러한 상황은 잘못된 것이 아니라 오히려 이상적인상황이다. 제대로 튜닝이 되지 않은 서비스에서는 포화지점을 지나면 오히려 TPS 가 떨어지기도 한다.

 

그러면 포화지점에서 더 이상 TPS 가 증가하지 않는 것은 무슨 의미를 가질까?

초당 처리할 수 있는 Transaction 의 수가 한계에 도달했고 그때부터 사용자가 증가하면 Latency 시간이 증가한다.

 

이러한 포화지점이 중요한 이유는 여기를 기준으로 해당 서버가 감당할 수 있는 부하의 한계를 정의할 수 있기 때문이다.

nGrinder

---

nGrinder 는 스트레스 테스트 도구로 네이버에 의해서 개발된 오픈소스이다.

유명한 성능 테스트 도구로 Apache 의 JMeter 가 있지만 나는 팀장님의 권유로 nGrinder 를 사용해보았다.

 

nGrinder 의 구성요소에 대해서 살펴보자.

구성	설명
Controller	웹 기반의 GUI 시스템으로 테스트 전반적인 작업이 이 Controller 에 의해서 작동한다.
Agent	Controller 의 명령어를 받아 Target 머신에 프로세스와 스레드를 실행시켜 부하를 발생시킨다. 복수의 머신에 설치되어서 Controller 의 신호에 따라서 일시에 부하를 발생시킨다.
Target	테스트를 하기위한 타겟 머신이다. 즉, 테스트를 하려는 서버가 Target 이다.

 

nGrinder 는 Java 베이스로 동작하기 때문에 Oracle JDK 1.6 이상이 설치되어 있어야 한다.

https://github.com/naver/ngrinder/releases  에서 Controller 파일을 다운로드 받을 수 있다.

'

이렇게 다운로드 받은 Controller 는 두 가지 방법으로 실행할 수 있다. 첫 번째 방법은 Docker 를 이용한 방법이고 두 번째 방법은 WAR 파일을 다운로드 받아 로컬환경에 직접 구동하는 방법이다.

 

먼저 Docker 를 이용한 방법을 살펴보자. docker-compose 파일은 다음과 같다.

version: '3'
services:
  ngrinder-controller:
    image: ngrinder/controller:3.5.5-p1
    container_name: ngrinder-controller
    ports:
      - "80:80"
      - "16001:16001"
      - "12000-12009:12000-12009"
    volumes:
      - ./ngrinder/controller:/opt/ngrinder-controller
 
  ngrinder-agent:
    container_name: ngrinder-agent-1
    image: ngrinder/agent:3.4
    command: ["ngrinder-controller:80"]

위 docker-compose 파일을 이용해 컨테이너를 띄우고 http://localhost:80 으로 접속하면 nGrinder 초기화면이 나온다.

 

두 번째로 로컬환경에 직접 구동하는 방법인데, 위 링크에서 Controller 파일중 WAR 파일을 받고 아래 명령어를 실행하면 된다.

java -XX:MaxPermSize=200m -jar ngrinder-controller-3.5.5-p1.war -p 7777

 

 

 

초기화면은 위와같고 기본적으로 설정되어있는 ID/Password 는 admin/admin 이다.

 

 

 

로그인을하고 메뉴를 보면 Download Agent 가 있는데 해당 메뉴를 통해 Agent 파일을 다운로드받아 Agent 역할을 할 PC 에 실행시키면 된다. 이후 Agent Management 메뉴에서 인식된 Agent 의 목록을 확인할 수 있다.

 

 

 

이제 성능테스트를 진행할 수 있는데 기본적으로 Script 를 작성해 요청할 API 와 파라미터 등을 설정할 수 있다. 물론 이렇게 추가된 Script 는 groovy 로 작성되어 있어 직접 수정할수도 있다.

 

이렇게 Script 를 통해 테스트를 진행할 API 를 설정했으면 vUser 수, 테스트 시간, Ramp-Up 등의 설정을 하고 테스트를 진행하면 된다. 나같은 경우엔 vUser 를 1, 10, 20, 30, 40, 50, 70, 99 로 늘려가며 테스트를 진행했고, 서버에 갑작스런 부하가 가지 않도록 Ramp-Up 을 설정한 후에 진행했다.

 

 

내가 진행한 성능테스트 결과중 하나이다. 아래 포스팅에서 소개한 EhCache 내부호출 문제를 개선한 후 성능 테스트를 진행한 것이고 확인할 수 있듯이 약 30프로 정도의 성능향상이 이루어진 것을 볼 수 있다.

 

https://ch4njun.tistory.com/265

[Spring Boot] EhCache Self-Invocation 문제

 

아쉬웠던 점은 groovy 를 이용해 테스트 Script 를 자유롭게 커스터마이징할 수 있는 것이 nGrinder 의 큰 장점이라고 하는데 groovy 의 문법도 모르고 기본적인 테스트만 진행해 이 부분을 활용하지 못한 점이다.

 

다음에 공부를 더 해서 상황에 맞게 이러한 장점을 활용해보고 싶다.