如何避免AWS的高额账单？

前言

Serverless架构在今天已经不再是新鲜的事物。该架构具有多个特点：较低的运营和开发成本、能快速上线、自动扩展、安全性高和适合微服务等。各大云服务商也提供了各自的Severless解决方案。然而，尽管Serverless架构在某些方面表现出色，但在当前轰轰烈烈的“微服务”进程中，它仍然不是一种主要的选择。除了由于本身特性导致的使用场景受限外，我想乏善可陈的关于Serverless最佳实践的总结也是一个重要的因素。
我有幸参与了一项基于AWS搭建的Serverless (FaaS) 系统的开发工作，该系统提供了一组核心服务。通过几次系统故障调研和性能优化的实际体验，我发现系统监控在Serverless架构中至关重要。所以本文将从Serverless系统监控的角度来展开一些讨论。

哪些指标需要被监控？

先分享一个真实发生的故事：

我们在对上文提到的FaaS 系统做一次部署时，由于API测试不通过导致流水线构建失败。调查发现是因为测试运行时间过久导致请求使用的令牌过期。这一发现直接指向了系统的性能问题。我们回溯大量流水线构建记录后发现，API测试所耗时长在近一个月以来逐日递增。在调查了CloudWatch中各项观测指标后发现：从一个月前开始，Lambda的调用次数始终保持在最大并发量，并且Lambda一直处于高执行时延状态。最终找到根因在于一个会触发Lambda执行的消息事件由于某个bug被大量复制，并且该事件在被Lambda处理后原样发回SQS，导致发生死循环。

尽管这个问题发生在非生产环境，但带来的影响依然是非常大的：首先，测试环境性能明显降低。另一方面，AWS是按使用收费。该问题导致一个月以来，Lambda，SQS，RDS，DynamoDB和CloudWatch等AWS服务被持续不断地使用，因而产生了高额的账单。

上述故事中反映出来的问题可能有很多方面，但缺乏监控与告警无疑是导致该问题持续近一个月而没有被发现和解决的罪魁祸首。那么，在Severless系统中，一般有哪些需要监控的指标呢？其实AWS 的CloudWatch已经给出了部分答案。不同于需要监控CPU/内存使用率等