写点什么

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

  • 2021-04-08
  • 本文字数:3909 字

    阅读完需:约 13 分钟

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

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


根据全球云管理服务厂商 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-04-08 10:002962

评论 2 条评论

发布
用户头像
老师您好,我是图书策划编辑,想要邀请您写书,不知道您有没有这个意向呢
2021-08-05 14:28
回复
用户头像
什么上云,也是使用固定地点的机房,就是机房与维护外包,云,是营销术语,跟大神的神是差不多的意思
2021-04-08 23:09
回复
没有更多了
发现更多内容

React组件通信

xiaofeng

React

研发分享 | StoneDB 如何给 Tianmu 引擎增加 delete 功能 #1 调研之旅

StoneDB

数据库 HTAP StoneDB 10月月更 企业号十月PK榜

CTO技术共享整理九个shell脚本

CTO技术共享

个人成长 DDoS 10月月更

大数据开发培训怎么选?

小谷哥

java开发技术培训费用是多少

小谷哥

技术分享| 消息队列Kafka群集部署

anyRTC开发者

nginx kafka zookeeper 分布式 消息

细说React组件性能优化

xiaofeng

React

遇到消息队列选型肿么办

CTO技术共享

个人成长 消息队列 10月月更

vue3实战-完全掌握ref、reactive

yyds2026

Vue

vue实战-深入响应式数据原理

yyds2026

Vue

React组件设计模式-纯组件,函数组件,高阶组件

xiaofeng

React

大数据开发培训学习哪家机构好

小谷哥

CTO技术共享整理出来的十个Python自动化脚本

CTO技术共享

Python 个人成长 10月月更

3M互助公排dapp系统开发智能合约定制

开发微hkkf5566

vue中的几个高级概念

yyds2026

Vue

SAP | 认识数据元素和域

暮春零贰

SAP abap 10月月更

大厂被裁,疫情之下,一个offer都没,测试人如何破局?

千锋IT教育

web前端开发课程培训哪家好

小谷哥

什么是无代码?企业为什么要用无代码进行数字化转型?

优秀

数字化转型 无代码

前端开发的程序员还有前途吗

小谷哥

SAP | 详解abap数据类型

暮春零贰

SAP abap 10月月更

Dell UltraSharp 27显示器,创造你想要的“视”界

科技热闻

Vue.nextTick核心原理

yyds2026

Vue

升级到React-Router-v6

xiaofeng

React

没想到!我在简历上写了“精通MySQL”,阿里面试官跟我死磕后就给我发了高薪offer

程序知音

Java MySQL 数据库 后端技术

极客时间运维进阶训练营第一周作业

好吃不贵

【CSPO认证】11月19-20日在线周末班 | 全国招生

ShineScrum

Scrum 敏捷 产品负责人 CSPO 产品经理培训

TiKV 源码阅读三部曲(一)重要模块

PingCAP

TiKV 源码解读

Confidential Containers:云原生机密计算基础设施

OpenAnolis小助手

开源 cncf 龙蜥 机密计算 沙箱

渲染行业的未来发展趋势

Finovy Cloud

渲染 云渲染 本地渲染

Wallys//routerboard,QCN9074,QUECTEL,RM500Q-GL,WiFi6ECard,802.11ax,IPQ6010,IPQ6000,IPQ6018

wallys-wifi6

IPQ6010 ipq6018 IPQ6000

上云之后,每年百万成本竟然悄无声息从指缝溜走(内附降本实战经验)_软件工程_apachekylin_InfoQ精选文章