本部分总结了我们的最佳实践，并提供了将 OPDK 与 AWS 云结合使用的建议。
Cassandra 用作几乎所有政策的后端和数据存储区，并且是 Apigee Edge 运行时环境的关键部分。本文档重点介绍如何针对 AWS 环境优化 Casssandra。
存储和 I/O 要求
大多数 Cassandra I/O 都是按顺序执行的，但在某些情况下，您需要使用随机 I/O。例如，在读取操作期间读取已排序的字符串表。SSD 是 Cassandra 推荐的存储机制，因为它可以为随机读取操作提供极短的响应时间，同时为压缩操作提供足够的顺序写入性能。此处还考虑了复制。
AWS EC2 中的许多实例都附带本地存储空间，其中硬盘以物理方式连接到托管 EC2 实例的硬件。在生产环境中运行 Cassandra 时，Apigee 建议同时使用 SSD 和实例存储区。当您使用包含多个 SSD 的实例类型时，可以使用 RAID0 来提高吞吐量和存储容量。
网络要求
Cassandra 使用 Gossip 协议与其他节点交换关于网络拓扑的信息。使用 Gossip 以及 Cassandra 的分布式特性（涉及与多个节点通信以进行读写操作）会导致通过网络进行大量数据传输。Apigee 建议为生产系统使用网络带宽至少为 1 Gbps 且高于 1 Gbps 的实例类型。
使用 CIDR 为 /16 的 VPC。由于 AWS 中的子网不能跨越多个可用区，因此 Apigee 建议如下：
- 为每个可用性区域 (AZ) 创建 1 个子网
- 安装 Apigee 时可使用 3 个专用子网，每个 AZ 中各有一个 Cassandra 节点。这 3 个子网应具有足够的 CIDR 块，以适应 Cassandra 集群的横向扩展。
- 为 Cassandra 配置 3 个具有专用 NAT 的公共子网，以便与互联网通信以进行软件下载和安全更新。
与传统的主从架构不同，Cassandra 具有无主架构，其中所有节点发挥相同作用，因此不存在单点故障。请考虑将您的 Cassandra 节点分布在多个可用区中，以实现高可用性。通过将节点分布到各个可用区，您仍然可以在发生灾难时保持可用性和正常运行时间。
选择实例系列
在查看 Cassandra CPU 要求时，请务必注意，在 Cassandra 中，需要大量插入内容的工作负载在受限于 IO 之前会受 CPU 限制。换句话说，所有写入操作都写入提交日志，但 Cassandra 写入非常高效，以至于 CPU 成为了限制因素。Cassandra 具有高并发性，会使用尽可能多的 CPU 核心。
Apigee 建议使用能够平衡 CPU 和内存的实例系列。 具体而言，如果在您的 AWS 区域提供 C5 系列实例，我们建议使用 C5 系列实例，并使用 C3 作为后备方案。在某些情况下，4xlarge 是两个系列中能够提供最佳性价比的最佳实例。
此外，Apigee 还建议为 Cassandra 实例使用默认租户。在扩容到每个可用区 1 个以上的实例时，如果您将租户设置为专用，则所有 Cassandra 实例很可能都放置在相同的底层硬件上。因此，当硬件发生故障时，您可能会丢失该可用区中的所有实例。
建议摘要
下表总结了将 AWS 与适用于私有云的 Apigee Edge 搭配使用的 Apigee 建议：
| 实例系列 | C5d（首选）或 C3 |
| 实例类型 | C(x).4xlarge |
| 实例存储 | 采用 RAID0 的 SSD（本地存储空间） |
| 租户类型 | 默认 |
| 节点放置 | 每个可用区 1 个 Cassandra 节点 |
| VPC 和子网 | 每个可用区 1 个子网，每个区域一个 VPC |
如需了解详情，请参阅 Amazon 实例类型。