AutoScaling 目标追蹤伸縮規則概述

彈性伸縮目标追蹤伸縮規則是彈性伸縮服務與雲監控深度結合的産物，定義了更加穩定，精準，快速的彈性伸縮政策，解決了目前伸縮組動态調整過程存在的一些難點和問題。

目标追蹤伸縮規則

目标追蹤伸縮規則是彈性伸縮服務提供的一種新類型的伸縮規則，目标追蹤伸縮規則擴充了彈性伸縮服務原有的伸縮規則。在本次擴充中，伸縮規則從原有的伸縮規則擴充為：簡單伸縮規則和目标追蹤伸縮規則。其中，簡單伸縮規則對應于原伸縮規則定義（本文中提到的簡單伸縮規則均指原伸縮規則定義的擴充方式）；目标追蹤伸縮規則為全新類型的伸縮規則。

背景分析

彈性伸縮服務目前基于簡單伸縮規則與雲監控服務，為使用者提供了伸縮組動态調整的能力，即，使用者通過雲監控服務監控特定名額值，當滿足門檻值條件時，則觸發指定的伸縮規則。基于簡單伸縮規則的動态調整政策為使用者帶來了極大的靈活性，同時節約了大量成本，使使用者真真實作了“按需使用”的目标。但是，該種方式下的動态調整政策仍存在以下問題：

1. 定義模糊。對于大多數使用彈性伸縮動态調整政策的使用者來說，關心的核心問題在于是否達到目标監控名額期望值，而基于簡單伸縮規則的動态調整政策則将動态調整政策的定義抛給了使用者。
2. 調整粒度固定。簡單伸縮規則定義了具體的擴縮容動作，其定義不感覺監控名額的實際狀态，是以使用者隻能夠根據經驗來設定一個固定的伸縮規則，其調整過程粒度無法實作動态調整。對于擴縮容過程，這意味着擴縮容過程的精度和效率無法協調。
3. 調整過程缺乏控制。基于簡單報警規則的動态調整政策，僅僅是将如何調整和何時調整這兩個定義簡單組合起來，缺乏有效的控制手段。下面簡單介紹兩種主要的問題：
   1. 資料抖動。對于新加入伸縮組的執行個體，其監控資料在短時間内是不可獲得或不準确的，是以，執行個體的加入，将使得整體的監控資料發生較大的抖動，新加入的執行個體占比越大，這種抖動帶來的影響也越大。在該階段，将可能導緻報警事件的觸發不符合實際需要。
   2. 連續回調。由于執行個體數變化帶來的監控名額變化通常不是同步的，當執行個體個數已經發生變化，但監控名額還未相應變化時，仍可能觸發報警事件，此時将再次觸發伸縮規則，導緻響應了延遲資料觸發的擴縮容。
4. 震蕩問題。當使用者期望将監控名額值維持在某區間時，通常是針對同一名額值設定一條擴容規則和一條縮容規則，不合理的設定将可能導緻伸縮組執行個體個數來回震蕩。

目标追蹤伸縮規則與雲監控進行深度結合，重新定義了伸縮組動态調整過程。具體表現在以下幾點：

1. 将如何擴容和何時擴容兩者定義整合到一起，将使用者關心的監控名額值暴露給使用者，使用者隻需要關注監控名額的目标值。
2. 快速、精準、動态的擴縮容。目标追蹤伸縮規則增加了對監控資料的感覺能力，根據曆史的監控資料值和期望目标值計算出所需要的擴縮容執行個體數，使用盡量少的調整過程趨近監控名額目标值。
3. 執行個體預熱。新執行個體加入伸縮組後，将首先進入執行個體預熱階段，在該階段，不會向雲監控上報其監控資料，也不作為擴縮容過程的基數執行個體。預熱階段能夠有效防止增加過多的執行個體。
4. 動态穩定區間。根據伸縮組的曆史監控資料計算目标值穩定的區間。

支援的監控項

在使用目标追蹤伸縮規則時，對可選的監控名額有一定限制，名額需要能夠正确反映伸縮組内機器整體的繁忙程度，并且名額值需要滿足根據伸縮組内執行個體數量的變化而相應的增加或減少，滿足上述條件的監控名額适合應用于目标追蹤伸縮規則。例如：cpu平均使用率名額能夠有效的反映執行個體的繁忙程度，并且與執行個體的數量變化具有明顯的線性關系；相反，cpu平均負載則不能準确的反映執行個體的繁忙程度，當機器上存在大量io等待時，可能出現高負載低使用率的情況，這種情況下，通常不是機器過于繁忙，而應該考慮能否優化應用結構。

目前目标追蹤伸縮規則支援的監控名額如下：

名額名稱	名額描述
CpuUtilization	cpu使用率
ClassicInternetRx	經典網絡公網入流量
ClassicInternetTx	經典網絡公網出流量
VpcInternetRx	vpc網絡公網入流量
VpcInternetTx	vpc網絡公網出流量
IntranetRx	内網入流量
IntranetTx	内網出流量

注意事項

