笔记本电脑到 Lambda：将日常工作外包给数以千计的瞬态容器

本周的论文评论是“Shell 的未来”系列文章中的第二篇（第 1 部分，这里有一篇关于在 shell 中进行创新的可能方法的论文）。与往常一样，请随时在 Twitter 上提供有关要阅读的论文的反馈或建议！这些每周论文评论也可以每周发送到您的收件箱。本周的论文讨论了 gg，这是一个系统，旨在使用云函数并行化从开发人员桌面启动的命令，就像在 Firecracker 虚拟机中运行在 AWS Lambda 上的那些，如之前的一篇论文评论中所讨论的那样。 - 另一种总结是 gg 允许开发人员在有限的时间内“在云中租用超级计算机”。虽然使用云函数并行计算在其自己的相关系统（如 Ray）上并不是一个新想法，但将在本文后面的评论中讨论。 , gg 专注于利用负担得起的云计算功能来加速不是为云原生设计的应用程序，如基于 make 的构建系统（在开源项目中很常见）、单元测试和视频处理管道。该论文包含两个主要贡献：gg（使用云函数执行的计算图并行化命令行操作的通用系统）的设计和实现以及 gg 在多个领域的应用（包括单元测试、软件编译和对象识别） ）。为了实现 gg 的目标，作者需要克服三个挑战：管理在云中运行的应用程序的软件依赖关系，限制从开发人员工作站到云的往返行程（如果开发人员的工作站协调云执行，则可能会发生这种情况），并利用云功能本身。要理解本文对这些问题的解决方案，了解几个相关工作领域的上下文会很有帮助： 流程迁移和外包：gg 旨在将计算从开发人员的工作站外包到远程节点。 distcc 和 icecc 等现有系统使用远程资源来加速构建，但通常需要长期存在的计算资源，这可能使它们的使用成本更高。相比之下，gg使用的云计算功能可以在秒级或毫秒级付费。

容器编排系统：gg 在云函数（实际上是云中的容器）中运行计算。现有的容器系统，如 Kubernetes 或 Docker Swarm，专注于任务的实际调度和执行，但不一定关心执行动态计算图——例如，如果任务 B 的输入是任务 A 的输出，我们怎么能使任务 A 的执行容错和/或记忆。工作流系统：gg 将应用程序转换为可以并行执行的小步骤。遵循类似模型（如 Spark）的现有系统需要针对特定​​任务进行编程，而不是为用户从命令行生成的“日常”应用程序而设计。虽然 Spark 可以调用系统二进制文件，但二进制文件通常安装在所有节点上，其中每个节点都是长期存在的。相比之下，gg 努力提供特定步骤所需的最小依赖项和数据——限制依赖项的目标也转化为更低的计算开销，因为在执行步骤之前需要传输的数据更少。最后，像 Spark 这样的系统是通过语言绑定访问的，而 gg 的目标是与语言无关。 Burst-parallel 云函数：gg 旨在成为一个更高级别和更通用的系统，用于运行比现有方法更短的生命周期的云函数——该论文引用 PyWren 和 ExCamera 作为两个使用云组件实现特定功能的系统（类似于 MapReduce框架和视频编码，分别）。相比之下，gg 旨在提供“用于依赖管理、落后者缓解和调度的通用服务”。构建工具：gg 旨在通过云中的并行化来加速多种类型的应用程序。这些应用程序之一，编译软件，由 Bazel、Pants 和 Buck 等系统处理。这些较新的工具有助于通过并行化和增量化操作来加速构建，但开发人员可能无法使用上述系统的高级功能，除非他们重新设计现有的构建。现在我们对 gg 的目标有了更多的了解，让我们进入系统的设计和实现。 gg 中间表示 (gg IR) 用于表示应用程序中涉及的计算单元 - gg IR 看起来像一个图，其中步骤之间的依赖关系是边，计算/数据的单元是节点。 gg 中间表示 (gg IR) 描述了给定应用程序执行所涉及的步骤。值得注意的是，该图是动态且延迟评估的，这有助于支持涉及“循环、递归或其他非 DAG 数据流”的应用程序。 .每个步骤都被描述为一个 thunk，包括该步骤调用的命令、环境变量、该命令的参数以及所有输入。 thunk 也可以用来表示不需要评估的原始值——例如，像 gcc 这样的二进制文件需要在 thunk 的执行中使用，但不需要被执行。使用内容寻址方案识别 thunk 论文描述了一种内容寻址方案，其中“对象的名称有四个组成部分：（1）对象是原始值（以 V 开头的哈希）还是表示结果强制其他一些 thunk（以 T 开头的哈希），(2) SHA-256 哈希，(3) 以字节为单位的长度，以及 (4) 一个命名对象或 thunk 输出的可选标签。”这允许一个 thunk 依赖另一个（通过指定对象数组，如下图所述）。

