AWS Lambda Web Functions tính phí bộ nhớ 5-7 phút sau request cuối

AWS Lambda Web Functions tính phí bộ nhớ 5–7 phút sau request cuối

AWS Lambda Web Functions vẫn tính phí bộ nhớ cho môi trường thực thi (execution environment) trong khoảng 5–7 phút sau khi request cuối cùng kết thúc, dù không có lưu lượng nào đi qua. Phát hiện này khiến Easel.sh quyết định tự vận hành hạ tầng compute thay vì dùng dịch vụ mới của AWS.

Vấn đề nằm ở khoảng thời gian chờ

Khi AWS công bố Lambda Web Functions vào tháng 10, đội ngũ Easel khá hào hứng. Trước đó họ đã dành nhiều tháng xây dựng hạ tầng để chạy ứng dụng web trên Lambda truyền thống, nên các tính năng như HTTP server gốc, xử lý request đồng thời và tính phí theo CPU hoạt động đúng là thứ họ tìm kiếm.

Các thử nghiệm ban đầu khá khả quan: Web Functions xử lý được 300 request đồng thời mà không lỗi, một function mới phục vụ request trong chưa đầy 9 giây. Nhưng vấn đề xuất hiện khi đo thời gian sống của môi trường nhàn rỗi.

AWS có ghi trong tài liệu rằng Web Functions tính phí bộ nhớ trong suốt vòng đời của môi trường thực thi, kể cả khi không có request nào chạy. Tuy nhiên, tài liệu không nêu rõ môi trường nhàn rỗi sẽ tồn tại bao lâu trước khi bị chấm dứt.

Trong thử nghiệm trên sáu môi trường đại diện, Easel đo được các khoảng nhàn rỗi kéo dài 313–411 giây (khoảng 5–7 phút), và không có cấu hình idle timeout nào để rút ngắn lại.

Với một request 200ms rồi sau đó là 345 giây không hoạt động, thời gian bộ nhớ bị tính phí gấp khoảng 1.700 lần thời gian xử lý request.

Đối chiếu với CloudWatch và AWS Cost Explorer, bộ nhớ chiếm khoảng 88% chi phí compute và request tính theo giá niêm yết, dù ứng dụng chỉ dùng khoảng 160–210 MB. Toàn bộ thử nghiệm chỉ tốn khoảng hai cent, nên với ứng dụng có lưu lượng đều đặn thì con số này không đáng lo — cùng một môi trường có thể phục vụ nhiều request và chia nhỏ chi phí bộ nhớ nhàn rỗi.

Nhưng Easel cần hỗ trợ hàng nghìn ứng dụng có lưu lượng khó đoán, trong đó nhiều ứng dụng chỉ nhận vài request mỗi ngày. Nhân con số đó lên hàng nghìn triển khai độc lập, bài toán kinh tế trở nên rất khác.

Easel từng thử tự chấm dứt môi trường sau 10 giây không hoạt động. Cách này giảm thời gian môi trường bị tính phí khoảng 20 lần, nhưng AWS ghi nhận mọi lần thoát có chủ ý là lỗi runtime, nên không thể dùng trong môi trường production.

Tự vận hành compute và kết quả benchmark

Thay vì dùng Web Functions, Easel chuyển việc thực thi ứng dụng lên các server do chính họ vận hành, giữ Lambda truyền thống làm phương án dự phòng khi quá tải. Cách này cho họ kiểm soát việc lập lịch và phân bổ tài nguyên, chia sẻ công suất giữa các ứng dụng mà không phải trả tiền cho từng môi trường nhàn rỗi.

Máy chủ compute tự vận hành đầu tiên đi vào hoạt động tại US East ngày 2/11, phục vụ cả website của Easel. Để so sánh, họ triển khai cùng một ứng dụng Next.js 16 lên cả hai nền tảng và chạy benchmark từ một máy khách ở Ashburn, Virginia.

Kết quả về request warm (môi trường đã khởi động sẵn):

• API JSON: 9,3ms trên Easel so với 27,0ms trên Web Functions, nhanh hơn 2,9 lần
• Server-side rendering: 12,2ms so với 26,0ms, nhanh hơn 2,1 lần
• Streaming (chunk đầu tiên): 9,1ms so với 18,1ms, nhanh hơn 2,0 lần
• API tốn CPU: 39,7ms so với 61,4ms, nhanh hơn 1,5 lần

Khác biệt không chỉ đến từ độ trễ mạng hay routing. Cùng một phép tính 20.000 lần băm SHA-256 nối tiếp mất 29,2ms trên máy chủ của Easel so với 43,8ms trên Web Functions, tức nhanh hơn khoảng 1,5 lần.

Về cold start (khởi động lạnh), sau khi để cả hai ứng dụng nhàn rỗi 12 phút, Easel phản hồi request đầu tiên trong 216–250ms, còn Web Functions mất 810–854ms, tức nhanh hơn khoảng 3,5 lần.

Đáng chú ý hơn, sau khoảng nhàn rỗi 5 phút, Web Functions đã chấm dứt môi trường và cần 908ms để phản hồi, trong khi Easel chỉ tạm dừng môi trường và trả lời trong 14ms.

Easel thừa nhận đây là kết quả sớm từ một vùng duy nhất và một ứng dụng nhỏ, chưa phải nghiên cứu hiệu năng toàn diện. So sánh cold start chỉ có hai lần thử ghép cặp và họ chưa benchmark thông lượng duy trì. Các nền tảng cũng chạy trên phần cứng và cấu hình tài nguyên khác nhau, nên đây là so sánh giữa hai triển khai chứ không phải so sánh phần cứng chuẩn hóa.

Góc nhìn

Với các đội phát triển ở Việt Nam đang cân nhắc serverless cho ứng dụng web, đây là lời nhắc rằng chi phí thực tế không chỉ nằm ở thời gian xử lý request. Nếu sản phẩm có nhiều ứng dụng nhỏ, lưu lượng thưa hoặc không đều — ví dụ các bản demo, môi trường staging hay dịch vụ nội bộ ít người dùng — phần bộ nhớ bị tính phí trong lúc nhàn rỗi có thể chiếm phần lớn hóa đơn.

Trước khi chọn nền tảng, nên đo trực tiếp thời gian sống của môi trường thực thi bằng dữ liệu CloudWatch và Cost Explorer thay vì chỉ dựa vào tài liệu. Với hệ thống có lưu lượng ổn định, mô hình tính phí này ít ảnh hưởng hơn nhiều, nên quyết định tự vận hành compute hay không cần dựa trên hình thái lưu lượng cụ thể của từng dự án.