Tự host giải pháp 'Distributed Web Performance Testing' trên cụm VPS rẻ với k6 và Kubernetes (K3s): Giả lập 50,000 khách truy cập

1. Đặt vấn đề: Thách thức khi kiểm thử hiệu năng quy mô lớn

Trong kỷ nguyên số, trải nghiệm người dùng quyết định sự sống còn của một sản phẩm công nghệ. Một ứng dụng Web hay hệ thống E-commerce chỉ cần chậm vài giây trong chiến dịch khuyến mãi lớn có thể dẫn đến thiệt hại hàng triệu USD và làm suy giảm uy tín thương hiệu nghiêm trọng. Do đó, Web Performance Testing (Kiểm thử hiệu năng Web) trở thành một bước bắt buộc trong quy trình phát triển và vận hành hệ thống.

Tuy nhiên, thách thức lớn nhất của các kỹ sư QC và DevOps là làm thế nào để giả lập một lượng lưu lượng truy cập khổng lồ (ví dụ: 50,000 người dùng đồng thời - Simultaneous Virtual Users) một cách chân thực nhất. Các giải pháp Cloud-based SaaS như LoadRunner Enterprise hay BlazeMeter dù rất mạnh mẽ nhưng lại sở hữu mức chi phí cực kỳ đắt đỏ, thường vượt quá ngân sách của các startup và doanh nghiệp vừa và nhỏ (SMEs).

Bài viết này sẽ hướng dẫn bạn cách tự host (Self-hosted) một giải pháp Distributed Web Performance Testing hoàn chỉnh. Bằng cách kết hợp công cụ kiểm thử hiện đại k6 và kiến trúc điều phối Kubernetes (phiên bản K3s gọn nhẹ) trên một cụm VPS chi phí thấp, chúng ta có thể dễ dàng đạt được mục tiêu giả lập 50,000 khách truy cập với chi phí tối ưu nhất.

2. Tại sao lại chọn k6 và K3s cho hệ thống tự host?

Để xây dựng một hệ thống kiểm thử phân tán hiệu quả, việc lựa chọn công nghệ lõi đóng vai trò quyết định. Thay vì các công cụ truyền thống, cấu hình này mang lại những ưu điểm vượt trội:

Về công cụ k6 (by Grafana Labs)

• Hiệu suất vượt trội: Được viết bằng ngôn ngữ Go (Golang), k6 tối ưu hóa tài nguyên phần cứng tốt hơn rất nhiều so với JMeter (chạy trên Java và tiêu tốn nhiều RAM cho luồng xử lý - OS Threads).
• Developer-centric: Kịch bản kiểm thử (Test Scripts) được viết hoàn toàn bằng JavaScript/TypeScript, giúp việc tích hợp vào luồng CI/CD trở nên tự nhiên và dễ dàng.
• Hỗ trợ Native cho Kubernetes: Thông qua k6 Operator, việc phân tán tải (Distributed Load) được tự động hóa hoàn toàn.

Về hệ điều phối K3s (by Rancher)

• Siêu nhẹ (Lightweight): K3s là phiên bản tinh giản của Kubernetes tiêu chuẩn, được thiết kế tối ưu cho môi trường có tài nguyên hạn chế như Edge, IoT hoặc VPS cấu hình thấp. Nó tiêu thụ chưa đến 512MB RAM trên mỗi Node.
• Đầy đủ tính năng: Dù gọn nhẹ, K3s vẫn cung cấp toàn bộ API của Kubernetes, đảm bảo khả năng mở rộng (Scaling) các k6 Runner một cách mượt mà.

3. Thiết kế kiến trúc cụm VPS giá rẻ

Để đạt được mục tiêu giả lập 50,000 Virtual Users (VUs), chúng ta không thể dựa vào một máy đơn lẻ do giới hạn về băng thông mạng (Network Bandwidth) và số lượng Socket kết nối (Ephemeral Ports) trên một hệ điều hành. Kiến trúc phân tán là bắt buộc.

Chúng ta sẽ cấu hình một cụm (Cluster) gồm các VPS từ các nhà cung cấp giá rẻ như Hetzner, DigitalOcean, Linode hoặc các nhà cung cấp nội địa:

• 1 Node Master (K3s Server): Cấu hình khuyến nghị 2 vCPU / 4GB RAM. Nhiệm vụ quản lý cụm, thu thập số liệu và điều phối.
• 3 đến 4 Node Worker (K3s Agent): Cấu hình khuyến nghị 4 vCPU / 8GB RAM mỗi Node. Đây là các máy trực tiếp sinh tải (Load Generators).

Lưu ý quan trọng về Network: Hãy đảm bảo các VPS được chọn có băng thông cổng mạng tốt (tối thiểu 1Gbps đến 10Gbps) và không bị giới hạn lưu lượng (Data Transfer) quá nghiêm ngặt trong thời gian ngắn chạy Test.

4. Từng bước triển khai hệ thống k6 trên K3s

Bước 1: Khởi tạo cụm K3s Cluster

Đầu tiên, tiến hành cài đặt K3s Server trên Node Master bằng lệnh terminal đơn giản:

