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

# 擴展計畫的最佳實務
<a name="best-practices-for-scaling-plans"></a>

以下最佳實務可協助您充分利用擴展計畫：
+ 當您建立啟動範本或啟動組態時，請啟用詳細監控，以一分鐘的頻率取得 EC2 執行個體的 CloudWatch 指標資料，確保對負載變更的回應更快速。五分鐘頻率的擴展指標可能會導致較慢的回應時間和用到過時的指標資料進行擴展。根據預設，EC2 執行個體啟用基本監控，這表示執行個體的指標資料以五分鐘為間隔提供。您可以啟用詳細監控，每一分鐘取得一次執行個體的指標資料，但須支付額外費用。如需詳細資訊，請參閱《Amazon EC2 Auto Scaling 使用者指南》中的[設定監控 Auto Scaling 執行個體](https://docs.aws.amazon.com/autoscaling/ec2/userguide/enable-as-instance-metrics.html)。
+ 我們也建議您啟用 Auto Scaling 群組指標。否則，在建立擴展計畫精靈完成時所顯示的容量預測圖表上，就不會顯示實際的容量資料。如需詳細資訊，請參閱《Amazon EC2 Auto Scaling 使用者指南》中的[監控 Auto Scaling 群組和執行個體的 CloudWatch 指標](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-cloudwatch-monitoring.html)。
+ 檢查 Auto Scaling 群組使用的執行個體類型，並小心使用爆量效能執行個體類型。T3 和 T2 等使用爆量效能的 Amazon EC2 執行個體，旨在提供 CPU 基準效能，並可根據工作負載的需求大幅提高效能。根據擴展計畫指定的目標使用率，您可能會面臨超出基線的風險，然後耗盡 CPU 額度並導致效能限制。如需詳細資訊，請參閱[爆量效能執行個體的 CPU 點數與基準效能](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html)。若要將這些執行個體設定為 `unlimited`，請參閱《*Amazon EC2 使用者指南*》中的[使用 Auto Scaling 群組將爆量效能執行個體啟動為無限制](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-how-to.html#burstable-performance-instances-auto-scaling-grp)。

## 其他考量
<a name="gs-considerations"></a>

**重要**  
如果您只將擴展計劃用於預測擴展，強烈建議您在 Auto Scaling 資源上直接設定預測擴展政策。此選項提供更多功能，例如使用指標彙總來建立新的自訂指標，或保留藍/綠部署的歷史指標資料。如需 Amazon EC2 Auto Scaling 的詳細資訊，請參閱《[Amazon EC2 Auto Scaling 使用者指南》中的 Amazon EC2 Auto Scaling 的預測](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html)擴展。 *Amazon EC2 Auto Scaling * 如需 Application Auto Scaling 的詳細資訊，請參閱《[Application Auto Scaling 使用者指南》中的 Application Auto Scaling 的預測](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-predictive-scaling.html)擴展。 * Auto Scaling *   
如需從擴展計劃遷移至 Amazon EC2 Auto Scaling 預測擴展政策的指南，請參閱 [遷移您的擴展計劃](migrate-scaling-plan.md)。

請謹記以下幾點考量：
+ 預測性擴展使用了負載預測來計畫未來的容量。預測的品質取決於負載的週期性和訓練預測模型的適用性。您可以在僅預測模式中執行預測擴展，來評估預測的品質以及預測建立的擴展動作。建立的擴展計畫時，您可以將預測性擴展模式設定為**僅預測**，然後在完成預測品質的評估時，將其變更為**預測與擴展**。如需更多詳細資訊，請參閱 [預測擴展設定](gs-specify-custom-settings.md#gs-customize-predictive-scaling) 及 [監控與評估預測](gs-create-scaling-plan.md#gs-monitoring-forecasts)。
+ 如果您選擇為預測擴展指定不同的指標，您必須確保擴展指標和負載指標有強烈關聯。指標值必須與 Auto Scaling 群組中的執行個體數目成比例增加和減少。此可確保指標資料可按比例依執行個體數量向外或向內擴展。例如，負載指標是請求計數的總量，而擴展指標是平均 CPU 使用率。如果請求總數增加 50%，那麼只要容量保持不變，平均 CPU 使用率也應增加 50%。
+ 在建立擴展計畫之前，您應該透過存取從中建立的主控台來刪除任何先前排程的擴展動作。 AWS Auto Scaling 不會建立與現有排程擴展動作重疊的預測擴展動作。
+ 您最低和最大容量的自訂設定，以及用於動態擴展的其他設定將顯示在其他主控台中。但是，我們建議您在建立擴展計畫後，不要從其他主控台修改這些設定，因為您的擴展計畫並不會收到來自其它主控台的更新。
+ 您的擴展計畫可以包含來自多個服務的資源，但每個資源一次只能在一個擴展計畫中。

## 避免 ActiveWithProblems 錯誤
<a name="gs-activewithproblems"></a>

建立擴展計畫或資源加入至擴展計畫時，可能會發生「ActiveWithProblems」錯誤。此錯誤會發生在擴展計畫為作用中，但有一或多個資源的擴展組態無法套用。

通常情況下，發生的原因是資源已有擴展政策，或 Auto Scaling 群組不符合預測性擴展的最低需求。

如果您的任何資源已有來自各種不同服務主控台的擴展政策，則預設 AWS Auto Scaling 不會覆寫這些其他擴展政策或建立新的擴展政策。您可以選擇刪除現有的擴展政策，並將其取代為從 AWS Auto Scaling 主控台建立的目標追蹤擴展政策。您可以藉由啟用 **Replace external scaling policies (取代外部擴展政策)** 設定來覆寫具有擴展政策的每個資源。

使用預測擴展時，我們建議在建立新 Auto Scaling 群組後，等待 24 小時再設定預測性擴展。至少必須有 24 小時的歷史資料才能產生初始預測。如果群組有少於 24 小時的歷史資料，且已啟用預測性擴展，擴展計畫會無法產生預測，直到群組已收集所需資料後的下一個預測時段。不過，您也可以編輯並儲存擴展計畫，以便在 24 小時的資料可用時，立即重新啟動預測處理。