189 8069 5689
上一篇《架构师视角看云成本管理》我们从宏观视角分享了一些成功企业的实践，以及云成本优化的成熟度模型；这是云成本管理第二篇，主要跟大家聊聊云上的计算成本，以及常见的一些认知误区拆解。
计算我想是大家都熟知的一块领域，尤其是虚拟机，但不得不说，了解越深入才越感受到，真正掌握云上计算实例还真不是件容易的事情。
很多时候往往我们自认为熟悉，反而容易丢掉宝贵的好奇心，从而阻碍我们真正了解云上的计算。
消除浪费是基本原则
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，闲置促销市场，价格便宜，计算资源本身没有区别。
规模越大的云供应商，客户遭遇计算资源容量挑战的概率越小；原因是，整个计算资源市场是被很多大的头部客户的需求不断撑大和扩展，而一旦计算资源扩大，云厂商是无法将计算资源缩回去的，只有旧代的计算实例类型会由于用户市场需求萎缩，而逐渐停止扩容。
因此，在云上上规模使用计算资源，要有容量管理意识，主动和云服务商沟通容量需求；
对云服务商而言，一个美好愿望是，”资源是无限的，想要就有“，而这句话的正确理解是，云的资源是可以无限扩展的，但不是第一天就是超大规模的容量，是动态根据客户需求而逐步扩充的，所以，任何大规模非线性增长的计算资源需求，都需要人为主动介入和干预的。
在看和转发就是对我的鼓励！