GTLC全球技术领导力峰会·上海站,首批讲师正式上线! 了解详情
写点什么

上云之后,每年百万成本竟然悄无声息从指缝溜走(内附降本实战经验)

2021 年 4 月 08 日

上云之后,每年百万成本竟然悄无声息从指缝溜走(内附降本实战经验)

当前数字化转型的大背景下,企业上云已经是大势所趋。一方面,企业上云之后享受着云服务带来的便利和效率,与此同时,云上成本浪费也越来越大。


根据全球云管理服务厂商 RightScale 的一份调研报告显示,当下企业级用户云支出的浪费高达 30-35%。在费用支出方面,13%的企业每年在公有云上花费超过 1200 万美元,而 50%的企业每年花费超过 120 万美元。 以大部分企业的标准 120 万美元计算,其一年的浪费为 36-42 万美元,按当前汇率计算约为 234-273 万元人民币。


因此,在上云和使用云过程中,如何在实现业务增长的前提下,合理监测和管理云上成本支出,成为了非常值得研究和探讨的问题,尤其是在疫情阴影没有完全消散的当下,控制运营成本,保证现金流,是每个上云企业必须思考的问题。本文将结合宏观原则和公司自身的实践给大家分享实战经验。

构建云成本监控和管理体系

要管理好云上成本,首先要构建完善的成本监控和管理体系。一般业内比较有代表性的做法是,根据事前规划、事中分析和事后评估三个阶段,分别制定各自阶段的规则,需要注意的是,这三个阶段不是独立和割裂的,而是一个不断完善的闭环体系。企业上云前,对云资源、云架构的选择就好比打地基,地基要打得稳,尤其是架构的规划设计,需要充分考虑未来的扩展性,否则后续会花费巨大的人力和物力去不断的修补甚至推倒重建。企业上云后,云上架构也需要灵活的调整,去适应企业业务的发展变化以及云厂商性价比更高的产品。



来源:https://blog.csdn.net/weixin_42556618/article/details/103314800

事前规划

事前规划需要制定上云规划标准、管控流程、云资源的选型和云架构的设计方案。这里我们主要关注上云规划标准和管控流程。上云规划标准的出发点即为节约成本,因此我们要从影响成本的主要因素下手,对症下药,制定相应策略。


云成本是用户在特定时间内使用特定数量的云资源或服务所产生的费用,像商品的成本一样, 云资源成本由两个变量决定:使用量和单价,计算公式为:成本=用量*单价。


从用量角度看,用量在很多情况下跟时间相关,即用量是资源静态数量与使用时长的乘积。因此企业可以从配额约束和时长约束两方面着手,对资源创建的数量、配额和运行时长等指标设定标准,同时建立配套监控机制,规律性扫描各平台上的资源,一旦发现违规资源及时通报和调整。如: 对日常测试的资源设置时长上限为 8 小时,超时则发出邮件报警通知或直接关闭资源;对时长超过 2 周的资源设置事先申请和预算审批流程。


单价角度,企业可以从区域约束、类型约束和价格约束三方面设定标准。要做好上述三方面约束,首先就是要了解各个云平台的产品单价和相应的折扣方案。了解折扣方案之后,即可整合各项规则,制定最优解。 如:在 AWS CN 平台上宁夏区域的产品单价会比北京区域便宜,在无特殊区域限制下我们可以优先选择宁夏区域。通过限定资源的区域、统一机器类型,以利用 RI (预留实例)来进行覆盖进而获取到单价折扣。


目前各个云厂商都有各自的折扣方案,但大致包括以下类别,大家可以根据需要详细了解。


  • OD:On-demand Instances,按需实例。按量付费,根据实际使用的资源支付其对应的费用。

  • RI:Reserved Instances,预留实例。预存一部分费用,可以在保证资源的同时拿到比较好的折扣。与按需实例和在特定可用区中预留实例相比,Amazon EC2 预留实例提供了相当大的折扣,最多可达 72%。

  • Spot:Spot Instances,竞价实例。和按需实例对比,竞价实例通常是其价格的 10-20%;和预留实例对比,竞价实例通常是其价格的 30-60%。一般来说,竞价实例提供了大量节省云资源费用的可能性。

  • Saving Plan:灵活的新折扣模式,是基于算力的统一机器池概念。


管控流程的事前规划也非常关键,如果所有用户都可以购买云资源或开启云服务,成本就无法有效得到管控。企业需要建立使用云资源的标准流程,并安排专人处理资源申请、资源变更、资源续期和资源回收等需求。同时通过账号、权限严格控制安全风险与成本风险。

事中规划

事中分析应该主要从成本节约角度来考虑。 事前我们制定了云资源使用规范,在事中我们主要对云资源使用进行监控,对违规资源进行通知和整改。具体可以从资源、计费模式两个角度来审查, 以下列出不同层面主要需要思考的问题,供大家参考。


