云虚机成本管理这些坑你碰到几个?

  • 来源:网络
  • 更新日期:2020-06-05

摘要:申明本站点所有文章,仅代表个人想法,不代表任何公司立场,所有数据都来自公开资料--转载请注明出处--上一篇《架构师视角看云成本管理》我们从宏观视角分享了一些成功企业的最佳

申明

本站点所有文章,仅代表个人想法,不代表任何公司立场,所有数据都来自公开资料--转载请注明出处--

上一篇《架构师视角看云成本管理》我们从宏观视角分享了一些成功企业的最佳实践,以及云成本优化的成熟度模型;这是云成本管理第二篇,主要跟大家聊聊云上的计算成本,以及常见的一些认知误区拆解。

计算我想是大家都熟知的一块领域,尤其是虚拟机,但不得不说,了解越深入才越感受到,真正掌握云上计算实例还真不是件容易的事情。

很多时候往往我们自认为熟悉,反而容易丢掉宝贵的好奇心,从而阻碍我们真正了解云上的计算。

消除浪费是基本原则

AWS 的成本优化一个基本原则是 “避免浪费”,客户在优化成本避免浪费的过程中,自然而然会走向云原生架构,过程虽痛苦,但客户的技术“肌肉”会越来越强壮,面临各种挑战时会更加灵活有竞争力;

有人问,平台怎么调节市场,每个云服务的上线运营,背后都至少一个小团队在负责,价格是市场调节器,同样也是云服务的试金石,在不浪费的前提下,每个云服务包括云合作伙伴解决方案都在充分竞争态势下赢取客户,最终客户受益。

你遇到过下面的计算浪费场景吗?

应用底层虚机集群采用固定数量

晚上哪怕用户少,集群机器也不会关机

很多机器的资源利用率极低但就是没人敢关

默认每台机器挂载 100GB甚至更多的磁盘

机器很少升级到新机型

极少利用 ARM 和 AMD 平台优化价格更高的 Intel 芯片

只用虚机,极少采用其它计算服务

”计算“没有看起来那么简单

客户通常给定机器 CPU/内存配置,以及需要的机器数量,跟往常一样对外进行询价,这种思路其实还停留在 IDC 的范式中,这样做的客户默认有几个假设前提:

忽视应用在云上的架构优化,限制云服务商仅仅提供计算资源

计算资源需求是固定的(通常是日常业务的峰值用量)

资源“占有欲”,脑袋里还计算着机柜数量

默认各厂商同样的 CPU/内存计算能力一致

忽略云服务的技术升级和服务能力价值

处于这样的阶段,我们通常认为是迁移里面最初级的阶段,从 IDC 照搬到云上,而忽视两者之间巨大的技术差异,从成本管理的角度,我们非常不建议客户停留在这个阶段太久,迁移的过程是一个非常好的契机来偿还技术债务,团队不进行转型,原来那套还是直接放到云上,很难取得理想的业务结果。

计算真的这么简单吗?

误区1:计算==虚机?

云服务发展到今天,从最初的物理机虚拟化,提供虚机服务,到如今丰富多样的计算能力和不同的计算市场,给到客户的选择灵活性不可同日而语。

丰富的虚机类型选择

从种类上来说,以 AWS 为例,提供了 270多种覆盖通用、内存优化、存储优化、高性能计算密集、GPU及图形计算、机器学习推理等各种工作负载的按场景优化的机型

CPU 平台而言,提供 Intel、AMD 和 ARM能力的各种处理器机器

不仅仅有虚拟机而且提供裸金属机器

单机网络性进入 100Gbps时代(太比特以太网络)

针对你的工作负载,选择最优的虚机类型是成本管理的第一步。

推荐扩展阅读:《你真的了解 AWS 实例“经济学”吗?》利用Python和Pandas库来分析AWS实例

按使用收费,不用不收费

云服务被人津津乐道的就是按使用付费,跟水电等基础设施类似,不占用资源就完全没有费用产生,机器来说,关机就停止收费,而且通常先使用,后结算。

虚机对客户而言毕竟还是底层资源,而企业往往需要的是支撑业务价值的应用,而从应用角度看成本模型,对企业意义非凡。应用需要的计算资源,可选虚机、容器、无服务器三类,其中无服务器的成本模型在很多场合对企业都是有帮助的。

比如 AWS Lambda, 主要的费用是按接口每百万次调用收费,没有调用不收费,但你的服务是一直可用状态。

再比如容器,很多客户习惯管理底层虚机,为了优化成本,需要有能力管理虚机的弹性伸缩,不断提升虚机的利用率,但 AWS Fargate 降低了客户使用容器管理底层虚机的困扰,直接以容器为单位,容器持续时间所占用的容器资源进行收费,用户无需考虑底层的虚机。

甚至数据库,也可以根据访问量的多少,自动帮助客户进行底层资源伸缩,从而节约成本;比如 Amazon Aurora Servless、NoSQL 数据库 Amazon DynamoDB 等等。

