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

# DAX 叢集調整大小指南
<a name="DAX.sizing-guide"></a>

本指南會為您提供建議，以便您為應用程式選擇合適的 Amazon DynamoDB Accelerator (DAX) 叢集大小和節點類型。這些指示會逐步引導您預估應用程式的 DAX 流量、選取叢集組態並加以測試。

如果您目前有 DAX 叢集，並且想評估叢集是否具有合適的節點數量與大小，請參考[擴展 DAX 叢集](DAX.cluster-management.md#DAX.cluster-management.scaling)。

**Topics**
+ [概觀](#DAX.sizing-guide.overview)
+ [預估流量](#DAX.sizing-guide.estimating-traffic)
+ [負載測試](#DAX.sizing-guide.load-testing)

## 概觀
<a name="DAX.sizing-guide.overview"></a>

不論您是要建立新的叢集或維護現有叢集，為工作負載適當擴展 DAX 叢集都很重要。隨著時間經過與應用程式工作負載變更，您也應該定期審視擴展決策來確保合適性。

此程序通常遵循下列步驟：

1. **預估流量。**在此步驟中，您將預測應用程式傳送至 DAX 的流量、流量的性質 (讀取比對寫入操作)，以及預計的快取命中率。

1. **負載測試。**在此步驟中，您將建立叢集並向叢集傳送流量，來驗證上一個步驟的預估。請重複這個步驟直到找到合適的叢集組態為止。

1. **生產監控。**當應用程式在生產階段使用 DAX 時，務必[監控叢集](DAX.Monitoring.md)以持續確認叢集仍會隨著工作負載變更正確調整規模。

## 預估流量
<a name="DAX.sizing-guide.estimating-traffic"></a>

典型 DAX 工作負載的特性有三個主要因素：
+ 快取命中率
+ 每秒[讀取容量單位](provisioned-capacity-mode.md#read-write-capacity-units) (RCU)
+ 每秒[寫入容量單位](provisioned-capacity-mode.md#read-write-capacity-units) (WCU)

### 預估快取命中率
<a name="DAX.sizing-guide.estimating-traffic.hit-rate"></a>

如果您已有 DAX 叢集，則可以使用 `ItemCacheHits` 和 `ItemCacheMisses` [Amazon CloudWatch 指標](dax-metrics-dimensions-dax.md)來判斷快取命中率。快取命中率等於 `ItemCacheHits` /(`ItemCacheHits` \$1 `ItemCacheMisses`)。如果您的工作負載包含 `Query` 或 `Scan` 操作，也請查看 `QueryCacheHits`、`QueryCacheMisses`、`ScanCacheHits` 與 `ScanCacheMisses` 指標。應用程式間的快取命中率會有所差異，而且非常容易受到叢集的存留時間 (TTL) 設定影響。使用 DAX 的應用程式通常有 85% 至 95% 的命中率。

### 預估讀取和寫入容量單位
<a name="DAX.sizing-guide.estimating-traffic.rcu-wcu"></a>

如果您的應用程式已經有 DynamoDB 資料表，請查看 `ConsumedReadCapacityUnits` 及 `ConsumedWriteCapacityUnits`[ CloudWatch 指標](dax-metrics-dimensions-dax.md)。使用 `Sum` 統計數字，除以週期中的秒數。

如果您也已經有 DAX 叢集，請記得此 DynamoDB `ConsumedReadCapacityUnits` 指標只會考量快取未中。因此，如果要了解 DAX 叢集每秒處理的讀取容量單位，請將數字除以快取未中率 (即 1：快取命中率)。

如果您還沒有 DynamoDB 資料表，請參閱[讀取和寫入容量單位](provisioned-capacity-mode.md#read-write-capacity-units)的相關文件，來根據應用程式的預估請求率、每個請求的存取項目數和項目大小來預估流量。

預估流量時，請將後續增長和預期/非預期的尖峰納入考量，來確保叢集有足夠的流量增加空間。

## 負載測試
<a name="DAX.sizing-guide.load-testing"></a>

預估流量後的下一步是測試負載叢集組態。

1. 進行第一次負載測試時，建議您先從 `dax.r4.large` 節點類型開始，這是最低成本固定效能、記憶體最佳化的節點類型。

1. 容錯叢集至少需要三個節點，分布於三個可用區域。在此情況下，如果有一個可用區域失效，則可用區域的有效數量會減少三分之一。進行第一次負載測試時，建議您先從兩個節點的叢集開始，這會模擬三個節點叢集中有一個可用區域失效的情形。

1. 負載測試期間，請對您的測試叢集推動持續流量 (如上一步驟中所預估)。

1. 在負載測試期間監控叢集的效能。

理想情況下，您在負載測試期間推動的流量概況，應該盡可能地符合應用程式實際流量。這包括操作的分配 (例如 70% `GetItem`、25% `Query` 和 5% `PutItem`)、各操作的請求率、每個請求的項目存取數和項目大小的分佈。如果要達到與應用程式預期相當的快取命中率，請密切注意測試流量中的金鑰分佈情形。

**注意**  
對 T2 節點類型 (`dax.t2.small` 與 `dax.t2.medium`) 進行負載測試時請小心。T2 節點類型提供[高載 CPU 效能](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html)，會根據節點的 CPU 點數餘額隨著時間變化。在 T2 節點上執行的 DAX 叢集可能看似正常運作，但只要有任何節點暴增超過本身執行個體的[基準效能](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html)，節點就會消耗累積的 CPU 點數餘額。如果點數餘額不足，[效能會逐漸降低](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-standard-mode.html)至基準效能等級。

請在負載測試期間[監控您的 DAX 叢集](DAX.Monitoring.md)，來判斷為負載測試使用的節點類型是否合適。此外，也請在負載測試期間監控請求率與快取命中率，來確保測試基礎設施真的有在推動您想要的流量。

 您應該留意所選叢集執行個體類型的網路位元組使用量。若超過 Amazon EC2 執行個體的可用基準頻寬，即表示您的叢集可能無法承受應用程式的工作負載，且需要進行擴展。

如果負載測試指出選取的叢集組態無法承受應用程式的工作負載，您應[切換至更大的節點類型](DAX.cluster-management.md#DAX.cluster-management.scaling.node-types)，尤其是在叢集的主節點上發現高 CPU 使用率、高移出率或高快取記憶體時更是如此。如果命中率一直很高，而且讀取與寫入流量的比率也很高的話，則建議您考慮[為叢集新增更多節點](DAX.cluster-management.md#DAX.cluster-management.scaling.read-scaling)。如果需要額外指導來了解何時該使用更大的節點類型 (垂直擴展) 或新增更多節點 (水平擴展)，則請參閱 [擴展 DAX 叢集](DAX.cluster-management.md#DAX.cluster-management.scaling)。

變更叢集組態後，請重複進行負載測試。