本部分总结了我们的最佳实践，并提供了将 OPDK 与 AWS 云搭配使用的建议。
Cassandra 用作几乎所有政策的后端和数据存储区，是 Apigee Edge 运行时环境的关键部分。本文档重点介绍如何针对 AWS 环境优化 Cassandra。
存储空间和 I/O 要求
大多数 Cassandra I/O 都是顺序 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 的 VPC。由于 AWS 中的子网不能跨越多个可用区，因此 Apigee 建议：
- 为每个可用区 (AZ) 创建 1 个子网
- 为 Apigee 安装使用 3 个专用子网，每个可用区中有一个 Cassandra 节点。这 3 个子网应有足够的 CIDR 块，以容纳 Cassandra 集群的横向扩展。
- 为 Cassandra 配置 3 个具有专用 NAT 的公共子网，以便能够与互联网通信，从而下载软件和安全更新。
与传统的主从架构不同，Cassandra 采用无主架构，其中所有节点都扮演相同的角色，因此不存在单点故障。考虑将 Cassandra 节点分布在多个可用区中，以实现高可用性。通过将节点分布在多个可用区，您仍然可以在发生灾难时保持可用性和正常运行时间。
选择实例系列
在查看 Cassandra CPU 要求时，请注意，在 Cassandra 中，插入密集型工作负载在受 IO 限制之前会受 CPU 限制。换句话说，所有写入操作都会进入提交日志，但 Cassandra 的写入效率非常高，以至于 CPU 成为限制因素。Cassandra 具有高度并发性，会尽可能多地使用可用的 CPU 核心。
Apigee 建议使用实例系列，该系列在 CPU 和内存之间取得了平衡。具体而言，我们建议您使用 C5 系列实例（如果您所在的 AWS 区域提供），并使用 C3 作为备用选项。在某些情况下，4xlarge 是这两个系列中可提供最佳性价比的最佳实例。
Apigee 还建议为 Cassandra 实例使用默认租用。当您将每个可用区扩缩到 1 个以上的实例时，如果您将租用设置为专用，则所有 Cassandra 实例很可能会放置在同一底层硬件上。因此，当硬件发生故障时，您可能会丢失该可用区中的所有实例。
建议摘要
下表总结了将 AWS 与 Apigee Edge for Private Cloud 搭配使用的 Apigee 建议：
| 实例系列 | C5d（首选）或 C3 |
| 实例类型 | C(x).4xlarge |
| 实例存储 | 采用 RAID0 的 SSD（本地存储空间） |
| 租用类型 | 默认 |
| 节点位置 | 每个可用区 1 个 Cassandra 节点 |
| VPC 和子网 | 每个可用区 1 个子网，每个区域 1 个 VPC |
如需了解详情，请参阅 Amazon 实例类型。