本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 最佳化 Amazon Keyspaces 資料表的成本 本節涵蓋如何最佳化現有 Amazon Keyspaces 資料表成本的最佳實務。您應查看以下策略，了解哪一項成本最佳化策略最適合您的需求，並反覆採用這些策略。每個策略都提供可能對成本造成影響的概觀、如何尋找最佳化成本的機會，以及如何實作這些最佳實務以協助您節省成本的規範性指導。 **Topics** + [在資料表層級評估您的成本](CostOptimization_TableLevelCostAnalysis.md) + [評估資料表的容量模式](CostOptimization_TableCapacityMode.md) + [評估資料表的 Application Auto Scaling 設定](CostOptimization_AutoScalingSettings.md) + [識別未使用的資源，以最佳化 Amazon Keyspaces 中的成本](CostOptimization_UnusedResources.md) + [評估您的資料表用量模式，以最佳化效能和成本](CostOptimization_TableUsagePatterns.md) + [評估您是否具有適當大小的佈建容量](CostOptimization_RightSizedProvisioning.md) # 在資料表層級評估您的成本 在 中找到的 Cost Explorer 工具 AWS 管理主控台 可讓您查看依類型細分的成本，例如讀取、寫入、儲存和備份費用。您還可以查看依期間 (例如月份或日期) 彙總的這些成本。 Cost Explorer 的一個常見挑戰是您無法輕鬆檢閱一個特定資料表的成本，因為 Cost Explorer 不會讓您依特定資料表的成本篩選或分組。您可以在資料表的**監控**索引標籤的 Amazon Keyspaces 主控台中檢視每個資料表的指標**計費資料表大小 （位元組）**。如果您需要更多每個資料表的成本相關資訊，本節說明如何使用[標記](tagging-keyspaces.md)在 Cost Explorer 中執行個別資料表的成本分析。 **Topics** + [如何檢視單一 Amazon Keyspaces 資料表的成本](#CostOptimization_TableLevelCostAnalysis_ViewInfo) + [Cost Explorer 的預設檢視](#CostOptimization_TableLevelCostAnalysis_CostExplorer) + [如何在 Cost Explorer 中使用和套用資料表標籤](#CostOptimization_TableLevelCostAnalysis_Tagging) ## 如何檢視單一 Amazon Keyspaces 資料表的成本 您可以在 主控台中查看 Amazon Keyspaces 資料表的基本資訊，包括主索引鍵結構描述、計費資料表大小和容量相關指標。您可以使用資料表的大小來計算資料表的每月儲存成本。例如，美國東部 （維吉尼亞北部） 每 GB 0 AWS 區域.25 美元。 如果資料表使用佈建容量模式，也會傳回目前的讀取容量單位 (RCU) 和寫入容量單位 (WCU) 設定。您可以使用此資訊來計算資料表目前的讀取和寫入成本。請注意，這些成本可能會變更，特別是如果您已使用 Amazon Keyspaces 自動擴展設定資料表時。 ## Cost Explorer 的預設檢視 Cost Explorer 中的預設檢視提供圖表，顯示耗用資源的成本，例如輸送量和儲存。您可以選擇按期間分組這些成本，例如按月或按天的總計。儲存、讀取、寫入和其他類別的成本也可以分割和比較。 ![\[影像顯示在「Cost Explorer」檢視中列出的耗用資源成本。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/CostOptimization/CostExplorerView.png) ## 如何在 Cost Explorer 中使用和套用資料表標籤 根據預設，Cost Explorer 不會提供任何一個特定資料表的成本摘要，因為它會將多個資料表的成本合併為總計。不過，您可以使用 [AWS 資源標記](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)，以中繼資料標籤來識別各個資料表。標籤是索引鍵/值組，可用於各種用途，例如識別屬於專案或部門的所有資源。如需詳細資訊，請參閱[使用 Amazon Keyspaces 資源的標籤和標籤](tagging-keyspaces.md)。 在此範例中，我們使用名為 **MyTable** 的資料表。 1. 設定一項具有「**table\$1name**」索引鍵和「**MyTable**」值的標籤。 1. [在 Cost Explorer 中啟用此標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)，然後篩選標籤值，以深入了解各個資料表的成本。 **注意** 標籤可能需要一到兩天的時間才會開始出現在 Cost Explorer 中 您可以在 主控台中自行設定中繼資料標籤，或使用 CQL AWS CLI、 或 AWS SDK 以程式設計方式設定中繼資料標籤。請考慮在組織的新標籤建立程序中要求設定 **table\$1name** 標籤。如需詳細資訊，請參閱[使用 Amazon Keyspaces 的標籤建立成本分配報告](CostAllocationReports.md)。 # 評估資料表的容量模式 本節提供如何為 Amazon Keyspaces 資料表選取適當容量模式的概觀。每種模式都經過調整，以滿足不同工作負載在回應輸送量變化以及該用量計費方式方面的需求。在做出決策時，必須平衡考量這些因素。 **Topics** + [有哪些可用的資料表容量模式](#CostOptimization_TableCapacityMode_Overview) + [何時選取隨需容量模式](#CostOptimization_TableCapacityMode_OnDemand) + [何時選取佈建容量模式](#CostOptimization_TableCapacityMode_Provisioned) + [選擇資料表容量模式時應考慮的其他因素](#CostOptimization_TableCapacityMode_AdditionalFactors) ## 有哪些可用的資料表容量模式 建立 Amazon Keyspaces 資料表時，您必須選取隨需或佈建容量模式。如需詳細資訊，請參閱[在 Amazon Keyspaces 中設定讀取/寫入容量模式](ReadWriteCapacityMode.md)。 **隨需容量模式** 隨需容量模式旨在消除規劃或佈建 Amazon Keyspaces 資料表容量的需求。在此模式中，您的資料表會立即容納請求，而不需要擴展或縮減任何資源 （高達資料表先前尖峰輸送量的兩倍）。 隨需資料表的計費方式是針對資料表計算實際請求數，因此您只需支付您使用的項目，而非已佈建的項目。 **佈建容量模式** 佈建容量模式是一種較傳統的模型，您可以在其中定義資料表可直接或在 Application Auto Scaling 的協助下可用於請求的容量。由於會在任何指定時間為資料表佈建特定容量，因此是根據佈建的容量而非請求數目進行計費。超過配置的容量也可能導致資料表拒絕請求，並減少應用程式使用者的體驗。 佈建容量模式需要在未過度佈建或佈建資料表下之間取得平衡，以實現低輸送量容量不足錯誤和最佳化成本。 ## 何時選取隨需容量模式 當您有類似下圖所示的無法預測工作負載時，最佳化成本時，隨需模式是您的最佳選擇。 這些因素會導致這種類型的工作負載： + 無法預測的請求時機 (導致流量尖峰) + 變動的請求量 (由批次工作負載導致) + 下降到指定小時峰值的零或低於峰值的 18% （由開發或測試環境產生） ![\[影像顯示尖峰工作負載，其流量峰值隨機分佈。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeOnDemand.png) 對於具有上述特性的工作負載，使用 Application Auto Scaling 來維持足夠容量讓資料表回應流量激增，可能會導致不良結果。資料表可能過度佈建且成本超過必要，或者資料表可能佈建不足，且請求導致不必要的低容量輸送量錯誤。在這種情況下，隨需資料表是更好的選擇。 由於隨需資料表是依請求計費，因此您不需要再在資料表層級執行任何操作來最佳化成本。您應該定期評估隨需資料表，以確認工作負載仍具有上述特性。如果工作負載已穩定，請考慮變更為佈建模式，以維持成本最佳化。 ## 何時選取佈建容量模式 佈建容量模式的理想工作負載是具有更可預測用量模式的工作負載，如下圖所示。 下列因素會導致可預測的工作負載： + 特定一小時或一天內的可預測/周期性流量 + 有限度的短期突發流量 ![\[影像顯示可預測性佳且流量峰值有限的工作負載。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeProvisioned.png) 由於指定時間或日期內的流量更為穩定，因此您可以設定相對接近資料表實際耗用容量的佈建容量。將佈建容量資料表進行成本最佳化，最終是讓佈建容量 （藍線） 盡可能接近耗用容量 （橘色線），而不會增加資料表`ThrottledRequests`的事件。兩行之間的空間同時是浪費的容量，以及因為輸送容量不足錯誤而導致不良使用者體驗的保險。 Amazon Keyspaces 為佈建容量資料表提供 Application Auto Scaling，可代表您自動平衡。您可以追蹤一整天的耗用容量，並根據少量變數來設定資料表的佈建容量。 **容量單位下限** 您可以設定資料表的最小容量，以限制輸送量容量不足錯誤的發生，但不會降低資料表的成本。如果您的資料表具有低用量期間，然後突然高用量暴增，則設定最小值可防止 Application Auto Scaling 設定太低的資料表容量。 **容量單位上限** 您可以設定資料表的容量上限，以避免資料表的規模調整到高於預期的程度。考慮對開發或測試資料表套用最大值，其中不需要大規模負載測試。您可以為任何資料表設定最大值，但在生產環境中使用時，請務必定期根據資料表基準評估此設定，以防止意外的輸送量容量不足錯誤。 **目標使用率** 對於佈建容量資料表，設定資料表的目標使用率是實現成本最佳化的主要方法。在此處設定較低的百分比值會增加資料表過度佈建的程度，增加成本，但可降低輸送量容量不足錯誤的風險。設定較高的百分比值會減少資料表過度佈建的程度，但會增加輸送量容量不足錯誤的風險。 ## 選擇資料表容量模式時應考慮的其他因素 在兩種容量模式之間做決定時，有一些其他因素值得考慮。 在兩個資料表模式之間進行決策時，請考慮此額外折扣對資料表成本的影響程度。在許多情況下，即使是相對不可預測的工作負載，在具有預留容量的過度佈建佈建容量資料表上執行也更具成本效益。 **改善工作負載的可預測性** 在某些情況下，工作負載可能同時具有可預測和不可預測的模式。雖然隨需資料表可以輕鬆支援，但如果工作負載中無法預測的模式可以改善，成本可能會更低。 這些模式最常見的原因之一是批次匯入。這種類型的流量通常可以超過資料表的基準容量，達到如果執行就會發生輸送量容量不足錯誤的程度。若要在佈建容量資料表上執行這類工作負載，請考慮下列選項： + 如果批次在排程時間發生，您可以在執行之前排程增加應用程式自動擴展容量。 + 如果批次隨機發生，請考慮嘗試延長執行所需的時間，而不是盡快執行。 + 將漸進測試期間新增至匯入，匯入速度從小開始，但在幾分鐘內緩慢增加，直到 Application Auto Scaling 有機會開始調整資料表容量為止。 # 評估資料表的 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 服務組合來回應您的特定應用程式需求。 # 識別未使用的資源，以最佳化 Amazon Keyspaces 中的成本 本節概述如何定期評估未使用的資源。隨著應用程式需求的演進，您應該確保沒有未使用的資源，並造成不必要的 Amazon Keyspaces 成本。以下所述的程序使用 Amazon CloudWatch 指標來識別未使用的資源，並採取行動以降低成本。 您可以使用 CloudWatch 監控 Amazon Keyspaces，其會收集來自 Amazon Keyspaces 的原始資料，並將其處理為可讀且近乎即時的指標。這些統計資料會保留一段時間，以便您存取歷史資訊，並更清楚了解自己的使用率。根據預設，Amazon Keyspaces 指標資料會自動傳送至 CloudWatch。如需詳細資訊，請參閱《*Amazon CloudWatch 使用者指南*》中的[什麼是 Amazon CloudWatch？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)以及[指標保留](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#metrics-retention)。 **Topics** + [如何識別未使用資源](#CostOptimization_UnusedResources_Identifying) + [識別未使用的資料表資源](#CostOptimization_UnusedResources_Tables) + [清除未使用的資料表資源](#CostOptimization_UnusedResources_Tables_Cleanup) + [清除未使用的point-in-time復原 (PITR) 備份](#CostOptimization_UnusedResources_Backups) ## 如何識別未使用資源 若要識別未使用的資料表，您可以查看 30 天內的下列 CloudWatch 指標，以了解特定資料表上是否有任何作用中的讀取或寫入： **`ConsumedReadCapacityUnits`** 在指定時段使用的讀取容量單位數目，可讓您追蹤已使用多少使用容量。您可以擷取資料表的總耗用讀取容量。 **`ConsumedWriteCapacityUnits`** 在指定時段使用的寫入容量單位數目，可讓您追蹤已使用多少使用容量。您可以擷取資料表的總耗用寫入容量。 ## 識別未使用的資料表資源 Amazon CloudWatch 是一種監控和可觀測性服務，提供可用於識別未使用資源的 Amazon Keyspaces 資料表指標。您可以透過 AWS 管理主控台 和 AWS Command Line Interface來檢視 CloudWatch 指標。 ------ #### [ AWS Command Line Interface ] 若要透過 檢視資料表指標 AWS Command Line Interface，您可以使用下列命令。 1. 首先評估資料表的讀取： **注意** 如果資料表名稱在帳戶中不是唯一的，您也必須指定金鑰空間的名稱。 ``` aws cloudwatch get-metric-statistics --metric-name ConsumedReadCapacityUnits --start-time --end-time --period --namespace AWS/Cassandra --statistics Sum -- dimensions Name=TableName,Value= ``` 為了避免將資料表誤認為未使用，請評估較長期間內的指標。選擇適當的開始時間和結束時間範圍，例如 ** 30 天**，以及適當的期間，例如 **86400**。 在傳回的資料中，任何大於 **0** 的**總和**都表示您所評估的資料表在該期間內曾經接收讀取流量。 下列結果顯示在評估期間接收讀取流量的資料表： ``` { "Timestamp": "2022-08-25T19:40:00Z", "Sum": 36023355.0, "Unit": "Count" }, { "Timestamp": "2022-08-12T19:40:00Z", "Sum": 38025777.5, "Unit": "Count" }, ``` 下列結果顯示在評估期間未接收讀取流量的資料表： ``` { "Timestamp": "2022-08-01T19:50:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-20T19:50:00Z", "Sum": 0.0, "Unit": "Count" }, ``` 1. 接下來，評估資料表的寫入數： ``` aws cloudwatch get-metric-statistics --metric-name ConsumedWriteCapacityUnits --start-time --end-time --period --namespace AWS/Cassandra --statistics Sum -- dimensions Name=TableName,Value= ``` 為了避免將資料表誤認為未使用，建議您評估較長期間內的指標。選擇適當的開始時間和結束時間範圍 (例如 **30 天**) 及適當的期間 (例如 **86400**)。 在傳回的資料中，任何大於 **0** 的**總和**都表示您所評估的資料表在該期間內曾經接收讀取流量。 下列結果顯示在評估期間接收寫入流量的資料表： ``` { "Timestamp": "2022-08-19T20:15:00Z", "Sum": 41014457.0, "Unit": "Count" }, { "Timestamp": "2022-08-18T20:15:00Z", "Sum": 40048531.0, "Unit": "Count" }, ``` 下列結果顯示在評估期間曾接收寫入流量的資料表： ``` { "Timestamp": "2022-07-31T20:15:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-19T20:15:00Z", "Sum": 0.0, "Unit": "Count" }, ``` ------ #### [ AWS 管理主控台 ] 下列步驟可讓您透過 評估資源使用率 AWS 管理主控台。 1. 登入 AWS 管理主控台 並導覽至位於 https：//[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 的 CloudWatch 服務頁面。如有必要，請在主控台的 AWS 區域 右上角選取適當的 。 1. 在左側導覽列上，找到**指標**區段，然後選擇**所有指標**。 1. 上述動作會開啟具有兩個面板的儀表板。在頂端面板中，您可以看到目前繪製的指標。在底部，您可以選取可用於繪製圖形的指標。在底部面板中選擇 Amazon Keyspaces。 1. 在 Amazon Keyspaces 指標選擇面板中，選擇**資料表指標**類別，以顯示目前區域中資料表的指標。 1. 向下捲動選單來識別資料表名稱，然後`ConsumedWriteCapacityUnits`為您的資料表選擇指標 `ConsumedReadCapacityUnits`和 。 1. 選擇**圖形化指標 (2)** 索引標籤，並將**統計資料**欄調整為**總和**。 1. 若要避免錯誤地將資料表識別為未使用，請評估較長期間內的資料表指標。在圖形面板頂端，選擇適當的時間範圍，例如 1 個月，以評估您的資料表。選擇**自訂**，在下拉式選單中選擇 **1 個月**，然後選擇**套用**。 1. 評估資料表的圖表化指標，判斷是否已使用該資料表。如果指標超過 **0**，就表示在評估期間內已使用該資料表。讀取和寫入的平面圖形為 **0**，表示資料表未使用。 ------ ## 清除未使用的資料表資源 如果找出未使用的資料表資源，您可以透過下列方式降低其持續產生的成本。 **注意** 如果找出未使用的資料表，但仍希望保留以備日後需要時可供存取，請考慮將其轉換為隨需模式。否則，您可以考慮刪除資料表。 **容量模式** Amazon Keyspaces 會收取讀取、寫入和存放 Amazon Keyspaces 資料表中資料的費用。 Amazon Keyspaces [有兩種容量模式](ReadWriteCapacityMode.md)，隨附處理資料表上的讀取和寫入的特定計費選項：隨需和佈建。讀取/寫入容量模式可控制您變更讀取與寫入輸送量以及管理容量的方式。 若為隨需模式資料表，不需要指定您預期應用程式將進行的讀取和寫入輸送量。Amazon Keyspaces 會針對應用程式在資料表上執行的讀取和寫入，收取讀取請求單位和寫入請求單位的費用。如果您的資料表上沒有活動，您不需要支付輸送量費用，但仍需支付儲存費用。 **刪除資料表** 如果您發現未使用的資料表並想要將其刪除，請考慮先進行備份或匯出資料。 透過 取得的備份 AWS Backup 可以利用冷儲存分層，進一步降低成本。如需如何使用生命週期將備份移至冷儲存體的資訊，請參閱[管理備份計劃](https://docs.aws.amazon.com/aws-backup/latest/devguide/about-backup-plans)文件。 備份資料表之後，即可選擇透過 AWS 管理主控台 或 AWS Command Line Interface加以刪除。 ## 清除未使用的point-in-time復原 (PITR) 備份 Amazon Keyspaces 提供Point-in-time復原，可提供 35 天的連續備份，協助您防止意外寫入或刪除。PITR 備份有相關聯的成本。 請參閱 的文件[使用 point-in-time復原來備份和還原資料](PointInTimeRecovery.md)，以判斷您的資料表是否已啟用可能不再需要的備份。 # 評估您的資料表用量模式，以最佳化效能和成本 本節提供如何評估您是否有效率地使用 Amazon Keyspaces 資料表的概觀。有些使用模式不適用於 Amazon Keyspaces，而且從效能和成本角度都允許最佳化的空間。 **Topics** + [執行較少高度一致性讀取操作](#CostOptimization_TableUsagePatterns_StronglyConsistentReads) + [啟用存留時間 (TTL)](#CostOptimization_TableUsagePatterns_TTL) ## 執行較少高度一致性讀取操作 Amazon Keyspaces 可讓您根據請求設定[讀取一致性](consistency.md#ReadConsistency)。根據預設，讀取請求最終會保持一致。最終一致讀取會以 0.5 RCU 收費，最多 4 KB 的資料。 分散式工作負載的多數部分都具有彈性，可以容忍最終一致性。但是，有些存取模式要求高度一致性讀取。高度一致的讀取會以 1 個 RCU 收費，最多 4 KB 的資料，基本上是讀取成本的兩倍。Amazon Keyspaces 可讓您靈活地在同一資料表上使用兩個一致性模型。 您可以評估工作負載和應用程式的程式碼，確定是否僅在需要時使用高度一致性讀取。 ## 啟用存留時間 (TTL) [存留時間 (TTL)](TTL.md) 可協助您簡化應用程式邏輯，並透過自動從資料表過期資料來最佳化儲存體的價格。您不再需要的資料會根據您設定的存留時間值，自動從資料表中刪除。 # 評估您是否具有適當大小的佈建容量 本節提供如何評估 Amazon Keyspaces 資料表上是否有適當大小的佈建的概觀。隨著工作負載的演進，您應該適當地修改操作程序，尤其是當您的 Amazon Keyspaces 資料表在佈建模式中設定，而且您有過度佈建或佈建不足資料表的風險時。 本節所述的程序需要從支援生產應用程式的 Amazon Keyspaces 資料表中擷取的統計資訊。若要了解您的應用程式行為，您應該定義足夠重要的時段，以擷取應用程式的資料季節性。例如，若應用程式顯示每週模式，三週時間便應足夠來分析應用程式輸送量需求。 若您不知道從何下手，請使用至少一個月的資料用量進行以下計算。 在評估容量時，對於 Amazon Keyspaces 資料表，您可以獨立設定**讀取容量單位 RCUs)** 和**寫入容量單位 (WCU)**。 **Topics** + [如何從 Amazon Keyspaces 資料表擷取取用指標](#CostOptimization_RightSizedProvisioning_ConsumptionMetrics) + [如何識別佈建不足的 Amazon Keyspaces 資料表](#CostOptimization_RightSizedProvisioning_UnderProvisionedTables) + [如何識別過度佈建的 Amazon Keyspaces 資料表](#CostOptimization_RightSizedProvisioning_OverProvisionedTables) ## 如何從 Amazon Keyspaces 資料表擷取取用指標 若要評估資料表容量，請監控下列 CloudWatch 指標，然後選取適當的維度以擷取資料表資訊： | 讀取容量單位 | 寫入容量單位 | | --- | --- | | `ConsumedReadCapacityUnits` | `ConsumedWriteCapacityUnits` | | `ProvisionedReadCapacityUnits` | `ProvisionedWriteCapacityUnits` | | `ReadThrottleEvents` | `WriteThrottleEvents` | 您可以透過 AWS CLI 或 執行此操作 AWS 管理主控台。 ------ #### [ AWS CLI ] 擷取資料表取用指標之前，您需要先使用 CloudWatch API 擷取一些歷史資料點。 首先要建立兩個檔案：`write-calc.json` 和 `read-calc.json`。這些檔案代表資料表的計算。您需要更新一些欄位，如下表所示，以符合您的環境。 **注意** 如果資料表名稱在帳戶中不是唯一的，您也必須指定金鑰空間的名稱。 | 欄位名稱 | 定義 | 範例 | | --- | --- | --- | | | 您正在分析的資料表名稱 | SampleTable | | | 您用來評估使用率目標的期間，以秒為單位 | 針對 1 小時的時間，您應指定：3600 | | | 評估間隔的開始時間，以 ISO8601 格式顯示 | 2022-02-21T23:00:00 | | | 評估間隔的結束時間，以 ISO8601 格式顯示 | 2022-02-22T06:00:00 | 寫入計算檔案會擷取指定日期範圍期間內佈建和取用的 WCU 數量。它也會產生可用於分析的使用率百分比。`write-calc.json` 檔案的完整內容看起來應該如下例所示。 ``` { "MetricDataQueries": [ { "Id": "provisionedWCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ProvisionedWriteCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Average" }, "Label": "Provisioned", "ReturnData": false }, { "Id": "consumedWCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ConsumedWriteCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": """ } ] }, "Period": , "Stat": "Sum" }, "Label": "", "ReturnData": false }, { "Id": "m1", "Expression": "consumedWCU/PERIOD(consumedWCU)", "Label": "Consumed WCUs", "ReturnData": false }, { "Id": "utilizationPercentage", "Expression": "100*(m1/provisionedWCU)", "Label": "Utilization Percentage", "ReturnData": true } ], "StartTime": "", "EndTime": "", "ScanBy": "TimestampDescending", "MaxDatapoints": 24 } ``` 讀取計算檔案使用類似的指標。此檔案會擷取在指定日期範圍的期間內佈建和取用的 RCUs 數量。在此範例中， `read-calc.json` 檔案的內容看起來應該類似 。 ``` { "MetricDataQueries": [ { "Id": "provisionedRCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ProvisionedReadCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Average" }, "Label": "Provisioned", "ReturnData": false }, { "Id": "consumedRCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ConsumedReadCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Sum" }, "Label": "", "ReturnData": false }, { "Id": "m1", "Expression": "consumedRCU/PERIOD(consumedRCU)", "Label": "Consumed RCUs", "ReturnData": false }, { "Id": "utilizationPercentage", "Expression": "100*(m1/provisionedRCU)", "Label": "Utilization Percentage", "ReturnData": true } ], "StartTime": "", "EndTime": "", "ScanBy": "TimestampDescending", "MaxDatapoints": 24 } ``` 建立檔案之後，您就可以開始擷取使用率資料。 1. 若要擷取寫入使用率資料，請發出下列命令： ``` aws cloudwatch get-metric-data --cli-input-json file://write-calc.json ``` 1. 若要擷取讀取使用率資料，請發出下列命令： ``` aws cloudwatch get-metric-data --cli-input-json file://read-calc.json ``` 這兩個查詢的結果都是一系列 JSON 格式的資料點，可用於分析。您的結果取決於您指定的資料點數量、期間，以及您自己的特定工作負載資料。在以下範例中可能看起來像 。 ``` { "MetricDataResults": [ { "Id": "utilizationPercentage", "Label": "Utilization Percentage", "Timestamps": [ "2022-02-22T05:00:00+00:00", "2022-02-22T04:00:00+00:00", "2022-02-22T03:00:00+00:00", "2022-02-22T02:00:00+00:00", "2022-02-22T01:00:00+00:00", "2022-02-22T00:00:00+00:00", "2022-02-21T23:00:00+00:00" ], "Values": [ 91.55364583333333, 55.066631944444445, 2.6114930555555556, 24.9496875, 40.94725694444445, 25.61819444444444, 0.0 ], "StatusCode": "Complete" } ], "Messages": [] } ``` **注意** 如果您指定短期間和長時間範圍，您可能需要修改值，該`MaxDatapoints`值預設為指令碼中的 24。這代表每小時產生一個資料點，每天 24 個資料點。 ------ #### [ AWS 管理主控台 ] 1. 登入 AWS 管理主控台 ，並在 [入門 AWS 管理主控台](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html)中導覽至 CloudWatch 服務頁面。 AWS 區域 視需要選取適當的 。 1. 找到左側導覽列上的指標區段，然後選擇**所有指標**。 1. 這會開啟具有兩個面板的儀表板。頂端面板會顯示圖形，而底部面板具有您要繪製圖形的指標。選擇 Amazon Keyspaces 面板。 1. 從子面板中選擇**資料表指標**類別。這會顯示目前 中的資料表 AWS 區域。 1. 向下捲動選單找出您的資料表名稱，然後選取寫入操作指標：`ConsumedWriteCapacityUnits` 和 `ProvisionedWriteCapacityUnits`。 **注意** 此範例討論寫入操作指標，但您也可以用這些步驟來繪製讀取操作指標的圖形。 1. 選取 **Graphed metrics (2)** (圖表化指標(2)) 標籤，修改公式。根據預設，CloudWatch 會為圖形選擇統計函數**平均**。 1. 同時選取兩個圖形化指標 (左側的核取方塊) 後，選取選單 **Add math** (新增數學)，再選取 **Common** (一般) 及 **Percentage** (百分比) 函數。重複該過程兩次。 第一次選取**百分比**函數。 第二次選取**百分比**函數。 1. 此時，選單底部應有四個指標。接著進行 `ConsumedWriteCapacityUnits` 計算。為了保持一致，您需要將名稱與您在 AWS CLI 區段中使用的名稱相符。按一下 **m1 ID**，並將此值變更為 **consumedWCU**。 1. 將統計資料從 **Average** (平均值) 變更為 **Sum** (總和)。此動作會自動建立另一個名為 **ANOMALY\$1DETECTION\$1BAND** 的指標。對於此程序的範圍，您可以透過移除新產生的 **ad1 指標**上的核取方塊來忽略這一點。 1. 重複步驟 8，將 **m2 ID** 重新命名為 **provisionedWCU**。將統計資料設定保留為 **Average** (平均值)。 1. 選擇 **Expression1** 標籤，並將值更新為 **m1**，並將標籤更新為**已使用 WCUs**。 **注意** 請確認您只選取 **m1** (左側的核取方塊) 及 **provisionedWCU**，適當地視覺化資料。按一下 **Details** (詳細資料)，並將公式變更為 **consumedWCU/PERIOD(consumedWCU)**，以更新公式。此步驟也可能產生另一個 **ANOMALY\$1DETECTION\$1BAND** 指標，但對於此程序的範圍，您可以忽略它。 1. 您現在應該有兩個圖形：一個表示資料表上的佈建 WCUs另一個表示耗用的 WCUs。 1. 選取 Expression2 圖形 (**e2**) 以更新百分比公式。將標籤和 ID 重新命名為 **utilizationPercentage**。將公式重新命名，以符合 **100\$1(m1/provisionedWCU)**。 1. 從 **utilizationPercentage** 以外的所有指標中移除核取方塊，以視覺化您的使用率模式。預設間隔設定為 1 分鐘，但您可以視需要修改間隔。 您取得的結果取決於工作負載的實際資料。使用率超過 100% 的間隔容易發生低輸送量容量錯誤事件。Amazon Keyspaces 提供[高載容量](throughput-bursting.md)，但一旦高載容量用盡，超過 100% 的任何內容都會遇到低輸送量容量錯誤事件。 ------ ## 如何識別佈建不足的 Amazon Keyspaces 資料表 對於大多數工作負載，資料表在持續耗用其佈建容量的 80% 以上時，會被視為佈建不足。 [爆量容量](throughput-bursting.md)是一項 Amazon Keyspaces 功能，可讓客戶暫時使用比原始佈建更多的 RCUs/WCUs （超過為資料表定義的每秒佈建輸送量）。高載容量是為了吸收由於特殊事件或使用量尖峰而突增的流量。此高載容量有限，如需詳細資訊，請參閱 [在 Amazon Keyspaces 中有效使用高載容量](throughput-bursting.md)。一旦未使用的 RCUs 和 WCUs 用盡，如果您嘗試使用比佈建更多的容量，可能會遇到低容量輸送量錯誤事件。當您的應用程式流量接近 80% 的使用率時，發生低容量輸送量錯誤事件的風險會大幅提高。 80% 使用率規則會因資料的季節性和流量成長而有所不同。請考量下列情況： + 如果您的流量在過去 12 個月內**穩定**保持約 90% 的使用率，那麼您的資料表容量剛好 + 如果您的應用程式流量在 3 個月內以每月 8% 的速度**增加**，您將達到 100% + 如果您的應用程式流量在略多於 4 個月的期間以 5% 的速度**增加**，您仍會達到 100% 上述查詢結果能讓您得知使用率的情況。您可以使用這些結果做為指引，進一步評估其他指標，以協助您根據需要增加資料表容量 (例如：每月或每週成長率)。與您的營運團隊合作，為工作負載和資料表定義合理的百分比。 在某些情況下，當您每天或每週分析資料時，資料會扭曲。例如，如果季節性應用程式在工作時間內 （但在工作時間之外降到幾乎零） 的使用量遽增，您可以受益於[排程應用程式自動擴展](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html)，您可以在其中指定一天的時數 （和一週的天數） 來增加佈建的容量，以及何時減少它。如果您的季節性較不明顯，則您也可以受益於 [Amazon Keyspaces 資料表自動調整規模](autoscaling.md)組態，而不是為了涵蓋忙碌時間而瞄準更高的容量。 ## 如何識別過度佈建的 Amazon Keyspaces 資料表 從以上指令碼獲得的查詢結果提供了執行部分初始分析所需的資料點。若您的資料集在數個間隔內顯示的使用率低於 20%，表示資料表可能過度佈建。若要進一步判斷是否需減少 WCU 和 RCU 數量，您應重新檢視間隔中的其他讀數。 當您的資料表包含數個低用量間隔時，您可以透過排程 Application Auto Scaling 或僅為根據使用率的資料表設定預設 Application Auto Scaling 政策，從使用 Application Auto Scaling 政策中獲益。 如果您的工作負載在間隔中具有低使用率和高限流率 (**Max(ThrottleEvents)/Min(ThrottleEvents)**)，則當您的工作負載非常尖峰，其中流量在特定日期 （或一天中的時間） 顯著增加，但在其他情況下一直很低時，可能會發生這種情況。在這些情況下，使用[排定的 Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html) 可能會有所幫助。