衡量性能效率：每笔交易成本优化指南

每笔交易成本是一个有用的云指标，因为它将工程工作与业务可理解的内容联系起来。与其说“RDS账单上涨了”或“CPU现在更低了”，不如说“本月成功完成一次结账的成本约为半分钱，而上个月更高”。这并不能使数字完美，但它开启了一场更好的对话。

在AWS中，每笔交易成本通常不是一个免费获得的单一指标。你需要从账单数据和应用程序数据中构建它。困难的部分不在于除法。困难的部分在于决定分子中包含什么、什么算作交易，以及如何避免以损害用户的方式优化这个数字。

在计算任何内容之前定义交易

交易应该是业务事件或服务结果，而不仅仅是随机的请求计数。对于电子商务系统，交易可能是完成的订单。对于支付API，它可能是授权的支付尝试。对于数据管道，它可能是处理过的文件或一百万个处理过的记录。对于内部API，它可能是在延迟目标下成功处理的请求。

选择一个人们可以捍卫的定义。如果你计算每个健康检查和失败的请求，分母会被夸大，指标看起来会比实际情况更好。如果你只计算完美的端到端成功，指标可能更诚实，但更难与基础设施级别的吞吐量进行比较。

一个实用的公式是：

每笔交易成本 = 分配的服务成本 / 成功的业务交易

例如：

每月分配成本 = $1,500
成功订单数 = 300,000
每笔订单成本 = $1,500 / 300,000 = $0.005

这个例子使用了整数。在真实系统中，成本分配是混乱的。共享负载均衡器、NAT网关、可观测性平台、支持计划、CI运行器和数据传输都可以支持多个服务。决定该指标是用于粗略趋势跟踪还是精确计费。这些是不同的工作。

谨慎构建分子

从直接参与服务交易的AWS服务开始：EC2、ECS、EKS工作节点、Lambda、RDS、DynamoDB、ElastiCache、SQS、SNS、Kinesis、S3、CloudFront、API Gateway、Elastic Load Balancing、NAT Gateway和数据传输。然后决定如何处理共享成本。

AWS Cost Explorer、成本和使用报告、成本分配标签以及账户结构是常用的工具。标签尤其重要。如果计算资源没有按服务、环境或团队进行标记，每笔交易成本就会变成猜测。

对于Web结账流程，每月分配的成本可能包括：

成本项目	分配方法
ECS服务或EC2 Auto Scaling组	直接服务标签
RDS集群	按应用程序所有权或查询工作负载拆分
ElastiCache	专用则直接分配，共享则按比例分配
负载均衡器	按请求计数或服务所有权拆分
NAT Gateway	通常共享；尽可能按流量分配
CloudWatch日志和指标	直接日志组标签或按量估算

不要因为分配不便就隐藏昂贵的共享基础设施。NAT Gateway数据处理、跨可用区流量和冗长日志可能会显著改变聊天服务的成本状况。

从应用程序真相构建分母

分母应来自业务事件的记录系统，而不仅仅是基础设施计数器。Application Load Balancer的请求计数可以告诉你流量大小，但不能告诉你订单是否成功创建。CloudWatch指标很有用，但应用程序指标或数据库事件通常提供更清晰的交易计数。

对于API服务，你可以发出自定义指标，如SuccessfulPaymentAuthorization或CompletedReportGeneration。对于管道，计算成功提交到目标的记录数，而不仅仅是读取自源头的记录数。对于异步作业，决定重试是否算作另一个交易。通常不应该；重试是完成一个逻辑工作单元的成本的一部分。

将每笔交易成本与延迟和错误率结合使用

较低的每笔交易成本并不自动意味着更好。你可以通过过度配置让用户等待更长时间、请求超时或重试将成本转移到其他地方，从而使数字看起来很好。CPT应与延迟、错误率、饱和度和队列深度一起阅读。

一个健康的审查可能会说：

成功报告的成本在合理调整工作节点后下降了18%。
P95延迟保持在目标以下。
错误率没有增加。
在高峰负载期间，队列年龄保持在五分钟以下。

如果成本下降而延迟翻倍，你并没有优化服务。你只是把痛苦从账单转移到了用户身上。

优化通常来自哪里

合理调整规模是第一步。查找长时间低利用率运行的实例、任务和数据库。AWS Compute Optimizer可以帮助处理EC2、EBS、Lambda和一些容器工作负载，但将建议视为起点。应用程序上下文仍然重要。平均CPU较低的数据库可能仍需要内存用于缓存或批处理窗口期间的I/O余量。

自动扩展是第二步。扩展策略应与瓶颈匹配。CPU目标跟踪适用于CPU密集型服务。队列深度或年龄通常更适合工作节点。每个目标的请求计数可能更适合Web集群。对于Lambda，关注持续时间、内存配置、并发、下游节流和冷启动敏感性。

一旦使用稳定，购买承诺可以提供帮助。节省计划和预留实例可以降低有效计算成本，但它们不能解决浪费问题。在了解基线后再做出承诺。否则，你可能锁定本应移除的资源的支出。

存储和数据传输是常见的盲点。在合理的情况下压缩大型有效负载。避免不必要的跨可用区或跨区域流量。有意设置日志保留期。仅在检查访问模式和检索成本后，将旧对象移动到更便宜的S3存储类。

具体的审查流程

选择一个服务和一项交易。提取上个月分配的AWS成本。提取同月的成功交易计数。计算基线。然后按服务分解成本。

