k6

들어가며

부하테스트가 이번에 인프라공방을 수강하면서 제일 재미가 느껴지는 부분이다. 수업에서는 여러가지 테스트 툴을 안내해줬지만 미션은 k6로 진행하길 주문받았다. 강사님께서는 ‘시나리오 기반의 테스트’가 가능하다면 어떤 툴이든 상관이 없다고 하셨는데 k6로 선정이 되었다.

공식 document를 쭉 살펴보았는데, 정리가 무척 잘 되어 있었고 구독자 수도 적지만 공식 유투브 채널도 운영중이라서 좀 신뢰가 갔다. 그리고 git action과 연동도 가능해서 이제 개인 프로젝트는 배포 파이프라인을 git action을 이용할 계획이었던 나에게 적절한 테스트 툴이라는 생각이 들었다.

이번 포스팅에서는 공식 문서에 다 나와있는 설치나 개념과 같은 쓸데없는 것을 빼고 실제로 내가 사용한 것들을 정리하고자 한다.(사실 다른 포스팅들도 그런 맥락에서 정리를 하고 있긴 하다)

k6를 사용한 테스트는 아래와 같은 흐름으로 진행된다. 매우 간단하다.

• ㄱ) 시나리오와 목표에 기반하여 테스트 로직을 자바스크립트로 작성

• ㄴ) 작성된 자바스크립트를 CLI 혹은 k6 cloud 를 통해서 run

• ㄷ) 테스트 결과를 보며 시나리오에 따른 서버의 capacity 파악

그래서 k6를 사용하기 위해서는 ‘테스트를 위한 자바스크립트’를 어떻게 작성하는지 알고, 이를 어떻게 작동 시키는지 알고, k6가 테스트 결과로 주는 결과지가 각 항목이 무엇을 의미하는지만 이해하면 큰 틀에서 다 파악한거라고 생각한다. 정리도 이 항목대로 진행한다.

1. 테스트를 위한 자바스크립트 작성 방법

아래는 내가 실제로 사용한 테스트 스크립트 파일이다. 간단히 lending 페이지 방문에 대한 smoke test이다.

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

export let options = {
    vus: 1,
    duration: '10s',

    thresholds: {
        http_req_duration: ['p(99)<1500'],
    },
};

const BASE_URL = 'https://fistkim.kro.kr';

export default () => {

    // lending page
    let homeUrl = `${BASE_URL}`;
    let lendingPageResponse = http.get(homeUrl);
    check(lendingPageResponse, {
        'lending page running': (response) => response.status === 200
    });
};

모든 테스트 스크립트 파일은 export default function을 가지고 있으며, 이 함수가 테스트 동안 무한히 실행된다. 무한히 실행된다는 의미는 말 그대로 실행=>종료=>실행=>종료 된다는 의미이며 이 로직을 vus 각각이 병렬적으로 요청하게 된다.

option은 이 전체 테스트 스크립트 파일이 갖게되는 테스트에 대한 configuration과 같다. 현재 스크립트의 option을 해석하자면 아래와 같다.

• 가상의 사용자는 1명

• 10초 동안 진행

• 모든 요청의 99퍼센트 이상의 ‘소요시간’이 1500ms 이내에 들어야 한다

http_req_duration Total time for the request. It’s equal to http_req_sending + http_req_waiting + http_req_receiving (i.e. how long did the remote server take to process the request and respond, without the initial DNS lookup/connection times)

check는 해당 요청에 대해서 무엇인가를 확인할때 사용한다. 지금은 단지 http status code만을 확인했는데, 서버로부터 받아온 json 데이터 내에 원하는 값이 있는지 구체적으로 확인도 가능하다.

위 테스트 스크립트에서 그대로 option만 바꿔주면 load test, stress test가 가능하다. 아래는 load test, stress test의 option 예시이다.

load test

export let options = {
    stages: [
        { duration: '5s', target: 100 },
        { duration: '20s', target: 100 },
        { duration: '5s', target: 0 },
    ],

    thresholds: {
        http_req_duration: ['p(99)<1500'],
    },
};

stress test

export let options = {
    stages: [
        { duration: '5s', target: 100 },
        { duration: '10s', target: 100 },
        { duration: '5s', target: 200 },
        { duration: '10s', target: 200 },
        { duration: '5s', target: 300 },
        { duration: '10s', target: 300 },
        { duration: '5s', target: 0 },
    ],
    thresholds: {
        http_req_duration: ['p(99)<1500'],
    },
};

매우 간단하다. target이 vus의 수다. 이전 duration과 target이 일치하면, 그 가상의 인원 그대로로 정해진 duration동안 요청을 병렬적으로 계속 진행하겠다는 의미이다. 그리고 이전 duration에 비해서 target이 상승하거나 하락하면 변화량 만큼 정해진 duration동안 가상의 인원 수를 조정하겠다(상승 또는 하락)는 의미이다.

