ASPLOS’19 Parties

ASPLOS’19 Parties

PARTIES: QoS-Aware Resource Partitioning for Multiple Interactive Services

Parties

Abstract

这限制了多租户的高效收益，特别是随着越来越多的云应用程序从批量作业转换到具有严格延迟要求的服务 。

Parties:一个QoS感知资源管理器，它可以启用任意数量的交互式latency-critical（LC）服务，以共享没有QoS干扰的物理节点。 Parties利用一组硬件和软件资源分区机制，以在运行时中动态调整分配，以满足每个共调度工作负载的QoS要求，并最大限度地提高机器的吞吐量。

Introduction

由于resource flexibility和cost efficiency成本优惠，云计算变得十分普遍。

resource flexibility的实现通过：用户可以按需扩展资源；cost efficiency的实现通过：多租户。通过在同一物理主机上调度多个用户的任务，提高利用率来实现。 不幸的是，多租户通常来自performance penalty，因为共同调度的应用争夺共享资源，导致干扰和性能的不可预测性。 干扰对于必须满足严格的服务质量（QoS）保证的交互，latency-critical（LC）服务是具有非常破坏性的。

之前的工作以三种方式解决干扰。

1）简单地禁止交互式服务与其他应用程序共享资源以避免干扰。 这保留了LC应用程序的QoS，但降低了系统的资源有效性。

2）避免共同调度可能会互相干扰的应用。 这提高了利用率，尽管它限制了可以共同调度的应用程序的选择。

3）专注于消除干扰，通过使用OS和硬件级别隔离技术在共同调度服务之间分配资源partition resources。 此方法可保护LC服务的QoS，并允许Best-Effort（BE）的工作负载利用未使用的资源。 遗憾的是，这种方法目前最多仅限于一个物理主机：一个交互服务，并共同调度一个或多个BE任务。 如果多个交互式应用程序在物理主机上共同调度，则它们的负载会显著下降，导致未充分利用。

云应用程序正逐步从批处理向低延迟服务转移。 例如，传统上的，throughput-bound的应用程序，如大数据和图形分析，现在正在转向in-memory computation内存计算，如Spark和X-Stream 等框架，它将任务执行延迟变为几毫秒或几秒。此外，云应用程序正在经历从单一庞大的服务转变为大量松耦合的微服务的重新设计 。 虽然大规模服务的端到端延迟仍然在几毫秒或秒的粒度下，每个微服务必须满足更严格的延迟约束，通常约为数百微秒。除此之外，每个微服务都驻留在一个小的，无状态stateless的容器中，这意味着大量的容器需要在一个物理主机上调度以最大化利用率。 因此，只允许每台计算机有一个高优先级LC服务的技术不足以管理这些新的应用程序场景。

在这篇文章中，作者提出了Parties（