Chính sách autoscaling: scale đúng lúc, không scale thừa

Mùa sale 11/11, traffic đổ về website tăng gấp 10 lần trong một giờ, server quá tải, đơn hàng bốc hơi vì khách không thanh toán nổi — trong khi tháng trước đó, bạn vẫn phải trả tiền cho dàn máy chủ "dự phòng" chạy cả tháng chỉ để chờ một đêm cao điểm không chắc chắn. Một đầu là scale muộn sập hệ thống, đầu kia là scale thừa đốt tiền. Đây chính là bài toán mà chính sách autoscaling được sinh ra để giải.

Chính sách autoscaling (autoscaling policy) là tập hợp quy tắc xác định khi nào hệ thống cloud tự động tăng (scale out/up) hoặc giảm (scale in/down) tài nguyên, tăng bao nhiêu, tăng dựa trên tín hiệu nào và giữ nguyên bao lâu sau mỗi lần thay đổi. Nói nôm na: policy tốt thì hệ thống "phình" đúng lúc cao điểm và "xẹp" đúng lúc vắng khách — còn policy dở thì hệ thống cứ phình-xẹp liên tục, vừa chậm vừa tốn tiền.

Chính sách autoscaling: autoscaling là gì? Nhìn lại bức tranh tổng thể

Autoscaling là khả năng hệ thống tự động điều chỉnh lượng tài nguyên tính toán (máy ảo, container) theo tải thực tế, không cần ai can thiệp bằng tay. Trong cloud, nó hoạt động theo bốn hướng:

• Scale out: thêm máy chủ (instance) mới vào cụm khi tải tăng.
• Scale in: bớt instance khi tải giảm.
• Scale up: nâng cấu hình (CPU/RAM) của máy hiện tại — thường cần khởi động lại hoặc ít nhất gây gián đoạn.
• Scale down: hạ cấu hình máy hiện tại.

Trên cloud hiện đại, scale theo chiều ngang (out/in) phổ biến hơn vì không gây gián đoạn: hệ thống thêm máy mới, san sẻ tải qua load balancer, rồi thu hồi máy thừa khi tải giảm. Vấn đề nằm ở chỗ: "thêm khi nào, bớt khi nào, thêm bao nhiêu" — và đó chính là nội dung của chính sách autoscaling.

Một chính sách autoscaling hoàn chỉnh trả lời năm câu hỏi: (1) tín hiệu nào kích hoạt (metric gì, ngưỡng bao nhiêu)? (2) điều kiện duy trì bao lâu trước khi hành động? (3) mỗi lần hành động tăng/giảm bao nhiêu? (4) sau hành động, hệ thống "nghỉ" bao lâu trước khi đánh giá lại? (5) giới hạn trần và sàn ở đâu (tối thiểu/tối đa bao nhiêu máy)?

Vì sao chính sách autoscaling quyết định hóa đơn cloud?

Nhiều doanh nghiệp nghĩ autoscaling chỉ là chuyện kỹ thuật — "chạy nhanh là được". Thực tế, policy trực tiếp điều khiển tiền bạc theo hai cách đối nghịch nhau.

Scale thừa = trả tiền cho tài nguyên không sinh giá trị. Một policy quá "nhạy cảm" (ngưỡng kích hoạt thấp, bước tăng lớn, thu hồi chậm) khiến hệ thống duy trì 20 instance trong khi chỉ cần 8. Với giá minh họa 1.500.000đ/máy/tháng, 12 máy thừa nghĩa là đốt 18.000.000đ mỗi tháng, 216.000.000đ một năm — trong khi chẳng ai dùng đến.

Scale muộn = mất doanh thu và uy tín. Ngược lại, policy quá "thận trọng" (ngưỡng quá cao, tăng quá chậm) khiến server quá tải đúng lúc khách hàng đổ về. Một website thương mại điện tử sập 30 phút trong giờ vàng có thể mất hàng trăm triệu doanh thu, chưa kể khách hàng bỏ đi và không quay lại.

Chính sách autoscaling tốt là điểm cân bằng: giữ hiệu năng ổn định trong mức SLA cam kết, đồng thời giữ chi phí compute ở mức thấp nhất có thể. Trong ngôn ngữ FinOps, đây chính là nguyên tắc vừa đủ (right-provisioning) — không dư, không thiếu.

