Cloud-based load testing — k6 Cloud, BlazeMeter — Performance Testing with JMeter and k6

Mở đầu — vì sao bài này quan trọng

Đến bài này, bạn đã biết viết một test k6 hoặc JMeter chạy trơn tru trên máy tính của mình. Nhưng có một khoảnh khắc gần như chắc chắn sẽ đến trong sự nghiệp Performance Engineer: sếp hoặc khách hàng hỏi "Hệ thống chịu được 50.000 người dùng đồng thời không?" — và bạn nhận ra chiếc laptop của mình không thể mô phỏng nổi con số đó.

Đây không phải chuyện hiếm. Một sàn thương mại điện tử Việt Nam chuẩn bị cho ngày 12.12, một ví điện tử chờ đón đợt khuyến mãi hoàn tiền, một hệ thống bán vé concert mở bán lúc 12h trưa — tất cả đều cần biết trước ngưỡng chịu tải thật của mình ở quy mô hàng chục nghìn, thậm chí hàng trăm nghìn người dùng ảo (Virtual User — VU). Và ở quy mô đó, self-hosted load testing (tự chạy test trên máy của bạn hoặc vài server tự dựng) sẽ gãy vì ba giới hạn vật lý.

Bài này giải quyết đúng bài toán đó: khi nào và làm thế nào để đẩy load test lên cloud, dùng các nền tảng như k6 Cloud (Grafana Cloud k6) và BlazeMeter. Bạn sẽ hiểu bản chất vì sao cloud giải được vấn đề, chọn nền tảng thế nào, và những cạm bẫy về chi phí lẫn kỹ thuật mà người mới hầu như luôn vấp phải.

Khái niệm cốt lõi

Ba giới hạn của self-hosted load testing

Trước khi nói về cloud, phải hiểu rõ vì sao máy của bạn "gãy". Có ba nút thắt:

1. Giới hạn tài nguyên máy (một máy, một CPU). Mỗi VU tiêu tốn CPU và RAM để tạo request, mã hóa TLS, parse response. Một máy 8 core / 16GB RAM chạy k6 thường tối đa được khoảng 5.000–20.000 VU tùy kịch bản (JMeter còn thấp hơn nhiều, thường vài nghìn vì nó tốn RAM cho mỗi thread). Muốn 100.000 VU, bạn cần nhiều máy — và tự quản lý một cụm nhiều máy là cả một cực hình.

2. Giới hạn một IP nguồn duy nhất. Khi tất cả traffic đến từ một địa chỉ IP, hệ thống mục tiêu (hoặc Cloudflare, WAF, rate limiter đứng trước nó) sẽ thấy "một client điên cuồng" và chặn bạn — trả về HTTP 429 (Too Many Requests) hoặc block hẳn. Kết quả test lúc đó phản ánh chính sách chống DDoS, chứ không phải năng lực thật của ứng dụng.

3. Giới hạn một region (một vị trí địa lý). Nếu bạn chạy test từ văn phòng ở TP.HCM đến server đặt ở Singapore, bạn đo được độ trễ của đúng tuyến đường đó. Nhưng người dùng thật của bạn nằm rải rác: Hà Nội, Đà Nẵng, Cần Thơ, thậm chí Việt kiều ở Mỹ, Nhật. Một máy không thể mô phỏng traffic đa vùng.

Cloud load testing giải quyết ra sao

Cloud load testing về bản chất là: nền tảng thuê hộ bạn một đội load generator (máy tạo tải) đặt ở nhiều vùng địa lý, tự động scale số lượng theo VU bạn cần, mỗi máy có IP riêng, rồi gom kết quả về một dashboard tập trung. Bạn chỉ việc upload script và nhấn Run.

Bốn giá trị cốt lõi cloud mang lại:

Scale gần như vô hạn: 100.000+ VU chỉ là một con số bạn gõ vào, hạ tầng tự lo. Không cần dựng cụm máy.
Distributed / multi-region: phát traffic từ nhiều vùng (ví dụ Singapore, Tokyo, Mumbai, US East) cùng lúc, phản ánh đúng phân bố người dùng thật, đồng thời né được rate-limit theo IP.
Zero hạ tầng cần bảo trì: bạn không patch OS, không lo disk đầy, không lo máy tạo tải tự nó thành bottleneck.
Dashboard & lưu trữ lịch sử: kết quả được lưu lại, so sánh giữa các lần chạy, chia sẻ link cho cả team và sếp xem — cực kỳ quan trọng cho phần theo dõi regression sau này.

