預測擴展的運作方式 - Amazon EC2 Auto Scaling

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

預測擴展的運作方式

本主題說明預測性擴展如何運作,並說明建立預測性擴展政策時應考量的事項。

運作方式

若要使用預測性擴展,請建立預測性資源調整政策,以 CloudWatch 指定要監視和分析的指標。為了預測擴展開始預測 future 值,此指標必須具有至少 24 小時的資料。

建立原則之後,預測性擴展會開始分析過去 14 天的指標資料,以識別模式。它會使用此分析產生接下來 48 小時的每小時容量需求預測。預測會使用最新 CloudWatch 資料每 6 小時更新一次。隨著新數據的推出,預測性擴展能夠不斷提高 future 預測的準確性。

當您第一次啟用預測擴展時,它會在僅預測模式下執行。在此模式中,它會產生產能預測,但實際上並不會根據這些預測調整您的「自動調整比例」群組。這可讓您評估預測的準確性和適用性。您可以使用GetPredictiveScalingForecastAPI作業或來檢視預測資料 AWS Management Console。

檢閱預測資料並決定根據該資料開始擴展之後,請將資源調整政策切換為預測和縮放模式。在此模式下:

  • 如果預測預期負載會增加,Amazon EC2 Auto Scaling 將透過向外擴展來增加容量。

  • 如果預測預期負載會減少,則不會擴展以移除容量。如果您想要移除不再需要的容量,則必須建立動態擴展政策。

根據預設,Amazon EC2 Auto Scaling 會根據該小時的預測,在每小時開始時擴展您的自動擴展群組。您可以選擇性地使用PutScalingPolicyAPI作業中的SchedulingBufferTime屬性或中的啟動前執行個體設定來指定較早的開始時間。 AWS Management Console這會導致 Amazon EC2 Auto Scaling 在預測的需求之前啟動新執行個體,讓執行個體有時間開機並準備好處理流量。

為了支援在預測需求之前啟動新執行個體,我們強烈建議您為 Auto Scaling 群組啟用預設執行個體暖機。這指定向外擴充活動之後的一段時間,即使動態擴展政策指出容量應減少,Amazon EC2 Auto Scaling 也不會擴展。這可協助您確保新啟動的執行個體有足夠的時間開始為增加的流量提供服務,然後再考慮進行擴充作業。如需詳細資訊,請參閱設定 Auto Scaling 群組的預設執行個體暖機期

最大容量限制

Auto Scaling 群組具有最大容量設定,可限制群組可啟動的EC2執行個體數目上限。根據預設,在設定擴展政策時,它們無法將容量增加到高於其最大容量的容量。

或者,如果預測容量接近或超過 Auto Scaling 群組的最大容量,您也可以允許自動增加群組的最大容量。若要啟用此行為,請使用PutScalingPolicyAPI作業中的MaxCapacityBreachBehaviorMaxCapacityBuffer內容或中的 [最大容量行為] 設定 AWS Management Console。

警告

允許自動增加最大容量時,請小心。如果未監控和管理增加的最大容量,這可能導致啟動的執行個體數量超過預期。然後,增加的最大容量會成為 Auto Scaling 群組的新一般最大容量,直到您手動更新為止。最大容量不會自動減少到原來的最大容量。

考量事項

  • 確認預測擴展是否適合您的工作負載。如果工作負載顯示特定於星期幾或一天中時間的週期性負載模式,則工作負載非常適合預測擴展。若要檢查此項目,請在僅預測模式下設定預測擴展政策,然後參考主控台中的建議。Amazon EC2 Auto Scaling 會根據對潛在政策效能的觀察結果提供建議。在讓預測擴展主動擴展應用程式之前,請先評估預測和建議。

  • 預測擴展需要至少 24 小時的歷史資料才能開始預測。不過,如果歷史資料跨越整整兩週,那麼預測會更加有效。如果透過建立新的 Auto Scaling 群組並刪除舊群組來更新應用程式,則新的 Auto Scaling 群組需要 24 小時的歷史負載資料,之後預測擴展才能夠再次開始產生預測。您可以使用自訂指標來彙總所有新舊 Auto Scaling 群組中的指標。否則,您可能需要等待幾天才能獲得更準確的預測。

  • 選擇可準確表示應用程式完整負載的負載量度,並且是應用程式最重要的擴充層面。

  • 使用動態擴展與預測性擴展,可協助您緊密追蹤應用程式的需求曲線、在低流量期間擴展,並在流量高於預期時向外擴展。當多個擴展政策處於作用中狀態時,每個政策會獨立決定所需的容量,並將所需容量設定為其中的最大值。例如,如果在目標追蹤擴展政策中需要 10 個執行個體維持在目標使用率,且在預測擴展政策中需要 8 個執行個體維持在目標使用率,則會將群組所需容量設定為 10。如果您不熟悉動態擴展,建議您使用目標追蹤擴展政策。如需詳細資訊,請參閱Amazon EC2 自動擴展的動態擴展

  • 預測性擴展的一個核心假設是 Auto Scaling 群組是同質的,並且所有執行個體的容量都相等。如果您的群組不是這樣,則預測容量可能不準確。因此,在為混合執行個體群組建立預測性擴展政策時請務必小心,因為可以佈建容量不相等的不同類型執行個體。以下是預測容量不準確的一些範例:

    • 您的預測性擴展政策是根據CPU使用率而定,但每個 Auto Scaling 執行個體的 vCPUs 數量會因執行個體類型而有所不同。

    • 您的預測擴展政策以網路輸入或網路輸出為基礎,但每個 Auto Scaling 執行個體的網路頻寬輸送量會因執行個體類型而異。例如,M5 與 M5n 執行個體類型相似,但 M5n 執行個體類型提供的網路輸送量明顯較高。

支援地區

  • 美國東部 (維吉尼亞北部)

  • 美國東部 (俄亥俄)

  • 美國西部 (加利佛尼亞北部)

  • 美國西部 (奧勒岡)

  • 非洲 (開普敦)

  • Asia Pacific (Hong Kong)

  • 亞太區域 (雅加達)

  • 亞太區域 (孟買)

  • 亞太區域 (大阪)

  • 亞太區域 (首爾)

  • 亞太區域 (新加坡)

  • 亞太區域 (雪梨)

  • 亞太區域 (東京)

  • 加拿大 (中部)

  • 中國 (北京)

  • 中國 (寧夏)

  • 歐洲 (法蘭克福)

  • 歐洲 (愛爾蘭)

  • 歐洲 (倫敦)

  • 歐洲 (米蘭)

  • 歐洲 (巴黎)

  • 歐洲 (斯德哥爾摩)

  • Middle East (Bahrain)

  • 中東 (UAE)

  • 南美洲 (聖保羅)

  • AWS GovCloud (美國東部)

  • AWS GovCloud (美國西部)