主要观点：2019 年开始考虑让 Lambda 客户用容器镜像部署函数，难点是性能尤其是冷启动延迟，新论文[On-demand Container Loading in AWS Lambda]解决此问题。
关键信息：

• 去重（Deduplication）：容器加载的最大优势在于避免重复移动相同数据，多数容器镜像由少量流行基础镜像创建，通过避免多次复制和缓存基础镜像可提高速度，数据显示约 75%的容器镜像包含少于 5%的独特字节，新系统在块级别进行去重。
• 懒加载（Lazy Loading）：容器镜像中大部分数据非独特，运行在容器中的进程实际使用的更少，利用 Firecracker 提供的抽象层，构建知道块容器格式的文件系统，按需获取所需块来实现约 15 倍的加速。
• 分层缓存（Tiered Caching）：架构中的分层缓存包括本地、可用区级别和 S3 中的缓存，缓存有效，通过在缓存内容名称函数中混入随时间变化的数据来减少坏块影响范围。
• 纠删码（Erasure Coding）：共享可用区级缓存架构使用纠删码降低尾延迟和缓存节点故障影响，将每个块分成多部分，只要有足够部分可重建就能应对节点故障，使软件部署更简单。
• 架构方面：容器加载系统约有 6 个部分，包括现有系统和专为项目设计的部分，不同组件有不同需求和部署方式，各组件交互构成 Lambda 系统。
  重要细节：
• 冷启动延迟是 Lambda 多年来的重点投资领域，新系统旨在支持容器镜像且不增加延迟。
• 懒加载通过 FUSE 构建文件系统，块保存在分层缓存中，本地内存缓存近期使用的块，本地磁盘缓存较不近期的块，可用区缓存几乎所有近期块，全量块存储在 S3。
• 纠删码中每个块分成 M 部分，只要 M - k >= 1 就能应对节点故障，对客户端代码复杂度有一定影响但带来操作简化和容错性。
• 总体架构中各组件有不同需求和部署方式，不同团队负责建设、运营和改进，选择组件边界需综合考虑多种因素。
  结论：作者喜欢写这篇论文，因为它体现了工作的兴奋点，系统通过少做工作获取性能，多做一些工作获取弹性，这在系统设计中值得关注。视频形式的演讲可在 ATC’23 找到，论文中有相关文献回顾，最初用 HTTP 构建原型但缓存机器能轻松饱和 NIC 所以暂用 HTTP。