亚马逊AWS官方博客

S3 成本优化 – Part 2 常见问题以及解决方案

背景

在我们的第一篇博客文章中,我们讲述了一下如何使用Amazon Simple Storage Service(以下简称S3)生命周期,S3批量处理,Athena,CUR等功能对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.不同存储类型的互相转换方式

参考https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/dev/lifecycle-transition-general-considerations.html

其他类型转换都比较明确,但是有一点可能需要注意到的是,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功能对实际数据进行详细的统计。

 

3.使用S3批量处理的时候作业失败,报错Task Target Couldn’t be URL decoded

使用S3批量处理的时候,大家可能会遇到类似这样的报错: Failed to parse task from Manifest XXXXX.csv at bytes offset XXXXXXXX. ErrorMessage: Task target couldn’t be URL decoded.这是由于提供的清单文件csv文件中有一些前缀含有非Unicode字符,原理是由于S3批量处理需要文件夹目录和文件名对于特殊字符已经经过转码处理(比如空格,百分号等)。

解决方式:开启清单模式的时候不要选择ORC或者Parquet,仅选择csv格式开启清单,这样生成的清单文件就会已经经过自动转码处理。

 

4.正常情况下删除文件是不收费的,但是优化之后在下月账单或者CUR中发现了DeleteObject收费

这是由于IA/智能分层/Glacier/Glacier Deep Archive这几个存储类别都有最少存储天数的要求,如果优化过程中删除了某些文件,但是这些文件没有达到相应存储类型的最少存储天数的要求,那么就会产生一次性的删除费用,补齐这些文件如果继续存满最小天数之后需要缴纳的费用。对于这几个存储类型, 最少存储天数要求分别是 , IA和智能分层最少30天,Glacier最少存储90天,Glacier Deep Archive最少存储180天。

解决方式:没有解决方式,因为这是正常的使用费用。

 

5.使用S3批量处理或者生命周期转换文件的时候有部分文件并没有被转换

这是因为这部分文件大小小于128KB,小于128KB的文件无法被转换为IA或者智能分层存储。

解决方式:使用S3清单,查询Athena排除小于128KB的文件,再使用S3批量处理进行转换到IA或者智能分层。使用生命周期的话无法排除,会直接不处理这些小文件,也不会收取额外费用。

 

6.小文件转换为Glacier和Glacier Deep Archive可能会造成成本上升而不是下降

由于S3在将文件转换为Glacier或者Deep Archive的时候会自动增加40KB的元数据,其中8KB会继续存在标准存储上,32KB存在对应的Glacier或者Deep Archive。所以8KB以下的文件转换到Glacier或Deep Archive可能会让这部分数据存储费反而增加。

解决方式:使用S3清单,查询Athena看小于8KB的文件有多少(具体命令参考上一篇博客文章),如果数量巨大,那么需要查询Athena排除小于8KB的文件,然后使用S3批量处理来做类型转换。如果数量很少可以接受,还是可以使用生命周期做自动转换(但是无法排除小文件)。

 

7.生命周期建立之后很久没有运行,导致成本优化没有进行

生命周期规则每天只会在通用协调时间 (UTC) 的午夜(00:00)运行一次,并且最多需要48小时才能开始运行参考官方文档

https://aws.amazon.com/cn/premiumsupport/knowledge-center/s3-lifecycle-rule-intelligent-tiering/?nc1=h_ls

 

8.S3批量处理作业建立好之后,运行时间很长一直显示运行中。

S3 批量处理转换所需的时间不是数据大小决定的,而是根据您对象的数量决定的。经过测试1天时间大概能够处理2亿文件量。

解决方式:S3批量处理作业会显示完成百分比,失败百分比等等。所以可以根据已经进行的时间预计完成时间。

 

总结

至此我们详细讲述了S3成本优化过程以及可能遇到的各种问题和解决方法,但是长期来看还会有进一步优化方案,比如改进应用将不需要频繁访问的文件直接上传为IA以节省后期转换费成本,应用上传文件的时候就打好业务标签以便于以后优化分析等等,但是由于不属于对已有的成本优化而是未来架构方面的优化,本文就不再一一探讨。最后希望大家在使用AWS的时候能更有效率的使用S3服务。

本篇作者

熊厚

AWS技术客户经理,负责企业级客户的架构和成本优化、技术支持等工作,致力于金融区块链等行业,曾供职于IBM,汤森路透等,拥有12年以上的产品设计、IT 架构、运维经验。