Tôi chưa từng thấy ai làm được Autoscaling mà không Overprovision 200%

Tôi không biết mọi người sao chứ cá nhân tôi chưa từng thấy team nào làm auto scaling thật sự hiệu quả mà không chấp nhận overprovision đến 200%. Tức là để hệ thống scale tự động ổn định, lúc nào cũng phải chấp nhận chạy dư tài nguyên gấp đôi hoặc hơn chứ nếu chỉ tính toán sát nút theo usage thì sớm muộn cũng chết Production.

Theo kinh nghiệm của tôi thì auto scaling chỉ là một câu chuyện đẹp trong slide hoặc buổi demo. Ra thực tế rồi, mọi thứ phức tạp hơn rất nhiều. Cái đầu tiên đập vào mặt là… metric lag.

1. Metrics lag và tín hiệu nhiễu

Hầu hết autoscaler (HPA, VPA, Cluster Autoscaler, thậm chí các tool xịn như Karpenter, Goldilocks, hay custom logic xài Prometheus Adapter) đều dựa vào metrics CPU, memory, đôi khi là custom metrics như RPS, latency, queue depth.

Vấn đề là metrics luôn có độ trễ. Prometheus scrape mỗi 15s, rồi phải đợi aggregation. Sau đó HPA poll lại mỗi 30s-60s. Lúc bạn scale lên là lúc user đã bỏ đi, còn lúc scale xuống thì burst traffic mới vừa vào.

Chưa kể có hàng tá sự kiện spike giả như cronjob chạy, task batch, GC, cold start… không xử lý ra logic cẩn thận thì autoscaler thành thằng “phá” hạ tầng, chứ không giúp gì cả.

2. Overprovision để cứu mình khỏi lỗi chết người

Tôi từng gặp team autoscale cực kỳ chính xác gần như matching usage từng millicore. Nhưng cái giá phải trả là vài lần pod scale chậm, request fail, backend timeout, alert nổ tùm lum. Sau lần đó, họ quyết định luôn để minReplica = 3 dù traffic thường chỉ cần 1.

Và đó là bài học: autoscale hiệu quả phải chấp nhận hy sinh tài nguyên để đổi lấy độ trễ thấp và độ tin cậy cao. Nếu bạn không overprovision, tức là bạn đang đánh cược rằng:

user sẽ đến đều đều
metrics luôn phản ánh đúng hiện tại
hệ thống không có spike bất thường

Mà như tôi thấy thì 3 điều đó chẳng khi nào đúng.

3. Workload khác nhau, không có 1 kiểu scale chung

Web API khác background worker, khác cronjob, khác ETL job, khác event-driven consumer. Thế nhưng rất nhiều nơi dùng cùng một bộ rule để autoscale cho tất cả xong rồi gặp chuyện thì đổ cho Cloud hay framework.

Autoscaling chỉ đúng khi:

Bạn hiểu rõ workload pattern.
Biết chính xác signal nào là “thật”.
Và thiết kế hệ thống sao cho scale được (ví dụ không giữ state trong memory, không xài local cache, pod nào lên cũng giống nhau).

Vấn đề là đa phần các app không hề được build như vậy từ đầu.

4. Autoscale không phải bật là chạy

Tôi không phản đối autoscaling. Tôi dùng nó mỗi ngày. Nhưng tôi nghĩ điều quan trọng là đừng thần thánh hóa nó, và nhất là đừng kỳ vọng autoscale sẽ giúp bạn tiết kiệm chi phí.

Thực tế là:

Bạn sẽ tốn nhiều thời gian tuning hơn tưởng tượng.
Sẽ chạy dư tài nguyên để hệ thống ổn định.
Và đôi khi phải scale thủ công trong các tình huống đặc biệt.

Tôi và mọi người có thể thích Cloud, thích automation, thích scaling dynamic, nhưng cuối ngày “Phải ưu tiên tính ổn định và trải nghiệm người dùng.”

Thế nên, nếu bạn thấy ai đó khoe autoscale tiết kiệm 80% chi phí, hãy hỏi họ:

Có lần nào bị alert nửa đêm vì scale không kịp chưa?

5. Đào sâu về Horizontal Pod Autoscaler (HPA): dễ hiểu, nhưng dễ chết

Ở ý 4 là đang định lại rồi để viết tiếp sau nhưng thôi đang vào luồng nên chém tiếp cho mọi người. Nhiều anh em mới nghĩ HPA là “cứ monitor CPU rồi tăng pod” nhưng thực tế scale hiệu quả bằng HPA đòi hỏi cực kỳ nhiều kinh nghiệm tuning.

5.1. CPU/memory gần như vô dụng với nhiều workload

Với API server chịu nhiều kết nối nhưng xử lý nhẹ (I/O bound), CPU gần như idle → HPA không scale dù đang quá tải thật.
Với worker background xử lý batch, memory tăng đều theo thời gian nhưng lại không release → bị scale lên vô nghĩa.

Đó là lý do phải chơi tới custom metrics như:

Length of job queue
Rate of incoming events
99th percentile latency
Concurrent users hoặc active sessions

Nhưng lúc này thì bạn lại phải build một pipeline metrics riêng (thường là Prometheus → Adapter → API server), lại tốn effort maintain, test và tránh signal nhiễu.

5.2. HPA scale theo average, không phải tail

Mặc định HPA lấy average CPU hoặc average custom metric để quyết định scale. Giả sử bạn có 10 pod, 9 cái idle, 1 cái full CPU → HPA thấy CPU trung bình là 10% → không scale!

Đây là lỗi chết người trong real-world. Một API backend mà chỉ cần 1 pod nghẽn là cả hệ thống timeout.

Fix:

Chuyển sang dùng custom metric + Prometheus histogram (quantile like P95 hoặc P99).
Hoặc tách traffic vào các pool khác nhau (canary, heavy-load pool…).

6. Cluster Autoscaler và thực tế đau đớn

Bên dưới layer pod là chuyện node-level autoscaling. Cluster Autoscaler của GKE, EKS, hay Karpenter của AWS – đều hoạt động dựa trên nhu cầu “pod nào pending” hoặc “node nào underused”.

6.1. Pod pending vì gì?

Có thể vì:

Pod yêu cầu ephemeral-storage cao hơn node nào cũng không đủ.
Pod cần taint toleration mà không node nào satisfy.
Pod xài PVC mà volume đó chỉ mount được 1 lần → nên pending vô vọng.

6.2. Karpenter thông minh hơn nhưng không phải thần thánh

Karpenter có thể launch node với shape phù hợp workload. Nghe rất hay, nhưng:

Bạn phải define well tất cả constraints (security group, instance type, labels, topology, architecture…).
Nếu AWS resource hết slot vùng (AZ) bạn đang xài, Karpenter đứng nhìn.

Thêm nữa, provisioning node mới vẫn mất 1-2 phút → quá trễ với burst traffic real-time.

7. Không scale được nếu không scale được… storage

Giả sử API của bạn scale lên 50 pod, nhưng tất cả pod đều ghi log vào 1 EFS hoặc S3 bucket chưa chắc backend chịu nổi request write liên tục từ 50 pod.

Tôi từng thấy team scale lên 100 pod xử lý hình ảnh → hệ thống nghẽn tại… shared database không chịu nổi lượng INSERT từ quá nhiều connection mở đồng thời.

Storage và database là bottleneck gốc rễ mà nhiều người bỏ qua khi scale app.

8. Có những thứ phải scale theo pattern, không theo usage

Cronjob mỗi giờ chạy batch → không cần auto scaling, cần đảm bảo job luôn có tài nguyên ưu tiên.
Consumer từ Kafka scale theo lag chứ không scale theo CPU.
ETL pipeline scale theo số lượng file trong S3, không theo request.

Autoscaler không thể giúp nếu bạn không biết workload của mình scale theo cái gì. Và rất nhiều người, kể cả 5-6 năm exp, cũng không biết workload của mình pattern ra sao vì chưa từng observability đúng cách.