Chính sách autoscaling: 4 loại scaling policy phổ biến: chọn loại nào cho workload nào?

Các nền tảng cloud (AWS, Google Cloud, Azure) và các hệ orchestration như Kubernetes đều hỗ trợ bốn họ chính sách dưới đây, với tên gọi có thể khác nhau đôi chút.

Target tracking scaling là loại dễ dùng và phổ biến nhất. Bạn chỉ định mục tiêu cần duy trì — ví dụ "giữ CPU trung bình ở 50%" — hệ thống tự tính toán tăng/giảm bao nhiêu máy để đạt mục tiêu đó. Giống như bật điều hòa ở 25 độ: máy tự điều chỉnh công suất, bạn không cần bấm từng nấc. Ưu điểm: đơn giản, tự cân bằng, phù hợp phần lớn workload web biến động theo ngày. Nhược điểm: phản ứng có phần chậm với các đợt spike đột ngột, và đôi khi "tham" mục tiêu đến mức scale thừa trong các dao động nhỏ.

Step scaling chia ngưỡng tải thành các bậc thang, mỗi bậc tương ứng một hành động cụ thể. Ví dụ (minh họa): CPU > 70% thì thêm 1 máy, CPU > 80% thêm 2 máy, CPU > 90% thêm 3 máy; CPU < 30% thì bớt 1, CPU < 20% thì bớt 2. Ưu điểm: kiểm soát chính xác từng mức phản ứng, tốt với workload có mức tải phân tầng rõ ràng (ví dụ xử lý batch theo batch). Nhược điểm: phải tự thiết kế từng bậc, dễ "lỏng lẻo" nếu bậc quá thưa hoặc quá dày.

Simple scaling là dạng cổ điển nhất: mỗi cảnh báo gắn với đúng một hành động cố định (ví dụ: "khi CPU > 70% trong 5 phút thì thêm 1 máy"). Đơn giản nhưng thô: không phân biệt được tải vừa tăng nhẹ hay tăng sốc, và dễ gây hiện tượng phình-xẹp liên tục nếu không đặt thời gian nghỉ (cooldown) hợp lý. Ngày nay nó dần bị target tracking và step scaling thay thế.

Scheduled scaling không dựa vào metric mà dựa vào lịch. Bạn đặt giờ: "mỗi ngày 8h sáng tăng lên 10 máy, 22h tối giảm về 3 máy" — phù hợp workload có nhịp sinh hoạt cố định: sàn thương mại điện tử cao điểm ban ngày, hệ thống nội bộ văn phòng chỉ dùng giờ hành chính, trường học/đào tạo trực tuyến theo lịch học.

Lưu ý thực tế: các loại policy có thể kết hợp. Công thức phổ biến của nhiều team là scheduled cho phần "đáy" theo giờ hành chính + target tracking cho phần biến động còn lại — vừa dự đoán được chi phí, vừa linh hoạt khi có spike.

Chính sách autoscaling: chọn metric kích hoạt: CPU không phải lúc nào cũng đúng

Sai lầm phổ biến nhất khi viết chính sách autoscaling là mặc định lấy CPU làm metric duy nhất. CPU phù hợp với ứng dụng tính toán thuần túy, nhưng nhiều workload hiện đại có "điểm nghẽn" nằm ở nơi khác.

Request count / requests per second (RPS): số yêu cầu mỗi giây là metric phản ánh đúng nhất "độ đông khách" của web. Website bán hàng có thể CPU chỉ 40% nhưng hàng đợi request đã dài gấp 3 lần — đây là dấu hiệu cần thêm máy ngay, trước khi CPU kêu cứu.

Request latency: độ trễ phản hồi trung bình. Nếu latency tăng trong khi CPU vẫn thấp, nghĩa là ứng dụng đang chờ thứ khác (database, API bên thứ ba) — scale thêm máy không giải quyết được, thậm chí còn làm tệ hơn vì database càng quá tải. Đây là ví dụ điển hình: metric sai dẫn đến hành động sai.

Queue length (độ dài hàng đợi): với hệ xử lý bất đồng bộ (worker xử lý đơn hàng, render video, gửi email), số message chờ trong hàng đợi là metric chuẩn xác nhất. Quy tắc kinh điển (minh họa): đặt mục tiêu "mỗi worker xử lý tối đa 1.000 message" — hàng đợi có 5.000 message thì cần 5 worker.