Hai nền tảng chính

k6 Cloud (nay là Grafana Cloud k6). Nếu bạn đã viết test k6, đây là lựa chọn liền mạch nhất. Cùng file JavaScript, cùng cú pháp options, checks, thresholds bạn đã học. Bạn chỉ đổi lệnh k6 run script.js thành k6 cloud run script.js (cú pháp mới; bản cũ là k6 cloud script.js). Nền tảng nhận diện các nhà cung cấp cloud (AWS) và cho chọn load zone. Dashboard đẹp, tích hợp sẵn hệ sinh thái Grafana.

BlazeMeter. Nền tảng thương mại (thuộc Perforce) mạnh về JMeter. Nó chạy được file .jmx gốc của JMeter mà gần như không cần sửa, ngoài ra còn hỗ trợ Gatling, Locust, Selenium, và cả k6. BlazeMeter là lựa chọn phổ biến ở doanh nghiệp lớn vì có báo cáo doanh nghiệp, quản lý team, tích hợp CI phong phú. Điểm mạnh lớn nhất: nếu tổ chức bạn đã đầu tư hàng trăm file .jmx, BlazeMeter cho phép đưa lên cloud mà không viết lại.

Khái niệm chi phí: VUh (Virtual User hours)

Đây là thứ quyết định hóa đơn của bạn, và cũng là thứ người mới hiểu sai nhiều nhất. Các nền tảng cloud tính tiền theo VUh — Virtual User hours (số VU nhân số giờ chạy). Ví dụ: 10.000 VU chạy trong 30 phút = 10.000 × 0,5 = 5.000 VUh. Một số nền tảng còn nhân hệ số phụ trội cho VU quy mô lớn. Ghi nhớ công thức này, vì nó là chìa khóa để không "cháy túi".

Tình huống thực tế

Ví dụ 1 — Sàn TMĐT chuẩn bị Flash Sale 12.12 (bối cảnh Việt Nam)

Một sàn thương mại điện tử tầm trung ở TP.HCM, tạm gọi là "ShopViet", dự kiến đợt 12.12 sẽ có khoảng 80.000 người dùng đồng thời trong 15 phút vàng khi mở deal. Team QA ban đầu chạy k6 từ một server nội bộ 16 core. Kết quả: đến khoảng 12.000 VU thì chính con server tạo tải nghẽn CPU 100%, latency đo được tăng vọt — nhưng đó là do máy phát tải yếu, không phải do ứng dụng.

Họ chuyển sang k6 Cloud, cấu hình options với phân bổ load zone: 70% traffic từ Singapore, 20% từ Tokyo, 10% từ Mumbai (mô phỏng cả người dùng nội địa lẫn Việt kiều). Ở 80.000 VU thật, họ phát hiện điểm nghẽn thật nằm ở tầng database khi tồn kho sản phẩm hot bị lock hàng loạt — điều mà bài test 12.000 VU trước đó không bao giờ chạm tới.

Bài học: self-hosted không chỉ không đủ tải, nó còn cho số liệu sai lệch vì máy phát tải trở thành bottleneck giả. Cloud tách bạch được "lỗi của hệ thống" khỏi "lỗi của công cụ test".

Ví dụ 2 — Ngân hàng số dùng BlazeMeter để tái sử dụng tài sản JMeter

Một ngân hàng số ở Đông Nam Á có sẵn hơn 200 kịch bản JMeter .jmx được viết trong nhiều năm cho các API chuyển khoản, tra cứu số dư, mở tài khoản. Đội performance được yêu cầu kiểm thử tải cho đợt ra mắt tính năng mới, quy mô 40.000 VU, nhưng không có ngân sách viết lại toàn bộ sang k6.

Họ chọn BlazeMeter: upload thẳng các file .jmx, cấu hình số engine (mỗi engine mô phỏng một lượng VU nhất định), chọn multi-region, và chạy. Nhờ tái sử dụng tài sản cũ, họ tiết kiệm được hàng tuần công viết lại. BlazeMeter còn tự động tổng hợp báo cáo dạng doanh nghiệp mà bộ phận tuân thủ (compliance) yêu cầu.

