Uber的QoS负载均衡管理框架QALM介绍

申明：本文转载自https://eng.uber.com/qalm-qos-load-management-framework，由谷歌翻译而翻译。

 

 

Uber的大部分业务涉及人与人之间的联系，这使我们客户平台的可靠性对于我们的成功至关重要。客户平台支持从拼车和Uber Eats到Uber Freight和Uber for Business的所有内容。我们的平台团队拥有拥有数千台主机的四项服务，可为每秒高达300,000个请求的高峰流量提供450多个内部服务。

任何具有这种复杂性的系统都可能会出现故障，尤其是增长如此迅速的系统。通过分析六个月内发生的停机情况，我们发现可以通过适度降级来缓解或避免28％的停机。

我们观察到的三种最常见的故障类型是由于：

• 入站请求模式更改，包括过载和不良参与者
• 资源耗尽，例如CPU，内存，io_loop或网络资源
• 依赖项故障，包括基础结构，数据存储和下游服务

为了根据请求的关键性主动管理流量负载，我们构建了QoS感知负载管理（QALM），这是一种基于关键性的动态传入请求减载框架。当服务由于流量过载，资源耗尽或依赖项故障而降级时，QALM会为优先级更高的请求分配服务器资源的优先级，并丢弃不那么重要的请求。我们与QALM的目标是减少任何中断或事件的频率和严重性，从而在我们的整个业务中提供更可靠的用户体验。

QALM体系结构

我们最初将QALM编写为Go库，将其集成到我们量最大的服务之一的应用程序层中。该框架具有智能过载检测，关键性注册和终结点隔离功能，可以满足服务质量（QoS）要求。通过智能过载检测，QALM可以在服务降级的情况下为关键请求保留资源，而端点级别的隔离可以保护特定的端点免受流量高峰的影响。

智能过载检测

静态的入站速率限制框架会限制请求的设置阈值，但对我们的平台有太多限制。尽管每当我们的服务容量发生变化时都需要更新静态阈值，但是端点之间的服务水平协议（SLA）和容量差异使配置变得复杂。

动态过载检测器提供了更大的灵活性，并提高了硬件效率，尤其是在诸如我们这样的复杂服务中。借助QALM，我们实现了受CoDel算法启发的过载检测器。为每个启用的端点添加了一个轻量级的请求缓冲区（由goroutine和channels实现），以监视从调用方接收到请求并在处理程序中开始处理之间的等待时间。每个队列监视滑动时间窗口内的最小延迟，如果延迟超过配置的阈值，则会触发过载情况。

图1：在QALM中，我们的过载检测器计算缓冲区队列中的请求等待时间以检测过载。

 

端点隔离

为了启用端点隔离，QALM根据其配置创建单独的队列。每个队列都有自己的过载检测器，因此当一个端点发生降级时，QALM将仅从该端点释放负载，而不会影响其他端点。

图2：QALM隔离了端点，因此，如果EP1遭受降解，EP2仍将正常运行。

 

要求关键

QALM引入的最重要功能之一是请求关键度，它可以确保降级期间的QoS。QALM根据Uber的业务需求定义了四个关键级别：

1. 核心基础架构请求：永不放弃。
2. 核心旅行流程要求：永不下降。
3. 面向用户的功能请求：系统过载时可能会被丢弃。
4. 内部流量，例如测试请求：系统过载时被丢弃的可能性更高。

如图2所示，当EP1降级时，仅丢弃来自Consumer1的非关键请求，而来自Consumer2的关键请求仍然成功。

QALM支持本地配置文件和通过Uber服务管理系统集成的简单在线图形用户界面（GUI）。GUI服务利用Jaeger跟踪数据为每个端点和默认关键程度预填充调用者。通过定期进行配置同步，GUI中的更新将在几分钟之内生效。

图3：服务所有者可以使用QALM UI更新端点-呼叫者对的关键程度。

 

负载测试实验

我们使用一项重要的生产服务执行了多次负载测试，以量化QALM如何改善正常降级和重要性意识。集成显着改善了成功请求的等待时间，并在过载期间正确丢弃了非关键请求。

优雅降级

我们以每秒6,000个请求（RPS）的压力测试了一个端点。没有QALM的情况下，延迟会随着时间的增加而恶化，最高可达20秒。实际上，大多数服务会在如此长的延迟后超时。

图4：在没有QALM集成的情况下，P99请求等待时间会非线性增加到〜20秒。

 

在启用动态过载检测的情况下运行负载测试，可为我们带来令人印象深刻的结果。QALM通过丢弃非关键请求（占总数的20％），显着改善了性能下降，将p99延迟保持在400毫秒以下。与没有QALM集成的负载测试相比，成功请求延迟提高了98％。

图5：在过载期间，QALM集成改进了成功请求延迟p99〜400毫秒。

 

 危机意识

在系统负载过多的请求期间，QALM丢弃非关键的请求，同时保留我们指定为关键的请求。在此测试中，我们为两个呼叫者配置了不同的关键程度（document：critical和document-staging：non-critical），使它们以大约2,300 RPS的速率命中同一端点。当QALM检测到系统过载时，它丢弃了一些文档登台请求，因此所有指定为关键的文档请求均成功。

