算术：使用Orchestrators扩展微服务应用程序

本文概述

• 计算容器编排参数
• 计算放大阈值
• 推导其他编排参数
• 用户加载功能如何？
• 介绍app-autoscaling-calculator
• 扩展微服务：在黑暗中不再困惑

微服务应用程序架构继续入侵软件设计也就不足为奇了。在简化开发和团队管理的同时, 分配负载, 创建高可用性部署和管理升级更加方便。

但是, 如果没有容器协调器, 故事肯定会不同。

要使用它们的所有主要功能, 尤其是自动缩放, 很容易。这真是一件幸运的事, 看着容器部署全天都在波动, 大小适中以应付当前的负载, 从而使我们有更多的时间用于其他任务。我们对容器监控工具的显示感到满意；同时, 我们仅配置了几个设置-是的, 这几乎就是创建魔术所需的全部！

这并不是说没有理由为此感到自豪：我们确信我们的用户拥有良好的体验, 并且我们不会因基础设施过大而浪费任何金钱。这已经相当可观了！

当然, 到达那里真是一段旅程！因为即使最后没有太多需要配置的设置, 它也比我们开始之前通常认为的要棘手得多。副本的最小/最大数量, 上/下限阈值, 同步周期, 冷却延迟-所有这些设置都紧密地联系在一起。修改一个很可能会影响另一个, 但是你仍然必须安排一个既适合你的应用程序/部署又适合你的基础结构的平衡组合。但是, 在Internet上找不到任何食谱或魔术公式, 因为这在很大程度上取决于你的需求。

我们大多数人首先将它们设置为”随机”或默认值, 然后根据监视时发现的内容进行调整。那让我开始思考：如果我们能够建立一个更”数学”的程序来帮助我们找到成功的组合, 该怎么办？

计算容器编排参数

当我们考虑为应用程序自动扩展微服务时, 我们实际上是在考虑改进两个主要方面：

1. 确保在负载快速增加的情况下可以快速扩展部署(因此用户不会遇到超时或HTTP 500)
2. 降低基础架构的成本(即, 防止实例负载不足)

这基本上意味着优化容器软件的阈值以进行放大和缩小。 (Kubernetes的算法针对这两个参数使用一个参数)。

稍后我将显示所有与实例相关的参数都与upscale-threshold相关。这是最难计算的—因此, 本文。

注意：关于在群集范围内设置的参数, 我没有很好的过程, 但是在本文结尾, 我将介绍一个软件(静态网页), 该软件在计算时会考虑它们实例的自动缩放参数。这样, 你将能够改变它们的价值以考虑其影响。

计算放大阈值

为了使这种方法有效, 你必须确保你的应用程序满足以下要求：

1. 负载必须均匀地分布在应用程序的每个实例中(以循环方式)
2. 请求时间必须短于容器集群的负载检查间隔。
3. 你必须考虑在大量用户(稍后定义)上运行该过程。

造成这些情况的主要原因来自以下事实：该算法不是按每个用户而是按分布来计算负载(稍后说明)。

获得所有高斯

首先, 我们必须为快速增加负载或换句话说, 在最坏的情况下制定定义。对我来说, 翻译它的一种好方法是：让大量用户在短时间内执行耗资源的操作-并且总是有这种可能性在另一组用户或服务执行其他任务时发生。因此, 让我们从这个定义开始, 尝试提取一些数学信息。 (准备好你的阿司匹林。)

介绍一些变量：

• $ N_ {u} $, “用户总数”
• $ L_ {u}(t)$, 单个用户执行”消耗资源的操作”所产生的负载($ t = 0 $指向用户开始操作的时刻)
• $ L_ {tot}(t)$, 总负载(由所有用户生成)
• $ T_ {tot} $, 即”短时间段”

在数学世界中, 谈论大量用户同时执行同一操作时, 用户随时间的分布遵循高斯(或正态)分布, 其公式为：

这里：

• µ是期望值
• σ是标准偏差

其图形如下($ µ = 0 $)：

可能让人想起你参加的某些课程-没什么新意的。但是, 我们在这里确实遇到了第一个问题：为了在数学上准确, 我们必须考虑一个从$-\ infty $到$ + \ infty $的时间范围, 显然这是无法计算的。

但是, 从图中可以看出, 区间$ [-3σ, 3σ] $之外的值非常接近于零, 并且变化不大, 这意味着它们的影响可以忽略不计, 可以放在一边。事实如此, 因为我们的目标是测试扩展应用程序, 因此我们正在寻找大量用户的变体。

另外, 由于区间$ [-3σ, 3σ] $包含我们的用户的99.7％, 因此它足以接近总数, 因此我们只需要将$ N_ {u} $乘以1.003就​​可以了。区别。选择此间隔将给我们$ µ =3σ$(因为我们将从$ t = 0 $开始工作)。

关于与$ T_ {tot} $的对应关系, 将其选择为等于$6σ$($ [-3σ, 3σ] $)并不是一个很好的近似值, 因为95.4％的用户在$ [- 2σ, 2σ] $, 持续时间为$4σ$。因此, 选择$ T_ {tot} $等于$6σ$将只为4.3％的用户增加一半的时间, 这并不是真正的代表。因此, 我们选择取$ T_ {tot} =4σ$, 我们可以得出：

和

那些价值观刚刚被淘汰吗？是。但这就是他们的目的, 并且不会影响数学过程。这些常数适合我们, 并定义了与我们的假设有关的概念。这仅意味着, 现在我们已经设置好它们, 我们最坏的情况可以转换为：

