[K6] K6 를 시작하기 전 알아두면 좋은 점

 

 

k6 는 Grafana 사에서 제공되는 퍼포먼스 테스트 툴입니다. k6 를 이용하면 마치 여러 명의 유저가 있는 것처럼 애플리케이션 퍼포먼스 테스트를 진행할 수 있습니다.

 

Smoke Test, Load Test, Stress Test 등 다양한 테스트를 쉽게 진행할 수 있도록 도와줍니다.

 

그리고 자바스크립트로 제공되기 때문에 어렵지 않게 테스트 시나리오를 작성할 수도 있죠.

 

아래는 아주 간단한 k6 스크립트입니다.

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

export const options = {
    vus: 10,
    duration: "10s",

}

export default function() {
    http.get('http://test.k6.io');
    sleep(1)
}

 

k6 run 명령어로 실행하면 아래와 같은 테스트 메트릭을 얻을 수 있습니다.

k6 메트릭

이번 글에서는 "k6 를 시작하기 전에 알아두면 좋은 점" 을 다루기 때문에 코드에 대한 설명은 추후 글에서 다루도록 하겠습니다.

 

이렇듯 쉽게 퍼포먼스 테스트가 가능한 것이 k6 의 큰 장점입니다. 

 

예를 들어 쿠버네티스에 애플리케이션 파드를 배포한다고 가정했을때, 파드의 resources 를 지정해줘야 하는데 어느 정도 값을 줘야 하는 지 모를때가 있습니다. 이때 k6 의 Load Test 를 진행하면 보다 수월하게 값을 지정할 수 있습니다.

 

이번 글에서는 k6 를 직접 다루기 보단, k6 를 시작하기 전에 알아두면 좋은 점에 대해 말해보고자 합니다.

 

그럼 렛츠두더코드~

 

 

주요 성능 지표

---

 

퍼포먼스 테스트의 결과를 분석 할때, 반드시 알아야 할 주요 성능 지표가 있습니다.

 

Latency(지연시간), Throughput(처리량), Iterations(반복) 입니다.

 

이 3가지 지표는 "식당"에 비유하면 쉽게 이해할 수 있습니다.

 

Latency

먼저 Latency(지연시간) 입니다.

 

고객이 배달 앱을 통해 식당에 음식을 주문하고 문 앞까지 도착하는 시간에 비유할 수 있습니다.

 

주문하는데 1분이 걸렸고, 요리하는데 10분, 배달 오는데 10분 총 21 분이 소요되었습니다. 이때는 21 분의 지연시간이 걸렸다고 할 수 있습니다.

Latency

 

이렇듯 인터넷에서 요청을 보내고 응답을 받기 전까지를 측정한 지표가 Latency 입니다.

 

당연한 얘기지만, Latency 가 낮아야 고객이 더 빨리 음식을 먹을 수가 있습니다. 식은 치킨보다 따뜻한 치킨이 훨씬 맛있는 법이죠. Latency 가 높다면 고객은 기다리는데 지쳐버릴 것이고, 결코 좋은 기억이 될 수 없을 것입니다.

 

 

Throuput

Throuput(처리량) 입니다.

 

이번엔 한 식당에 100 명의 고객이 웨이팅하고 있다고 가정해보겠습니다. Throuput 은 식당이 1시간 동안 100 명의 고객에게 음식을 대접할 수 있는지에 비유할 수 있습니다.

 

Throuput

 

식당이 높은 Throuput 을 가졌다면, 1시간 동안 100 명의 고객에게 모두 음식을 대접할 수 있을 것이고, 낮은 Throuput 을 가졌다면 고객들은 더 많은 시간을 기다려야 할 것입니다.

 

당연히 높은 Throuput 을 가져야 고객들에게 좋은 인상을 남겨줄 수 있죠.

 

 

Iterations

Iterations(반복) 입니다.

Iterations

 

"A 고객이 음식을 주문하고, 식당은 음식을 조리하고, 고객에게 음식을 제공합니다."

"B 고객이 음식을 주문하고, 식당은 음식을 조리하고, 고객에게 음식을 제공합니다."

"C 고객이 음식을 주문하고, 식당은 음식을 조리하고, 고객에게 음식을 제공합니다."

 

이렇듯 같은 행위를 얼마만큼 안정적으로 반복할 수 있는지를 테스트하는 지표가 Iterations 입니다.

 

 

주의할 점

---

 

k6 는 가상 유저를 만들어 애플리케이션에 원하는 요청을 반복적으로 보내게 됩니다.

 

위에서 사용한 코드를 보면,

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

export const options = {
    vus: 10,
    duration: "10s",

}

export default function() {
    http.get('http://test.k6.io');
    sleep(1)
}

 

10명의 가상 유저가 10s 동안 http://test.k6.io 을 호출합니다. 

나중에 다루겠지만, 1명의 가상 유저가 한번만 default function 을 호출하는 것이 아닌, 10초 동안 해당 함수를 계속 호출합니다.
즉, default function 을 1명씩 1번 호출해서 총 10번 호출하는 것이 아닌, 1명의 가상유저가 5~10번 정도 호출합니다. 

 

