Finops成本优化企业实践-可优化篇

引言：即上一章讨论了finops的第一步--可视化之后，本篇继续讨论finops第二步--可优化，其中涉及到可视化的部分请读者移步致上一篇。

笔者今年在项目上完成了40%的费用节省，从一月份的每月9万美刀降至十月份的每月5万多美刀。本篇会把我在项目上省的每一笔钱的方法都详细讨论，供大家参考，可所谓是干货中的干货。但有两点要提醒大家注意：一，优化阶段要做的慢一些，要非常谨慎。优化的本质是减少单位时间的资源使用，而面对减少的资源，要有完备的监控覆盖，以及演练过的应急预案，要做到删之前先恢复一遍。我计划后续写一篇以稳定性治理的思维去做finops。二、凡可道者，非恒道也。任何方法，不可一概而论，不要拿来就用，一定要结合实际分析而定。

本文例子多引用AWS产品。

一、冗余资源优化

按照可视化篇所分析的优化方向，第一优先级是盘点冗余资源。尤其是开发环境和测试环境。删除不在使用的资源。比较常见的冗余资源如下：

ebs是最容易存在的冗余资源，可以到ebs列表里查看其状态，当状态是‘available’时，表明这个ebs没有被任何ec2使用或挂载，可以直接删除（但凡被挂载到ec2上的ebs是无法删除的，即便ec2关机了也无法删除）

snapshot

最容易被遗忘的冗余资源，snapshot通常由于系统升级等变更需要保留一份历史版本，或者设置了定期生成快照的策略，如果没有删除策略，长期会积压很多snapshot，建议定期删除或者配置删除策略，比如删除半年前的snapshot；或者每个应用保留若干个版本，其余删除。在aws中，snapshot提供生命周期管理器功能，可以制定什么时候开始备份、保留几个版本。

vpc endpoint：

vpce是隐藏最深的冗余资源，通常在开发环境和测试环境在部署前期很容易创建多余的vpce。可以通过费用分析工具（如aws 的cost explorer）列出vpc服务的费用占比（详细方法在上一篇有讲），同时再结合监控工具（如aws 的cloudwatch）查看具体某个vpce近期的流量，如下图，三个月了都没有连接进来，可以考虑删除。

在测试或开发阶段多余创建的ec2，或者做蓝绿升级时遗留下来的ec2未删，确认不再使用后可及时删除。如有需要可以先关机，但即便关机也会计费（ebs费用）。

Kubernetes cluster：eks cluster有一个隐藏费用，即版本过期的支持费用。云厂商一般会建议用户升级到最新的Kubernetes版本，对于较老的版本会收取支持费用，而且这笔费用不便宜。在开发或者测试环境，容易忽略集群的版本升级，从而导致而外的支持费用，而且这笔费用还不好找出来，在aws cost explorer里，过滤eks服务并group by api，即可看到一项extendedsupport fee。

二、即开即用策略

非工作时间自动shutdown

常用于开发环境。开发环境下班后是没有人在使用的，可以考虑设置固定时间关机，并在上班前开机。对于集群应用，直接在auto scaling group里设置比较方便；对于应用部署在单个ec2上的，稍微比较麻烦，需要借助lambda脚本，通过对ec2打标识别，调用aws提供的api，例如在python里引用库boto3，可以调用ec2.start_instances来启动。

工作时间也保持shutdown

对于测试环境，通常只有要做功能测试时才会使用，不同于开发环境需要整个工作时间都打开。但如果在用的时候打开、用完了关掉，会非常耗费人力成本。我们的策略是：在下班时间点设置统一的关机策略，但第二天早上不会自动开机，谁要用，谁去触发开机。一旦开机了，一整天都让它保持开机状态，不主动关机，直到下班触发关机策略。同时把开机动作脚本化，尽量减少人力投入时间。

对于开机动作脚本化，我们可准备好简单的shell脚本放到dev机器上，调用aws cli开机，以下是一些列子：

单体应用部署在ec2上, 直接执行：

aws ec2 start-instances --instance-ids i-1234567890abcdef0

对于集群应用，可以通过autoscaling执行：

aws autoscaling update-auto-scaling-group --auto-scaling-group-name [group name] --desired-capacity [n] --min-size [min] --max-size [max]

三、低峰缩容策略

在考虑低峰缩容时，可将应用分为两类。一类是计划性任务较多，比如大数据应用，有很多定时任务在跑，这类应用可以很好地把定时任务腾挪到一个时间段，例如集中到凌晨或者白天。那么在低峰期时可采用固定时间段缩容。不过一定要评估清楚缩容后的资源能不能支撑起峰值。以一个kubernetes cluster举例：

