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

# 選擇您的節點大小
<a name="CacheNodes.SelectSize"></a>

您為 ElastiCache 叢集選取的節點大小會影響成本、效能和容錯能力。

## 節點大小 (Valkey 和 Redis OSS)
<a name="CacheNodes.SelectSize.redis"></a>

如需有關 Graviton 處理器優點的詳細資訊，請參閱 [AWS  Graviton 處理器](https://aws.amazon.com/pm/ec2-graviton/)。

回答下列問題可協助您判斷 Valkey 或 Redis OSS 實作所需的最低節點類型：
+ 您是否預期會有具有多個用戶端連線的輸送量繫結工作負載？

  如果是這種情況，而且您正在執行 Redis OSS 5.0.6 版或更高版本，您可以使用增強型 I/O 功能來獲得更好的輸送量和延遲，其中可用的 CPUs用於代表 Redis OSS 引擎卸載用戶端連線。如果您執行 Redis OSS 7.0.4 版或更新版本，除了增強型 I/O 之外，您還可以透過增強型 I/O 多工功能獲得額外的加速，其中每個專用網路 IO 執行緒管道命令都會從多個用戶端流向 Redis OSS 引擎，利用 Redis OSS 的 功能有效率地分批處理命令。在 ElastiCache for Redis OSS v7.1 及更高版本中，我們擴展了增強型 I/O 執行緒功能，以處理呈現層邏輯。依呈現層而言，我們的意思是增強型 I/O 執行緒現在不僅讀取用戶端輸入，還會將輸入剖析為 Redis OSS 二進位命令格式，然後轉送至主執行緒以執行，從而提高效能。如需其他詳細資訊，請參閱[部落格文章](https://aws.amazon.com/blogs/database/achieve-over-500-million-requests-per-second-per-cluster-with-amazon-elasticache-for-redis-7-1/)和[支援的版本](VersionManagement.md#supported-engine-versions)頁面。
+ 您是否有經常存取少量資料的工作負載？

  如果是這種情況，而且您在 Redis OSS 引擎 6.2 版或更新版本上執行，您可以選擇 r6gd 節點類型來利用資料分層。透過資料分層，最近使用的資料會存放在 SSD 中。當檢索資料時，會有少量的延遲成本，可藉由成本節省加以抵銷。如需詳細資訊，請參閱[ElastiCache 中的資料分層](data-tiering.md)。

  如需詳細資訊，請參閱[支援的節點類型](CacheNodes.SupportedTypes.md)。
+ 您的資料需要多少總記憶體？

  若要取得一般估計值，請使用要快取的項目大小。將此大小乘以您希望同時保持在快取中的項目數。若要取得合理的項目大小估計，收先請序列化您的快取項目，接著計算字元數。然後再除以您叢集中碎片數。

  如需詳細資訊，請參閱[支援的節點類型](CacheNodes.SupportedTypes.md)。
+ 您正在執行哪個版本的 Redis OSS？

  2.8.22 之前的 Redis OSS 版本要求您為容錯移轉、快照、同步和將複本提升為主要操作預留更多記憶體。此需求的原因是您必須針對處理期間所有發生的寫入擁有足夠的記憶體。

  Redis OSS 2.8.22 版和更新版本使用無分支儲存程序，需要的記憶體比先前程序更少。

  如需詳細資訊，請參閱下列內容：
  + [同步與備份的實作方式](Replication.Redis.Versions.md)
  + [確保您有足夠的記憶體來建立 Valkey 或 Redis OSS 快照](BestPractices.BGSAVE.md)
+ 您應用程式所需要的大量寫入程度為何？

  需要大量寫入的應用程式可能需要在取得快照或容錯移轉時擁有大上許多的可用記憶體 (尚未由資料使用的記憶體)。每次執行 `BGSAVE` 處理序時，都必須有資料未使用的足夠記憶體，以容納執行 `BGSAVE` 處理序時產生的所有寫入。例如拍攝快照、將主要叢集與叢集中的複本同步，以及啟用僅限附加檔案 (AOF) 功能時。另一個範例是將複本提升為主要節點 (若您已啟用多個可用區) 時。最糟糕的情況是執行處理序過程中所有資料都被重寫。在這種情況下，節點執行個體的大小需為單純資料所需記憶體的兩倍。

  如需詳細資訊，請參閱[確保您有足夠的記憶體來建立 Valkey 或 Redis OSS 快照](BestPractices.BGSAVE.md)。
+ 您的實作是獨立的 Valkey 或 Redis OSS （停用叢集模式） 叢集，還是具有多個碎片的 Valkey 或 Redis OSS （啟用叢集模式） 叢集？

**Valkey 或 Redis OSS （停用叢集模式） 叢集**  
如果您要實作 Valkey 或 Redis OSS （停用叢集模式） 叢集，您的節點類型必須能夠容納所有資料加上必要的額外負荷，如上一個項目符號所述。

  例如，假設您估計所有項目的總大小為 12 GB。在這種情況下，您可以使用具有 13.3 GB 記憶體的 `cache.m3.xlarge` 節點或記憶體為 13.5 GB 的 `cache.r3.large` 節點。但是，您可能需要更多記憶體以執行 `BGSAVE` 作業。如果您的應用程式需執行大量寫入，請將記憶體需求加倍為至少 24 GB。因此，可使用 `cache.m3.2xlarge` (含 27.9 GB 記憶體) 或 `cache.r3.xlarge` (含 30.5 GB 記憶體)。

**具有多個碎片的 Valkey 或 Redis OSS （啟用叢集模式）**  
如果您要實作具有多個碎片的 Valkey 或 Redis OSS （啟用叢集模式） 叢集，則節點類型必須能夠容納資料的`bytes-for-data-and-overhead / number-of-shards`位元組。

  例如，假設您估計所有項目的總大小為 12 GB 且有兩個碎片。在這種情況下，您可以使用具有 6.05 GB 記憶體 (12 GB/2) 的 `cache.m3.large` 節點。但是，您可能需要更多記憶體以執行 `BGSAVE` 作業。如果您的應用程式需執行大量寫入，請將記憶體需求加倍為每個碎片至少 12 GB。因此，可使用 `cache.m3.xlarge` (含 13.3 GB 記憶體) 或 `cache.r3.large` (含 13.5 GB 記憶體)。
+ 您是否有使用 Local Zones？

[Local Zones](Local_zones.md) 可讓您將資源 (例如 ElastiCache 叢集) 放置在靠近使用者的多個位置。但是選擇節點大小時請注意，無論容量要求為何，目前可用節點都會限制為下列大小：
  + 最新一代：

    **M5 節點類型：**`cache.m5.large`、`cache.m5.xlarge`、`cache.m5.2xlarge`、`cache.m5.4xlarge`、`cache.m5.12xlarge`、`cache.m5.24xlarge`

    **R5 節點類型：**`cache.r5.large`、`cache.r5.xlarge`、`cache.r5.2xlarge`、`cache.r5.4xlarge`、`cache.r5.12xlarge`、`cache.r5.24xlarge`

    **T3 節點類型：**`cache.t3.micro`、`cache.t3.small`、`cache.t3.medium`

在您的叢集執行中時，您可以監控發佈到 CloudWatch 的記憶體用量、處理器使用率、快取命中及快取未命中指標。您可能會注意到叢集沒有您想要的命中率，或是索引鍵被移出的頻率太頻繁。在這些情況下，您可以選擇 CPU 和記憶體規格較大的不同節點大小。

監控 CPU 用量時，請記住 Valkey 和 Redis OSS 是單執行緒。因此，將回報的 CPU 使用率乘上 CPU 核心數，可得出實際的使用率。例如，報告 20% 使用率的四核心 CPU 實際上是 Redis OSS 以 80% 使用率執行的一個核心。

## 節點大小 (Memcached)
<a name="CacheNodes.SelectSize.Mem"></a>

Memcached 叢集包含一或多個節點，其中叢集的資料會分割在各個節點中。因此，叢集的記憶體需求與節點的記憶體相關，但不相同。您可以透過擁有幾個大型節點或數個較小的節點，來達到您需要的叢集記憶體容量。除此之外，隨著您的需求變更，您可以新增節點或從叢集移除節點，來只為您需要的項目支付費用。

您叢集的總記憶體容量是透過將叢集中的節點數與每個節點的 RAM 容量相乘，再減去系統額外負荷計算而得。每個節點的容量是根據節點類型而定。

```
cluster_capacity = number_of_nodes * (node_capacity - system_overhead)
```

叢集中的節點數量是您執行 Memcached 叢集可用性的關鍵因素。單一節點發生故障，可能會影響您應用程式的可用性及後端資料庫的負載。在這種情況下，ElastiCache 會為失敗的節點佈建一個替代節點，並重新填入資料。您可以將記憶體和運算容量分散到更多容量較小的節點間，而非使用少數具備高容量的節點，藉此降低此可用性影響。

在希望擁有 35 GB 快取記憶體的案例中，可以透過以下任一組態進行設定：
+ 11 個 `cache.t2.medium` 節點，其具備 3.22 GB 的記憶體及 2 個執行緒，合計 35.42 GB 和 22 個執行緒。
+ 6 個 `cache.m4.large` 節點，其具備 6.42 GB 的記憶體及 2 個執行緒，合計 38.52 GB 和 12 個執行緒。
+ 3 個 `cache.r4.large` 節點，其具備 12.3 GB 的記憶體及 2 個執行緒，合計 36.90 GB 和 6 個執行緒。
+ 3 個 `cache.m4.xlarge` 節點，其具備 14.28 GB 的記憶體及 4 個執行緒，合計 42.84 GB 和 12 個執行緒。


**比較節點選項**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonElastiCache/latest/dg/CacheNodes.SelectSize.html)

這些選項每個都能提供相似的記憶體容量，但不同的運算容量及成本。若要比較您具體選項的成本，請參閱 [Amazon ElastiCache 定價](https://aws.amazon.com/elasticache/pricing/)。

針對執行 Memcached 的叢集，每個節點上一部分的可用記憶體會用於連線額外負荷。如需詳細資訊，請參閱 [Memcached 連線額外負荷](ParameterGroups.Engine.md#ParameterGroups.Memcached.Overhead)

使用多個節點需要將索引鍵分散到這些節點當中。每個節點都有自己的端點。為了簡化端點管理，您可以使用 ElastiCache 的自動探索功能，讓用戶端程式能自動識別叢集中的所有節點。如需詳細資訊，請參閱[自動識別叢集中的節點 (Memcached)](AutoDiscovery.md)。

在某些案例中，您可能不確定需要多少容量。這個情況下，建議從一個 `cache.m5.large` 節點開始測試。然後使用發佈到 Amazon CloudWatch 的 ElastiCache 指標，監控記憶體用量、CPU 使用率及快取命中率。如需有關 ElastiCache 的 CloudWatch 指標的詳細資訊，請參閱「[使用 CloudWatch 指標監控用量](CacheMetrics.md)」。針對生產及更大的工作負載，R5 節點可提供最佳效能及 RAM 成本值。

若您的叢集沒有達到所需的命中率，您可輕易新增更多節點來增加叢集中可用的總記憶體。

若您的叢集具備足夠的命中率，但受到 CPU 限制，請使用提供更強運算能力的節點類型設定新的叢集。