Thanawat Wongchai

Posted on Jun 25 • Originally published at apidog.com

k6 การทดสอบโหลด API: คู่มือฉบับปฏิบัติ

หาก API ของคุณทำงานได้ดีเมื่อมีผู้ใช้คนเดียว แต่เริ่มช้า ล้มเหลว หรือ timeout เมื่อมีทราฟฟิกเพิ่มขึ้น คุณควรเพิ่มการทดสอบโหลดเข้าไปใน workflow ของทีม k6 เป็นเครื่องมือที่เหมาะสำหรับงานนี้ เพราะเขียนสคริปต์ด้วย JavaScript รันง่าย และใช้กำหนด performance threshold ใน CI ได้ บทความนี้พาคุณติดตั้ง k6 เขียนสคริปต์แรก ตั้งค่า VUs/stages/thresholds อ่านผลลัพธ์ และวาง k6 ร่วมกับการทดสอบประสิทธิภาพ API และการทดสอบฟังก์ชันใน pipeline โดยอ้างอิงจากเอกสาร k6 อย่างเป็นทางการในส่วนสำคัญ

ลองใช้ Apidog วันนี้

k6 คืออะไร?

k6 เป็นเครื่องมือทดสอบโหลดแบบโอเพนซอร์ส ที่ดูแลโดย Grafana คุณเขียน test script เป็น JavaScript และ k6 จะใช้เอนจิน Go ในการสร้างโหลดจริงไปยัง API endpoint ของคุณ

แนวคิดหลักคือ:

คุณเขียน scenario ด้วยภาษาที่นักพัฒนาคุ้นเคย
k6 รันโหลดด้วย runtime ที่เร็วและเบา
ผลลัพธ์แสดง latency percentile, request rate, error rate และ threshold pass/fail
เหมาะสำหรับวัดว่า API ยังเร็วและเสถียรภายใต้ทราฟฟิกหรือไม่

k6 ไม่ใช่ API client, documentation tool หรือ functional testing framework โดยตรง หน้าที่หลักของมันคือสร้างโหลดที่ทำซ้ำได้และวัดพฤติกรรมของระบบภายใต้โหลดนั้น

คำศัพท์ที่ควรรู้ก่อนเริ่ม:

คำศัพท์	ความหมาย
VU หรือ Virtual User	ผู้ใช้จำลองที่รันสคริปต์ซ้ำ ๆ
Iteration	การรันฟังก์ชันทดสอบครบหนึ่งรอบ
Stage	ช่วงเวลาในการเพิ่ม/ลดจำนวน VU
Threshold	เงื่อนไข pass/fail เช่น `p(95)<500`
Check	assertion แบบไม่หยุดการทดสอบ เช่น status ต้องเป็น 200

การติดตั้ง k6

k6 เป็น binary เดี่ยว ติดตั้งได้รวดเร็ว

บน macOS:

brew install k6

บน Windows ด้วย Chocolatey:

choco install k6

บน Debian หรือ Ubuntu:

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

ตรวจสอบว่า k6 พร้อมใช้งาน:

k6 version

หากไม่ต้องการติดตั้งบนเครื่อง สามารถใช้ Docker image ได้เช่นกัน ควรตรวจสอบคำสั่งล่าสุดจากเอกสาร k6 เพราะรายละเอียด package อาจเปลี่ยนตามเวลา

เขียนสคริปต์ k6 แรก

การทดสอบ k6 คือไฟล์ JavaScript ที่ export default function ออกมา k6 จะเรียกฟังก์ชันนี้ซ้ำตามจำนวน VU และ iteration

สร้างไฟล์ script.js:

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

export default function () {
  const res = http.get('https://test-api.example.com/users');

  check(res, {
    'status is 200': (r) => r.status === 200,
    'body is not empty': (r) => r.body.length > 0,
  });

  sleep(1);
}

รันสคริปต์:

k6 run script.js

ในตัวอย่างนี้:

