Amazon ElastiCache Well-Architected Lens 效能效率支柱 - Amazon ElastiCache
PE 1：如何監控 Amazon ElastiCache 叢集的效能？PE 2：您如何在 ElastiCache 叢集節點間分發工作？PE 3：針對快取工作負載，如何追蹤和報告快取的有效性和效能？ PE 4：如何利用您的工作負載讓網路資源和連線得到最佳運用？PE 5：如何管理刪除和/或移出索引鍵？PE 6：如何建立模型並與 中的資料互動 ElastiCache？ PE 7：如何在 Amazon ElastiCache 叢集中記錄慢速執行的命令？PE8：Auto Scaling 如何協助提高ElastiCache 叢集的效能？

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

Amazon ElastiCache Well-Architected Lens 效能效率支柱

效能效率支柱著重於有效率地使用 IT 和運算資源。重要主題包括根據工作負載需求選取適當的資源類型和大小、監控效能，以及做出明智的決策，以便隨著業務需求的發展維持效率。

PE 1：如何監控 Amazon ElastiCache 叢集的效能？

問題難易度簡介：藉由了解現有的監控指標，您就能識別目前的使用率。適當監控有助於識別影響叢集效能的潛在瓶頸。

問題難易度優點：了解與叢集相關聯的指標有助於引導最佳化技術，進而降低延遲並增加輸送量。

  • [必要] 使用工作負載的子集進行基準效能測試。

    • 您應該使用像是負載測試這類機制來監控實際工作負載的效能。

    • 在執行這些測試時監控 CloudWatch 指標，以了解可用的指標，並建立效能基準。

  • 【最佳】 對於 ElastiCache （Redis OSS） 工作負載，重新命名運算上昂貴的命令，例如 KEYS，以限制使用者在生產叢集上執行封鎖命令的能力。

    • ElastiCache （Redis OSS） 執行引擎 6.x 的工作負載，可以利用角色型存取控制來限制特定命令。使用 AWS 主控台或 建立使用者和使用者群組CLI，並將使用者群組與 ElastiCache （Redis OSS） 叢集建立關聯，即可控制對命令的存取。在 Redis OSS 6 中，RBAC當 啟用時，我們可以使用 "-@dangerous"，而且會不允許該使用者使用昂貴的命令MONITOR，例如 KEYS、SORT、 等。

    • 對於引擎 5.x 版，請使用 ElastiCache （Redis OSS） 叢集參數群組上的 rename-commands 參數重新命名命令。

  • [較佳] 分析緩慢的查詢並尋找最佳化技術。

    • 對於 ElastiCache （Redis OSS） 工作負載，請分析慢速日誌，進一步了解您的查詢。例如，您可以使用下列命令 valkey-cli slowlog get 10 來顯示超出延遲閾值 (預設為 10 秒) 的最後 10 個命令。

    • 某些查詢可以使用複雜的 ElastiCache （RedisOSS） 資料結構更有效率地執行。舉例來說，針對數值樣式範圍的查詢，應用程式可以使用排序集來實作簡單的數值索引。管理這些索引可以減少對資料集執行掃描的次數，並且以更高的效能效率傳回資料。

    • 對於 ElastiCache （Redis OSS） 工作負載， redis-benchmark提供簡單的介面，用於使用使用者定義的輸入來測試不同命令的效能，例如用戶端數量和資料大小。

    • 由於 Memcached 僅支援簡單的索引鍵層級命令，因此請考慮建置其他索引鍵作為索引，以避免反覆查看索引鍵空間來處理用戶端查詢。

  • [資源]：

PE 2：您如何在 ElastiCache 叢集節點間分發工作？

問題層級簡介：應用程式連線至 Amazon ElastiCache 節點的方式可能會影響叢集的效能和可擴展性。

