（译）发现 Serverless 应用中的隐形成本
像 AWS Lambda 这样的服务，代码每运行 100 毫秒，就需要支付一定的费用。例如 512 MB 内存的 Lambda 的（每 100 毫秒）费率是 $0.000000834。最好的一点是，如果代码没有运行，就无需支付费用——在一些大的组织机构中，如果服务器的使用率低于 20%，这种无服务器的方式会在财务上带来巨大的成本节约。企业已经注意到了这一点。
这有问题么？没有。这个技术很有意思。然而新技术总是有风险的，必须做出识别和防范。特拉维夫 AWS Community Day 上，The Real Cost of Pay-Per-Use in Serverless 这篇谈话中，Ran Ribenzaft 说到了 Serverless 技术中几个方面的成本问题。下文将会说到其中的一部分。
服务硬件配置是否越低越好
部署一个无服务器函数的时候，第一个选择往往就是内存和 CPU。Lambda 中，这两个参数是绑定的一系列固定选择。更大的内存就对应着更高的价格。这么看来，选择较低的内存会省钱对么？不是的，过低的内存可能带来以下问题：
- 更低的内存配置一般也对应着更低的 CPU 配置，也就意味着更长的运行时间，甚至可能造成超时。超时的严重程度可以与台式机的关机相提并论，是大家非常不愿见到的情况。
- 更长的运行时间当然也代表着更高的成本。所以降低内存配置可能会取得一个相反的效果。
在 AWS Lambda 的性能测试中，发现一个令人惊奇的结果：性能和价格同步上升——直到某点之后，配置的提高不再带来性能的提升。
所以想要一次确定 CPU 和内存的最佳方案是不太实际的。函数自身也会发生变更和升级，对配置的需要也有发生变化的肯能。
所以该怎么办？
对执行时间和内存用量进行监控
一般来说在复杂系统中，在你不知道你不知道的情况下，会发生最严重的问题。可观测性是一个关键点——不仅是检测异常和性能瓶颈，还要知道函数的内存消耗和执行时间。最有用的方式之一就是，在问题发生之后的告警之外，尝试预测问题发生的可能。可以通过静态规则以及用峰值和常规行为进行对比的方式来进行这种尝试。
昂贵的 API 调用
一个主要的观察结果就是，性能和账单是直接相关的。代码运行越慢、就要付出更多。无服务器的总成本由两个因素组成：
- 运行业务逻辑的时间
- 等待 API 调用返回的时间
The Importance and Impact of APIs in Serverless 的演示中，对一个 Auth0 这样的常见服务的简单调用，可能会消耗 Lambda 函数中的 80% 的时间。这并不是说不应该使用第三方 API，正好相反，创建完全无服务器的可伸缩应用，使用第三方应用是一个关键。然而应该对自己的选择有深入了解，相对于传统应用，对工具的配置在无服务器应用中可能会产生更大的影响。
让账单变得可以预测
虽然从传统上来说，云计算的账单很复杂且难于理解，通常还是可以预测的——买一千个虚拟机，一般是大约知道可能发生的费用的。在 Lambda 以及一些像 Amazon Aurora Serverless 这样的新服务来说，账单变得更加动态，更难预测。
预测成本
成本预估是控制支出的有效方法。根据目前的花费情况，可以预测本月的最终成本。成本预测是一种简单有效的防止超支的方式。简单的预测公式：
月度支出 = 当前支出*（本月天数/当前日期）例如本月有 30 天，今天是 15 号，本月已经消费了 $200，那么就可以预计到月底的花费应该是 $400。这种预测对于单独的函数或者整体成本都是有效的，在 Epsagon，函数视图中包含了每个函数的预测。
成本监控
正如使用性能监控工具来保障应用的正常运行一样，无服务器函数也需要对成本进行监控。Epsagon 的案例研究中，我们分享了一个故事，其中一个 Lambda 函数有严重的问题，它会以很高的并发方式运行，最终导致了每月 $12k 的成本。幸运的是，我们对自己的系统进行了监控。另外还发生过大公司发现过价值 $50,000 的 bug 的问题，也多亏了 Epsagon 的监控功能。
Lambda 成本计算器是一个开源工具，能帮助用户理解函数的可能花费。
写在最后
按使用付费的方式是一个绝妙的概念，让无服务器应用能够大幅降低成本。但是性能问题可能直接影响月度账单，是一个值得注意的问题。
成本的预测和监控能够降低意外高额账单的风险。特别需要指出的是，无服务器应用中的 API 应该小心使用并注意监控，因为它有成为主要的性能和成本瓶颈的可能。