Stress Test with AWS Worker

Table of Contents Hide

1. Mục tiêu của stress test chịu tải trong hệ thống AWS Worker và SQS
2. Cấu trúc hạ tầng dùng để stress test
3. Chuẩn bị dữ liệu test
1. Ví dụ: Kết quả thực tế Case 1 (500 threads / 60 giây)
4. Cấu hình JMeter để gửi dữ liệu lên AWS
5. Ví dụ Worker Lambda (Python)
6. Phân tích và đánh giá kết quả
7. Kết luận
1. Tài liệu tham khảo

1. Mục tiêu của stress test chịu tải trong hệ thống AWS Worker và SQS

Khi triển khai ứng dụng theo mô hình serverless (không có máy chủ cố định, AWS tự động tạo hoặc dừng worker tùy theo tải), khái niệm “chịu tải” không còn phụ thuộc vào CPU hay RAM của một máy chủ đơn lẻ.

Thay vào đó, điều quan trọng là khả năng hệ thống hấp thụ (nhận message) và xử lý (xử lý message) với khối lượng lớn dữ liệu trong môi trường phi đồng bộ thông qua hàng đợi (queue).

Mục tiêu của stress test là kiểm tra khả năng hoạt động của hệ thống khi “bơm” một lượng lớn dữ liệu vào Amazon SQS (Simple Queue Service). Cụ thể, hệ thống cần đảm bảo:

Xử lý toàn bộ message trong thời gian chấp nhận được.
Duy trì tốc độ xử lý ổn định khi tải tăng cao.
Tự phục hồi sau khi tải giảm.
Không làm quá tải các thành phần phụ trợ như cơ sở dữ liệu hoặc API backend.

2. Cấu trúc hạ tầng dùng để stress test

Dưới đây là mô hình cơ bản của một hệ thống xử lý phi đồng bộ (asynchronous) trên AWS được sử dụng cho bài kiểm thử tải:

Thành phần	Vai trò	Ghi chú khi test
API Gateway	Nhận request HTTP từ công cụ test (JMeter, k6) và đẩy payload vào SQS.	Bật log để theo dõi tốc độ gửi và tỉ lệ lỗi.
Amazon SQS	Hàng đợi trung gian chứa message cần xử lý.	Dùng loại Standard Queue để đạt throughput cao nhất.
Lambda Worker / ECS Worker	Đọc message từ SQS và thực hiện xử lý nghiệp vụ.	Giới hạn concurrency để tránh làm nghẽn backend.
CloudWatch	Thu thập log và metric hiệu năng.	Theo dõi các chỉ số như queue depth, message age, invocations, throttles.
DLQ (Dead Letter Queue)	Lưu trữ các message bị lỗi sau nhiều lần retry.	Bắt buộc bật để không mất dữ liệu.

3. Chuẩn bị dữ liệu test

Trước khi tiến hành stress test, bạn cần chuẩn bị dữ liệu test phản ánh hành vi thực tế của hệ thống. Các tệp Excel thường được dùng để mô tả chi tiết từng kịch bản kiểm thử — ví dụ như “load test”, “spike test”, hoặc “long duration test”. Mỗi sheet trong file Excel tương ứng với một loại bài test.

Một số ví dụ về các kịch bản test cơ bản:

Tên test	Số request	Ramp-up time (giây)	Tốc độ gửi (req/s)	Mục tiêu
`Load_500_60`	500	60	~8	Đánh giá năng lực xử lý trung bình
`Spike_2000_60`	2000	60	~33	Kiểm tra phản ứng khi tải tăng đột ngột
`Stable_10000_300`	10000	300	~33	Đánh giá độ ổn định trong thời gian dài

Ví dụ: Kết quả thực tế Case 1 (500 threads / 60 giây)

Dưới đây là kết quả kiểm thử được ghi nhận (theo file Excel và log giám sát thực tế):

Trong bài test này (Case 1), hệ thống được giả lập với 500 người dùng đồng thời trong vòng 60 giây.

