AWS 宣布改变 Lambda 函数连接虚拟私有云（Virtual Private Cloud，简称 VPC）资源的方式。这个改变，即使用预先创建的网络接口而不是为每个函数执行环境创建的网络接口，为无服务器功能消除了“冷启动”的一个主要因素。
这个改变是不是 IOpipe 的 Austin Huminski所称的“大量使用 VPC 的企业采用无服务器的转折点”？可以肯定的是，自 2016 年以来，AWS Lambda 用户已经能够连接到运行于 VPC 中的服务器和服务了。由于 AWS Lambda 的所有计算基础设施都运行于 AWS 拥有的 VPC 中，因此，与客户 VPC 的连接传统上是通过弹性网络接口实现的。在客户 VPC 中，为每个执行环境创建了这些弹性网络接口。在这些网络接口被创建和附加之前，无法执行 Lambda 函数代码。随着功能的扩展，更多执行环境需要甚至更多的网络接口，如来自 AWS 的下图所示。
借助刚发布的 AWS Lambda 更新，正如 AWS 的一篇博文所解释的那样，连接架构得到了简化。
从今天开始，我们改变了功能连接到 VPC 的方式。用于网络负载平衡器和 NAT 网关的网络函数虚拟化平台 AWS Hyperplane ，支持 AWS PrivateLink 等产品的 VPC 之间的连接，并且，我们现在利用 Hypenplane 提供从 Lambda VPC 到客户 VPC 的 NAT 功能。
如下图所示，从 AWS 到客户 VPC 子网的网络接口现在在整个 AWS Lambda 执行环境中共享。
AWS 表示，这个共享网络接口的一次性设置只需要 90 秒就可以完成。但是，由于网络接口是在 Lambda 函数首次创建或 VPC 设置更新时创建的，与连接相关的延迟在冷启动时接近于零。函数扩展也一样，不再需要为每个新执行环境提供新的网络接口。Amazon 的 Chris Munns最近发了一则推文，他展示了一张图，显示在部署了这个 VPC 网络更改后，延迟有显著的降低。
顺便提一下，“冷启动”问题经常出现，原因是无服务器功能不适合很多工作负载。在调用函数和代码实际运行之间，是什么因素造成了延迟？Amazon 的 Tim Bray指出，有很多因素导致了冷启动延迟。
启动一个函数需要的时间取决于最近启动该函数的时间。因为，如果我们已经在最近合理地运行了该函数，那么，我们可能已经把它加载到主机上，准备运行了，只需要把事件路由到正确的地方就可以。如果不是这样，那么，我们必须找到一个空主机，在存储器中找到函数，拉取出来，在我们使用它之前安装一下即可。
接着，Bray提到，一旦函数被“启动”，那么，就会有特定语言的初始化，可能需要编译代码或启动一个 VM。接着，函数要做的事是加载状态并连接到依赖的服务。不管怎样，AWS 在大力调整 Lambda，以减少冷启动时间，正如在这个最近的编程语言冷启动时间上的比较所示。
当然，客户可以并确实能够使用 AWS Lambda 而无需运行 VPC。默认情况下，Lambda 函数可以访问任何在公共互联网上可用的东西，包括很多 AWS 服务。尽管，在最近几年，AWS 已经把客户引导到 VPC 上去用经典的工作负载。默认情况下，Amazon EC2 虚拟机运行于 VPC 内部。 Amazon RDS 、数据仓库 Redshift ，以及类似 Paas 的环境弹性 Beanstalk 的关系数据库产品也是如此。IOpipe 的 Huminski说，采用云的企业熟悉 VPC 模式，而现在更适合于 AWS Lambda 这样的现代运行时。
对于从私有数据中心迁移过来，或仍在运行混合基础设施的公司或组织来说，VPC 似乎是个无需动脑的选择。它怎么看都像孤立的传统服务环境，有着 IT 习惯的藩篱。
…
尽管新的更改有利于开发人员把 Lambda 函数连接到 VPC，但是，基础架构不会因我们的 VPC 而变化。
这个功能正在全球范围逐步推广，预计于几周内完成。AWS 为这次更改更新了其文档，并共享了这个升级功能，没有相关的成本。根据 AWS 的说法，VPC 连接的很多方面保持不变，包括对 IAM 权限配置的要求和所需的 NAT 网关，以连接 VPC 外部端点。
原文链接：
Change to AWS Lambda Networking Reduces Cold Start Time for VPC Customers
评论