发布于: 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 功能对实际数据进行详细的统计。
相关文章