http.get() ส่ง request ไปยัง API
check() ตรวจ response แบบไม่หยุดการทดสอบ
sleep(1) พัก 1 วินาทีระหว่าง iteration เพื่อจำลองพฤติกรรมผู้ใช้จริง

ถ้าไม่ใส่ sleep() แต่ละ VU จะยิง request ให้เร็วที่สุดเท่าที่ทำได้ ซึ่งเหมาะกับ throughput test บางกรณี แต่ไม่สมจริงสำหรับ user behavior ทั่วไป

ตั้งค่า VUs, stages และ thresholds

สคริปต์แรกจะรันแบบง่ายมาก หากต้องการ load test จริง ให้เพิ่ม options

กำหนดจำนวน VU และระยะเวลา

export const options = {
  vus: 50,
  duration: '30s',
};

ตัวอย่างนี้หมายถึงรันผู้ใช้เสมือน 50 คน เป็นเวลา 30 วินาที

ใช้ stages เพื่อจำลอง traffic profile

export const options = {
  stages: [
    { duration: '1m', target: 100 }, // ramp up to 100 VUs
    { duration: '3m', target: 100 }, // hold at 100 VUs
    { duration: '1m', target: 0 },   // ramp down to 0
  ],
};

stages ช่วยจำลองรูปแบบโหลดที่ใกล้เคียง production มากกว่า เช่น ค่อย ๆ เพิ่มโหลด คงโหลดไว้ แล้วลดโหลดลง

เพิ่ม thresholds สำหรับ CI

export const options = {
  stages: [
    { duration: '1m', target: 100 },
    { duration: '3m', target: 100 },
    { duration: '1m', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
  },
};

thresholds ในตัวอย่างนี้หมายถึง:

95% ของ request ต้องใช้เวลาน้อยกว่า 500 ms
request ที่ล้มเหลวต้องน้อยกว่า 1%

ถ้า threshold ไม่ผ่าน k6 จะ exit ด้วย non-zero code ทำให้ CI pipeline fail ได้ทันที นี่คือวิธีเปลี่ยน performance budget ให้เป็นโค้ด

เลือก load profile ให้เหมาะกับคำถาม

โปรไฟล์	เป้าหมาย	ใช้ตอบคำถาม
Smoke	โหลดน้อย ตรวจว่าสคริปต์ทำงานได้	test script ถูกต้องหรือไม่
Load	ทราฟฟิกปกติที่คาดไว้	API รองรับการใช้งานประจำวันได้หรือไม่
Stress	โหลดเกินระดับสูงสุดที่คาดไว้	ระบบเริ่มพังตรงไหน
Spike	เพิ่ม VU อย่างรวดเร็ว	ระบบรับ traffic spike ได้หรือไม่
Soak	โหลดปานกลางเป็นเวลาหลายชั่วโมง	มี memory leak หรือ degradation ระยะยาวหรือไม่

เริ่มจาก smoke test และ load test ก่อน จากนั้นค่อยเพิ่ม stress, spike หรือ soak เมื่อคุณมี baseline แล้ว หากต้องการภาพรวมแนวคิดและเมตริกเพิ่มเติม อ่านพื้นฐานการทดสอบประสิทธิภาพ

ตัวอย่างสคริปต์ load test ที่ใช้งานได้จริง

ตัวอย่างนี้รวม options, request, check และ threshold ไว้ในไฟล์เดียว:

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

export const options = {
  stages: [
    { duration: '30s', target: 20 },
    { duration: '1m', target: 20 },
    { duration: '30s', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
    checks: ['rate>0.99'],
  },
};

export default function () {
  const res = http.get('https://test-api.example.com/users');

  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 500ms': (r) => r.timings.duration < 500,
    'has response body': (r) => r.body && r.body.length > 0,
  });

  sleep(1);
}

รัน:

k6 run script.js

ใช้รูปแบบนี้เป็นจุดเริ่มต้น แล้วค่อยเปลี่ยน endpoint, payload, authentication และ thresholds ให้ตรงกับ API จริงของคุณ

