사이드 프로젝트 내 부하테스트 & 시각화 기술 선정기 (with k6, nGrinder, Grafana)

현재 지인 분들과 티케팅 사이트 프로젝트를 진행 중이다.

GitHub - Tiketeer/Tiketeer-BE

해당 프로젝트의 메인 주제는 바로 '동시성 이슈 핸들링'인데, 이를 위해 부하 테스트를 진행할 계획이 있다.

이를 위해, 해당 글에서는 여러 부하 테스트 툴 중 어떤 것을 선택할지 고민한 과정과 최종적으로 선택하게 된 툴에 대해 소개하고자 한다.

 

테스팅 툴 선정 시 고려 사항

먼저 테스팅 툴 선정 시 고려한 사항들은 다음과 같다.

1. 기본적인 부하테스트 시나리오 작성 가능성
2. 성능 (충분한 부하를 만들어 낼 수 있는가)
3. Docker(Compose)를 통한 자동 환경 구성의 가능성
4. 관련 레퍼런스
5. Grafana와의 연동성

고려될 방안들이 위 사항들을 모두 만족할 필요는 없으나 많이 만족할수록 가산점을 주었다.

Grafana는 왜?

부하테스트 툴을 선정하는데 Grafana와의 연동성은 불필요하지 않냐라고 할 수 있고, 타당한 의문이다.

다만 여기에서 Grafana까지 고려하는 것은 이후 프로젝트의 가시성을 위해 Grafana를 도입할 가능성을 고려하고 있고, 그렇게 될 경우 하나의 시각화 툴을 활용하여 부하 테스트 결과까지 확인이 가능해지는 것이기 때문이다.

따라서 일반적인 부하테스트 툴을 선정하기 위한 고려 사항은 아니지만 프로젝트의 방향성에 의해 고려되는 사항이라고 볼 수 있다.

 

방안 1. nGrinder

nGrinder

nGrinder는 네이버에서 개발한 오픈소스로, 부하테스트를 위한 방법론과 그 결과를 출력하는 시각화를 함께 동시에 제공하는 툴이다.

nGrinder는 개발자가 작성한 스크립트 기반으로 동작하게 되는데, Groovy, Jython(Python) 등이 이용 가능하여 기존 Java 혹은 Python으로 개발해왔던 개발자라면 무리 없이 스크립트를 작성할 수 있다.

실제로 아래 링크에는 nGrinder에서 직접 제공하는 login 테스트 용 예시 Groovy 코드가 있는데, 그냥 Java 코드라고 해도 무방한 수준이다.

ngrinder/script-sample/test-with-login/login.groovy at master · naver/ngrinder

nGrinder는 docker-compose를 통해 자동 환경 구성을 수행할 수 있다.

아래는 직접 작성한 docker-compose.yml 파일이다.

// docker-compose.yml
services:
  controller:
    image: ngrinder/controller:3.5.5
    restart: always
    ports:
      - 9000:80
      - 16001:16001
      - 12000-12009:12000-12009
    volumes:
      - ./ngrinder-controller:/opt/ngrinder-controller
  agent1:
    image: ngrinder/agent:3.5.5
    restart: always
    links:
      - controller
  agent2:
    image: ngrinder/agent:3.5.5
    restart: always
    links:
      - controller
  agent3:
    image: ngrinder/agent:3.5.5
    restart: always
    links:
      - controller
  agent4:
    image: ngrinder/agent:3.5.5
    restart: always
    links:
      - controller

공식 페이지 상에서 언급하는 현재 가용 버전은 3.5.5이기 때문에 버전을 위와 같이 맞춰주었고, 테스트에 활용할 agent의 수를 4로 맞춰주기 위해 agent들을 위와 같이 구성해주었다. 꼭 4개일 필요는 없으며, 하나 이상을 지정해주기만 하면 문제 없다.

위처럼 docker-compose.yml 파일을 작성한 뒤 docker-compose up -d 명령어를 실행시키면 얼마 뒤에 localhost:9000에 접속이 가능하다. (이 때 포트 번호는 설정하기 나름)

