Amazon ElastiCache Well-Architected 的鏡頭性能效率支柱 - Amazon ElastiCache （雷迪OSS斯）
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 的鏡頭性能效率支柱

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

PE 1：如何監控 Amazon ElastiCache 群集的性能？

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

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

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

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

    • 在執行這些測試時監視測 CloudWatch 量結果，以瞭解可用的測量結果，並建立效能基準線。

  • [最佳] 對於 ElastiCache (RedisOSS) 工作負載，請重新命名運算昂貴的命令，例如KEYS，限制使用者在生產叢集上執行封鎖命令的能力。

    • ElastiCache (RedisOSS) 工作負載執行引擎 6.x，可利用角色型存取控制來限制某些命令。透過「 AWS 主控台」建立「使用者」和「使用者群組」CLI，或將「使用者群組」與 ElastiCache (RedisOSS) 叢集關聯，來控制命令的存取。在 Redis OSS 6 中，當RBAC啟用時，我們可以使用「-@dangerous」，它將禁止昂貴的命令KEYS，如 MONITORSORT，等為該用戶。

    • 對於引擎版本 5.x，請使用 ElastiCache (RedisOSS) 叢集rename-commands參數群組上的參數重新命名命令。

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

    • 對於 ElastiCache (RedisOSS) 工作負載，請透過分析慢速記錄來進一步瞭解您的查詢。例如，您可以使用下列命令 redis-cli slowlog get 10 來顯示超出延遲閾值 (預設為 10 秒) 的最後 10 個命令。

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

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

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

  • [資源]：

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

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

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

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

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

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

  • [更好] 利用啟用的 ElastiCache (RedisOSS) 叢集模式來改善延展性。

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

    • 您也可以透過在 ElastiCache (Redis) (已啟用叢集模式OSS) 叢集中的可用碎片之間移動 hashslot 來重新平衡叢集。這樣做有助於更有效率地在可用碎片中分配工作。

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

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

    • 工作負載中的快速鍵可能會影響使用中節點的效能。對於 ElastiCache (RedisOSS) 工作負載，您可以使用是redis-cli --hotkeys否有LFU最大記憶體原則來偵測快速鍵。

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

    • EElastiCache(RedisOSS) 版本 6 支援伺服器協助用戶端快取。這可讓應用程式等待金鑰的變更，然後再進行網路呼叫ElastiCache。

  • [資源]：

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

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

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

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

    [資源]：

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

    [資源]：

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

    [資源]：

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

問題級介紹：ElastiCache （RedisOSS）和 ElastiCache （Memcached）被許多應用程序客戶端支持，實現可能會有所不同。您需要了解現有的網路和連線管理，以分析潛在的效能影響。

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

  • [必要] 主動管理 ElastiCache 叢集的連線。

    • 在應用程式中使用連線集區，可減少因開啟和關閉連線而對叢集造成的額外負荷量。 CloudWatch 使用CurrConnections和監控 Amazon 中的連接行為NewConnections。

    • 適時確實地關閉用戶端連線，以避免洩漏連線。連線管理策略包括確實地關閉未使用的連線，以及設定連線逾時。

    • 針對 Memcached 工作負載保留了用於處理連線的可設定記憶體數量，稱為 memcached_connections_overhead。

  • [較佳] 壓縮大型物件以減少記憶體並改善網路輸送量。

    • 資料壓縮可減少所需的網路輸送量 (Gbps)，但會增加應用程式壓縮和解壓縮資料的工作量。

    • 壓縮還可以減少索引鍵耗用的記憶體數量

    • 請根據您應用程式的需求，考慮壓縮比和壓縮速度之間的權衡。

  • [資源]：

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

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

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

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

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

    • 預設原則會收回具有設定到期時間 (TTL值) 的金鑰，以volatile-lru釋放記憶體。最不常使用的 (LFU) 和最近最少使用的 (LRU) 原則會根據使用情況移除金鑰。

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

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

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

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

  • [資源]：

PE 6：您如何建模並與中的數據進行交互 ElastiCache？

問題級介紹：在ElastiCache 很大程度上應用程序取決於所使用的數據結構和數據模型，但也需要考慮基礎數據存儲（如果存在）。瞭解可用的 ElastiCache (RedisOSS) 資料結構，並確保您使用最適合您需求的資料結構。

問題層級的好處：中的資料模型ElastiCache 具有多個層級，包括應用程式使用案例、資料類型以及資料元素之間的關係。此外，每個 ElastiCache (RedisOSS) 資料類型和命令都有自己詳細記錄的效能簽章。

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

    [資源]：

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

    [資源]：

  • [最佳] 用於APIs取得叢集中資料模型的GUI可見度。

    [資源]：

PE 7：如何在 Amazon ElastiCache 集群中記錄運行緩慢的命令？

問題難易度簡介：透過擷取、彙總和通知長時間執行的命令，達到效能調整效益。透過瞭解命令執行所需的時間，您可以判斷哪些命令會導致效能不佳，以及阻止引擎以最佳方式執行的命令。 ElastiCache （RedisOSS）也有能力將這些信息轉發給 Amazon CloudWatch 或 Amazon Kinesis Data Firehose。

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

  • [必要] Amazon ElastiCache (RedisOSS) 執行 6.0 版或更新版本的引擎，且已在叢集上啟用正確設定的參數群組和SLOWLOG記錄。

    • 必要的參數只有在引擎版本相容性設定為 Redis 6.0 或更高OSS版本時才可用。

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

    • 變更會立即生效。

  • [最佳] 利用 CloudWatch 或 Kinesis Data Firehose 功能。

    • 使用 CloudWatch日誌見解和 Amazon 簡單通知服務的 CloudWatch篩選和警示功能來實現效能監控和事件通知。

    • 使用 Kinesis Data Firehose 的串流功能，將SLOWLOG記錄檔存檔到永久儲存空間，或觸發自動化叢集參數調整。

    • 確定是否JSON或普通TEXT格式最適合您的需求。

    • 提供發佈至 CloudWatch Kinesis Data Firehose 的IAM權限。

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

    • 此參數決定命令可以在 Redis OSS 引擎中執行的時間長度，然後再將其記錄為緩慢執行的命令。預設值為 10,000 微秒 (10 毫秒)。對於某些工作負載而言，預設值可能太高。

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

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

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

    • 預設值適用於大多數的工作負載。如果需要透過SLOWLOG指令從 redis-cli 在展開的時間視窗中分析資料，請考慮增加此值。這允許更多命令保留在 Redis OSS 內存中。

      如果您要將SLOWLOG資料傳送至 CloudWatch 記錄檔或 Kinesis Data Firehose，資料將會保留下來，並可在 ElastiCache 系統外部進行分析，減少在 Redis 記憶體中儲存大量緩慢執行命令的需求。OSS

  • [資源]：

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

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

問題層級的好處：瞭解並規劃工作負載的尖峰情況，可確保增強快取效能和業務連續性。 ElastiCache (RedisOSS) Auto Scaling 會持續監控您的 CPU /Memory 使用率，以確保叢集以所需的效能等級運作。

  • [必要] 為 ElastiCache (RedisOSS) 啟動叢集時：

    1. 確定已啟用叢集模式

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

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

    [資源]：

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

    [資源]：

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

    [資源]：

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

    [資源]：