CLOUD TESTING

Kiểm thử hiệu năng cloud phân tán: đặt tải và điểm đo ở đâu?

21/7/2026 · 16 phút

Các test agent phân tán tạo tải qua nhiều vùng cloud tới ứng dụng và dịch vụ
Mục lục bài viết 8 phần

Trong hybrid và multi-cloud, tải phát từ một điểm chỉ cho thấy một lát cắt. Cần đặt test agent và điểm đo theo hành trình người dùng để phân biệt giới hạn ứng dụng, cloud network, Internet, security tier và kết nối liên vùng.

ĐỌC NHANH

Bài viết giúp bạn

  • Vẽ service path trước khi tạo tải
  • Đặt load agent theo phân bố người dùng
  • Phân tách test objective
Tùy chỉnh đọc
01

Vẽ service path trước khi tạo tải

#

Mô tả client region, DNS/CDN, WAF, load balancer, gateway, service, database và dependency. Ghi rõ public/private path, peering, transit, NAT và egress.

Nếu không biết traffic đi đâu, kết quả latency không thể gắn với domain chịu trách nhiệm. Flow log, trace và packet capture có chọn lọc giúp xác nhận path.

02

Đặt load agent theo phân bố người dùng

#

Chọn region/site theo tỷ lệ người dùng và rủi ro. Một agent cùng region với server đo chủ yếu application tier; agent từ chi nhánh hoặc region khác bao gồm WAN/Internet và security path.

Kiểm tra quota CPU, network, ephemeral port và public IP của agent. Chạy calibration để chắc generator không chạm giới hạn trước SUT.

Các agent tạo tải phân tán từ nhiều vùng cloud tới ứng dụng
Kết quả đa vùng chỉ so sánh được khi đồng bộ thời gian và lưu đầy đủ metadata của đường đi.
03

Phân tách test objective

#

Capacity test tăng tải để tìm giới hạn; soak test giữ tải để tìm leak; spike test kiểm tra autoscaling; failover test gây lỗi có kiểm soát; network impairment test đánh giá resilience.

Không chạy tất cả cùng lúc. Mỗi phase có baseline, biến chính và expected behavior để kết quả có thể giải thích.

04

Quan sát xuyên lớp

#

Kết hợp client-side response percentile và error với load balancer metrics, application tracing, queue, database, cloud network và cost. Correlation ID và đồng bộ thời gian là bắt buộc.

Autoscaling event cần được đặt cạnh latency và error để thấy capacity xuất hiện đủ nhanh hay không. Average CPU thấp không loại trừ hot partition hoặc giới hạn connection pool.

05

Kiểm soát chi phí và an toàn

#

Ước lượng data transfer, agent compute, log ingestion và autoscaling trước khi chạy. Đặt budget alert, rate limit và stop condition.

Chỉ test endpoint được phép; dùng dữ liệu tổng hợp, account riêng, secrets ngắn hạn và cleanup sau bài đo. Tránh để test traffic làm ô nhiễm analytics hoặc gửi thông báo thật.

06

Báo cáo theo region và service path

#

Không gộp tất cả agent thành một số trung bình. Báo cáo per-region, percentile, success rate, throughput và path metadata, sau đó mới tổng hợp theo tỷ trọng người dùng.

Kết luận nên nêu bottleneck, headroom, thời gian scale, ảnh hưởng của network và chi phí tại mức tải mục tiêu; kèm test configuration để tái hiện sau thay đổi kiến trúc.

07

Đồng bộ thời gian và khả năng tái hiện đa vùng

#

Khi agent nằm ở nhiều region, chênh lệch clock làm sai correlation và one-way timing. Đồng bộ thời gian, ghi timezone/region/AZ, image version, instance type, network path và public/private endpoint cho từng agent.

Cloud thay đổi theo thời gian; neighbor, route, autoscaling và managed service có thể khác giữa các lần chạy. Lặp lại ở nhiều khung giờ, giữ infrastructure as code và đánh dấu mọi thay đổi để biết biến thiên đến từ hệ thống hay từ môi trường.

  • Clock sync và timestamp thống nhất
  • Immutable agent image và checksum test package
  • Region/AZ/path metadata trong từng sample
  • Warm-up connection, DNS và autoscaling trước steady state
08

Đọc kết quả cùng chi phí và giới hạn dịch vụ

#

Tại mỗi mức tải, báo cáo response percentile, error, throughput, saturation và chi phí phát sinh từ compute, data transfer, load balancer, logging và test agent. Một kiến trúc nhanh hơn nhưng chi phí tăng không kiểm soát chưa chắc là phương án tốt.

Kiểm tra quota, rate limit, connection tracking, NAT/SNAT, ephemeral port và managed-service ceiling. Stop condition và budget alert phải hoạt động trước khi chạy tải lớn; cleanup tài nguyên là một bước bắt buộc của test plan.

THUẬT NGỮ NHANH

Khái niệm cần nhớ

DUT / SUT
Thiết bị hoặc toàn bộ hệ thống đang là đối tượng của bài kiểm thử.
Steady state
Giai đoạn tải đã ổn định và đủ điều kiện để lấy số liệu đại diện.
Pass / fail
Kết luận dựa trên ngưỡng đã thống nhất, luôn đi cùng topology, cấu hình và điều kiện đo.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo1 nguồn

Nội dung được biên soạn độc lập, theo hướng vendor-neutral và đối chiếu các tài liệu gốc dưới đây. Tính năng sản phẩm cần được kiểm tra lại theo phiên bản đang sử dụng.

Nguyên tắc biên tập

NetVali ưu tiên nguồn tiêu chuẩn và tài liệu chính thức; phân biệt khuyến nghị triển khai với yêu cầu của tiêu chuẩn; không công bố thông số sản phẩm chưa gắn với phiên bản và điều kiện đo.

Thông số và khả năng sản phẩm có thể thay đổi theo phiên bản. Hãy đối chiếu tài liệu chính thức trước khi xây dựng cấu hình hoặc tiêu chí nghiệm thu.
BẮT ĐẦU TỪ BÀI TOÁN

Cần chuyển kiến thức thành test plan?

Chia sẻ mục tiêu, topology và ràng buộc kỹ thuật. NetVali sẽ cùng bạn xác định bài đo phù hợp.

Trao đổi yêu cầu kỹ thuật