Serverless 底座的持续创新

文章作者：亚马逊云科技 资深开发者布道师 黄帅

引言

自 2014 年以来，亚马逊云科技一直通过 Lambda 服务向用户提供 Serverless 的能力。使用 Lambda，用户不必担心管理服务器或调整容量，以应对不断变化的市场需求，而且上述需求均由亚马逊云科技自动进行配置，用户只需为他们使用的资源付费。

Datadog 的 2021 年 Serverless 状态报告表明，开发者正在加速采用 Serverless 架构，以应对新的、更高级的业务挑战。我们很高兴看到，越来越多的组织受益于采用 Lambda 等 Serverless 技术所带来的敏捷性、弹性和成本效率，支持这个不断发展多元化的开发者社区。-- Ajay Nair，亚马逊云科技 Lambda 服务体验 总经理

这个强大的 Serverless 服务背后隐含了许多底座持续创新的内幕。今天我们就来谈一谈亚马逊云科技的 Serverless 底座的持续创新。

底座创新

Serverless 是一种云计算领域的架构，用户不在需要购买或者管理固定数量的服务器，而是由云根据用户的业务特征，动态管理服务器资源，并提供弹性调度、自动扩缩容，故障自愈等能力，用户无需为服务器计费，而是为真正消耗的资源付费。

广义的 Serverless，通常有 FaaS（函数即服务）和 BaaS（后端即服务）组成，用户无需关心基础架构的管理和维护，只需要关心业务代码，即可在 FaaS 环境中运行自己的服务端业务逻辑，并可以使用云提供的多种 BaaS 服务，而且无须关心运维和服务器的扩缩容。

因此，除去 BaaS 的多样性，整个 Serverless 的底座，本质上取决于 Serverless 计算服务（FaaS）的性能与安全。也就是说，我们在这里探讨的 Serverless 底座创新，针对的就是 Lambda 服务。同时，我们也可以想一想 FaaS 的性能与安全，取决于哪些方面，简单来讲，FaaS 的性能与安全严重依赖于底座芯片和虚拟化的能力。所以，我们今天要探讨的 Serverless 底座持续创新，主要关注在 FaaS 的芯片与虚拟化上。

FaaS 的芯片创新

Graviton 是亚马逊云科技于 2018 年发布的基于 ARM 架构的一款服务器处理器，面向 EC2 虚拟机实例的用户。第一代 Graviton 处理器采用定制芯片和 64 位 Neoverse 内核，EC2 A1 实例支持基于 ARM 的应用程序，例如 Web 服务器、缓存队列、分布式大数据处理和容器化微服务。使用开放式 ARM 架构，意味着通过不从头开始创建新芯片来节省成本，相反，采用了现有的 ARM 架构，针对 EC2 实例的工作方式对其进行了定制，希望为用户在 EC2 实例选择方面提供更多选择，为基于 ARM 的应用程序提供高可用性和安全性，同时降低虚拟化成本，为用户提供良好的服务器性能和更低的价格。

与第一代 Graviton 处理器相比，Graviton2 处理器在性能和功能上实现了重大飞跃。基于 Graviton2 的实例为 EC2 实例中的工作负载提供最佳性价比。基于 Graviton2 的实例支持广泛的通用、突发、计算优化、内存优化、存储优化和加速计算工作负载，包括应用服务器、微服务、高性能计算、机器学习推理、视频编码、EDA、游戏、数据库和内存缓存。许多 Serverless 服务，包括 Lambda 和 Fargate 等，也支持基于 Graviton2 的实例，以提供具有性价比优势的完全托管体验，提高了性能并节省了成本。

Graviton3 处理器是 Graviton 处理器系列中的最新款。与 Graviton2 处理器相比，计算性能提高了 25%，浮点性能提高了 2 倍，加密工作负载性能提高了 2 倍。与用于 ML 工作负载的 Graviton2 处理器相比，Graviton3 处理器的性能提高了 3 倍，包括对 bfloat16 的支持，还支持 DDR5 内存，与 DDR4 相比，内存带宽增加了 50%，未来也将支持 Lambda 等 Serverless 服务。

Lambda 服务目前支持基于 ARM 的 Graviton2 处理器上运行。使用此处理器架构选项可获得高达 34% 的更高性价比。Julian Wood 的文章《Migrating AWS Lambda functions to Arm-based AWS Graviton2 processors》，重点介绍了如何从 x86 迁移到 ARM64，以及迁移过程中需要的注意事项。Graviton2 处理器内置的性能和安全性，旨在为计算密集型工作负载提供高达 19% 的性能提升，使用多线程和多处理或执行  I/O 操作的工作负载，可以体验更短的调用时间以降低成本，与 x86 定价相比，以毫秒为单位计费的持续时间费用，降低了 20%。从 x86 架构到 ARM 架构的更改，不会影响 Lambda 函数调用的方式，与 API、服务、应用程序或工具的集成不受新架构的影响，并继续像以前一样工作。

许多功能可以通过配置更改无缝迁移，其他功能需要重新构建以使用 ARM64 的软件包，我们也可以使用 Lambda PowerTuning 工具测试迁移后的 Lambda 函数性能状况，具体可访问这里：

• https://github.com/alexcasalboni/aws-lambda-power-tuning

FaaS 的虚拟化创新

在最初构建 Lambda 服务时，我们有两条路：

1. 容器化，快速且资源高效，但不提供用户之间的强隔离
2. 在虚拟机中运行代码，以计算开销为代价提供更高的安全性。

安全性始终是 AWS 的首要任务，因此，我们最早使用传统 VM 的方式构建了 Lambda。

用户要求我们提供更快的扩展、更低的延迟和高级功能，例如预置并发。我们知道，这种功能需求无法在传统 VM 上进行构建。

随着用户越来越广泛采用 Serverless 技术，我们认识到现行的虚拟化技术无法针对呈短暂性特点的工作负载进行优化。我们认为需要构建特别针对 Serverless 计算的虚拟化技术，需要既能提供基于硬件虚拟化的安全性边界，同时又能保持容器和函数的轻量与敏捷性。

因此我们构建了 Firecracker，并于 2018 年 11 月将该虚拟化平台开源发布。Firecracker 是一种采用基于 Linux 内核的虚拟机 (KVM) 技术的开源虚拟机监控程序(VMM)。Firecracker 允许创建微型虚拟机，即 microVM。Firecracker 坚持精简主义的设计原则，仅包含运行安全、轻量的虚拟机所需的组件。Firecracker 依据 Apache 2.0 进行许可。请访问 Firecracker GitHub 存储库以了解更多信息和为 Firecracker 做贡献。

• https://github.com/firecracker-microvm/firecracker

Firecracker 同时满足了

1. 基于硬件虚拟化的虚拟机的安全性
2. 容器的资源效率和快速启动时间

2020 年 USENIX 网络系统设计和实施研讨会上，我们发表了一篇论文，详细解释了 Firecracker 的工作原理。

• https://assets.amazon.science/96/c6/302e527240a3b1f86c86c3e8fc3d/firecracker-lightweight-virtualization-for-serverless-applications.pdf

 

其中，容器（左）使代码可以直接访问操作系统的一些核心功能（“内核”），通过拒绝访问其他功能（“沙盒”层中的 x）来增强安全性；虚拟机（右）为工作负载提供自己的用户内核，并使用硬件虚拟化功能隔离。

虚拟化的核心部分是虚拟机监视器（或 VMM），用来设置虚拟化、管理内存和处理 I/O（如网络连接和磁盘存储）。传统的 VMM 几乎与完整的操作系统一样复杂，例如：QEMU 是一种虚拟机监视器，通常与 Linux 内核虚拟机 (KVM) 结合使用，拥有超过 140 万行代码（以及相应的广泛而强大的功能）。

Firecracker 比 QEMU 高效得多的原因是其精简的 VMM，只有 50,000 行代码——比 QEMU 减少了 96%。这允许为每个用户程序创建单个 microVM，这是一个简单但强大的安全模型。此外，这 50,000 行代码是用 Rust 语言编写的，2017 年秋，我们决定以 Rust 语言来编写 Firecracker，这是一种非常先进的编程语言，可保证线程和内存安全，防止缓存溢出以及可能导致安全性漏洞的许多其他类型的内存安全问题，并内置了一个REST 控制 API，可启动实例、获取或设置 VM 配置、管理快照等。单台服务器每秒可创建多达 150 个 Firecracker microVM，并同时运行数千个 microVM。

当然，大幅减小 VMM 的大小同样会大幅降低其功能。Firecracker 没有实现像 BIOS 或 PCI 总线这样的传统设备，而是通过优化的virtio接口与用户内核进行通信。重要的是，Serverless 的工作负载不需要 USB、显示器、扬声器和麦克风等硬件功能，因此根本没有必要去实现对这些功能的支持。

Firecracker 为 Lambda 服务提供支持，2020年的一个数据是，Firecracker 每月为数十万用户处理数万亿个请求。目前，已经释出稳定的 1.0 版本。目前，Firecracker VM 可以在不到 125 毫秒的时间内完全启动，而完全创建 microVM 需要不到 7 毫秒。每个 microVM 的内存占用小于 5MB。

Firecracker 用于多个容器托管平台，如appfleet、Fly.io、Koyeb等，可以使用容器运行时进行管理，包括通过 firecracker-containerd、Weave Kubes 和 Kata Containers 进行容器化，从而使其能够与 Kubernetes 集成。

总结

本文分享了亚马逊云科技在 Serverless 底座的持续创新，我们将继续大力投入 Serverless 计算的三个层面：应用层、虚拟化层和硬件层，为用户提供卓越的计算能力，同时保证安全性、可扩展性和高性能。大力投入基础技术的研发是持续创新的关键要义之一，这不仅是为了明天，更是为了下一个十年甚至更远的将来。在此创新的过程中，我们也与社区紧密合作与共享。通过将 Firecracker 开源化，我们不仅欢迎您深入研究构建 Serverless 计算的未来基础技术，也希望您能与我们一起强化和完善 Firecracker。更多信息请参阅 Firecracker 问题列表和 Firecracker 路线图。 

点击了解 “启动Linux 虚拟机”教程

学习更多教程，戳这里！