GMTC深圳站本周日开幕,14大专题全部上线,完整日程>> 了解详情
写点什么

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

  • 2021 年 4 月 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 年 4 月 08 日 10:002017

评论 2 条评论

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

Xtrabackup的安装使用

一个有志气的DB

MySQL 工具 数据的分片和备份

尽管HTTP/3已经来了,HTTP/2也得了解啊

清远

网络协议 HTTP

OneData之OneModel

KAMI

大数据 数据中台 数据治理 OneData

OneData之OneID

KAMI

大数据 数据中台 数据治理 OneData

让你高效工作与学习的免费工具(1)

石云升

高效工作 效率工具 工具

从一次排查ES线上问题得出的总结——熔断机制

罗琦

elasticsearch 源码分析 circuit break 熔断

如何在一台计算机上安装多个 JDK 版本

mghio

Java jdk 版本管理工具

OneData之OneService

KAMI

大数据 数据中台 数据治理 OneData

浅谈Cloud Native技术对云上产品的影响

韩超

Docker Kubernetes 云原生 IaaS PaaS

码农理财(一)

北漂码农有话说

理财

业余前端的日常

顿晓

学习 前端 日常 专家 知识体系

Harbor 2.0的飞跃: OCI 兼容的工件仓库

亨利笔记

Kubernetes 容器 k8s Harbor 镜像

微服务涉及的技术生态有哪些?

攀鱼飞岩

分布式 微服务 方法论 软件架构

谈谈控制感(5):怎么破控制感损失的局

史方远

职场 心理 成长

松哥手把手教你定制 Spring Security 中的表单登录

江南一点雨

Java spring Spring Boot spring security

游戏夜读 | Scikit-learn迎来0.21之前

game1night

《后浪》产品经理篇(恶搞版)

静陌

产品经理 后浪

更聪明地学习,而不是苦读——《如何高效学习》

mzlogin

学习

sync.Map源码分析

陈思敏捷

源码 源码分析 Go 语言

松哥手把手带你入门 Spring Security,别再问密码怎么解密了

江南一点雨

Java spring Spring Boot spring security

数据治理与OneData 体系

KAMI

大数据 数据中台 数据治理 OneData

程序员的晚餐 | 5 月 17 日 当西红柿遇上鱼

清远

美食

严选合伙人(二)

Neco.W

创业 重新理解创业 合伙人

如果你觉得学习 Git 很枯燥,那是因为你还没玩过这款游戏!

GitHubDaily

git GitHub 编程 程序员 开发者工具

设计模式之观察者模式

设计模式

Python 核心技术与进阶 list & tuple

Bonaparte

《零基础学 Java》 FAQ 之 7-Java 中的内存是怎么分配的

臧萌

Java JVM

计算机中的递归对普通人有什么启示?

BitSea

算法

对于程序员,那些既陌生又熟悉的计算机硬件

架构师修行之路

微软 编程 程序员 cpu 架构师

Redis稳定性实践

心平气和

redis 缓存 稳定性

OpenResty部署配置和日志切割

wong

nginx centos openresty

2021星空论坛:破局创新,论道数字化转型

2021星空论坛:破局创新,论道数字化转型

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