导读

亚马逊云科技 Lambda SnapStart 现已支持 Python 和 .NET 函数！SnapStart 可以减少函数的冷启动时间，几乎无需修改代码，显著提升函数性能。参加本次会议，了解更多关于 Python 和 .NET 的 SnapStart 信息。探索 SnapStart 如何通过创建和重用快照来工作，如何轻松为新旧函数启用 SnapStart，以及如何确保您的函数和依赖项适合快照。离开时，您将掌握初始化更快的 Python 和 .NET Lambda 函数。

演讲精华

以下是小编为您整理的本次演讲的精华。

2024年亚马逊云科技 re:Invent大会上举办了一场题为“利用SnapStart加速Lambda函数”的精彩会议，由亚马逊云科技高级工程师Leandro da Masana和Amazon Lambda主要产品经理Samrat主讲。会议深入探讨了最新推出的SnapStart功能，旨在通过减少初始化时间来提高Amazon Lambda函数的性能，解决开发人员面临的常见挑战。

Leandro首先承认，在构建Amazon Lambda函数时，初始化时间存在各种挑战，这些时间会因所使用的编程语言而有很大差异。对于Java函数，加载Java虚拟机(JVM)和所需类的过程本身就很耗时，这反映了Java语言的本质。然而，客户已采用策略来缓解这一问题，例如仅使用必需的库，并通过定期调用来保持函数处于热状态。

对于.NET函数，Leandro强调了与Java在需要引导公共语言运行时(CLR)和加载必需类方面的相似之处。尽管如此，随着.NET 8的出现，客户可以利用提前编译(AOT)功能，这已被证明可以改善.NET Lambda函数的初始化时间。此外，客户还可以通过避免导入不必要的库或命名空间来进一步优化性能。

虽然Python作为一种解释型语言，通常不会遇到与Java或.NET一样多的冷启动，但客户仍然报告了这方面的挑战。为了缓解这些挑战，客户采用了诸如仅导入所需库、选择轻量级框架、SDK或工具包(如亚马逊云科技 Lambda Power Tools)以及避免将多余库发送到Lambda代码等策略。此外，在微服务架构中，采用单一Lambda函数处理多个端点的整体式Lambda函数方法也被用于解决冷启动问题。

尽管采取了这些努力，Leandro承认，有时初始化时间的改善还是不够，因此需要引入SnapStart功能。他接着解释了Amazon Lambda函数的传统按需调用模型，其中每次函数调用都会触发新的执行环境的创建。这个过程包括下载和解压代码、引导运行时以及执行Lambda处理程序之外的任何初始化代码。因此，Lambda函数的第一次调用通常会经历冷启动，因为整个环境必须从头开始创建。

后续调用可能会受益于重用同一个容器，从而避免冷启动。但是，这种行为并不能保证，因为底层EC2机群的刷新或负载均衡机制可能会导致每次调用都分配一个新的容器。

在这一阶段，Samrat接手介绍了针对Python和.NET Lambda函数的SnapStart功能，旨在减少可扩展和响应式应用程序的启动延迟。他强调SnapStart对两种主要用例特别有益:延迟敏感的Web API或Web应用程序(用户面临的延迟至关重要)以及批量数据处理工作负载(需要解决初始化时间较长的异常函数)。

Samrat指出，虽然Java函数通常会经历约4秒的中位冷启动延迟，但Python函数通常执行速度更快。然而，即使在Python中，某些框架如Flask、Django和LangChain也可能经历2到5秒的冷启动延迟。使用SnapStart后，这种延迟可以降低到亚秒级。同样，使用DuckDB、LangPIO或NumPy等库的处理工作负载也被观察到会出现超过5秒的冷启动延迟，采用SnapStart可以显著改善这一问题。

