构建和维护星球最强对象存储系统的一点微小经验

木鸟杂记

发布于 2023-11-14 18:44:52

1440

发布于 2023-11-14 18:44:52

本文来自 Amazon S3 VP Andy Warfield[1] 在 FAST 23 上的主旨演讲的文字稿[2]，总结了他们在构架和维护如此量级的对象存储 —— S3 的一些经验。我们知道，Amazon S3 是云时代最重要的存储基础设施之一，现在各家云厂商的对象存储基本都兼容 S3 接口，所有云原生的基础设施，比如云原生数据库，其最终存储都要落到对象存储上。

截至 2023 年，Amazon S3 自 2006 年上线以来，已经 17 岁了。在开始之前，我们首先看下Andy Warfield 给出的一组数据，来感受下星球最强的对象存储已经到了什么量级：

AWS S3 的一些指标

即，

容量和吞吐：超过 280 万亿个对象，QPS 平均超过 1 亿 / s
事件：每天 S3 会向 serverless 应用发送超过 1250 亿个事件
冗余：每周超过 100 PB 的数据冗余
冷存储检索：每天都要至少从 S3 归档存储中回复 1 PB 数据
数据完整性校验：每秒进行 40 亿次完整性校验计算

对这个量级有了直观的感受之后，我们来看看 Andy Warfield 分享的经验。为了方便叙述，下面都用第一人称——我们，意指 S3 团队。

HDD 对 S3 设计的影响

虽然 SSD 在价格上已经越来越便宜，但对于 S3 如此量级的存储来说，仍然大量采用 HDD。其中一个重要原因仍然是成本优势（存储密度和寿命都很棒）。相对其最初诞生时期，HDD 体积缩小了 5k+ 倍、单字节成本更是便宜了 60亿倍！然而，受制于机械特性，其随机访问延迟只降低了 150+ 倍左右。

S3 刚上线时，HDD 的满载 IOPS 大概是 120，这个数值在这么多年间基本没有变过。HDD 这种存储密度越来越高，但访问延迟却一直停滞的特点，给 S3 的设计带来了很大影响—— 必须想方设法将流量均摊到不同硬盘上去，避免单块盘的 IO 过载。

热度管控：数据放置和性能

基于上述原因，S3 在不断 scale 的同时，所面临的最主要和有意思的问题之一就是：如何在如此多的 HDD 上管理和均衡 IO 流量。我们称该问题为——热度管控（heat management）。

所谓热度（heat）：就是任意时间点，某个磁盘承受的 IO 请求。如果管控不当，造成不同磁盘间流量的严重倾斜，就会造成数据局部访问热点（hotspot），从而造成长尾效应（“stragglers”）。这些长尾请求通过 S3 的存储软件栈（software storage stack）层层放大之后，可能大范围影响请求性能。为了解决这个问题，我们需要仔细考虑数据放置策略（data placement）。

通常来说，由于无法在数据写入时（即进行放置决策时）预知其之后的访问模式，我们很难用一个策略消除所有用户的访问热点。但由于 S3 的量级以及多租户机制，我们可以进行完全不同的设计。

我们发现一个特点：在 S3 上运行的工作负载越多，不同对象请求间的去相关性（decorrelated）就越强。对于用户的单个存储单元来说（比如一组 Object，或者一个 Bucket），其通常的访问模式是：长时间沉寂后，突然一个远高于平均值访问高峰。但是当我们聚合了百万计的请求之后，非常有趣的事情发生了：聚合请求总量的变化曲线变的非常平缓，且出现了某种内在可预测的规律。可以看这个视频[3]直观感受下。