Load Test ในการพัฒนามือถือ — คืออะไร สถานการณ์ และวิธีการทำ

Load Test คืออะไร?

Load Test เป็นกระบวนการตรวจสอบว่าระบบทำงานภายใต้จำนวนคำขอหรือผู้ใช้พร้อมกันที่คาดหวังอย่างไร ในบริบทของการพัฒนามือถือ Load Test ถูกนำไปใช้กับทั้งฝั่งเซิร์ฟเวอร์ (API, ฐานข้อมูล, แคช) และฝั่งคลายเอนต์ (การประมวลผลการแจ้งเตือน push, การซิงโครไนซ์ข้อมูล) ความแตกต่างหลักจากการทดสอบความเครียดคือ Load Test จำลองภาระจริง ไม่ใช่ภาระสูงสุด ตาม AWS Well-Architected Framework (2024) การทดสอบภาระควรดำเนินการโดยใช้โปรไฟล์ภาระที่อิงตามการวิเคราะห์การใช้งานจริง

Load Test สามารถดำเนินการได้ในระดับคำขอ HTTP ไปยัง API, การเชื่อมต่อ WebSocket หรือธุรกรรมฐานข้อมูล วัตถุประสงค์ คือเพื่อให้แน่ใจว่าเวลาตอบสนองของแต่ละคำขอไม่เกินเกณฑ์ที่กำหนด (โดยทั่วไป 500–1000 ms สำหรับ API) และปริมาณการรองรับ (RPS — จำนวนคำขอต่อวินาที) ตรงตามความต้องการ Google Cloud Armor (2024) กำหนดค่าเกณฑ์โดยอิงตามเปอร์เซนไทล์: เวลาตอบสนอง p95 ไม่ควรเกิน 2 วินาทีสำหรับจุดสิ้นสุดที่สำคัญ

การทดสอบภาระของแบ็กเอนด์มือถือรวมถึงการจำลองสถานการณ์ทั่วไป: การลงทะเบียน, การตรวจสอบสิทธิ์, การโหลดฟีด, การส่งแบบฟอร์ม สถานการณ์ จะถูกบันทึกเป็นไฟล์ HAR (HTTP Archive) และเล่นซ้ำโดยเครื่องมือทดสอบภาระ ตามเอกสาร k6 (2025) การแปลง HAR สามารถลดเวลาเตรียม Load Test ได้ถึง 60%

วัตถุประสงค์ของการทดสอบภาระ

วัตถุประสงค์แรกของ Load Test คือ การยืนยันปริมาณการรองรับของระบบ หากข้อกำหนดต้องการประมวลผล 1000 RPS การทดสอบภาระต้องยืนยันค่านี้โดยมีส่วนเกิน 20% ตาม Netflix Tech Blog (2024) การทดสอบภาระใน Netflix ดำเนินการโดยมีส่วนเกิน 2x ของภาระสูงสุด: หากคาดว่า 10000 RPS การทดสอบจะตรวจสอบ 20000 RPS วิธีการนี้รับประกันความเสถียรในระหว่างการเพิ่มขึ้นอย่างกระทันหันของปริมาณการจราจร

วัตถุประสงค์ที่สองคือ การระบุจุดคอขวด (bottlenecks) ในสถาปัตยกรรม จุดคอขวดทั่วไปในแบ็กเอนด์มือถือคือ ฐานข้อมูล (คำสั่งช้า), แคช (กลยุทธ์การทำให้ใช้การไม่ได้ไม่ถูกต้อง), และ API ภายนอก (บริการบุคคลที่สามที่ช้า) การติดตามแบบกระจาย (Jaeger, Zipkin) ช่วยระบุตำแหน่งปัญหาในระดับบริการหรือคำขอเฉพาะ

วัตถุประสงค์ที่สามคือ การกำหนดจุดอิ่มตัว (saturation point) นี่คือช่วงที่การเพิ่มผู้ใช้ใหม่ไม่ทำให้ปริมาณการรองรับเพิ่มขึ้นอีก ในแอปพลิเคชันมือถือ จุดอิ่มตัวมักเกิดขึ้นเมื่อโหลด CPU บนเซิร์ฟเวอร์ฐานข้อมูลอยู่ที่ 70–80% การปรับขนาดอัตโนมัติ ควรทำงานก่อนถึงจุดนี้

สถานการณ์การทดสอบภาระ