Memory: ứng dụng cache, xử lý dữ liệu lớn, database in-memory cạn RAM trước khi cạn CPU. Nhưng memory là metric "một chiều": nhiều ứng dụng chiếm RAM rồi không trả (memory leak nhẹ), khiến policy scale liên tục. Hãy dùng memory cho các ứng dụng quản lý bộ nhớ tốt, và luôn đặt giới hạn trần.

Custom metric: tín hiệu nghiệp vụ riêng — số đơn hàng đang chờ, số phòng học trực tuyến đang mở, số luồng video đang stream. Đây là metric "đắt" nhất (phải tự phát triển và giám sát) nhưng chính xác nhất với bài toán kinh doanh.

Bảng gợi ý chọn metric theo loại ứng dụng:

Nguyên tắc vàng: scale theo tài nguyên mà workload của bạn thực sự cạn trước. Nếu không chắc, theo dõi cả CPU, memory, latency và queue trong 2–4 tuần trước khi viết policy — dữ liệu thực tế luôn đúng hơn cảm tính.

Cooldown và hysteresis: cách chống "flapping" (phình-xẹp liên tục)

Có một căn bệnh phổ biến của autoscaling gọi là flapping — hệ thống thêm máy, tải giảm ngay, hệ thống bớt máy, tải lại tăng, cứ thế phình-xẹp liên tục như nhịp thở. Mỗi lần thêm-bớt đều tốn thời gian khởi động, gây tải cho load balancer, và trên cloud trả theo giờ, bạn còn trả tiền cho cả những phút "vô ích" đó.

Hai cơ chế chính để trị flapping:

Cooldown (thời gian nghỉ) là khoảng "im lặng" bắt buộc sau mỗi lần scale. Ví dụ (minh họa): đặt cooldown 300 giây nghĩa là sau khi thêm 1 máy, hệ thống không được thêm/bớt máy nào khác trong 5 phút — đủ thời gian để máy mới khởi động, nhận tải và ổn định. Thực tiễn hay dùng: cooldown 180–300 giây cho scale-out (phản ứng nhanh khi tải tăng), 300–600 giây cho scale-in (thu hồi chậm, thận trọng). Sai lầm kinh điển: đặt cooldown quá ngắn (ví dụ 30 giây) — máy mới chưa kịp khởi động xong thì policy đã ra quyết định tiếp theo dựa trên dữ liệu cũ, và hệ thống scale chồng chất.

Hysteresis (vùng trễ) nghĩa là ngưỡng scale-in thấp hơn đáng kể so với ngưỡng scale-out, tạo ra "vùng đệm" ở giữa. Ví dụ (minh họa): scale-out khi CPU > 70%, nhưng chỉ scale-in khi CPU < 35% — khoảng 35–70% là vùng an toàn, hệ thống không làm gì cả. Nếu đặt hai ngưỡng sát nhau (ví dụ scale-out ở 70%, scale-in ở 65%), hệ thống sẽ rung lắc quanh ngưỡng, thêm-bớt liên tục mỗi khi tải nhấp nhô.

Bảng cấu hình mẫu (minh họa) cho web bán hàng trung bình:

Lưu ý hai chi tiết quan trọng: scale-out tăng nhiều (+2) nhưng scale-in giảm ít (−1) — "mở nhanh, thu chậm" là triết lý an toàn chung; và điều kiện scale-in luôn khắt khe hơn (duy trì 10 phút mới thu hồi) để tránh thu hồi nhầm một đợt giảm tải nhất thời.

Scale-to-zero: tiết kiệm tối đa cho môi trường không dùng thường xuyên

Mức "scale-in" cực đoan nhất là scale-to-zero: khi không có tải, hệ thống tắt hoàn toàn, không còn máy nào chạy và bạn không trả đồng nào cho compute. Đây là tính năng đặc trưng của các nền tảng serverless (AWS Lambda, Google Cloud Run, Azure Functions) và được hỗ trợ trên Kubernetes qua các công cụ như KEDA.

Scale-to-zero phù hợp với: môi trường dev/test chỉ dùng giờ hành chính; webhook/API xử lý sự kiện theo đợt; batch job chạy theo lịch; website nội bộ ít truy cập. Ví dụ (minh họa): cụm dev gồm 4 máy chỉ dùng 8h–18h các ngày trong tuần — scale-to-zero ngoài khung giờ này giảm hóa đơn compute của cụm từ 100% xuống còn ~36% mà không ảnh hưởng ai.

