本節總結我們的最佳做法，並提供搭配 AWS 雲端使用 OPDK 的建議。
Cassandra 是幾乎所有政策的後端和資料儲存庫，也是 Apigee Edge 執行階段環境的重要部分。本文著重於針對 AWS 環境最佳化 Cassandra。
儲存空間和 I/O 需求
大多數 Cassandra I/O 都是依序執行，但有時需要隨機 I/O。例如在讀取作業期間讀取排序字串資料表。SSD 是 Cassandra 建議的儲存機制，因為它能為隨機讀取作業提供極低延遲的回應時間，同時為壓縮作業提供足夠的循序寫入效能。這裡也會考量複製作業。
AWS EC2 中的許多執行個體都隨附本機儲存空間，硬碟會實際連接至託管 EC2 執行個體的硬體。Apigee 建議在正式環境中執行 Cassandra 時，同時使用 SSD 和執行個體儲存空間。如果使用的執行個體類型有多個 SSD，可以透過 RAID0 提高處理量和儲存空間容量。
網路需求
Cassandra 使用 Gossip 通訊協定，與其他節點交換網路拓撲相關資訊。使用 Gossip 加上 Cassandra 的分散式特性 (涉及與多個節點通訊以進行讀取和寫入作業)，會導致透過網路傳輸大量資料。Apigee 建議使用網路頻寬至少 1 Gbps 的執行個體類型，正式環境系統則建議使用超過 1 Gbps 的執行個體類型。
使用 CIDR 為 /16 的虛擬私有雲。由於 AWS 中的子網路無法跨越多個可用區，Apigee 建議採取下列做法：
- 為每個可用區建立 1 個子網路
- 使用 3 個私人子網路安裝 Apigee，每個可用區各有一個 Cassandra 節點。這 3 個子網路應有足夠的 CIDR 區塊，可容納 Cassandra 叢集的水平擴充。
- 設定 3 個公開子網路，並為 Cassandra 提供專屬網路位址轉譯 (NAT)，以便與網際網路通訊，下載軟體和安全性更新。
與傳統的主從式架構不同，Cassandra 採用無主架構，所有節點都扮演相同角色，因此不會出現單點故障。建議您將 Cassandra 節點分散到多個可用區，以啟用高可用性。將節點分散在多個可用區，即使發生災難，仍可維持可用性和運作時間。
選擇執行個體系列
查看 Cassandra CPU 需求時，請注意，在 Cassandra 中，插入作業繁重的工作負載會先受限於 CPU，然後才受限於 IO。換句話說，所有寫入作業都會進入修訂記錄，但 Cassandra 的寫入效率極高，因此 CPU 會成為限制因素。Cassandra 具有高度並行性，會盡可能使用可用的 CPU 核心。
Apigee 建議使用 CPU 和記憶體平衡的執行個體系列。具體來說，如果 AWS 區域提供 C5 系列執行個體，建議您使用該系列，並以 C3 做為備用選項。在某些情況下，4xlarge 是這兩個系列中最佳的執行個體，可提供最佳的性價比。
Apigee 也建議對 Cassandra 執行個體使用預設租用模式。如果將租賃模式設為專用，當您將每個可用區的執行個體數量擴充至超過 1 個時，所有 Cassandra 執行個體很可能會放在相同的基礎硬體上。因此，當硬體故障時，您可能會失去該可用區中的所有執行個體。
建議摘要
下表總結了 Apigee 建議，說明如何搭配使用 AWS 與 Apigee Edge for Private Cloud：
| 執行個體系列 | C5d (建議) 或 C3 |
| 執行個體類型 | C(x).4xlarge |
| 執行個體儲存區 | SSD (本機儲存空間)，採用 RAID0 |
| 租用類型 | 預設 |
| 節點位置 | 每個可用區 1 個 Cassandra 節點 |
| 虛擬私有雲和子網路 | 每個可用區 1 個子網路，每個區域 1 個虛擬私有雲 |
詳情請參閱「Amazon 執行個體類型」。