由$ N {u} $的99.7％产生的负载, 执行消耗操作$ L {u}(t)$, 其中95.4％的负载在持续时间$ T {tot} $内完成。

(使用网络应用程序时, 这一点值得记住。)

将先前的结果注入用户分布函数(高斯)中, 我们可以简化方程, 如下所示：

从现在开始, 在定义$σ$和$ µ $的基础上, 我们将在[0, \ frac {3} {2} T_ {tot}] $(持续时间$6σ$)中的时间间隔$ t \ in中工作。

用户总负载是多少？

自动扩展微服务的第二步是计算$ L_ {tot}(t)$。

由于$ G(t)$是分布, 因此要检索某个时间点的用户数, 我们必须计算其积分(或使用其累积分布函数)。但是由于并非所有用户都同时开始操作, 因此尝试引入$ L_ {u}(t)$并将等式简化为可用的式子真是一团糟。

因此, 为了使这一过程变得更容易, 我们将使用黎曼和, 这是一种数学方法, 可以使用有限形状的小数和(在这里使用矩形)来近似积分。形状(细分)越多, 结果越准确。使用细分的另一个好处来自以下事实：我们可以认为某个细分内的所有用户都已同时开始其操作。

回到黎曼和, 它具有与整数连接的以下属性：

$ x_k $定义如下：

这是正确的, 其中：

• $ n $是细分数。
• $ a $是下限, 此处为0。
• $ b $是上限, 这里是$ \ frac {3} {2} * T_ {tot} $。
• $ f $是函数(此处为$ G $), 用于近似其面积。

注意：细分中存在的用户数不是整数。这是产生两个先决条件的原因：拥有大量用户(因此小数部分影响不大), 并且需要在每个实例之间平均分配负载。

还要注意, 我们可以在黎曼和定义的右侧看到细分的矩形形状。

现在我们有了黎曼和公式, 可以说, 时间$ t $的负载值是每个细分用户的用户数乘以相应时间的用户负载函数的总和。可以这样写：

替换变量并简化公式后, 结果变为：

和瞧！我们创建了加载功能！

查找放大阈值

最后, 我们只需要运行一个二分法算法, 就可以改变阈值以找到最大值, 其中每个实例的负载在整个负载函数中都不会超过其最大限制。 (这是应用程序完成的操作。)

推导其他编排参数

找到扩展阈值($ S_ {up} $)后, 其他参数就很容易计算。

从$ S_ {up} $你将知道最大实例数。 (你还可以在负载函数中查找最大负载, 并按每个实例的最大负载除以四舍五入。)

实例的最小数量($ N_ {min} $)必须根据你的基础结构来定义。 (我建议每个AZ至少有一个副本。)但是它还需要考虑load函数：由于高斯函数的增长非常迅速, 因此负载分布在每个副本的开始处(每个副本)更加密集。可能希望增加副本的最小数量以减轻这种影响。 (这很可能会增加你的$ S_ {up} $。)

最后, 一旦定义了最小数量的副本, 就可以考虑以下因素来计算缩小阈值($ S_ {down} $)：由于缩小单个副本对其他实例的影响不大于从缩小时的影响。 $ N_ {min} + 1 $到$ N_ {min} $, 我们必须确保在缩小后不会立即触发放大阈值。如果允许的话, 将会产生溜溜球效果。换一种说法：

要么：

另外, 我们可以接受的是, 将群集配置为在缩减之前等待的时间越长, 将$ S_ {down} $设置为接近上限的安全性就越高。再一次, 你将必须找到适合自己的平衡。

请注意, 在将Mesosphere Marathon编排系统与其自动缩放器一起使用时, 可立即从缩小中删除的最大实例数与AS_AUTOSCALE_MULTIPLIER($ A_ {mult} $)绑定, 这意味着：

用户加载功能如何？

是的, 这只是一个问题, 而不是数学上最简单的问题-甚至根本不可能解决。

要解决此问题, 其想法是运行一个应用程序实例, 并反复增加执行同一任务的用户数量, 直到服务器负载达到分配的最大负载(但不超过此数量)。然后除以用户数, 然后计算请求的平均时间。对你想要集成到用户加载功能中的每个动作重复此过程, 添加一些时间, 就可以了。

我知道此过程意味着要考虑到每个用户请求在其处理过程中都有恒定的负载(这显然是不正确的), 但是由于每个用户不在同一处理步骤, 因此大量用户会产生这种影响。因此, 我认为这是可以接受的近似值, 但这再次暗示你正在与大量用户打交道。

你还可以尝试其他方法, 例如CPU火焰图。但是我认为创建一个准确的公式将用户的行为与资源消耗联系起来非常困难。

介绍app-autoscaling-calculator

现在, 对于通篇提到的小型Web应用程序：它以负载函数, 容器协调器配置以及其他一些常规参数作为输入, 并返回放大阈值和其他与实例相关的数字。

该项目托管在GitHub上, 但也有一个实时版本。

这是Web应用程序给出的结果, 针对测试数据(在Kubernetes上)运行：

扩展微服务：在黑暗中不再困惑

当涉及微服务应用程序体系结构时, 容器部署成为整个基础架构的中心。而且, 协调器和容器配置得越好, 运行时就越流畅。

我们在DevOps服务领域中的人们一直在寻找更好的方法来为我们的应用程序调整业务流程参数。让我们采用一种更数学的方法来自动扩展微服务！