localhost:9000/login 접속화면

초기 ID, PW는 모두 admin이며, 실제 부하테스트를 실행하는 방법은 이미 훌륭한 한글 레퍼런스들이 많기 때문에 링크로 대체한다.

[Test] nGrinder을 이용한 성능테스트

직접 nGrinder를 사용해본 뒤 느낀 장점은 아래와 같다.

먼저 셋업이 간단하다. 필요한 의존성은 nGrinder가 끝이기 때문에, compose 파일을 통해 nGrinder를 실행시킨 뒤 사전에 작성한 or 신규 스크립트를 작성하기만 하면 테스트를 위한 준비가 끝이 난다.

또한 웹브라우저 UI 기반으로 동작하기 때문에 사용하기 쉽다는 장점이 있다. 

마지막으로 네이버의 오픈소스이다보니 한국어 레퍼런스가 꽤 많다는 점도 장점이 될 수 있을 것 같다.

다만 아쉬운 점도 있었다.

먼저 nGrinder는 로컬 환경 기준으로, 큰 규모의 부하를 만들어내기는 쉽지 않았다. 조금만 규모가 커져도 곧바로 메모리 부족으로 인해 테스트가 실패하곤 했었다. 좀 찾아보니 이건 자체 UI를 제공하는 툴들의 한계로도 볼 수 있는 문제인 것 같았다.

두번째는 시각화의 아쉬움이다. 다른 툴에 비해 nGrinder의 테스트 결과 시각화는 좀 아쉽다는 생각이 들었다.

nGrinder의 테스트 결과 창

마지막으로는 Grafana와의 연동이 쉽지 않았다. 물론 자체 시각화가 있기 때문에 불필요한 것은 맞지만 애초에 고려하기로 한 사안에는 맞지 않는 것이 사실이다.

 

방안 2. k6 + influxDB + Grafana

Load testing for engineering teams | Grafana k6

 

Grafana k6는 Javascript 기반으로 스크립트를 작성할 수 있는 부하테스트 툴이다.

더 나은 성능을 위해 웹브라우저 기반의 UI는 제공하지 않으며, 같은 이유로 Go 언어 기반으로 동작한다.

아래는 공식 홈페이지에서 제공하는 로그인 테스트 예시인데, js 지식이 있는 개발자라면 바로 이해할 수 있을 정도로 스크립트 작성에 있어 직관성을 가질 수 있다.

import http from 'k6/http'
import { check, sleep } from 'k6'

export default function () {
  const data = { username: 'username', password: 'password' }
  let res = http.post('https://myapi.com/login/', data)

  check(res, { 'success login': (r) => r.status === 200 })

  sleep(0.3)
}

k6는 자체 시각화를 제공하지 않기 때문에 테스트 결과를 다양한 곳에 내보낼 수 있고 이를 통해 다른 툴을 이용하여 시각화가 가능하다.

이 때 가장 많이 등장하는 세트가 바로 k6 + InfluxDB + Grafana이다.

k6에서 수행한 부하테스트 결과를 InfluxDB로 내보낸 뒤, Grafana에서 datasource 설정을 통해 InfluxDB에서 데이터를 읽어와 대시보드를 생성하는 플로우를 갖는다. 이렇게 만들어진 대시보드는 아래와 같은 형태를 갖는다.

출처: https://grafana.com/grafana/dashboards/2587-k6-load-testing-results/

이를 구성하는 방법 또한 레퍼런스들이 많기 때문에 링크로 대체한다.

Grafana k6으로 부하 테스트하고 시각화하기

해당 구성을 직접 사용해본 뒤 느낀점은 다음과 같다.

우선 로컬 기준으로 nGrinder와 비교했을 때, k6를 통한 부하테스트가 더 많은 vUser를 다룰 수 있었다. nGrinder에서 4개의 agent에 각각 200개의 vUser를 할당하여 테스트 해본 것이 최대인 반면, k6에서는 vUser가 1000인 상황에서도 너끈히 테스트가 가능했다.

