Tối ưu chi phí dịch vụ đám mây (Cloud Cost Optimization)

Tối ưu chi phí đám mây là quá trình liên tục giúp bạn trả tiền cho đúng những gì thực sự cần, mà không làm giảm hiệu năng hay độ tin cậy. Phần lớn lãng phí đến từ vài nguồn quen thuộc: tài nguyên cấp phát quá lớn, tài nguyên bị bỏ quên, dữ liệu nằm sai lớp lưu trữ, phí truyền dữ liệu không được để ý và không tận dụng giảm giá cam kết. Bài viết đi qua từng nguồn lãng phí kèm cách xử lý, áp dụng được cho AWS, Azure lẫn Google Cloud.

Vì sao hóa đơn cloud dễ vượt kiểm soát

Cloud biến chi phí hạ tầng từ khoản đầu tư một lần thành chi phí vận hành theo mức dùng. Ai có quyền tạo tài nguyên cũng có thể tạo chi phí, chỉ bằng vài cú nhấp chuột. Một máy ảo thử nghiệm quên tắt, một bản snapshot cũ không ai dọn, một cụm cơ sở dữ liệu cỡ lớn cho môi trường dev chạy suốt cuối tuần, cộng lại thành con số đáng kể mà không ai cảm thấy mình chịu trách nhiệm.

Bước 1: Nhìn thấy chi phí

Không thể tối ưu thứ bạn không đo được. Trước khi cắt giảm bất cứ thứ gì:

• Bật công cụ phân tích chi phí của nhà cung cấp: AWS Cost Explorer, Azure Cost Management, Google Cloud Billing reports.
• Gắn tag/label nhất quán cho mọi tài nguyên: dự án, môi trường (prod, staging, dev), đội sở hữu. Bắt buộc tag bằng chính sách để tài nguyên không tag không thể tạo.
• Đặt ngân sách và cảnh báo theo tài khoản, dự án, kèm cảnh báo bất thường khi chi tiêu tăng đột biến.
• Xuất dữ liệu hóa đơn chi tiết vào kho dữ liệu để phân tích sâu khi quy mô lớn.

Khi chi phí được phân bổ theo đội và dự án, cuộc trò chuyện chuyển từ "hóa đơn cloud tăng" thành "dịch vụ X của đội Y tăng chi phí sau đợt phát hành tuần trước", dễ hành động hơn nhiều.

Bước 2: Dọn dẹp tài nguyên bị bỏ quên

Đây thường là khoản tiết kiệm nhanh nhất:

• Ổ đĩa không gắn vào máy nào.
• Snapshot và bản sao lưu quá hạn lưu giữ.
• Địa chỉ IP công khai không sử dụng.
• Cân bằng tải không có máy phía sau.
• Môi trường thử nghiệm của dự án đã kết thúc.
• Image container cũ trong registry.

Các công cụ như AWS Trusted Advisor, Azure Advisor và Google Cloud Recommender gợi ý sẵn nhiều mục trong số này.

Bước 3: Chọn đúng cỡ tài nguyên

Khi tạo máy ảo, người ta thường chọn cỡ lớn "cho chắc". Sau vài tuần, số liệu giám sát cho thấy CPU chỉ dùng một phần nhỏ. Rightsizing là điều chỉnh cỡ tài nguyên theo số liệu thực:

1. Thu thập số liệu CPU, bộ nhớ, mạng trong khoảng thời gian đủ dài để bao gồm chu kỳ cao điểm.
2. Xác định tài nguyên dùng thấp kéo dài.
3. Giảm cỡ hoặc chuyển sang họ máy phù hợp hơn (ví dụ họ tối ưu bộ nhớ nếu ứng dụng cần RAM nhiều hơn CPU).
4. Theo dõi sau thay đổi để đảm bảo hiệu năng không bị ảnh hưởng.

Các thế hệ máy mới hoặc máy dùng chip ARM (như AWS Graviton, Azure Cobalt, Google Axion) thường cho tỷ lệ giá trên hiệu năng tốt hơn với phần mềm tương thích.

Bước 4: Tắt những gì không cần chạy 24/7

Môi trường dev và staging thường chỉ được dùng trong giờ làm việc. Lên lịch tự động tắt vào buổi tối và cuối tuần có thể giảm đáng kể chi phí cho các môi trường này. Với khối lượng công việc biến động, Auto Scaling giúp số máy theo sát nhu cầu thay vì luôn chạy ở mức đỉnh. Kiến trúc serverless đẩy nguyên tắc này đến cùng: không có lưu lượng thì không trả tiền tính toán, như phân tích trong bài backend serverless với AWS Lambda.

