Cách một startup ML cắt giảm hóa đơn AWS 22.000 USD bằng việc sửa đổi lịch trình

Một startup về machine learning với tám kỹ sư gần đây đã cắt giảm hóa đơn hạ tầng đám mây hàng tháng của mình đi gần năm nghìn đô la. Nhóm đạt được khoản tiết kiệm này không phải bằng cách viết lại các mô hình suy luận (inference) hay thay đổi loại instance, mà bằng cách đồng bộ lịch sử dụng GPU với các mẫu nhu cầu thực tế của người dùng. Trường hợp này làm nổi bật cách mà thời gian vận hành, chứ không chỉ là hiệu quả kiến trúc, tạo ra sự khác biệt lớn về chi phí trong môi trường đám mây.

Chuyện gì đã xảy ra

Startup này đang vận hành một API suy luận cho môi trường production phục vụ lưu lượng truy cập thực tế, dẫn đến hóa đơn AWS lên tới 22.000 USD mỗi tháng. Phần lớn chi phí này đến từ tài nguyên tính toán GPU dùng cho việc suy luận mô hình. Khi một chuyên gia tư vấn xem xét tài khoản, họ kỳ vọng sẽ tìm thấy phần cứng bị cấp phát quá mức hoặc mã nguồn kém hiệu quả. Thay vào đó, họ nhận thấy rằng các loại instance rất phù hợp với khối lượng công việc và tỷ lệ sử dụng trong giờ hoạt động cao điểm là hợp lý. Không có sự lãng phí kỹ thuật rõ ràng nào trong chính kiến trúc hệ thống.

Nguyên nhân gốc rễ của chi phí cao nằm ở yếu tố thời gian, không phải kỹ thuật. Phân tích nhật ký lưu lượng truy cập cho thấy 90% tất cả yêu cầu của người dùng diễn ra từ 9 giờ sáng đến 11 giờ đêm theo giờ miền Đông Hoa Kỳ (US Eastern time). Khoảng thời gian qua đêm hầu như im lặng, chỉ bao gồm các kiểm tra sức khỏe tự động (health checks) và các tác vụ nền nhỏ. Bất chấp sự thiếu hụt nhu cầu này, các instance GPU vẫn chạy hết công suất và chịu giá đầy đủ suốt 24 giờ mỗi ngày. Nhóm đã giữ cụm máy chủ ở kích thước đỉnh điểm qua đêm vì cảm thấy an toàn hơn, dẫn đến tám giờ gần như không sử dụng tài nguyên mỗi đêm.

Để giải quyết vấn đề này, nhóm đã triển khai một lịch trình thu nhỏ quy mô (scale-down). Vào lúc 11 giờ đêm giờ miền Đông, cụm suy luận thu nhỏ xuống trạng thái ấm tối thiểu (minimal warm state). Trạng thái này đủ để xử lý các tác vụ nền và phản hồi các kiểm tra sức khỏe nhưng tiêu thụ ít tài nguyên hơn đáng kể. Vào lúc 8 giờ sáng giờ miền Đông, trước khi lưu lượng buổi sáng tăng vọt, cụm máy chủ mở rộng trở lại hết công suất. Toàn bộ thay đổi chỉ mất hai ngày để triển khai và thử nghiệm an toàn.

Chi tiết chính

• Hóa đơn AWS hàng tháng của startup là 22.000 USD, chủ yếu do chi phí tính toán GPU cho việc suy luận.
• Phân tích lưu lượng cho thấy 90% yêu cầu diễn ra từ 9 giờ sáng đến 11 giờ đêm giờ miền Đông Hoa Kỳ.
• Các instance GPU chạy hết công suất 24/7, bất chấp tám giờ lưu lượng người dùng gần như bằng không mỗi đêm.
• Giải pháp liên quan đến việc thu nhỏ xuống trạng thái ấm tối thiểu vào lúc 11 giờ đêm và mở rộng lại vào lúc 8 giờ sáng giờ miền Đông.
• Việc triển khai mất hai ngày để thử nghiệm và đưa vào hoạt động mà không cần thay đổi kiến trúc cơ bản hay các mô hình.
• Điều chỉnh này giúp tiết kiệm 4.800 USD mỗi tháng bằng cách khớp phân bổ tài nguyên với nhu cầu thực tế.

Bối cảnh

