介绍

在Wayfair上,我们通常从基础设施的角度讨论可伸缩性——例如,当考虑为即将到来的假日季节供应多少服务器时,我们通常的反应是根据市场团队的客户数量预测来计算。然而,尽管这种数据来源在作出此类决定时无疑是有用的,但它并不总是充分的。根据预测的客户容量数据来确定额外的服务器容量需要假设吞吐量将在更高的用户负载下继续线性增长,并且添加额外的硬件总是有助于吸收额外的负载。但是,情况并不总是这样。

随着硬件的增加,负载的增加是很容易理解的;随着硬件变得越来越便宜,简单地通过配置(增加比我们需要的更多的容量)来避免性能瓶颈似乎是一个越来越有吸引力的选择。不幸的是,性能瓶颈更可能出现在应用程序设计中,而不是系统的硬件中,而且大多数软件系统在更高的规模下表现为非线性。因此,应该避免简单地将更多硬件扔到瓶颈处的诱惑,因为它不一定会得到改善性能1

但是,即使附加硬件做了总是要提高绩效,额外的/不必要的能力会减少分配的预算。通常,开发新服务的软件团队会向我们的基础架构团队要求更多的硬件,因为他们没有过去的数据可以依靠。但是,通过采用科学的、基于数据的方法来计算必要的能力,如Wayfair目前正在开发的模型,可以避免这种不必要的开支。

确定所需容量的一种典型方法是在每个用户负载级别上进行负载测试,以确定峰值吞吐量。吞吐量停滞或开始下降的输入负载水平被确定为系统的最大吞吐量/容量。这种方法在单台服务器或相对较小的服务器组上工作得非常好,在这些服务器中可以相当快地实现峰值吞吐量。然而,在设计为水平可伸缩的分布式系统中,达到峰值并不是那么简单。在这种情况下,我们可以利用Neil Gunther博士设计的称为通用可扩展性定律(USL)的数学模型,该模型考虑了计算机系统由于以下原因而不能线性伸缩这一事实排队效果。

在下面的部分中,我将演示如何使用这个模型来对比Wayfair使用的一个分布式系统来确定峰值容量,并跟踪容量对容量的影响,同时通过负载测试获得的少量数据点将负载加倍。

为什么系统不总是线性的

线性可伸缩性是理想的,但实际上线性可伸缩性的系统很少。理解其原因非常有用,因为正确理解可伸缩性以及次线性扩展的原因和来源是构建更可伸缩系统的关键2如果一个节点每秒观察到的事务是2000,而5个节点每秒产生10000个事务,那么系统就是完美的线性系统。这样的系统将是100%的效率。实际上,几乎总是存在一些效率损失,这意味着系统不是线性的。事实上,真实的系统不仅趋向于变成次线性,而且实际上在某一点上表现出倒退的可伸缩性:当你扩展时,你的系统执行效率更低(参见图1)。这种非线性归因于计算机网络中的排队或争用以及计算机系统之间的串扰。

图1:随着(硬件)节点的增加,线性和次线性行为

分布式系统中的排队

那么,排队到底是什么,它与容量规划有什么关系呢?我们在日常生活中体验排队——杂货店收银台、机场、交通灯、体育、音乐活动等;即使在这些看似微不足道的情况下,你也能看到排队理论在起作用。以杂货店收银台前排队的顾客为例。的队列不仅包括客户等待而且是目前的客户在服务。所以,如果有5个收银台,只有2个顾客在柜台,仍然有能力处理更多的顾客。但当共有5名顾客,每个柜台服务1名顾客时,则容量或利用率为100%。现在到达任何一个柜台的第6位顾客必须等待,直到当前顾客离开柜台。在周末,通常商店里会有更多的顾客,而顾客到达收银台的比率是可变的。柜台的服务时间也是可变的,因为它取决于所购买的商品数量和柜台代理扫描商品所需的时间。顾客在结账过程中花费的总时间(也称为停留时间)是排队等候的时间和柜台服务时间的总和。