假设我们有一个kubernetes集群，集群上跑的是定时的数据分析任务，每当跑一个任务时，kubernetes会新起一个pod，每个pod申请的资源固定是2c4g。在缩容时我们需要考虑两个点：一是实际使用资源（$limit-a)小于总资源的上限。pod虽然申请了2c4g，但它不一定用得完。那么$limit-a我们通过监控工具如zabbix就可以评估出来。二是单位时间内申请的总资源上限（$limit-b）。假设某一分钟内启动了100个任务，即100个pod，那么瞬间会申请到2c4g * 100 的资源，即便实际使用的资源不会打满，但如果$limit-b超过了集群总资源，那将会有pod起不来，这是我们需要避免的情况。所以缩容后的总资源既要大于$limit-a，又要大于$limit-b。在评估$limit-b时，如果按照分钟级叠加pod的申请资源总和，那就太累了，退一步可以按照小时级来评估，例如选取每周内的某天，叠加每个小时内的mem，很容易可以看出来低峰期的时段在哪、峰值在哪。如例图（纵坐标是单位小时内所有pod申请的mem叠加，横坐标是24小时）：

然而对于非计划性任务，可根据cpu使用率来自动扩缩容。实现方法有很多，例如AWS提供的auto scaling group可以设置动态扩缩容策略，根据利用率、网络流量、或者cloudwatch上的某一报警，来控制集群中的节点数。亦或者kubernetes本身提供的水平Pod自动伸缩（HPA）、垂直Pod自动伸缩（VPA）、集群节点自动伸缩（Cluster Autoscaler）。对于优化资源使用率这个话题比较大，不在本篇赘述。Finops官网内容中专门有一章节讨论finops在容器中如何落地，后续笔者会专门写一篇容器篇来讨论。

四、Spot替换策略

Spot是AWS中ec2购买方式的一种类型，AWS会将ec2某一实例类型的空闲资源池来出来以极低的价格售卖，享有按需的便利，同时抵过RI和saving plans，但缺点是会随时回收。这样的特性非常适合于批处理任务和大数据分析的应用，这些应用可以容忍中断，或者从中断地方继续执行。但在实施缩容时，建议优先分析业务高低峰时段，如果在高峰时段频繁中断任务，可能会造成数据延迟。可以采用组合策略：在业务高峰期采用按需容量、跑非核心任务采用spot、低峰期缩容实例。

例如一个AWS EMR集群，有主节点、核心实例、任务实例组成。在非核心任务期间，我们把任务实例全换成spot，可以通过aws cli实现：

aws emr modify-instance-fleet --cluster-id j-2HYAWOD0XGPS7 \
--instance-fleet InstanceFleetId=$SpotInsTaskGroupId,TargetOnDemandCapacity=0,TargetSpotCapacity=$SpotTaskNum

在周末任务较少时，我们把核心实例、任务实例缩容。也是通过以上代码，把 InstanceFleetId换成核心实例组的id。把整体逻辑写到shell脚本里并放到crontab计划任务里执行。

五、合理的容量匹配

对于单体应用的缩容，通过监控工具判断其合理的资源使用水位，并修改到对应的实例大小。例如利用zabbix，或者云厂商自带的cloudwatch监控工具，观察近一个月或者三个月的cpu利用率和内存使用率，即可得出该应用的最大负载。需要注意的是，在应用层中要限制应用本身对资源的申请。例如，应用部署在一台4c8g的ec2上，其上主要在跑java进程，那么java的最大堆内存不Xmx能超过6g。这部分相对比较简单，就不在举例了。

六、跨AZ优化

当考虑到集群高可用时，首先想到的是跨AZ部署。然而跨AZ部署会带来一个潜在问题：AZ的流量费用。集群内是否存在ec2跨AZ调用取决于应用性质。例如一个大数据应用，需要在node之间做map-reduce，会存在大量的调用。具体费用可以通过账单里查询。例如用aws的账单分析工具cost explorer，通过api filter，选择interZone，即可过滤出来。如下图中是ec2-other里通过api filter的构成费用。

七、存储资源设置house keeping policy

存储资源主要针对S3等对象存储。通常S3的费用能排到前五。对S3的house keeping policy，同样也是借助成本分析工具，我们可以先过滤出归档层的top5 bucket有哪些，注意归档层的数据是超过90天没有访问的，也是最容易满足回收条件的。过滤出来之后还不够细，需要开启S3 inventory，列出这些桶每个目录的大小，并根据业务需求设置lifecycle policy。

以aws cost explorer举例，以tag-Name作为group by维度，以s3的intelligentTieringAIAstorage 为filter，可过滤出归档层的bucket。（因我的环境有敏感数据，不便展示）

然后到对应的桶中制定生命周期规则，注意范围一定要筛选到file级别：