Spot instance là gì? Khi nào dùng được để giảm 70% chi phí?

Hãy tưởng tượng bạn thuê một căn hộ cao cấp với giá chỉ bằng 1/3 giá niêm yết — đổi lại, chủ nhà có quyền lấy lại phòng bất cứ lúc nào khi có khách trả giá đầy đủ, nhưng sẽ báo trước cho bạn 2 phút để dọn đồ. Nghe có vẻ "mạo hiểm", nhưng nếu bạn chỉ cần chỗ ngủ qua đêm và đồ đạc đã đóng gói sẵn, đây là món hời không thể bỏ qua. Đó chính xác là cách spot instance hoạt động trong thế giới cloud: dùng công suất máy chủ đang nhàn rỗi của nhà cung cấp với mức giá rẻ hơn rất nhiều, chấp nhận rủi ro bị thu hồi. Bài viết này giải thích spot instance là gì, khi nào dùng được để tiết kiệm chi phí thực sự, và khi nào tuyệt đối không nên đụng vào.

Spot instance là gì? Định nghĩa ngắn gọn nhất

Spot instance là hình thức thuê máy chủ cloud dùng phần công suất dư thừa (spare capacity) — những máy chủ đang bật nhưng chưa có khách thuê theo giá thông thường. Nhà cung cấp bán lại với giá rẻ hơn nhiều, đổi lại họ có quyền thu hồi máy bất cứ lúc nào khi cần công suất cho khách trả giá đầy đủ, với thông báo trước 2 phút.

Điểm mấu chốt: khi đang chạy, spot instance giống hệt máy thuê theo giá thông thường (On-Demand) — cùng CPU, RAM, mạng, hệ điều hành. Khác biệt duy nhất là bạn không được đảm bảo giữ máy đến khi xong việc. Theo tài liệu chính thức của AWS, spot instance giúp tiết kiệm tới 90% so với giá On-Demand. Chi tiết xem tại tài liệu best practices cho EC2 Spot.

Tại Việt Nam, các nhà cung cấp cloud nội địa thường không gọi tên "spot instance", nhưng nguyên lý tương tự tồn tại dưới dạng gói cam kết dài hạn hoặc chiến lược tắt/mở máy theo giờ. Hiểu rõ spot instance giúp bạn áp dụng tư duy FinOps đúng cho mọi nền tảng cloud.

Spot instance là gì: vì sao spot instance rẻ đến vậy: cơ chế "công suất dư"

Hãy nhìn từ phía nhà cung cấp: họ đầu tư hàng nghìn máy chủ nhưng nhu cầu thuê lên xuống theo giờ, theo mùa. Lúc thấp điểm, hàng loạt máy vẫn bật, vẫn tốn điện và chi phí vận hành — nhưng không sinh doanh thu. Thay vì để lãng phí, họ mở bán phần công suất dư với giá "xả hàng".

Giá spot biến động theo cung — cầu của từng nhóm máy (pool): dư nhiều thì rẻ sâu, tranh nhau thì giá nhích lên và nguy cơ bị thu hồi tăng. Bạn trả giá spot hiện hành của pool; việc có bị thu hồi hay không phụ thuộc vào tình trạng công suất.

Khi cần lại công suất, hệ thống gửi thông báo gián đoạn đến máy spot của bạn trước 2 phút qua metadata nội bộ và hệ thống sự kiện. Sau 2 phút, máy bị tắt. Ứng dụng phải được thiết kế để "nghe" thông báo này và tự dọn dẹp: lưu trạng thái, ngắt kết nối, chuyển việc sang máy khác.

Spot instance là gì: so sánh Spot, On-Demand và Reserved: chọn sao cho đúng

Trên các nền tảng cloud lớn, compute thường có ba cách mua chính. Bảng dưới đây giúp bạn chọn đúng:

Quy tắc ngón tay cái của giới FinOps: Reserved/Savings Plan cho phần tải nền ổn định (baseline chạy 24/7), Spot cho phần tải linh hoạt, ngắt quãng, và On-Demand cho phần còn lại — những việc ngắn hạn, khó đoán, hoặc làm "vùng đệm" khi spot bị thu hồi. Kết hợp cả ba mới là tối ưu, chứ không phải "tất cả dùng spot".

Spot instance là gì: khi nào DÙNG ĐƯỢC spot instance: 6 nhóm workload phù hợp

Tiêu chí vàng: workload phải chịu được gián đoạn — tức là khi một máy bị tắt đột ngột, hệ thống vẫn hoàn thành việc, không mất dữ liệu, không ảnh hưởng người dùng cuối. Dưới đây là 6 nhóm điển hình:

1. Xử lý dữ liệu lớn theo lô (big data, ETL). Job phân tích, tổng hợp báo cáo chạy hàng đêm: máy bị thu hồi thì job manager chạy lại phần dở dang trên máy khác. Dữ liệu nguồn vẫn còn, chỉ tốn thêm chút thời gian.

2. CI/CD — build và test tự động. Mỗi lần push code cần máy biên dịch, chạy test vài phút. Job build vốn đã thiết kế để chạy lại khi lỗi — rất hợp với spot.