또한 대시보드에 출력되는 데이터가 더 다채롭고 눈에 잘 들어온다는 장점이 있었다.

마지막으로 레퍼런스 또한 nGrinder 만큼은 아니라도, 공식 문서가 잘되어있어 어렵지 않게 테스트를 진행할 수 있었다.

하지만 아쉬운 점도 있었다.

이 구성에서는 필수적으로 개발자가 직접 수동으로 구성을 완료해주어야 한다는 것이다.

레퍼런스 대부분이 InfluxDB - Grafana 연동을 수동으로 진행하고 있었는데, 이는 너무 큰 소요라고 생각되어 자동화 방안을 리서치했다. Grafana의 Provisioning 기능을 통해 이를 달성하고자 했는데, 직접 해보고 알게 된 결론은 "불가능하다" 였다. 이게 불가능한 이유는 Grafana - InfluxDB를 연동하기 위해서는 InfluxDB 측에서 accessToken을 직접 발급 후 이를 Provisioning 파일에 추가해주어야 하는데, 이 과정에서 어쩔 수 없이 직접 InfluxDB를 만져야하는 소요가 있었기 때문이다.

결국 자동화가 불가능하기 때문에 해당 방안의 우선순위를 많이 낮출 수 밖에 없었다.

 

방안 3. k6 + Prometheus + Grafana

앞선 방안 2의 문제를 어떻게 해결할 수 있을까 고민하다가, InfluxDB 대신 Prometheus를 추가하는 구성이 있어서 이에 대해 추가적인 리서치를 진행했다. 이 구성에서 중요한 것은 결국 '어떤 툴로 부하테스트를 진행하느냐' 와 '어떤 툴로 시각화 하느냐' 이기 때문에 중간 다리 역할을 하는 InfluxDB가 Prometheus로 바뀌는 건 큰 문제가 없었다. 

그리고 내린 결론은 "자동화가 가능하다" 였다.

Grafana의 Provisioning을 통해 함께 띄울 Prometheus 컨테이너를 datasource로 사전에 등록해주고 이를 시각화할 dashboard만 구성해주면 되기 때문에 어렵지 않게 가능해 보였다. 

다만, 이에 대한 레퍼런스가 부족하여 직접 컴포즈 파일을 작성했다. 아래 링크에서 확인이 가능하다.

k6 + Prometheus + Grafana 자동 환경 구성하기 (with Docker-compose)

해당 방법을 통해 구성되는 대시보드는 아래와 같다.

이 방식은 k6를 사용했을 때 얻을 수 있는 성능적인 이점 뿐만 아니라, 컴포즈 파일을 통한 자동화도 가능했다.

다만 한가지 아쉬운 점은 InfluxDB를 통한 Grafana 대시보드에 비해 이 쪽이 조금 더 초라(?)하다는 점이다.

 

결론

위에서 고려한 방안들의 특징을 정리하면 아래와 같다.

	nGrinder	k6 + InfluxDB + Grafana	k6 + Prometheus + Grafana
테스트 시나리오 작성 용이성	Java와 유사한 Groovy를 통해 손쉽게 작성 가능	Js를 통해 쉽게 작성 가능	Js를 통해 쉽게 작성 가능
성능	k6와 비교하여 더 낮은 성능	nGrinder와 비교하여 더 나은 성능	nGrinder와 비교하여 더 나은 성능
Docker를 통한 자동 구성 가능성	컴포즈 파일을 통해 자동 환경 구성 가능	불가능 (InfluxDB - Grafana 연동에 있어 개발자가 개입해야 할 필요 존재)	컴포즈 파일을 통해 자동 환경 구성 가능
레퍼런스	한글 레퍼런스가 많음	공식문서, 해외 레퍼런스가 많음	공식문서, 해외 레퍼런스가 많음
Grafana 연동성	불가능	가능	가능

그리고 이러한 비교를 통해 최종적으로 

k6 + Prometheus + Grafana를 선택하였다.

가장 마음에 들었던 지점은 성능이 준수하면서도,

부하 테스트 과정을 docker-compose up 명령어 하나로 자동화할 수 있다는 점.