本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Amazon ElastiCache Well-Architected Lens 成本最佳化支柱
成本最佳化支柱著重於避免不必要的成本。重要主題包括了解和控制錢花費在哪裡、選取最合適的節點類型 (使用支援根據工作負載需求進行資料分層的執行個體)、適切的資源類型數量 (有多少個讀取複本)、分析經過一段時間後的花費，以及因應業務需求進行擴展而不超支。
**Topics**
+ [COST 1：如何找出並追蹤與 ElastiCache 資源相關聯的成本？ 如何制定出各種機制，讓使用者能夠建立、管理及處置建立的資源？](#CostOptimizationPillarCOST1)
+ [COST 2：如何使用持續監控工具來協助您將有關 ElastiCache 資源的成本最佳化？](#CostOptimizationPillarCOST2)
+ [COST 3：是否應該使用支援資料分層的執行個體類型？ 資料分層有何優點？ 何時不適合使用資料分層執行個體？](#CostOptimizationPillarCOST3)
## COST 1：如何找出並追蹤與 ElastiCache 資源相關聯的成本？ 如何制定出各種機制，讓使用者能夠建立、管理及處置建立的資源？
**問題難易度簡介**：若要了解成本指標，就需要有多個團隊參與並且跨團隊協作：軟體工程、資料管理、產品負責人、財務及領導階層。若要找出關鍵的成本驅動因素，就需要參與的各方都了解服務用量控制槓桿與成本管理權衡，這時常成為投入成本最佳化的努力獲得成功與不太成功的關鍵差異。確保您擁有現成的程序和工具可追蹤從開發到生產與淘汰整個過程中所建立的資源，便能幫助您管理 ElastiCache 伴隨的成本。
**問題難易度優點：**若要持續追蹤與工作負載相關聯的所有成本，便需要深入了解包含 ElastiCache 這個元件在內的架構。此外，您應制定成本管理計劃來收集用量，並與您的預算進行比較。
+ **[必要] **建構雲端卓越中心 (CCoE)，並將自行定義、追蹤有關組織的 ElastiCache 使用量指標，以及對指標採取行動等納入，成為其中一篇創始章程。如果 CCoE 已存在且運作正常，請確定它知道如何讀取和追蹤與 ElastiCache 相關的成本。建立資源時，請使用 IAM 角色和政策來確認只有特定團隊和群組能夠執行個體化資源。這樣可確保成本與業務成果相關聯，並從成本的角度建立明確的責任脈絡。
1. CCoE 應識別、定義並發佈成本指標，這些指標會根據分類資料中重要的 ElastiCache 使用量定期 (每月) 更新，例如：
1. 使用的節點類型及其屬性：標準與記憶體最佳化、隨需與預留執行個體、區域和可用區域
1. 環境類型：免費、開發、測試和生產
1. 備份儲存與保留策略
1. 區域內與跨區域的資料傳輸
1. 在 Amazon Outposts 上執行的執行個體
1. CCoE 是由一個跨職能的團隊所組成，其中包括您組織中軟體工程、資料管理、產品團隊、財務和領導團隊的非專屬代表。
**[資源]：**
+ [打造雲端卓越中心](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-laying-the-foundation/cloud-center-of-excellence.html)
+ [Amazon ElastiCache 定價](https://aws.amazon.com/elasticache/pricing/)
+ **[必要] **使用成本分配標籤以較低精細程度來追蹤成本。使用 AWS 成本管理來視覺化、了解和管理一段時間內的 AWS 成本和用量。
1. 使用標籤來整理您的資源，並使用成本分配標籤來詳細追蹤您的 AWS 成本。啟用成本分配標籤後， AWS 會使用成本分配標籤來整理成本分配報告上的資源成本，讓您更輕鬆地分類和追蹤 AWS 成本。 AWS 提供兩種類型的成本分配標籤： AWS 產生的標籤和使用者定義的標籤。 會 AWS 為您定義、建立和套用 AWS 產生的標籤，以及定義、建立和套用使用者定義的標籤。您必須分別啟用這兩種標籤，它們才會顯示在 Cost Management 或成本分配報告中。
1. 使用成本分配標籤來整理 AWS 帳單，以反映您自己的成本結構。若將成本分配標籤新增至 Amazon ElastiCache 中的資源，您就可依資源標籤值將發票上的費用分組，藉此追蹤成本。您可考慮結合標籤，以便更深入追蹤成本的細節。
**[資源]：**
+ [使用 AWS 成本分配標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)
+ [使用成本分配標籤監控成本](Tagging.md)
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)
+ **[最佳] **將 ElastiCache 成本連結到整個組織的指標。
1. 考慮業務指標以及像是延遲等操作指標 - 您的業務模型中有哪些概念是可以跨角色理解的？ 這些指標需要讓組織中越多角色理解越好。
1. 範例 - 同時提供服務的使用者、每項操作和每個使用者的最大和平均延遲、使用者參與度分數、使用者回流率/週、工作階段長度/使用者、放棄率、快取命中率，以及追蹤的索引鍵
**[資源]：**
+ [使用 CloudWatch 指標監控用量](CacheMetrics.md)
+ **[良好] **在使用 ElastiCache 的整個工作負載中，維持指標與成本的最新架構和操作能見度。
1. 了解您的整個解決方案生態系統，ElastiCache 往往是 AWS 其技術集中服務的完整生態系統的一部分，從用戶端到 API Gateway、Redshift 和 QuickSight 報告工具 （例如）。
1. 在您的架構圖上，對應來自用戶端、連線、安全性、記憶體內操作、儲存、資源自動化、資料存取和管理的解決方案元件。每一層都連接到整個解決方案，並且有自己的需求和功能，能夠增添和/或有助您管理整體成本的能力。
1. 您的圖表應包括使用運算、網路、儲存、生命週期政策、指標收集，以及應用程式的操作和運作 ElastiCache 元素
1. 工作負載的需求可能會隨著時間而演進，因此您務必繼續維護並記錄對基礎元件以及主要功能目標的理解程度，以便在工作負載成本管理中保持主動。
1. 為了針對 ElastiCache 制定出有效的成本管理策略，高階主管對於可見性、責任、優先順序和資源的支援對您來說便至關重要。
## COST 2：如何使用持續監控工具來協助您將有關 ElastiCache 資源的成本最佳化？
**問題難易度簡介：**您需要在 ElastiCache 成本和應用程式效能指標之間取得適當的平衡。Amazon CloudWatch 提供關鍵操作指標的可見性，能夠協助您根據需求評估 ElastiCache 資源利用是否過度或不足。從成本最佳化的觀點來看，您需要了解何時過度佈建，並能夠制定出適當的機制來調整 ElastiCache 資源的規模，同時維持您的運作、可用性、彈性和效能需求。
**問題難易度優點：**在理想狀態下，您將佈建足夠的資源來滿足工作負載運作需求，並且沒有資源使用率不足的情況，而導致處於非最佳成本狀態。您需要能夠識別並避免長時間操作規模過大的 ElastiCache 資源。
+ **【必要】 **使用 CloudWatch 監控您的 ElastiCache 叢集，並分析這些指標與您的 AWS Cost Explorer 儀表板有何關聯。
1. ElastiCache 同時提供主機層級指標 （例如 CPU 用量） 和快取引擎軟體特有的指標 （例如快取取得和快取遺漏）。每隔 60 秒會針對每個快取節點測量及發佈這些指標。
1. ElastiCache 效能指標 (CPUUtilization、EngineUtilization、SwapUsage、CurrConnections 及 Evictions) 可指出您需要縱向擴展/縮減 (使用較大/較小的快取節點類型) 或橫向擴展/縮減 (增加/減少碎片)。藉由建立教戰手冊對照表來預估額外成本，以及達到應用程式效能閾值所需的最短和最長時間，從而了解擴展決策的成本影響。
**[資源]：**
+ [使用 CloudWatch 指標監控用量](CacheMetrics.md)
+ [應監控哪些指標？](CacheMetrics.WhichShouldIMonitor.md)
+ [Amazon ElastiCache 定價](https://aws.amazon.com/elasticache/pricing/)
+ **[必要] **了解並記錄您的備份策略和成本影響。
1. 使用 ElastiCache 時，備份會存放在 Amazon S3 中以便長久儲存。您需要了解與您的故障復原能力相關的成本影響。
1. 啟用自動備份，這樣將會刪除保留期限已過的備份檔案。
**[資源]：**
+ [排程自動備份](backups-automatic.md)
+ [Amazon Simple Storage Service 定價](https://aws.amazon.com/s3/pricing/)
+ **[最佳] **針對執行個體使用預留節點，這是為了管理已充分了解並記錄的工作負載成本刻意而為的策略。您必須先為預留節點預付費用，實際費用取決於節點類型及保留時間長度 (一或三年)。此費用遠低於您使用隨需節點時需支付的每小時使用費。
1. 您可能需要使用隨需節點操作 ElastiCache 叢集，直到您收集了足夠的資料來預估預留執行個體的需求。規劃並記錄滿足您的需求所需的資源，並比較各執行個體類型 (隨需與預留) 的預期成本
1. 定期評估可用的新快取節點類型，並從成本和操作指標的角度評估是否合理，以便將您的執行個體機群移轉到新的快取節點類型
## COST 3：是否應該使用支援資料分層的執行個體類型？ 資料分層有何優點？ 何時不適合使用資料分層執行個體？
**問題難易度簡介：**選取適當的執行個體類型不僅會影響效能和服務層面，還會影響財務層面。執行個體類型有各種不同的相關成本。您可能自然而然會選取一個或少數幾個可滿足記憶體中所有儲存需求的大型執行個體類型。但是隨著專案逐漸成熟，這可能會產生重大的成本影響。為了確保選取正確的執行個體類型，就需要定期檢查 ElastiCache 物件閒置時間。
**問題難易度優點：**您應該清楚了解各種不同的執行個體類型對您目前和未來的成本有何影響。邊際或定期工作負載變更不應造成不成比例的成本變更。在工作負載允許的情況下，選擇支援資料分層的執行個體類型就能提供單一儲存價格更實惠的可用儲存。這是因為每個執行個體可用的 SSD 儲存資料分層執行個體可支援的單一執行個體總資料量高出許多。
+ **[必要] **了解資料分層執行個體的限制
1. 僅適用於 ElastiCache for Valkey 或 Redis OSS 叢集。
1. 僅限幾種執行個體類型可支援資料分層。
1. 僅支援適用於 Redis OSS 和更新版本的 ElastiCache 6.2 版
1. 大型項目不會交換至 SSD。超過 128 MiB 的物件會保存在記憶體中。
**[資源]：**
+ [資料分層](data-tiering.md)
+ [Amazon ElastiCache 定價](https://aws.amazon.com/elasticache/pricing/)
+ **[必要] **了解工作負載定期存取的資料庫百分比。
1. 資料分層執行個體非常適合經常存取整個資料集的一小部分，但仍需要快速存取其餘資料的工作負載。換句話說，熱資料與暖資料的比例約為 20：80。
1. 發展叢集層級的物件閒置時間追蹤。
1. 超過 500 Gb 資料量的大型實作就是很好的選擇。
+ **[必要] **了解資料分層執行個體並非某些工作負載的可選項目。
1. 存取較少用的物件會伴隨很小的效能成本，因為這些物件會交換至本機 SSD。如果您的應用程式對回應時間較為敏感，請測試對工作負載的影響。
1. 不適用大多儲存大小超過 128 MiB 之大型物件的快取。
**[資源]：**
+ [限制](data-tiering.md#data-tiering-prerequisites)
+ **[最佳] **預留執行個體類型可支援資料分層。這樣可確保每個執行個體的資料儲存量擁有最低成本。
1. 在您充分了解自己的需求之前，可能需要使用非資料分層執行個體操作 ElastiCache 叢集。
1. 分析您的 ElastiCache 叢集資料使用模式。
1. 建立自動化的工作來定期收集物件閒置時間。
1. 如果您發現有很大百分比 (約 80%) 的物件閒置了一段時間，則視為適合讓您的工作負載記錄調查結果，並建議將叢集遷移到支援資料分層的執行個體。
1. 定期評估可用的新快取節點類型，並從成本和操作指標的角度評估是否合理，以便將您的執行個體機群移轉到新的快取節點類型。
**[資源]：**
+ [OBJECT IDLETIME](https://valkey.io/commands/object-idletime/)
+ [Amazon ElastiCache 定價](https://aws.amazon.com/elasticache/pricing/)