• 目标追蹤規則假設在名額值高于目标值時進行擴充操作，不支援在名額低于目标值時進行擴充操作。
• 目标追蹤規則将為您建立2條雲監控報警規則，分别用于擴容過程和縮容過程，我們采用了相對激進的擴容政策和相對保守的縮容政策。伸縮組擴容報警規則采樣間隔為60s，連續3分鐘滿足門檻值條件則進行擴容，縮容報警規則采樣間隔為60s，連續15分鐘滿足門檻值條件則進行縮容。
• 當計算得到的調整執行個體個數為小數時，對于擴容過程，采取向上取整；對于縮容過程，采取向下取整。例如，當需要增加執行個體個數為1.5時，實際将增加2個執行個體；當需要縮容的執行個體個數為-1.5時，實際将減少1個執行個體。
• 當監控資料名額不足時，将不會觸發擴/縮容操作。
• 當報警規則發生報警時，将觸發對應的擴縮容操作，彈性伸縮将根據監控名額的曆史資料計算擴縮容過程的執行個體個數。對于擴容過程，計算所得的擴容數量采取向上取整，避免擴容的機器不足；對于縮容過程，計算所得的擴容數量采取向下取整，避免釋放過多的執行個體數量。
• 監控名額值可能與目标值存在較大的差距，這種情況通常發生在組内執行個體個數較少的情況下，此時，組内執行個體數量的變化，對伸縮組聚合名額值具有較大的影響。例如，您可能會遇到作用于縮容過程的報警規則一直處于報警狀态，卻沒有縮容活動發生的情況。這種情況主要是由于縮容過程計算得到的縮容執行個體數量少于一個，是以不會産生實際的伸縮活動。
• 請勿編輯或删除為目标追蹤伸縮規則建立的報警規則。任何修改都将導緻拒絕執行對應的擴/縮容活動，當您删除伸縮規則時，相應的報警規則會自動删除。

禁用縮容

目标追蹤伸縮規則支援禁用縮容，通過指定disableScaleIn參數為true，便可禁用縮容過程，禁用縮容操作将不會建立或者删除作用于縮容過程的報警規則。通過該功能，您可以使用其他方式控制伸縮組的縮容過程，例如，您可以通過報警規則監控其他名額，觸發一條簡單的伸縮規則用于縮容。

執行個體預熱

新的執行個體加入伸縮組之後，通常需要經曆業務部署，slb健康檢查，資料采集等過程，才能上報穩定的監控資料，不适合在此基礎上觸發新的伸縮活動。為了限制擴/縮容過程執行的頻率，我們通常建議對伸縮規則設定合适的冷卻時間，在冷卻期内，将拒絕執行伸縮規則。對于目标追蹤伸縮規則，我們引入了全新的執行個體預熱過程，下面我們将詳細介紹執行個體預熱過程。

注意：隻有目标追蹤規則與步進規則建立出來的執行個體才擁有執行個體預熱階段。

執行個體在預熱階段時具有以下行為：

1. 執行個體将正常加入伸縮組，但是執行個體不會開始向雲監控上報資料，雲監控在聚合伸縮組次元監控名額時忽略預熱執行個體，不将預熱執行個體作為伸縮組内執行個體。
2. 執行個體預熱結束後，将開始向雲監控上報資料，雲監控此時将其作為伸縮組内執行個體。
3. 擴容過程中，預熱執行個體不會做為擴容基數。例如，目前組内執行個體數量為c,伸縮組觸發擴容活動，添加5個執行個體到伸縮組，預熱時間設定為300s，在執行個體預熱期間，再次觸發擴容活動，仍按照數量c作為擴容基數。假設本次需要擴容的執行個體數量為6，那麼實際上隻需要再生産的執行個體數量為1，使得預熱執行個體數達到6個。這可確定添加的執行個體不會超出您的需要。
4. 縮容過程中，對于縮容過程，将自動根據曆史執行情況，設定合适的冷卻時間，方式由于資料延遲引發的連續縮容事件導緻執行個體過多釋放。

我們建議您根據實際的業務需要設定合适的執行個體預熱時間，這可幫助目标追蹤伸縮政策更高效，更準确的接近您所設定的目标值。

最佳實踐

使用SDK建立目标追蹤伸縮規則

這裡我們主要展示如何使用java SDK建立伸縮規則，并采用maven進行依賴管理。建立目标追蹤伸縮規則，需要使用aliyun-java-sdk-ess 2.2.9及以上版本。

程式所需的maven依賴如下：

<dependency>
            <groupId>com.aliyun</groupId>
            <artifactId>aliyun-java-sdk-core</artifactId>
            <version>3.0.8</version>
        </dependency>
        <dependency>
            <groupId>com.aliyun</groupId>
            <artifactId>aliyun-java-sdk-ess</artifactId>
            <version>2.3.1-SNAPSHOT</version>
        </dependency>           

建立目标追蹤伸縮規則

CreateScalingRuleRequest request = new CreateScalingRuleRequest();
        request.setScalingGroupId(scalingGroupId);
        request.setScalingRuleType("TargetTrackingScalingRule");
        request.setTargetValue(targetValue);
        request.setMetricName(metricName);
        request.setDisableScaleIn(disableScaleIn);
        request.setEstimatedInstanceWarmup(estimateWarmupTime);
        CreateScalingRuleResponse response = client.getAcsResponse(request);           

控制台操作介紹

請參考

Auto Scaling 支援目标追蹤伸縮規則

。