Nhưng scale-to-zero có cái giá: cold start. Khi request đầu tiên đến, hệ thống phải khởi động máy/container từ con số 0, có thể mất từ vài giây đến vài phút. Với API trả lời khách hàng trực tiếp, cold start vài chục giây là không chấp nhận được. Giải pháp dung hòa: giữ "số lượng tối thiểu = 1" cho dịch vụ production cần phản hồi nhanh, chỉ scale-to-zero cho workload không nhạy cảm với độ trễ khởi động.

Bẫy "scale thừa": 6 cách autoscaling âm thầm đốt tiền

Ngay cả khi đã bật autoscaling, nhiều hệ thống vẫn lãng phí vì những bẫy tinh vi dưới đây.

1. Ngưỡng mục tiêu quá thấp. Đặt target tracking giữ CPU ở 30% nghĩa là hệ thống luôn duy trì gấp đôi số máy cần thiết so với mục tiêu 60%. Mỗi 10% mục tiêu CPU thấp hơn tương đương số máy cần nhiều hơn một cách tuyến tính. Trừ khi SLA yêu cầu độ trễ cực thấp, mục tiêu 50–70% CPU là điểm ngọt của đa số workload.

2. Không đặt giới hạn trần (max). Một policy không giới hạn max là tấm séc trắng. Có trường hợp vòng lặp lỗi (retry storm) khiến traffic tăng đột biến giả, autoscaling scale lên hàng trăm máy trong vài giờ, hóa đơn phình gấp hàng chục lần trước khi ai đó phát hiện. Luôn đặt max = số máy cao nhất bạn từng cần trong đợt cao điểm lịch sử, cộng thêm 20–30% biên dự phòng.

3. Scale-in quá chậm hoặc không scale-in. Nhiều team chỉ cấu hình scale-out mà quên scale-in, hoặc đặt điều kiện scale-in khắt khe đến mức gần như không bao giờ kích hoạt. Hệ thống cứ phình to sau mỗi đợt cao điểm rồi "quên" xẹp xuống. Quy tắc: thời gian scale-in thành công phải được kiểm thử như một tính năng, không phải mặc định nó sẽ chạy.

4. Scale theo metric sai (xem mục trên). Scale thêm máy khi nghẽn ở database không những không giải quyết được vấn đề mà còn tăng số kết nối vào database, làm nó sập nhanh hơn — trong khi bạn vẫn trả tiền cho đám máy mới vô dụng.

5. Quên chi phí "ẩn" đi kèm mỗi instance. Mỗi máy thêm vào không chỉ tốn tiền compute: còn có phí IP public, dung lượng log tăng, kết nối license phần mềm tính theo node, và phí load balancer xử lý thêm. Khi tính toán, hãy dùng chi phí toàn phần mỗi instance, không chỉ giá niêm yết của máy ảo.

6. Test tải không bao giờ chạy. Policy được viết ra nhưng chưa từng được kiểm thử bằng tải giả lập. Đến khi cao điểm thật đến, policy hoạt động sai (hoặc không hoạt động), team phải scale tay trong lúc hệ thống đang cháy. Hãy chạy load test định kỳ hàng quý: giả lập gấp 2–3 lần tải đỉnh lịch sử và quan sát policy phản ứng — đo thời gian từ khi tải tăng đến khi máy mới nhận tải, và thời gian thu hồi sau khi tải giảm.

Ví dụ tổng hợp (minh họa): một hệ thống 10 máy với policy tốt (target CPU 60%, max 20, scale-in chủ động) tốn khoảng 15 triệu đồng/tháng compute; cùng hệ thống với policy dở (target CPU 30%, không max, scale-in yếu) có thể phình lên 20 máy và tốn 30 triệu đồng/tháng — gấp đôi, cho cùng một lượng khách hàng.

Autoscaling trên Kubernetes: HPA, VPA và Cluster Autoscaler

Nếu hệ thống của bạn chạy trên Kubernetes, autoscaling được chia thành ba cơ chế riêng biệt — nhầm lẫn giữa chúng là sai lầm rất phổ biến.