资源层面:


  • 是否存在闲置云资源?是否存在极低使用率的云服务器、未挂载的云硬盘?

  • CPU、内存、磁盘、带宽的配置规格是否比峰值高出很多?

  • 后付费资源有没有设置峰值?

  • 云上资源使用完毕后,有没有忘记关闭,从而导致资源一直被计费?

  • 是否考虑了跨区域读取写入数据会产生高额的流量费用?


计费模式层面:


  • 临时测试和弹性伸缩用的按量付费资源,使用时是否开启了停机不收费功能以保留数据并实现快速启用?

  • 长期使用的资源,使用过程中是否做到及时优化?能否观察资源负载后相应升级配置,或降低配置或释放?

  • 开发和测试所用的按量付费资源,非工作时间是否设置了自动启停?

事后分析

事前规划准备和事中资源监控并不够支撑整个云成本监控和管理体系,事后定期的成本统计分析也是重要一环。这个环节我们可以从多个维度做分析,作为持续优化的依据。 一般来说我们可以分析年度的宏观趋势,再看季度,月度的趋势,甚至细化到日;还可以按自身产品类别、使用的云上资源类型做分析;最后还可以根据需求按所属人、部门和项目分析成本。


具体到实施,事后分析云上成本可以通过 Tags 体系来实现,几乎所有云厂商在云资源上均有对应的 Tags 体系(如 AWS Tagging Strategies ),企业可以制定合理的 Tag 规范,对所有云上资源进行标记,以进行云成本分析。



来源:https://blog.csdn.net/weixin_42556618/article/details/103314800


Kyligence 案列,“现身说法”


为了更好地让大家理解,笔者以公司自身使用云资源的真实案列进行分析,分享如何根据实际业务类型,制定云上资源的使用规范。


Kyligence 云上资源类型主要包括 Online Service 服务为代表的长期资源、日常开发测试用到的临时资源和阶段性项目、POC 类的短期资源,通过账单分析,以上各类资源占比约为 3:5:2。


对长期资源的成本优化比较简单,我们直接通过采购 RI 进行覆盖处理。从资源的占比可以看出临时、短期资源属于“不确定性资源”,且占比高,如何去优化这部分资源的使用成本,难度系数较大 。如不做优化,均按按需的计费模式,则价格昂贵。


理论上,RI 可以获得最高 72%的折扣,保证 RI 的利用率在 60%以上,都属于“赚到了”。据此,对这部分“不确认性资源”,我们可以通过控制 RI 的覆盖率来进行成本优化。 我们尽量让 RI 高峰覆盖率达到 50%左右,日常覆盖率处在 80%左右,再使用一些 Saving Plan,同时配合使用 Spot 来应对每天突然的计算资源申请,基本可以达到理想的状态,这也是我们目前探索出的最佳实践。 如果有开发能力,企业可以开发一些工具,来合理的均衡 OD 与 Spot 比例,以进一步挖掘潜力。


资源规划示意图


RI 使用小贴士:RI 具有三个灵活属性:大小灵活性匹配、合并拆分和可转换(CRI)。由于 RI 是针对某个区域的某个类型的节点, 因此尽量将机器的区域、机型限制在相同区域和相同机型系列,利用 RI 的灵活性,我们可以最大程度提高 RI 的覆盖率。


举例来说:


场景一:假设您在北京区域购买了一个 m5.2xlarge 类型 OS 为 Linux/Unix 的标准 RI,并且您的账户在该区域有两个 m5.xlarge 实例在运行 ,那么两个实例将完全匹配。


场景二:假设在该区域有个 m5.4xlarge 实例(Linux/Unix)在运行 ,且当前我有一个 m5.2xlarge 的标准 RI ,一个 m5.large 的标准 RI,这种场景下您的两个 RI 能够匹配到 m5.4xlarge 实例费用的 75%,并且您只需再购买一个 m5.xlarge 的标准 RI,这样就可以完全匹配,您无需重新购买 m5.4xlarge 的 RI。



RI 覆盖率和利用率示意图


以上解决了“单价”的问题。“用量”如何来减少?


未做资源监控之前,我们分析账单时,发现很多资源未能及时关闭,甚至被遗忘导致整月被计费。公司随之着手建立资源监控体系,而资源监控又依赖 Tags 体系。给资源添加 Tag 是一项非常重要的步骤,我们也相应制定了 Tag 使用规范,并建立了一套监控程序来检查云资源的 Tag 合规性。


具体而言,现在公司利用 Tag 的值来给资源进行分类、并限定时长。 超过 8 小时以上的资源我们需要资源申请,并在 Tag 上标记资源的申请 ID。我们的监控程序定时扫描这些资源。如申请的资源 ID 超时了,该资源会被监控直接停止,同时发送提醒邮件。 这一套资源监控系统,不仅可以减少资源的浪费,同时提高用户的节约意识。