k6 를 사용한다는 것은 지속적으로 애플리케이션에 부하를 주는 것이니 마음대로 아무 애플리케이션을 호출했다간 끔찍?한 일이 발생할 수도 있습니다.

 

따라서 k6 를 수행하기 전에는 다음과 같은 주의할 점이 있습니다.

• 본인 소유의 애플리케이션이 아닌 경우 테스트하지 않기
• 본인 소유 애플리케이션이라도 테스트를 해도 되는 상황인지 확인하기
• Production 환경이 아닌 Dev 또는 Staging 환경에서 진행하기
• 성능을 분석할 때, 절대 평균값으로 판단하지 않기 (이유는 바로 밑에서 다룸)
• 클라우드 환경을 이용한다면, k6 를 테스트할 때 Scale Up, Out 에 주의하기 

 

p(90) 과 p(95) 의 의미

---

 

아래 이미지는 k6 를 사용해서 퍼포먼스 테스트 결과를 얻은 화면입니다.

성능 지표

 

avg, min, med, max 은 확눈에 무슨 값을 의미하는지 알 수 있습니다. 그런데 p(90) 과 p(95) 는 무엇을 의미하는 지 대충은 알 것 같은데.. 정확한 감은 오지 않습니다.

 

p 는 percentile 을 의미하고 뒤에 90, 95 는 각각 90%, 95% 를 의미합니다.

 

즉, p(90) 은 "90%의 요청이 주어진 지연보다 빠르거나 동일한 시간 안에 완료된다는 것을 의미" 하고, p(95) 는 "95%의 요청이 주어진 지연보다 빠르거나 동일한 시간 안에 완료된다는 것을 의미"합니다.

 

보다 쉬운 이해를 위해 성능 지표에 나온 것을 분석해보죠.

성능 지표

 

http_req_duration 은 요청 -> 응답 까지 얼마나 걸렸는지를 나타내는 지표입니다.

 

여기서 p(90) = 439.21ms 는 90% 이상의 요청은 439.21ms 내에 성공적으로 이루어졌고, p(95) = 783.98ms 는 95% 이상의 요청은 783.98ms 내에 성공적으로 이루어 진 것으로 볼 수 있습니다.

 

그럼 왜 이 지표가 중요한걸까요? 왜 하필 90과 95 일까요? 100은 안되는 걸까요?

 

식당에서 500 명의 고객들이 햄버거를 주문했다고 가정해봅시다.

햄버거 주문

 

80% 인 400 명은 20초 안에 햄버거를 받았고, 20% 인 100 명은 햄버거를 받기까지 10분 이상이 걸렸습니다.

 

이때 평균적으로 한 고객이 햄버거를 받기까지 약 4분이 소요됩니다.

 

대부분의 사람들이 20초 내에 햄버거를 받았음에도 불구하고 평균 시간은 4분으로 측정되기 때문에 햄버거를 받기까지의 시간이 오래걸린다고 생각할 수 있습니다. 

 

이렇듯 평균은 실제로 전체 성능을 말해주기엔 함정이 있습니다.

 

따라서 퍼포먼스 측정을 진행 할 때는 평균을 보는 것에 주의를 주어야 하며, 평균보다는 p(90) 과 p(95) 가 더 중요합니다.

 

이번엔 100만 건의 요청을 보냈을 때, 모든 요청은 1초 내에 이루어져야 하는데, 딱 하나의 요청만이 1분이 걸렸다고 가정해봅시다.

100 만 건의 요청

 

과연 이 행위는 실패한 것일까요? 성공할 것일까요? 일반적인 관점에서는 실패로 볼 수 있지만, Service Level Objective(SLO) 관점에서 바라보면 성공입니다. 왜냐 SLO 에서 100% 는 있을 수 없기 때문이죠.

 

AWS S3 서비스만 봐도 99.999999999%의 내구성과 99.99%의 가용성을 제공한다고 합니다. 100% 는 있을 수 없죠.

100% 가용성을 제공해주는 서비스를 발견한다면 댓글로 남겨주세요!

 

그래서 보통 "90%의 응답은 요청을 받은 후 0.5초 사이에 있다." 라고 말합니다. 적당한 합의를 본 것이죠.

 

우리가 제어할 수 없는 몇 가지 일에 의해 발생하는 사건에 대해서는 신경쓰지 않는 것이 속편합니다.

 

SLO 관점으로 보았을 때 90% 과 95% 의 수치가 가장 보편적이기 때문에 k6 에서는 p(90) 과 p(95) 를 보여줍니다.

 

오늘은 이렇게 k6 를 시작하기 전 알아두면 좋은 점을 알아봤습니다. 다음 글에서는 본격적으로 k6 를 통해 Smoke, Load, Stress Test 등 다양한 퍼포먼스 테스트를 진행해보도록 하겠습니다.

 

그럼 오늘은 여기까지!