問題難易度優點：正確使用叢集中的可用節點，可確保將工作分配到可用的資源。以下技術也有助於避免資源閒置。

  • 【必要】 讓用戶端連線到適當的 ElastiCache 端點。

    • ElastiCache （Redis OSS） 會根據使用的叢集模式實作不同的端點。對於啟用叢集模式， ElastiCache 將提供組態端點。對於停用的叢集模式， ElastiCache 提供主要端點，通常用於寫入，以及用於平衡複本讀取的讀取器端點。正確實作這些端點可提升效能並且更輕鬆地擴展操作。除非有特定需求，否則避免連線到個別節點端點。

    • 對於多節點 Memcached 叢集， ElastiCache 提供啟用 Auto Discovery 的組態端點。建議使用雜湊演算法將工作平均分配到各個快取節點。許多 Memcached 用戶端程式庫會實作一致的雜湊。檢查您使用的程式庫文件，查看其是否支援一致性雜湊以及其實作方式。您可以在這裡找到有關實做這些功能的詳細資訊。

  • 【更好的】 利用啟用的 ElastiCache （Redis OSS） 叢集模式來改善可擴展性。

    • ElastiCache （Redis OSS） （啟用叢集模式） 叢集支援線上擴展操作 （輸出/輸入和上/下），以協助在碎片之間動態分發資料。使用組態端點可確保您的叢集感知用戶端能夠因應叢集拓撲中的變更進行調整。

    • 您也可以在 ElastiCache （Redis OSS） （啟用叢集模式） 叢集中的可用碎片之間移動雜湊區，以重新平衡叢集。這樣做有助於更有效率地在可用碎片中分配工作。

  • [較佳] 實施策略來識別和修復工作負載中的快速鍵。

    • 考慮多維度 Valkey 或 Redis OSS資料結構的影響，例如清單、串流、集等。這些資料結構儲存在單一金鑰中，這些金鑰位於單一節點上。相當大型的多維度索引鍵可能比其他資料類型利用更多的網路容量和記憶體，並且可能造成該節點的使用率不成比例。您的工作負載設計應盡可能將資料存取分散到多個獨立的索引鍵。

    • 工作負載中的快速鍵可能會影響使用中節點的效能。對於 ElastiCache （Redis OSS） 工作負載，valkey-cli --hotkeys如果已制定LFU最大記憶體政策，您可以使用 偵測快速鍵。

    • 請考慮將快速鍵複寫到多個節點，讓分配到各節點的存取權更平均。此方法需要用戶端寫入多個主要節點 （Valkey 或 Redis OSS節點本身不提供此功能），並維護除了原始金鑰名稱之外要讀取的金鑰名稱清單。

    • ElastiCache 搭配 Valkey 7.2 及更高版本，以及 Redis 第 6 版及更高OSS版本，支援伺服器輔助用戶端快取。這可讓應用程式等待變更金鑰，然後再將網路呼叫回 ElastiCache。

  • [資源]：

PE 3：針對快取工作負載，如何追蹤和報告快取的有效性和效能？

問題層級簡介：快取是 上常見的工作負載 ElastiCache ，您必須了解如何管理快取的有效性和效能。

問題難易度優點：您的應用程式可能會出現效能遲緩的跡象。假如能夠使用快取專用指標做出明智的決策來提高應用程式效能，這點對於快取工作負載而言至關重要。

  • [必要] 測量並追蹤經過一段時間的快取命中率。快取的效率是由其「快取命中率」所決定。快取命中率的計算定義是索引鍵命中總數除以命中加未命中總數。命中率越接近 1，表示快取越有效。快取未命中數量是造成快取命中率低的原因。快取中找不到請求的索引鍵時，就會產生快取未命中數。快取中沒有某個索引鍵是因為該索引鍵已移出或刪除、已過期或不曾存在。了解索引鍵為什麼不在快取中，並制定適當的策略將其納入快取中。

    [資源]：

  • 【必要】 測量並收集應用程式快取效能，以及延遲和CPU使用率值，以了解您是否需要調整您的 time-to-live 或其他應用程式元件。 為每個資料結構 ElastiCache 提供彙總延遲的一組 CloudWatch 指標。這些延遲指標是使用來自 ElastiCache （Redis OSS） INFO命令的命令統計資料計算，不包含網路和 I/O 時間。這只是 ElastiCache （Redis OSS） 處理操作所耗用的時間。

    [資源]：

  • [最佳] 選擇最合乎您需要的快取策略。快取未命中數量是造成快取命中率低的原因。如果您的工作負載設計是維持低快取未命中數量 (例如即時通訊)，那麼最好檢閱您的快取策略，並對工作負載套用最適當的解決方案 (例如查詢檢測) 來測量記憶體和效能。您實際用來填入和維護快取的策略，取決於您的用戶端需要快取的資料，以及該資料的存取模式。例如，您不太可能對串流應用程式上的個人化推薦和熱門新聞報導採用相同的策略。

    [資源]：

PE 4：如何利用您的工作負載讓網路資源和連線得到最佳運用？

