本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Application Auto Scaling 的目標追蹤擴展如何運作
本主題說明目標追蹤擴展的運作方式，並介紹目標追蹤擴展政策的關鍵元素。
**Topics**
+ [運作方式](#target-tracking-how-it-works)
+ [選擇 Metrics (指標)](#target-tracking-choose-metrics)
+ [定義目標值](#target-tracking-define-target-value)
+ [定義冷卻時間](#target-tracking-cooldown)
+ [考量事項](#target-tracking-considerations)
+ [多個擴展政策](#target-tracking-multiple-scaling-policies)
+ [常用命令](#target-tracking-policy-commonly-used-commands)
+ [相關資源](#target-tracking-related-resources)
+ [限制](#target-tracking-limitations)
## 運作方式
若要使用目標追蹤擴展，您可以建立目標追蹤擴展政策並指定下列項目：
+ **指標**：要追蹤的 CloudWatch 指標，例如平均 CPU 使用率或單一目標平均請求數。
+ **目標值**：指標的目標值，例如 50% CPU 使用率或每分鐘每個目標 1000 個請求。
Application Auto Scaling 會建立和管理可觸發擴展政策的 CloudWatch 警示，並根據指標和目標值來計算擴展調整內容。該功能會視需求新增及移除容量，讓指標保持在等於或接近指定目標值的狀態。
指標高於目標值時，Application Auto Scaling 會擴增規模，亦即增加容量，以減少指標值與目標值之間的差距；當指標低於目標值時，Application Auto Scaling 則會移除容量，縮減規模。
擴展活動之間會有冷卻時間，以防止容量快速波動。您可自行選擇是否設定擴展政策的冷卻時間。
下圖顯示設置完成後目標追蹤擴展政策的運作方式總覽。
請注意，相較於在使用率減少時移除容量，目標追蹤擴展政策會在使用率增加時更積極地新增容量。例如，如果政策的指定指標達到目標值，政策會假設應用程式已經滿載。因此，它採取的回應方式為根據指標值的比例盡快新增容量。指標越高，新增的容量越多。
當指標低於目標值時，如果政策計算出移除最小容量單位可能會使指標回到高於目標值，則不會縮減。在此情況中，只有在使用率突破閾值遠低於目標值 (通常低於 10%)，而確定使用率減緩時，才會移除容量，擴展速度會變慢。這種較為保守的行為的目的是，確保只有在應用程式不再遇到與之前同樣大量的需求時，才會移除容量。
## 選擇 Metrics (指標)
您可以使用預先定義的指標或自訂指標建立目標追蹤擴展政策。
在使用預先定義的指標類型建立目標追蹤擴展政策時，您從 [目標追蹤擴展政策的預先定義指標](monitoring-cloudwatch.md#predefined-metrics) 中的預先定義指標清單選擇一個指標。
選擇指標時請謹記以下事項：
+ 並非所有的自訂指標都適用於目標追蹤。指標必須是有效的使用率指標，而且能夠表示可擴展性目標的忙碌程度。指標值必須根據可擴展性目標的容量按比例增加或減少，以使指標資料可用於按比例擴展可擴展性目標。
+ 若要使用 `ALBRequestCountPerTarget` 指標，您必須指定 `ResourceLabel` 參數來識別與指標相關聯的目標群組。
+ 當指標向 CloudWatch 真的發出 0 值時 (例如 `ALBRequestCountPerTarget`)，如果應用程式持續一段時間沒有流量，Application Auto Scaling 可能縮減到 0。為了讓可擴展的目標在沒有收到請求時縮減到 0，可擴展目標的容量下限必須設定為 0。
+ 您可以使用指標數學來合併現有的指標，而不是發布新的指標來用於您的擴展政策。如需詳細資訊，請參閱[使用指標數學運算建立 Application Auto Scaling 的目標追蹤擴展政策](application-auto-scaling-target-tracking-metric-math.md)。
+ 若要查看使用的服務是否支援在服務主控台中指定自訂指標，請參閱該服務的文件。
+ 建議您使用可以一分鐘間隔提供的指標，從而幫助您更快速地擴展以回應利用率變更。目標追蹤會針對所有預先定義的指標和自訂指標，評估以一分鐘精細度彙總的指標，但基礎指標可能會以較低頻率發佈資料。例如，依預設，所有 Amazon EC2 指標都會以五分鐘的間隔傳送，但可設定為一分鐘 (稱為詳細監控)。此選擇取決於個別服務。大多數人會嘗試使用盡可能小的間隔。
## 定義目標值
建立目標追蹤擴展政策時，您必須指定目標值。目標值代表應用程式的最佳平均使用率或輸送量。若要以符合成本效益的方式使用資源，請盡可能高地設定目標值，並為非預期的流量增加提供合理的緩衝區。如果您的應用程式已經針對一般流量進行最佳化橫向擴展，實際指標值應等於或低於目標值。
擴展政策以輸送量為基礎時 (例如 Application Load Balancer 每個目標的要求計數、網路 I/O 或其他計數指標)，目標值代表一分鐘期間單一實體的最佳平均輸送量 (例如 Application Load Balancer 目標群組的單一目標)。
## 定義冷卻時間
您可以選擇在目標追蹤擴展政策中定義冷卻時間。
冷卻時間指定擴展政策等候上一個擴展活動生效的時間量。
冷卻時間有兩種類型：
+ *向外擴展冷卻期間*的目的是連續的規模擴展 (但並非過度)。在 Application Auto Scaling 使用擴展政策成功擴展之後，就會開始計算冷卻時間。除非觸發較大的橫向擴展或冷卻時間結束，否則擴展規模政策不會再次增加所需的容量。在向外擴展冷卻期間有效時，由起始冷卻的向外擴展活動所增加的容量，將計入下次向外擴展活動所需的容量。
+ *縮減冷卻時間*的用意在於保守縮減以保護應用程式的可用性，所以縮減冷卻期過後才會開放縮減活動。不過，若在向內擴展冷卻期間另有警示觸發了向外擴展活動，Application Auto Scaling 則會立即向外擴展目標。在這種情況下，縮減冷卻時間隨即停止，且不會完成。
每個冷卻期間都是以秒為單位進行測量，且僅適用於擴展政策相關擴展活動。在冷卻期間，當已排定的動作在已排定的時間開始時，它可以立即觸發擴展活動，而無須等候冷卻期間過期。
您可以從預設值開始，之後再進行微調。例如，您可能需要增加冷卻期間，以防止目標追蹤擴展政策對短時間內發生的變更過於積極。
**預設值**
Application Auto Scaling 為 ElastiCache 提供預設值 600，並為下列可擴展目標提供預設值 300：
+ WorkSpaces 應用程式機群
+ Aurora 資料庫叢集
+ ECS 服務
+ Neptune 叢集
+ SageMaker AI 端點變體
+ SageMaker AI 推論元件
+ SageMaker AI Serverless 佈建並行
+ Spot Fleets
+ WorkSpaces 集區
+ 自訂資源
對於所有其他可擴展目標，預設值為 0 或 null：
+ Amazon Comprehend 文件分類和實體識別器端點
+ DynamoDB 資料表和全域次要索引
+ Amazon Keyspaces 資料表
+ Lambda 佈建並行
+ Amazon MSK 代理程式儲存
當 Application Auto Scaling 評估冷卻時間時，Null 值會被視為與零值相同。
您可以更新任何預設值，包括 null 值，以設定自己的冷卻時間。
## 考量事項
使用目標追蹤擴展政策時，下列考量適用：
+ 請勿編輯或刪除用於目標追蹤擴展政策的 CloudWatch 警示。Application Auto Scaling 可建立和管理與目標追蹤擴展政策關聯的 CloudWatch 警示，並會在不再需要時刪除它們。
+ 如果指標缺少資料點，這會導致 CloudWatch 警示狀態變更為 `INSUFFICIENT_DATA`。發生這種情況時，Application Auto Scaling 無法擴展您的可擴展目標，直到找到新的資料點為止。如需詳細資訊，請參閱「Amazon CloudWatch 使用者指南」**中的[設定 CloudWatch 警示如何處理遺失資料](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)。
+ 如果指標在設計上是以稀疏的方式來報告，指標數學可能會有所幫助。例如，若要使用最新的值，請使用指標為 `m1` 的 `FILL(m1,REPEAT)` 函數。
+ 您可能會看到目標值與實際指標資料點之間有些差距。原因是 Application Auto Scaling 在決定新增或移除多少容量時，一律以四捨五入來保守處理。這樣可防止新增不足的容量，或移除過多的容量。不過，對於具有小容量的可擴展性目標，實際指標資料點可能會遠於目標值。
例如，假設您為 CPU 使用率設定了 50% 的目標值，然後 Auto Scaling 群組就會超過目標。我們可能會判斷新增 1.5 執行個體使 CPU 使用率降低接近 50%。由於不可能新增 1.5 執行個體，我們四捨五入而新增兩個執行個體。這可能會降低 CPU 使用率低於 50%，但可確保有足夠的資源來支援您的應用程式。同樣地，如果我們判斷移除 0.5 個執行個體會將您的 CPU 使用率提高到 50% 以上，我們將選擇不縮減，直到指標降低到我們認為縮減不會造成振盪的程度為止。
對於具有較大容量的可擴展性目標，新增或移除容量促使目標值與實際指標資料點之間的差距變少。
+ 目標追蹤擴展政策假設在指定的指標超過目標值時，應執行向外擴展。您無法使用目標追蹤擴展政策在指定的指標低於目標值時執行向外擴展。
## 多個擴展政策
任一個可擴展性目標均能有多個目標追蹤擴展政策，但前提是各政策使用不同的指標。Application Auto Scaling 的用意一律以可用性為優先，因此其行為視目標追蹤政策是準備水平擴展或縮減而有所不同。如果任何目標追蹤政策已準備好擴展，此服務就會擴展可擴展目標，但只有在所有目標追蹤政策 (已啟用縮減部分) 已準備好縮減，才會進行縮減。
如果多個擴展政策同一時間指示可擴展的目標橫向擴展或縮減，Application Auto Scaling 會根據縮減和橫向擴展都可達最大容量的政策來擴展。如此能夠更靈活地涵蓋多種情況，確保始終有足夠的容量可處理您的工作負載。
您可以停用目標追蹤擴展政策的縮減部分，以對縮減和橫向擴展使用不同的方法。例如，您可以使用步進擴展政策進行向內擴展，同時使用目標追蹤擴展政策向外擴展。
不過，我們建議您小心使用目標追蹤擴展政策與步進擴展政策，因為這些政策之間的衝突可能會造成非預期行為。例如，如果步進擴展政策在目標追蹤政策準備好縮減之前即啟動縮減活動，則不會封鎖縮減活動。向內擴展活動完成之後，目標追蹤政策可以指示可擴展的目標再次向外擴展。
對於本質上是循環的工作負載，您也可以選擇使用已排定的擴展在排程上自動執行容量變更。對於每個已排定的動作，可以定義新的容量下限值和新的容量上限值。這些值形成擴展政策的界限。透過結合已排定的擴展和目標追蹤擴展，可協助在立即需要容量時，降低使用率急遽增加的影響。
## 建立、管理及刪除擴展政策常用的命令
擴展政策常用的命令包括：
+ [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) 將 AWS 或自訂資源註冊為可擴展的目標 (Application Auto Scaling 可以擴展的資源），以及暫停和繼續擴展。
+ [put-calable-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)，新增或修改現有可擴展目標的擴展政策。
+ [describe-scaling-activities](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/describe-scaling-activities.html) 傳回 AWS 區域中擴展活動的相關資訊。
+ [describe-scaling-policies](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/describe-scaling-policies.html)，傳回 AWS 區域的擴展政策相關資訊。
+ [delete-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scaling-policy.html)，刪除擴展政策。
## 相關資源
如需取得有關建立 Amazon EC2 Auto Scaling 的目標追蹤擴展政策之資訊，請參閱《*Amazon EC2 Auto Scaling 使用者指南*》中的「[Amazon EC2 Auto Scaling 的目標追蹤擴展政策](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html)」。
## 限制
以下是使用目標追蹤擴展政策時的限制：
+ 可擴展的目標不能是 Amazon EMR 叢集。Amazon EMR 不支援目標追蹤擴展政策。
+ 當 Amazon MSK 叢集是可擴展的目標時，縮減會停用且無法啟用。
+ 您無法使用 `RegisterScalableTarget`或 `PutScalingPolicy` API 操作來更新 AWS Auto Scaling 擴展計劃。
+ 主控台對可擴展資源的檢視、新增、更新或移除目標追蹤擴展政策的存取，視您所使用的資源而定。如需詳細資訊，請參閱[AWS 服務 可與 Application Auto Scaling 搭配使用](integrated-services-list.md)。