Amazon ElastiCache Well-Architected Lens 成本最佳化支柱 - Amazon ElastiCache
COST 1：如何識別和追蹤與 ElastiCache資源相關的成本？ 如何制定出各種機制，讓使用者能夠建立、管理及處置建立的資源？COST 2：如何使用持續監控工具來協助您最佳化與 ElastiCache 資源相關聯的成本？COST 3：您是否應使用支援資料分層的執行個體類型？ 資料分層有何優點？ 何時不適合使用資料分層執行個體？

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

Amazon ElastiCache Well-Architected Lens 成本最佳化支柱

成本最佳化支柱著重於避免不必要的成本。重要主題包括了解和控制錢花費在哪裡、選取最合適的節點類型 (使用支援根據工作負載需求進行資料分層的執行個體)、適切的資源類型數量 (有多少個讀取複本)、分析經過一段時間後的花費，以及因應業務需求進行擴展而不超支。

COST 1：如何識別和追蹤與 ElastiCache資源相關的成本？ 如何制定出各種機制，讓使用者能夠建立、管理及處置建立的資源？

問題難易度簡介：若要了解成本指標，就需要有多個團隊參與並且跨團隊協作：軟體工程、資料管理、產品負責人、財務及領導階層。若要找出關鍵的成本驅動因素，就需要參與的各方都了解服務用量控制槓桿與成本管理權衡，這時常成為投入成本最佳化的努力獲得成功與不太成功的關鍵差異。確保您擁有適當的程序和工具，以追蹤從開發到生產和淘汰期間建立的資源，可協助您管理與 相關的成本ElastiCache。

問題層級優點：持續追蹤與工作負載相關的所有成本需要深入了解包含 ElastiCache 作為其元件之一的架構。此外，您應制定成本管理計劃來收集用量，並與您的預算進行比較。

  • 【必要】 建立 Cloud Center of Excellence （CCoE） 及其創始章程之一，以擁有定義、追蹤和針對組織ElastiCache 用量的指標採取行動。如果CCoE存在 和 函數，請確保它知道如何讀取和追蹤與 相關聯的成本 ElastiCache。建立資源時，請使用IAM角色和政策來驗證只有特定團隊和群組可以實現資源。這樣可確保成本與業務成果相關聯，並從成本的角度建立明確的責任脈絡。

    1. CCoE 應識別、定義和發佈每月定期更新的成本指標，這些指標圍繞類別資料中的金鑰 ElastiCache 用量，例如：

      1. 使用的節點類型及其屬性：標準與記憶體最佳化、隨需與預留執行個體、區域和可用區域

      2. 環境類型：免費、開發、測試和生產

      3. 備份儲存與保留策略

      4. 區域內與跨區域的資料傳輸

      5. 在 Amazon Outposts 上執行的執行個體

    2. CCoE 由跨職能團隊組成，其中包含組織中軟體工程、資料管理、產品團隊、財務和領導團隊的非專屬代表。

    [資源]：

  • [必要] 使用成本分配標籤以較低精細程度來追蹤成本。使用 AWS 成本管理來視覺化、了解和管理一段時間內的 AWS 成本和用量。

    1. 使用標籤來整理您的資源，並使用成本分配標籤來詳細追蹤您的 AWS 成本。啟用成本分配標籤後， AWS 會使用成本分配標籤來整理成本分配報告中的資源成本，讓您更輕鬆地分類和追蹤 AWS 成本。 AWS 提供兩種類型的成本分配標籤、 AWS 產生的標籤和使用者定義標籤。為您 AWS 定義、建立和套用 AWS 產生的標籤，以及定義、建立和套用使用者定義標籤。您必須分別啟用這兩種標籤，它們才會顯示在 Cost Management 或成本分配報告中。

    2. 使用成本分配標籤來組織 AWS 帳單，以反映您自己的成本結構。當您將成本分配標籤新增至 Amazon 中的資源時 ElastiCache，您將能夠透過將發票上的費用依資源標籤值分組來追蹤成本。您可考慮結合標籤，以便更深入追蹤成本的細節。

    [資源]：

  • 【最佳】 將 ElastiCache 成本連接到跨組織達到的指標。

    1. 考慮業務指標以及像是延遲等操作指標 - 您的業務模型中有哪些概念是可以跨角色理解的？ 這些指標需要讓組織中越多角色理解越好。

    2. 範例 - 同時提供服務的使用者、每項操作和每個使用者的最大和平均延遲、使用者參與度分數、使用者回流率/週、工作階段長度/使用者、放棄率、快取命中率，以及追蹤的索引鍵

    [資源]：

  • 【良好】 使用 的整個工作負載，保持 up-to-date指標和成本的架構和操作可見性 ElastiCache。

    1. 了解您的整個解決方案生態系統， ElastiCache 傾向成為 AWS 其技術集中服務的完整生態系統的一部分，從用戶端到 API Gateway、Redshift 和 QuickSight 報告工具 （例如）。

    2. 在您的架構圖上，對應來自用戶端、連線、安全性、記憶體內操作、儲存、資源自動化、資料存取和管理的解決方案元件。每一層都連接到整個解決方案，並且有自己的需求和功能，能夠增添和/或有助您管理整體成本的能力。

    3. 您的圖表應包括使用運算、聯網、儲存、生命週期政策、指標收集，以及應用程式的操作和功能 ElastiCache 元素

    4. 工作負載的需求可能會隨著時間而演進，因此您務必繼續維護並記錄對基礎元件以及主要功能目標的理解程度，以便在工作負載成本管理中保持主動。

    5. 高階主管對可見性、責任、優先順序和資源的支援，對於您擁有有效的 成本管理策略至關重要 ElastiCache。

