Ước tính chi phí hệ thống

"Hóa đơn cloud tháng này gấp ba tháng trước"

Cuối tháng, bộ phận tài chính gửi cho trưởng nhóm gdev-shop hóa đơn hạ tầng gấp ba tháng trước, dù lượng khách chỉ tăng 20%. Không ai biết vì sao. Sau hai ngày điều tra, nhóm phát hiện: một nhật ký chi tiết bật nhầm ở môi trường production sinh ra vài terabyte log mỗi tháng, và một job báo cáo tải dữ liệu qua lại giữa hai vùng mỗi đêm, tính phí truyền dữ liệu. Không thành phần nào "hỏng". Chỉ là không ai ước lượng và theo dõi chi phí như một yêu cầu thiết kế.

Chi phí là một ràng buộc phi chức năng ngang với độ trễ hay availability. Thiết kế tốt không chỉ "chạy đúng và đủ nhanh" mà còn "đủ rẻ để bền vững". Bài này dạy cách ước tính chi phí hệ thống từ các con số tải đã học, và nhận ra các động lực chi phí hay bị bỏ sót.

Các thành phần của chi phí

Chi phí một hệ thống cloud thường chia thành các nhóm:

Điều cuối thường lớn nhất nhưng bị bỏ ra khỏi các bảng tính hạ tầng: một kiến trúc phức tạp hơn đòi hỏi nhiều thời gian kỹ sư hơn để xây, vận hành, trực sự cố. Khi so sánh monolith với microservices hay một database với nhiều loại database, chi phí nhân sự và độ phức tạp là một phần của phép so sánh.

Cấu trúc chi phí gồm hai loại:

• Chi phí cố định: trả dù dùng ít hay nhiều (máy chạy 24/7, instance database, bản đã cam kết).
• Chi phí biến đổi: tăng theo mức dùng (số request, dung lượng, băng thông, số lần gọi hàm).

Hệ thống nhỏ thường chủ yếu là chi phí cố định. Dịch vụ serverless và pay-per-use thiên về biến đổi. Biết thành phần nào cố định, thành phần nào biến đổi quyết định cách chi phí tăng theo tải.

Cách ước tính: từ tải đến tiền

Quy trình dùng lại các con số đã học ở bước ước lượng, thêm đơn giá:

Cách đọc sơ đồ

1. Bắt đầu từ ước lượng tải (số request mỗi giây, số người dùng, tốc độ tăng dữ liệu), đúng như phần đầu khóa học.
2. Suy ra năng lực cần thiết: bao nhiêu instance, bao nhiêu dung lượng lưu trữ, băng thông bao nhiêu.
3. Nhân với đơn giá thực tế của nhà cung cấp (tra bảng giá chính thức).
4. Cộng thành chi phí hằng tháng cho từng thành phần.
5. Tính tổng và chi phí đơn vị (ví dụ chi phí cho 1.000 request), một con số dùng để so sánh giữa các phương án và theo dõi theo thời gian.
6. So sánh các lựa chọn và đặt ngân sách.

Ví dụ ước tính cho gdev-shop (số liệu và đơn giá giả định)

Lưu ý quan trọng: mọi đơn giá dưới đây là giả định để minh họa phương pháp, không phải giá của nhà cung cấp nào. Khi làm thật, hãy tra bảng giá chính thức.

Tải giả định: đỉnh 120 request mỗi giây, trung bình khoảng 40 request mỗi giây, nghĩa là khoảng 100 triệu request mỗi tháng. Dữ liệu: 500 GB database và 2 TB ảnh. Truyền ra ngoài: 3 TB mỗi tháng.

Từ đây có thể tính chi phí đơn vị: 1.340 đô chia 100 triệu request, bằng 0,0134 đô trên 1.000 request (khoảng 1,3 xu). Con số này giúp so sánh: nếu một thay đổi (thêm CDN) giảm truyền ra và giảm tải server, chi phí đơn vị có giảm không?

Cách đọc biểu đồ

Biểu đồ cột cho thấy thành phần nào chiếm phần lớn chi phí (với số liệu giả định): database chiếm lớn nhất (khoảng 37%), tiếp theo là truyền dữ liệu ra (khoảng 18%). Đây là điều trực giác thường không đoán đúng: nhiều người nghĩ server ứng dụng là phần tốn nhất. Hành động đúng là ưu tiên tối ưu theo khoản lớn nhất: tối ưu server ứng dụng thêm 20% chỉ tiết kiệm khoảng 42 đô, trong khi giảm truyền dữ liệu ra bằng CDN hoặc nén có thể tiết kiệm nhiều hơn rất nhiều. Cùng nguyên lý với tối ưu hiệu năng: đo, tìm khoản lớn nhất, xử lý nó trước.

Hai khoản dễ bị bất ngờ nhất trong thực tế:

• Truyền dữ liệu: dữ liệu đi ra khỏi cloud hoặc giữa các vùng và AZ thường bị tính phí, trong khi dữ liệu đi vào thường miễn phí hoặc rẻ. Kiến trúc đa AZ hoặc đa vùng làm các dịch vụ trao đổi dữ liệu liên vùng liên tục sinh phí truyền ngầm. Đây là thứ cần tính khi chọn nơi đặt các thành phần giao tiếp nhiều với nhau.
• Quan sát: log chi tiết, metric nhiều chiều và trace không lấy mẫu có thể trở thành một trong những khoản lớn nhất. Cần chính sách lưu giữ và lấy mẫu.

Ước tính theo kịch bản và tăng trưởng

Một con số duy nhất cho hôm nay chưa đủ. Cần ước tính cho ba kịch bản:

• Hiện tại: tải thực.
• Tăng trưởng: tải gấp 3, gấp 10. Chi phí nào tăng gần tuyến tính, nào tăng theo bậc thang (thêm instance), nào tăng nhanh hơn tải (truyền dữ liệu, log)?
• Đỉnh đột biến (như 12.12): chi phí của năng lực dư để chịu đỉnh so với chi phí chịu một số lỗi.

Kết quả hữu ích: biết chi phí đơn vị có tăng hay giảm khi quy mô lớn dần (hiệu quả theo quy mô), và mốc tải nào buộc chuyển sang kiến trúc khác (ví dụ mốc tại đó tự chạy máy rẻ hơn serverless).

Kiểm soát chi phí: FinOps ở mức nhập môn

FinOps là thực hành đưa trách nhiệm về chi phí vào đội kỹ thuật. Những việc đơn giản mà hiệu quả:

• Gắn nhãn (tag) mọi tài nguyên theo service, môi trường, nhóm. Không có nhãn thì không biết khoản nào của ai.
• Ngân sách và cảnh báo: đặt ngân sách theo tháng, cảnh báo khi vượt 50%, 80%, 100%, và cảnh báo bất thường (hóa đơn tăng vọt trong một ngày), như sự cố đầu bài.
• Xem xét chi phí định kỳ như xem xét hiệu năng.
• Dọn tài nguyên không dùng: máy, đĩa, snapshot, môi trường thử nghiệm bị bỏ quên.
• Ghi ngân sách vào NFR: bên cạnh P99 dưới 300 ms và availability 99,9%, có thêm "chi phí hạ tầng không vượt 0,02 đô trên 1.000 request".

Những hiểu lầm phổ biến

• "Chi phí là việc của bộ phận tài chính." Quyết định kiến trúc quyết định phần lớn chi phí. Kỹ sư phải hiểu và chịu trách nhiệm.
• "Server là khoản tốn nhất." Thường database, truyền dữ liệu hoặc quan sát mới lớn. Hãy đo.
• "Cloud rẻ vì trả theo mức dùng." Rẻ khi dùng hợp lý. Tài nguyên dư thừa, quên tắt, và egress có thể làm hóa đơn phình lên.
• "Chỉ tính chi phí hạ tầng." Chi phí nhân sự để xây, vận hành, trực sự cố của kiến trúc phức tạp thường còn lớn hơn.
• "Ước tính một lần là đủ." Chi phí đổi theo tải, giá và kiến trúc. Cần theo dõi liên tục.

Must Know, Good to Know, Advanced

• Must Know: các nhóm chi phí (compute, storage, database, egress, quan sát, bên thứ ba, nhân sự); cố định so với biến đổi; quy trình từ tải đến tiền; tính chi phí đơn vị; ưu tiên tối ưu khoản lớn nhất; chi phí là một NFR.
• Good to Know: truyền dữ liệu giữa vùng và AZ; chi phí quan sát; ước tính theo ba kịch bản; gắn nhãn và cảnh báo ngân sách.
• Advanced: các mô hình giá cam kết, tối ưu theo đơn vị kinh doanh (chi phí mỗi đơn hàng). Chỉ cần biết tên và mục đích.

Tự kiểm tra

1. Với bảng giả định, khoản nào lớn nhất? Tối ưu server ứng dụng thêm 20% tiết kiệm khoảng bao nhiêu so với giảm truyền dữ liệu ra 50%?
2. Vì sao việc đặt hai service giao tiếp nhiều ở hai vùng khác nhau có thể làm hóa đơn tăng bất ngờ?
3. Hệ thống tăng tải gấp 10 lần. Chi phí thành phần nào có thể tăng nhanh hơn tải?

Đáp án gợi ý

1. Khoản lớn nhất trong bảng giả định là database chính và một replica: 500 đô mỗi tháng. Tối ưu server ứng dụng thêm 20% tiết kiệm khoảng 20% × 210 = 42 đô, còn giảm truyền dữ liệu ra 50% tiết kiệm 50% × 240 = 120 đô, tức nhiều hơn gần ba lần. Tối ưu nên nhắm vào khoản lớn và có đòn bẩy cao nhất, không chỉ phần quen thuộc.
2. Dữ liệu truyền giữa các vùng hoặc AZ thường bị tính phí theo GB, và hai service giao tiếp nhiều tạo ra lượng dữ liệu rất lớn. Chi phí này không hiện trên cấu hình máy nên dễ bị quên khi thiết kế, và chỉ lộ ra trên hóa đơn. Nên đặt các thành phần giao tiếp nhiều ở cùng vùng hoặc AZ nếu yêu cầu cho phép.
3. Thành phần có chi phí phi tuyến hoặc tăng theo nhiều chiều: truyền dữ liệu ra, quan sát (log, metric, trace tăng theo lượng yêu cầu và độ chi tiết), database (khi phải nâng cấu hình hoặc thêm replica), và dịch vụ bên thứ ba tính theo giao dịch. Server ứng dụng thường tăng gần tuyến tính theo tải.

Nếu chỉ nhớ 3 điều

1. Chi phí là một NFR: ước tính từ tải đến tiền (năng lực nhân đơn giá), tính chi phí đơn vị (ví dụ mỗi 1.000 request).
2. Ưu tiên khoản lớn nhất, thường là database, truyền dữ liệu hoặc quan sát chứ không phải server; đừng quên nhân sự.
3. Theo dõi liên tục: gắn nhãn, ngân sách, cảnh báo bất thường; ước tính theo ba kịch bản.