การอ่านผลลัพธ์ k6

เมื่อ test run จบ k6 จะพิมพ์ summary ใน terminal เมตริกที่ควรดูเป็นพิเศษคือ:

เมตริก	ความหมาย
`http_req_duration`	เวลารวมของ request แสดง avg, min, max, median, p90, p95
`http_req_failed`	อัตรา request ที่ล้มเหลว
`http_reqs`	จำนวน request ทั้งหมดและ request ต่อวินาที
`iterations`	จำนวนรอบที่รันสำเร็จ
`vus`, `vus_max`	จำนวน VU ที่ใช้งานและค่าสูงสุด
`checks`	อัตราการผ่านของ `check()`

ให้โฟกัส percentile มากกว่าค่าเฉลี่ย เช่น ค่าเฉลี่ย 200 ms อาจดูดี แต่ถ้า p99 อยู่ที่ 4 วินาที หมายความว่าผู้ใช้บางส่วนยังเจอประสบการณ์ที่แย่มาก

ตัวอย่าง threshold ที่ควรเริ่มใช้:

thresholds: {
  http_req_duration: ['p(95)<500', 'p(99)<1000'],
  http_req_failed: ['rate<0.01'],
}

สำหรับการรันครั้งเดียว summary ใน terminal มักเพียงพอ แต่ถ้าต้องการวิเคราะห์ต่อเนื่อง k6 สามารถ export เป็น JSON/CSV หรือส่ง metrics ไปยัง Grafana และ Prometheus เพื่อทำ dashboard ได้

รัน k6 ใน CI/CD

เพราะ k6 exit ด้วย non-zero code เมื่อ threshold fail คุณจึงใส่ k6 เป็น step ใน CI ได้ตรงไปตรงมา

ตัวอย่าง GitHub Actions แบบพื้นฐาน:

name: k6-load-test

on:
  workflow_dispatch:

jobs:
  load-test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install k6
        run: |
          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

      - name: Run k6
        run: k6 run script.js

แนวทางที่แนะนำ:

รันกับ staging environment ไม่ใช่ production โดยตรง
เริ่มจาก smoke/load test ใน CI
ใช้ stress/spike test แบบ scheduled หรือก่อน release
ตั้ง threshold ให้สะท้อน SLO หรือ performance budget จริงของทีม

k6 เหมาะกับอะไร และ Apidog เหมาะกับอะไร

k6 ตอบคำถามว่า:

API ยังเร็วและเสถียรหรือไม่เมื่อมีทราฟฟิกต่อเนื่อง?

แต่ k6 ไม่ได้ออกแบบมาเพื่อยืนยันว่า API ส่งข้อมูลถูกต้องตาม contract หรือ authentication ทำงานครบทุก endpoint งานเหล่านั้นเหมาะกับ functional testing และ contract testing มากกว่า

ข้อกังวล	เครื่องมือที่เหมาะ	คำถามที่ตอบได้
โหลดหนักต่อเนื่องและ latency percentile	k6	API ยังเร็วภายใต้โหลดหรือไม่
ความถูกต้องของ response, contract, authentication	Apidog	API คืนค่าถูกต้องหรือไม่
regression test ทุก commit	Apidog CLI (`apidog run`)	commit นี้ทำ endpoint พังหรือไม่
performance budget ใน CI	k6 thresholds	latency หรือ error rate เกินขีดจำกัดหรือไม่

Apidog ใช้สำหรับด้านความถูกต้องของ API คุณสามารถออกแบบหรือนำเข้า API, สร้าง test scenario ด้วย visual assertions และรันใน CI ด้วย apidog run ได้ คู่มือApidog CLI อธิบายวิธีผูก functional test เข้ากับ pipeline

Apidog ยังมีความสามารถด้านการทดสอบประสิทธิภาพแบบเบาสำหรับ quick check ซึ่งดูได้จากบทความการทดสอบประสิทธิภาพ API ใน Apidog แต่ไม่ได้แทนที่ load generator เฉพาะทางอย่าง k6

