本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Amazon ElastiCache Well-Architected Lens 效能效率支柱
效能效率支柱著重於有效率地使用 IT 和運算資源。重要主題包括根據工作負載需求選取適當的資源類型和大小、監控效能，以及做出明智的決策，以便隨著業務需求的發展維持效率。
**Topics**
+ [PE 1：如何監控 Amazon ElastiCache 叢集的效能？](#PerformanceEfficiencyPillarPE1)
+ [PE 2：如何將工作分配到各個 ElastiCache 叢集節點？](#PerformanceEfficiencyPillarPE2)
+ [PE 3：針對快取工作負載，如何追蹤和報告快取的有效性和效能？](#PerformanceEfficiencyPillarPE3)
+ [PE 4：如何利用您的工作負載讓網路資源和連線得到最佳運用？](#PerformanceEfficiencyPillarPE4)
+ [PE 5：如何管理刪除和/或移出索引鍵？](#PerformanceEfficiencyPillarPE5)
+ [PE 6：如何在 ElastiCache 中建立資料模型並與資料互動？](#PerformanceEfficiencyPillarPE6)
+ [PE 7：如何記錄 Amazon ElastiCache 叢集中執行緩慢的命令？](#PerformanceEfficiencyPillarPE7)
+ [PE8：自動擴展功能如何協助提高 ElastiCache 叢集的效能？](#PerformanceEfficiencyPillarPE8)
## PE 1：如何監控 Amazon ElastiCache 叢集的效能？
**問題難易度簡介：**藉由了解現有的監控指標，您就能識別目前的使用率。適當監控有助於識別影響叢集效能的潛在瓶頸。
**問題難易度優點：**了解與叢集相關聯的指標有助於引導最佳化技術，進而降低延遲並增加輸送量。
+ **[必要] **使用工作負載的子集進行基準效能測試。
+ 您應該使用像是負載測試這類機制來監控實際工作負載的效能。
+ 在執行這些測試的同時監控 CloudWatch 指標，便能對可用的指標有所了解，並且建立效能基準。
+ **【最佳】 **對於 ElastiCache for Valkey 和 Redis OSS 工作負載，重新命名運算上昂貴的命令，例如 `KEYS`，以限制使用者在生產叢集上執行封鎖命令的能力。
+ 執行引擎 6.x for Redis OSS 的 ElastiCache 工作負載可以利用角色型存取控制來限制特定命令。使用AWS主控台或 CLI 建立使用者和使用者群組，並將使用者群組與叢集建立關聯，即可控制對命令的存取。在 Redis OSS 6 中，啟用 RBAC 時，我們可以使用 "-@dangerous"，而且會不允許該使用者使用昂貴的命令，例如 KEYS、MONITOR、SORT 等。
+ 對於引擎 5.x 版，請使用叢集`rename-commands`參數群組上的 參數重新命名命令。
+ **[較佳]** 分析緩慢的查詢並尋找最佳化技術。
+ 對於 ElastiCache for Valkey 和 Redis OSS 工作負載，請透過分析慢速日誌進一步了解您的查詢。例如，您可以使用下列命令`valkey-cli slowlog get 10`來顯示超過延遲閾值的最後 10 個命令 （預設為 10 毫秒）。
+ 某些查詢可以使用複雜的 ElastiCache for Valkey 和 Redis OSS 資料結構更有效率地執行。舉例來說，針對數值樣式範圍的查詢，應用程式可以使用排序集來實作簡單的數值索引。管理這些索引可以減少對資料集執行掃描的次數，並且以更高的效能效率傳回資料。
+ 對於 ElastiCache for Valkey 和 Redis OSS 工作負載， `redis-benchmark`提供簡單的界面，以使用使用者定義的輸入來測試不同命令的效能，例如用戶端數量和資料大小。
+ 由於 Memcached 僅支援簡單的索引鍵層級命令，因此請考慮建置其他索引鍵作為索引，以避免反覆查看索引鍵空間來處理用戶端查詢。
+ **[資源]：**
+ [使用 CloudWatch 指標監控用量](CacheMetrics.md)
+ [使用 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Valkey 和 Redis OSS 特定參數](ParameterGroups.Engine.md#ParameterGroups.Redis)
+ [SLOWLOG](https://valkey.io/commands/slowlog/)
+ [ 基準測試](https://valkey.io/topics/benchmark/)
## PE 2：如何將工作分配到各個 ElastiCache 叢集節點？
**問題難易度簡介：**應用程式連線到 Amazon ElastiCache 節點的方式可能會影響叢集的效能和可擴展性。
**問題難易度優點：**正確使用叢集中的可用節點，可確保將工作分配到可用的資源。以下技術也有助於避免資源閒置。
+ **[必要] **讓用戶端連線到適當的 ElastiCache 端點。
+ ElastiCache for Valkey 和 Redis OSS 會根據使用的叢集模式實作不同的端點。若叢集模式已啟用，ElastiCache 會提供組態端點。若叢集模式已停用，ElastiCache 會提供主要端點 (通常用於寫入) 和讀取器端點 (用於平衡複本之間的讀取)。正確實作這些端點可提升效能並且更輕鬆地擴展操作。除非有特定需求，否則避免連線到個別節點端點。
+ 針對多節點 Memcached 叢集，ElastiCache 提供了可進行自動探索的設定端點。建議使用雜湊演算法將工作平均分配到各個快取節點。許多 Memcached 用戶端程式庫會實作一致的雜湊。檢查您使用的程式庫文件，查看其是否支援一致性雜湊以及其實作方式。您可以在[這裡](BestPractices.LoadBalancing.md)找到有關實做這些功能的詳細資訊。
+ **【更佳】 **利用 ElastiCache for Valkey 和 Redis OSS 叢集模式啟用的叢集來改善可擴展性。
+ ElastiCache for Valkey 和 Redis OSS （啟用叢集模式） 叢集支援[線上擴展操作](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online) （輸出/輸入和上/下），以協助在碎片之間動態分配資料。使用組態端點可確保您的叢集感知用戶端能夠因應叢集拓撲中的變更進行調整。
+ 您也可以在 ElastiCache for Valkey 和 Redis OSS （啟用叢集模式） 叢集中的可用碎片之間移動雜湊槽，以重新平衡叢集。這樣做有助於更有效率地在可用碎片中分配工作。
+ **[較佳] **實施策略來識別和修復工作負載中的快速鍵。
+ 考慮多維度 Valkey 或 Redis OSS 資料結構的影響，例如清單、串流、集等。這些資料結構存放在位於單一節點的單一金鑰中。相當大型的多維度索引鍵可能比其他資料類型利用更多的網路容量和記憶體，並且可能造成該節點的使用率不成比例。您的工作負載設計應盡可能將資料存取分散到多個獨立的索引鍵。
+ 工作負載中的快速鍵可能會影響使用中節點的效能。對於 ElastiCache for Valkey 和 Redis OSS 工作負載，`valkey-cli --hotkeys`如果 LFU 記憶體上限政策已就緒，您可以使用 偵測熱鍵。
+ 請考慮將快速鍵複寫到多個節點，讓分配到各節點的存取權更平均。此方法要求用戶端寫入多個主節點 (Valkey 或 Redis OSS 節點本身不提供此功能），並維護要讀取的金鑰名稱清單，以及原始金鑰名稱。
+ ElastiCache 引擎 7.2 for Valkey 和更新版本，以及 ElastiCache 第 6 版 for Redis OSS 和更新版本，所有 都支援伺服器輔助[用戶端快取](https://valkey.io/topics/client-side-caching/)。這可讓應用程式等待索引鍵變更，然後再回頭對 ElastiCache 進行網路呼叫。
+ **[資源]：**
+ [設定 ElastiCache for Valkey 和 Redis OSS 以獲得更高的可用性](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
+ [在 ElastiCache 中尋找連線端點](Endpoints.md)
+ [負載平衡最佳實務](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/BestPractices.LoadBalancing.html)
+ [Valkey 或 Redis OSS 的線上重新分片 （啟用叢集模式）](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)
+ [Valkey 和 Redis OSS 中的用戶端快取](https://valkey.io/topics/client-side-caching/)
## PE 3：針對快取工作負載，如何追蹤和報告快取的有效性和效能？
**問題難易度簡介：**快取是 ElastiCache 上常見的工作負載，因此您務必了解如何管理快取的有效性和效能。
**問題難易度優點：**您的應用程式可能會出現效能遲緩的跡象。假如能夠使用快取專用指標做出明智的決策來提高應用程式效能，這點對於快取工作負載而言至關重要。
+ **[必要]** 測量並追蹤經過一段時間的快取命中率。快取的效率是由其「快取命中率」所決定。快取命中率的計算定義是索引鍵命中總數除以命中加未命中總數。命中率越接近 1，表示快取越有效。快取未命中數量是造成快取命中率低的原因。快取中找不到請求的索引鍵時，就會產生快取未命中數。快取中沒有某個索引鍵是因為該索引鍵已移出或刪除、已過期或不曾存在。了解索引鍵為什麼不在快取中，並制定適當的策略將其納入快取中。
**[資源]：**
+ [Valkey 和 Redis OSS 的指標](CacheMetrics.Redis.md)
+ **[必要]** 測量並收集應用程式快取效能，並結合延遲和 CPU 使用率值，以了解是否需要調整存留時間或其他應用程式元件。ElastiCache 針對每一種資料結構提供了一組用於彙總延遲的 CloudWatch 指標。這些延遲指標是使用 INFO 命令的 commandstats 統計資料計算，不包含網路和 I/O 時間。這只是 ElastiCache 處理操作所花費的時間。
**[資源]：**
+ [Valkey 和 Redis OSS 的指標](CacheMetrics.Redis.md)
+ [使用 Amazon CloudWatch 監控 ElastiCache 的最佳實務](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[最佳] **選擇最合乎您需要的快取策略。快取未命中數量是造成快取命中率低的原因。如果您的工作負載設計是維持低快取未命中數量 (例如即時通訊)，那麼最好檢閱您的快取策略，並對工作負載套用最適當的解決方案 (例如查詢檢測) 來測量記憶體和效能。您實際用來填入和維護快取的策略，取決於您的用戶端需要快取的資料，以及該資料的存取模式。例如，您不太可能對串流應用程式上的個人化推薦和熱門新聞報導採用相同的策略。
**[資源]：**
+ [Memcached 的快取策略](Strategies.md)
+ [快取最佳實務](https://aws.amazon.com/caching/best-practices/)
+ [Performance at Scale with Amazon ElastiCache (利用 Amazon ElastiCache 大規模提高效能) 白皮書](https://d0.awsstatic.com/whitepapers/performance-at-scale-with-amazon-elasticache.pdf)
## PE 4：如何利用您的工作負載讓網路資源和連線得到最佳運用？
**問題層級簡介：**許多應用程式用戶端都支援 ElastiCache for Valkey、Memcached 和 Redis OSS，且實作可能有所不同。您需要了解現有的網路和連線管理，以分析潛在的效能影響。
**問題難易度優點：**有效運用網路資源可改善叢集的效能效率。下列建議可減少網路需求，並改善叢集延遲和輸送量。
+ **[必要] **主動管理與您的 ElastiCache 叢集的連線。
+ 在應用程式中使用連線集區，可減少因開啟和關閉連線而對叢集造成的額外負荷量。在 Amazon CloudWatch 中使用 `CurrConnections` 和 `NewConnections` 監控連線行為。
+ 適時確實地關閉用戶端連線，以避免洩漏連線。連線管理策略包括確實地關閉未使用的連線，以及設定連線逾時。
+ 針對 Memcached 工作負載保留了用於處理連線的可設定記憶體數量，稱為 `memcached_connections_overhead`。
+ **[較佳] **壓縮大型物件以減少記憶體並改善網路輸送量。
+ 資料壓縮可減少所需的網路輸送量 (Gbps)，但會增加應用程式壓縮和解壓縮資料的工作量。
+ 壓縮還可以減少索引鍵耗用的記憶體數量
+ 請根據您應用程式的需求，考慮壓縮比和壓縮速度之間的權衡。
+ **[資源]：**
+ [ElastiCache - 全域資料存放區](https://aws.amazon.com/elasticache/redis/global-datastore/)
+ [Memcached 專用參數](ParameterGroups.Engine.md#ParameterGroups.Memcached)
+ [ElastiCache 5.0.3 for Redis OSS 增強了 I/O 處理以提升效能](https://aws.amazon.com/about-aws/whats-new/2019/03/amazon-elasticache-for-redis-503-enhances-io-handling-to-boost-performance/)
+ [Valkey 和 Redis OSS 的指標](CacheMetrics.Redis.md)
+ [設定 ElastiCache 以獲得更高的可用性](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
## PE 5：如何管理刪除和/或移出索引鍵？
**問題難易度簡介：**工作負載各有不同的需求，在叢集節點接近記憶體耗用限制時，也各有不同的預期行為。ElastiCache 有不同的政策來處理這些情況。
**問題難易度優點：**適當管理可用記憶體並且了解移出政策，將有助於確保在超過執行個體記憶體限制時，能夠察覺到叢集行為。
+ **[必要] **檢測資料存取權以評估要套用的政策。找出適當的最大記憶體政策，以控制是否要在叢集上執行移出，以及移出的方式。
+ 當達到叢集上的最大記憶體耗用量，而且已設有允許移出的政策時，就會進行移除。在此情況下，叢集的行為會取決於指定的移出政策。您可以使用叢集參數群組`maxmemory-policy`上的 來管理此政策。
+ 預設政策 `volatile-lru` 會藉由將已設定到期時間 (TTL 值) 的索引鍵移出來釋出記憶體。最不常用 (LFU) 和最近最少使用 (LRU) 政策會根據使用情形移除索引鍵。
+ 針對 Memcached 工作負載，有一項預設的 LRU 政策可用來控制每個節點上的移出作業。您可以使用 Amazon CloudWatch 上的「移出」指標來監控 Amazon ElastiCache 叢集上的移出數量。
+ **[較佳] **將刪除行為標準化，就可控制對叢集的效能影響，進而避免非預期的效能瓶頸發生。
+ 對於 ElastiCache for Valkey 和 Redis OSS 工作負載，從叢集明確移除金鑰時， `UNLINK` 就像 `DEL`：它會移除指定的金鑰。然而，該命令會在不同的執行緒中執行實際的記憶體回收，因此不會封鎖，但 `DEL` 會封鎖。實際的移除操作會在之後以非同步方式進行。
+ 對於 ElastiCache 6.x 版的 Redis OSS 工作負載，可以使用 `lazyfree-lazy-user-del` 參數在參數群組中修改`DEL`命令的行為。
+ **[資源]：**
+ [使用 ElastiCache 參數群組設定引擎參數](ParameterGroups.md)
+ [UNLINK](https://valkey.io/commands/unlink/)
+ [使用 進行雲端財務管理AWS](https://aws.amazon.com/aws-cost-management/)
## PE 6：如何在 ElastiCache 中建立資料模型並與資料互動？
**問題難易度簡介：**ElastiCache 的應用相當依賴所使用的資料結構和資料模型，但同樣需要考慮基礎資料存放區 (如有的話)。了解可用的資料結構，並確保您使用最符合您需求的資料結構。
**問題難易度優點：**ElastiCache 中的資料建模包含數層，包括應用程式使用案例、資料類型，以及資料元素之間的關係。此外，每個資料類型和命令都有自己的記錄效能簽章。
+ **[最佳] **最佳實務是減少意外覆寫資料的情況。使用盡可能減少索引鍵名稱重疊的命名慣例。資料結構的慣用命名是使用像是 `APPNAME:CONTEXT:ID` 這類階層方法，例如 `ORDER-APP:CUSTOMER:123`。
**[資源]：**
+ [索引鍵命名](https://docs.gitlab.com/ee/development/redis.html#key-naming)
+ **【最佳】 **ElastiCache for Valkey 和 Redis OSS 命令具有 Big O 表示法定義的時間複雜性。命令的這種時間複雜度是其影響的演算/數學表示法。當您在應用程式中引入新的資料類型時，需仔細查看相關命令的時間複雜度。時間複雜度為 O(1) 的命令在時間上是恆定的，並不取決於輸入大小，但是時間複雜度為 O(N) 的命令在時間上是線性的，因此會受輸入大小的影響。由於 ElastiCache for Valkey 和 Redis OSS 的單一執行緒設計，大量的高時間複雜性操作將導致效能降低和潛在的操作逾時。
**[資源]：**
+ [命令](https://valkey.io/commands/)
+ **[最佳] **使用 API 來取得叢集中資料模型的 GUI 可見度。
**[資源]：**
+ [Redis OSS 命令程式](https://www.npmjs.com/package/ElastiCache for Redis-commander)
+ [Redis OSS 瀏覽器](https://github.com/humante/redis-browser)
+ [Redsmin](https://www.redsmin.com/)
## PE 7：如何記錄 Amazon ElastiCache 叢集中執行緩慢的命令？
**問題難易度簡介：**透過擷取、彙總和通知長時間執行的命令，達到效能調整效益。藉由了解命令執行所需的時間，就可以判斷哪些命令會導致效能不佳，以及哪些命令造成引擎無法以最佳效能執行。ElastiCache 也能夠將此資訊轉送至 Amazon CloudWatch 或 Amazon Kinesis Data Firehose。
**問題難易度優點：**針對慢速命令記錄到專用的永久位置並提供通知事件，有助於進行詳細的效能分析，並可用於觸發自動化事件。
+ **【必要】 **執行 Valkey 引擎 7.2 或更新版本的 ElastiCache，或在叢集上執行 Redis OSS 引擎 6.0 或更新版本、正確設定的參數群組和啟用的 SLOWLOG 記錄。
+ 只有在引擎版本相容性設定為 Valkey 7.2 及更高版本，或 Redis OSS 6.0 版或更高版本時，才能使用必要的參數。
+ 當命令的伺服器執行時間超過指定的值時，SLOWLOG 記錄就會發生。叢集的行為取決於相關聯的參數群組參數，也就是 `slowlog-log-slower-than` 和 `slowlog-max-len`。
+ 變更會立即生效。
+ **[最佳] **利用 CloudWatch 或 Kinesis Data Firehose 的功能。
+ 使用 CloudWatch、CloudWatch Logs Insights 及 Amazon Simple Notification Service 的篩選和警示功能，就能實現效能監控和事件通知。
+ 使用 Kinesis Data Firehose 的串流功能將 SLOWLOG 日誌封存到永久儲存體，或觸發自動化叢集參數調整。
+ 判斷 JSON 或純文字格式最合乎您的需要。
+ 提供 IAM 許可以發佈到 CloudWatch 或 Kinesis Data Firehose。
+ **[較佳] **將 `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 記憶體中存放大量慢速執行命令的需求。
+ **[資源]：**
+ [如何在叢集中開啟慢速日誌？](https://repost.aws/knowledge-center/elasticache-turn-on-slow-log)
+ [日誌傳送](Log_Delivery.md)
+ [Redis OSS 特定參數](ParameterGroups.Engine.md#ParameterGroups.Redis)
+ [https://aws.amazon.com/cloudwatch/](https://aws.amazon.com/cloudwatch/)Amazon CloudWatch
+ [Amazon Kinesis Data Firehose](https://aws.amazon.com/kinesis/data-firehose/)
## PE8：自動擴展功能如何協助提高 ElastiCache 叢集的效能？
**問題難易度簡介：**透過實作 Valkey 或 Redis OSS 自動擴展功能，ElastiCache 元件可以隨著時間調整，自動增加或減少所需的碎片或複本。藉由實作目標追蹤或排程的擴展政策就能達到此目的。
**問題難易度優點：**了解並規劃工作負載的尖峰，就可確實增強快取效能與業務連續性。ElastiCache Auto Scaling 會持續監控您的 CPU/記憶體使用率，以確保您的叢集在所需的效能層級運作。
+ **【必要】 **為 ElastiCache for Valkey 或 Redis OSS 啟動叢集時：
1. 確定已啟用叢集模式
1. 確定執行個體屬於支援自動擴展的特定類型和大小系列
1. 確保叢集未在全域資料存放區、Outposts 或 Local Zones 中執行
**[資源]：**
+ [在 Valkey 和 Redis OSS 中擴展叢集 （啟用叢集模式）](scaling-redis-cluster-mode-enabled.md)
+ [搭配碎片使用自動擴展](AutoScaling-Using-Shards.md)
+ [搭配複本使用自動擴展](AutoScaling-Using-Replicas.md)
+ **[最佳] **確認您的工作負載為大量讀取或大量寫入，以定義擴展政策。為了獲得最佳效能，請使用單獨一個追蹤指標。建議您避免針對每個維度實施多項政策，因為自動擴展政策會在命中目標時橫向擴展，但只有在所有目標追蹤政策都準備好縮減時才會縮減。
**[資源]：**
+ [自動擴展政策](AutoScaling-Policies.md)
+ [定義擴展政策](AutoScaling-Scaling-Defining-Policy-API.md)
+ **[最佳] **隨著時間監控效能可幫助您偵測到在特定時間點監控時，可能無法察覺的工作負載變更。您可以分析對應的 CloudWatch 指標來了解四週期間內的叢集使用率，藉此判斷目標值的閾值。如果您仍不確定要選擇哪個值，建議從支援的最小預先定義指標值開始。
**[資源]：**
+ [使用 CloudWatch 指標監控用量](CacheMetrics.md)
+ **[較佳] **我們建議您使用預期的最小和最大工作負載來測試應用程式，藉此找出叢集制定擴展政策和減輕可用性問題所需的準確碎片/複本數量。
**[資源]：**
+ [註冊可擴展的目標](AutoScaling-Register-Policy.md)
+ [使用 註冊可擴展目標AWS CLI](AutoScaling-Scaling-Registering-Policy-CLI.md)