针对.NET开发人员面临的挑战，Samrat承认，尽管AOT编译带来了好处，但仍存在一些问题，尤其是与修剪概念相关的问题。在即时编译过程中，如果由于动态查找而修剪了应用程序的某些部分，应用程序的行为可能会变得不确定。在这种情况下，Samrat建议利用SnapStart来减少.NET函数的延迟，而无需更改代码。

Samrat接着阐述了SnapStart的内部工作原理，解释说该功能在函数的初始化阶段会创建内存和磁盘状态的加密快照。这个快照被存储在低延迟缓存中的小块中。当后续调用发生时，加密快照会被加载回来，最常访问的块会被优先处理，从而提高延迟。

创建和加载快照的过程由Firecracker microVM来促进，它提供了安全性和低延迟能力。Samrat逐步介绍了使用Firecracker的调用模型的各个阶段，包括创建执行环境、下载和解压代码、启动运行时以及执行初始化代码，然后创建快照。

对于后续调用，一旦快照可用并准备就绪，基于Firecracker的快照就会恢复，并执行配置为在快照创建后运行的任何逻辑，然后调用Lambda处理程序。

为了说明SnapStart的好处，Leandro和Samrat展示了两个引人入胜的用例。第一个是使用LangChain库构建语言模型应用程序，该库为各种模型和服务(包括Amazon Lambda提供的服务)提供了抽象层。通过利用SnapStart，导入LangChain、FastAPI和Mangum(FastAPI的包装器)的Lambda函数可以创建一个问答API，该API查询大型语言模型并生成响应。与传统的按需模型相比，后者对于1GB函数会产生约3.5秒的冷启动延迟，SnapStart将第一次调用的延迟降低到大约500毫秒。

第二个用例集中在数据分析上，Lambda函数查询大型或中等规模的数据集以进行汇总或快速响应检索。在这种情况下，该函数导入了关系数据库DuckDB以及广泛使用的数据操作库pandas。虽然传统的按需模型对于1GB函数会经历8秒的冷启动延迟，但SnapStart即使在连续调用数小时后，也能持续提供亚秒级的恢复时间。

Samrat随后指导观众如何为新的或现有的Lambda函数启用SnapStart。他强调SnapStart只适用于Lambda函数的已发布版本或别名，这是客户经常忽视的一个关键点。Samrat使用亚马逊云科技管理控制台演示了配置过程，在该控制台中可以在函数配置的一部分中启用SnapStart，然后选择并发布函数版本。一旦函数版本发布，快照创建过程就会启动，状态会从“待定”转换为“活动”，这表明后续调用将从加密快照加载执行环境，从而减少冷启动延迟。

Samrat还展示了使用亚马逊云科技 Cloud Development Kit (CDK)、Amazon CloudFormation和Amazon Serverless Application Model (SAM)启用SnapStart的示例，并强调了各自所需的配置和属性。

接下来，Samrat解释了Python和.NET的运行时钩子，这些钩子允许开发人员在快照创建之前或之后实现代码。这些钩子的常见用例包括运行清理和初始化任务、设置动态配置、处理外部集成以及进行性能调优。他强调，对于Python来说，正确导入并将已注册的钩子包含在函数代码中非常重要，因为Lambda会忽略未导入到函数处理程序中的运行时钩子。

Samrat提供了在Python中使用register_before_snapshot和register_after_restore装饰器或函数的示例，以及在.NET的AmazonLambda.Core库中使用RegisterBeforeSnapshot和RegisterAfterSnapshot方法的示例。他还分享了最佳实践，例如使用函数进行钩子注册，以在涉及多个钩子时获得执行顺序的明确控制，并确保钩子在主处理程序导入的文件中注册。

随着会议的进行，Leandro讨论了使用SnapStart时的一些注意事项和最佳实践。他强调了处理唯一性需求的重要性，例如生成唯一的加密盐或标识符，否则由于重用同一个容器，可能会在多次调用中使用相同的值。

