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 EC2 Worker và SQS)
2. Kiến 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. Giám sát EC2 Worker và hàng đợi SQS
6. Phân tích kết quả và đánh giá hệ thống
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 EC2 Worker và SQS)

Khi hệ thống xử lý theo mô hình bất đồng bộ (asynchronous) — trong đó API nhận dữ liệu, đẩy vào hàng đợi (queue), và worker chạy nền (trên EC2) xử lý dần — việc đánh giá khả năng chịu tải không chỉ là đo tốc độ phản hồi API mà là đánh giá toàn bộ chuỗi xử lý message.

Stress test giúp xác định hệ thống có thể hấp thụ và xử lý bao nhiêu message mỗi giây, khi worker EC2 thực thi song song trên nhiều thread. Đây là bài test quan trọng để tối ưu số lượng instance, cấu hình thread pool và giới hạn throughput của hàng đợi SQS.

Đo thời gian trung bình để xử lý một lượng lớn message.
Xác định giới hạn throughput trước khi queue backlog.
Phát hiện điểm nghẽn (bottleneck) ở tầng API, SQS hoặc Worker.
Đánh giá mức ổn định và khả năng phục hồi khi tải giảm.

2. Kiến trúc hạ tầng dùng để stress test

Dưới đây là kiến trúc tham chiếu của hệ thống AWS EC2 Worker & SQS trong bài test:

Thành phần	Vai trò	Ghi chú khi test
API Gateway	Nhận request từ JMeter và đẩy payload vào SQS.	Bật log để theo dõi tốc độ gửi và lỗi HTTP.
Amazon SQS	Hàng đợi lưu message cần xử lý.	Dùng Standard Queue để đạt throughput cao nhất.
EC2 Worker (Java)	Ứng dụng Java chạy trên EC2, đọc message từ SQS và xử lý nghiệp vụ.	Chạy nhiều thread song song; điều chỉnh thread pool để tối ưu hiệu năng.
Amazon RDS	Lưu kết quả xử lý hoặc log hệ thống.	Tối ưu connection pool (HikariCP hoặc datasource) để tránh quá tải.
CloudWatch	Thu thập metric từ SQS và EC2.	Theo dõi CPU, queue depth, backlog, throughput.

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

Dữ liệu test cần mô phỏng hành vi thật của hệ thống, bao gồm payload gửi vào API và cấu hình tốc độ bắn tải. Thông thường, các test case được lưu trong file Excel — mỗi sheet là một loại test (load, spike, stability…).

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	Đo 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 nhanh
`Stable_10000_300`	10000	300	~33	Đánh giá độ ổn định dài hạn

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

Công cụ được sử dụng là Apache JMeter — chuyên dùng để tạo tải HTTP và kiểm tra hiệu năng API. Mỗi request được gửi tới API Gateway, sau đó dữ liệu được đẩy vào hàng đợi SQS để worker EC2 xử lý.

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()}",
    "payload": "${__RandomString(32,ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890)}",
    "timestamp": "${__time(yyyy-MM-dd'T'HH:mm:ss)}"
  }

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

Chạy test bằng chế độ non-GUI để tiết kiệm tài nguyên:

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

Nếu cần mô phỏng tăng tải dần, bạn có thể dùng plugin Stepping Thread Group để tăng số luồng từng giai đoạn, giúp kết quả thực tế hơn.

5. Giám sát EC2 Worker và hàng đợi SQS

Trong quá trình test, CloudWatch là công cụ chính để giám sát hệ thống. Các metric cần chú ý:

Metric	Nguồn	Ý nghĩa
`ApproximateNumberOfMessagesVisible`	SQS	Số message đang chờ xử lý. 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 tăng nhanh → có backlog.
`CPUUtilization`	EC2	Theo dõi mức sử dụng CPU của worker Java.
`NetworkIn/Out`	EC2	Lưu lượng xử lý qua API hoặc đọc/ghi dữ liệu.
`DBConnections`	RDS	Số kết nối tới cơ sở dữ liệu. Nếu tăng đột biến → nghẽn kết nối.

6. Phân tích kết quả và đánh giá hệ thống

Sau khi test, cần đối chiếu kết quả từ JMeter (thời gian phản hồi, throughput) với metric từ CloudWatch (queue depth, CPU, backlog). Một hệ thống tốt là khi:

Queue depth không tăng mãi, mà dao động quanh ngưỡng ổn định.
CPU trên EC2 được sử dụng hiệu quả (~60–80%), không nghẽn 100% liên tục.
Throughput duy trì ổn định trong suốt thời gian test.
Số message trong DLQ = 0 hoặc rất thấp.

7. Kết luận

Stress test trên AWS EC2 Worker và SQS giúp bạn hiểu được giới hạn chịu tải của hệ thống cũng như khả năng tự phục hồi sau khi backlog. Khi theo dõi đúng metric và xác định rõ “ngưỡng nghẽn” (bottleneck), bạn có thể điều chỉnh thread pool, số lượng EC2 instance hoặc kích thước hàng đợi để đạt hiệu suất tối ưu.