Canva 每年如何节省超过 300 万美元的亚马逊 S3 成本

Canva 是一款在线设计工具，它使全球用户能够设计、编辑和发布他们能想到的任何东西。Canva 使用多种核心服务在 亚马逊云科技 上运行大部分生产工作负载，包括 亚马逊 S3、亚马逊 EC S 、 亚马逊 RDS 和 亚马逊 Dy namoDB 。过去 10 年来，在 亚马逊云科技 上运行有助于 Canva 快速发展并跟上我们用户群的快速扩展。自2013年推出以来，Canva的网站已从不起眼的起步发展到每月超过1亿活跃用户，他们共同创作了超过 150亿个设计！ Canva 现在的用户遍布 190 个国家，他们使用 100 多种语言 进行设计， 这要归功于我们的国际化团队所 做的出色 本地化工作 。

Canva 设计通常从 模板 开始 ，让创作者可以轻松地从我们精选的 7500 多万张库存照片和图片库中提取图像、图形、动画和 视频。 但是，与我们存储的内容总量相比，这个数字相对较小。这是因为Canva允许每个品牌创建和发布自己的模板、媒体和其他内容，从而导致我们需要存储在某个地方的用户生成的内容激增！

Canva 演示文稿的特定品牌模板

Amazon S3 为我们提供了可靠、极其耐用、低成本的存储解决方案。特别是，Amazon S3 提供了针对不同访问模式和工作负载设计的各种存储类别。了解这些 S3 存储类别之间的差异对于经济高效地大规模运营至关重要。在Canva的生产环境中，我们在Amazon S3中存储了超过230 PB的数据，其中最大的S3存储桶高达45 PB！在这篇博客文章中，我们将深入探讨如何了解这些海量数据，以及将大量数据移动 到 Amazon S3 Glacier 即时检索 如何 满足我们的用例并每年为我们节省数百万美元。

亚马逊 S3 存储类别

Amazon S3 有几种 不同的存储类别 可供 您根据工作负载的数据访问权限、灵活性和成本要求进行选择，如下图所示。

图 1：亚马逊 S3 存储类别

对于 Canva 的常用模板、图库照片和图形库，S3 标准存储类别最适合我们。许多用户每天经常访问这些内容，因此将其保存在针对经常访问的数据进行了优化的存储类别中效果非常好。相比之下，用户的设计以及他们上传给他们的图像和媒体往往会在很短的时间内被访问。用户来到 Canva，创建他们的设计， 展示 或 打印出来 ，完成后通常不会返回到旧的设计。对于此类内容，我们历来选择使用 S3 标准不频繁访问（S3 标准-IA）存储类别，因为它比 S3 标准更具成本效益，同时还能提供快速的检索时间。我们在这里稍作简化，因此，如果您想更全面地了解我们多元化的用户群的访问模式，请阅读我们最近的博客文章 “ 通过大规模 频率分段 了解多元化的用户群 ”。

对于某些特定的用例，例如日志存档和备份，我们还使用 S3 Glacier 灵活检索。S3 Glacier 灵活检索非常适合可在几分钟到几小时内检索的数据。对于日志存档和备份，这种要求是可以接受的，它们可能只需要在极少数情况下才能访问，但通常不适合像使用模板、素材照片和图形那样频繁访问用户生成的内容。

当 亚马逊云科技 于 2021 年 11 月推出 S3 Glacier 即时检索时，它为不经常访问的数据、低成本的档案存储和以毫秒为单位的快速检索提供了两全其美的优势。因此，这自然促使我们自问，将不常访问的数据迁移到这个 S3 Glacier 即时检索存储类可以节省多少。我们应该迁移哪些存储桶？

了解我们的数据

虽然我们知道用户生成的内容往往会在创建后不久被访问，但我们并不完全确定故障情况。我们之前使用过 S3 生命周期策略 ，该策略 会在 30 天后将数据从 S3 标准转换到 S3 标准-IA，但没有对节省情况进行分析。可以让我们对该领域有所了解的新发布的工具是 S3 存储类分析 ，我们可以按存储桶级别开启该工具。存储类分析提供了一些图表，这些图表提供了有价值的见解。

下图仅引用存储在 S3 Standard 中的数据，并显示存储的总字节数和按年限（即自数据创建以来的天数）细分的检索率。由于前面提到的生命周期策略，存储的总字节数在30天后急剧下降。根据我们之前提到的预期访问模式，在最初的15天之后，检索率也急剧下降。

图 2：一段时间内的 Amazon S3 标准存储访问模式

下一张图表显示了相同的信息，只是针对存储在 S3 Standard-IA 中的数据。存储的字节看起来有点奇怪，但是仔细观察天轴会发现时间段变长了（前 15 天，然后是 30 天，然后是 180 天，然后是 365 天）。如果你将此图表展平，使其时间段间隔相等，则它看起来与Canva随着时间的推移用户增长非常相似。但重要的是，所有时间段的检索率似乎都相当平稳。

图 3：一段时间内的 Amazon S3 标准 IA 存储访问模式