Leandro还强调了确保为正确的函数版本或别名启用SnapStart的必要性，因为调用最新版本而不发布新版本将导致使用传统的按需模型，正如Lambda日志中的调用模型和环境变量所示。

针对DNS缓存的潜在问题，Leandro向观众保证，Python和.NET运行时都不会缓存DNS条目，确保即使在快照中执行，DNS查询也会始终刷新。但是，他警告不要使用有意缓存DNS条目的库，因为这可能会导致问题。

另一个需要考虑的因素是使用预置并发功能，这是一种预先启动指定数量的Lambda容器的功能。虽然预置并发对于流量不可预测的工作负载可能有益，但Leandro建议SnapStart可能更适合具有一致流量模式的低延迟工作负载。

Leandro强调在使用SnapStart时监控Lambda函数的重要性，利用CloudWatch指标、Amazon X-Ray和Lambda Telemetry API等工具来跟踪初始化时间和恢复时间等指标。他还强调需要观察启用了SnapStart的函数的行为，因为性能特征可能与传统的按需模式不同。

使用SnapStart的最佳实践包括在从快照恢复后处理连接和临时数据。Leandro举例说明了Lambda函数在初始化阶段建立数据库连接或检索密钥，如果由于服务器更改或密钥轮换策略等因素，快照在几天或几小时后恢复，这些连接或密钥可能会失效。

为了说明这一点，Leandro提出了一个场景，其中Lambda函数在初始化阶段与Amazon Relational Database Service (RDS)实例建立连接。如果在从快照恢复后没有检查连接，由于套接字不可用或地址已更改，调用可能会失败。同样，如果函数从Amazon Secrets Manager检索密钥并在创建快照时将它们存储在内存中，当快照恢复时，这些密钥可能已经轮换，导致尝试连接数据库时出现身份验证失败。

接下来，Samrat讨论了SnapStart的定价模型，该模型基于两个维度:缓存量和恢复次数。他举例计算了一个1GB函数在整个月内活跃的情况，考虑了基于GB-秒费率的缓存费用和基于恢复次数的恢复费用，通常恢复费用不到总费用的1%。

Samrat指出，对于Python和.NET函数，如果14天内没有调用某个函数版本，则不会删除该版本的快照，与Java SnapStart不同，后者在14天不活动后快照会变为非活动状态。他还解释了缓存的最低费用，计算方式是最少3小时，之后按毫秒计费。

为进一步说明定价模型，Samrat提供了一个场景，涉及一个1GB函数，执行时间为300毫秒，1亿次调用和25万次恢复。在这种情况下，总费用包括558美元的计算和请求费用，基于Lambda缓存的快照量的缓存费用，以及基于恢复次数的恢复费用，总计约为558美元。

作为最佳实践，Samrat建议使用ListVersionByFunction API来识别并删除不再使用但启用了SnapStart的旧函数版本。这种做法可以帮助优化成本，因为Lambda会继续为旧版本维护快照，除非它们被明确删除或禁用SnapStart。

总之，本次会议全面概述了Amazon Lambda函数的SnapStart功能，包括其优势、用例、配置、运行时钩子、注意事项、最佳实践和定价模型。Leandro和Samrat强调了理解和利用SnapStart来提高构建在Amazon Lambda之上的可扩展应用程序的性能和响应能力的重要性，尤其是那些对延迟敏感或批量数据处理工作负载的应用程序。

本次会议强调了采用SnapStart为Python、.NET和Java函数显著降低冷启动延迟的真实世界示例和客户案例。与会者获得了关于SnapStart内部工作原理的宝贵见解，使他们能够就其在Amazon Lambda应用程序中的实施和优化做出明智决策。

我们正处在 Agentic AI 爆发前夜。 2025 亚马逊云科技中国峰会提出，企业要从 " 成本优化 " 转向 " 创新驱动 " ，通过完善的数据战略和 AI 云服务，把握全球化机遇。亚马逊将投入 1000 亿美元在 AI 算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在 AI 时代突破。