从业务特性,细分应用场景,无服务器架构先行。

固定成本和弹性成本

我们在前文中提到,一个企业的云成本管理成熟度越高,他们的弹性成本优化的就越好。

购买方式,对于客户而言,有两种极端。

第一种,全弹性成本,比如游戏行业客户,新游戏发行,通常不清楚该游戏是否能够持续活跃下去,因此往往初期更愿意采取全按需方式使用,全弹性成本,随时止损。

第二种,全固定成本,比如企业后台应用,很多是传统的企业应用,需要一直提供服务,这种情况下,按照固定成本支出的思路,包年使用可以拿到最优的价格。

大多数企业是需要在固定成本和弹性成本之间取得一个平衡,而其中优化的重点就是弹性成本,往往有很多企业不恰当适用过多的按需实例,而导致成本居高不下。

为什么会出现弹性成本?很多是由于业务特性带来的,比如流媒体网站 Netflix 往往周五开始用户流量上涨,周一开始回落,晚上用户流量大于白天用户访问;又比如,很多用户夜间会有很多跑批处理的任务,白天则以分析师交互查询为主等等;又比如开发测试环境,本身就是一个短暂生命周期的使用环境;

如上图所示,云厂商的计算资源的成本基线是以虚机的按需单价为基础的,不同区域通常单价略有差异。

弹性计算资源优化建议从 Spot 实例市场入手或将弹性资源通过 Saving Plan 优化成动态固定成本,往往有出乎意料的好结果。

误区2:虚机都一样?性价比差异超出你的想象

再也别单纯基于 vCPU和内存数量直觉判断所有的供应商提供的产品都是一样的能力。

从工作负载出发,定义你关注的机器性能指标,测试先行,基于性价比再来看成本,通常会豁然开朗。

我们期望客户不断的”喜新厌旧“,不断优化已有的计算实例的成本;

去年网易游戏团队在《荒野行动》 全球游戏用户的网络加速组件中,测试并利用 AWS A1 机型替换原本的 C4/C5机型,直接获得了 40%的性价比提升。

虚拟化技术的发展,如今以 AWS 为参照,Nitro System 的虚拟化技术,虚拟化软件的资源消耗占整体宿主机的 1% 以下。

还有虚拟机资源的独占和“超售”使用的问题,我想一直是客户比较关注的,这个可以通过长时间测试虚机性能稳定性来判断。

误区3:资源”占有“安全感与成本优化困境

由于云是公共基础设施,刚开始非常不适应的是,容量管理挑战,即如何确保在任何需要的时候,企业有足够的资源?

传统 IDC 固定容量的安全感,进化到大家共享资源池的云计算服务,确实需要调整思路。

云上能否做到类似 IDC 这样的“占有欲“下的容量安全呢?

答案是肯定的。唯一的挑战是成本,因为计算资源的容量预留给到你的账号,那无论你是否使用都会产生费用,因为这部分资源不能被其他客户重用,无论你用不用,资源都锁在你的账户;通常遇到特殊情况导致整个市场计算资源容量紧张时(比如黑五,有大量客户在抢占使用资源),为了保障自身业务增长所需要的容量,才会这么做;

大部分的客户的虚机是共享资源,你释放掉计算资源,有可能会立刻被另外一个客户占用,如果你是一个计算资源消耗大户企业,有可能会碰到由于某类机型可用资源不足而导致的虚机启动失败。

这点不确定性,会令不少企业客户不舒服,但一种常见的误区是,客户一直尝试在一个可用区,不断尝试同一种实例类型的机器,这种策略可算不上高明;因为资源池有两个因素决定:所在的可用区,实例类型;一种被验证降低容量挑战的策略就是利用多可用区,多实例类型的计算资源;

如上图,AWS 的计算资源,从购买方式来看,存在两个市场:一个是市场 A,通常拥有大量最新计算实例资源,如果容量紧张会从市场 B的资源池调度计算资源来补充;另一个是市场 B,闲置促销市场,价格便宜,计算资源本身没有区别。

规模越大的云供应商,客户遭遇计算资源容量挑战的概率越小;原因是,整个计算资源市场是被很多大的头部客户的需求不断撑大和扩展,而一旦计算资源扩大,云厂商是无法将计算资源缩回去的,只有旧代的计算实例类型会由于用户市场需求萎缩,而逐渐停止扩容。

因此,在云上上规模使用计算资源,要有容量管理意识,主动和云服务商沟通容量需求;

对云服务商而言,一个美好愿望是,”资源是无限的,想要就有“,而这句话的正确理解是,云的资源是可以无限扩展的,但不是第一天就是超大规模的容量,是动态根据客户需求而逐步扩充的,所以,任何大规模非线性增长的计算资源需求,都需要人为主动介入和干预的。

在看和转发就是对我的最大鼓励!