Bước 5: Tối ưu lưu trữ

Lưu trữ đối tượng có nhiều lớp với giá và tốc độ truy cập khác nhau:

Lớp rẻ hơn thường đi kèm phí truy xuất và thời gian lưu tối thiểu, nên không phải cứ chuyển xuống là tiết kiệm. Hãy dùng chính sách vòng đời để tự động chuyển dữ liệu theo tuổi và xóa dữ liệu hết hạn. Với dữ liệu có mẫu truy cập khó đoán, tùy chọn như S3 Intelligent-Tiering tự di chuyển dữ liệu giữa các lớp. Bản sao lưu chiếm phần lớn dung lượng ở nhiều tổ chức; cách cân bằng giữa chi phí và khả năng khôi phục được bàn trong bài sao lưu và phục hồi thảm họa trên cloud.

Đừng quên ổ đĩa khối: chuyển sang loại ổ thế hệ mới (như gp3 trên AWS) và giảm IOPS cấp phát dư thừa cũng giúp tiết kiệm.

Bước 6: Tận dụng mô hình giá

• Cam kết sử dụng: Savings Plans, Reserved Instances, Committed Use Discounts giảm giá đáng kể khi bạn cam kết dùng một mức tài nguyên trong một hoặc ba năm. Chỉ cam kết cho phần tải nền ổn định, sau khi đã rightsizing.
• Máy ảo giá rẻ có thể bị thu hồi: Spot Instances (AWS), Spot VMs (Azure, Google Cloud) rẻ hơn nhiều nhưng có thể bị thu hồi khi nhà cung cấp cần lại tài nguyên. Phù hợp xử lý theo lô, CI, kết xuất hình ảnh, cụm có khả năng chịu lỗi.
• Giấy phép: tận dụng giấy phép phần mềm sẵn có khi nhà cung cấp cho phép.

Bước 7: Kiểm soát phí truyền dữ liệu

Dữ liệu đi vào cloud thường miễn phí, nhưng đi ra Internet, đi giữa các region, và trong nhiều trường hợp giữa các Availability Zone đều tính phí. Một số cách giảm:

• Dùng CDN để phục vụ nội dung tĩnh, giảm lưu lượng ra từ máy chủ gốc.
• Đặt các thành phần trao đổi nhiều dữ liệu cùng vùng.
• Dùng VPC endpoint thay vì đi qua NAT Gateway khi truy cập dịch vụ của chính nhà cung cấp, vì NAT Gateway tính phí theo lượng dữ liệu xử lý.
• Nén dữ liệu trước khi truyền.

Bước 8: Biến tối ưu chi phí thành văn hóa (FinOps)

FinOps là thực hành kết hợp tài chính, kỹ thuật và kinh doanh để quản lý chi phí cloud, được FinOps Foundation phổ biến với vòng lặp ba giai đoạn: Inform (hiển thị chi phí), Optimize (tối ưu), Operate (vận hành liên tục). Điểm cốt lõi là kỹ sư, người tạo ra chi phí, phải nhìn thấy và chịu trách nhiệm về chi phí đó:

• Hiển thị chi phí của từng đội trên dashboard mà đội xem hằng ngày.
• Đưa ước tính chi phí vào quy trình duyệt hạ tầng dưới dạng mã, ví dụ công cụ hiển thị chênh lệch chi phí trong pull request.
• Rà soát chi phí định kỳ hằng tháng cùng đội kỹ thuật và tài chính.
• Đo chi phí theo đơn vị kinh doanh (chi phí trên mỗi người dùng, mỗi đơn hàng) thay vì chỉ nhìn tổng hóa đơn.

Những điều không nên làm khi cắt giảm

• Tắt sao lưu hoặc giảm thời gian lưu giữ dưới mức yêu cầu phục hồi.
• Bỏ triển khai nhiều vùng sẵn sàng cho hệ thống quan trọng chỉ để tiết kiệm.
• Cam kết dài hạn cho tài nguyên chưa ổn định nhu cầu.
• Tắt nhật ký kiểm toán và giám sát bảo mật.

Tiết kiệm chi phí không nên đánh đổi bằng rủi ro mà doanh nghiệp không chấp nhận được. Nếu bạn đang chọn nhà cung cấp, cấu trúc giá khác nhau giữa các nền tảng cũng là một yếu tố, như đã đề cập trong bài so sánh AWS, Google Cloud và Azure.