SkyPilot: An Intercloud Broker for Sky Computing 论文阅读
我就说 Sky Computing 怎么没在 Skyplane 上写，原来搁这儿呢。
文章中「任务负载」指的是 workload。
论文在这里。
Abstract
为了遵守越来越多的关于数据存放和处理的政府法规，并保护自己免受重大云中断的影响，许多用户希望能够在云之间轻松迁移他们的任务负载。在本文中，我们不通过强加统一和全面的标准，而是通过云代理创建一个细粒度的两方市场来做到这一点。这些代理将使用户不只把云生态系统看作是一个单独的、基本不兼容的云的集合，而是看作是一个更加综合的「计算天空」。我们进行了一个名为 SkyPilot 的云代理的设计和实现，评估了它的优势，并报告了它的实际使用情况。
这里面 Sky of Computing 没有中文翻译，只是简单翻译成「计算天空」了。总之它是一个整合了各种云服务商资源的东西，是一个云服务之上的逻辑。原文「代理」对应的是 broker 这个单词，翻译是来自消息队列的 broker 的意思。
Introduction
现代信息基础设施是围绕三个部分建立的。互联网提供了端到端的网络连接，蜂窝电话通过日益强大的手持设备提供了泛在用户访问，而云计算使所有人可以使用可扩展的计算资源。这些生态系统表面上显然有许多区别，但它们最根本的区别也许在于每个生态系统中的供应商之间的兼容程度。
互联网和手持设备基础设施的设计目标是实现普遍可及性。这需要统一和全面的行业标准和广泛采用的互连协议（用于互联网对等和手机漫游），因此产生了一个全球连接的竞争性供应商联盟。
比如 IETF 和 3GPP？大概吧。
云生态系统有着非常不同的起源，它是作为专用的内部计算集群的替代品出现的，而不是作为一个互联的通信基础设施。因此，云供应商一开始就强调他们的不同之处，而不是他们的相似之处；虽然云都是基于相同的基本概念单元（如虚拟机、容器和现在的 FaaS），但他们最初在编排接口上有很大的不同。随着时间的推移，这些编排接口已变得更加相似，但一些云继续通过许多专有的服务接口（如存储或 KV 存储）来区分自己。
这里的编排接口应该指的是 API 接口，毕竟没有接口文档和规范，想咋写咋写，所以每家基本都有自己的 API 接口和参数。
此外，云通常对离开的数据征收比进入的数据高得多的费用，导致了「数据重力」（即由于转移数据的费用，很难将任务转移到另一个云中）。
这个工作就是 Skyplane 关注的。
专有服务接口和数据重力的结合导致了严重的客户锁定：已经在一个云上建立计算任务负载的公司很难将其转移到另一个云上。
然而，随着云计算已经成为我们计算基础设施的重要组成部分，企业越来越担心在云之间迁移任务负载的难度。对于企业希望在任务负载安置方面有更多的自由这件事，有两个令人信服的理由。首先，任何企业都不希望将其基础设施的任何关键部分捆绑在一个供应商身上，因为这种锁定减少了他们的谈判筹码，也使企业容易受到供应商大规模故障的影响。其次，现在有关于数据和操作主权的严格规定，决定了数据可以在哪里存储，计算任务可以在哪里运行。并非所有的云供应商在所有国家都有数据中心，所以无法在云供应商之间迁移任务可能是满足这些新法规的一个痛苦的障碍。
这两点原因分析十分精彩，是很符合当前现状的。
这两个原因不是理论上的问题，其解决方案将是「有了更好」；最近发生的大规模云中断和越来越多的政府法规正在迅速使这种解决方案成为云的大规模用户的「必须」。
产生这个需求的原因并不是理论不够好，而是一系列外部因素导致的。
本文描述了我们如何通过 Sky Computing 的兴起来缓解任务负载的迁移，这一概念最早是在 HotOS '21 中提出的，但在这里得到了显著的扩展和更深入的探讨。Sky Computing 是指用户不直接与云互动，而是将他们的工作提交给我们所说的云代理，由他们处理任务的安排和监督任务的执行。
Related Concepts and Recent Developments
本节将讨论两个相关概念：标准和多云（multicloud）并讨论最近在兼容性方面的进展。
主要将围绕两个关心的问题进行讨论。
为什么不直接采用标准
人们可能会问的第一个问题是，如果目标是无缝迁移，为什么不采用一套统一全面的云计算标准，就像为互联网和蜂窝电话所做的那样？事实上，十年前，IEEE 就提出了一套云际标准，涉及云际服务目录（Intercloud Service Catalog）和云际联合层（Intercloud federation layer），为了实现云供应商之间的可移植性、互操作性和联合。这个和其他关于这种统一和全面的云计算标准的提案有两个基本问题。首先，占主导地位的云（即那些拥有大量市场份额的云）没有动力采用这种标准；这将降低他们的竞争优势，使客户更容易将业务转移到其他云。其次，用户在很多层面上与云交互，除了使用 PyTorch 或 TensorFlow 等高级服务接口外，还会使用 K8s 等低级别的编排接口。如果目标是使任务负载无缝迁移，那么所有这些接口都需要标准化。
这两个分析都是面临的关键问题，首先是云厂商没有动力，其次是接口已经被 well-developed 了，再开一套规定一个新标准肯定是不现实的。可能早点标准化也就没这么多事了，事后才想起来应该这么干，但是已经被资本绑架了，这样改变起来就很难了。
要求每个云对每个接口进行标准化既不现实（如第一个反对意见所述），也不明智（因为这些高级接口随着时间的推移发生了很大的变化，对它们进行标准化会大大阻碍创新）。
这个东西为什么不是多云？
多云现在是一个行业热词，有报道称大多数企业已经或即将进行多云部署；这似乎意味着我们无缝任务负载迁移的目标已经实现。然而，多云一词的普遍使用只要求企业在两个或更多的云上有负载（例如，财务团队在亚马逊上运行他们的后台功能，而分析团队在谷歌上运行他们的 ML 任务），而不是说他们可以轻松地在云之间移动这些任务负载。从我们与业内人士的交谈中可以看出，在云之间移动许多任务负载仍然很困难。
要想理解区别的话可以看 Cloudflare 的描述，多云虽然是部署在多个云服务商的，但是这种部署仍然是粗粒度的。比如把人资放到一个云上，把 ML 放到一个云上，数据存储再放到另一个云上。而 Sky Computing 是一种细粒度的，比如把 ML 的一些过程分配在不同的云上，是要移动 workload 的，多云不涉及 workload 的移动。
这方面的例外是最近在多云上运行的第三方（如 Trifacta, Confluent, Snowflake, Databricks 等），用户确实可以相对轻松地在云之间迁移仅使用这些服务的工作负载（Google 提供的 BigQuery 提供类似的跨云支持）。然而，这些第三方只针对特定的 workload，不提供通用的 workload 迁移。
此外，现在也有如 JClouds 和 Libcloud 这样的编程和管理框架支持多云。他们提供了对许多对供应商的计算、存储和其他服务的可移植抽象。然而，用户仍然手动去放置任务，而 Sky Computing 的一个关键特性就是可以自动放置任务。在管理前端方面，Terraform 在不同的云上准备和管理资源，但需要使用供应商特定的 API，而且也不处理任务放置。K8s 编排容器化的任务负载，可以在多个云上运行（例如 Anthos）。这些框架虽然很有价值，但侧重于在云提供的较低级别的基础设施接口中提供更多的兼容性（见下一节），因此与 Sky Computing 有很好的互补性，但并不排除对 Sky Computing 的需求。
这里的「放置」是 placement，就是把任务安排到某个机器上运行。
接口兼容性的发展
抛开相关概念，我们现在讨论一下 Sky Computing 将利用的一个最新进展。就像之前提过的，云计算用户会与大范围的计算或管理接口交互。它们中的大多数都是开源系统并且已经成为了事实标准，此外，AWS 的接口在其他云上被广泛支持： Azure 和 Google 为他们的对象存储提供类似 S3 的 API，使客户更容易从 AWS 转移到他们自己的云中。类似地，用于管理机器镜像和私有网络的 API 也在不断融合。
这些趋势增加了我们所说的有限的界面兼容性，其中这两个限定词都很关键。这种兼容性只适用于个别接口，这些接口通常不被所有云支持，而是被多个云支持。根据我们在生态系统中看到的情况，我们的论点是，这些具有这种有限兼容性的接口——即在一个以上的云上得到支持——的数量和使用正在增加，主要但不完全是由于开源的努力。
我们的做法是基于这样的信念：这一趋势将继续下去，利用这一趋势远比追求统一和全面的标准更可取。套用林肯的一句话，我们知道所有的接口都被一些云支持，一些接口可能被所有的云支持，但我们不能也不应该要求所有的接口都被所有的云支持。
The Vision of Sky Computing
什么是 Sky Computing
鉴于这种有限的接口兼容性水平不断提高，我们如何利用它来缓解工作负载迁移问题？有两个关键部分。首先，为了减小数据重力，云可以达成互惠的免费数据对等；即两个云可以同意让用户将数据从一个云转移到另一个云而不收费。随着高速连接的盛行（许多云有 100Gbps 的连接到各种互连点，他们可以与其他云对等），我们认为这种免费对等可以很容易地得到支持，其成本被它所带来的计算收入的增加所抵消。
这里的互联点相当于 IXP，云服务商毕竟也要对外提供服务，他们自己就可以成为一个 ISP 了。但是 IXP 这种模式会不会实现，毕竟现在大家都用 S3-like 接口了，不存在 lock-in 的问题，那大家有钱一起赚，建基础设施的钱可能没多久就收回来了，感觉还是可行的。
人们可能会担心这种传输产生的延迟，但如果由此产生的计算时间与数据大小成超线性关系（或与一个合理的大常数成线性关系），那么无论数据集变得多大，网络延迟都不会成为一个主要瓶颈。
超线性就是多项式函数关系，但是特指
中 的情况。也就是说，计算永远比数据传输慢得多（多项式地大于），从现在的情况看来确实是这样，网络越来越快，计算量越来越大导致计算越来越慢。
第二个关键部分，也是我们在本文其余部分关注的部分，就是我们所说的云代理。在本文中，我们描述了我们的云代理，它是专门为计算批处理任务而设计的。虽然批处理工作（如 ML、科学任务、数据分析）只占今天不同的云使用案例的一小部分，但它们的计算需求正在迅速增长，是最近专门硬件激增的原因。因此，我们从一个为批处理作业设计的代理开始，作为一个可操作的、常见的和快速增长的任务负载。我们期望未来版本的代理将解决更广泛的工作负载，并提供更广泛的功能集，但这不是我们在这里的重点。此外，我们预计，最终会有一个开放的云代理市场，对其代理服务收取少量费用；其中一些代理公司将是通用的，另一些则更多地针对特定的工作负载，就像我们的那样。
我记得云安全技术课上讲了云代理，但是发展并不好。所以 Sky Computing 能不能翻译成云代理
一个云间的计算任务用一个 DAG 来描述，其中点是一种粗粒度的计算（比如数据处理，训练）。
因为 Airflow 里就这么定义的，已经是事实标准了。但是实际上是不是事实标准，我不知道
由于缺乏一个更好的术语，我们把这些计算称为「任务」。该请求还包括用户对价格和性能的偏好。
然后，云代理负责将这些任务放在不同的云中。与现有的多云应用不同的是，云代理可以在多个云中运行同一个应用实例。比如对于一次学习任务，可能使用 Azure 的 Azure Confidential Computing 进行加密的数据处理，在 GCP 上利用 TPU 进行模型训练，然后把服务放到 AWS 上利用 Inferentia 加速。
对应用进行分片的能力使专门的云出现。例如，云供应商可以通过专注于单一任务，如 ML 训练，并为该任务提供最佳性价比来建立成功的业务。
现在的云几乎都提供 general propose 的业务，Sky Computing 关注于特定目的的业务
此外，即使在应用程序完全在单一云上运行的情况下，云代理也有优势，它能自动选择最符合用户偏好的云，并在该云中选择最佳区域和区域，或者使用仅由单一云提供的服务，将任务放在该云上，但仍可自由使用其他云完成其他任务。
为什么这是一个转型
有三个原因，每一个都是从不同的角度，为什么我们认为这是云计算的一个转型，而不仅仅是任务负载迁移的机制。
用户方面
当使用云代理时，用户不会与独立的云进行交互，而是与一个更集成的「Sky」进行交互。用户只需指定他们的计算方法和标准，然后云代理就会安排任务。
这就是我想在算力网里要的东西
这使云的使用变得非常容易，并可能导致云的采用率提高。请注意，这样的接口隐藏了云之间和云内部的异构性。
我的想法是，无论是科学计算还是机器学习，都相当于一个函数，这个函数很大，但是运行过程都是输入数据然后输出数据，而不是像 Web 服务一样是持续对外提供的。所以针对这种十分特殊的服务，可以采取这种任务流式的描述。其次，大伙都很关心实现和运行，希望跑起来快点，费用低点，但是确实不知道有什么方法来安排任务，如果有这么个东西，大伙就不必关心运维细节，直接丢任务上去就可以了，对于研发来说这是十分好的事情。
用户不再需要研究哪个云有最好的价格，或提供特定的服务。这也适用于单个云中，因为一个云中的不同区域可以提供不同的硬件选择和不同的价格。
竞争方面
我也觉得很怪，英文是 Competitive Perspective
请注意，通过充当用户和云之间的中介，云代理为计算创造一个细粒度的两方市场：用户指定他们的任务和要求，而云则提供他们的接口及其定价和性能。
任务安排不再主要由促进锁定的措施（如专有接口和数据重力）驱动，而是越来越多地由每个云通过更快和/或更有成本效益的实施满足用户要求的能力驱动。
这里指使用云代理建设良性市场，现在的市场是一个卖方市场，各大云服务商几乎垄断了云服务提供。如果想在某个云上部署一个应用，那就得部署全套的，如果分一半一半部署，那就有网络瓶颈，要么就大幅增加开销。
这意味着，云计算为了增加其市场，可能会开始支持工作中常用的接口，推动市场增加兼容性。
云服务商毕竟也是企业，如果没活整了总得找点新增长点。并且对于初创企业，怎么跟现在的云服务商打差异化，以获得自己的增长点，这也是一个需要考虑的问题。
生态系统方面
一旦建立了两方市场，云生态系统就可以从所有云提供广泛的服务并尽力锁定客户的模式，过渡到许多云专注于成为「计算天空」的一部分，它们可以专门从事某些任务，因为如果它们最能满足用户对这些特定任务的需求，云代理会自动将计算引向它们；附录中的经济分析更精确地说明了这一情况。
这一愿景应该用现实来调和。首先，虽然我们设想一些云将通过专注于兼容接口和采用互惠的自由数据对等来拥抱 Sky Computing 的愿景，但我们预计其他云，特别是那些具有主导市场地位的云，将继续把锁定作为一种市场战略。尽管如此，一个可行的替代性云计算生态系统的存在将为创新和满足用户需求设定标准，因此所有用户都将受益。
其次，我们假设 Sky Computing 的建立将是一个漫长的过程，它将缓慢地开始并逐渐形成势头。我们在本文中的目标是研究如何开始这一转变，而不是定义其最终形式。因此，我们从批处理工作的云代理开始——这是一组小而重要的任务负载。
第三，考虑到我们对「Sky」早期阶段的关注，我们没有提供最终必须解决的几个问题的解决方案，例如如何排除在多个云上运行的应用程序发生的故障。
Intercloud Broker
前置需要
- 对云服务和实例进行编目
- 跟踪定价和动态可用性：可能运行时就被抢占了，8 天里被抢占了 319 次
- 动态优化：根据目前的可用性和价格进行重新优化
- 管理资源和应用程序
架构
总体架构图如下图。
实现
Skypilot 大概有 21,000 行 Python 代码。目前支持 AWS，GCP 和 Azure 三个云服务商。
代码提供了一堆 API，可以指定任务，设置输入输出和资源，并且需要提供一个估计任务完成时间的函数，之后按策略把任务连起来就好了。
之后是他们的优化器，又是一个 ILP 问题。考虑
给定一张 DAG
令
总之根据这个可以列目标
其中
还可以优化端到端时间，也就是最小化任务结束时间。定义
其实应该是后面的最小值的，但是由于 DAG 性质确实可以这么写，也只有这么写才能写成一个线性规划的形式。总之还是同样方法把第二项线性化掉之后用 ILP 求解。
后续还可以加上碳排放的考虑，做到绿色计算。
Experiments
实验进行了三种任务的测试，分别是机器学习，生物信息和数据分析。机器学习做了 CV 和 NLP 两类任务的。生物信息做的有点类似于 HPC 那样长任务，多资源的，数据分析用到了不同的软件服务和硬件架构。看数据效果是很好的，时间降低了，并且花费也更低。
同时也对 Skypilot 本身进行了测试，发现在简单的任务拓扑上规划得很快，但是在复杂的拓扑上跑得很慢，原因是解空间太大了，跑 ILP 确实很慢。但是由于 DAG 中的每个任务都是粗粒度的（例如，可能需要几个小时），跑 ILP 的时间在 DAG 运行时间中是可以忽略不计的。
如果资源可用性在运行期间发生变化，可能需要对 DAG 进行重新优化，以生成一个修订的执行计划。由于重新优化的过程涉及到更新可行集群的列表和重新启动 ILP 优化，其开销与初始优化的开销相当。
反正重新规划的话就得重新跑一遍，好像没有增量规划的方法。
Deployment Experience
现实中有 3 所大学和 4 个其他组织使用了 Skypilot。使用 Skypilot 给他们提高了生产力，因为它提升了云的可用性。例如，用户喜欢云代理自动提供的跨云或跨地区的稀缺资源的能力，容易获得最佳的硬件（如 TPU），以及对现有程序的简单打包。此外，通过与代理而不是云的互动，他们重视在不同的云上运行相同工作的能力，而无需改变他们的代码或工作流程。
使用 Skypilot 还可以实现集群复用，以实现更快的开发和调试。还可以利用 On-premise 的集群，实现本地和云的协同计算。但是挑战包括设计溢出规则和处理兼容性和存储。
Related Work
实际 Sky Computing 这个名词在 2009 年就已经出现了，然而，这些论文侧重于特定的技术解决方案，如在跨云 IaaS 平台上运行中间件（如 Nimbus），并针对特定的工作负载，如 HPC。本文从更广泛的角度看待 Sky Computing，将其视为整个生态系统的变化，并考虑技术趋势和市场力量如何在 Sky Computing 的出现中发挥关键作用。
Comment
在 Skyplane 里面的那堆 ML 的东西都挪到这儿来了。虽然说在实验中确实也举了生物信息，数据分析的例子，但是感觉还没有很强的需求放在 HPC 上。
在附录里确实对经济效益做了十分简单的分析，不是那种特别完备的分析，但是也没怎么看懂。总之从经济效益来看，Sky Computing 确实有效地建立了一个两方市场。两方市场是很常见的，它们通常受到那些拥有高利润并希望保持高利润的市场参与者的反对，但也受到那些努力在市场上站稳脚跟的人的欢迎，因为他们无法克服市场主导者的固有优势（如更好的知名度、更大的销售队伍等）。在目前的云计算市场上，只有亚马逊和 Azure 可以被视为具有市场支配地位；所有其他云计算供应商的市场占有率都低于 10%。对于所有这些其他的云计算供应商（大约占目前云计算市场的一半），Sky Computing 可能是最好的选择。
但是至于它今后的发展，是只停留在论文上，还是会有厂商跟进。它这个东西代码实现都两年多了也没见有厂商跟进，怕不是要凉。
All it needs is time, again.
P.S. 最近感觉看论文看多了就有种自己也能发 CCF-A 的错觉。