Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vận hành một hệ thống bán hàng online. Ngày thường lượng truy cập ổn định, bạn chạy 3 máy chủ là đủ. Nhưng đúng 12 giờ đêm ngày 11 tháng 11 — giờ mở màn của đợt sale 11.11 — lượng khách đổ vào tăng gấp 20 lần chỉ trong vài phút. Nếu vẫn chỉ có 3 máy chủ, hệ thống sập, khách không thanh toán được, và bạn mất tiền thật. Còn nếu bạn "phòng thủ" bằng cách bật sẵn 60 máy chủ chạy 24/7 quanh năm, thì 364 ngày còn lại bạn đang đốt tiền vào những cỗ máy ngồi không.
Đây chính là bài toán mà auto-scaling (tự động co giãn) ra đời để giải quyết. Auto-scaling là cơ chế cho phép hệ thống tự động thêm hoặc bớt tài nguyên tính toán dựa trên nhu cầu thực tế, mà không cần con người ngồi canh và bấm nút. Đây là một trong những "siêu năng lực" quan trọng nhất mà cloud mang lại — thứ mà máy chủ vật lý truyền thống rất khó làm được.
Trong bài này, chúng ta sẽ tìm hiểu ba "người anh em" của auto-scaling trên ba nền tảng lớn: ASG (Auto Scaling Group của AWS), MIG (Managed Instance Group của GCP), và HPA (Horizontal Pod Autoscaler của Kubernetes). Hiểu được ba khái niệm này, bạn sẽ nắm được xương sống của việc vận hành hệ thống co giãn trên cloud.
Khái niệm cốt lõi
Vì sao phải auto-scale?
Có ba lý do chính khiến auto-scaling trở thành tiêu chuẩn trong DevOps hiện đại:
1. Khớp năng lực với nhu cầu (match capacity with demand) → tiết kiệm chi phí. Trên cloud, bạn trả tiền theo giờ (hoặc theo giây) cho mỗi máy chủ đang chạy. Nếu ban đêm ít khách, hệ thống tự bớt máy; ban ngày đông khách, hệ thống tự thêm máy. Bạn chỉ trả tiền cho đúng phần bạn dùng.
2. Xử lý đột biến lưu lượng (traffic spike) tự động. Livestream bán hàng, flash sale, một bài viết viral trên mạng xã hội — những sự kiện này tạo ra đỉnh lưu lượng không đoán trước. Auto-scaling phản ứng trong vài phút mà không cần đội kỹ thuật thức đêm trực.
3. Tự thay thế máy chủ hỏng (unhealthy instance). Nếu một máy chủ "chết" hoặc phản hồi chậm bất thường, cơ chế auto-scaling phát hiện qua health check và tự động khai tử máy hỏng, tạo máy mới thay thế. Đây là nền tảng của khả năng "tự chữa lành" (self-healing).
Hai kiểu scaling: theo chiều dọc và chiều ngang
Trước khi đi sâu, cần phân biệt hai hướng co giãn:
- Vertical scaling (scale up/down — co giãn theo chiều dọc): làm cho một máy chủ mạnh hơn hoặc yếu đi (thêm CPU, thêm RAM). Giống như bạn thay động cơ xe máy bằng động cơ ô tô. Cách này có giới hạn trần và thường phải khởi động lại máy.
- Horizontal scaling (scale out/in — co giãn theo chiều ngang): thêm hoặc bớt số lượng máy chủ chạy song song. Giống như bạn thêm nhiều xe máy để chở hàng thay vì một xe tải khổng lồ. Đây là cách được ưa chuộng trên cloud vì gần như không có trần và không gây gián đoạn.
ASG — Auto Scaling Group (AWS)
ASG là nhóm các máy ảo EC2 được AWS quản lý như một khối thống nhất. Bạn định nghĩa:
- Launch Template: bản thiết kế cho mỗi máy (loại instance, image AMI, security group...).
- Min / Max / Desired capacity: số máy tối thiểu, tối đa và số máy mong muốn hiện tại. Ví dụ min=2, max=10, desired=3.
- Scaling policy (chính sách co giãn): quy tắc quyết định khi nào thêm/bớt máy. Phổ biến nhất là Target Tracking — ví dụ "giữ CPU trung bình quanh mức 50%". Khi CPU vượt 50%, ASG tự thêm máy; khi CPU tụt xuống, ASG bớt máy.
MIG — Managed Instance Group (GCP)
MIG là phiên bản của Google Cloud, tương đương với ASG. MIG dùng Instance Template làm bản thiết kế và hỗ trợ autoscaler dựa trên nhiều tín hiệu: mức sử dụng CPU, dung lượng phục vụ của load balancer, hoặc custom metric từ Cloud Monitoring.
Một điểm mạnh của MIG là autohealing (tự chữa lành): nếu ứng dụng của bạn có endpoint kiểm tra sức khỏe (health check trả về "OK"), MIG sẽ tự tạo lại bất kỳ máy nào không phản hồi. MIG cũng hỗ trợ rolling update — cập nhật phiên bản mới cho từng nhóm máy một cách tuần tự, không gây downtime.
HPA — Horizontal Pod Autoscaler (Kubernetes)
HPA hoạt động ở một tầng khác: tầng ứng dụng bên trong Kubernetes, chứ không phải tầng máy ảo. Thay vì thêm/bớt máy chủ, HPA thêm/bớt số lượng Pod (bản sao của ứng dụng đóng gói trong container).
HPA theo dõi các chỉ số như CPU, RAM, hoặc custom metric (ví dụ số request mỗi giây, độ dài hàng đợi). Bạn khai báo: "giữ CPU của mỗi Pod quanh 70%, số Pod dao động từ 3 đến 20". HPA sẽ tính toán và điều chỉnh số bản sao (replicas) tương ứng.
Điểm cực kỳ quan trọng cần nhớ: HPA scale số Pod, nhưng nếu cụm Kubernetes hết chỗ để đặt Pod mới thì cần Cluster Autoscaler (hoặc Karpenter trên AWS) để thêm node (máy ảo) cho cụm. Hai cơ chế này phối hợp với nhau: HPA lo tầng Pod, Cluster Autoscaler lo tầng máy ảo.
So sánh nhanh
| Đặc điểm | ASG (AWS) | MIG (GCP) | HPA (Kubernetes) |
|---|---|---|---|
| Đối tượng scale | Máy ảo EC2 | Máy ảo Compute Engine | Pod (container) |
| Tầng hoạt động | Hạ tầng | Hạ tầng | Ứng dụng |
| Bản thiết kế | Launch Template | Instance Template | Deployment |
| Tự chữa lành | Có | Có (autohealing) | Có (qua ReplicaSet) |
Tình huống thực tế
Tình huống 1 — Sàn TMĐT Việt Nam vượt bão sale 12.12
Một sàn thương mại điện tử tại TP.HCM (giả định tên là ShopViet) chạy backend trên AWS với ASG. Ngày thường họ giữ desired=4 máy EC2 loại c5.large. Trước đợt sale 12.12, đội DevOps làm hai việc:
- Đặt scheduled scaling (co giãn theo lịch): 23h50 ngày 11/12, ASG tự nâng min lên 12 máy để "làm nóng" sẵn — vì việc khởi động máy và ứng dụng mất khoảng 3-4 phút, không kịp phản ứng với đỉnh dốc đứng nếu đợi đến khi CPU tăng.
- Đặt target tracking policy giữ CPU quanh 50%, max=30 máy để xử lý phần đột biến còn lại.
Bài học: Với những đỉnh dốc đứng đã biết trước (sale, livestream), hãy kết hợp scheduled scaling để làm nóng trước, chứ đừng chỉ dựa vào reactive scaling (phản ứng sau khi tải tăng). Máy khởi động không kịp là nguyên nhân sập hệ thống phổ biến nhất.
Tình huống 2 — Startup fintech dùng Kubernetes và HPA
Một startup fintech ở Singapore triển khai microservice trên GKE (Google Kubernetes Engine). Dịch vụ xử lý giao dịch (payment-service) của họ cấu hình HPA: min=3, max=20 Pod, target CPU=65%.
Vào giờ cao điểm 8-9h sáng khi mọi người chuyển tiền đi làm, HPA tự nâng số Pod từ 3 lên 14. Nhưng đội kỹ thuật phát hiện đôi khi Pod mới "bật lên rồi tắt đi" liên tục (hiện tượng flapping/thrashing), gây bất ổn. Nguyên nhân: chỉ số CPU dao động mạnh khiến HPA phản ứng quá nhạy.
Họ khắc phục bằng cách: (a) chuyển từ chỉ số CPU sang custom metric là số request mỗi giây — sát với thực tế tải hơn; (b) cấu hình stabilizationWindowSeconds để HPA chờ một khoảng trước khi thu nhỏ, tránh co giãn giật cục. Song song, họ bật Cluster Autoscaler để đảm bảo khi HPA cần 14 Pod nhưng node hết chỗ, cụm tự thêm máy.
Bài học: CPU không phải lúc nào cũng là chỉ số tốt nhất. Với ứng dụng phụ thuộc I/O hoặc hàng đợi, custom metric phản ánh đúng bản chất tải hơn. Và luôn nhớ HPA cần Cluster Autoscaler đứng sau để có chỗ đặt Pod.
Tình huống 3 — Công ty logistics và bài học "quên đặt Max"
Một công ty logistics dùng GCP với MIG cho hệ thống tính toán lộ trình giao hàng. Một ngày, do lỗi trong một microservice khiến CPU tăng vọt bất thường (không phải do tải thật). MIG cấu hình max quá cao (không giới hạn thực tế), nên autoscaler cứ thêm máy liên tục — từ 5 lên 60 máy chỉ trong 40 phút. Hóa đơn cuối tháng tăng đột biến vài nghìn USD cho một lỗi phần mềm.
Bài học: Max capacity chính là "cầu chì" bảo vệ ví tiền của bạn. Luôn đặt max ở mức hợp lý dựa trên tải đỉnh thực tế cộng thêm biên độ an toàn, và bật billing alert để được cảnh báo khi chi phí vượt ngưỡng. Auto-scaling giúp tiết kiệm tiền, nhưng cấu hình sai lại có thể đốt tiền nhanh không kém.
Hướng dẫn từng bước
Dưới đây là quy trình chung để thiết lập một auto-scaling group (áp dụng được cho cả ASG và MIG với thuật ngữ tương ứng):
Bước 1 — Chuẩn bị bản thiết kế máy (Launch/Instance Template). Định nghĩa loại máy, image (đã cài sẵn ứng dụng hoặc dùng startup script), security group/firewall, và các thông số mạng.
Bước 2 — Xác định min, max, desired. Suy nghĩ kỹ: min phải đủ đảm bảo tính sẵn sàng (thường ≥2 để có dự phòng), max là trần chi phí và năng lực, desired là điểm khởi đầu.
Bước 3 — Cấu hình health check. Chỉ định endpoint kiểm tra (ví dụ GET /healthz trả về 200). Đây là điều kiện để cơ chế biết máy nào "khỏe", máy nào cần thay thế.
Bước 4 — Chọn scaling policy.
- Target Tracking: đơn giản và được khuyến nghị — "giữ CPU quanh 50%".
- Step/Simple Scaling: thêm N máy khi vượt ngưỡng X.
- Scheduled Scaling: co giãn theo lịch cố định (cho sự kiện đã biết trước).
Bước 6 — Đặt cooldown / stabilization window. Khoảng thời gian "hạ nhiệt" để tránh co giãn liên tục giật cục.
Với HPA trên Kubernetes, quy trình rút gọn hơn: bạn cần một Deployment đã đặt resources.requests cho CPU/RAM (HPA cần biết mốc này để tính toán), cài Metrics Server, rồi tạo đối tượng HPA khai báo min, max và target metric. Ví dụ khái niệm: "cho Deployment web, giữ CPU quanh 70%, min=3, max=15".
Lỗi thường gặp & mẹo
Lỗi 1 — Không đặt Max hợp lý. Như tình huống 3, thiếu trần chi phí có thể khiến một lỗi phần mềm biến thành hóa đơn khổng lồ. Luôn đặt max và bật cảnh báo chi phí.
Lỗi 2 — Bỏ qua thời gian khởi động (warm-up). Máy ảo mất vài phút để boot + cài đặt + sẵn sàng nhận request. Nếu đỉnh tải đến quá nhanh, reactive scaling không kịp. Mẹo: dùng scheduled scaling cho sự kiện biết trước, hoặc dùng golden image (AMI đã cài sẵn) để rút ngắn thời gian khởi động.
Lỗi 3 — HPA cấu hình mà quên resources.requests. Nếu Pod không khai báo request CPU, HPA không có mốc để tính phần trăm và sẽ không hoạt động. Đây là lỗi kinh điển của người mới.
Lỗi 4 — Thrashing (co giãn giật cục). Hệ thống liên tục thêm rồi bớt máy. Khắc phục bằng cooldown/stabilization window và chọn chỉ số ổn định hơn.
Lỗi 5 — Ứng dụng có trạng thái (stateful). Auto-scaling giả định các máy có thể thay thế lẫn nhau (stateless). Nếu bạn lưu session hay dữ liệu ngay trên máy, khi máy bị khai tử dữ liệu sẽ mất. Mẹo: đẩy trạng thái ra ngoài (Redis, database, object storage) để ứng dụng trở nên stateless.
Mẹo vàng — Scale out nhanh, scale in chậm. Khi tải tăng, hãy phản ứng nhanh để không sập. Khi tải giảm, hãy thu nhỏ từ từ để tránh cắt máy quá sớm rồi lại thiếu.
Bài tập thực hành
- Phân tích tình huống: Một ứng dụng có lưu lượng ổn định ban ngày nhưng gần như bằng 0 lúc 2-5h sáng. Bạn sẽ chọn kết hợp scaling policy nào (target tracking, scheduled, hay cả hai)? Vì sao?
- Tính toán chi phí: Giả sử một máy EC2 giá 0.1 USD/giờ. Phương án A: chạy cố định 20 máy suốt tháng. Phương án B: dùng ASG trung bình 6 máy, chỉ tăng lên 20 máy trong 4 giờ/ngày cho giờ cao điểm. Hãy ước tính chi phí mỗi tháng của hai phương án và cho biết tiết kiệm được bao nhiêu.
- Thiết kế cấu hình: Cho một web service dự kiến bình thường cần 3 máy, đỉnh sale cần khoảng 15 máy. Hãy đề xuất giá trị min, max, desired, chỉ số target và giải thích lựa chọn của bạn.
- Gỡ lỗi: HPA của bạn hiển thị
TARGET: <unknown>/70%và không scale. Hãy liệt kê ít nhất hai nguyên nhân có thể và cách kiểm tra.
Tóm tắt
Auto-scaling là năng lực cốt lõi giúp hệ thống cloud khớp năng lực với nhu cầu, xử lý đột biến lưu lượng, và tự thay thế máy hỏng. Ba công cụ đại diện là ASG (AWS) và MIG (GCP) — hoạt động ở tầng máy ảo, và HPA (Kubernetes) — hoạt động ở tầng Pod/ứng dụng, thường phối hợp với Cluster Autoscaler ở tầng dưới.
Những điều quan trọng nhất cần nhớ: đặt min/max hợp lý (max là cầu chì bảo vệ chi phí), chọn scaling policy phù hợp (target tracking cho phổ thông, scheduled cho sự kiện biết trước), tính đến thời gian khởi động, giữ ứng dụng stateless, và luôn bật cảnh báo chi phí. Auto-scaling cấu hình đúng sẽ vừa giúp hệ thống bền bỉ trước bão traffic, vừa tiết kiệm đáng kể chi phí vận hành — đúng tinh thần của DevOps hiện đại.