第一次审查通常会揭示一些明显的问题：过大的数据库、空闲实例、昂贵的NAT流量、过多的调试日志，或者比其节省的数据库负载成本更高的缓存。一次修复一个问题，并注释指标，以便下一个读者知道发生了什么变化。

一个简单的月度表格就足以开始：

月份	分配成本	交易数	CPT	备注
一月	$1,500	300,000	$0.0050	基线
二月	$1,350	310,000	$0.0044	减少了空闲工作节点
三月	$1,420	420,000	$0.0034	流量增加，数据库大小不变

趋势比虚假精度更重要。如果分配规则发生变化，请标记变化。由于排除共享数据库成本而导致的CPT下降并不是工程上的胜利。

常见错误

最常见的错误是混合环境。生产交易应与生产成本匹配。开发和生产环境可以有各自的效率指标，但它们不应稀释生产数字。

另一个错误是将失败的尝试计为成功交易。失败的工作仍然花费金钱，并且应显示为浪费。如果需要，保留一个单独的每请求成本指标。

第三个错误是局部优化一个组件。一个团队可能通过使用更少的工作节点来降低EC2成本，但只会增加队列延迟和数据库锁争用。每笔交易成本很有用，因为它阻止了使整个流程变得更糟的狭隘胜利。

有用的目标

目标不是尽可能低的CPT。目标是在满足可靠性和性能目标的同时，实现可持续的最低CPT。这意味着该数字应与SLO、事件历史记录和容量计划一起审查。

一旦指标稳定，它就成为评估变更的好方法。新的缓存是否降低了数据库成本，足以证明其合理性？更大的实例系列是否提高了每美元吞吐量？重写是否降低了计算时间但增加了数据传输？每笔交易成本不会回答所有问题，但它为团队提供了一个共享、具体的起点。

将重试视为成本信号

重试通常隐藏在聚合指标中。用户提交一份报告，但系统由于下游调用超时而尝试了三次。如果你计算基础设施请求，分母可能看起来很高。如果你计算成功报告，额外的尝试会显示为每完成交易的成本更高，这通常是更有用的信号。

跟踪重试率与CPT。稳定的流量下CPT上升可能指向重试风暴、部分故障、锁争用或低效的代码路径。在分布式系统中，浪费通常不是一次昂贵的请求。而是数千次重复的廉价请求，因为没有人应用退避或在永久错误后停止重试。

分离固定和可变成本

某些基础设施成本对于给定架构是固定的。最小的数据库集群、基线可观测性、负载均衡器和小的常开工作节点池，无论你处理一万笔交易还是十万笔交易，成本大致相同。其他成本随流量变化：Lambda持续时间、数据传输、队列请求、日志量和额外的计算能力。

将CPT分解为固定和可变部分使数字更容易解释：

固定月度服务成本 = $900
可变月度服务成本 = $600
交易数 = 300,000
混合CPT = $0.0050
可变CPT = $0.0020

如果流量翻倍而固定成本保持不变，混合CPT应该改善。如果可变CPT同时上升，你可能存在扩展效率问题。也许缓存命中率在负载下下降。也许数据库查询计划发生了变化。也许更大的有效负载增加了传输和日志成本。

使用单位经济学进行架构选择

CPT在比较两种都满足需求的设计时很有用。假设一个API可以在Lambda或ECS上运行。Lambda在低流量时可能更便宜且操作更简单。ECS在流量稳定且高时可能变得更便宜。仅凭月度账单无法说明这一点；每成功请求的成本可以。

同样的原则适用于缓存。每月花费$400的缓存将数据库成本降低$100，可能不是成本优化，尽管它可能仍然是延迟优化。每月花费$400并允许数据库层缩小$1,200的缓存更容易证明其合理性。将决策与延迟、可靠性和CPT联系起来，而不是将任何新组件视为自动高效。

注意成本转移

团队有时通过将成本推入另一个项目来降低一个账单。将工作从EC2转移到Lambda可以减少空闲计算，但可能会增加持续时间费用、日志或下游数据库压力。压缩响应可以减少数据传输但增加CPU。更激进的自动扩展可以减少计算小时数但增加冷启动或队列延迟。

好的CPT审查会询问成本去了哪里。如果总分配成本下降且服务质量保持不变，那是真正的胜利。如果一个账户看起来更便宜，因为共享平台成本吸收了差异，那么指标在说谎。

让仪表板变得简单

一个有用的CPT仪表板不需要花哨。它每个月需要相同的定义：

分配的AWS成本
成功交易数
每笔交易成本
p95或p99延迟
错误率
重试率
主要发布或事件的备注

为部署、流量峰值、定价承诺变更和分配规则变更添加注释。没有注释，人们会编造故事来解释图表。一个简单的注释，如“3月12日将图像处理移至异步工作节点”，可以节省以后的时间。

在审查中使用指标，而不是作为武器

如果每笔交易成本成为一个生硬的目标，它可能导致不良行为。团队可能会避免必要的冗余、过度减少日志记录或对关键路径进行过度配置以使数字看起来更好。将其用作工程审查指标，而不是独立的评分。

最好的对话听起来很实际：“我们的CPT上升了，因为流量转移到了更重的端点”，“数据库现在是成本的最大部分”，“上次发布后重试翻了一番”，或者“节省计划降低了计算成本，但存储现在是更大的机会。”这就是指标发挥作用的地方。