我们分析中的最后一张图表显示了每个存储类别中存储桶中访问的数据总量。在这个特定的存储桶中，总数据中大约有10％存储在S3标准中，而90％存储在S3标准-IA中。该图显示，在所有访问的数据中，有60-70％来自S3标准，而30-40％来自S3标准-IA。这与 S3 的存储类定价 模型非常吻合。S3 标准的每 GB 存储成本更高，但数据访问成本非常低，而 S3 标准 — IA（和 S3 Glacier 即时检索）的每 GB 存储成本较低，但数据访问成本较高。

图 4：一段时间内相对的 Amazon S3 存储类访问模式

这种数据访问是我们用来存储用户生成内容的许多存储桶的典型情况。因此，我们可以添加 生命周期策略 ，将所有内容转移到 S3 Glacier 即时检索并称之为一天，对吧？好吧，就像软件中的所有内容一样，这要视情况而定。

过渡成本

在 S3 存储类别之间转换对象时，您需要按请求付费。例如，将对象移至 S3 Glacier 即时检索的费用为每 1,000 个对象 0.02 美元。但是，我们在Canva的S3库存中包含超过3000亿个对象，因此，在不考虑的情况下过渡所有内容将花费超过600万美元。这是为什么最大限度地提高存储成本可见性并充分了解数据足迹很重要的另一个原因。

有趣的是，这种过渡成本取决于我们正在移动的物体的数量。同时，S3 Glacier 即时检索可能节省的费用主要来自存储类中的总数据量。此外，转换所有数据的成本是一次性收费，而更便宜的存储类别所节省的费用仍在继续。

这意味着我们可以根据存储桶中的平均对象大小来计算从 S3 标准版迁移到 S3 Glacier 即时检索以实现收支平衡所需的大致时间。例如，如果您需要过渡少量非常大的对象，则效果很快就会发生。或者，过渡大量小对象可能需要几个月的时间才能实现收支平衡。我们对 S3 Standard-IA 做了同样的分析，因为为了节省成本，我们已经在存储类中拥有了大量数据。

图 5：亚马逊 S3 标准版到亚马逊 S3 Glacier 即时检索盈亏平衡点（月）和亚马逊 S3 标准版到亚马逊 S3 Glacier 即时检索盈亏平衡点（月）

图表的 x 轴从左边开始，为 128 KB，因为这是 S3 Standard-IA 和 S3 Glacier 即时检索中对象的最小可计费大小（即使您的对象小于 128 KB，您仍需按 128 KB 计费）。因此，对于低于 128 KB 的对象，从 S3 Standard-IA 迁移到 S3 Glacier 即时检索时实现收支平衡的时间是恒定的，因为所有对象都按照 128 KB 计费。你可以在下图中看到这一点。

图 6：亚马逊 S3 标准版到亚马逊 S3 Glacier 即时检索盈亏平衡点（月）和亚马逊 S3 标准版到亚马逊 S3 Glacier 即时检索盈亏平衡（月）与平均对象大小（KB）

该图探讨了小于 128 KB 的对象的盈亏平衡点。需要再次注意的是，S3 标准-IA 和 S3 Glacier 即时检索中的对象始终按照 128 KB 计费。因此，在某一点（大约 20 KB）中，在 S3 标准中存储对象比在 S3 标准版或 S3 Glacier 即时检索中存储对象更具成本效益。

重要的结论是，在平均对象大小较大的存储桶上更快地将对象从 S3 Standard-IA 移动到 S3 Glacier 即时检索，我们将看到正的投资回报。在进行此分析时，我们决定首先将平均对象大小等于 400 KB 或以上的存储桶（采用上一节中的适当使用模式）作为目标，因为这些存储桶将在 6 个月或更短的时间内显示出正的投资回报。

结论

关于迁移工作，几乎没有什么可写的，这是工程师的梦想！我们对每个存储桶应用了生命周期策略，并在大约两天内快速迁移了近 800 亿个对象。在撰写本博客时，Canva在S3中的总共230 PB数据中，大约有130 PB存储在S3 Glacier即时检索中。我们发现它作为降低我们不经常访问的用户数据成本的工具非常有价值。它提供了 S3 Standard-IA 和 S3 Glacier 灵活检索两全其美的功能。

得益于这些变化，Canva每月可节省大约30万美元（每年360万美元），而且鉴于我们存储的用户生成数据量不断增加，这些节省的费用会随着时间的推移而持续增长。请务必记住，这些节省需要我们首先了解数据的访问模式，并一次性支出 160 万美元来迁移大约 800 亿个对象。总体而言，这意味着我们在过渡仅几个月后就看到了正的投资回报率，这仍然非常棒！

在所有这些工作中，亚马逊云科技 一直是很好的合作伙伴，并将继续投资于适合用途的存储类别，以帮助客户处理任何规模的用例。感谢您阅读这篇博客文章！不要犹豫，在评论部分留下您的反馈。

这篇文章中的内容和观点是第三方作者的内容和观点，亚马逊云科技 对这篇文章的内容或准确性不承担任何责任。