本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Amazon EC2 Auto Scaling 的目標追蹤擴展政策
目標追蹤擴展政策會根據目標指標值自動擴展 Auto Scaling 群組的容量。它會自動適應個別應用程式的獨特使用模式。這可讓您的應用程式維持 EC2 執行個體的最佳效能和高使用率，以提高成本效益，而無需手動介入。
如果使用目標追蹤，您必須選取指標和目標值，以代表應用程式理想的平均使用率或輸送量。Amazon EC2 Auto Scaling 會建立和管理 CloudWatch 警示，在指標偏離目標時調用擴展事件。例如，這類似於調溫器如何維持目標溫度。
例如，假設您目前有一個應用程式在兩個執行個體上執行，而且您希望當應用程式的負載變更時，Auto Scaling 群組的 CPU 使用率保持在 50% 左右。這樣可以給予您額外的容量處理流量尖峰，而不會維持過多的閒置資源數。
您可以透過建立以 50% 的平均 CPU 利用率為目標的目標追蹤擴展政策來滿足此需求。然後，當 CPU 超過 50% 來處理增加的負載時，Auto Scaling 群組將橫向擴展或增加容量。當 CPU 低於 50% 時，它會縮減或減少容量，以在低使用率期間最佳化成本。
**Topics**
+ [多個目標追蹤擴展政策](#target-tracking-multiple-policies)
+ [選擇 Metrics (指標)](#target-tracking-choose-metrics)
+ [定義目標值](#target-tracking-define-target-value)
+ [定義執行個體暖機時間](#as-target-tracking-scaling-warmup)
+ [考量事項](#target-tracking-considerations)
+ [建立目標追蹤擴展政策](policy_creating.md)
+ [使用高解析度指標建立目標追蹤政策，以加快回應速度](policy-creating-high-resolution-metrics.md)
+ [使用指標數學建立目標追蹤擴展政策](ec2-auto-scaling-target-tracking-metric-math.md)
## 多個目標追蹤擴展政策
為協助最佳化擴展效能，您可使用多個目標追蹤擴展政策，但前提是各政策使用不同的指標。例如，使用率和輸送量可能會相互影響。每當這些指標之一發生變化時，通常意味著其他指標也會受到影響。因此，使用多個指標可提供有關 Auto Scaling 群組所承受負載的其他資訊。這有助於 Amazon EC2 Auto Scaling 在判斷要新增至群組的容量時，做出更明智的決策。
Amazon EC2 Auto Scaling 的目的是一律優先考慮可用性。如果任何目標追蹤政策已準備好向外擴展，則會向外擴展 Auto Scaling 群組。只有在所有目標追蹤政策 （啟用縮減部分） 都準備好縮減時，才會縮減。
## 選擇 Metrics (指標)
您可以使用預先定義的指標或自訂指標建立目標追蹤擴展政策。預先定義的指標可讓您更輕鬆地存取最常用於擴展的指標。自訂指標可讓您擴展其他可用的 CloudWatch 指標，包括[以更精細的間隔按幾秒鐘的順序發佈的高解析度指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Resolution_definition)。您可以發佈自己的高解析度指標或其他 服務發佈的 AWS 指標。
如需使用高解析度指標建立目標追蹤政策的詳細資訊，請參閱 [使用高解析度指標建立目標追蹤政策，以加快回應速度](policy-creating-high-resolution-metrics.md)。
目標追蹤支援下列預先定義的指標：
+ `ASGAverageCPUUtilization`：Auto Scaling 群組的 CPU 平均使用率。
+ `ASGAverageNetworkIn`：Auto Scaling 群組在所有網路介面上收到的平均位元組數量。
+ `ASGAverageNetworkOut`：Auto Scaling 群組在所有網路介面上傳送出去的平均位元組數量。
+ `ALBRequestCountPerTarget` — Auto Scaling 群組每個目標的平均 Application Load Balancer 請求計數。
**重要**
有關每個目標的 CPU 使用率、網路 I/O 和 Application Load Balancer 請求計數指標的其他寶貴資訊，請參閱《*Amazon EC2 使用者指南*》中的[列出執行個體主題的可用 CloudWatch 指標](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html)，以及《Application [ Application Load Balancer 使用者指南》中的 Application Load Balancer 主題的 CloudWatch 指標](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)。 **
您可以在 CloudWatch 中透過指定自訂指標，選擇其他可用的 CloudWatch 指標或自己的指標。如需使用 為目標追蹤擴展政策指定自訂指標規格的範例 AWS CLI，請參閱 [的範例擴展政策 AWS CLI](examples-scaling-policies.md)。
選擇指標時請謹記以下事項：
+ 我們建議您只使用一分鐘或更低間隔可用的指標，以協助您更快地擴展以回應使用率變更。以較低間隔發佈的指標可讓目標追蹤政策更快地偵測和回應 Auto Scaling 群組使用率的變化。
+ 如果您選擇 Amazon EC2 發佈的預先定義指標，例如 CPU 使用率，建議您啟用詳細監控。根據預設，所有 Amazon EC2 指標會以五分鐘的間隔發佈，但可透過啟用詳細監控，將其設定為較低的一分鐘間隔。如需如何啟用詳細監控的資訊，請參閱 [設定 Auto Scaling 執行個體的監控](enable-as-instance-metrics.md)。
+ 並非所有的自訂指標都適用於目標追蹤。指標必須是有效的使用率指標，而且能夠表示執行個體的忙碌程度。指標值必須與 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 為基礎的擴展政策](as-using-sqs-queue.md)。
+ 若要使用 `ALBRequestCountPerTarget` 指標，您必須指定 `ResourceLabel` 參數來識別與指標相關聯的負載平衡器目標群組。如需使用 指定目標追蹤擴展政策`ResourceLabel`參數的範例 AWS CLI，請參閱 [的範例擴展政策 AWS CLI](examples-scaling-policies.md)。
+ 當指標向 CloudWatch 真的發出 0 值時 (例如 `ALBRequestCountPerTarget`)，如果應用程式持續一段時間沒有流量，Auto Scaling 群組可能縮減到 0。若要讓 Auto Scaling 群組在沒有請求傳送到它時縮減為 0，該群組的容量下限必須設定為 0。
+ 您可以使用指標數學來合併現有的指標，而不是發布新的指標來用於您的擴展政策。如需詳細資訊，請參閱[使用指標數學建立目標追蹤擴展政策](ec2-auto-scaling-target-tracking-metric-math.md)。
## 定義目標值
建立目標追蹤擴展政策時，您必須指定目標值。目標值代表 Auto Scaling 群組的最佳平均使用率或輸送量。若要以符合成本效益的方式使用資源，請盡可能高地設定目標值，並為非預期的流量增加提供合理的緩衝區。當您的應用程式進行最佳橫向擴展以達到正常流量時，實際指標值應等於或略低於目標值。
擴展政策以輸送量為基礎時 (例如 Application Load Balancer 每個目標的要求計數、網路 I/O 或其他計數指標)，目標值代表一分鐘期間單一執行個體的最佳平均輸送量。
## 定義執行個體暖機時間
您可以選擇性指定新啟動的執行個體暖機所需的秒數。在指定的暖機時間結束之前，執行個體不會計入 Auto Scaling 群組的彙總 EC2 執行個體指標。
當執行個體處於暖機期間時，只有在未暖機的執行個體指標值大於政策的目標使用率時，擴展政策才會向外擴展。
如果群組再次水平擴展，則仍在暖機的執行個體將計為下次水平擴展活動所需的容量一部分。這種做法的目的是連續的向外擴展 (但並非過度)。
當向外擴展活動正在進行時，所有由擴展政策啟動的向內擴展活動都會遭到封鎖，直到執行個體完成暖機。當執行個體完成暖機時，如果發生擴展事件，則在計算新的所需容量時，目前正在終止的任何執行個體都會計入群組的目前容量。所以，我們不會從 Auto Scaling 群組移除超過必要數量的執行個體。
**預設值**
如果未設定任何值，擴展政策將使用預設值，這是為群組定義之[預設執行個體暖機](ec2-auto-scaling-default-instance-warmup.md)期的值。如果預設執行個體暖機期為 null，則會回到[預設冷卻時間](ec2-auto-scaling-scaling-cooldowns.md#set-default-cooldown)的值。我們建議您使用預設執行個體暖機期，以便在暖機期變更時更輕鬆地更新所有擴展政策。
## 考量事項
使用目標追蹤擴展政策時，下列考量適用：
+ 請勿建立、編輯或刪除用於目標追蹤擴展政策的 CloudWatch 警示。Amazon EC2 Auto Scaling 會建立和管理與您的目標追蹤擴展政策相關聯的 CloudWatch 警示，並視需要編輯、取代或刪除它們，以自訂應用程式的擴展體驗及其不斷變化的使用率模式。
+ 目標追蹤擴展政策會在流量減少時逐漸縮減，在流量水平波動期間排定可用性優先順序。如果您想要更好的控制，步驟擴展政策可能是更好的選項。您可以暫時停用目標追蹤政策的縮減部分。這有助於維持成功部署的執行個體數量下限。
+ 如果指標缺少資料點，這會導致 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%，但可確保有足夠的資源來支援您的應用程式。同樣地，如果我們判斷移除 0.5 執行個體會將您的 CPU 使用率增加到 50% 以上，我們將選擇不縮減，直到指標降低到我們認為縮減不會造成振盪的程度為止。
對於具有較多執行個體的大型 Auto Scaling 群組，使用率會分佈於較多的執行個體，在這種情況下，新增或移除執行個體所導致目標值和實際指標資料點之間的差距會比較小。
+ 目標追蹤擴展政策假設在指定的指標超過目標值時，應擴增您的 Auto Scaling 群組。當指定的指標低於目標值時，您無法使用目標追蹤擴展政策來橫向擴展 Auto Scaling 群組。