workflow ที่ใช้งานได้จริงคือ:

ทุก commit: รัน functional/contract test ด้วย Apidog
ก่อน release หรือแบบ scheduled: รัน k6 load test กับ staging
ให้ CI fail เมื่อ functional test หรือ performance threshold ไม่ผ่าน

หากกำลังเปรียบเทียบเครื่องมือ load testing เพิ่มเติม k6 มักถูกเทียบกับ JMeter, Gatling และ Locust อ่านต่อได้ที่สรุปเครื่องมือทดสอบโหลด และการเปรียบเทียบทางเลือกของ Locust

คำถามที่พบบ่อย

k6 ฟรีหรือไม่?

ฟรี k6 เป็นโอเพนซอร์สภายใต้ใบอนุญาต AGPL และสามารถรัน local ได้โดยไม่มีข้อจำกัดด้านจำนวน VU นอกจากทรัพยากรเครื่องของคุณเอง Grafana ยังมี k6 Cloud ซึ่งเป็นบริการแบบชำระเงินสำหรับ distributed load test และการจัดเก็บผลลัพธ์ แต่ไม่จำเป็นสำหรับการเริ่มต้น หากต้องการดูตัวเลือกอื่น อ่านภาพรวมเครื่องมือทดสอบโหลด

ต้องรู้ JavaScript มากแค่ไหนถึงใช้ k6 ได้?

ต้องรู้พื้นฐาน JavaScript ก็เพียงพอ สคริปต์ k6 ส่วนใหญ่ประกอบด้วย:

export default function
http.get() หรือ http.post()
check()
options
thresholds

ไม่มี build step และไม่ต้องเรียน framework เพิ่มเติม

k6 ต่างจาก Apidog อย่างไรในการทดสอบประสิทธิภาพ?

k6 เป็น load generator ที่สร้างทราฟฟิกหนักต่อเนื่องและรายงาน percentile ในระดับใหญ่ เหมาะกับ load test, stress test, spike test และ performance threshold ใน CI

Apidog เป็นแพลตฟอร์ม API สำหรับออกแบบ ทดสอบฟังก์ชัน ตรวจ contract ทำ mock และสร้างเอกสาร API โดยมี performance check แบบเบาสำหรับการตรวจเร็ว ๆ ใช้ Apidog เพื่อยืนยันว่า API ทำงานถูกต้อง และใช้ k6 เพื่อยืนยันว่า API ยังทำงานได้ดีภายใต้โหลด

ควรรัน k6 ใน CI/CD หรือไม่?

ควรรัน โดยเฉพาะกับ staging environment ตั้ง threshold เช่น p95 latency และ error rate แล้วให้ pipeline fail เมื่อเกินขีดจำกัด ตัวอย่างคำสั่งพื้นฐานคือ:

k6 run script.js

จับคู่กับ functional test เช่น:

apidog run

เพื่อให้ pipeline ตรวจทั้งความถูกต้องและประสิทธิภาพ

บทสรุป

k6 เป็นวิธีที่ตรงไปตรงมาในการสร้างโหลดจริงบน API: ติดตั้ง binary, เขียน JavaScript script, กำหนด VUs/stages, เพิ่ม thresholds แล้วอ่าน percentile จากผลลัพธ์ ใช้ k6 สำหรับคำถามด้าน performance และใช้ functional/contract testing สำหรับคำถามด้านความถูกต้อง

สำหรับด้านความถูกต้องของ API Apidog ช่วยให้คุณออกแบบ ทดสอบ mock และจัดทำเอกสาร API ได้ในที่เดียว พร้อมรัน functional test ใน CI ด้วย apidog run เมื่อนำ Apidog และ k6 มาใช้ร่วมกัน คุณจะได้ pipeline ที่ตรวจทั้ง “API ถูกต้องหรือไม่” และ “API ยังเร็วภายใต้โหลดหรือไม่”

DEV Community