Grafana k6: kiểm thử tải như viết mã, thử nghiệm cho chuỗi siêu thị mini
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
k6 trong một trang: kiểm thử tải như viết mã, và khi nào nên chọn
k6 là công cụ kiểm thử tải (load testing, tức là tạo nhiều người dùng ảo để xem hệ thống chịu được bao nhiêu) do Grafana Labs phát triển. README mô tả mục tiêu thiết kế chính là trải nghiệm tốt cho lập trình viên và nêu khẩu hiệu "như unit test, nhưng cho hiệu năng". Kịch bản kiểm thử được viết bằng JavaScript, còn phần lõi chạy bằng Go. [1]
Bài này đề xuất một hướng dùng cụ thể: một chuỗi siêu thị mini có ứng dụng đặt hàng và hệ thống đồng bộ tồn kho giữa các cửa hàng muốn biết hệ thống có trụ nổi trong đợt khuyến mãi cuối tuần hay không. Đó là tình huống giả định để phân tích, không phải một dự án đã diễn ra. k6 phù hợp khi nhóm kỹ thuật đã có API hoặc trang web để đo, có người đọc được mã JavaScript và muốn đưa bài kiểm tra vào quy trình CI.
Nên cân nhắc kỹ hơn nếu doanh nghiệp chưa có người vận hành hệ thống, vì k6 chỉ tạo tải và đo kết quả; nó không sửa nút thắt cổ chai. Cũng cần xem lại giấy phép AGPL-3.0 nếu định sửa mã nguồn k6 rồi cung cấp cho người khác dùng qua mạng. Còn nếu chỉ cần một con số nhanh cho một trang tĩnh, một công cụ đơn giản hơn có thể đủ. [1][2]
Vì sao một chuỗi cửa hàng nhỏ vẫn cần đo tải trước ngày khuyến mãi
Siêu thị mini thường có lưu lượng rất không đều: ngày thường vắng, nhưng đợt giảm giá, ngày lương hoặc dịp lễ có thể kéo nhiều người mở ứng dụng cùng lúc. Nếu cổng đặt hàng, hệ thống thanh toán hoặc dịch vụ tồn kho chậm lại đúng thời điểm đó, thiệt hại là đơn hàng bị bỏ dở và nhân viên cửa hàng phải xử lý thủ công. Đây là lập luận về rủi ro vận hành, không dựa trên số liệu thị trường nào.
Phương pháp phổ biến nhưng yếu là chờ ngày khuyến mãi để biết hệ thống có chịu được hay không. Cách khác là một người bấm thử nhiều tab trình duyệt, không lặp lại được và không so sánh được giữa hai lần phát hành. Kiểm thử tải viết thành mã giải quyết đúng điểm này: kịch bản được lưu trong kho mã, chạy lại sau mỗi thay đổi và có tiêu chí pass/fail rõ ràng.
Bên trong một tiến trình k6: lõi Go, kịch bản JavaScript và các kịch bản tải
README mô tả k6 là sự kết hợp giữa hiệu năng của Go và sự quen thuộc của JavaScript nhờ một bộ máy JavaScript nhúng. Người dùng viết một tệp kịch bản; tệp này khai báo cấu hình trong biến options và hành vi người dùng trong hàm mặc định. Ví dụ trong README dùng module http và hàm check để kiểm tra mã trả về, rồi sleep để mô phỏng thời gian chờ giữa các thao tác. [1]
Khái niệm trung tâm là VU (virtual user, người dùng ảo) và scenario (kịch bản tải). README liệt kê scenarios cho phép chọn mô hình tải mở hoặc đóng, số yêu cầu mỗi giây cố định, số lần lặp cố định và nhiều kiểu khác. Với siêu thị mini, mô hình mở (đặt tốc độ đến) gần với thực tế hơn mô hình đóng, vì khách mới tới không chờ khách trước xong. Nhận định này là phân tích của bài, tài liệu nguồn chỉ nêu khả năng chọn mô hình. [1]
Phần ngưỡng (thresholds) cho phép mã hóa mục tiêu mức dịch vụ. Trong ví dụ README, điều kiện là 99% yêu cầu hoàn thành dưới 3000 mili giây; đó chỉ là số trong ví dụ của dự án, không phải khuyến nghị cho bất kỳ doanh nghiệp nào. Khi ngưỡng không đạt, lệnh chạy kết thúc ở trạng thái lỗi nên CI có thể chặn bản phát hành. [1][3]
Đường đi của một lần chạy: từ kịch bản, qua người dùng ảo, đến số liệu và ngưỡng
Hãy theo dõi một lần chạy giả định của chuỗi siêu thị. Kỹ sư viết kịch bản gồm ba bước: mở danh mục, thêm sản phẩm vào giỏ, gửi đơn. Cấu hình stages tăng dần số VU, giữ ổn định rồi giảm xuống, tương tự cấu trúc ramp trong ví dụ README. Mỗi VU lặp lại hàm mặc định, gửi yêu cầu HTTP tới môi trường thử và ghi nhận kết quả. [1]
Tài liệu thiết kế 020 mô tả thêm một đường đi khác khi chạy phân tán. Trong mô hình execution segment, toàn bộ lần chạy được xem là khoảng từ 0 đến 1, chia thành các đoạn không chồng lấn, mỗi tiến trình k6 chỉ khởi tạo và chạy phần việc thuộc đoạn của mình. Tài liệu nói lệnh k6 run thông thường tương đương đoạn 0:1. [3]
Điểm tinh tế nằm ở các việc quanh phần chạy: phân phối gói kịch bản, chạy setup đúng một lần, đồng bộ lúc bắt đầu, gom số liệu để tính ngưỡng và chạy teardown một lần. Tài liệu liệt kê chín việc như vậy và thừa nhận phần lớn chúng hiện cần thành phần điều phối bên ngoài, ví dụ k6-operator hoặc dịch vụ đám mây. Với doanh nghiệp nhỏ, ý nghĩa thực tế là: một máy chạy một tiến trình là cách đơn giản nhất; chạy phân tán là một dự án vận hành riêng. [3]
Những gì README và tài liệu thiết kế xác nhận hiện có
Theo README, danh sách tính năng cốt lõi gồm: tạo tải cấu hình được, kiểm thử bằng mã, API kịch bản đầy đủ, bộ máy JavaScript nhúng, nhiều giao thức (HTTP, WebSockets, gRPC, Browser), hệ sinh thái extension, lưu trữ và hiển thị số liệu linh hoạt, và tích hợp với Grafana Cloud. Đây là lời giới thiệu của nhà phát triển. Bài này dùng chúng làm danh sách khả năng được công bố, chưa phải khả năng đã kiểm chứng bằng chạy thử. [1]
Cần tách ba lớp. Lớp hiện có: những mục trên. Lớp lộ trình: README có đường dẫn tới public roadmap và nói rõ thời gian và ưu tiên có thể thay đổi; SUPPORT.md viết thêm rằng lộ trình không phải cam kết phát triển. Lớp thương mại: dịch vụ đám mây Grafana Cloud k6, được README mô tả là giải pháp SaaS để chạy kiểm thử và phân tích dữ liệu, là sản phẩm riêng, không nằm trong gói nguồn mở. [1][7]
Tài liệu thiết kế 020 thuộc lớp lộ trình và ý tưởng: nó đề xuất phương án chạy phân tán gốc và bộ kiểm thử gồm nhiều kịch bản. Bài này không khẳng định các đề xuất đó đã hoàn thành ở commit đã chọn. [3]
Ai nên cân nhắc k6, và ai nên bỏ qua
Nhóm phù hợp nhất là đội phát triển có API hoặc ứng dụng web riêng và có ít nhất một người thoải mái với JavaScript. README nhắm tới lập trình viên và người kiểm thử trong bối cảnh DevOps, nên dự án được thiết kế để đi vào CI hơn là để một người thao tác bằng giao diện. [1]
Nhóm nên bỏ qua hoặc làm sau: cửa hàng chỉ dùng phần mềm bán hàng đóng gói, không có quyền chạm tới máy chủ. Nếu không được phép tạo tải lên hệ thống của nhà cung cấp, kịch bản k6 dễ vi phạm điều khoản sử dụng của họ. Doanh nghiệp cũng cần hạn chế chạy tải lên hệ thống thật có dữ liệu khách hàng.
Tình huống đề xuất: chuỗi siêu thị mini kiểm tra ứng dụng đặt hàng trước đợt khuyến mãi
Giả định một chuỗi siêu thị mini có nhiều cửa hàng ở Đà Nẵng. Chuỗi có ứng dụng đặt hàng giao tận nơi, một API đồng bộ tồn kho từ các cửa hàng và một trang tra cứu khuyến mãi. Đội kỹ thuật gồm vài người, một phần là đối tác thuê ngoài. Đây là kịch bản đề xuất để minh họa cách dùng k6, không phải mô tả một doanh nghiệp có thật.
Giai đoạn một, chọn ba luồng quan trọng: xem danh mục theo cửa hàng, thêm vào giỏ, gửi đơn. Mỗi luồng thành một scenario riêng trong cùng một tệp kịch bản. Dữ liệu thử là tài khoản và sản phẩm giả trong môi trường staging, không dùng thông tin khách hàng thật. Hàm check kiểm tra mã trả về, còn ngưỡng cho từng luồng do chủ sản phẩm và kỹ sư cùng đặt. [1]
Giai đoạn hai, mô phỏng khuyến mãi cuối tuần bằng mô hình tốc độ đến tăng dần, rồi giữ ở mức cao trong vài phút. Kỹ sư theo dõi đồng thời CPU, bộ nhớ và độ trễ cơ sở dữ liệu ở phía máy chủ. Câu hỏi cần trả lời là: ở mức tải nào luồng gửi đơn bắt đầu vượt ngưỡng, và nút thắt nằm ở API, cơ sở dữ liệu hay dịch vụ bên thứ ba. [1]
Giai đoạn ba, đưa một bản rút gọn của kịch bản vào CI để chạy mỗi lần phát hành. Một cách tiết kiệm là dùng bản chạy ngắn trên một máy, chỉ để phát hiện suy giảm rõ rệt; bản chạy dài chỉ làm trước mùa khuyến mãi. Nếu nhu cầu vượt khả năng một máy, mới cân nhắc chạy phân tán như tài liệu 020 mô tả, và khi đó cần ngân sách thời gian vận hành riêng. [3]
Chạy k6 ở quy mô nhỏ: máy đơn, CI và những việc cần có người chịu trách nhiệm
Con đường đơn giản nhất là chạy một tiến trình k6 trên một máy hoặc một runner CI, trong cùng mạng với môi trường thử để giảm nhiễu từ đường truyền. README nói có thể chạy từ dòng lệnh, trong CI hoặc trên cụm Kubernetes. Với quy mô chuỗi mười cửa hàng, hai lựa chọn đầu thường đủ để bắt đầu, còn Kubernetes là bước sau nếu thực sự có nhu cầu. [1]
Cần cố định các yếu tố ảnh hưởng đến tính so sánh được: phiên bản k6, cấu hình máy chạy, dữ liệu thử và trạng thái môi trường (bộ nhớ đệm nóng hay nguội). Nếu mỗi lần chạy một khác, sự thay đổi độ trễ có thể là do môi trường chứ không phải do bản phát hành. Nguyên tắc này là thực hành chung của bài, không phải quy tắc riêng của k6.
Về nâng cấp, Dependencies.md cho biết dự án muốn hỗ trợ build bằng hai phiên bản Go mới nhất và chỉ chuyển sau khi bản vá .1 ra mắt. Điều này liên quan tới ai tự biên dịch k6; người dùng bản dựng sẵn cần theo dõi ghi chú phát hành. Doanh nghiệp nên ghim phiên bản trong CI thay vì lấy bản mới nhất mỗi lần. [6]
Rủi ro bảo mật: kịch bản chứa bí mật, tải thử đến hệ thống thật và chuỗi cung ứng
Rủi ro thực tế nhất không nằm ở phần mềm k6 mà ở cách dùng. Kịch bản kiểm thử thường cần token, tài khoản thử hoặc khóa API. Đưa chúng thẳng vào kho mã là sai lầm phổ biến; nên đọc từ biến môi trường hoặc kho bí mật của CI. Lời khuyên này là thực hành chung, README không bàn tới chi tiết.
Thứ hai, chuỗi cung ứng. Extension và thư viện phụ thuộc là mã bên thứ ba. Dependencies.md cho thấy dự án có chính sách cập nhật phụ thuộc, nhưng chính sách này không thay thế việc doanh nghiệp tự xem xét extension mình cài. Cần ghi lại extension nào được dùng, nguồn nào, phiên bản nào. [1][6]
Thứ ba, quy trình báo lỗ hổng: CONTRIBUTING.md và README đều hướng việc công bố vấn đề bảo mật tới SECURITY.md của kho thay vì issue công khai. Doanh nghiệp nên làm theo kênh đó nếu phát hiện lỗ hổng. Bài chưa đọc nội dung SECURITY.md nên không nhận xét về chính sách ấy. [1][5]
AGPL-3.0: điều gì áp dụng cho mã k6 tại commit này, và điều gì chưa được trả lời
Tệp LICENSE.md ở gốc kho là văn bản GNU Affero General Public License phiên bản 3. README cũng nói k6 được phân phối theo AGPL-3.0. Tệp giấy phép mở đầu bằng lời nêu AGPL là giấy phép copyleft thiết kế cho phần mềm máy chủ mạng, và phần lời mở đầu giải thích rằng người vận hành phiên bản đã sửa đổi trên máy chủ công khai phải cung cấp mã nguồn cho người dùng của máy chủ đó. [1][2]
Có một thư mục con riêng, internal/dashboard, chứa tệp LICENSE của chính nó. Nội dung tệp là văn bản AGPL phiên bản 3 với định dạng khác tệp gốc. Bài không xác minh chủ sở hữu bản quyền hay phạm vi tệp đó bao phủ, nên người thẩm định pháp lý cần đọc thêm. [4]
Các điều cần nói rõ. Thứ nhất, giấy phép này áp dụng cho mã k6 tại commit đã chọn, không tự động áp dụng cho extension bên thứ ba, thư viện phụ thuộc, kịch bản của bạn hay dịch vụ Grafana Cloud k6. Thứ hai, CONTRIBUTING.md yêu cầu người đóng góp ký CLA (thỏa thuận cấp phép cho người đóng góp) qua cla-assistant. Thứ ba, bài không tìm thấy trong các tệp đã đọc quy định riêng về nhãn hiệu. [2][5]
Hệ quả thực tế cần luật sư xác nhận. Chạy k6 nguyên bản nội bộ để kiểm thử hệ thống của chính mình là tình huống ít vấn đề nhất. Rủi ro tăng khi doanh nghiệp sửa mã k6, đóng gói vào sản phẩm bán cho khách hoặc cho người khác dùng qua mạng. Khi đó nghĩa vụ công bố mã nguồn của AGPL có thể phát sinh. Bài này không phải tư vấn pháp lý.
Nguồn lực cần có: người, máy chạy tải và thời gian bảo trì kịch bản
Phần mềm không thu phí giấy phép, nhưng không có nghĩa là không có chi phí. Loại nguồn lực thứ nhất là con người: một kỹ sư viết và bảo trì kịch bản, một người am hiểu nghiệp vụ để đặt ngưỡng hợp lý và một người có quyền đọc số liệu giám sát phía máy chủ. Khoản này thường lớn hơn chi phí máy.
Loại thứ hai là phần cứng. Một máy hoặc runner CI cho các lần chạy nhỏ; máy lớn hơn hoặc nhiều máy cho tải nặng. Cần ước lượng theo thực nghiệm trong giai đoạn thử, vì README chỉ nói máy cấu hình thấp cũng mô phỏng được nhiều lưu lượng chứ không đưa con số cụ thể. Bài không đưa ra số máy hay chi phí. [1]
Loại thứ ba là phương án dịch vụ thương mại. README giới thiệu Grafana Cloud k6 như SaaS để chạy kiểm thử; bảng giá và hạn mức không có trong các tệp đã đọc, nên bài không đưa ra con số. Doanh nghiệp cần tự lấy báo giá hiện hành nếu cân nhắc. [1]
Cuối cùng là thời gian vận hành chạy phân tán. Tài liệu 020 cho thấy chạy một lần kiểm thử trên nhiều máy kéo theo nhiều việc điều phối. Nếu chọn k6-operator hoặc dịch vụ đám mây, khoản này chuyển thành công sức triển khai Kubernetes hoặc chi phí thuê. [3]
Đặt k6 cạnh các hướng khác: công cụ dòng lệnh, giao diện đồ họa và dịch vụ đo tải
Có ba hướng tiếp cận có thể so sánh ở mức phương pháp. Hướng một: công cụ kiểm thử tải viết bằng mã, như k6 hoặc các công cụ cùng triết lý. Ưu điểm là kịch bản nằm trong kho mã và chạy được trong CI; nhược điểm là cần người viết mã. Bài không so sánh số liệu hiệu năng giữa các công cụ vì chưa đo.
So với hướng hai và ba, k6 nằm ở phía mã nguồn và dòng lệnh, đồng thời có nhánh thương mại là Grafana Cloud k6 và công cụ phụ k6 Studio cho người không muốn viết mã. Lợi thế là người dùng có thể bắt đầu bằng bản nguồn mở rồi quyết định có sang đám mây hay không. Ràng buộc là phần lớn tính năng điều phối phân tán nằm ngoài lõi. [1][3]
Giới hạn cần biết và những trường hợp không nên dùng k6
Giới hạn đầu tiên nằm ở chính bản chất kiểm thử tổng hợp: kịch bản chỉ phản ánh hành vi người dùng mà người viết đã mô hình hóa. Nếu bỏ sót một luồng, ví dụ tìm kiếm sản phẩm, kết quả có thể lạc quan hơn thực tế. Không có công cụ nào thay thế được việc hiểu hành vi khách hàng.
Giới hạn thứ hai: chạy phân tán chưa phải trải nghiệm đơn giản. Tài liệu 020 tự thừa nhận vấn đề phân tán gốc là issue cũ và được nhiều người mong đợi nhất, đồng thời trình bày các hạn chế của giải pháp hiện tại như phải tắt setup, teardown và summary khi chạy nhiều tiến trình rồi cài đặt lại logic bên ngoài. Đây là tài liệu thiết kế có thời điểm; trạng thái hiện hành phải kiểm tra trên bản phát hành mới. [3]
Không nên dùng k6 khi: chưa được phép tạo tải lên hệ thống đích; không có ai chịu trách nhiệm bảo trì kịch bản; ràng buộc giấy phép AGPL không phù hợp với kế hoạch tích hợp sâu vào sản phẩm thương mại; hoặc vấn đề thật sự là chất lượng dữ liệu hoặc quy trình chứ không phải hiệu năng. [2]
Kế hoạch thử nghiệm sáu tuần với tiêu chí đo được
Mục tiêu của thử nghiệm: chứng minh nhóm kỹ thuật có thể viết, chạy và đọc một bài kiểm tra tải cho luồng gửi đơn, và phát hiện được ít nhất một nút thắt hoặc xác nhận rằng hệ thống đạt ngưỡng đã đặt. Mọi con số dưới đây là ngưỡng đề xuất để đội tự điều chỉnh, không phải chuẩn của dự án.
Tuần một và hai: dựng môi trường staging cô lập, tạo dữ liệu thử, viết kịch bản cho một luồng. Tiêu chí hoàn thành: kịch bản chạy lặp lại được trên hai máy khác nhau và hai lần chạy liên tiếp cho kết quả cùng bậc độ lớn. Nếu dao động quá lớn, ưu tiên sửa môi trường trước khi đo tiếp. [1]
Tuần ba và bốn: mở rộng sang ba luồng, đặt ngưỡng bằng mã, tăng tải theo từng nấc. Ghi lại ở nấc nào ngưỡng bắt đầu vi phạm và đối chiếu với số liệu giám sát máy chủ. Tiêu chí: tìm ra nguyên nhân của ít nhất một lần vi phạm, hoặc có bằng chứng ghi chép về việc không có vi phạm trong dải tải đã thử. [1]
Tuần năm: đưa bản chạy ngắn vào CI. Tiêu chí: thời gian chạy đủ ngắn để không cản trở phát hành, tỷ lệ báo động giả thấp theo mức đội chấp nhận, và có người nhận cảnh báo. Đồng thời rà soát giấy phép và bí mật trong kho mã. [2]
Tuần sáu: đánh giá. Tiêu chí tiếp tục: chi phí công sức thực tế so với ước lượng, mức độ đội hiểu kết quả không cần người viết kịch bản gốc giải thích, và quyết định về phân tán. Tiêu chí dừng: không có người bảo trì, môi trường staging không đại diện được, hoặc pháp lý không chấp nhận AGPL cho kế hoạch dự kiến. Chỉ cân nhắc chạy phân tán khi một máy đã chứng minh không đủ. [3]
Kết luận: một công cụ đo tốt cần một kỷ luật đo tốt
k6 là lựa chọn đáng thử cho đội kỹ thuật muốn biến kiểm thử tải thành một phần của quy trình phát hành. Các điểm mạnh mà nguồn xác nhận gồm kịch bản bằng JavaScript, ngưỡng viết bằng mã, mô hình tải đa dạng và hệ sinh thái mở rộng. Những điều đó chưa được bài này kiểm chứng bằng chạy thật. [1]
Với chuỗi siêu thị mini trong tình huống giả định, giá trị lớn nhất không nằm ở công cụ mà ở việc buộc nhóm trả lời các câu hỏi cụ thể: luồng nào quan trọng, ngưỡng nào chấp nhận được, ai chịu trách nhiệm khi vượt ngưỡng. Công cụ chỉ làm các câu trả lời đó lặp lại được.
Nguồn, commit và giới hạn phương pháp
Đây là nghiên cứu bàn giấy (desk research) tại một commit cố định, không phải ấn phẩm khoa học được bình duyệt. Chúng tôi không cài đặt, chạy, đo hiệu năng hay triển khai k6; mọi nhận định về tính năng dựa trên văn bản trong kho. Commit được dùng là 61c5b75786e5cab7a55c3a115b08b25bb39fafb9, ngày commit 2026-10-12, ngày kiểm tra 2026-10-12. [1]
Các tệp đã đọc ở commit này: README.md, LICENSE.md, tài liệu thiết kế docs/design/020-distributed-execution-and-test-suites.md, tệp internal/dashboard/LICENSE, CONTRIBUTING.md, Dependencies.md và SUPPORT.md. Bài không đọc mã nguồn Go, không đọc tài liệu trên trang grafana.com và không đọc các kho k6-operator, k6-studio. [1][3][4][5][6][7]
Dự án được chọn từ kho lưu trữ GitHub Trending của bonfy/github-trending. Lần quan sát đầu là ngày 2026-01-08, danh sách ngôn ngữ Go, vị trí 3, và dự án xuất hiện 7 lần trong dữ liệu tới ngày 2026-09-29. Kho lưu trữ chỉ bao phủ các danh sách Python, Go, JavaScript và Swift, thiếu ngày 2026-09-03 và 2026-10-12, nên không phải bảng xếp hạng chính thức hay top 100 chính thức. [8]
Giới hạn chính: tài liệu thiết kế 020 là tài liệu có từ trước và có thể không phản ánh trạng thái hiện hành; các mô tả của README là tuyên bố của nhà phát triển; mọi số liệu ngưỡng trong bài là ví dụ. Phần giấy phép là phân tích kỹ thuật, không phải tư vấn pháp lý. [2][3]