Trong điện toán đám mây, đặc biệt là với phần cứng chuyên dụng như GPU, chi phí thường gắn liền với thời gian hoạt động (uptime) chứ không chỉ là quá trình xử lý tích cực. Nhiều nhóm mặc định giữ các cụm máy chủ ở công suất tối đa để đảm bảo độ trễ thấp và tính sẵn sàng cao, lo sợ rằng việc thu nhỏ quy mô có thể gây ra rủi ro hoặc chậm trễ. Cách tiếp cận này, thường được gọi là "cấp phát quá mức để đảm bảo an toàn", có thể dẫn đến lãng phí đáng kể trong những khoảng thời gian lưu lượng thấp có thể dự đoán trước.

FinOps, hay hoạt động tài chính, là thực tiễn quản lý chi phí đám mây thông qua sự hợp tác giữa các nhóm kỹ thuật và tài chính. Một nguyên tắc cốt lõi của FinOps là khớp chi tiêu với giá trị kinh doanh. Trong bối cảnh này, điều đó có nghĩa là đảm bảo các tài nguyên đắt đỏ chỉ hoạt động khi chúng đang phục vụ người dùng tích cực. Các chính sách tự động mở rộng/thu nhỏ quy mô cho phép các nhóm điều chỉnh tài nguyên linh hoạt dựa trên thời gian hoặc tải, thu hẹp khoảng cách giữa độ tin cậy kỹ thuật và hiệu quả tài chính.

Tại sao điều này quan trọng

Đối với các nhóm tự quản lý hạ tầng phần mềm của mình, trường hợp này minh họa rằng tối ưu hóa chi phí không nhất thiết đòi hỏi phải tái cấu trúc phức tạp. Các kỹ sư thường tập trung vào hiệu quả mã nguồn hoặc chỉ mục cơ sở dữ liệu để giảm chi phí, bỏ qua các lịch trình vận hành. Khi các mẫu lưu lượng truy cập có thể dự đoán được, chẳng hạn như trong các ứng dụng B2B với giờ làm việc rõ ràng, các chính sách mở rộng tĩnh có thể khiến bạn bỏ lỡ cơ hội tiết kiệm tiền. Nhận thức rằng "sự an toàn" thông qua công suất đỉnh điểm liên tục có một hình phạt tài chính trực tiếp là một sự thay đổi tư duy quan trọng đối với các trưởng nhóm DevOps.

Hơn nữa, câu chuyện này nhấn mạnh tầm quan trọng của việc ra quyết định dựa trên dữ liệu trong quản lý hạ tầng. Nếu không phân phối theo mốc thời gian của các yêu cầu, nhóm đã giả định rằng hóa đơn cao của họ là hợp lý do nhu cầu liên tục. Bằng cách đơn giản quan sát khi nào người dùng thực sự hoạt động, họ đã xác định được một cơ hội tiết kiệm rõ ràng. Cách tiếp cận này áp dụng được cho nhiều dịch vụ tự host (self-hosted) nơi tải biến động có thể dự đoán được, từ các công cụ nội bộ đến các API hướng tới khách hàng.

Bạn có thể làm gì

• Phân tích nhật ký dịch vụ của bạn để xác định các khung giờ cao điểm và thấp điểm, tìm kiếm các mẫu hàng ngày hoặc hàng tuần có thể dự đoán được.
• Xem xét các chính sách tự động mở rộng hiện tại của bạn để xem liệu chúng có cho phép thu nhỏ sâu trong các khoảng thời gian lưu lượng thấp đã biết hay không.
• Triển khai cấu hình "trạng thái ấm" giữ cho các kiểm tra sức khỏe thiết yếu và worker nền vẫn chạy trong khi giảm bớt các node tính toán đắt đỏ.
• Thử nghiệm các sự kiện mở rộng/thu nhỏ quy mô trong môi trường staging để đảm bảo rằng thời gian khởi động lại không ảnh hưởng đến trải nghiệm người dùng trong các đợt tăng lưu lượng.
• Thiết lập cảnh báo cho các đợt tăng lưu lượng bất thường ngoài các khung giờ dự kiến để bắt kịp các dị thường mà không cần giữ tài nguyên ở mức cao vĩnh viễn.
• Thường xuyên xem xét lại lịch trình mở rộng của bạn khi hành vi người dùng thay đổi, đảm bảo cấu trúc chi phí của bạn luôn khớp với nhu cầu thực tế.