การทดสอบภาระสูงสุด (Spike Test) — จำลองการเพิ่มขึ้นอย่างกระทันหันของกิจกรรม เช่น แคมเปญแจ้งเตือน push ตอนเช้าหรือการเปิดตัวแคมเปญโฆษณา ตาม Grafana k6 (2025) Spike Test จำลองการเพิ่มภาระจาก 100 เป็น 10000 RPS ภายใน 30 วินาที ระบบต้องจัดการกับสิ่งนี้โดยไม่สูญเสียคำขอและไม่เกินเวลาตอบสนองมากกว่า 50%

การทดสอบความทนทาน (Endurance Test) — ตรวจสอบความเสถียรของระบบในระยะเวลาการทำงานภายใต้ภาระยาวนาน ระยะเวลาทั่วไปคือ 1–4 ชั่วโมง Endurance Test เผยให้เห็นการรั่วไหลของหน่วยความจำในแอปพลิเคชันเซิร์ฟเวอร์, ปัญหาพูลการเชื่อมต่อฐานข้อมูล, และการเสื่อมประสิทธิภาพของแคช พูลการเชื่อมต่อ PostgreSQL ภายใต้ภาระยาวนานโดยไม่มีการตั้งค่าที่เหมาะสมอาจทำให้การเชื่อมต่อที่ใช้ได้หมดภายใน 2–3 ชั่วโมงของการทำงาน

การทดสอบภาระแบบเพิ่มทีละขั้น (Step Load Test) — เพิ่มภาระทีละน้อย 10–20% ทุก 2–5 นาที สถานการณ์นี้ช่วยค้นหาขอบเขตที่แน่นอนหลังจากนั้นระบบเสื่อมประสิทธิภาพ InfluxDB และ Prometheus รวบรวมตัวชี้วัดในแต่ละขั้นเพื่อสร้างกราฟเวลาตอบสนองเทียบ RPS

ตัวชี้วัด Load Test

เวลาตอบสนอง

เวลาตอบสนอง (Response Time) เป็นตัวชี้วัดหลักของ Load Test วัดเป็นมิลลิวินาที และวิเคราะห์โดยเปอร์เซนไทล์: p50 (มัธยฐาน), p95 และ p99 Google SRE (2024) แนะนำเกณฑ์ p95 ไม่เกิน 1000 ms สำหรับ REST API และไม่เกิน 200 ms สำหรับ gRPC เปอร์เซนไทล์มีความสำคัญกว่าค่าเฉลี่ยเพราะแสดงพฤติกรรมของคำขอที่แย่ที่สุด ซึ่งผู้ใช้จะสังเกตได้ก่อนอื่น Apdex (ดัชนีประสิทธิภาพแอปพลิเคชัน) เป็นตัวชี้วัดประกอบที่พิจารณาสัดส่วนของผู้ใช้ที่พึงพอใจ, ยอมรับได้ และผิดหวัง

ปริมาณการรองรับ

ปริมาณการรองรับ (Throughput) — จำนวนคำขอที่สำเร็จต่อหน่วยเวลา วัดเป็น RPS (จำนวนคำขอต่อวินาที) หรือ TPS (จำนวนธุรกรรมต่อวินาที) กราฟ Throughput ในพิกัด "เวลา — RPS" ควรเป็นเส้นตรงจนถึงจุดอิ่มตัว การลดลงอย่างกระทันหันของ Throughput เมื่อภาระเพิ่มขึ้นเป็นสัญญาณของการถึงขอบเขตของระบบ Apache Bench และ wrk เป็นเครื่องมือ CLI ง่ายๆ สำหรับการตรวจสอบ Throughput อย่างรวดเร็วในระหว่างการพัฒนา

อัตราข้อผิดพลาด

อัตราข้อผิดพลาด (Error Rate) — สัดส่วนของการตอบสนองที่มีสถานะ HTTP 4xx หรือ 5xx จากจำนวนคำขอทั้งหมด เกณฑ์ที่ยอมรับได้คือต่ำกว่า 1% ข้อผิดพลาด 429 (Too Many Requests) และ 503 (Service Unavailable) ภายใต้ภาระสูงแสดงถึงความจำเป็นต้องตั้งค่า rate limiting และ auto-scaling ตัวจำกัดอัตราด้าน API Gateway ป้องกันแบ็กเอนด์จากการเกินภาระที่อนุญาต นโยบายการลองใหม่ แบบ exponential backoff ช่วยให้คลายเอนต์จัดการกับข้อผิดพลาดชั่วคราวได้อย่างถูกต้อง