排队理论可以归结为回答如下简单的问题3.:

  • 有多少事情会排着队等待呢?
  • 要等多久?
  • 服务于此线路的服务器/人员/系统有多忙?
  • 需要多少产能来满足预期的需求水平?

这些问题可以换一种说法:“由于等待时间过长或产能不足,我们失去业务的可能性有多大?”

将上述杂货店的类比转换为计算机系统,可以将客户视为系统服务的工作单位。例如:一个web请求,数据库查询。柜台上的收银员是处理工作单元的服务器。例如:web服务器或数据库服务器。队列是工作单元等待的地方,如果服务器忙,无法处理到达的工作。排队系统中的停留时间是响应时间或延迟时间。

排队会引起资源争用,从而降低可用容量——USL试图通过一个数学模型来捕获它的大小。更多关于为什么系统通常不能线性扩展以及为什么它们有时表现出逆行的可伸缩性的解释将在下一节由USL来解释。

普遍的可伸缩性法律

图2:争用和相干性对线性的影响

Neil Gunther博士通过通用可伸缩性法则(USL)定义可伸缩性4。他以三个C -的形式给出了观察到的非线性现象的三个原因并发性,争用,一致性。并发性是到达的客户/进程/工作单元的数量服务器并行,如图所示,斜率随可扩展性线性上升所示在图2中,图A.争用本质上是按照上面的理论进行的请求排队。在高可用性和遵循最终一致模型的分布式系统中,服务器之间存在恒定的串扰,以确保数据的一致性。

这三个C以基于三个参数有理函数的参数模型的形式得到。这个模型使统计拟合过程具有通用性,简化了整个过程。下面讨论的示例用例使用三个系数建模。

3参数USL模型

在任何给定的负载N上,USL定义的可伸缩性模型为

就绝对吞吐量而言,X(N) = N X(1),即总吞吐量X(N)与用户负载N成正比增加。单用户吞吐量X(1)不变化,作为比例常数,记为,即,静止。所以X(N) = N。新的参数是一个比例常数,它表示与理想平行缩放相关的直线的斜率5

分母中的第二项表示共享可写数据的序列化程度,并由不变的cpi参数化。分母中的第三个项表示维护共享可写数据的一致性所带来的损失,它由常量常量参数化。当elf = 0和elf = 0时,系统是线性可扩展的。

上式对硬件和软件可扩展性都成立,自变量N表示软件可扩展性和硬件可扩展性在固定硬件配置下的用户数量;如果p表示物理处理器的数量,N表示每个处理器执行的物理进程的数量,则N/p的比率保持不变。

USL模型适用于电子商务中使用的多层体系结构,因为吞吐量和响应时间等性能指标是在系统级作为聚合事务而不是单独的子事务来度量的6使用USL的关键假设对于多层架构来说,负载测试平台具有同质性,即当用户负载N变化时,测试执行同质的工作负载并维护固定硬件组件的同质配置。

例子