3. Render hình ảnh, video. Các frame render độc lập; frame dở dang thì render lại.

4. Web server không trạng thái (stateless) sau load balancer. Node bị thu hồi, load balancer chuyển traffic sang node còn lại; người dùng không cảm nhận được gì.

5. Hàng đợi xử lý nền (queue workers). Gửi email hàng loạt, xử lý ảnh upload — worker chết thì message quay lại hàng đợi cho worker khác làm.

6. Tính toán khoa học, huấn luyện AI. Có cơ chế checkpoint — lưu trạng thái định kỳ, gián đoạn thì chạy tiếp từ checkpoint gần nhất.

Điểm chung: không giữ trạng thái quan trọng trên máy cục bộ và đã có sẵn cơ chế thử lại (retry).

Khi nào TUYỆT ĐỐI không dùng spot: 5 nhóm workload cấm kỵ

Ngược lại, có những workload mà 2 phút báo trước là không đủ, hoặc gián đoạn đồng nghĩa với thảm họa. AWS khuyến cáo rõ ràng không dùng spot cho các workload không linh hoạt, có trạng thái, không chịu được lỗi:

1. Cơ sở dữ liệu chính (production database). Database cần nhất quán và liên tục tuyệt đối — mất node đột ngột có thể gây mất dữ liệu hoặc downtime dây chuyền.

2. Hệ thống thanh toán, giao dịch tài chính. Giao dịch đang xử lý dở mà máy tắt là cơn ác mộng về đối soát và niềm tin khách hàng.

3. Workload đơn lẻ không dự phòng. Toàn bộ hệ thống trên một máy duy nhất: máy bị thu hồi nghĩa là dịch vụ sập. Spot chỉ an toàn khi chạy theo cụm nhiều máy.

4. Ứng dụng stateful giữ trạng thái trên RAM/ổ cục bộ. Ví dụ game server đang giữ trạng thái trận đấu — tắt máy là mất trắng phần việc đang làm.

5. Hệ thống yêu cầu độ trễ ổn định tuyệt đối. Khi spot bị thu hồi hàng loạt lúc cao điểm, cụm máy co lại tạm thời, độ trễ tăng vọt.

Nguyên tắc nhớ: "không chịu được gián đoạn" là đèn đỏ tuyệt đối cho spot, bất kể giá có rẻ đến đâu.

Xử lý khi bị "thu hồi": tận dụng 2 phút báo trước

Hai phút nghe ngắn, nhưng đủ để hệ thống được chuẩn bị kỹ "hạ cánh an toàn":

• Lắng nghe thông báo gián đoạn: ứng dụng poll metadata nội bộ hoặc đăng ký nhận sự kiện để biết trước 2 phút, lập tức ngừng nhận việc mới.
• Drain kết nối: báo load balancer ngừng chuyển traffic mới tới, chờ request đang xử lý hoàn tất rồi mới tắt.
• Checkpoint: job đang chạy lưu tiến độ ra storage bền vững để máy khác tiếp tục từ điểm dừng.
• Fleet đa dạng: chạy spot trên nhiều loại máy và nhiều vùng khác nhau — một pool bị thu hồi, các pool khác vẫn còn. AWS cung cấp Spot Instance Advisor để xem tần suất gián đoạn lịch sử từng pool.
• On-Demand làm "neo": giữ vài máy On-Demand đảm bảo dịch vụ tối thiểu, phần còn lại dùng spot; khi spot bị thu hồi, hệ thống tự scale On-Demand bù vào.

5 best practice giảm rủi ro gián đoạn xuống mức thấp nhất

1. Đa dạng hóa loại máy và vùng. Dùng 4–6 loại instance tương đương, trải đều nhiều availability zone — pool càng rộng, xác suất toàn bộ fleet bị thu hồi cùng lúc càng thấp.

2. Phân bổ theo công suất (capacity-optimized). Ưu tiên các pool còn nhiều công suất trống thay vì pool rẻ nhất (nơi ai cũng đổ vào, dễ bị thu hồi nhất).

3. Thiết kế ứng dụng "miễn nhiễm" gián đoạn ngay từ đầu. Stateless, lưu trạng thái ra ngoài, retry với backoff, idempotent. Không có nền tảng này, mọi kỹ thuật khác chỉ là vá víu.

4. Giám sát giá và tần suất gián đoạn. Đặt cảnh báo khi giá tăng bất thường hoặc pool nào bị thu hồi nhiều.

5. Tự động hóa hoàn toàn vòng đời. Dùng auto-scaling group để hệ thống tự thay thế máy bị thu hồi trong vài phút — gián đoạn trở thành sự kiện bình thường được xử lý tự động, không phải sự cố cần trực chiến.

Áp dụng tư duy spot cho cloud Việt Nam: tiết kiệm không cần "spot"

Nếu dùng cloud/VPS trong nước — nơi chưa có sản phẩm tên "spot instance" — bạn vẫn áp dụng được triết lý cốt lõi: đừng trả giá cao nhất cho mọi workload:

• Tắt/mở máy theo lịch: môi trường dev, test chỉ cần chạy giờ hành chính — tắt ban đêm và cuối tuần giảm đáng kể chi phí nhóm máy này.
• Chọn đúng cấu hình (rightsizing): nhiều VPS đang chạy thừa CPU/RAM so với nhu cầu thực. Hạ cấu hình cho đúng nhu cầu là tiết kiệm ngay, không rủi ro.
• Cam kết dài hạn cho tải nền: workload chạy ổn định 24/7 nên dùng gói thanh toán 12–48 tháng để hưởng chiết khấu so với trả theo tháng.
• Tách workload: đưa việc ngắt quãng (build, render, batch) ra cụm máy riêng tắt/mở linh hoạt, thay vì để tất cả trên cụm production đắt đỏ.

Checklist: 10 câu hỏi trước khi chuyển workload sang spot

Trả lời "có" càng nhiều, workload càng hợp với spot:

1. Workload có chịu được việc một máy tắt đột ngột không?
2. Trạng thái quan trọng có được lưu ra ngoài máy không?
3. Hệ thống có cơ chế tự chạy lại (retry) khi job thất bại không?
4. Workload có chạy dạng cụm nhiều máy thay vì máy đơn lẻ không?
5. Có load balancer hoặc hàng đợi để phân phối lại việc không?
6. Ứng dụng có "nghe" được thông báo thu hồi trước 2 phút không?
7. Thời gian hoàn thành job có linh hoạt không?
8. Bạn có đo được chi phí compute hiện tại để so sánh tiết kiệm không?
9. Team có tự động hóa được provisioning/scaling không?
10. Khi spot khan hiếm, có phương án dự phòng sang On-Demand không?

Nếu trả lời "không" cho các câu 1–3, workload đó chưa sẵn sàng cho spot. Hãy bắt đầu từ những việc "vô hại" nhất (CI/CD, job batch đêm), đo lường tiết kiệm thực tế rồi mới mở rộng.

Kết luận

Spot instance là gì — tóm lại, đó là cách mua compute rẻ nhất trên cloud bằng cách tận dụng công suất dư thừa, với điều kiện workload chịu được gián đoạn và được thiết kế để tự phục hồi. Mức tiết kiệm tới 90% là có thật (theo công bố của AWS), nhưng chỉ dành cho đúng loại việc: batch, build, render, worker không trạng thái. Nguyên tắc vàng: database, thanh toán và hệ thống đơn lẻ không bao giờ được đặt lên spot.

Dù dùng cloud quốc tế hay trong nước, tư duy cốt lõi vẫn giống nhau: phân loại workload, chọn đúng cách mua, tự động hóa và giám sát liên tục. Nếu muốn rà soát chi phí hạ tầng, SunCloud có đội ngũ kỹ thuật tư vấn giải pháp Cloud Server và VPS tại datacenter Tier III trong nước. Liên hệ hotline 083 979 3434 hoặc truy cập suncloud.vn.

Câu hỏi thường gặp

Spot instance có dùng được cho website WordPress không?

Được nếu kiến trúc đúng: WordPress chạy stateless sau load balancer, file upload ra object storage/CDN, database trên máy riêng (không phải spot). Website nhỏ trên một VPS duy nhất thì không phù hợp vì không có dự phòng khi bị thu hồi.

Giá spot có ổn định không, hay thay đổi liên tục?

Giá spot biến động theo cung — cầu từng pool và từng vùng, nhưng biên độ thực tế thường hẹp. Quan trọng hơn giá là tần suất gián đoạn của pool — hãy xem lịch sử qua Spot Instance Advisor của AWS trước khi chọn.

Bị thu hồi giữa chừng thì dữ liệu đang xử lý có mất không?

Tùy thiết kế. Nếu ứng dụng lưu checkpoint ra storage bền vững và có retry, máy khác tiếp tục từ điểm dừng — không mất gì ngoài chút thời gian. Nếu giữ mọi thứ trên RAM/ổ cục bộ của máy spot, phần việc dở dang sẽ mất và phải làm lại.

Có cách nào "giả lập" spot trên cloud Việt Nam không?

Không có sản phẩm cùng tên, nhưng bạn đạt hiệu quả tương tự bằng: tách workload ngắt quãng ra cụm riêng tắt/mở theo lịch, dùng gói cam kết dài hạn cho tải nền ổn định, và rightsizing để không trả tiền cho tài nguyên thừa.

Spot instance có phù hợp với startup không?

Rất phù hợp nếu team kỹ thuật vững: chi phí compute thấp giúp kéo dài runway, đặc biệt với CI/CD, dev/test, xử lý dữ liệu. Nếu team còn mỏng và chưa có tự động hóa, hãy bắt đầu từ việc đơn giản nhất và ưu tiên ổn định production.

Ngoài spot, còn cách nào giảm chi phí cloud đáng kể?

Có nhiều: rightsizing, tắt tài nguyên nhàn rỗi theo lịch, cam kết dài hạn cho tải ổn định, dọn storage và snapshot cũ, tối ưu phí egress, đặt ngân sách + cảnh báo chi phí. Spot chỉ là một trong nhiều "đòn bẩy" FinOps — kết hợp nhiều đòn bẩy mới cho hiệu quả lớn nhất.