curl -sfL [https://get.k3s.io](https://get.k3s.io) | sh -

Sau khi hoàn tất, lấy Token bảo mật từ Master Node để kết nối các Worker Nodes:

sudo cat /var/lib/rancher/k3s/server/node-token

Trên các Node Worker, thực hiện lệnh sau để gia nhập vào cụm:

curl -sfL [https://get.k3s.io](https://get.k3s.io) | K3S_URL=https://:6443 K3S_TOKEN= sh -

Bước 2: Cài đặt k6 Operator thông qua Helm

k6 Operator giúp chúng ta định nghĩa các tài nguyên tùy chỉnh (Custom Resource Definitions - CRDs) trong Kubernetes để quản lý việc kiểm thử phân tán. Hãy cài đặt nó thông qua Helm Chart:

helm repo add k6-operator [https://grafana.github.io/helm-charts](https://grafana.github.io/helm-charts)
helm repo update
helm install k6-operator k6-operator/k6-operator

Bước 3: Viết kịch bản kiểm thử (Test Script)

Tạo một file JavaScript có tên load-test.js định nghĩa kịch bản mô phỏng hành vi người dùng (ví dụ: truy cập trang chủ, gọi API login, xem sản phẩm):

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

export const options = {
  discardResponseBodies: true,
};

export default function () {
  const res = http.get('[https://your-target-website.com/api/v1/products](https://your-target-website.com/api/v1/products)');
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1);
}

Nén kịch bản này vào một Kubernetes ConfigMap để cụm K3s có thể phân phối tới các Pods:

kubectl create configmap k6-test-scripts --from-file=load-test.js

Bước 4: Cấu hình phân tán để đạt 50,000 VUs

Tạo một file manifest YAML định nghĩa thực thể K6 phân tán. Điểm mấu chốt ở đây là tham số parallelism, quy định số lượng Pods (Runner) sẽ chia sẻ tổng lượng tải.

apiVersion: k6.io/v1alpha1
kind: K6
metadata:
  name: distributed-50k-users
spec:
  parallelism: 10
  script:
    configMap:
      name: k6-test-scripts
      file: load-test.js
  arguments: --vus 5000 --duration 10m

Trong cấu hình trên, chúng ta định nghĩa parallelism: 10 (10 Pods chạy song song) và mỗi Pod sẽ chịu trách nhiệm giả lập 5000 VUs. Tổng cộng hệ thống sẽ tạo ra chính xác 50,000 khách truy cập đồng thời trong thời gian 10 phút.

5. Thu thập kết quả và Giám sát trực quan

Chạy kiểm thử phân tán mà không có hệ thống giám sát thời gian thực (Real-time Monitoring) giống như việc lái xe trong đêm không bật đèn. Khi các Pods chạy độc lập, dữ liệu log thô sẽ rất khó phân tích.

Giải pháp tối ưu là cấu hình k6 xuất dữ liệu trực tiếp về một cơ sở dữ liệu trung tâm như InfluxDB hoặc Prometheus, sau đó trực quan hóa các biểu đồ thông qua Grafana Dashboard.

Các chỉ số cốt lõi (Core Metrics) doanh nghiệp cần đặc biệt lưu tâm bao gồm:

• http_req_duration (Response Time): Thời gian phản hồi trung bình, cũng như các phân vị quan trọng P95, P99. Nếu P99 vượt quá ngưỡng 2 giây, hệ thống đang gặp thắt nút cổ chai (Bottleneck).
• http_req_failed (Error Rate): Tỷ lệ lỗi (5xx, 4xx). Tỷ lệ này phải bằng 0% hoặc ở mức cực kỳ thấp dưới 0.1% trong suốt quá trình tải đỉnh.
• VUs (Virtual Users): Biểu đồ thể hiện lượng người dùng tăng trưởng theo mô hình (Ramping up) ổn định đến mốc 50k thành công.

6. Kết luận và Khuyến nghị tối ưu

Xây dựng một hệ thống Distributed Web Performance Testing tự host trên cụm VPS rẻ bằng k6 và K3s không chỉ giúp doanh nghiệp tiết kiệm hàng ngàn USD chi phí bản quyền SaaS, mà còn mang lại sự chủ động tuyệt đối trong quy trình phát triển phần mềm.

Để đảm bảo quá trình kiểm thử diễn ra chính xác nhất, doanh nghiệp cần lưu ý một số điểm sau trước khi bấm nút khởi chạy:

1. Tối ưu hóa Kernel OS (Sysctl): Hãy tăng giới hạn nofile (số lượng file mở tối đa) và dải cổng local_port_range trên toàn bộ các Worker Node để tránh lỗi nghẽn hệ điều hành.
2. Không chạy test từ một vùng địa lý duy nhất: Nếu khách hàng mục tiêu ở toàn cầu, hãy thuê VPS ở nhiều Region khác nhau (Mỹ, Châu Âu, Châu Á) để giả lập độ trễ mạng thực tế.
3. Kiểm soát phía nhận tải: Luôn thông báo hoặc chuẩn bị hạ tầng phía Server đích (Target system) sẵn sàng đón nhận đợt tải lớn, tránh làm ảnh hưởng đến người dùng thực tế nếu test trên môi trường Production.