위 예시는 매우 간단한 lending page에 대한 테스트이지만, 시나리오를 세워서 ‘로그인을 하고 정보를 생성’하는 것도 얼마든지 가능하다. 아래 예시는 기존 계정정보로 로그인을 하고 로그인을 통해 가져온 토큰을 이용해 인증을 통과하여 원하는 object를 post 요청하는 예시이다.

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

export let options = {
    vus: 1,
    duration: '10s',

    thresholds: {
        http_req_duration: ['p(99)<1500'],
    },
};

const BASE_URL = 'https://fistkim.kro.kr';
const USERNAME = '[e-mail]';
const PASSWORD = '12qw';

export default () => {

    // login
    let loginUrl = `${BASE_URL}/login/token`;
    let loginPayload = JSON.stringify({
        email: USERNAME,
        password: PASSWORD,
    });
    let loginParams = {
        headers: {
            'Content-Type': 'application/json',
        },
    };
    let loginResponse = http.post(loginUrl, loginPayload, loginParams);
    check(loginResponse, {
        'logged in successfully': (response) => response.json('accessToken') !== '',
    });

    // create line
    let createLineUrl = `${BASE_URL}/lines`;
    let lineRandomNumber = Math.random().toString().split('.')[1];
    let createLinePayload = JSON.stringify({
        name: `testLine-${lineRandomNumber}`,
        color: "grey darken-4",
        upStationId: 1,
        downStationId: 2,
        distance: 10,
    });
    let createLineParams = {
        headers: {
            'Authorization': `Bearer ${loginResponse.json('accessToken')}`,
            'Content-Type': 'application/json',
        },
    };
    let createLinesResponse = http.post(createLineUrl, createLinePayload, createLineParams);
    check(createLinesResponse, {
        'created Line successfully': (response) => response.status === 201,
    });
};

k6 공식문서 를 참고하면 여러가지 다양하고 복잡한 시나리오 테스트가 가능하다.

2. 테스트 자바스크립트 작동 방법

1) k6를 설치해둔 상태에서 커맨드라인을 이용해서 준비해둔 .js 파일을 실행

$ k6 run smoke.js

2) k6 cloud를 이용해서 실행

js 파일별로 시각화해서 목록이 보여지고, 각 js 파일 마다 실행결과가 그래프로 보여진다

원하는 로직을 Configure 에 들어가서 작성한다

개별 테스트의 결과 역시 아주 보기좋게 그래프로 보여준다. 이건 내가 실제로 해본 stress test 이다

3) git action을 이용해서 실행

사용법은 여기 에서 알 수 있다. 아래는 내가 git action에 사용한 ci 로직이다. 부하테스트의 결과와 별개로 새로 작성한 코드의 도커 이미지가 push 되도록 의존성을 연결짓지 않았다.

  load_test:
    runs-on: ubuntu-latest
    needs: [ test, docker_image_build_and_push ]
    name: Run k6 test
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Run k6 local test
        uses: k6io/action@v0.1
        with:
          filename: ./test-script/lending/smoke.js

주의해야 할 것은 테스트의 결과에 무관하게 아래와 같이 성공한 것처럼 나온다는 것이다. 왜냐하면 테스트를 실행한 것 자체는 성공했고, 테스트가 내용적으로 시나리오에 따라 시행 되었을때 실패했는지 성공했는지, 절반정도 성공했는지는 git action 입장에서는 상관이 크게 없기 때문이다.

반면에 테스트를 실행하는 것 자체가 실패하면 아래와 같이 실패하였다는 것이 보이고, 메일로 알람까지 받을 수 있다. 아래 케이스는 내가 .js파일의 경로를 잘못설정해서 아예 k6 test를 실행하지도 못한 경우이다.

3. k6 테스트 결과 분석

CLI를 통해서 테스트를 수행하면 아래와 같은 metrics를 얻을 수 있다.

각각의 항목에 대한 설명은 공식문서 에 자세하게 나와있는데, 공식문서를 보지 않고 지표들의 이름만 봐도 대략적으로 내용을 알 수 있긴 하다. 나중에 실무에 내가 적용한다면 중요하게 볼 것 같은 지표는 http_req_duration과 http_reqs이다. http_req_duration을 통해서는 평균적으로 한번의 요청당 얼마만큼의 시간이 소요되었는지 알 수 있고, http_reqs를 통해서는 평균적인 처리 속도를 지표화 해서 목표와의 갭을 확인할 수 있기 때문이다.

주의 해야할 점은 http_reqs는 총 request 갯수라는 사실이다. ‘로그인->회원가입’ 시나리오를 한번 실행하면 http_reqs는 2 이다.

이 부분에 관해서는 부하테스트 포스팅에도 써두었지만 내 기준에 정말 완벽히 설명된 블로그를 찾아서 여기도 덧붙인다.

결국 서버의 성능 목표는 Throughput 과 Latency 를 기준으로 결정해야하는데, 이 내용에 관해서 친절히 설명된 블로그 를 찾았다. 성능 개선에 대한 포인트까지 잘 설명되어 있어서 정말 많은 도움이 되었다.