HPA (Horizontal Pod Autoscaler) tăng/giảm số lượng bản sao (replica) của pod dựa trên CPU, memory hoặc custom metric. Đây là "cái cần đẩy" chính cho đa số ứng dụng web chạy trên K8s. Ví dụ cấu hình (minh họa): giữ CPU trung bình mỗi pod ở 60%, tối thiểu 2 replica, tối đa 10 replica.

VPA (Vertical Pod Autoscaler) điều chỉnh lượng CPU/RAM cấp cho từng pod hiện có, thay vì tăng số lượng pod. Phù hợp workload không chia nhỏ theo chiều ngang tốt (database, ứng dụng đơn luồng nặng). Quan trọng: đừng bật HPA và VPA cùng lúc trên cùng một metric cho cùng một workload — HPA thêm pod trong khi VPA đồng thời đổi kích thước pod, hai cơ chế giằng co nhau và gây bất ổn.

Cluster Autoscaler hoạt động ở tầng cụm: thêm/bớt node (máy vật lý/ảo) khi pod không còn chỗ chạy (pending) hoặc node bị dùng không hết. Nó phản ứng với quyết định của HPA/VPA: HPA muốn thêm pod mà hết chỗ → Cluster Autoscaler thêm node.

Trên cloud Việt Nam, Kubernetes đang ngày càng phổ biến cho doanh nghiệp vừa và lớn; với team nhỏ, autoscaling ở tầng máy ảo (ASG-style) hoặc các dịch vụ container-managed đơn giản hơn thường đủ dùng và dễ vận hành hơn.

Checklist thiết lập chính sách autoscaling an toàn

1. Đo trước khi viết: thu thập metric thực tế 2–4 tuần, xác định tài nguyên cạn trước (CPU/RAM/queue/latency).
2. Chọn đúng metric: scale theo điểm nghẽn thật của workload, không mặc định CPU.
3. Đặt min và max bắt buộc: min đảm bảo dự phòng tối thiểu, max là "cầu chì" chống hóa đơn bùng nổ.
4. Thiết kế hysteresis: ngưỡng scale-in thấp hơn scale-out ít nhất 25–35 điểm phần trăm.
5. Đặt cooldown hợp lý: scale-out 3–5 phút, scale-in 5–10 phút; scale-in luôn thận trọng hơn.
6. "Mở nhanh, thu chậm": mỗi lần scale-out tăng nhiều hơn số lượng scale-in giảm.
7. Kết hợp scheduled + dynamic: scheduled cho nhịp cố định, target tracking/step cho biến động.
8. Tính chi phí toàn phần: cộng cả IP, log, license theo node khi ước tính.
9. Cảnh báo trước khi chạm max: khi hệ thống chạm 80% giới hạn max, gửi cảnh báo cho team — đó có thể là tấn công hoặc lỗi vòng lặp.
10. Load test định kỳ: hàng quý giả lập 2–3 lần tải đỉnh, đo thời gian scale-out và scale-in thực tế.

Áp dụng thực tế cho doanh nghiệp Việt Nam

Với doanh nghiệp dùng public cloud quốc tế (AWS/Azure/Google), autoscaling là tính năng có sẵn: Auto Scaling Group, VM Scale Sets, Managed Instance Groups. Với cloud nội địa Việt Nam, khả năng autoscaling tùy nhà cung cấp — một số đã hỗ trợ autoscaling cho Cloud Server, số khác hỗ trợ ở tầng Kubernetes hoặc qua API để team tự xây dựng cơ chế scale.

Khi đánh giá nhà cung cấp trong nước, hãy hỏi rõ: có hỗ trợ autoscaling tự động theo metric không hay phải tự viết script gọi API? Metric nào được hỗ trợ (CPU/RAM/network)? Thời gian khởi động một Cloud Server mới là bao lâu (ảnh hưởng trực tiếp đến thiết kế cooldown)? Có giới hạn số lần scale mỗi giờ không? Và chính sách tính tiền khi scale theo giờ/phút như thế nào?

Các gói Cloud Server của SunCloud hỗ trợ dùng thử 10 ngày — khoảng thời gian lý tưởng để đo metric thực tế, chạy load test và căn chỉnh policy trước khi đưa vào production. Hạ tầng Tier III với uptime cam kết 99,98% giúp quá trình scale-out/scale-in diễn ra trên nền tảng ổn định, không bị gián đoạn bởi sự cố hạ tầng. Khi policy đã chuẩn, kết hợp với chính sách thanh toán dài hạn (giảm sâu khi trả trước 12–48 tháng — giá tham khảo tại thời điểm viết, xem giá mới nhất tại suncloud.vn), doanh nghiệp vừa có hệ thống tự co giãn theo tải, vừa "neo" được chi phí ở mức tối ưu.