問題層級簡介：ElastiCache 許多應用程式用戶端支援 （Redis OSS） 和 ElastiCache （Memcached），且實作可能會有所不同。您需要了解現有的網路和連線管理，以分析潛在的效能影響。

問題難易度優點：有效運用網路資源可改善叢集的效能效率。下列建議可減少網路需求，並改善叢集延遲和輸送量。

PE 5：如何管理刪除和/或移出索引鍵？

問題層級簡介：工作負載有不同的需求，以及當叢集節點接近記憶體耗用限制時的預期行為。 ElastiCache （Redis OSS） 有不同的政策來處理這些情況。

問題難易度優點：適當管理可用記憶體並且了解移出政策，將有助於確保在超過執行個體記憶體限制時，能夠察覺到叢集行為。

  • [必要] 檢測資料存取權以評估要套用的政策。找出適當的最大記憶體政策，以控制是否要在叢集上執行移出，以及移出的方式。

    • 當達到叢集上的最大記憶體耗用量，而且已設有允許移出的政策時，就會進行移除。在此情況下，叢集的行為會取決於指定的移出政策。此政策可以使用 ElastiCache （Redis OSS） 叢集參數群組maxmemory-policy上的 進行管理。

    • 預設政策會逸出具有設定過期時間 （TTL 值） 的金鑰來volatile-lru釋放記憶體。最少常用 （LFU） 和最少最近使用 （LRU） 的政策會根據用量移除金鑰。

    • 對於 Memcached 工作負載，會有一個預設LRU政策來控制每個節點上的驅逐。您可以使用 Amazon 上的 Evictions 指標來監控 Amazon ElastiCache 叢集上的驅逐次數 CloudWatch。

  • [較佳] 將刪除行為標準化，就可控制對叢集的效能影響，進而避免非預期的效能瓶頸發生。

    • 對於 ElastiCache （Redis OSS） 工作負載，從叢集明確移除金鑰時， UNLINK 就像 DEL：它會移除指定的金鑰。然而，該命令會在不同的執行緒中執行實際的記憶體回收，因此不會封鎖，但 DEL 會封鎖。實際的移除操作會在之後以非同步方式進行。

    • 對於 ElastiCache （Redis OSS） 6.x 工作負載，可以使用 lazyfree-lazy-user-del 參數在參數群組中修改DEL命令的行為。

  • [資源]：

PE 6：如何建立模型並與 中的資料互動 ElastiCache？

問題層級簡介： ElastiCache 高度依賴於資料結構和使用的資料模型的應用程式，但還需要考慮基礎資料存放區 （如果有）。了解可用的 ElastiCache （Redis OSS） 資料結構，並確保您使用最適合您需求的資料結構。

問題層級優點： 中的資料建模ElastiCache 有數個層，包括應用程式使用案例、資料類型和資料元素之間的關係。此外，每個 ElastiCache （Redis OSS） 資料類型和命令都有自己的妥善記錄效能簽章。

  • [最佳] 最佳實務是減少意外覆寫資料的情況。使用盡可能減少索引鍵名稱重疊的命名慣例。資料結構的慣用命名是使用像是 APPNAME:CONTEXT:ID 這類階層方法，例如 ORDER-APP:CUSTOMER:123。

    [資源]：

  • 【最佳】 ElastiCache （Redis OSS） 命令具有 Big O 記號定義的時間複雜性。命令的這種時間複雜度是其影響的演算/數學表示法。當您在應用程式中引入新的資料類型時，需仔細查看相關命令的時間複雜度。時間複雜度為 O(1) 的命令在時間上是恆定的，並不取決於輸入大小，但是時間複雜度為 O(N) 的命令在時間上是線性的，因此會受輸入大小的影響。由於 ElastiCache （Redis OSS） 的單一螺紋設計，大量的高時間複雜性操作將導致效能降低和潛在的操作逾時。

    [資源]：

  • 【最佳】 使用 APIs來取得叢集中資料模型的GUI可見性。

    [資源]：

PE 7：如何在 Amazon ElastiCache 叢集中記錄慢速執行的命令？

問題難易度簡介：透過擷取、彙總和通知長時間執行的命令，達到效能調整效益。透過了解執行命令所需的時間，您可以判斷哪些命令會導致效能不佳，以及封鎖引擎以最佳方式執行的命令。 ElastiCache （Redis OSS） 也能夠將此資訊轉送至 Amazon CloudWatch 或 Amazon Kinesis Data Firehose 。