COST 2：如何使用持續監控工具來協助您最佳化與 ElastiCache 資源相關聯的成本？

問題層級簡介：您需要在 ElastiCache 成本和應用程式效能指標之間取得適當的平衡。Amazon CloudWatch 提供關鍵操作指標的可見性，可協助您評估 ElastiCache 資源是否過度使用或不足，以滿足您的需求。從成本最佳化的角度來看，您需要了解何時過度佈建，並能夠開發適當的機制來調整資源大小 ElastiCache，同時維持營運、可用性、彈性和效能需求。

問題難易度優點：在理想狀態下，您將佈建足夠的資源來滿足工作負載運作需求，並且沒有資源使用率不足的情況，而導致處於非最佳成本狀態。您需要能夠識別和避免長時間操作過大 ElastiCache 的資源。

  • 【必要】 使用 CloudWatch 來監控ElastiCache 叢集，並分析這些指標與您的 AWS Cost Explorer 儀表板有何關聯。

    1. ElastiCache 同時提供主機層級指標 （例如，CPU用量） 和快取引擎軟體特有的指標 （例如，快取取得和快取遺失）。每隔 60 秒會針對每個快取節點測量及發佈這些指標。

    2. ElastiCache 效能指標 （CPUUtilization EngineUtilization、SwapUsage CurrConnections、 和 Evictions） 可能表示您需要向上/向下擴展 （使用較大/較小快取節點類型） 或輸入/輸出 （新增更多/較少碎片）。藉由建立教戰手冊對照表來預估額外成本，以及達到應用程式效能閾值所需的最短和最長時間，從而了解擴展決策的成本影響。

    [資源]：

  • [必要] 了解並記錄您的備份策略和成本影響。

    1. 使用 ElastiCache時，備份會儲存在 Amazon S3 中，可提供持久的儲存。您需要了解與您的故障復原能力相關的成本影響。

    2. 啟用自動備份，這樣將會刪除保留期限已過的備份檔案。

    [資源]：

  • [最佳] 針對執行個體使用預留節點，這是為了管理已充分了解並記錄的工作負載成本刻意而為的策略。您必須先為預留節點預付費用，實際費用取決於節點類型及保留時間長度 (一或三年)。此費用遠低於您使用隨需節點時需支付的每小時使用費。

    1. 您可能需要使用隨需節點操作 ElastiCache 叢集，直到您已收集足夠的資料來估計預留執行個體需求為止。規劃並記錄滿足您的需求所需的資源，並比較各執行個體類型 (隨需與預留) 的預期成本

    2. 定期評估可用的新快取節點類型，並從成本和操作指標的角度評估是否合理，以便將您的執行個體機群移轉到新的快取節點類型

COST 3：您是否應使用支援資料分層的執行個體類型？ 資料分層有何優點？ 何時不適合使用資料分層執行個體？

問題難易度簡介：選取適當的執行個體類型不僅會影響效能和服務層面，還會影響財務層面。執行個體類型有各種不同的相關成本。您可能自然而然會選取一個或少數幾個可滿足記憶體中所有儲存需求的大型執行個體類型。但是隨著專案逐漸成熟，這可能會產生重大的成本影響。確保選取正確的執行個體類型需要定期檢查 ElastiCache 物件閒置時間。

問題難易度優點：您應該清楚了解各種不同的執行個體類型對您目前和未來的成本有何影響。邊際或定期工作負載變更不應造成不成比例的成本變更。在工作負載允許的情況下，選擇支援資料分層的執行個體類型就能提供單一儲存價格更實惠的可用儲存。由於每個執行個體可用的SSD儲存資料分層執行個體支援更高的每個執行個體總資料量。

  • [必要] 了解資料分層執行個體的限制

    1. 僅適用於 ElastiCache （Redis OSS） 叢集。

    2. 僅限幾種執行個體類型可支援資料分層。

    3. 僅支援 ElastiCache （Redis OSS） 6.2 版及更新版本

    4. 大型項目不會切換為 SSD。超過 128 MiB 的物件會保存在記憶體中。

    [資源]：

  • [必要] 了解工作負載定期存取的資料庫百分比。

    1. 資料分層執行個體非常適合經常存取整個資料集的一小部分，但仍需要快速存取其餘資料的工作負載。換句話說，熱資料對暖資料的比例約為 20:80。

    2. 發展叢集層級的物件閒置時間追蹤。

    3. 超過 500 Gb 資料量的大型實作就是很好的選擇。

  • [必要] 了解資料分層執行個體並非某些工作負載的可選項目。

    1. 存取較不常用的物件需要很小的效能成本，因為這些物件會換成本機 SSD。如果您的應用程式對回應時間較為敏感，請測試對工作負載的影響。

    2. 不適用大多儲存大小超過 128 MiB 之大型物件的快取。

    [資源]：

  • [最佳] 預留執行個體類型可支援資料分層。這樣可確保每個執行個體的資料儲存量擁有最低成本。

    1. 您可能需要使用非資料分層執行個體操作 ElastiCache 叢集，直到您更了解您的需求為止。

    2. 分析 ElastiCache 叢集的資料用量模式。

    3. 建立自動化的工作來定期收集物件閒置時間。

    4. 如果您發現有很大百分比 (約 80%) 的物件閒置了一段時間，則視為適合讓您的工作負載記錄調查結果，並建議將叢集遷移到支援資料分層的執行個體。

    5. 定期評估可用的新快取節點類型，並從成本和操作指標的角度評估是否合理，以便將您的執行個體機群移轉到新的快取節點類型。

    [資源]：