Amazon EC2 Auto Scaling 的目標追蹤擴展政策 - Amazon EC2 Auto Scaling
多個目標追蹤擴展政策選擇 Metrics (指標)定義目標值定義執行個體暖機時間考量事項

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

Amazon EC2 Auto Scaling 的目標追蹤擴展政策

目標追蹤擴展政策會根據目標指標值自動擴展 Auto Scaling 群組的容量。如此一來，您的應用程式就能維持最佳效能和成本效益，無需手動介入。

如果使用目標追蹤，您必須選取指標和目標值，以代表應用程式理想的平均使用率或輸送量。Amazon EC2 Auto Scaling 會建立和管理在指標偏離目標時叫用擴展事件的 CloudWatch 警示。例如，這類似於恆溫器維持目標溫度的方式。

例如，假設您目前有一個應用程式在兩個執行個體上執行，而且您希望當應用程式的負載變更時，Auto Scaling 群組的 CPU 使用率保持在 50% 左右。這樣可以給予您額外的容量處理流量尖峰，而不會維持過多的閒置資源數。

您可以透過建立以 50% 的平均 CPU 利用率為目標的目標追蹤擴展政策來滿足此需求。然後，當 CPU 超過 50% 以處理增加的負載時，您的「Auto Scaling」群組將向外擴充或增加容量。當 CPU 降至 50% 以下時，它會擴充或減少容量，以便在低使用率期間達到最佳化成本。

主題

多個目標追蹤擴展政策

為協助最佳化擴展效能，您可使用多個目標追蹤擴展政策，但前提是各政策使用不同的指標。例如，使用率和輸送量可能會相互影響。每當這些指標之一發生變化時，通常意味著其他指標也會受到影響。因此，使用多個量度可提供有關 Auto Scaling 群組所處負載的其他資訊。這有助於 Amazon EC2 Auto Scaling 在決定要新增至群組的容量時，做出更明智的決策。

Amazon EC2 Auto Scaling 的目的是始終優先考慮可用性。如果任何目標追蹤政策已準備好向外擴充，它將向外擴充 Auto Scaling 群組。只有在所有目標追蹤原則 (已啟用部分縮放) 都準備好擴充時，它才會擴充。

選擇 Metrics (指標)

您可以使用預先定義的指標或自訂指標建立目標追蹤擴展政策。

在使用預先定義的指標類型建立目標追蹤擴展政策時，您從如下預定義指標清單選擇一個指標：

  • ASGAverageCPUUtilization：Auto Scaling 群組的 CPU 平均使用率。

  • ASGAverageNetworkIn - 所有網路界面上單個執行個體接收到的平均位元組數。

  • ASGAverageNetworkOut - 所有網路界面上單個執行個體傳送出的平均位元組數。

  • ALBRequestCountPerTarget - 每個目標的平均 Application Load Balancer 請求計數。

重要

有關 CPU 使用率、網路 I/O 和每個目標的 Application Load Balancer 請求計數的其他有價值資訊，請參閱 Amazon EC2 使用者指南中的列出執行個體的可用指 CloudWatch 標主題，以及應用程式負載平衡器使用者指南中的「應用程式負載平衡器使用者指南」主題中的指標。CloudWatch

您可以在中指定自訂 CloudWatch 量度 CloudWatch 來選擇其他可用量度或您自己的量度。您必須使用 AWS CLI 或 SDK 來建立具有自訂度量規格的目標追蹤原則。如需使用指定目標追蹤調度調整原則之自訂度量規格的範例 AWS CLI，請參閱擴展政策的範例 AWS CLI。

選擇指標時請謹記以下事項：

  • 建議您僅使用可以一分鐘間隔提供的指標，從而幫助您更快速地擴展以回應利用率變更。目標追蹤會針對所有預先定義的指標和自訂指標，評估以一分鐘精細度彙總的指標，但基礎指標可能會以較低頻率發佈資料。例如，依預設，所有 Amazon EC2 指標都會以五分鐘的間隔傳送，但可設定為一分鐘 (稱為詳細監控)。此選擇取決於個別服務。大多數人會嘗試使用盡可能小的間隔。如需啟用詳細監視的詳細資訊，請參閱 設定 Auto Scaling 執行個體的監控。

  • 並非所有的自訂指標都適用於目標追蹤。指標必須是有效的使用率指標，而且能夠表示執行個體的忙碌程度。指標值必須與 Auto Scaling 群組中的執行個體數成比例增加或減少。如此，指標資料便可依比例依執行個體數量擴增或縮減。例如，如果 Auto Scaling 群組的負載分佈於各執行個體之間，則 Auto Scaling 群組的 CPU 使用率是有效的 (也就是具有指標維度 AutoScalingGroupName 的 Amazon EC2 指標 CPUUtilization)。

  • 以下指標不適用於目標追蹤：

    • 面對 Auto Scaling 群組的負載平衡器所收到的請求數量 (也就是 Elastic Load Balancing 指標 RequestCount)。負載平衡器收到的請求數量不會根據 Auto Scaling 群組的使用率而改變。

    • 負載平衡器請求延遲 (也就是 Elastic Load Balancing 指標 Latency)。請求延遲會隨使用率提高而增加，但不一定會依比例變動。

    • CloudWatch Amazon SQS 佇列指標ApproximateNumberOfMessagesVisible。佇列中的訊息數量可能不會隨處理佇列訊息之 Auto Scaling 群組的大小成比例地變更。然而，測量 Auto Scaling 群組中每個 EC2 執行個體佇列中訊息數量的自訂指標是可行的。如需詳細資訊，請參閱 以 Amazon SQS 為基礎的擴展政策。

  • 若要使用 ALBRequestCountPerTarget 指標，您必須指定 ResourceLabel 參數來識別與指標相關聯的負載平衡器目標群組。如需使用指定目標追蹤調度調整原則之ResourceLabel參數的範例 AWS CLI，請參閱擴展政策的範例 AWS CLI。

  • 當量度發出實際 0 值給 CloudWatch (例如，ALBRequestCountPerTarget) 時，如果應用程式在持續一段時間內沒有流量，Auto Scaling 群組就可以擴展為 0。若要讓 Auto Scaling 群組在沒有請求傳送到它時縮減為 0，該群組的容量下限必須設定為 0。

  • 您可以使用指標數學來合併現有的指標，而不是發布新的指標來用於您的擴展政策。如需詳細資訊，請參閱 使用指標數學建立目標追蹤擴展政策。

