网站建设最简单的教程视频教程,wordpress点餐主题,宁波本地网站排行,建设网站深圳市引言#xff1a;上一章讨论了finops的一些方法论#xff0c;笔者在拿到finops官方认证finops-engineer certificate之后#xff0c;将方法论运用到所在项目组中#xff0c;并于今年完成了40%的费用节省。在此将这些实践方法总结沉淀#xff0c;与大家分享。实践包括三篇上一章讨论了finops的一些方法论笔者在拿到finops官方认证finops-engineer certificate之后将方法论运用到所在项目组中并于今年完成了40%的费用节省。在此将这些实践方法总结沉淀与大家分享。实践包括三篇可视化篇可优化篇可规划篇。这三篇里不讲太多理论主要以实践为主干货满满理论部分可以看上一篇。
一、月度账单分析
1. 目的
可视化的目标就是讲清楚你在云上花的每一笔钱。在起步阶段不需要在这一步花费太多时间遵从“爬、走、跑”原则在较短时间内把top5的cost分析清楚后面优化阶段够你省的了。
我之前做TAM的时候服务的一家客户一家做ERP的公司领导层决定做finops项目于是上来就要先搞个可视化平台于是平台从开发到上线三五个月过去了还没进入优化阶段呢。
2. 方法
最省事的方法不是最快最快的方法是把我请过去做让你们的云厂商来做。找到你们的TAM让他每月做一个月度账单汇报并给出优化建议。
当然这个方法也有一些弊端厂商不够了解你们的业务不了解你们这个月做了什么事情。比如你们这个月对集群做了一次蓝绿升级遗留了一堆实例和ebs或者你们对跨az的eks集群扩缩容了遗留了一堆pvcebs不支持跨az挂载或者你们对应用升级了打了一堆计划之外的snapshot等等厂商看着就会很懵。
自主分析依托厂商提供的工具以不同分组和纬度组合得出你所需要的数据。本篇以AWS提供的cost explorer为例阿里云、腾讯云、华为云都有类似的工具。
3. 方向
账单分析的下一步是优化那么优化的方向是我们需要在分析阶段break down的。不要上来就想着把最贵的干掉确定优化方向要结合考虑业务稳定性、难易程度、人力投入成本。我推荐从以下四个优先级来做
3.1 冗余资源
首先识别出多余的、不用的资源删除不会有任何业务影响的资源这部分也是比较容易识别的。例如没有使用的ec2没有挂载的ebs时间久远的snapshot不再使用的vpc endpoint等等。
3.2 能快速恢复的资源
一些可快速恢复的资源删减后可以快速恢复对业务影响时间较短可以放到第二优先级。常见于集群的自动扩缩容、spot节点替换、standby节点缩规格等。
3.3 人力成本投入较大的资源
前两个优先级做完后基本可以省下一笔可观的钱还想要继续深度优化的话就要考虑一些投入比较大的、当然产出也比较可观的调整。比如架构优化或者体系化地做资源整体的回收策略。
3.4 无法恢复的资源
这不一步不推荐做尤其不推荐放在不成熟的finops阶段做。要做这不一定要把稳定性做的非常成熟再做我计划再写一篇稳定性篇来讨论finops的稳定性如何做简单讲面对不可恢复的资源要做好监控覆盖、应急预案、应急演练之后且省无可省了再考虑做这一步。
讲一个真实的案例可以跳过某部门新上任了一位部门领导在做成本优化时已经在月度分析的报告中告诉了他计算资源、网络资源的占比是最高的存储资源其次我们应该优先分析计算资源但他偏不很倔强地定了一个决策要清理aws S3存储桶里的数据把该删的删了不用的放冰川层。于是拉着一帮人去分析哪个数据是给哪个业务部门用的、花多少钱、占比多少这三个问题在没有充分打标时是非常难统计的尤其存储大小和费用的关系当开启了智能分层时。S3我们没有打标签全靠bucket name人肉分析花了一个来月。然后开始做house keeping用life cycle左加一条规则又加一条规则对着20几个桶加出了快上百条life cycle policy一点都不优雅最错误的一步是挪到冰川层standard是0.25 $/Gb/month本来我们开启智能分层自动放进归档层只需要花费0.05$/Gb/month已经很省了为了再省3分钱冰川层是哦。0.002$/Gb/month要强行挪到平川层。挪到冰川层只有两个结果一是彻底不用那为什么不直接删掉二是等待恢复恢复费用超级贵的除非你能放三年不用。结果挪到冰川层的第二天欧吼有人要用数据于是开始紧急恢复关键还没做恢复预案临时提单给厂商帮忙恢复花了较多时间恢复。在下一个月的账单里S3不仅没有省钱倒花两千美金恢复数据等恢复之后再过一个月我们看到节省的效果只有1500$然而却花了几个月的人力投入。
4. 维度
列出top5 的资源没打标签之前先以service纬度列出可以是饼状图或者柱状图主要先定下我们优化的service定了主要优化目标后再继续往下细拆。
例如我把成本按照service分组可以看出70%的成本来自于ec2而14%的成本来自于S3那么接下来我的分析重心就是ec2。 再往下拆在ec2里面instance占比67%other占比33%再把other细拆流量占到大头流量费用即图中的interZone-in, interZone-outec2的流量来源于实例之间跨AZ的访问我们发现是一个大数据的应用集群部署在了3个AZ上而它每次做map-reduce时在集群内部就会产生大量跨AZ调用导致流量费用升高。于是有了action1调整应用集群的部署AZ来减少流量费用。再看图中存在gp2的使用gp2相比gp3较贵性能也差应该全部替换或删除掉。于是有了action2替换gp2为gp3清理没有挂载的卷。 对于ec2的instance分析我们可以打上应用的标签注意如果要展示费用明细不同维度的过滤方式可能会有重叠比如按照应用分析A应用的ec2总费用会包含ebs、ec2之间的流量、snapshot如下图所示在确定应用的比重之后可以继续细分比如按照实例类型、api调用等。具体计算资源的优化方案会在规划篇详细介绍。 接下来是存储的细分这里的存储特指对象存储而非EBS存储卷因为通常来讲对象存储的占比会是一个大头EBS只是很小一部分而且随着EC2的优化就被优化掉了。以AWS S3为例S3存储桶有一个天然优势即它自带一个key就是它的name。所以我们可以得到每个存储桶所花的费用占比所以我们可以很明确地得出哪个桶是我们最需要关注的。如图 对于S3有两个维度一个是存储维度一个是请求维度这两个维度都必须搞清楚它的细节以及计费规则才可有效优化。我们先从存储维度谈起S3的存储分为如下几层 在存储维度有很关键的一步就是开启智能分层让数据自动归类不需要琢磨着把它放到冰川层。如果想针对某个桶做house keeping那么可以先过滤出具体的桶名再以存储的维度展示那么归档层占比较大的桶就是我们首先做house keeping的对象。
下一个是请求维度按照请求维度可以看到具体哪个桶的读写请求最多再结合access log查询出是什么应用在调用数据是否合理。 例如下图可以看到二月份的list bucket和get object请求特别多可以进一步查询是哪个服务的调用增长。 5. 灵活运用api过滤和cloudtrail
在展示的时候AWS的cost explorer还提供了一个很好的维度即api。例如上图中ec2-other和s3 request都是通过api过滤出来的可以详细看到里面的内容。
结合使用cloudtrail来定位具体费用通过cloudtrail可以看到具体的资源、对象、时间、账号的事件。例如S3中某个请求在某一天调用频繁可通过cloudtrail追踪具体是哪个账号在调用。
6. 指标
还记得公式 费用 单位时间资源使用量 * 费率 吗其中的费率可以作为我们观测的主要指标例如RI覆盖率、saving plans覆盖率。当覆盖率接近100%时才证明我们充分利用了RI和saving plans。
如图在周一到周五时我们对集群扩容从而使用的按需实例较多没有被saving plans完全覆盖而周末对集群缩容刚好让所有的实例都被saving plans覆盖住。后续在做计划性的扩缩容时可参考这一指标。 二、异常检测告警
1. 阈值告警
分析报告通常一个月做一次但如果遇到天级别的问题那么可以设置阈值告警例如可以针对某一应用设置天级别的阈值当超出阈值时发送邮件告警。
2. 异常告警
开启AWS 异常告警功能当费用忽高忽低时会发出警告。
三、关联服务费用
有一些服务的费用会相互关联比如
当glue频繁调用S3时S3的读写请求费用会增高如果开启了kms加密传输那么kms加密解密的费用也会增加guardduty扫描S3 bucket的费用也会增加在guarduty里也能看出具体哪个桶费用最高也是一个辅助分析的方式。
