本文的讨论基于这篇文章：https://handbook.vantage.sh/aws/concepts/io-operations/

Input/output operations per second (IOPS) are a relatively low-level unit in AWS for measuring disk performance. The maximum size of an IOP is 256 KiB for SSD volumes and 1 GiB for HDD volumes. 1 MiB of storage is worth 3 IOPS, so a 1,000 GiB EBS Volume has 3,000 IOPS available. When using these volume types you are charged for the amount of provisioned IOPS even if you don’t fully utilize them.

在 AWS 上，SSD 上一个 IO 操作可以读取 256KB 数据，HDD 上一个 IO 操作可以读取 1MB（原文GB 是 typo） 数据。

在云上，按照 AWS 的资源预分配策略，1GB 存储会分配 3 IOPS，所以一个 1000 GB EBS 卷可以支持 3000 IOPS。

Provisioned IOPS SSD volumes use a consistent IOPS rate, which you specify when you create the volume, and Amazon EBS delivers the provisioned performance 99.9% of the time.

在云计算领域，“Provisioned”（配置的）这个词通常用来描述云资源分配和准备工作的状态。当提到"Provisioned"资源时，意味着这些资源已经按照用户的请求配置并且准备就绪，用户可以开始使用这些资源来运行应用程序、存储数据、执行计算任务等。

例如，在一个云服务提供商（如Amazon Web Services, Microsoft Azure, Google Cloud Platform等）中：

• Provisioned Compute Resources: 分配了CPU、内存、网络带宽以及其他必要的系统资源来运行虚拟机或者容器。
• Provisioned Storage: 配置了一定量的磁盘空间用于持久化存储数据。
• Provisioned Databases: 创建并配置了数据库实例，包括设置数据库类型（如SQL或NoSQL）、容量、备份和性能要求。
• Provisioned IOPS (Input/Output Operations Per Second): 在某些类型的存储服务中，用户可以指定需要的IOPS，即磁盘操作的性能。这代表了磁盘读写能力的配置。

通常情况下，"provisioning"一个服务在云平台上是一个自动化的过程，在用户选择服务、规格并且发出请求之后，云平台通过其底层管理系统自动完成资源分配和配置。这个过程可以通过API调用、云管理控制台或者基于模板的配置管理工具来完成。

"Provisioning"与"Deprovisioning"相对应，后者意味着在不再需要服务时，资源将被释放和回收。这是云计算提供的一个关键优势——即按需分配（provisioning）和释放（deprovisioning）资源，提高资源利用效率并降低成本。

所以，上面这段英文的意思是：

Provisioned IOPS SSD 卷是一种云存储解决方案，它提供一致的IOPS性能，用户在创建该存储卷时指定这个性能的数值。亚马逊的弹性块存储（EBS）服务承诺99.9%的时间都能提供用户预配置的性能水平。

简言之，这句话说明了以下几点：

• 存储卷类型：这里讨论的是一种SSD类型的EBS存储卷，这种存储卷支持用户设定预期的IOPS。
• 性能一致性：Provisioned IOPS SSD 卷能提供稳定的性能，即一个固定的IOPS率。这表示无论什么时候，无论系统负载如何，用户都应该期望所使用的存储卷具有一致的IOPS表现。
• 性能水平的设定：用户在创建Provisioned IOPS SSD卷时可以自定义所需的IOPS水平，以满足特定应用程序的性能需求。
• 性能保证：Amazon EBS承诺用户指定的预配置IOPS性能将在99.9%的时间内得到满足。这个百分比表明服务的高可靠性，确保用户大部分时间内都能获得他们预期的存储性能。

这样的一个服务层级协议（SLA）为需要高性能和高稳定性的应用程序，比如数据库和高频交易平台，提供了必要的性能保证。

The performance consistency between a Provisioned IOPS volume and a general purpose (gp2, gp3), throughput optimized (st1), or cold HDD (sc1) is going to be better for both random and sequential disk access.

此句话表明使用 Provisioned IOPS 卷能够提供更一致的性能，相较于其他类型如通用目的SSD或各种优化的HDD，在处理随机和顺序磁盘访问时，可以预期更好的表现，这对于性能敏感的应用是十分重要的。这意味着在这些工作负载中，Provisioned IOPS卷将提供更稳定且可预测的性能。

• 预配置IOPS（Provisioned IOPS）卷：这是一种高性能的SSD卷，特别适用于需要高IOPS的应用场景。
• 通用目的SSD（gp2, gp3）：这些是Amazon EBS提供的一般性能的SSD卷，平衡了价格和性能，适合广泛的工作负载。
• 吞吐量优化HDD（st1）：专为吞吐量密集型的工作负载优化，适合大量连续读写操作。
• 冷HDD（sc1）：这种类型的硬盘驱动器专为低成本存储大量数据设计，性能较低，适合不常访问的数据。

Note that for operations with large and sequential accesses, provisioned IOPS are likely less efficient than a st1 volume.

不过，Provisioned IOPS 卷也不是万能的。在大量顺序读场景下，它的性能没有 st1 卷性能好。这是因为 st1 专门为这种场景做了特殊优化（预取？）

IOPS Considerations

• Volume Type: There are multiple volume types with different impacts on IOPS.
• I/O Demand: Most likely the workload has a bursty demand pattern, where consistently high throughput is not as important as meeting spikes of demand. As the workload deviates from this, provisioned IOPS become more important.
• Throughput Limits: The instance will have an upper limit of throughput it can support. For example, an i2.xlarge can support up to 62,500 IOPS. If the number of Provisioned IOPS is even higher than this limit, it’s a waste, because the instance cannot use them all up.

考虑 IOPS 的时候需要注意：

• 磁盘卷的类型
• IO 需求特征：突发需求多？持续高并发需求多？
• 单机 IOPS 上线：每个 EC2 机型能支持的最大 IOPS 是有限的，比如 i2.xlarge 最多支持 62500 IOPS。如果此时 Provisioned IOPS 买得比这个还高，实际是浪费钱，因为用不完比 62500 更高的能力。

Optimal Provisioned IOPS
.
The most common cost waste with IOPS is having too many of them. It is commonly believed that the key to RDS is to have some amount of Provisioned IOPS. Luckily, we don’t have to guess.
.
AWS suggests inspecting the VolumeQueueLength metric for CloudWatch. This metric is reported as IOPS, which means the formula is simple: if VolumeQueueLength is greater than the number of provisioned IOPS and latency is an issue, then you should consider increasing the number of provisioned IOPS.

IOPS 买太大通常是浪费，要因地制宜，不大不小是最好的。确定合适的 IOPS 的方式，在 AWS 上是在 CloudWatch 上看 VolumnQueueLength 指标，如果这个指标比分配的 IOPS 大，同时我们又比较关注延迟，那么就应该增加一些 IOPS。