本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 評估資料表的 Application Auto Scaling 設定
本節概述如何評估 Amazon Keyspaces 資料表的 Application Auto Scaling 設定。[Amazon Keyspaces Application Auto Scaling](autoscaling.md) 是一項功能，可根據您的應用程式流量和目標使用率指標來管理資料表輸送量。這可確保您的資料表具有應用程式模式所需的容量。
Application Auto Scaling 服務會監控您目前的資料表使用率，並將其與目標使用率值進行比較：`TargetValue`。如果該增加或減少配置的容量，它會通知您。
**Topics**
+ [了解 Application Auto Scaling 設定](#CostOptimization_AutoScalingSettings_UnderProvisionedTables)
+ [如何識別目標使用率低的資料表 (<=50%)](#CostOptimization_AutoScalingSettings_IdentifyLowUtilization)
+ [如何處理具有季節性差異的工作負載](#CostOptimization_AutoScalingSettings_SeasonalVariance)
+ [如何處理具有未知模式的尖峰工作負載](#CostOptimization_AutoScalingSettings_UnknownPatterns)
+ [如何處理具有連結應用程式的工作負載](#CostOptimization_AutoScalingSettings_BetweenRanges)
## 了解 Application Auto Scaling 設定
您的營運團隊需定義目標使用率的正確值、初始步驟和最終值。這可讓您根據歷史應用程式用量正確定義值，以用來觸發 Application Auto Scaling 政策。使用率目標是在套用 Application Auto Scaling 規則前一段時間內需要達到的總容量百分比。
當您設定**高使用率目標 （約 90% 的目標**) 時，這表示您的流量需要高於 90% 一段時間，才能啟用 Application Auto Scaling。除非您的應用程式狀態穩定，且不會接收到流量尖峰，否則不應使用高使用率目標。
當您設定**極低的使用率 （低於 50% 的目標**) 時，表示您的應用程式需要達到佈建容量的 50%，才能觸發 Application Auto Scaling 政策。除非您的應用程式流量成長快速，否則這通常會變成未使用容量和資源浪費。
## 如何識別目標使用率低的資料表 (<=50%)
您可以使用 AWS CLI 或 AWS 管理主控台 來監控和識別 Amazon Keyspaces 資源中 Application Auto Scaling 政策`TargetValues`的 。
**注意**
當您在佈建容量模式中使用多區域資料表搭配 Amazon Keyspaces 自動擴展時，請務必使用 Amazon Keyspaces API 操作來設定自動擴展。Amazon Keyspaces 代您呼叫的基礎 Application Auto Scaling API 操作沒有多區域功能。如需詳細資訊，請參閱[在 Amazon Keyspaces 中檢視多區域資料表的佈建容量和自動擴展設定](tables-mrr-view.md)。
------
#### [ AWS CLI ]
1. 執行下列命令，傳回完整的資源清單：
```
aws application-autoscaling describe-scaling-policies --service-namespace cassandra
```
此命令將傳回發給任何 Amazon Keyspaces 資源的完整 Application Auto Scaling 政策清單。若您只想從特定資料表擷取資源，您可以新增 `–resource-id parameter`。例如：
```
aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name”
```
1. 執行下列命令，僅傳回特定資料表的自動擴展政策
```
aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name”
```
Application Auto Scaling 政策的值會反白顯示如下。您需要確保目標值大於 50%，以避免過度佈建。您應該會獲得類似以下的結果：
```
{
"ScalingPolicies": [
{
"PolicyARN": "arn:aws:autoscaling:us-east-1:111122223333:scalingPolicy::resource/keyspaces/table/table-name-scaling-policy",
"PolicyName": $”,
"ServiceNamespace": "cassandra",
"ResourceId": "keyspace/keyspace-name/table/table-name",
"ScalableDimension": "cassandra:table:WriteCapacityUnits",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"TargetValue": 70.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "KeyspacesWriteCapacityUtilization"
}
},
"Alarms": [
...
],
"CreationTime": "2022-03-04T16:23:48.641000+10:00"
},
{
"PolicyARN": "arn:aws:autoscaling:us-east-1:111122223333:scalingPolicy::resource/keyspaces/table/table-name-scaling-policy",
"PolicyName":$”,
"ServiceNamespace": "cassandra",
"ResourceId": "keyspace/keyspace-name/table/table-name",
"ScalableDimension": "cassandra:table:ReadCapacityUnits",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"TargetValue": 70.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "KeyspacesReadCapacityUtilization"
}
},
"Alarms": [
...
],
"CreationTime": "2022-03-04T16:23:47.820000+10:00"
}
]
}
```
------
#### [ AWS 管理主控台 ]
1. 登入 AWS 管理主控台 ，並在 [入門 AWS 管理主控台](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html)中導覽至 CloudWatch 服務頁面。 AWS 區域 視需要選取適當的 。
1. 在左側導覽列中，選取 **Tables** (資料表)。在 **Tables** (資料表) 頁面上，選取資料表 **Name** (名稱)。
1. 在**容量**索引標籤的**資料表詳細資訊**頁面上，檢閱資料表的 Application Auto Scaling 設定。
------
若您的目標使用率值小於或等於 50%，您應探索資料表使用率指標，查看指標是否[佈建不足或過度佈建](CostOptimization_RightSizedProvisioning.md)。
## 如何處理具有季節性差異的工作負載
請考慮下列情況：您的應用程式大部分時間都以最小平均值運作，但使用率目標很低，因此應用程式可以快速回應特定時間發生的事件，且您擁有足夠容量避免受到限流。應用程式在正常辦公時間 (上午 9 點至下午 5 點) 非常忙碌，但下班時間僅在基礎層級運作時，這種情況就很常見。由於某些使用者會在上午 9 點之前開始連線，因此應用程式會使用此低閾值快速提升，以在尖峰時間達到*所需的*容量。
此情況可能如下所示：
+ 下午 5 點至上午 9 點之間，`ConsumedWriteCapacityUnits` 單位停留在 90 和 100 之間
+ 使用者在上午 9 點前開始連線到應用程式，且容量單位大幅增加 (您看到的最大值為 1500 WCU)
+ 平均而言，在工作期間，應用程式使用量介於 800 到 1200
如果先前的案例適用於您的應用程式，請考慮使用[排程應用程式自動擴展](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html)，其中您的資料表仍然可以設定 Application Auto Scaling 規則，但具有較不積極的目標使用率，只會以您所需的特定間隔佈建額外的容量。
您可以使用 AWS CLI 來執行下列步驟，以建立排程的自動擴展規則，該規則會根據一天中的時間和星期幾來執行。
1. 向 將 Amazon Keyspaces 資料表註冊為可擴展的目標 Application Auto Scaling。可擴展的目標是 Application Auto Scaling 可橫向擴充和縮減的資源。
```
aws application-autoscaling register-scalable-target \
--service-namespace cassandra \
--scalable-dimension cassandra:table:WriteCapacityUnits \
--resource-id keyspace/keyspace-name/table/table-name \
--min-capacity 90 \
--max-capacity 1500
```
1. 根據您的需求設定排定的動作。
您需要兩個規則來涵蓋案例：一個向上擴展，另一個向下擴展。擴展排程動作的第一個規則會顯示在下列範例中。
```
aws application-autoscaling put-scheduled-action \
--service-namespace cassandra \
--scalable-dimension cassandra:table:WriteCapacityUnits \
--resource-id keyspace/keyspace-name/table/table-name \
--scheduled-action-name my-8-5-scheduled-action \
--scalable-target-action MinCapacity=800,MaxCapacity=1500 \
--schedule "cron(45 8 ? * MON-FRI *)" \
--timezone "Australia/Brisbane"
```
此範例中顯示縮減排程動作的第二個規則。
```
aws application-autoscaling put-scheduled-action \
--service-namespace cassandra \
--scalable-dimension cassandra:table:WriteCapacityUnits \
--resource-id keyspace/keyspace-name/table/table-name \
--scheduled-action-name my-5-8-scheduled-down-action \
--scalable-target-action MinCapacity=90,MaxCapacity=1500 \
--schedule "cron(15 17 ? * MON-FRI *)" \
--timezone "Australia/Brisbane"
```
1. 執行以下命令，驗證這兩個規則皆已啟用。
```
aws application-autoscaling describe-scheduled-actions --service-namespace cassandra
```
您應該會取得如下結果：
```
{
"ScheduledActions": [
{
"ScheduledActionName": "my-5-8-scheduled-down-action",
"ScheduledActionARN": "arn:aws:autoscaling:us-east-1:111122223333:scheduledAction::resource/keyspaces/table/table-name:scheduledActionName/my-5-8-scheduled-down-action",
"ServiceNamespace": "cassandra",
"Schedule": "cron(15 17 ? * MON-FRI *)",
"Timezone": "Australia/Brisbane",
"ResourceId": "keyspace/keyspace-name/table/table-name",
"ScalableDimension": "cassandra:table:WriteCapacityUnits",
"ScalableTargetAction": {
"MinCapacity": 90,
"MaxCapacity": 1500
},
"CreationTime": "2022-03-15T17:30:25.100000+10:00"
},
{
"ScheduledActionName": "my-8-5-scheduled-action",
"ScheduledActionARN": "arn:aws:autoscaling:us-east-1:111122223333:scheduledAction::resource/keyspaces/table/table-name:scheduledActionName/my-8-5-scheduled-action",
"ServiceNamespace": "cassandra",
"Schedule": "cron(45 8 ? * MON-FRI *)",
"Timezone": "Australia/Brisbane",
"ResourceId": "keyspace/keyspace-name/table/table-name",
"ScalableDimension": "cassandra:table:WriteCapacityUnits",
"ScalableTargetAction": {
"MinCapacity": 800,
"MaxCapacity": 1500
},
"CreationTime": "2022-03-15T17:28:57.816000+10:00"
}
]
}
```
下圖顯示一律保持 70% 目標使用率的範例工作負載。請注意，自動擴展規則如何仍然套用，且輸送量不會降低。
![\[此圖表顯示在一天內佈建與消耗容量的比較，以每秒單位為單位的寫入用量。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings3.png)
放大時可以看到應用程式中，有一個尖峰觸發了 70% 的自動擴展閾值，強制啟動自動擴展，並提供資料表所需的額外容量。排程的自動擴展動作會影響最大值和最小值，而設定這些值是您的責任。
![\[圖形的更詳細檢視，以每秒單位為單位顯示佈建與耗用容量的比較，在特定時間放大。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings4.png)
![\[顯示圖表的詳細檢視，其中顯示佈建與一天內消耗容量的比較，以每秒單位為單位的寫入用量。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings5.png)
## 如何處理具有未知模式的尖峰工作負載
在此案例中，應用程式使用非常低的使用率目標，因為您尚不知道應用程式模式，而且您想要確保工作負載不會遇到低容量輸送量錯誤。
請考慮改用[隨需容量模式](ReadWriteCapacityMode.OnDemand.md)。隨需資料表非常適合流量模式不明的尖峰工作負載。使用隨需容量模式，您可以按請求支付應用程式在資料表上執行的資料讀取和寫入費用。您不需要指定預期應用程式執行的讀取和寫入輸送量，因為 Amazon Keyspaces 會在工作負載上升或下降時立即容納工作負載。
## 如何處理具有連結應用程式的工作負載
在此情況中，應用程式會依賴其他系統，像是在批次處理的情況，您可能會根據應用程式邏輯中的事件，遇到流量出現大峰值。
考慮開發自訂應用程式自動調整規模邏輯，以對您可以增加資料表容量並`TargetValues`根據您的特定需求做出反應的事件做出反應。您可以受益於 ， Amazon EventBridge 並使用 Λ 和 Step Functions 等 AWS 服務組合來回應您的特定應用程式需求。