Bỏ qua tới nội dung
CloudDojo
Phần 3/7 · 5 phút

Dynamic scaling: simple, step và target tracking scaling policy

0/2
Từ khóa của phần nàyChọn một từ để xem nghĩa trước khi đọc

Khi tải tăng đột ngột, điều quan trọng là launch thêm bao nhiêu instance và nhanh tới mức nào; mỗi loại dynamic scaling policy giải quyết vấn đề này theo cách khác nhau.

Ba loại dynamic scaling policy đều phản ứng theo CloudWatch metric, nhưng khác nhau ở cách tính số instance cần thêm và thời điểm được phản ứng tiếp. Với simple scaling và step scaling, người thiết kế tự tạo CloudWatch alarm với ngưỡng cố định; với target tracking, chỉ cần chọn metric và giá trị mục tiêu, Auto Scaling tự tạo và quản lý alarm. Chạy cùng một đợt tăng tải với từng policy:

Policy
CooldownAlarm CPU > 60% → thêm 2 instance

Lúc phút 4, MFTECH mở bán một sản phẩm được quảng bá rộng rãi: tải tăng gấp bốn và giữ nguyên. Nhóm đang chạy 4 instance, tối đa 20. Trong mô phỏng, instance mới sẵn sàng sau 2 phút.

CPU trung bình (%)050100ngưỡng alarm 60%Số instance010200′3′6′9′12′15′18′21′24′instance sẵn sàngdesired capacityđang chờ cooldown

Chọn policy, sau đó nhấn Chạy 25 phút. Với simple scaling, thử cả hai giá trị cooldown.

Hai khái niệm thời gian dễ nhầm lẫn. Cooldown (mặc định 300 giây) áp dụng cho simple scaling: sau mỗi scaling activity, policy không phản hồi alarm mới cho tới khi cooldown kết thúc. Instance warmup áp dụng cho target tracking và step scaling: instance mới chưa được tính vào metric tổng hợp của nhóm cho tới khi hết warmup, nhưng đã được tính vào desired capacity, nên policy không launch thừa instance. AWS khuyến nghị bật default instance warmup cho nhóm.

Ghi nhớ:
  • Giữ metric quanh một giá trị (CPU 50%, backlog SQS trên mỗi instance): target tracking, không phải step hay simple.
  • Step scaling: mức điều chỉnh theo độ lớn breach, phản hồi alarm liên tục.
  • Simple scaling: một mức điều chỉnh, chờ activity và cooldown, phản ứng chậm với tải tăng đột ngột; AWS khuyến nghị không dùng.
  • Cả ba đều phản ứng sau khi tải tăng; tải có chu kỳ cần predictive scaling.
Part 3/7 · 5 phút

Dynamic scaling: simple, step and target tracking scaling policies

0/2
Từ khóa của phần nàyChọn một từ để xem nghĩa trước khi đọc

When load spikes, what matters is how many instances to launch and how fast; each type of dynamic scaling policy handles this differently.

All three dynamic scaling policies react to a CloudWatch metric, but they differ in how they calculate the instances to add and when they may react again. With simple and step scaling, the designer creates CloudWatch alarms with fixed thresholds; with target tracking, the designer only picks a metric and a target value, and Auto Scaling creates and manages the alarms. Run the same surge under each policy:

Policy
CooldownAlarm CPU > 60% → thêm 2 instance

Lúc phút 4, MFTECH mở bán một sản phẩm được quảng bá rộng rãi: tải tăng gấp bốn và giữ nguyên. Nhóm đang chạy 4 instance, tối đa 20. Trong mô phỏng, instance mới sẵn sàng sau 2 phút.

CPU trung bình (%)050100ngưỡng alarm 60%Số instance010200′3′6′9′12′15′18′21′24′instance sẵn sàngdesired capacityđang chờ cooldown

Chọn policy, sau đó nhấn Chạy 25 phút. Với simple scaling, thử cả hai giá trị cooldown.

Two time settings are easy to confuse. The cooldown (300 seconds by default) applies to simple scaling: after each scaling activity, the policy does not respond to new alarms until the cooldown ends. Instance warmup applies to target tracking and step scaling: a new instance does not count toward the group’s aggregated metrics until its warmup ends, but it already counts toward desired capacity, so the policy does not launch extra instances. AWS recommends enabling the default instance warmup for the group.

Ghi nhớ:
  • Keep a metric near a value (CPU 50%, SQS backlog per instance): target tracking, not step or simple.
  • Step scaling: the adjustment depends on the size of the breach and alarms keep being answered.
  • Simple scaling: one adjustment, then wait for the activity and the cooldown, so it reacts slowly to a sudden surge; AWS recommends against it.
  • All three react after load rises; cyclical load needs predictive scaling.

Kiểm tra nhanh

Trả lời để ghi nhận đã đọc phần này. Câu trả lời sai sẽ được nhắc ôn lại vào những ngày sau.

MFTECH cần giữ CPU trung bình của nhóm quanh 50% mà không tự tạo và quản lý CloudWatch alarm. Chọn policy nào?
Với target tracking, instance mới launch chưa phản ánh tải thực tế. Cơ chế nào giúp policy không launch thừa instance trong khoảng thời gian này?

Đã trả lời 0/2 câu