問題難易度優點：針對慢速命令記錄到專用的永久位置並提供通知事件，有助於進行詳細的效能分析，並可用於觸發自動化事件。

  • 【必要】 執行引擎 6.0 版或更新版本的 Amazon ElastiCache （Redis OSS），在叢集上啟用正確設定的參數群組和SLOWLOG記錄。

    • 只有在引擎版本相容性設定為 Valkey 7.2 及更高版本，或 Redis 6.0 版或更高OSS版本時，才能使用所需的參數。

    • SLOWLOG 當命令的伺服器執行時間超過指定的值時，就會發生記錄。叢集的行為取決於相關聯的參數群組參數，也就是 slowlog-log-slower-than 和 slowlog-max-len。

    • 變更會立即生效。

  • 【最佳】 利用 CloudWatch 或 Kinesis Data Firehose 功能。

    • 使用 CloudWatch、 CloudWatchLogs Insights 和 Amazon Simple Notification Services 的篩選和警示功能來實現效能監控和事件通知。

    • 使用 Kinesis Data Firehose 的串流功能將SLOWLOG日誌封存至永久儲存體，或觸發自動叢集參數調校。

    • 判斷 JSON或 純TEXT格式是否最符合您的需求。

    • 提供發佈至 CloudWatch 或 Kinesis Data Firehose 的IAM許可。

  • [較佳] 將 slowlog-log-slower-than 設定為預設值以外的值。

    • 此參數決定命令在記錄為慢速執行命令之前，可在 Valkey 或 Redis OSS引擎內執行多久。預設值為 10,000 微秒 (10 毫秒)。對於某些工作負載而言，預設值可能太高。

    • 根據應用程式需求和測試結果，決定更合乎您工作負載的值；不過，太低的值可能會產生過多資料。

  • [較佳] 保留 slowlog-max-len 的預設值。

    • 此參數會決定在任何指定時間，Valkey 或 Redis OSS記憶體中擷取多少慢速執行命令的上限。值為 0 會有效停用擷取。值越高，記憶體中儲存的項目就越多，因而減少重要資訊在檢閱之前就遭到移出的情形。預設值為 128。

    • 預設值適用於大多數的工作負載。如果需要透過 SLOWLOG命令從 valkey-cli 擴充的時段中分析資料，請考慮增加此值。這允許更多命令保留在 Valkey 或 Redis OSS記憶體中。

      如果您要將SLOWLOG資料發射至 CloudWatch Logs 或 Kinesis Data Firehose，資料會保留，而且可以在 ElastiCache 系統外部進行分析，減少在 Valkey 或 Redis OSS記憶體中存放大量慢速執行命令的需求。

  • [資源]：

PE8：Auto Scaling 如何協助提高ElastiCache 叢集的效能？

問題層級簡介：透過實作 Valkey 或 Redis OSS自動擴展功能，您的 ElastiCache 元件可以隨著時間調整，以自動增加或減少所需的碎片或複本。藉由實作目標追蹤或排程的擴展政策就能達到此目的。

問題層級優點：了解和規劃工作負載中的峰值可確保增強的快取效能和業務連續性。 ElastiCache （Redis OSS） Auto Scaling 會持續監控您的 CPU/Memory 使用率，以確保您的叢集以所需的效能層級運作。

  • 【必要】 啟動 ElastiCache （Redis ） 的叢集時OSS：

    1. 確定已啟用叢集模式

    2. 確定執行個體屬於支援自動擴展的特定類型和大小系列

    3. 確保叢集未在全域資料存放區、Outposts 或 Local Zones 中執行

    [資源]：

  • [最佳] 確認您的工作負載為大量讀取或大量寫入，以定義擴展政策。為了獲得最佳效能，請使用單獨一個追蹤指標。建議您避免針對每個維度實施多項政策，因為自動擴展政策會在命中目標時橫向擴展，但只有在所有目標追蹤政策都準備好縮減時才會縮減。

    [資源]：

  • [最佳] 隨著時間監控效能可幫助您偵測到在特定時間點監控時，可能無法察覺的工作負載變更。您可以分析叢集使用率在四週期間內的對應CloudWatch 指標，以判斷目標值閾值。如果您仍不確定要選擇哪個值，建議從支援的最小預先定義指標值開始。

    [資源]：

  • [較佳] 我們建議您使用預期的最小和最大工作負載來測試應用程式，藉此找出叢集制定擴展政策和減輕可用性問題所需的準確碎片/複本數量。

    [資源]：