定時任務與警示任務協同配置最佳實務
Auto Scaling支援定時任務和警示任務（含目標追蹤規則）兩種自動調整方式。在同時使用這兩種方式時，如果配置不當，可能導致定時擴容被警示任務覆蓋，最終容量不符合預期。本文介紹定時任務與警示任務的協同機制，並提供最佳配置方案，協助您避免伸縮衝突。
問題情境
當伸縮組同時開啟期望執行個體數、定時任務和警示任務（如目標追蹤規則）時，可能出現以下問題：定時任務在指定時間觸發擴容，但擴容尚未完成時，警示任務隨即觸發並覆蓋了定時任務設定的期望執行個體數，導致擴容未生效。
典型案例
原因分析
上述問題的根本原因在於定時任務與警示任務的執行機制差異：
|
對比維度 |
定時任務（僅修改期望執行個體數） |
警示任務 |
|
執行方式 |
僅修改期望執行個體數的值，不直接觸發伸縮活動 |
立即觸發伸縮活動並同步修改期望執行個體數 |
|
生效時間 |
期望執行個體數修改後，需要等待30秒~1分鐘才生效 |
立即生效 |
|
衝突風險 |
在等待生效的視窗期內，可能被其他任務覆蓋 |
執行後直接更新期望執行個體數為當前實際值 |
核心問題：當定時任務僅修改期望執行個體數時，該操作不是一次原子性的、立即生效的容量變更。在30秒~1分鐘的生效延遲期間，警示任務可能基於當前的實際執行個體數觸發伸縮活動，並重新計算和覆蓋期望執行個體數。
最佳實務：定時任務控制基座容量，警示任務控制彈性容量
方案概述
採用"基座 + 彈性"的分層容量模型，將定時任務和警示任務的職責明確分離：
-
基座容量（定時任務負責）：通過定時任務同步設定最小執行個體數和期望執行個體數，保證業務高峰期的底線容量不被警示任務縮容。
-
彈性容量（警示任務負責）：通過目標追蹤規則或警示任務，在基座容量之上根據實際負載動態增減執行個體。
操作步驟
以下通過一個樣本情境說明推薦配置：假設業務需要在每天早上8:00將執行個體數從日常的10台擴容至50台，晚上22:00恢複日常水平，同時使用目標追蹤規則維持CPU使用率在60%。
步驟一：建立定時擴容任務
建立一個定時任務，在業務高峰開始時同步設定最小執行個體數和期望執行個體數，確保基座容量立即生效且不會被警示任務覆蓋。
-
在左側導覽列，單擊伸縮組管理。
-
找到目標伸縮組，單擊伸縮組名稱進入詳情頁面。
-
單擊伸縮規則與任務頁簽，在定時任務列表下，單擊建立定時任務。
-
建立定時擴容任務，配置如下：
配置項
值
任务名称
scheduled-scale-up
執行時間
每天早上8:00（或業務高峰開始時間）
週期
按天
伸缩方式
伸縮組內實例數量設置
最小实例数
50
期望实例数
50
關鍵配置：伸縮方式選擇伸縮組內實例數量設置，同時設定最小实例数和期望实例数為50。這樣定時任務執行時會同步修改伸縮組的最小執行個體數和期望執行個體數，確保容量不會被警示任務縮容到50台以下。
步驟二：建立定時縮容任務
建立一個與擴容任務成對的定時縮容任務，在業務高峰結束後將最小執行個體數恢複到日常水平，避免資源浪費。
-
在定時任務列表下，單擊建立定時任務，配置如下：
配置項
值
任务名称
scheduled-scale-down
執行時間
每天晚上22:00（或業務高峰結束時間）
週期
按天
伸缩方式
伸縮組內執行個體數量設定
最小实例数
10
期望实例数
10
步驟三：配置目標追蹤規則
建立目標追蹤規則，讓警示任務在定時任務設定的基座容量之上，根據實際負載自動進行Auto Scaling。
-
單擊伸縮規則與任務頁簽，在伸縮規則列表下，單擊建立伸縮規則。
-
建立目標追蹤規則，配置如下：
配置項
值
伸縮規則類型
目標追蹤規則
指標類型
(ECS)平均CPU使用率
目標值
60%
目標追蹤規則會根據CPU使用率在伸縮組的最小執行個體數和最大執行個體數之間自動調整執行個體數量。由於定時任務已將最小執行個體數設定為50，即使CPU使用率較低，執行個體數量也不會低於50台。
配置後的執行效果
|
時間 |
事件 |
最小執行個體數 |
期望執行個體數 |
實際效果 |
|
每天 08:00 |
定時擴容任務觸發 |
10 → 50 |
10 → 50 |
立即開始擴容至50台 |
|
08:00~22:00 |
目標追蹤規則持續工作 |
50 |
≥50 |
CPU使用率高於60%時，在50台基礎上繼續擴容；低於60%時最多縮容至50台 |
|
每天 22:00 |
定時縮容任務觸發 |
50 → 10 |
50 → 10 |
恢複日常容量水平，多餘執行個體逐步釋放 |
|
其他時段 |
目標追蹤規則持續工作 |
10 |
≥10 |
根據CPU使用率在10台基礎上Auto Scaling |
配置要點總結
-
定時任務選擇"伸縮組內執行個體數量設定"伸縮方式，同時設定最小執行個體數和期望執行個體數，而非僅修改期望執行個體數。
-
成對建立定時任務：擴容和縮容任務成對出現，確保高峰期結束後最小執行個體數能恢複到日常水平，避免資源浪費。
-
最小執行個體數、期望執行個體數、最大執行個體數三者的關係：
-
定時任務通過設定最小執行個體數和期望執行個體數控制基座容量。
-
警示任務/目標追蹤規則在最小執行個體數和最大執行個體數之間進行彈性調整。
-
系統內建規則保證最小執行個體數 ≤ 期望執行個體數 ≤ 最大執行個體數，優先順序清晰，無需額外設計衝突規避機制。
-
常見問題
-
定時任務擴容成功後，如果CPU使用率較低，目標追蹤規則會不會把執行個體縮回去？
不會。定時任務同步設定了最小实例数，目標追蹤規則不會將執行個體數縮容到最小实例数以下。這就是為什麼同時設定最小实例数的關鍵。
-
定時任務只修改期望執行個體數是否可行？
不建議。僅修改期望实例数存在以下風險：
-
期望实例数修改後有30秒~1分鐘的生效延遲，期間警示任務可能覆蓋該值。
-
即使擴容成功，由於最小实例数未同步調整，目標追蹤規則可能將執行個體數縮容到預期以下。
-
-
是否需要在定時任務中同時設定最大執行個體數？
通常不需要。最大实例数一般保持一個固定的上限值，以防止異常情況導致執行個體無限擴容。如果您的業務情境需要在不同時段設定不同的執行個體上限，也可以在定時任務中同步調整最大实例数。
-
如果不使用目標追蹤規則，而是使用簡單規則的警示任務，還會有衝突嗎？
是的，同樣可能出現衝突。無論警示任務關聯的是簡單規則、步进规则還是目標追蹤規則，只要警示任務在定時任務的生效延遲期內觸發，都會覆蓋期望实例数。本文的解決方案對所有類型的警示任務均適用。