เครื่องมือสำหรับ Load Test

k6 (Grafana)

k6 — เครื่องมือทดสอบภาระแบบโอเพนซอร์สชั้นนำของ Grafana สคริปต์เขียนด้วย JavaScript, รองรับสถานการณ์แบบโมดูล, เกณฑ์ (thresholds) และการผสานรวมกับ Prometheus และ InfluxDB k6 สามารถทำงานได้ทั้งใน CLI และบนคลาวด์ Grafana Cloud k6 Grafana Cloud สร้างแดชบอร์ดโดยอัตโนมัติจากผลลัพธ์ Load Test และเปรียบเทียบกับข้อมูลในอดีต k6 รองรับ Protocol Buffers และ gRPC ผ่านโมดูล k6/net/grpc ที่แยกต่างหาก

Apache JMeter

Apache JMeter — เครื่องมือ Load Test แบบคลาสสิกที่มีส่วนต่อประสานผู้ใช้แบบกราฟิก รองรับโปรโตคอลที่หลากหลาย: HTTP, JDBC, JMS, FTP และ TCP JMeter เหมาะกับสถานการณ์ที่ซับซ้อนซึ่งมีคำขอหลายประเภท แต่ต้องการการตั้งค่าด้วยตนเองมากกว่าเมื่อเทียบกับ k6 ปลั๊กอิน JMeter ขยายฟังก์ชันสำหรับการทดสอบ WebSocket และ gRPC สำหรับการดำเนินการแบบกระจาย JMeter ใช้สถาปัตยกรรม master-slave ที่มีตัวควบคุมหนึ่งตัว

Locust

Locust — เครื่องมือที่ใช้ Python ซึ่งช่วยให้สามารถอธิบายสถานการณ์ภาระในโค้ด Locust สะดวกสำหรับทีมที่ใช้ Python เป็นภาษาหลักสำหรับการทำงานอัตโนมัติ ต่างจาก k6 และ JMeter Locust รองรับการดำเนินการแบบกระจายมาในตัว: โหนด master หนึ่งตัวประสานงานกับโหนด worker หลายตัว การดำเนินการแบบกระจาย ช่วยให้สามารถสร้างภาระได้สูงถึง 100000 RPS จากหลายเครื่อง Locust ยังรองรับการทดสอบ WebSocket ผ่านส่วนขยายที่กำหนดเอง

import http from 'k6/http'
import check from 'k6'
import sleep from 'k6'

export const options = {
    stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 200 },
    ],
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed: ['rate<0.01'],
    }
}

export default function() {
    const res = http.get('https://api.example.com/users')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
    sleep(1)
}

ตัวอย่างการเขียน Load Test ด้วย k6

สคริปต์ k6 ด้านบนแสดงโครงสร้างการทดสอบภาระทั่วไป Options กำหนดโปรไฟล์ภาระ: ramp-up 2 นาทีเป็น 100 ผู้ใช้, จากนั้น 5 นาทีภาระคงที่ และ ramp-up อีกเป็น 200 ผู้ใช้ เกณฑ์ กำหนดเกณฑ์การผ่านการทดสอบ: เวลาคำขอ p95 ไม่เกิน 500 ms, อัตราข้อผิดพลาดต่ำกว่า 1% หากเกณฑ์ถูกเกิน k6 จะออกโดยใช้โค้ดที่ไม่ใช่ศูนย์ — ทำให้สามารถผสาน Load Test เข้ากับ CI/CD

ในการพัฒนามือถือ Load Test ของฝั่งเซิร์ฟเวอร์มีความสำคัญโดยเฉพาะเมื่อเปิดตัวฟีเจอร์ใหม่ที่จะสร้างภาระเพิ่มเติม: การกดไลก์, ความคิดเห็น, การสตรีมมิ่ง คำแนะนำ — ดำเนินการ Load Test ในแต่ละ staging ก่อนเผยแพร่สู่ production การสร้างโปรไฟล์ภาระพื้นฐานในช่วงการออกแบบ API ช่วยหลีกเลี่ยงปัญหาทางสถาปัตยกรรมในระยะต่อๆ ไป