公司在 2020 年 11 月份开始执行云上资源使用规范。对云上资源进行规划,设定资源监控报警,一段时间后,云成本明显下降。


Kyligence 月费用趋势图


此外,公司通过自己开发的 Flag 系统来对所有云平台的成本按不同的维度进行分析, Flag 系统是公司内部的数据分析平台,部署在云平台 Azure 上,系统基于公司的产品 Kyligence Cloud 和 Kyligence Insight,用来展示公司各方面的运营数据,云平台成本分析也是其中之一。 以下是公司用来监测云上成本的数据分析图,供大家参考,分别为:按服务类型进行成本分析、按部门费用分析成本、按 Owner 费用进行成本分析和按项目费用进行成本分析。


各维度云上成本分析图





写在最后

罗马不是一天建成的,同样地,云上成本监控与管理也是。从开始建立规范到使用时及时监控,再到使用后定期分析,每一个环节都是反复迭代、持续优化的过程,没法做到一劳永逸。在实践中,我们也不能丢失初心, 云上成本管控和优化并不是为了降低成本而降低成本,而是为了更好地服务业务,将最宝贵的资源用在刀刃上,助力企业在数字化转型的浪潮中乘风破浪,勇往直前!


本文转载自公众号 ApacheKylin(ID:apachekylin)。


原文链接


上云之后,每年百万成本竟然悄无声息从指缝溜走(内附降本实战经验)

2021 年 4 月 08 日 10:001459

评论 1 条评论

发布
用户头像
什么上云,也是使用固定地点的机房,就是机房与维护外包,云,是营销术语,跟大神的神是差不多的意思
2021 年 04 月 08 日 23:09
回复
没有更多了
发现更多内容

spring事务的这10种坑,你稍不注意可能就会踩中

简爱W

牛逼操作,ThreadLocal还能当缓存用

简爱W

Java

这么理解业务架构就对了!

周金根

BIZBOK 业务架构

架构师训练营高可用学习总结

qihuajun

8锁问题

HeGuang

synchronized

一个实用的开源项目,可以快速将 Elasticsearch 数据导出到 csv

AlwaysBeta

Python 数据库 elasticsearch Kibana Lucene Elastic Search

Spring的Controller是单例还是多例?怎么保证并发的安全

简爱W

做职场里的“超级英雄”,需要怎样的盔甲与工具?

脑极体

【数据结构与算法】力扣实战之移动零、盛最多的水、爬楼梯

三钻

算法 前端 LeetCode 数据结构与算法

都2020了,你的APP还不能运行小程序?

fino星君

小程序生态 私有小程序技术

Java 约束注解

HeGuang

MySQL系列(二):MySQL是怎么处理并发操作的?

z小赵

MySQL 数据库 事务

如何提升系统可用性

码猿外

可用性 持续交付 工程能力 团队文化

Flink中的数据传输-5

小知识点

scala 大数据 flink

第11周作业

小胖子

oeasy 教您玩转linux010101查看内核uname

o

面试28k职位,老乡面试官从HashCode到HashMap给我讲了一下午!「回家赶忙整理出1.6万字的面试材料」

小傅哥

数据结构 hashmap 面试题 面试官 红黑树

我在项目中不可或缺么?

escray

学习 面试 面试现场

刘华:弹性便是一切

刘华Kenneth

架构 DevOps 敏捷 弹性

LeetCode题解:25. K 个一组翻转链表,迭代,JavaScript,详细注释

Lee Chen

LeetCode 前端进阶训练营

书摘之《堂吉诃德》—— 谁不曾想过仗剑走天涯?

Sicolas Flamel

读书笔记

学会反射后,我被录取了(干货)

cxuan

Java 后端 反射

架构师训练营高可用作业

qihuajun

我能讲明白哪些技术?

escray

学习 面试 沟通 面试现场

透过兴趣爱好看本质

escray

学习 面试现场

JavaScript基础语法

Java

阿里内部流传的Mybatis笔记终于流传出来了,赶紧收藏

简爱W

深入浅出Vert.x架构

dinstone

我的缺点就是做事太认真

escray

学习 面试 面试现场

我,一个当代普通大学生的自述

有梦的咸鱼

个人成长 大学生日常 个人感悟 讨论写作

一款高仿 Eyepetizer | 开眼短视频的 MVVM 开源项目

vipyinzhiwei

android kotlin 短视频 eyepetizer 开眼

DNSPod与开源应用专场

DNSPod与开源应用专场

上云之后,每年百万成本竟然悄无声息从指缝溜走(内附降本实战经验)-InfoQ