图6：QALM从文档登台中正确识别出非关键请求，在过载期间减少了约50％的请求。

 

从应用程序层到RPC层

在我们构建并测试了QALM之后，我们团队中的四个核心生产服务对其进行了整合，并立即获得了显着的可靠性提升。现在，我们知道该解决方案适用于我们的试点服务，因此我们将精力重新集中在确定其他团队如何使用QALM上。

通过多次采用QALM服务，我们发现集成代码和配置更改会减慢该过程。在考虑如何使QALM对Uber中的其他组可用时，我们重点关注三个值：

1. 减载应该是每项服务的内置功能
2. QALM应该易于配置
3. 服务所有者不必担心将负载削减与业务逻辑代码混合在一起

幸运的是，Uber投资于许多开发人员效率项目。一个这样的项目就是YARPC，这是一个用于Go服务的开源远程过程调用（RPC）平台。YARPC具有灵活而广泛的中间件，可以处理入站和出站请求。

我们将QALM重写为入站中间件，因此可以轻松地将其插入到现有的YARPC服务中。此外，我们为UberFx依赖项注入服务框架创建了QALM模块。通过这种方法，服务所有者在部署QALM时无需进行任何代码更改，并且可以通过简单的配置来实现减载。使用YARPC和UberFx，我们将QALM的实施时间从几天缩短到了不到两分钟。

图7：此图显示了插入YARPC层的QALM入站中间件，因此服务处理程序不需要更改其代码。

 

在将QALM移至应用程序层使实现更加容易的同时，我们需要确保它仍然可以有效地工作。由于QALM为每个端点创建单独的缓冲区，因此不可避免地会导致一些CPU开销。为了了解QALM的影响，我们在单个主机上有五个端点的测试运行中使用了CPU性能分析，每个端点的速度为100 RPS。将这种配置与没有QALM的配置进行比较，我们发现CPU开销仅略微增加了大约3％。

图8：此图显示QALM的CPU使用率低，仅为〜3％的开销。

 

在Uber的生产中使用QALM

为了确保我们新的QALM YARPC插件已准备好在Uber Engineering之间进行集成，我们与另一个小组中的另一个团队启动了封闭式Beta计划。我们将此Beta程序作为改善我们的技术文档和集成支持的机会。

我们选择支持Uber Visa的团队来支持该计划，因为他们的服务有非常具体的可靠性要求：端点级别隔离。该服务的一个关键端点apply 允许最终用户申请信用卡，需要与其他非关键端点流量高峰隔离。

我们的负载测试使用以下参数集中于端点级别隔离：

• 适用端点大约10 RPS，持续30分钟
• 非关键端点getProvidedCards的> 1200 RPS峰值

图9：没有QALM，getProvidedCards达到1,200 RPS之后，所有应用请求都开始超时。

 

图10：启用QALM后，即使getProvidedCard达到1,800 RPS，apply仍可以服务请求。在30分钟的负载测试期间，只有两个请求超时。

 

图11：通过QALM为Uber Visa提供端点级别隔离，我们看到了针对流量高峰的可靠性容忍度提高了50％。

 

外卖

我们开始专门为我们的团队开发QALM，当我们看到它如何提高服务可靠性时，我们知道它可以使整个Uber Engineering团队受益。从开发和集成QALM的经验中，我们吸取了一些教训：

• 可靠性功能不应与业务逻辑混合使用。服务所有者应能够根据需要轻松地将其插入或禁用。将QALM构建到RPC层中使采用变得非常容易。
• 指标胜于雄辩。量化可靠性改进使服务所有者容易理解QALM的价值。通过全面的性能负载测试，我们可以为提高可靠性提供令人信服的案例。
• 文档很重要，特别是对于自助登机。我们提供了全面的Wiki，监视仪表板，负载测试说明以及警报模板，以帮助服务所有者了解该过程。
• 在为RPC层做贡献时，协作非常重要。我们一直在与多个团队合作进行此项目，并主动向利益相关者提供更新。

 

向前进

我们将继续改进QALM，以使团队更容易实施并进一步提高可靠性。具体来说，我们打算：

• 为服务所有者构建自动化流程，以减少进行负载测试时的手动配置，并设置警报以简化集成过程。
• 提高警报阈值，以防止对我们的值班工程师进行非关键性工作。将异常检测与QALM 集成在一起还将提供更准确的警报阈值。

我们对QALM项目的座右铭。

 

If building the next level of customer platform to support Uber’s sustainable growth interests you, come join us to make an impact. 

Subscribe to our newsletter to keep up with the latest innovations from Uber Engineering. 

Acknowledgements

QALM was built by the Customer Platform Foundation Team –  Scott Yao, Ping Jin, Feng Wang, Xin Peng. We would also like to thank Kris Kowal from the RPC team for his collaboration on this project. Lastly, QALM could not have been built without the support from our engineering managers Deepti Chheda, Chintan Shah, and Yan Zhang.