Kết quả cho thấy throughput trung bình đạt khoảng 8.3 requests/giây với 100% thành công, thời gian phản hồi trung bình là 227ms và cực đại là 307ms.

Điều này cho thấy hệ thống có khả năng xử lý ổn định ở mức tải trung bình.

Jmeter

EC2

Worker

RDS

SQS

Mẫu Jmeter setting

CSV Data Set Config:
  Filename: data_test.csv
  Variable Names: message_id,payload
  Recycle on EOF: True

HTTP Body:
{
  "messageId": "${message_id}",
  "payload": "${payload}",
  "timestamp": "${__time(yyyy-MM-dd'T'HH:mm:ss)}"
}

4. Cấu hình JMeter để gửi dữ liệu lên AWS

Thread Group:
  Number of Threads (users): 500
  Ramp-up Period: 60
  Loop Count: 1

HTTP Request Sampler:
  Method: POST
  URL: https://{api-id}.execute-api.{region}.amazonaws.com/prod/push
  Body Data:
  {
    "messageId": "${__UUID()}",
    "timestamp": "${__time(yyyy-MM-dd'T'HH:mm:ss)}",
    "payload": "${__RandomString(32,ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890)}"
  }

HTTP Header Manager:
  Content-Type: application/json
  x-api-key: ${API_KEY}

jmeter -n -t HTTPRequest_500_60_001.jmx -l results.csv -JAPI_KEY=xxxx

Nếu muốn mô phỏng tải tăng dần theo thời gian, bạn có thể sử dụng plugin Stepping Thread Group trong JMeter để tạo luồng người dùng thực tế hơn.

5. Ví dụ Worker Lambda (Python)

Dưới đây là ví dụ AWS Lambda Worker cơ bản đọc message từ SQS và xử lý payload. Worker nên được thiết kế stateless (không lưu trạng thái) để có thể mở rộng song song mà không gây xung đột.

import json
def lambda_handler(event, context):
    for record in event['Records']:
        body = json.loads(record['body'])
        message_id = body.get('messageId')
        payload = body.get('payload')
        print(f"Processing message {message_id} with payload length {len(payload)}")
        process_message(payload)
def process_message(data):
    # Mô phỏng xử lý nghiệp vụ
    return True

Tham số cấu hình	Giải thích	Khuyến nghị
`BatchSize`	Số lượng message Lambda đọc mỗi lần.	5–10 message/lần đọc là hợp lý.
`Reserved Concurrency`	Giới hạn số lượng Lambda chạy song song để bảo vệ backend.	Điều chỉnh theo giới hạn DB/API.
`VisibilityTimeout`	Thời gian message bị ẩn trước khi retry.	Gấp 6 lần thời gian xử lý trung bình.
`DLQ`	Hàng đợi chứa message lỗi sau nhiều lần retry.	Bắt buộc bật để không mất dữ liệu.

6. Phân tích và đánh giá kết quả

Sau khi test, hãy kiểm tra log và metric từ CloudWatch hoặc JMeter để đánh giá hệ thống. Các chỉ số quan trọng bao gồm:

Metric	Nguồn	Ý nghĩa
`ApproximateNumberOfMessagesVisible`	SQS	Số lượng message còn trong queue. Nếu tăng liên tục → worker xử lý không kịp.
`ApproximateAgeOfOldestMessage`	SQS	Tuổi của message lâu nhất trong queue. Nếu cao → hệ thống bị backlog.
`Lambda Invocations / Throttles`	Lambda	Theo dõi mức scale và giới hạn concurrency.
`DLQ Message Count`	SQS	Số lượng message lỗi, thể hiện độ ổn định của hệ thống.

7. Kết luận

Stress test không chỉ giúp bạn biết hệ thống chịu được bao nhiêu tải, mà quan trọng hơn — giúp bạn hiểu hệ thống phản ứng như thế nào khi tải tăng đột biến. Một hệ thống tốt không phải là hệ thống không bao giờ backlog, mà là hệ thống có khả năng backlog, mở rộng (scale up), rồi tự phục hồi (recover) an toàn.