Stress Test trong phát triển mobile: định nghĩa, mục tiêu và cách thực hiện

Stress Test là gì?

Stress Test (kiểm thử stress) — là quá trình đánh giá khả năng hoạt động của hệ thống trong điều kiện vượt quá các chỉ số tính toán. Đối với ứng dụng di động, điều này có thể là 10000 thông báo push đồng thời so với định mức 1000, đối với backend — 50000 RPS so với 5000 dự kiến. Sự khác biệt chính của Stress Test so với Load Test là mục tiêu không phải xác nhận hiệu năng mà là nghiên cứu hành vi của hệ thống vượt quá công suất thiết kế. Netflix Engineering (2024) định nghĩa Stress Test là “kiểm tra giả thuyết rằng hệ thống sẽ hỏng theo cách có thể dự đoán trước”.

Kiểm thử stress bao gồm hai giai đoạn bắt buộc: tải đến khi hỏng và quan sát phục hồi. Phục hồi (recovery) — khả năng hệ thống trở lại hoạt động bình thường sau khi loại bỏ quá tải. Hệ thống không thể phục hồi mà không khởi động lại được coi là dễ vỡ, ngay cả khi nó chịu được quá tải ngắn hạn. Theo AWS Well-Architected Framework (2024), thời gian phục hồi sau Stress Test không quá 5 phút.

Đối với client di động, Stress Test bao gồm kiểm tra hoạt động khi kết thúc tiến trình cưỡng bức, ngắt kết nối mạng và cạn kiệt RAM. Android Low Memory Killer có thể kết thúc tiến trình nền khi thiếu RAM — kiểm thử stress phải đảm bảo ứng dụng khôi phục đúng trạng thái sau khi kết thúc như vậy. Apple UIKit (2024) khuyến nghị kiểm tra kịch bản cảnh báo bộ nhớ trên mỗi màn hình ứng dụng.

Mục tiêu kiểm thử stress

Xác định điểm lỗi

Mục tiêu đầu tiên của Stress Test là xác định điểm lỗi (breaking point). Đó là thời điểm một trong các chỉ số hiệu năng chính vượt ngưỡng nghiêm trọng: thời gian phản hồi p95 vượt 10 giây, tỷ lệ lỗi HTTP 5XX vượt 5% hoặc thông lượng giảm dưới 50% so với baseline. Ghi nhận điểm lỗi cho phép nhóm biết trước giới hạn mở rộng của hệ thống. Lập kế hoạch dung lượng dựa trên dữ liệu Stress Test chứ không phải Load Test vì Load Test không kiểm tra điều kiện biên.

Kiểm tra cơ chế phục hồi

Mục tiêu thứ hai là kiểm tra cơ chế phục hồi. Sau khi tải giảm xuống mức bình thường, hệ thống phải trở lại các chỉ số tiêu chuẩn. Nếu pool kết nối cơ sở dữ liệu không được giải phóng hoặc bộ nhớ đệm không được vô hiệu hóa, Stress Test sẽ phát hiện vấn đề này. Circuit breaker (Hystrix, Resilience4j) phải kích hoạt khi quá tải và tự động khôi phục kết nối sau khi ổn định. Điểm cuối Health check giúp giám sát trạng thái từng dịch vụ trong quá trình kiểm tra.

Xác thực auto-scaling

Mục tiêu thứ ba là xác thực auto-scaling. Nếu hạ tầng sử dụng Kubernetes hoặc AWS Auto Scaling, Stress Test kiểm tra rằng pod hoặc instance mới được tạo đủ nhanh. Theo Google Kubernetes Engine (2024), thời gian triển khai pod mới không quá 30 giây kể từ khi kích hoạt metric HPA (Horizontal Pod Autoscaler). HPA phải mở rộng dựa trên CPU, bộ nhớ và metric tùy chỉnh. Cluster Autoscaler thêm node mới nếu node hiện tại không chứa được pod.

Phương pháp Stress Test

Tăng dần tải (Ramp-up Stress Test) — kịch bản phổ biến nhất. Tải ban đầu đặt ở mức 50% tải dự kiến, sau đó cứ 2 phút tăng 10% cho đến khi hệ thống hỏng. Kịch bản này cho phép tìm chính xác ranh giới ổn định. Grafana Cloud k6 (2025) khuyến nghị mức tăng không quá 10% để có biểu đồ thời gian phản hồi mượt.

Tăng đột biến tải (Spike Stress Test) — tải tăng từ 10% lên 500% trong 10–30 giây. Kịch bản này mô phỏng tình huống như lan truyền nội dung lan truyền hoặc tấn công DDoS. Spike Stress Test kiểm tra không phải hiệu năng mà là khả năng sống sót của hệ thống: khả năng không sụp đổ hoàn toàn và trở lại hoạt động sau khi ổn định. API Gateway phải cấu hình giới hạn tốc độ để bảo vệ backend khỏi các đột biến.

Duy trì quá tải kéo dài (Sustained Stress Test) — hệ thống duy trì trạng thái quá tải trong 30–60 phút. Kịch bản này phát hiện rò rỉ tài nguyên không xuất hiện trong các kiểm tra ngắn hạn. Rò rỉ bộ nhớ trong ứng dụng Java/Kotlin tích tụ trong 20–40 phút hoạt động cường độ và chỉ Sustained Stress Test phát hiện được.

Phân tích điểm lỗi và phục hồi

Điểm lỗi được xác định theo ba tiêu chí: thời gian phản hồi, tỷ lệ lỗi và thông lượng. Thông thường, ngưỡng thời gian phản hồi bị vượt trước — yêu cầu bắt đầu xử lý lâu hơn giới hạn đã đặt. Sau đó tỷ lệ lỗi tăng: máy chủ không xử lý kịp yêu cầu và trả về 503. Cuối cùng, Throughput giảm — hệ thống không xử lý được ngay cả tải tối thiểu. Metric điểm lỗi được ghi lại trong hồ sơ tải để lập kế hoạch dung lượng.

