System DesignChọn metric theo bản chất tải:
- Service CPU-bound → CPU utilization.
- Service I/O-bound (chờ DB, gọi API ngoài) → CPU gần như đứng yên trong khi đã nghẽn; dùng số request đang xử lý đồng thời hoặc RPS mỗi instance.
- Worker đọc queue → độ dài hàng đợi hoặc tuổi message cũ nhất chia cho số worker, đây là tín hiệu trực tiếp nhất.
- Nhìn thêm latency p95 như một biến kiểm chứng, nhưng đừng scale trực tiếp theo latency: latency tăng có thể do phụ thuộc bên dưới chậm, thêm instance chỉ làm phụ thuộc đó tệ hơn.
Vì sao vẫn lỗi lúc cao điểm — autoscaling luôn chạy sau tải:
- Trễ tích luỹ: metric lấy mẫu (~1 phút) + thời gian quyết định + khởi tạo máy + kéo image + warm-up/JIT + đăng ký health check. Tổng có thể vài phút, trong khi đỉnh tải chỉ mất vài giây để hình thành.
- Instance mới nhận lưu lượng khi chưa sẵn sàng (cache trống, pool chưa mở) nên latency ban đầu xấu, dễ bị health check loại ra.
- Nghẽn không nằm ở tầng app: DB hết connection thì thêm instance chỉ làm cạn nhanh hơn.
- Flapping: ngưỡng scale-in và scale-out sát nhau khiến cụm liên tục co giãn.
Cách giảm rủi ro: đặt ngưỡng scale-out thấp hơn cảm giác cần thiết để có biên; scale-out nhanh, scale-in chậm kèm cooldown; pre-scale theo lịch cho sự kiện biết trước (flash sale, mở bán vé); giữ một lượng dư nhất định; và luôn có load shedding làm lớp bảo vệ cuối, vì mọi cơ chế scaling đều có độ trễ.