Bài học: chọn nền tảng cloud không chỉ dựa trên "cái nào hiện đại nhất", mà dựa trên tài sản test hiện có của tổ chức. Đã lỡ đầu tư JMeter thì BlazeMeter giảm ma sát; team mới bắt đầu thì k6 Cloud gọn hơn.

Ví dụ 3 — Startup fintech "cháy túi" vì để test chạy quên tắt

Một startup fintech nhỏ dùng gói dùng thử k6 Cloud để test API thanh toán. Một kỹ sư cấu hình soak test (test chịu đựng lâu) nhưng vô tình đặt duration thành nhiều giờ với 20.000 VU và... về nhà. Test chạy suốt đêm. Sáng hôm sau, họ nhận ra đã tiêu gần hết quota VUh của cả tháng chỉ trong một lần chạy quên tắt.

Bài học: VUh là tiền thật. Luôn tính trước ngân sách VUh, đặt giới hạn, và với các test dài phải có người theo dõi hoặc dùng cơ chế abort tự động. Cloud mạnh nhưng "vòi tiền" cũng mở theo.

Hướng dẫn từng bước

Dưới đây là quy trình đưa một test k6 lên k6 Cloud — cách phổ biến nhất cho người đã học k6 ở các bài trước.

Bước 1 — Đăng ký và lấy token. Tạo tài khoản trên Grafana Cloud (có gói free với hạn mức VUh nhất định để làm quen). Vào phần k6, lấy API token của bạn.

Bước 2 — Đăng nhập CLI. Chạy:

k6 cloud login --token <YOUR_TOKEN>

Lệnh này lưu token vào máy để các lần chạy sau không cần nhập lại.

Bước 3 — Khai báo load zones trong script. Đây là bước biến test một-region thành đa-region. Thêm khối ext.loadimpact vào options:

