Mark Olson 参与 AWS Elastic Block Store （EBS） 的开发已有 10 多年，他发表了一篇博客文章，回顾了 EBS 如何从依赖共享驱动器的简单数据块存储服务演变为每天执行超过 140 万亿次操作的大规模网络存储系统。
EBS 于 2008 年推出，即 EC2 测试版推出两年后。它始于一个简单的想法，即为 EC2 实例提供网络连接数据块存储，并且只有一两名存储专家和少数分布式系统人员。
在加入 Amazon 之前，Olson 在网络和安全领域工作，并于 2011 年加入 Amazon 时开始从事存储方面的工作。Olson 开始开发 EBS 客户端，该客户端将实例 IO 请求转换为 EBS 存储操作，并且随着 EBS 的发展，几乎参与了 EBS 的每个组件。
计算机与存储交互的基本方式根本没有改变：存储设备和 CPU 都连接到总线，当 CPU 向设备发送请求时，设备要么将数据存储在 HDD 或 SSD 等耐用介质上的内存中，要么从介质中读取数据并将其放入内存中。
当多个请求同时到达时，存储将请求排队并按顺序处理它们。在网络存储系统中，在各个层提供队列，例如操作系统内核和存储适配器之间、主机存储适配器和存储结构之间以及目标存储适配器和存储介质之间。
当 EBS 在 2008 年开始时，大部分存储是 HDD，整个服务的延迟主要由 HDD 的延迟决定。尽管制造商已经做出了各种努力来提高速度，但由于必须将臂移动到旋转盘片上的适当位置的物理限制，HDD 的平均延迟始终为 6 到 8 毫秒。此外，如果数据以碎片化和分布式方式存储，则需要时间来读取，有时可能会出现几百毫秒的延迟。
因此，早期的 EBS 延迟以数十毫秒为单位进行测量，即使增加数十微秒的网络延迟也几乎没有影响。EBS 开发团队将影响另一个工作负载的工作负载命名为“嘈杂邻居”，并努力减少该邻居的影响。尽管他们进行了改进，例如更改驱动器调度算法和跨心轴平衡用户工作负载，但用户工作负载是不可预测的，并且无法实现必要的一致性。
由于 SSD 不受物理臂的限制，并且与 HDD 相比可以非常快速地执行随机访问，因此 EBS 开发团队认为，只需将 HDD 替换为 SSD 即可解决几乎所有问题。2012 年，引入了 SSD，媒体部分的延迟得到了极大的改善，但整个系统并没有像 EBS 开发团队希望的那样得到改善，因此有必要关注网络和软件部分。
通过测量各种指标以提高系统性能，EBS 开发团队研究了“哪些部分应该改进”。他们同时从事短期改进工作和长期架构更改工作。此外，他们划分了开发团队并划分了他们负责的领域，以便他们可以不断改进相同的领域。
EBS 开发团队通过利用虚拟化和开发名为 Nitro 的专用硬件来处理数据包处理，从而提高了处理速度。同时，他们通过开发一种称为“可扩展相关图 （SRD）”的协议来取代 TCP，从而减少了网络开销。Olson 说：“重要的是要始终质疑假设，并通过测量和分析来关注最重要的点。
在这些开发团队的努力下，EBS 的平均延迟从服务开始时的 10 毫秒以上，到 2024 年已改善到不到 1 毫秒。由于 EBS 用作 EC2 实例的系统盘，作为需要强调性能和持久性的存储系统，它具有一些独特的限制，为了将其发展为每天执行超过 140 万亿次操作的大规模网络存储系统，有必要了解跨越多个层的大规模分布式系统， 从顶部的来宾操作系统到底部的自定义 SSD 设计。
Olson 在博客文章的结尾写道：“我们的客户一直在寻求改进，正是这种挑战促使我们不断创新和迭代。
