发布于: May 19, 2021

云存储服务优化伴随着云存储服务的广泛推广,逐步受到人们的重视。Amazon S3 云存储服务提供了一种持久安全可扩展的云存储解决方案来备份、存储大量数据,为各种各样的使用案例提供低成本高效的对象存储服务。在接下来的这篇文章中我们会讲述一下对 S3 优化过程中会遇到的常见问题/注意事项以及如何解决这些问题

实际例子

首先我们先看一个 S3 成本优化的案例(以下所有费用以美东1 佛吉尼亚为例):

比如目前一个 S3 存储桶现状是

标准存储 :文件大小 3000TB 大约存储成本 65000$/ 每月,一共 30 亿文件数

Glacier :文件大小 2000TB 大约存储成本 8200$/ 每月,一共 50 亿文件数

现有生命周期:超过 6 个月的数据自动转换为 Glacier,超过 3 年的数据自动删除

每个月新增 4 亿文件数,这部分新增文件大小为 200TB,每个月新增文件数相同,所以同样会有 200TB 的文件自动转换为 Glacier。

现有每月成本为 9.4 万 $: “标准存储费 65000$”+“Glacier 存储费 8200$”+“每月新增 Glacier 存储费 200X1024X0.004=820$”+“生命周期转换费400,000,000X0.05X0.001=20,000$”

如果考虑到 Glacier Deep Archive 比 Glacier 便宜很多的情况,直接选择方案将现有生命周期修改为 – “超过 6 个月数据自动转换为 Glacier Deep Archive“, 保留“超过 3 年的数据自动删除”

优化后第一个月成本为 31.7 万$:“标准存储费 65000$”+“Deep Archive 存储费2000X1024X0.00099=2028$”+“每月新增 Deep Archive 存储费200X1024X0.00099=203$”+“一次性生命周期转换费5000,000,000X0.05X0.001=250,000$”

之后每个月成本为            8.7万:“标准存储费65000$”+“Deep
Archive存储费2000X1024X0.00099 =2028$”+“每月新增Deep Archive存储费200X1024X0.00099=203$”X2+“每月生命周期转换费400,000,000X0.05X0.001=20,000$”

综合比较,第一个月多付出 22.3 万$,第二个月开始每个月节省 7000$,长期来看需要 31 个月才能开始收回这一次“优化”的成本,而且由于已有的 Glacier 文件本身会在 3 年后删除,对他们进行再次转换损失的成本远远高于不转换的成本。
由此,可以基本定义此方案为优化失败。

可以从例子中总结出 – 注意优化中的各种费用和特定问题是成功优化成本的关键。

常见问题列表和对应解决方式

常见问题 1.不同存储类型的互相转换方式

参考资料

其他类型转换都比较明确,但是有一点可能需要注意到的是,Glacier 虽然正常情况下需要解冻才可以读取里面的文件,但是可以不经过解冻直接转换为 Glacier Deep Archive,而且因为 Glacier Deep Archive 是 2019 年才推出的新服务,很多客户可能目前的 S3 桶上都有 Glacier。 如果没有意识到这一点,新增生命周期或者修改已有的生命周期为转换到 Glacier Deep Archive,不仅仅其他类型会转换为 Deep Archive,Glacier 本身也会转换为 Deep Archive。对于已经使用 Glacier 很久的客户这可能会导致一份很高的单月转换费用,需要特别注意。(比如本文开始提到的案例)

解决方式:

a.使用第一篇博客中提到的方法,用 Athena 查询出来非 Glacier 文件列表,然后使用 S3 批量处理做一次性转换为 Glacier Deep Archive。 优点是没有其他额外费用生成,但是无法做到长期自动化,需要每个月手动操作。

b.可以使用S3批量处理单独给所有非 Glacier 文件打标签,然后之后上传的文件也使用应用打好标签,之后用生命周期根据标签转换为 Glacier Deep Archive,从而排除已有的 Glacier。优点是可以实现长期自动化,但是标签本身也有费用,1 亿个 S3 标签的费用为 100$/ 每月,需要考虑这部分额外费用。

常见问题2.避免使用大致的文件数量和文件大小做预估

默认在不开启任何特殊功能的情况下,大家可以在 S3 控制台中看到全桶统计的所有文件大小(BucketSizeBytes)和所有文件数量(numberofobjects)。

通过 S3 控制台–存储桶界面–管理–指标–存储 可以找到。 如下所示:

但是这并不能给我们太多指引,因为平均文件个数,平均文件大小在实际生产中根据前缀(prefix)和应用不同可能会有很大差别,所以并不一定每个存储类型中的平均文件大小都是一致的。比如按照本文开始提到的例子使用平均算法来看的话,标准存储为 30/50* 80 亿=48 亿文件数,Glacier 为 20/50* 80 亿=32 亿文件数,跟实际值误差超过 60%,如果使用不准确的数据进行优化方案推测,优化结果也可能会差别非常大,无法达到预期效果。

解决方式:使用我们在前一篇博客中提到的开启 S3 清单功能,然后使用 Athena 功能对实际数据进行详细的统计。

相关文章