前端通过特定于语言的 SDK（开发人员在其中描述应用程序在代码中的执行）生成 gg IR。这似乎与 Ray 密切相关，这是之前的另一篇论文评论。或使用模型替换原语。模型替换原始模式使用 gg infer 来生成原始命令执行中涉及的所有 thunk（也称为步骤）。此命令基于如何对特定类型的系统建模的高级知识执行 - 例如，想象定义一种处理使用 make 的项目的方法。在这种情况下，gg infer 能够将上述 make 命令转换为一组 thunk，这些 thunk 将并行编译独立的 C++ 文件，合并结果以生成预期的二进制文件 - 请参见下图以获取直观表示。后端通过“强制”执行对应于应用程序执行输出的 thunk 来执行前端生成的 gg IR。然后沿着导致最终输出的边缘向后追踪计算图。后端可以在不同的云提供商上实现，甚至可以使用开发人员的本地机器。虽然后端的内部结构可能不同，但每个后端都必须具有三个高级组件： 存储引擎：用于对内容可寻址输出执行 CRUD 操作（例如，存储 thunk 的执行结果）。执行引擎：一个实际执行 thunk 的函数，抽象出实际执行。它必须支持“一个简单的抽象：一个接收 thunk 作为输入并返回其输出对象（可以是值或 thunk）的哈希值的函数”。执行引擎的示例是“本地多核机器、远程 VM 集群、AWS Lambda、Google Cloud Functions 和 IBM Cloud Functions (OpenWhisk)”。 Coordinator：Coordinator 是一个通过与一个或多个执行引擎和存储引擎通信来编排 gg IR 执行的过程。从论文中不清楚是否可以将多个存储引擎与单个协调器相关联。 .它提供了更高级别的服务，例如制定调度决策、记住 thunk 执行（不要不必要地重新运行 thunk）、如果 thunk 失败则重新运行，以及滞后缓解 在这种情况下，滞后缓解意味着确保运行缓慢的 thunk 不会影响整体执行时间。解决此问题的一种策略是并行取消 thunk 的多个副本，然后在第一次成功后继续——这可能是因为 thunk 的内容可寻址性质意味着它们的执行是幂等的。 . gg 系统被应用于四个，并对其进行了评估 本文还包括递归斐波那契的实现，以证明 gg 可以处理动态执行图，同时还可以记住冗余执行。用例：软件编译、单元测试、视频编码和对象识别。对于软件编译，FFmpeg、GIMP、Inkscape 和 Chromium 是在本地编译的，使用分布式构建工具 (icecc) 或使用 gg。对于大中型程序（Inkscape 和 Chromium），gg 的性能优于使用 AWS Lambda 执行引擎的替代方案，可能是因为它能够更好地处理高度并行性——基于 gg 的编译能够执行所有步骤远程，而另外两个系统在根节点执行瓶颈步骤。该论文还包括一个有趣的图形，概述了 gg worker 在编译期间的行为，其中包含一个有趣的缓解落后者的视觉效果（见下文）。

对于单元测试，LibVPX 测试套件在 AWS Lambda 上与 gg 并行构建，并与构建框进行比较 - 两种策略之间的时间差异很小，但作者认为基于 gg 的解决方案能够更早地提供结果因为它的并行性。对于视频编码，gg 的性能比优化的实现（基于 ExCamera）差，尽管基于 gg 的系统引入了记忆和容错。对于对象识别，gg 与 Scanner 进行了比较，“Scanner 是一个分布式系统，用于构建可扩展的高效视频处理应用程序。” - 看到这在 Ray 中实现会很有趣！ ，并观察到显着的加速。作者提到 gg 实现专门针对该任务进行了调整。作者将其归因于 gg 的调度算法并删除了 Scanner 设计中的抽象。虽然 gg 似乎是一个用于扩展命令行应用程序的令人兴奋的系统，但它可能并不最适合每个项目（如实验结果所示）——特别是，gg 似乎很适合加速传统的基于 make 的构建，而无需大规模迁移。论文作者还指出了系统的局限性，例如 gg 与 GPU 程序的不兼容——我之前关于 Ray 的论文评论似乎与未来适应 gg 相关。作为计算基板，我们怀疑云功能在 2000 年代处于与图形处理单元相似的位置。当时，GPU 专为 3D 图形而设计，但社区逐渐认识到它们已经变得足够可编程，可以执行一些与图形无关的并行算法。随着时间的推移，这种“通用 GPU” (GPGPU) 运动创造了系统支持技术，并成为 GPU 的主要用途，特别是用于物理模拟和深度神经网络。云函数可能会讲述类似的故事。尽管旨在用于异步微服务，但我们相信，通过该社区的足够努力，相同的基础架构能够开发广泛且令人兴奋的新应用程序。正如 GPGPU 计算在十年前所做的那样，非传统的“无服务器”计算可能会产生深远的影响。感谢您的阅读，并随时在 Twitter 上提供反馈意见 - 直到下一次！