为了证明USL模型的有效性,我利用了SolrCloud在Wayfair上使用的平台,除了各种内部应用程序之外,还可以用于增强我们以客户为中心的产品关键字搜索。我从一个测试SolrCloud集群获得了用户负载和吞吐量的性能测试数据,评估了软件的可伸缩性(集群中的固定#硬件节点),并将它们插入到USL中。在应用USL模型之前进行负载测试;下面的图表显示了模拟数据和测量数据,它们之间的紧密性是显而易见的。请注意,这里提供的所有数据仅用于说明目的。

开放源码188金博宝备用软件包R具有“nls”(非线性最小二乘)内置求解器,可用于确定非线性模型参数的非线性(加权)最小二乘估计7R的Nmax是602,预计吞吐量是282。如果我们将用户负载翻倍,R模型将预测吞吐量,在这种情况下,它类似于逆行可伸缩性,即负载为1280个用户时的预计吞吐量将低于在320个用户时观察到的吞吐量。

图3:3参数USL模型

分析

从图3所示。从上面我们可以看到,R模型已经计算了一些值,显示在图例中。让我们来了解一下它们的意义。观察到的系数为incoherent-only系统。这样的系统在工作负载上没有明显的争用(线性可伸缩),但是集群中的节点表现出串扰/数据交换一致性,从而有助于逆向可伸缩性。这意味着,当我们通过添加更多节点来进行水平伸缩时,峰值吞吐量会更快地下降。描述这种行为的系统有OLAP、科学计算、数据挖掘、决策支持软件等。OLAP通常涉及跨大型数据集的复杂聚合查询,如查询所有客户的银行账户、通过关键字搜索(我们这里的案例研究)查询产品、推荐等。OLAP数据库通常是通过批处理查询填充的——所有数据都是同时插入的。插入OLAP数据库的数据通常来自OLTP(例如:SQL Server)应用程序。批处理查询用于扫描源系统并将数据导入OLAP数据库8因此,SolrCloud可以被认为是一个OLAP系统,因为它促进了业务智能允许用户在结果集上计算复杂的统计聚合。

重要的是要认识到,295的最大测量吞吐量是预计流量(请求/秒)的6倍,在这个有90多个节点的SolrCloud集群中再增加一个节点可能只会略微提高线性可伸缩性。这样做还会增加节点间串扰的影响,从而降低吞吐量。

对更高负载级别(8次)下吞吐量下降的进一步诊断发现,可以进行一些TCP/IP内核参数优化,这应该有助于平衡吞吐量。另外,通过批处理查询停止/减少使用OLTP数据填充SolrCloud索引的多个作业的频率,可以减轻额外负载对系统的影响。但是,考虑到系统能够使用一些缓冲能力处理预期的客户流量,这些更改被认为并不重要。整个测试工作为软件和基础设施团队在假期前提供了必要的信心。

尽管USL指出在较高负载下逆行的可伸缩性,但根据上述分析,这是SolrCloud集群的预期行为。然而,这对于其他系统可能不是真的,而且可能实际上表明应用程序设计存在缺陷,需要进一步调查。

结论

从上面的分析可以明显看出,我们不能总是通过添加更多的硬件来解决可伸缩性问题。虽然添加更多硬件的边际成本可能较低,但在我们的示例场景中,好处几乎完全消失了。

如果工程师没有实现一个更精确、科学的方式接近容量规划,他们将达到一个点,他们会把更多的钱的问题,但会看到收益递减由于相干点球(β> 0)。在USL不是福音,它给我们一个模型快速分析系统容量趋势。容量和可伸缩性问题应该通过硬件和软件优化的组合来解决,而不是单独地解决。通过负载测试或从生产系统获得的一些数据点,USL可以提供在较高负载级别需要什么最佳容量的估计。根据USL的建议,额外的负载测试可以在负载输入加倍的情况下执行,以验证模型。USL在Wayfair仍然处于混乱状态,因为团队刚刚开始实施它的容量计划和衡量它的有效性。请继续关注这个主题的进一步更新!

参考文献

  1. Gunther, n.j.(2007)。游击容量规划:为高度可伸缩的应用程序和服务进行规划的一种战术方法。纽约,纽约:施普林格
  2. 施瓦兹,b(2015)。应用通用可扩展性定律进行实际可扩展性分析。从检索https://cdn2.hubspot.net/hubfs/498921/eBooks/scalability_new.pdf?t=1449863329030
  3. 施瓦兹,b(2015)。你需要知道的关于排队理论的一切。从检索http://cdn2.hubspot.net/hubfs/498921/eBooks/queueing-theory_1-1.pdf
  4. 如何量化可伸缩性-性能动态。(无日期)。从检索http://www.perfdynamics.com/Manifesto/USLscalability.html
  5. USL可伸缩性建模的三个参数-性能的核心。(无日期)。从检索http://perfdynamics.blogspot.com/2018/05/usl-scalability-modeling-with-three.html
  6. Gunther, n.j.(2007)。游击容量规划:为高度可伸缩的应用程序和服务进行规划的一种战术方法。纽约,纽约:施普林格
  7. nls。(无日期)。从检索https://stat.ethz.ch/R-manual/R-devel/library/stats/html/nls.html
  8. OLAP是什么?| Database.Guide。(2017)。从检索https://database.guide/what-is-olap/