Phân tích phục hồi bao gồm ba giai đoạn: phản ứng ngay lập tức (30 giây đầu sau khi loại bỏ tải), ổn định (1–5 phút) và phục hồi hoàn toàn (5–30 phút). Trong giai đoạn phản ứng ngay lập tức, thời gian phản hồi phải giảm dưới baseline — hệ thống được giải phóng khỏi hàng đợi. Nếu không xảy ra, vấn đề không phải ở tải mà ở trạng thái tích lũy. Suy giảm êm (Graceful degradation) — khả năng hệ thống duy trì chức năng một phần khi quá tải — là chỉ số chính về độ trưởng thành của kiến trúc.

Chaos Engineering bổ sung cho Stress Test bằng cách cố tình đưa lỗi vào: tắt máy chủ cơ sở dữ liệu, làm chậm mạng, dừng microservice. Chaos Monkey của Netflix (2024) ngẫu nhiên kết thúc tiến trình trong production, kiểm tra độ bền của hệ thống. Đối với ứng dụng di động, Chaos Engineering nghĩa là kiểm tra kịch bản: không có mạng, API không khả dụng, phản hồi trống từ máy chủ.

Công cụ cho Stress Test

k6 với ramping-arrival-rate

k6 hỗ trợ Stress Test qua module `execution` với cấu hình ramping-arrival-rate. Chế độ này tăng số lượng yêu cầu mỗi giây bất kể thời gian thực hiện của từng yêu cầu. So với Load Test, Stress Test trong k6 yêu cầu cấu hình threshold mạnh hơn và tắt gracefull-stop để mô phỏng lỗi đột ngột. Grafana Cloud tự động phát hiện điểm lỗi theo điểm gãy của biểu đồ thời gian phản hồi. k6-operator cho Kubernetes cho phép chạy Stress Test phân tán từ cluster.

JMeter với Ultimate Thread Group

JMeter cho phép cấu hình Stress Test qua Ultimate Thread Group — plugin xác định hồ sơ tải dưới dạng bảng: số luồng, thời gian khởi động, thời gian duy trì, thời gian hạ nhiệt. Ultimate Thread Group tiện cho các kịch bản đa pha phức tạp. JMeter Backend Listener gửi metric đến InfluxDB để xây dựng biểu đồ điểm lỗi. Đối với Stress Test, nên tắt timeout kết nối trong JMeter để đo hành vi chính xác hơn khi quá tải.

Gremlin cho Chaos Engineering

Gremlin — nền tảng Chaos Engineering cho Stress Test hạ tầng. Gremlin cho phép ngắt mạng, tải CPU, làm đầy đĩa và kết thúc tiến trình ở mức pod Kubernetes riêng lẻ. Nhóm SRE sử dụng Gremlin cùng k6 để Stress Test toàn diện: k6 tạo tải, Gremlin đưa lỗi vào. Game Day — các phiên Stress Test định kỳ sử dụng Gremlin, được ghi nhận trong “chaos report” để phân tích độ bền của hệ thống.

Ví dụ Stress Test trên k6

Kịch bản k6 dưới đây thể hiện Stress Test với tăng dần tải đến khi hỏng. Ramping-arrival-rate tăng số lượng yêu cầu mỗi giây bất kể thời gian thực hiện. Threshold được cấu hình để phát hiện suy thoái mạnh: p95 không quá 2000 ms, tỷ lệ lỗi không quá 5%. Khi vượt ngưỡng, k6 kết thúc kiểm tra với mã lỗi, cho phép tích hợp Stress Test vào đường ống CI/CD.

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

export const options = {
    scenarios: {
        stress: {
            executor: 'ramping-arrival-rate',
            startRate: 50,
            timeUnit: '1s',
            stages: [
                { duration: '2m', target: 200 },
                { duration: '5m', target: 500 },
                { duration: '2m', target: 1000 },
            ],
            preAllocatedVUs: 50,
            maxVUs: 200,
        },
    },
    thresholds: {
        http_req_duration: ['p(95)<2000'],
        http_req_failed: ['rate<0.05'],
    },
}

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

Thực hành tốt nhất kiểm thử stress

Bắt đầu Stress Test trên staging — kiểm thử stress trên production yêu cầu giám sát nâng cao và kế hoạch rollback. Google SRE (2024) khuyến nghị thực hiện Stress Test trong môi trường cách ly 100% sao chép production về kiến trúc và dung lượng. Sau khi kiểm tra thành công trên staging, có thể chuyển sang production dưới sự giám sát của SRE. Feature flag để tắt chức năng khi quá tải là yếu tố bắt buộc.

Tự động hóa Stress Test trong CI/CD để phân tích hồi quy điểm lỗi. Nếu phiên bản ứng dụng mới có điểm lỗi thấp hơn 20% so với phiên bản trước, đó là hồi quy cần sửa trước khi phát hành. Baseline breaking point được lưu trong metric và tự động so sánh với kết quả từng Stress Test. Cảnh báo kích hoạt khi điểm lỗi giảm 10%.

Ghi lại từng Stress Test: hồ sơ tải, điểm lỗi, hành vi phục hồi và danh sách vấn đề đã phát hiện. Netflix Engineering (2024) tổ chức “Game Day” — các phiên Stress Test định kỳ, kết quả được ghi nhận trong “chaos report”. Báo cáo kiểm thử stress phải chứa biểu đồ “RPS — thời gian phản hồi” với điểm lỗi được đánh dấu.