export const options = {
  stages: [
    { duration: '2m', target: 10000 },
    { duration: '5m', target: 10000 },
    { duration: '2m', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<800'],
    http_req_failed: ['rate<0.01'],
  },
  ext: {
    loadimpact: {
      name: 'ShopViet 12.12 Load Test',
      distribution: {
        singapore: { loadZone: 'amazon:sg:singapore', percent: 70 },
        tokyo:     { loadZone: 'amazon:jp:tokyo', percent: 20 },
        mumbai:    { loadZone: 'amazon:in:mumbai', percent: 10 },
      },
    },
  },
};

Lưu ý cách thresholds (bạn đã học ở bài 16) vẫn hoạt động y nguyên trên cloud — chúng trở thành SLA gate quyết định test pass hay fail.

Bước 4 — Chạy trên cloud. Thay vì k6 run, dùng:

k6 cloud run script.js

k6 sẽ upload script, khởi tạo load generator ở các zone bạn chọn, chạy test, và in ra một URL dashboard trực tiếp.

Bước 5 — Theo dõi realtime và đọc kết quả. Mở URL dashboard. Bạn thấy biểu đồ latency, throughput, error rate theo thời gian thực, tách theo từng load zone. Đây là lúc bạn quan sát ứng dụng "gãy" ở ngưỡng nào.

Bước 6 — Với BlazeMeter (nếu dùng JMeter). Quy trình tương tự về tinh thần: đăng nhập web UI, tạo một Test, upload file .jmx, chọn số engine và các location, đặt số VU và thời lượng, nhấn Run. BlazeMeter cũng có plugin để kích hoạt test từ CI.

Bước 7 — Ước tính chi phí TRƯỚC khi chạy. Luôn tính: VU × giờ = VUh. Với ví dụ trên (10.000 VU, tổng ~9 phút ≈ 0,15 giờ) ≈ 1.500 VUh. So con số này với quota gói bạn đang dùng trước khi bấm Run.

Lỗi thường gặp & mẹo

Lỗi 1 — Không "smoke test" trước khi bắn lớn. Đừng bao giờ chạy thẳng 100.000 VU. Luôn chạy một smoke test 1–5 VU trên cloud trước để chắc script không lỗi, không sai endpoint, checks đúng. Bắn lớn với một script hỏng vừa tốn VUh vừa cho kết quả vô nghĩa.

Lỗi 2 — Vô tình DDoS hệ thống production của chính mình (hoặc của người khác). Cloud phát tải rất mạnh. Chỉ test trên môi trường bạn được phép, ưu tiên staging giống production. Nếu bắt buộc test production, phải báo trước cho team hạ tầng, nhà cung cấp cloud, và whitelist IP của load generator để không kích hoạt hệ thống chống DDoS. Test không xin phép có thể vi phạm điều khoản dịch vụ và cả pháp luật.

Lỗi 3 — Quên tắt / để test chạy quá lâu. Như ví dụ startup fintech ở trên. Đặt duration rõ ràng, dùng threshold để tự abort khi error rate vượt ngưỡng, và không bỏ đi khi test dài đang chạy.

Lỗi 4 — So sánh táo với cam giữa các region. Latency từ zone Mumbai đến server Singapore đương nhiên cao hơn từ zone Singapore. Khi đọc số liệu, luôn tách theo từng load zone, đừng gộp một con số trung bình rồi hoảng loạn.

Mẹo — Dùng cloud có chọn lọc. Không phải test nào cũng cần cloud. Test nhỏ hằng ngày, smoke test trong CI cứ chạy local cho nhanh và miễn phí. Chỉ đẩy lên cloud khi cần quy mô lớn, đa vùng, hoặc báo cáo chia sẻ. Cloud là "vũ khí hạng nặng", không phải công cụ dùng mỗi ngày.

Mẹo — Chốt phân bổ region từ dữ liệu analytics thật. Đừng đoán tỷ lệ traffic theo cảm tính. Lấy số liệu từ Google Analytics hoặc log để biết người dùng thật đến từ đâu, rồi cấu hình distribution khớp với thực tế. Test giống production ở điểm này mới ra kết quả đáng tin.

Bài tập thực hành

Đăng ký gói free. Tạo tài khoản Grafana Cloud k6, đăng nhập CLI bằng k6 cloud login, và ghi lại hạn mức VUh của gói free bạn nhận được.

Chuyển một test lên cloud. Lấy một script k6 đơn giản bạn đã viết ở các bài trước (ví dụ test một GET endpoint công khai như https://test.k6.io). Thêm khối ext.loadimpact với ít nhất 2 load zone, chạy k6 cloud run, và mở dashboard.

Bài toán ước tính chi phí. Bạn cần test 30.000 VU trong 20 phút. Tính số VUh cần dùng. Nếu gói của bạn có 5.000 VUh/tháng, bạn chạy được bài test này bao nhiêu lần trong tháng? (Đáp án: 30.000 × (20/60) = 10.000 VUh — vượt quá quota tháng, không chạy nổi dù chỉ một lần; bạn cần nâng gói hoặc giảm quy mô.)

So sánh multi-region. Chạy cùng một test với hai cấu hình distribution khác nhau (ví dụ 100% Singapore so với 50% Singapore + 50% Mumbai). Ghi lại chênh lệch p95 latency giữa hai lần và giải thích vì sao.

Tình huống quyết định. Tổ chức của bạn có 150 file .jmx JMeter đang dùng và cần test 60.000 VU cho đợt ra mắt. Viết một đoạn ngắn (5–7 câu) lập luận nên chọn k6 Cloud hay BlazeMeter, và vì sao.

Tóm tắt

Self-hosted load testing gãy ở ba giới hạn: tài nguyên một máy, một IP nguồn, một region — khiến máy phát tải trở thành bottleneck giả và số liệu sai lệch.
Cloud load testing thuê hộ bạn đội load generator đa vùng, tự scale, mỗi máy IP riêng, gom kết quả về dashboard tập trung — mở khóa quy mô 100.000+ VU và mô phỏng traffic đúng phân bố người dùng thật.
k6 Cloud (Grafana Cloud k6): liền mạch nếu bạn đã viết k6, chỉ cần k6 cloud run và thêm ext.loadimpact với các load zone. BlazeMeter: mạnh cho tổ chức đã đầu tư JMeter .jmx, chạy file gốc gần như không cần sửa.
Chi phí tính theo VUh (VU × giờ) — luôn ước tính trước khi bấm Run để không cháy quota.
Ba nguyên tắc sống còn: smoke test trước khi bắn lớn, không tự DDoS / phải xin phép và whitelist, và không để test chạy quên tắt.
Cloud là vũ khí hạng nặng: dùng cho quy mô lớn và đa vùng; test nhỏ hằng ngày cứ chạy local cho nhanh và miễn phí.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi