【论文】略读笔记77-前沿-灵活的跨云天空计算

📖《SkyPilot: An Intercloud Broker for Sky Computing》

2023 年 UC Berkeley大学团队 发表于 CCF-A 类会议 NSDI。

🎯需求

• 为了遵守越来越多的有关数据放置和处理的政府法规，并保护自己免受重大云中断的影响，许多用户希望能够在云之间轻松迁移工作负载。
  • 现代信息基础设施围绕三个组成部分构建。这些生态系统显然有许多表面上的差异，但也许它们最根本的差异在于每个生态系统中提供者之间的兼容性程度。
    • (1)互联网提供端到端的网络连接，
    • (2)蜂窝电话通过功能日益强大的手机提供几乎无处不在的用户访问，
    • (3)云计算使所有人都可以使用可扩展的计算。
    • (1)互联网和(2)蜂窝基础设施的设计目标是普遍可达。
      • 这需要统一和全面的行业标准以及广泛采用的互连协议（用于互联网对等互连和蜂窝漫游），从而形成竞争提供商的全球连接联盟。
    • (3)云生态系统有着截然不同的起源，它是作为专用本地计算集群的替代品而出现的，而不是充当互连的通信基础设施。
      • 因此，云提供商一开始就强调它们的差异而不是相似之处；尽管云都基于相同的基本概念单元（例如虚拟机、容器和现在的 FaaS），但它们最初在编排界面上存在很大差异。随着时间的推移，这些编排接口变得越来越相似，但一些云继续通过众多专有服务接口（例如存储或键值存储）来区分自己。
      • 此外，云通常对数据离开收取比数据输入更高的费用，从而导致 “数据引力” （即，由于传输数据的费用而难以将工作转移到另一个云）。
      • 专有服务接口（有限的接口兼容性）和数据引力的结合导致了严重的客户锁定：对于在一个云上建立计算工作负载的公司来说，很难将其转移到另一个云上。
  • 然而，随着云计算已成为我们计算基础设施的重要组成部分，企业越来越担心在云之间迁移工作负载的难度。希望在工作负载分配方面获得更多自由有两个令人信服的理由。
    • a）首先，没有企业希望其基础设施的任何关键部分与单一提供商绑定，因为这种锁定会降低其谈判筹码，也使企业容易受到提供商大规模中断的影响。
    • b）其次，现在有关于数据和操作主权的严格规定，规定了数据可以存储在哪里以及计算作业可以在哪里运行。并非所有云提供商在所有国家/地区都设有数据中心，因此无法在云提供商之间迁移工作可能会成为满足这些新法规的痛苦障碍。
    • 这两个原因并不是“可有可无”的理论问题。最近发生的大规模云中断以及越来越多的政府法规正在迅速使这种解决方案成为大规模云用户的“必备”。

🚧现状

• 我们首先回顾与迁移工作负载能力相关的两个概念——标准和多云，然后讨论兼容性方面的最新进展。

（1）为什么不直接采用标准？

• 人们可能会问的第一个问题是，如果无缝迁移是目标，为什么不采用一套统一且全面的云标准，就像互联网和蜂窝网络所做的那样？
  • 事实上，十年前，IEEE 提出了一套针对云提供商之间的可移植性、互操作性和联合的 Intercloud 标准，涉及 Intercloud 服务目录和 Intercloud 联合层。对于这种统一和全面的云标准，此提案和其他提案存在两个基本问题。
  • a）首先，主导云（即拥有较大市场份额的云）没有动力采用此类标准；这会降低他们的竞争优势，并使客户更容易将其业务转移到其他云。
  • b）其次，除了 Kubernetes 等底层编排接口之外，用户还使用 PyTorch 或 TensorFlow 等高层服务接口与多个级别的云进行交互。如果目标是实现工作负载无缝迁移，那么所有这些接口都需要标准化。要求每个云标准化每个接口既不现实（如第一个反对意见中所述）也不明智（因为这些更高级别的接口随着时间的推移已经发生了显着变化，标准化它们将极大地阻碍创新）。

（2）为什么现有多云技术还不够？

• a）灵活性差：多云现已成为行业流行语，有报告表明大多数企业已经或即将拥有多云部署；这似乎意味着我们无缝工作负载迁移的目标已经实现。然而，多云一词的常见使用仅要求企业在两个或多个云上运行工作负载（例如，财务团队在 Amazon 上运行后端功能，而分析团队在 Google 上运行 ML 作业），而不是说他们可以轻松地在在云之间移动这些工作负载。从我们采访过的业内每个人看来，很明显，在云之间移动许多工作负载仍然很困难。
• b）独占性强：例外的是最近在多个云上运行的第三方产品（例如 Trifacta、Confluence、Snowflake、Databricks 等），用户确实可以相对轻松地在云之间迁移仅使用这些服务的工作负载（Google 提供的 BigQuery 提供类似的跨云支持）。但是，这些都是针对特定工作负载的，并不为工作负载迁移提供一般支持。
• c）自动性差：此外，还有多种支持多云的编程或管理框架。 JClouds 和 Libcloud 提供了对许多提供商的计算、存储和其他服务的可移植抽象。然而，用户仍然手动进行放置，而自动放置是SkyComputing的一个关键功能。
• d）管理层级过低：在管理方面，Terraform 在不同的云上配置和管理资源，但需要使用特定于提供商的 API，并且也不处理工作安排。 Kubernetes 编排容器化工作负载，并且可以跨多个云运行（例如 Anthos）。这些框架虽然非常有价值，但专注于在云提供的较低级别基础设施接口中提供更多兼容性（请参阅第 2.3 节），因此与 SkyComputing 很好地互补，但并不能消除对 SkyComputing 的需求。

（3）接口兼容性的趋势

• 如前所述，云计算的用户调用各种各样的计算和管理接口。其中许多是开源系统，已成为软件堆栈不同层的事实上的标准，包括：
  • 操作系统（Linux）、
  • 集群资源管理器（Kubernetes、Apache Mesos）、
  • 应用程序打包（Docker）、
  • 数据库（MySQL、Postgres）、
  • 大数据执行引擎（Apache Spark、Apache Hadoop）、
  • 流引擎（Apache Flink、Apache Spark、Apache Kafka）、
  • 分布式查询引擎和数据库（Cassandra、MongoDB、Presto、SparkSQL、Redis）、
  • 机器学习库（PyTorch、TensorFlow、MXNet、MLflow、Horovod、Ray RLlib）
  • 以及通用分布式框架（Ray、 Erlang、Akka）。
• 此外，AWS **的一些接口越来越多地在其他云**上得到支持：
  • Azure 和 Google 为其 Blob 存储提供类似 S3 的 API，以便客户更轻松地从 AWS 迁移到自己的云。
  • 同样，用于管理机器映像和专用网络的 API 也在融合。
• 这说明有限的接口兼容性正在成为趋势，其中：
  • 尽管部分API有兼容性，但这种兼容性仅适用于单个接口；
  • 并且这些接口通常不受所有云支持，而是受有限个云支持。
• 根据我们在生态系统中看到的情况，我们的论点是，这些具有有限兼容性（即在多个云上支持）的接口的数量和使用量正在增加，这主要是由于开源的努力。
• 我们的方法基于这样的信念：这一趋势将持续下去，并且利用这一趋势远比追求统一和全面的标准更可取。
  • 套用林肯的一句话，我们知道所有接口都被某些云支持，并且某些接口可能被所有云支持，但我们不能也不应该要求所有接口都被所有云支持。

🛩创新

• 在本文中，我们建议不要通过强加统一和全面的标准来实现这一目标，而是通过云间代理创建细粒度的双边市场。这些代理将允许用户不只是将云生态系统视为单个且基本上不兼容的云的集合，而且视为更加集成的计算天空。我们描述了名为 SkyPilot 的云间代理的设计和实现，评估其优势并报告其实际使用情况。
• 我们首先描述什么是天空计算，并阐明为什么我们认为它不仅是渐进性的，而且是颠覆性的。

什么是天空计算？

• 天空计算这个概念首次在[2]中引入，但在这里得到了显着扩展和更深入的探讨。天空计算是指用户不直接与云交互，而是将其作业提交给我们所谓的云间经纪人，后者负责处理放置并监督其作业的执行。
• 在这种有限的接口兼容性不断增加的情况下，我们如何利用它来缓解工作负载迁移?有两个关键的组成部分。
  • （1）首先，为了降低数据引力，云可以进入对等的自由数据对等；也就是说，两个云可以同意让用户在不收取费用的情况下将数据从一个云移动到另一个云。
    • 随着高速连接(许多云有100Gbps的连接到各种互连点,它们可以与其他云对等)的盛行，我们认为这种自由对等很容易得到支持，其它所能实现的收益增加超过所产生的成本。
    • 人们可能担心这种传输引起的延迟，但如果由此产生的计算时间在数据大小(或具有合理的高常数的线性)上是超线性的。（？）
  • （2）第二个组件，也是我们在本文其余部分重点关注的组件，就是我们所说的云间代理。
    • 在本文中，我们描述了我们的 intercloud 代理，它是专门为计算批处理作业而设计的。虽然批处理作业（例如 ML、科学作业、数据分析）仅代表当今多样化云用例的一小部分，但它们的计算需求正在快速增长，并且导致了最近专用硬件的激增。因此，我们从一个为批处理作业设计的代理开始，作为一种易于处理但常见且快速增长的工作负载。我们预计代理的未来版本将解决更广泛的工作负载，并提供更广泛的功能，但这不是我们的重点。
    • 此外，我们预计最终将有一个开放的云间经纪商市场，其经纪服务收取少量费用；其中一些代理将是通用的，而其他代理则更适合特定的工作负载，就像我们的一样。
• 云间代理将计算请求作为输入，该计算请求被指定为**有向无环图 (DAG)**。
  • 这是由工作流系统提供的，该系统现在已成为编排复杂批处理应用程序的事实上的标准。
  • 其中节点是粗粒度计算（例如数据处理、训练）。由于缺乏更好的术语，我们将这些计算称为“任务”。该请求还包括用户对价格和性能的偏好。
• 然后，云间代理负责跨云放置这些任务。
  • 与每个云运行应用程序实例的现有多云应用程序不同，云间代理可以跨多个云运行单个应用程序实例。
    • 例如，图 1 显示了包含三个任务的机器学习 (ML) 管道：数据处理、训练和服务。用户可能希望在安全处理数据的同时最小化总成本。云间代理可能决定在 Azure 机密计算上运行数据处理以匿名化数据，从而保护数据机密性，在 GCP（Google Cloud Platform） 上进行训练以利用 TPU，并在 AWS 上提供服务以利用 Inferentia 加速器。
  • 划分应用程序的能力使得专用云的出现成为可能。例如，云提供商只需专注于单一任务（例如 ML 训练）并为该任务提供最佳性价比，就可以建立成功的业务；有关此问题的更详细讨论，请参阅正文附录§A.1部分。
• 此外，即使应用程序在以下两种情况，云间代理也能提供优势：
  • (i) 完全在单个云上运行，通过自动选择最符合用户偏好的云并选择该云内的最佳区域和区域，
  • 或 (ii) 使用仅由单个云提供的服务，将任务放置在该云上，但仍然可以自由地使用其他云来执行其他任务。
    • “服务”是指由一个或多个云提供的计算服务或托管服务，例如托管的 Apache Spark（例如，EMR、HDInsight）和托管的 Kubernetes（例如，EKS、GKE，或 AKS）。仅由单个云提供，将任务放置在该云上，但仍然可以自由地使用其他云来执行其他任务。
      

为什么是颠覆性的？

我们将其视为云计算的变革，而不仅仅是工作负载迁移的战术机制，这有三个原因，每个原因都从不同的角度来看。

• （1）用户的视角：使用云间代理时，用户不再与单个云交互，而是与更集成的计算“天空”交互。他们只需指定计算结果和标准，然后经纪人就会安排工作。这使得云的使用变得更加容易，并可能导致云的采用率增加。请注意，这样的界面隐藏了云之间和云内部的异构性。用户不再需要研究哪些云具有最优惠的价格，或提供特定的服务。这也适用于单个云，因为云中的不同区域可以提供不同的硬件选项和不同的价格。
• （2）竞争视角：请注意，通过充当用户和云之间的中介，云间代理正在创建一个细粒度的双边计算市场：用户指定他们的任务和要求，云提供其定价和性能的接口。工作安排不再主要由促进锁定的措施（例如专有接口和数据引力）驱动，而是越来越多地由每个云通过更快和/或更经济高效的实施来满足用户需求的能力驱动。这意味着，为了扩大市场，云可能会开始支持工作中常用的接口，从而推动市场提高兼容性。
• （3）生态系统视角：一旦建立了双边市场，云生态系统就可以从所有云都提供广泛的服务并尽力锁定客户的生态系统转变为许多云致力于成为其中一部分的生态系统。计算天空，他们可以专注于某些任务，因为如果他们最好地满足用户对这些特定任务的需求，云间代理将自动将计算定向给他们；正文附录（§A.1.2）中的经济分析使这种情况更加准确。

这一愿景应该与现实相结合。

• （1）首先，虽然我们预计一些云将通过专注于兼容接口和采用互惠的免费数据对等来拥抱天空计算的愿景，但我们预计其他云，特别是那些拥有主导市场地位的云，将继续将锁定作为一种市场策略。尽管如此，可行的替代云生态系统的存在将为创新和满足用户需求设定标准，因此所有用户都将受益。
• （2）其次，我们假设天空计算的创建将是一个漫长的过程，将缓慢开始并逐渐积聚动力。我们本文的目标是研究如何开始这种转变，而不是定义其最终形式。因此，我们从用于批处理作业的云间代理开始——一组小但重要的工作负载。
• （3）第三，鉴于我们专注于Sky的早期阶段，我们没有为最终必须解决的几个问题提供解决方案，例如如何解决跨多个云运行的应用程序发生的故障。

📊效果

• SkyPilot 是开源的，可从 https://github.com/skypilot-org/skypilot 获取。

⛳️未来机会

• 我们预计代理的未来版本将解决更广泛的工作负载，并提供更广泛的功能。

🧠疑问

1. 本文的描述方式、故事线很有意思，不愧是数年磨一剑的产品。“数据引力”的描述很形象。
2. 为什么互联网和移动蜂窝就能够接纳“统一标准”？是因为接纳后能够为自己带来更广阔的市场？为什么云计算就不可以？是因为大家产品本身的差异化不够明显，所以统一反而容易让别人抢占市场？还是说只是因为现在的供应商呈现几乎垄断的态势，所以在初期更难推进、在未来还是有可能的？并没有感受到在本质上云计算和另外两类（互联网和移动蜂窝）的区别。
3. 解决“数据引力”的“对等的自由数据对等”在市面上如何支持？有什么产品能够支持？
4. 跨云传输数据的时间开销能够忽视？没有足够的论据。根据现有共识，跨云传输会导致模型训练时间大大延长才对。
5. SkyPilot的输入是什么？能够获取多云的什么信息？
   • 通过“Catalog”组件维护，记录每个云中的可用实例和服务信息。具体包括详细位置、分配/关闭/访问API、按需VM/数据存储/数据出口/服务的长期价格（通常长期不发生变化）。
   • 看起来一个假设是“云是无限的”，比较符合日常使用场景。但如果在云资源不足的情况下则不适用。

---

---

• 希望这篇博客对你有帮助！如果你有任何问题或需要进一步的帮助，请随时提问。
• 如果你喜欢这篇文章，欢迎动动小手给我一个follow或star。

🗺参考文献

[1] Yang, Zongheng, et al. “{SkyPilot}: An intercloud broker for sky computing.” 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23). 2023.

[2] Ion Stoica and Scott Shenker. From cloud computing to sky computing. In Proceedings of the Workshop on Hot Topics in Operating Systems, HotOS ’21, page 26-32, New York, NY, USA, 2021. Association for Computing Machinery.