谈谈API的成本盘算方法

引言

前一段时间，拜访客户的时候，客户提出一个问题：原来他们的AI应用，把不同的模子部署在不同的EC2实例上，不同模子的EC2实例打不同的tag，通过tag来识别不同模子的成本斲丧。如今他们想把不同的模子部署到同一个EC2实例上，那么这么混合部署后，怎样来识别不同的模子的成本斲丧呢？
我们现场讨论了几种方案。厥后回来后，我想了想，以为这个是个挺有意思的话题。多年前，我在网龙工作时，我们曾经试图通过压测的定量分析来引导步伐的优化，在雷同的方向上有过讨论，有许多的共通之处。这里把思考做一个记录、总结，以供大家参考。
抱负的成本

抱负情况下，一次API调用的成本可以简单明白为，调用这个API一次，斲丧了多少资源，折合多少钱。
但是在实际的执行过程中，通常很难这么衡量。原因在于，大多数的用于保障API执行的底子设施，并不是以这么细的粒度来进行计费和付费的（哪怕是云上serverless lambda的方式，通常也只是盘算层可以做到这么细粒度的计费，假如这个盘算要用到DB，也很难把DB的斲丧细化到每一个API请求）。
从财政的角度

通常时候，只能以一台大概一组服务器作为粒度来盘算成本。即便是引入假造化大概云化后，也只能以虚机的维度来盘算成本。很难进行更细粒度的成本拆分。
这个角度，只是为了让全部的成本有归属，全部的资源使用能找到承担成本和责任的人。
损耗的问题

实际上，体系在运行中，着实是有损耗的，我们很难把硬件设备的性能用尽。比如一台服务器，一天有能力执行100W次的盘算，但是实际上，我们只执行了50W次盘算。那么实际上就损耗了50%的算力资源，但是我们还是要为这部门没有被使用起来的资源支付费用。
假如这部门的损耗不能正确识别出来，效果会影响我们对体系的负载能力的团体判断。也会对将来的成本预期做出错误的估计。
目的

• 准确识别抱负成本
  
• 准确识别体系损耗
  
• 预估体系的负载上限、引导体系扩容
  
• 合理进行成本核算
  

实行

抱负成本的得到

取一个标准环境（比如一台2核4G的EC2，一台2核4G的RDS）。假定它一个小时的代价是P1，把它一个小时的资源记为R1。那么一天的成本就是P1*24，一天的可使用资源量就是R1*24。
实际上，经济成本核资源成本，只是成本的两种表现方式，在资源代价确定的时候，这两个成本是可以换算的。以是后面我们都已经济成原来讨论。
在这个标准环境上，对业务A（大概是单个或一组API）进行多轮压测。得到一个平均TPS值，假定这个值是M1。
那么我们可以盘算业务A的经济成本为：P1/(M1*3600)
究竟上，我们的体系在实际运行的时候，假如真的达到压测的满载状态，是会存在一定的风险的（比如大概导致体系出现慢请求），以是我们通常应该要设定一个资源使用率阈值，这里假定设这个阈值为90%。那么上面的成本应该修正为：
经济成本为：P1/(M1*3600*0.9)
业务A在一段时间内里的总成本为：P1/(M1*3600*0.9)*业务A总请求量。
全部业务在一段时间（T）内里的总成本为：全部业务的总成本之和 CT。
体系损耗的盘算

在一段时间内里，我们支付的总费用是 P1 *  T。
这一段时间，体系的损耗是 P1 * T - CT。
进一步，要看公司的核算内里，损耗部门是作为公共支出，还是要核算为业务成本。假如作为公共支出，是最容易的，把这部门当列就好了。
假如要核算为业务成本，那么要定义业务的分摊规则。比如是按照业务的请求量分担，还是按照业务的理论成本占比分摊。
假如按照业务的理论成本占比分摊，那么一个业务的分摊值为：
(P1 * T - CT) * (P1/(M1*3600*0.9)*业务A总请求量) / CT。
进一步的应用

通过 P1 * T - CT 和 CT的占比，我们也能分析出，此时体系的富余容量，预知体系还可以承受多少的负载增加，进一步推算用户在什么水平的增长水平上，体系可以正常运行，必要在什么时候进行扩容。
在多业务混合使用资源的时候，也可以依据这个推算的数据，联合线上资源的观测，来判断业务混合部署是否能有效使用资源，哪些业务的资源使用是会互相干扰的。
实际使用过程中，还大概出现，压测和实际运行，都会出现体系的性能已经无法提拔，但是确观测到CPU，内存都还很空闲，大概其中一种资源空闲的状态。
假如是一种资源空闲，说明体系的配置不合理，我们必要调整配置，来更好地优化性价比。
假如都空闲，那么必要考虑体系是不是有外部依赖，外部依赖拖累了体系的性能发挥，这个时候优化的方向是提拔外部依赖体系的相应速度，大概降低本体系的配置，以和外部体系适配，镌汰资源的浪费。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。