负载平衡系统令人惊讶的经济性

马克的博客 关于我 我的名字是马克·布鲁克。我喜欢构建有用的东西，做很酷的事情。我喜欢建造大东西。我还涉足机械加工、焊接、烹饪和滑雪。我是西雅图 Amazon Web Services (AWS) 的一名工程师，主要研究代理 AI，特别是代理 AI 的安全和策略。在此之前，我从事过 EC2、EBS、数据库、无服务器和无服务器数据库方面的工作。所有意见都是我自己的。链接 我的出版物和视频 @marcbrooker on Mastodon @MarcJBrooker on Twitter 这个博客是人工智能写的吗？负载平衡系统令人惊讶的经济性 M/M/c 模型的行为可能并不像您期望的那样。我有一个有c个服务器的系统，每个服务器只能处理一个并发请求，并且没有内部排队。服务器位于负载均衡器后面，其中包含无限队列。无限数量的客户端平均每秒向负载均衡器提供 c * 0.8 个请求。换句话说，我们随 c 线性增加提供的负载，以保持每台服务器的负载恒定。一旦请求到达服务器，平均需要一秒钟的时间来处理。客户端观察到的平均请求时间如何随 c 变化？选项A是平均延迟快速减少，随着c的增加而渐近接近1秒（换句话说，在队列中花费的时间接近零）。选项B不变。选项C是线性改进，D是延迟线性降低。您凭直觉认为延迟会遵循哪条曲线？我向我的 Twitter 粉丝提出了同样的问题，得到了一个有趣的混合结果：稍微分解一下问题将有助于找出正确的答案。首先，名字。用队列论的术语来说，这是一个M/M/c排队系统：泊松到达过程、指数分布的客户端服务时间和c个后端服务器。在电信工程中，它是 Erlang 的延迟系统（或者，因为术语很有趣，M/M/n）。我们可以使用排队论的经典结果来分析这个系统：Erlang 的 C 公式 E 2,n (A) ，它根据服务器数量（ n 又名 c ）和提供的流量 A 计算传入客户请求排队（而不是立即处理）的概率。详细信息请参见 Teletraffic Engineering Handbook 第 194 页。这是曲线的基本形状（使用我们相同的参数）：沿着蓝线到达饱和点的一半，在 2.5 rps 提供的负载下，看看概率如何约为 13%。现在看看紫色线处于其饱和点的一半，即 5 rps。只有3.6%。因此，在半负载情况下，5 服务器系统无需排队即可处理 87% 的流量，而在双倍负载和双倍服务器的情况下，我们无需排队即可处理 96.4% 的流量。这意味着只有 3.6% 的人看到任何额外的延迟。事实证明，这种改进确实正在渐近地接近 1。Twitter 民意调查的正确答案是 A。使用平均值来衡量延迟是有争议的（尽管也许不应该如此）。为了避免这种争议，我们需要知道百分位数是否以相同的速度变得更好。以封闭形式执行此操作有些复杂，但该系统非常简单，因此我们可以使用蒙特卡罗模拟将它们绘制出来。结果如下： 这完全是个好消息。中位数 (p50) 很好地遵循平均线，高百分位数（第 99 和 99.9）具有相似的形状。没有隐藏的问题。这对于云和服务经济来说也是个好消息。使用较大的 c，我们可以在相同的利用率下获得更好的延迟，或者在相同的延迟下获得更好的利用率，所有这些都在相同的每服务器吞吐量下进行。这不仅仅对大型服务来说是个好消息，因为大部分好处都发生在相对适中的 c 下。随着 c 的增加，与规模和分布式系统相关的问题很少会变得更容易。这是其中之一。还有一些合理的后续问题。结果对我们任意选择的 0.8 是否稳健？是的，他们是 1 。泊松到达和指数服务时间的 M/M/c 假设对于典型服务是否合理？我想说他们是合理的，尽管是错误的。指数服务时间尤其错误：现实服务往往更像对数正态分布。这可能并不重要。下次再详细介绍。更新：Dan Ports 通过一条引人入胜的 Twitter 帖子回复了我的帖子，指出了 SoCC’14 中的尾部延迟的故事：硬件、操作系统和应用程序级尾部延迟来源，该帖子在野外研究了这种效应。脚注 在某种程度上。一旦平均到达率超过系统完成请求的能力，队列就会无限增长，延迟将达到无穷大。在我们的例子中，当请求负载超过 c 时就会发生这种情况。更一般地，要使系统稳定，λ/cμ 必须小于 1，其中 λ 是平均到达率，μ 是服务器处理请求所需的平均时间。 « 返回博客索引 类似帖子 2021 年 8 月 5 日 » 延迟悄然降临 2021 年 4 月 19 日 » 尾部延迟可能比您想象的更重要