[부하 테스트] k6 설치 및 사용 방법

k6는 사용자인척 요청을 보내는 도구이다.

원래라면 사용자가 직접 서비스에 요청을 보내야 하는데, k6는 여러 명의 사용자를 대신해서 요청을 보내는 도구이다.

 

k6 설치(맥 기준)

맥에서 k6를 설치하는 방법은 매우 간단하다.

brew install k6

 

설치가 완료되고 k6를 입력하고 아래와 같은 화면이 나타났다면 정상적으로 설치된 것이다.

 

read: connection reset by peer
윈도우나 맥에서 k6를 사용하다보면 read: connection reset by peer 문제를 마주할 수 있다.
이는 MacOS에서 소켓에 제한을 걸어서 발생되는 문제이다.

이는 3가지 방법으로 파훼할 수 있다.

1. ulimit -n 명령어 사용

ulimit -n 65535​

소켓의 수를 임시적으로 65535개로 늘리는 명령어다.
이 명령은 현재 셸 세션에서만 일시적으로 유효하다.
터미널을 종료하거나 시스템을 재부팅하면 원래 기본값(예: 256 또는 1024 등)으로 돌아간다.

2. k6를 컨테이너화
k6를 도커를 통해서 컨테이너로 띄우면 해결이 된다.

compose.yml

version: "3.8" services:   k6:     image: grafana/k6:latest     container_name: k6-load-test     volumes:       - ./script.js:/scripts/script.js     command: run /scripts/script.js

3. AWS EC2 활용
EC2 인스턴스를 하나 생성해서 윈도우나 맥이 아닌 OS로 k6를 설치하면 된다.
아래는 우분투에서 k6를 설치하는 명령어이다.

$ sudo gpg -k && /
sudo gpg --no-default-keyring --keyring /usr/share/keyrings/k6-archive-keyring.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69 && /
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list && /
sudo apt-get update && /
sudo apt-get install k6​

 

부하 테스트 진행

주의점
1분 간격으로 기록되는 모니터링 도구를 가지고 정확하게 성능을 측정하려면 최소 5분간의 부하테스트는 진행해야 한다. 그래야 일관된 결과값을 얻을 수 있다.

데이터베이스는 데이터가 어떻게 저장되어 있는 지와 얼마나 많은 양이 저장되어 있는 지에 따라서 성능 차이가 많이 난다. 따라서 실제 프로덕션 환경과 비슷하게 데이터를 구성해두고 부하 테스트를 해야 보다 정확한 결과값을 얻을 수 있다.

프로덕션 환경에서 부하 테스트를 하면 안 된다. 왜냐하면 부하 테스트를 함으로써 실제 서비스의 성능에 악영향을 끼칠 수 있기 때문이다.

 

 

스크립트 작성

백엔드 서버에 부하를 주기 위해 k6 스크립트 작성

구성한 시스템이 1초당 몇 개의 요청을 견딜 수 있는 지 알아보려면, 점진적으로 트래픽을 늘려가게끔 부하 테스트를 셋팅해야 한다.

 

script.js

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  // 부하를 생성하는 단계(stages)를 설정
  stages: [
    // 10분에 걸쳐 vus(virtual users, 가상 유저수)가 6000에 도달하도록 설정
    { duration: '10m', target: 6000 }
  ],
};

export default function () {
  // API 주소로 GET 요청
  http.get('서버 주소');
  // 1초 휴식
  sleep(1);
}

 

부하 테스트 시작

K6_WEB_DASHBOARD=true k6 run script.js

 

 

k6 웹 대시보드 확인

• http://{k6가 실행되고 있는 호스트 주소}:5665

 

부하 테스트 결과 해석

• HTTP Request Rate : 1초당 처리한 요청 수를 의미한다. 즉, Throughput(처리량)을 나타내는 값이다.
• HTTP Request Duration : 요청에 대한 평균 응답 시간을 의미한다. 즉, Latency(지연 시간)을 나타내는 값이다.
• HTTP Request Failed : 1초당 요청 실패 수를 의미한다. 요청 실패가 발생한다면 어떤 문제로 인해 요청이 실패하는 지 체크해봐야 하는 신호이다.

 

VUs가 늘어나도 HTTP Request Rate가 더 이상 증가하지 않는 구간을 찾는다.

• 더 이상 증가하지 않는 HTTP Request Rate가 현재 시스템의 최대 Throughput이다.
• 초당 2,700개 정도의 요청을 처리하고 있다. 즉, 현재 시스템은 1초당 2,700개의 요청을 처리할 수 있다는 뜻이다.
• 이걸 보고 ‘현재 시스템의 최대 Throughput은 2,700 TPS’라고 표현한다.

 

HTTP Request Duration이 비이상적으로 높은 건 아닌지 체크한다.

• 요청 당 응답 시간(Latency)이 비이상적으로 높을 경우 문제가 있는 건 아닌 지 체크해봐야 한다.
• 여기서 ‘비이상적’의 기준은 정하기 나름이다. 특정 서비스에서 응답 시간이 1초가 넘어가는 순간 사용자 이탈률이 크게 증가한다면, 정상적인 응답 시간 기준을 1초로 잡으면 된다.

참고
VUs가 높아짐에 따라 서버가 처리할 수 있는 요청량이 밀려서 대기하는 시간이 늘어나기 때문에,
HTTP Request Rate(= Throughput)는 늘어나지 않는데 Request Duration(Latency)는 늘어나는 현상을 확인할 수 있다.

 

HTTP Request Failed가 있는 건 아닌지 체크한다.

• 만약 실패한 요청이 있다면 요청이 왜 실패했는 지 분석해야 한다.