使用 Amazon Lambda 函数的最佳实践 - Amazon Lambda
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

使用 Amazon Lambda 函数的最佳实践

以下是推荐使用 Amazon Lambda 的最佳实践:

有关 Lambda 应用程序最佳实践的更多信息,请参阅 Serverless Land 中的 Application design

函数代码

  • 从核心逻辑中分离 Lambda 处理程序。这样您可以创建更容易进行单元测试的函数。在 Node.js 中可能如下所示:

    exports.myHandler = function(event, context, callback) { var foo = event.foo; var bar = event.bar; var result = MyLambdaFunction (foo, bar); callback(null, result); } function MyLambdaFunction (foo, bar) { // MyLambdaFunction logic here }
  • 利用执行环境重用来提高函数性能。连接软件开发工具包 (SDK) 客户端和函数处理程序之外的数据库,并在 /tmp 目录中本地缓存静态资产。由函数的同一实例处理的后续调用可重用这些资源。这样就可以通过缩短函数运行时间来节省成本。

    为了避免调用之间潜在的数据泄露,请不要使用执行环境来存储用户数据、事件或其他具有安全影响的信息。如果您的函数依赖于无法存储在处理程序的内存中的可变状态,请考虑为每个用户创建单独的函数或单独的函数版本。

  • 使用 keep-alive 指令来维护持久连接。Lambda 会随着时间的推移清除空闲连接。在调用函数时尝试重用空闲连接会导致连接错误。要维护您的持久连接,请使用与运行时关联的 keep-alive 指令。有关示例,请参阅在 Node.js 中通过 Keep-Alive 重用连接

  • 使用环境变量将操作参数传递给函数。例如,您在写入 Amazon S3 存储桶时,不应对要写入的存储桶名称进行硬编码,而应将存储桶名称配置为环境变量。

  • 控制函数部署程序包中的依赖关系。Amazon Lambda 执行环境中包括若干库,例如适用于 Node.js 和 Python 运行时的 Amazon 软件开发工具包(完整列表位于此处:Lambda 运行时)。Lambda 会定期更新这些库,以支持最新的功能组合和安全更新。这些更新可能会使 Lambda 函数的行为发生细微变化。要完全控制您的函数所用的依赖项,请使用部署程序包来打包所有依赖项。

  • 将部署程序包大小精简为只包含运行时必要的部分。这样会减少调用前下载和解压缩部署程序包所需的时间。对于用 Java 或 .NET Core 编写的函数,请不要将整个 Amazon 软件开发工具包库作为部署程序包的一部分上传,而是要根据所需的模块有选择地挑选软件开发工具包中的组件(例如 DynamoDB、Simple Storage Service (Amazon S3) 软件开发工具包模块和 Lambda 核心库)。

  • 将依赖关系 .jar 文件置于单独的 /lib 目录中,可减少 Lambda 解压缩部署程序包(用 Java 编写)所需的时间。这样比将函数的所有代码置于具有大量 .class 文件的同一 jar 中要快。有关说明,请参阅使用 .zip 或 JAR 文件归档部署 Java Lambda 函数

  • 将依赖关系的复杂性降至最低。首选在执行环境启动时可以快速加载的更简单的框架。例如,首选更简单的 Java 依赖关系注入 (IoC) 框架,如 DaggerGuice,而不是更复杂的 Spring Framework

  • 避免在 Lambda 函数中使用递归代码,因为如果使用递归代码,函数便会自动调用自身,直到满足某些任意条件为止。这可能会导致意想不到的函数调用量和升级成本。如果您不慎执行此操作,请立即将函数保留并发设置为 0 来限制对函数的所有调用,同时更新代码。

  • Lambda 函数代码中不要使用非正式的非公有 API。对于 Amazon Lambda 托管式运行时,Lambda 会定期为 Lambda 的内部 API 应用安全性和功能更新。这些内部 API 更新可能不能向后兼容,会导致意外后果,例如,假设您的函数依赖于这些非公有 API,则调用会失败。请参阅 API 参考以查看公开发布的 API 列表。

  • 编写幂等代码。为您的函数编写幂等代码可确保以相同的方式处理重复事件。您的代码应该正确验证事件并优雅地处理重复事件。有关更多信息,请参阅如何使我的 Lambda 函数具有幂等性?

函数配置

  • 对您的 Lambda 函数进行性能测试是确保选择最佳内存大小配置的关键环节。增加内存大小会触发函数可用 CPU 的同等水平的增加。您的函数的内存使用量是按每次调用确定的,并且可以在 Amazon CloudWatch 上查看。每次调用都将生成一个 REPORT: 条目,如下所示:

    REPORT RequestId: 3604209a-e9a3-11e6-939a-754dd98c7be3 Duration: 12.34 ms Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 18 MB

    分析 Max Memory Used: 字段能够确定函数是否需要更多内存,或函数的内存大小是否过度配置。

    要为您的函数查找适合的内存配置,我们建议使用开源 Amazon Lambda 功率调谐项目。有关更多信息,请参阅Amazon Lambda开启电源调节 GitHub。

    为了优化函数性能,我们还建议部署可以利用高级矢量扩展 2 (AVX2) 的库。这样一来,您就可以处理艰巨的工作负载,如机器学习推理、媒体处理、高性能计算(HPC)、科学模拟和财务建模。有关更多信息,请参阅使用 AVX2 创建更快的 Amazon Lambda 函数

  • 对您的 Lambda 函数进行加载测试,确定最佳超时值。分析函数的运行时间很重要,这样更容易确定依赖关系服务是否有问题,这些问题可能导致并发函数以超出您的预期的速度增加。如果您的 Lambda 函数进行网络调用的资源无法处理 Lambda 扩缩,这就更加重要。

  • 设置 IAM policy 时使用最严格的权限。了解您的 Lambda 函数所需的资源和操作,并限制这些权限的执行角色。有关更多信息,请参阅Lambda 资源访问权限

  • 熟悉Lambda 配额在确定运行时资源限制时,负载大小、文件描述符和 /tmp 空间通常会被忽略。

  • 熟悉您的上游和下游吞吐量限制。虽然 Lambda 函数可随负载无缝扩展,但上游和下游依赖项可能不具有相同的吞吐量。如果您需要限制函数可以扩展的幅度,请配置预留并发

  • 删除不再使用的 Lambda 函数。这样,未使用的函数就不会不必要地占用有限的部署程序包空间。

  • 如果您使用 Amazon Simple Queue Service 作为事件源,请确保该函数的预计调用时间值不超过队列上的可见性超时值。这适用于 CreateFunctionUpdateFunctionConfiguration

    • 如果是 CreateFunction,则函数创建过程Amazon Lambda将失败。

    • 如果是 UpdateFunctionConfiguration,则可能会导致函数的重复调用。

指标和警报

  • 使用使用 Lambda 函数指标 CloudWatch 警报,而不是在 Lambda 函数代码中创建或更新指标。追踪 Lambda 函数的运行状况是更加有效的方式,这样您就可以在早期开发过程中发现问题。例如,您可以根据 Lambda 函数调用的预计持续时间配置警报,以解决函数代码引起的瓶颈或延迟。

  • 利用您的日志记录库和 Amazon Lambda 指标和维度捕捉应用程序错误(例如,ERR、ERROR、WARNING 等)

  • 使用 Amazon Cost Anomaly Detection 来检测您账户中的异常活动。Cost Anomaly Detection 使用机器学习技术来持续监控您的成本和使用情况,并尽力减少误报。Cost Anomaly Detection 使用来自 Amazon Cost Explorer 的数据,该数据最长可能会延迟 24 小时。因此,发生使用后最长可能需要 24 小时才会检测到异常。要开始使用 Cost Anomaly Detection,您必须首先注册 Cost Explorer。然后访问 Cost Anomaly Detection

处理流

  • 测试不同批处理和记录的大小,这样每个事件源的轮询频率都会根据函数完成任务的速度进行调整。该CreateEventSourceMapping BatchSize 参数控制每次调用可以发送到您的函数的最大记录数。批处理大小如果较大,通常可以更有效地吸收大量记录的调用开销,从而增加吞吐量。

    默认情况下,Lambda 会在记录可用时尽快调用您的函数。如果 Lambda 从事件源中读取的批处理只有一条记录,则 Lambda 将会只向该函数发送一条记录。为避免在记录数量较少的情况下调用该函数,您可以配置 batching window(批处理时段),让事件源缓冲最多五分钟的记录。调用函数前,Lambda 会持续从事件源中读取记录,直到收集完整批处理、批处理时段到期或批处理达到 6MB 的有效负载时为止。有关更多信息,请参阅批处理行为

    警告

    Lambda 事件源映射对每个事件至少处理一次,并且可能会出现批次的重复处理。为避免与重复事件相关的潜在问题,我们强烈建议您将函数代码设为等性。要了解更多信息,请参阅知识中心中的 “如何使我的 Lambda 函数具有等性”。 Amazon

  • 通过增加分区提高 Kinesis 流处理吞吐量。一个 Kinesis 流由一个或多个分区组成。Lambda 轮询每个分区时最多会使用一个并发调用。例如,如果您的流有 100 个活跃分区,则最多可以并发运行 100 个 Lambda 函数调用。增加分区数量会直接增加 Lambda 函数并发调用的最大数量,还可增加 Kinesis 流处理的吞吐量。如果您增加 Kinesis 流中的分区数量,请确保您已为数据选择了合适的分区键(请参阅分区键),这样相关记录将会位于同一分区中,而且也可合理分配您的数据。

  • 使用亚马逊 CloudWatch IteratorAge 来确定您的 Kinesis 直播是否正在处理中。例如,将 CloudWatch 警报配置为最大设置为 30000(30 秒)。

安全最佳实操

  • 监控 Amazon Lambda 的使用情况,因为它与使用 Amazon Security Hub 的安全最佳实践有关。Security Hub 使用安全控件来评估资源配置和安全标准,以帮助您遵守各种合规框架。有关使用 Security Hub 评估 Lambda 资源的更多信息,请参阅《Amazon Security Hub 用户指南》中的 Amazon Lambda 控件