Kết luận

Chính sách autoscaling tốt không phải policy scale nhanh nhất, mà là policy cân bằng nhất: scale đủ nhanh để giữ SLA trong cao điểm, đủ chậm và thận trọng khi thu hồi để không đốt tiền vào tài nguyên thừa. Năm trụ cột cần nhớ: chọn đúng metric theo điểm nghẽn thật, thiết kế hysteresis và cooldown chống flapping, luôn đặt giới hạn max như một cầu chì tài chính, kết hợp scheduled với dynamic cho workload có nhịp cố định, và kiểm thử bằng load test định kỳ.

Nếu hệ thống của bạn đang chạy cố định một số lượng máy quanh năm — vừa lo sập khi cao điểm, vừa tiếc tiền những tháng vắng khách — thì đây là lúc thiết kế lại chính sách autoscaling. SunCloud với hạ tầng Cloud Server Tier III, uptime 99,98% và chính sách dùng thử 10 ngày giúp bạn đo đạc, thử nghiệm và căn chỉnh policy an toàn trước khi áp dụng thật. Liên hệ hotline 083 979 3434 hoặc truy cập suncloud.vn để được tư vấn phương án phù hợp.

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

Chính sách autoscaling khác gì với autoscaling?

Autoscaling là khả năng tự động co giãn của hệ thống; chính sách autoscaling (policy) là bộ quy tắc quyết định co giãn như thế nào — metric nào, ngưỡng bao nhiêu, tăng/giảm bao nhiêu, nghỉ bao lâu. Cùng một hệ thống autoscaling, policy khác nhau cho ra hóa đơn và hiệu năng hoàn toàn khác nhau.

Nên đặt mục tiêu CPU bao nhiêu phần trăm?

Điểm ngọt của đa số workload web là 50–70%. Dưới 40% nghĩa là bạn đang trả tiền cho quá nhiều máy dự phòng; trên 80% nghĩa là không còn biên an toàn cho spike đột ngột. Workload nhạy cảm với độ trễ (game, stream) có thể đặt thấp hơn (40–50%), workload batch chịu được trễ có thể đặt cao hơn (70–80%).

Cooldown bao lâu là hợp lý?

Phổ biến: 3–5 phút cho scale-out, 5–10 phút cho scale-in. Nguyên tắc: cooldown phải dài hơn thời gian một máy mới khởi động xong và nhận tải. Nếu máy mất 4 phút để sẵn sàng mà cooldown chỉ 1 phút, policy sẽ ra quyết định tiếp theo dựa trên dữ liệu chưa phản ánh máy mới — dẫn đến scale chồng chất.

Scale-to-zero có phù hợp với website bán hàng không?

Thường là không cho production. Cold start từ 0 có thể mất từ vài giây đến vài phút — khách hàng sẽ bỏ đi trước khi trang kịp tải. Scale-to-zero phù hợp với dev/test, batch job theo lịch, API xử lý sự kiện không nhạy cảm với độ trễ. Với web bán hàng, hãy giữ tối thiểu 1–2 máy luôn chạy.

Có nên bật HPA và VPA cùng lúc trên Kubernetes không?

Không nên trên cùng một metric cho cùng một workload. HPA tăng số lượng pod trong khi VPA đồng thời thay đổi kích thước pod — hai cơ chế giằng co nhau gây bất ổn. Hãy chọn một: HPA cho workload chia nhỏ được theo chiều ngang, VPA cho workload khó chia nhỏ như database.

Autoscaling có làm tăng hóa đơn không?

Có, nếu policy thiết kế dở: ngưỡng mục tiêu quá thấp, không đặt giới hạn max, scale-in quá chậm hoặc metric sai. Autoscaling chỉ tiết kiệm khi policy được căn chỉnh đúng — đó chính là lý do bài viết này tập trung vào chính sách chứ không chỉ công cụ.

Bài viết liên quan

• Cloud VPS là gì? Lợi ích khi sử dụng Cloud VPS là gì?
• Cho thuê máy chủ ảo - Bảng giá dịch vụ đám mây chi tiết