定義目標值

建立目標追蹤擴展政策時，您必須指定目標值。目標值代表 Auto Scaling 群組的最佳平均使用率或輸送量。若要以符合成本效益的方式使用資源，請盡可能高地設定目標值，並為非預期的流量增加提供合理的緩衝區。當您的應用程式進行最佳橫向擴展以達到正常流量時，實際指標值應等於或略低於目標值。

擴展政策以輸送量為基礎時 (例如 Application Load Balancer 每個目標的要求計數、網路 I/O 或其他計數指標)，目標值代表一分鐘期間單一執行個體的最佳平均輸送量。

定義執行個體暖機時間

您可以選擇性指定新啟動的執行個體暖機所需的秒數。在指定的預熱時間過期之前，執行個體不會計入 Auto Scaling 群組的彙總 EC2 執行個體指標。

雖然執行個體處於預熱期間，但只有在未預熱執行個體的指標值大於政策的目標使用率時，您的擴展政策才會向外延展。

如果群組再次水平擴展，則仍在暖機的執行個體將計為下次水平擴展活動所需的容量一部分。這種做法的目的是連續的向外擴展 (但並非過度)。

當向外延展活動正在進行中時，由擴展政策啟動的所有活動規模都會遭到封鎖，直到執行個體完成預熱為止。當執行個體完成預熱時，如果發生事件中的比例，目前正在終止程序中的任何執行個體都會在計算新的所需容量時計入群組的目前容量。所以，我們不會從 Auto Scaling 群組移除超過必要數量的執行個體。

預設值

如果未設定任何值，則資源調度政策將使用預設值，這是為群組定義的預設執行個體暖機值。如果預設執行個體預熱為 null，則會回復為預設冷卻時間的值。建議您使用預設執行個體暖機，以便在暖機時間變更時更輕鬆地更新所有擴展政策。

考量事項

使用目標追蹤擴展政策時，下列考量適用：

  • 請勿建立、編輯或刪除與目標追蹤資源調整政策搭配使用的 CloudWatch 警示。Amazon EC2 Auto Scaling 會建立和管理與目標追蹤擴展政策相關聯的 CloudWatch警示，並在不再需要時將其刪除。

  • 目標追蹤擴展政策會在流量減少時逐漸縮減，在流量水平波動期間排定可用性優先順序。如果您希望 Auto Scaling 群組在工作負載完成時立即縮減，可以停用政策的縮減部分。這可讓您靈活使用縮減方法，它能在使用率低時滿足您的需求。為了確保縮減盡快發生，我們建議不要使用簡單的擴展政策以防止增加冷卻時間。

  • 如果指標遺失資料點，這會導致 CloudWatch 警示狀態變更為INSUFFICIENT_DATA。發生這種情況時，Amazon EC2 Auto Scaling 無法擴展您的群組，直到找到新的資料點為止。

  • 如果指標在設計上是以稀疏的方式來報告，指標數學可能會有所幫助。例如，若要使用最新的值，請使用指標為 m1 的 FILL(m1,REPEAT) 函數。

  • 您可能會看到目標值和實際指標資料點之間有些差距。原因我們會在決定新增或移除多少執行個體時，透過向上或向下四捨五入保守地行動。如此一來，防止我們新增不足數量的執行個體，或移除太多的執行個體。然而，對於較小的 Auto Scaling 群組使用較少的執行個體，該群組的使用率可能與目標值相差甚遠。例如，假設您將 CPU 使用率的目標值設定為 50%，您的 Auto Scaling 群組則會超過目標。我們可能會判斷新增 1.5 執行個體使 CPU 使用率降低接近 50%。由於不可能新增 1.5 執行個體，我們四捨五入而新增兩個執行個體。這可能會降低 CPU 使用率低於 50%，但可確保有足夠的資源來支援您的應用程式。同樣地，如果我們判斷移除 1.5 個執行個體可讓 CPU 使用率提升到 50% 以上，我們只會移除一個執行個體。

    對於具有較多執行個體的大型 Auto Scaling 群組，使用率會分佈於較多的執行個體，在這種情況下，新增或移除執行個體所導致目標值和實際指標資料點之間的差距會比較小。

  • 目標追蹤擴展政策假設在指定的指標超過目標值時，應擴增您的 Auto Scaling 群組。當指定的指標低於目標值時，您無法使用目標追蹤擴展政策來橫向擴展 Auto Scaling 群組。