Máy ảo và trình duyệt đám mây được tính phí theo thời gian nên các tác vụ hàng loạt rất dễ chạm hạn mức. Hãy ước tính mức tiêu thụ, xác định ngưỡng đồng thời thực tế và xử lý theo đúng thứ tự khi vượt hạn mức.
Với tài nguyên được tính phí theo thời gian, logic hóa đơn rất đơn giản: thời gian chạy nhân với số lượng phiên bản. Hạn mức là một giới hạn cứng. Khi chạm giới hạn, tác vụ không chỉ chậm đi mà có thể thất bại ngay: không tạo được phiên bản mới, phiên bản đang chạy có thể bị thu hồi và API bắt đầu trả lỗi giới hạn tần suất. Biết mình còn cách giới hạn bao xa hữu ích hơn nhiều so với chỉ tăng ngân sách sau khi sự cố đã xảy ra.
Trước tiên hãy phân biệt mức tiêu thụ nào là cần thiết
Cùng một hạn mức nhưng hiệu quả có thể khác rất nhiều tùy tác vụ sử dụng nó. Hãy bắt đầu bằng việc kiểm kê và chia tác vụ theo việc chúng có thực sự cần chạy theo thời gian thực hay không.
Các tác vụ chạy thường trực là nhóm dễ ngốn hạn mức nhất. Chúng có thể chạy cả ngày trong khi thời gian thực sự có việc chỉ vài phút. Chuyển giám sát thường trực thành kích hoạt theo lịch thường có thể cắt giảm đáng kể mức tiêu thụ mà gần như không ảnh hưởng đến hoạt động kinh doanh. Các tác vụ có đỉnh tải tập trung vào một số khung giờ có thể dịch sang giờ khác, còn tác vụ một lần chỉ cần khởi chạy khi cần.
Sau đó hãy tự hỏi: nếu tác vụ này chạy muộn hơn sáu giờ thì hoạt động kinh doanh có bị ảnh hưởng không? Nếu có, hãy giữ nó trên đường găng và chạy theo thời gian thực. Nếu không, hãy chuyển thành lô ưu tiên thấp và xếp vào khung giờ còn nhiều hạn mức. Trong phần lớn tình huống, giảm tần suất theo dõi giá đối thủ từ mỗi giờ một lần xuống hai lần mỗi ngày không làm giảm đáng kể giá trị thông tin.
Ước tính mức tiêu thụ và xác định độ đồng thời
Khi tính phí theo thời gian chạy của phiên bản, tổng mức tiêu thụ của một lô xấp xỉ thời lượng trung bình của một tác vụ nhân với số tác vụ. Nó không phụ thuộc vào mức đồng thời; đồng thời chỉ quyết định lô hoàn thành nhanh đến đâu. Thứ thực sự phụ thuộc vào đồng thời là áp lực tức thời: càng nhiều phiên bản khởi chạy cùng lúc thì càng dễ chạm trần đồng thời của nhóm tài nguyên hoặc giới hạn tần suất từ phía nền tảng.
Vì vậy, hãy bắt đầu với mức đồng thời nhỏ nhất. Trước tiên chạy một tác vụ để xác nhận thời lượng trung bình và tỷ lệ thành công. Sau đó tăng dần lên vài tác vụ rồi khoảng hơn chục tác vụ, đồng thời ghi lại tỷ lệ lỗi và số lần thử lại. Khi tỷ lệ lỗi tăng rõ rệt sau một ngưỡng nào đó, đó chính là trần thực tế có thể dùng. Tăng cao hơn nữa chỉ khiến thời gian tiết kiệm được bị trả lại qua các lần thử lại.
Khi ước tính, đừng bỏ sót thời gian ẩn: chờ đăng nhập, tải trang, bước xác minh và thử lại sau lỗi. Những phần này thường còn lâu hơn cả luồng chính. Chừa dư địa cho mỗi tác vụ hữu ích hơn là cố tính chính xác đến từng phút.
Khi cạn hạn mức sẽ trông như thế nào
Cạn hạn mức không phải lúc nào cũng dễ nhận ra vì nó thường giống các sự cố khác.
Một biểu hiện là tác vụ kẹt ở giai đoạn khởi động do yêu cầu tạo môi trường hoặc phiên bản bị từ chối, còn nhật ký chỉ để lại một lỗi mơ hồ. Trường hợp khác là phiên bản bị thu hồi giữa chừng khiến toàn bộ tiến độ trước đó mất đi. Bạn cũng có thể gặp lỗi giới hạn tần suất, một số tác vụ thành công còn một số thất bại, hoặc hàng đợi ngày càng dài nhưng không được xử lý.
Dễ chẩn đoán nhầm nhất là trạng thái treo giả: phiên bản vẫn tồn tại và tác vụ có vẻ đang chạy, nhưng thực tế chỉ mắc kẹt trong chờ đợi trong khi hạn mức vẫn tiếp tục bị tiêu thụ theo thời gian. Khi gặp trường hợp này, trước tiên hãy xem bảng sử dụng hạn mức, sau đó chạy riêng một tác vụ nhỏ. Nếu tác vụ nhỏ cũng không khởi động được, hãy kiểm tra hạn mức hoặc quyền. Nếu nó chạy bình thường, vấn đề nhiều khả năng nằm ở mức đồng thời hoặc việc tái sử dụng môi trường.
Thứ tự khắc phục
Hãy bắt đầu bằng các biện pháp không tốn thêm tiền.
Bước một, dừng mức tiêu thụ thường trực có giá trị thấp và chuyển tác vụ giám sát sang chạy theo lịch. Bước hai, dời các tác vụ có thể trì hoãn sang những khung giờ còn nhiều hạn mức để làm phẳng đường cong tiêu thụ. Bước ba, giảm giới hạn đồng thời và thêm hàng đợi để tác vụ được xử lý theo năng lực sẵn có thay vì khởi chạy cùng lúc. Bước bốn, cắt giảm tiêu thụ vô ích: dùng bộ nhớ đệm để không tải lại cùng một tài nguyên, lấy nhiều dữ liệu hơn trong mỗi yêu cầu khi phù hợp, dừng sớm các yêu cầu chắc chắn thất bại và không thử lại vô hạn.
Sau bốn bước này, hãy đánh giá xem có thực sự cần tăng ngân sách hoặc chuyển lên cấp dịch vụ cao hơn hay không. Thường bạn sẽ thấy hạn mức thực sự cần nhỏ hơn dự tính ban đầu. Ngược lại, nếu tăng ngân sách trước, bạn cũng đang trả tiền cho cả những thói quen lãng phí.
Đừng nén lớp môi trường cùng với lớp tính toán
Một lỗi phổ biến khi tiết kiệm hạn mức là để nhiều tác vụ dùng chung một môi trường trình duyệt với lý do chỉ cần mở môi trường đó một lần là đủ.
Cái giá xuất hiện ngay lập tức: phiên làm việc ghi đè lẫn nhau, trạng thái đăng nhập bị đẩy ra, bộ nhớ đệm trộn lẫn và một tác vụ lỗi có thể kéo theo các tác vụ khác. Phần nhỏ thời gian phiên bản tiết kiệm được sẽ bị trả lại nhiều lần qua việc xử lý sự cố và chạy lại.
Hai lớp này cần được xem xét riêng. Lớp tính toán chịu trách nhiệm chạy logic tác vụ, lập lịch theo nhu cầu và tối ưu hiệu quả chi phí. Lớp môi trường chịu trách nhiệm về danh tính và cách ly, mỗi tác vụ dùng một môi trường độc lập để tối ưu độ ổn định. Vì tài nguyên tính toán khan hiếm mà nén lớp môi trường là đang trộn lẫn hai loại chi phí. Việc tạo và thu hồi môi trường hàng loạt nên do công cụ của lớp môi trường quản lý tập trung. Khi PurpleMark cách ly phiên và bộ nhớ đệm theo từng môi trường, các tác vụ và trình thực thi ở lớp trên mới có thể được điều phối linh hoạt.
Cuối cùng, đừng giảm chi phí theo hướng vi phạm quy định. Không dùng dịch vụ từ kênh không chính thức chỉ để tiết kiệm hạn mức và không cố ép lưu lượng bằng cách tăng tần suất yêu cầu. Khi đã kích hoạt giới hạn tần suất, các lần thử lại thường tiêu tốn nhiều hạn mức hơn so với chạy theo nhịp kiểm soát.
