ASG - Scaling Policies

Scaling Policy

Dynamic Scaling

Target Tracking Scaling

• Kiểu này giống như 1 cái thermostat (bộ điều nhiệt).
• Bạn chỉ định 1 target, ví dụ: “giữ CPU trung bình của ASG ở mức 40%”.
• ASG sẽ tự động scale-in / scale-out để giữ CPU gần mức 40%.

👉 Dễ dùng, phù hợp với hầu hết case load dao động liên tục.

⏩ Ví dụ:

Target CPU: 40%
Nếu CPU vượt 40% → tự động scale-out.
Nếu CPU thấp hơn 40% → tự động scale-in.

Simple / Step Scaling

• Trigger bằng CloudWatch Alarm, với từng ngưỡng cụ thể.
• Bạn define cụ thể:
  • Nếu CPU > 70% thì tăng 2 instance.
  • Nếu CPU < 30% thì giảm 1 instance.

🧠 Đây là loại rule-based, nên phù hợp với các hệ thống mà load lên/xuống theo bước rõ ràng (step function).

Scheduled Scaling

• Dành cho các hệ thống có pattern dùng tài nguyên theo thời gian (ví dụ: giờ hành chính, giờ vàng,...).
• Bạn định nghĩa thời điểm và hành động.

⏩ Ví dụ:

Vào 17:00 thứ Sáu, tăng Min Capacity = 10.
Vì biết lúc đó có chiến dịch sale.

Predictive Scaling 

• Một dạng nâng cấp hơn của Scheduled Scaling, kết hợp với khả năng machine learning của AWS để tự động dự đoán và lên lịch scaling trước khi load thực sự xảy ra.

1. Analyze historical load
   - AWS Auto Scaling sử dụng dữ liệu load thực tế trong quá khứ (ví dụ: CPU, request count, v.v...)
   - Từ 4/1 đến 4/15: thu thập hành vi sử dụng tài nguyên.
2. Generate forecast
   - Dùng mô hình dự đoán để vẽ ra pattern trong tương lai (từ 4/15 đến 4/30).
   - Đường nét đứt thể hiện dự đoán load trong tương lai.
   - ML model này của AWS sẽ học pattern lặp lại theo thời gian (daily/weekly cycles).
3. Scaling actions
   - Dựa trên dự đoán, ASG sẽ tự động lên lịch scale-in / scale-out.
   - Các cột xám là "capacity planned ahead" (ví dụ số EC2 instance được tạo trước khi peak load xảy ra).
   - So với Scheduled Scaling thường (mình tự set giờ), cái này tự động thông minh hơn.

Các metric tốt để sử dụng cho Auto Scaling

• CPUUtilization: Mức sử dụng CPU trung bình trên toàn bộ các instance.
• RequestCountPerTarget: Đảm bảo rằng số lượng request trên mỗi EC2 instance là ổn định.

• Average Network In / Out: Dành cho ứng dụng có phụ thuộc nhiều vào băng thông mạng.
• Bất kỳ custom metric nào (do bạn tự đẩy lên thông qua CloudWatch).

Auto Scaling Groups – Thời gian Cooldown (Scaling Cooldowns)

• Sau khi một hoạt động scaling diễn ra, hệ thống sẽ bước vào thời gian cooldown (mặc định là 300 giây).
• Trong khoảng thời gian cooldown, Auto Scaling Group (ASG) sẽ không launch hoặc terminate thêm instance nào nữa → mục đích là để các metrics ổn định lại trước khi thực hiện scaling tiếp.
• Khuyến nghị: Sử dụng AMI đã cấu hình sẵn (ready-to-use AMI) để giảm thời gian khởi tạo cấu hình, giúp phục vụ request nhanh hơn và rút ngắn thời gian cooldown.
  • Ready-to-use AMI:
    • Là một khái niệm / định nghĩa về cách bạn xây dựng AMI để phục vụ cho mục tiêu: launch lên là chạy ngay.
    • Pre-cài app, dependencies.
    • Đã có code backend hoặc agent.
    • Có thể tự động join ALB, lấy config nếu cần.
    • Vậy build một “Ready-to-use AMI” nghĩa là gì?
      • Nó là cách bạn cấu hình một AMI tùy chỉnh, thường bao gồm:

• Khi EC2 được launch từ AMI này:
  • Boot lên là chạy ngay.
  • Thời gian từ launch → serve traffic rất ngắn.

Cooldown có thể rút ngắn lại vì instance ổn định nhanh → scaling actions kế tiếp có thể trigger đúng lúc hơn.

• Scaling Action Occurs → Một hành động scaling (tăng hoặc giảm instance) diễn ra.
• Kiểm tra: Default Cooldown in effect?
  • Nếu Có: Bỏ qua action này (tránh scaling liên tục không kiểm soát).
  • Nếu Không: Thực hiện launch hoặc terminate instance mới.