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

# 預測擴展的運作方式
<a name="predictive-scaling-policy-overview"></a>

本主題說明預測擴展的運作方式，並說明建立預測擴展政策時應考量的事項。

**Topics**
+ [運作方式](#how-predictive-scaling-works)
+ [容量上限](#predictive-scaling-maximum-capacity-limit)
+ [考量事項](#predictive-scaling-considerations)
+ [支援的區域](#predictive-scaling-regions)

## 運作方式
<a name="how-predictive-scaling-works"></a>

若要使用預測擴展，請建立預測擴展政策，指定要監控和分析的 CloudWatch 指標。若要讓預測擴展開始預測未來值，此指標必須至少有 24 小時的資料。

建立政策後，預測性擴展會開始分析過去最多 14 天內的指標資料，以識別模式。它使用此分析來產生未來 48 小時容量需求的每小時預測。預測會使用最新的 CloudWatch 資料，每 6 小時更新一次。隨著新資料傳入，預測擴展能夠持續改善未來預測的準確性。

當您首次啟用預測性擴展時，它會以*僅預測*模式執行。在此模式中，它會產生容量預測，但不會根據這些預測實際擴展 Auto Scaling 群組。這可讓您評估預測的準確性和適用性。您可以使用 `GetPredictiveScalingForecast` API 操作或 檢視預測資料 AWS 管理主控台。

在您檢閱預測資料並決定根據該資料開始擴展之後，請將擴展政策切換至*預測和擴展*模式。在此模式中：
+ 如果預測預期負載增加，Amazon EC2 Auto Scaling 將透過向外擴展來增加容量。
+ 如果預測預期負載減少，則不會縮減以移除容量。如果您想要移除不再需要的容量，您必須建立動態擴展政策。

根據預設，Amazon EC2 Auto Scaling 會根據該小時的預測，在每個小時開始時擴展 Auto Scaling 群組。您可以選擇使用 `PutScalingPolicy` API 操作中的 `SchedulingBufferTime` 屬性或 中的**啟動前執行個體**設定來指定較早的開始時間 AWS 管理主控台。這會導致 Amazon EC2 Auto Scaling 在預測需求之前啟動新的執行個體，讓他們有時間開機並準備好處理流量。

為了支援在預測需求之前啟動新的執行個體，強烈建議您為 Auto Scaling 群組啟用*預設執行個體暖機*期。這會指定橫向擴展活動之後的時段，在此期間 Amazon EC2 Auto Scaling 不會縱向擴展，即使動態擴展政策指出應減少容量。這可協助您確保新啟動的執行個體有足夠的時間開始為增加的流量提供服務，然後再考慮縮減操作。如需詳細資訊，請參閱[設定 Auto Scaling 群組的預設執行個體暖機期](ec2-auto-scaling-default-instance-warmup.md)。

## 容量上限
<a name="predictive-scaling-maximum-capacity-limit"></a>

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

或者，您可以允許在預測容量接近或超過 Auto Scaling 群組的最大容量時，自動增加群組的最大容量。若要啟用此行為，請使用 `PutScalingPolicy` API 操作中的 `MaxCapacityBreachBehavior`和 `MaxCapacityBuffer` 屬性，或 中的**最大容量行為**設定 AWS 管理主控台。

**警告**  
允許自動增加最大容量時請小心。如果未監控和管理增加的最大容量，這可能會導致啟動比預期更多的執行個體。增加的最大容量會成為 Auto Scaling 群組的新正常最大容量，直到您手動更新為止。最大容量不會自動減少回原始最大容量。

## 考量事項
<a name="predictive-scaling-considerations"></a>
+ 確認預測擴展是否適合您的工作負載。如果工作負載顯示特定於星期幾或一天中時間的週期性負載模式，則工作負載非常適合預測擴展。若要檢查此項目，請在*僅預測*模式下設定預測擴展政策，然後參考主控台中的建議。Amazon EC2 Auto Scaling 會根據潛在政策效能的觀察提供建議。在讓預測擴展主動擴展應用程式之前，請先評估預測和建議。
+ 預測擴展需要至少 24 小時的歷史資料才能開始預測。不過，如果歷史資料跨越整整兩週，那麼預測會更加有效。如果透過建立新的 Auto Scaling 群組並刪除舊群組來更新應用程式，則新的 Auto Scaling 群組需要 24 小時的歷史負載資料，之後預測擴展才能夠再次開始產生預測。您可以使用自訂指標來彙總所有新舊 Auto Scaling 群組中的指標。否則，您可能需要等待幾天才能獲得更準確的預測。
+ 選擇能準確代表應用程式完整負載，且是應用程式最重要擴展方面的負載指標。
+ 使用動態擴展搭配預測擴展可協助您密切遵循應用程式的需求曲線、在低流量期間縮減規模，以及在流量高於預期時擴展規模。當多個擴展政策處於作用中狀態時，每個政策會獨立決定所需的容量，並將所需容量設定為其中的最大值。例如，如果在目標追蹤擴展政策中需要 10 個執行個體維持在目標使用率，且在預測擴展政策中需要 8 個執行個體維持在目標使用率，則會將群組所需容量設定為 10。如果您是初次使用動態擴展，我們建議您使用目標追蹤擴展政策。如需詳細資訊，請參閱[Amazon EC2 Auto Scaling 動態擴展](as-scale-based-on-demand.md)。
+ 預測性擴展的一個核心假設是 Auto Scaling 群組是同質的，並且所有執行個體的容量都相等。如果您的群組不是這樣，則預測容量可能不準確。因此，為[混合執行個體群組](ec2-auto-scaling-mixed-instances-groups.md)建立預測擴展政策時請小心，因為可以佈建容量不相等的不同類型執行個體。以下是預測容量不準確的一些範例：
  + 您的預測擴展政策以 CPU 使用率為基礎，但每個 Auto Scaling 執行個體上的 vCPU 數量會因執行個體類型而異。
  + 您的預測擴展政策以網路輸入或網路輸出為基礎，但每個 Auto Scaling 執行個體的網路頻寬輸送量會因執行個體類型而異。例如，M5 與 M5n 執行個體類型相似，但 M5n 執行個體類型提供的網路輸送量明顯較高。

## 支援的區域
<a name="predictive-scaling-regions"></a>
+ 美國東部 (維吉尼亞北部)
+ 美國東部 (俄亥俄)
+ 美國西部 (加利佛尼亞北部)
+ 美國西部 (奧勒岡)
+ 非洲 (開普敦)
+ 亞太地區 (香港)
+ 亞太區域 (海德拉巴)
+ 亞太地區 (雅加達)
+ 亞太地區 (墨爾本)
+ 亞太地區 (孟買)
+ 亞太區域 (大阪)
+ 亞太區域 (首爾)
+ 亞太區域 (新加坡)
+ 亞太地區 (雪梨)
+ 亞太區域 (東京)
+ 加拿大 (中部)
+ 加拿大西部 (卡加利)
+ 中國 (北京)
+ 中國 (寧夏)
+ 歐洲 (法蘭克福)
+ 歐洲 (愛爾蘭)
+ 歐洲 (倫敦)
+ 歐洲 (米蘭)
+ Europe (Paris)
+ 歐洲 (西班牙)
+ 歐洲 (斯德哥爾摩)
+ 歐洲 (蘇黎世)
+ 以色列 (特拉維夫)
+ Middle East (Bahrain)
+ 中東 (阿拉伯聯合大公國)
+ 南美洲 (聖保羅)
+ AWS GovCloud （美國東部）
+ AWS GovCloud （美國西部）