使用基尼系数规划边缘容量

# 使用基尼系数规划边缘容量 来源：https://www.fastly.com/blog/using-gini-coefficient-plan-edge-capacity 支撑 Fastly 容量模型的核心统计量，通常出现在经济学论文中。基尼系数是用于描述人口中不平等程度的宏观经济指标。而 Fastly 的容量问题似乎要具体得多。我们需要知道某个 POP 能否应对大型游戏发布，某个大洲在为直播体育赛事保留多少余量，随着 AI 和安全工作负载持续快速增长会发生什么，以及我们应该在数月或数年后将基础设施投资投向何处。 但事实证明，基尼系数正是我们容量规划的关键。 重大事件会改变我们服务的流量形态。在 Fastly，平常的一天涉及客户工作负载的巨大多样性、服务变更以及对象热度的变化。而在大型游戏发布、软件更新、直播活动或从其他提供商迁移的过程中，少数工作负载可能会突然占据大部分流量。 这一观察结果成为了 Fastly 今天使用的容量模型的核心： `` 流量不平等 -> 缓存行为 -> CPU 利用率 -> 余量 `` 令人惊讶的是，这一个信号能解释如此多的问题。我最初尝试了一长串机器学习和预测方法：AutoML 系统、神经网络、树模型、集成方法、回归、专门的时序预测模型，甚至包括大语言模型。许多方法在普通流量上表现良好，但在容量规划最关键的那些罕见情况下却力不从心。 最终胜出的模型小巧、可解释、且速度足够快，能用于交互式场景分析。它已在生产环境中使用超过一年。 关键在于将流量不平等视为一等信号。 ## 边缘的容量是工作负载问题 Fastly 的 POP 没有一个简单的叫做“容量”的数字。Fastly POP 由裸金属服务器组成，运行着混合工作负载，基于 Fastly 复杂且高性能的软件栈。流量组合因地区、客户、时间和事件而异。POP 同时承载着直播视频、API 流量、安全负载、软件下载、混合 Web 流量以及基于 wasm 的计算工作负载。每一个额外的请求、Gbps 流量或计算任务，其影响可能因具体内容而截然不同。POP 是随时间逐步建设的，因此硬件组合也反映了基础设施部署的时间和地点。 这使得规划成为一个实际的系统问题，而不是一个干净或抽象的资源配置问题。一个今天有充足余量的 POP，可能在另一天就变得捉襟见肘，即使工作负载表面上看起来相似。 我们需要能够规划常见情况，同时处理不常见情况。这意味着我们要问如下问题： - 这个 POP 下周能承载某个已知事件吗？ - 这个区域还能吸收多少额外的批量下载流量？ - 假如计算和安全负载的增长速度是交付流量的两倍？ - 哪个进程组会首先成为 CPU 瓶颈？ - 在正常季节性流量之上还有多少余量？ - 我们应该在哪里建设更多容量？ - 当客户流量因故障转移从其他提供商迁移到 Fastly 时会发生什么？ 流量可能因多种原因转移到 Fastly：客户路由决策、计划内事件、流量迁移、维护或互联网其他地方的故障。容量模型需要将这些转移视为常规规划场景。 一个有用的模型必须支持反事实推断。我们通常并不试图预测接下来会发生什么，因为我们预料到会有意外发生。我们更关心在各种假设场景下会发生什么。 ## 现成的 AI 和 ML 是不够的 最初这看起来像是一个常规的 AI/ML 问题。我们有如此多的遥测数据，对于 AI/ML 来说就像老鼠掉进了米缸：数千个关于流量、请求速率、计算任务、互联网状况、缓存行为、CPU 利用率等的指标。很自然地，我们会尝试流行的开源包和各种供应商专有产品中提供的标准 AI/ML 技术工具箱。 许多这类标准技术在平均情况下的误差表现不错。它们很好地学习了正常流量，因此在平常的日子里预测可能看起来相当好。然而，容量规划恰恰是由不寻常的日子定义的。 通用模型通常学习到宽泛的关系，例如： `` 更多的字节 -> 更多的 CPU 更多的请求 -> 更多的 CPU 更多的 wasm 计算 -> 更多的 CPU `` 这正是它们应该从数据中学到的东西。问题在于这些关系的强度取决于工作负载的具体细节，而这些细节，无论模型多么复杂，都没有被任何通用模型捕捉到。 ## 边缘版本的“不平等” 基尼系数衡量一组值（如收入）之间的不平等程度。但在我们的边缘基础设施中，关键的不平等在于客户工作负载之间：即在特定时间占主导地位的流量形态。 关键的观察是，我们的算法隐式地针对一种流量类型占主导的情况进行了调优。缓存，从处理器到 POP 的每一层，都受益于热门度。缓存使得提供热数据比从别处获取并返回冷数据更省计算资源。事实证明，热门度只是不平等的一种形式，而基尼系数是衡量这种不平等的正确指标。它为我们提供了一个数字来表示这种热门度信号，而无需模型知道游戏的名字、事件、客户或发布时间表。 这一点最明显的体现是缓存命中率。一个分散的工作负载可能有数千个客户各自贡献一小部分流量。而一个重大发布或直播活动可能只有少数几个客户贡献了 POP 的大部分流量。这两种情况可能具有相同的总流量，但缓存行为却截然不同：我发现以基尼系数形式呈现的流量不平等，在重新缩放后，能够追踪到我们经常为此进行规划的最极端情况下的边缘缓存行为。同时，这些事件恰好也是通用 AI/ML 技术表现最差的，因为它们属于极端、不可预测的离群值。 **在 EWR POP 上，大型游戏发布前后及期间，基尼系数的重新缩放平方根与前端的缓存命中率的对比。** 这一观察结果引出了一个与 POP CPU 利用率分开的缓存模型： `` gini = 基于前几位客户流量份额的基尼系数 top_N_ratio = 来自 N 个最大客户的流量比例 predicted_cache_hit_ratio = a * sqrt(gini) + b * top_N_ratio + c `` 其中的系数来自对近期历史数据的稳健回归。除了基尼系数外，加入前 N 个客户，捕捉了类似的直觉，对于流量多样性明显较低的 POP 尤为重要。预测结果会被截断在合理范围内。我们还利用遥测数据识别出结构上不易缓存的客户，这样不可缓存工作负载的集中就不会被误判为有用的缓存局部性。 平方根是一个微小但重要的重新缩放。缓存行为似乎并不随着流量不平等而线性改善。集中度的最初迹象至关重要：它意味着流量变得足够热门，缓存可以利用。一旦流量已经高度集中，额外的不平等带来的收益递减。取平方根拉伸了基尼系数的低中范围，压缩了高端部分，使两者对齐。 ## 将不平等纳入 CPU 利用率 让我们回到 CPU 利用率。我最初使用各种标准 AI/ML 技术构建的模型，目的是从流量预测 CPU 利用率： `` 流量组合 -> 预测的 CPU -> POP 容量/余量 `` 一旦知道预测的 CPU，你就可以用不同的流量组合运行场景，看看会达到什么 CPU 水平。模拟越来越高的话务量将达到 CPU 上限，这告诉你 POP 的容量和余量。 既然缓存行为是准确建模 POP 容量的关键，复杂的 AI/ML 技术就变得不再必要。生产模型现在异常简单。 首先，它使用上述方法从流量集中度预测前端缓存命中率。前端缓存命中率对 CPU 效率至关重要，因为它告诉我们是否可以在不询问集群主节点的情况下提供对象，而集群和 POP 范围内的缓存命中率（高得多）则更多地告诉我们关于源站卸载的信息。 其次，它从流量、请求率、计算任务量以及缓存预测中预测 CPU，如下所示： `` 流量组合 -> 预测的缓存比率 -> 预测的 CPU -> POP 容量/余量 | | -------------------------- `` 我们针对每个 POP 进行训练。模型分别针对我们服务器上相关的 CPU 组进行训练。该模型的特征故意设计得狭窄且操作性强： `` 比特每秒 请求每秒 计算任务量 `` CPU 利用率模型使用这些特征在 1 分钟粒度上进行稳健回归。我们在拟合前过滤掉低 CPU 的行，因为非常安静的时段对容量规划信息量较少。在拟合缓存乘数时，我们还对高 CPU 样本进行加权，因为上界范围是规划决策发生的地方。 在训练期间，我们使用真实的前端缓存命中率数据；在推理期间，我们首先运行基于基尼系数的缓存命中率模型，并将其输出前馈。对于假设事件，我们不知道缓存命中率。模型必须预测流量组合将产生的缓存行为，然后预测随之而来的 CPU 利用率。缓存乘数捕捉了更好的缓存行为如何降低 CPU 成本，其截止值和幂常数通过简单的网格搜索确定： `` downshifted = max(cache_hit_ratio - cutoff, 0) multiplier = 1 - downshifted ^ power predicted_cpu_utilization = base_cpu_utilization * multiplier `` 这个模型推理近乎瞬时。规划人员和工程师可以快速调整 POP、基线、客户、工作负载类型和增长场景。输出也包含有用的中间值：流量集中度、预测缓存比率、缓存乘数、基础 CPU 预测、最终 CPU 预测以及限制性 CPU 组。模型的简单性有助于其可解释性。 尽管 Fastly 在实际中遇到的流量形态范围很广，我们发现这个简单模型与真实 CPU 利用率的误差保持在 5% 以内，而更复杂的模型常常偏差 25% 或更多。 ## 余量取决于场景 一个 POP 对于均匀增长、计算密集型增长、批量下载或直播活动，可能拥有不同的余量。模型必须使这些假设可见。 余量循环从一个代表性基线开始。然后它根据场景缩放流量，并运行预测链，直到达到 CPU 阈值。 `` 选择一个场景和基线时间戳 使用二分查找找到刚好低于 CPU 组最大阈值的流量水平： 预测缩放后流量组合的缓存行为 根据流量、计算量以及预测的缓存行为预测 CPU `` 输出包括限制性 CPU 组、极限处的预测 CPU、额外的 Gbps 或 RPS、相关的计算任务余量以及每服务器容量。最终的规划答案还会考虑网络约束，如 NIC、对等和传输容量。 这种框架对事件规划很有用，因为它让我们可以用多种方式提出相同的问题。规划者可以比较接近峰值的基线与非峰值基线、均匀增长假设与特定客户的批量事件、或交付密集型客户增长与计算密集型客户增长。 ## 寻找正常基线 我们需要一个代表 POP 正常流量的基线。基线应避免未知事件、故障或意外的流量行为。否则，余量计算将从一个无法解释的基线开始。 与 CPU 模型类似，我本以为复杂的时序预测模型会有所帮助，但再次失望了。对于这个用例，最佳方法是来自 statsforecast 的季节性朴素预测 (`Seasonal naive forecasting`)[https://nixtlaverse.nixtla.io/statsforecast/src/core/models.html#seasonalnaive]。 季节性朴素预测很简单：近期的季节性行为预测正常的未来行为。互联网流量具有强烈的日和周节律，因此这种简单方法为我们提供了一种可靠的方法来识别普通日子。更灵活的系统，包括 Prophet 风格的模型，在选择正常基线方面通常不那么有用。它们引入了复杂性，却没有改善规划决策。 这强化了从 CPU 模型中得到的更广泛的教训：最好的模型是那些与操作性问题匹配的模型。 ## 从预测到放置 一旦我们将流量集中度视为缓存效率信号，我们就可以不同地推理放置。在分布式系统中，均匀分布流量是一种自然本能。但对于某些边缘工作负载，有意的集中可以提高效率和性能，因为它增加了缓存局部性。 但这并不意味着每个工作负载都应该集中。集中是有局限性和风险的。它可能造成热点、降低故障隔离性，或使 POP 面临其他约束。这个模型为我们提供了一种量化评估这些权衡的方法。 对于兼容的工作负载，我们利用不平等洞察有意识地集中流量并提高效率，尤其是在较旧的硬件上。相同的硬件在服务分散的长尾流量与服务热门的缓存友好流量时，表现可能截然不同。一个理解流量集中度的模型让我们无需猜测就能发现这些机会。 这是这个模型更有趣的成果之一。它最初是作为预测 POP 余量的一种方式，却导致我们改变了某些流量形态以最大化效率。 ## 简洁性与生产用途 这个模型已在 Fastly 生产环境中使用超过一年。我们用它来理解重大游戏发布时的容量、在世界各地建设 POP 等。 最终的模型很简单，因为问题结构是明确的。更复杂的模型有时可以从足够的数据中推断出隐藏的关系。但我们最重要的案例是间歇性的、异构的且操作敏感的。寄希望于一个通用模型从间歇性事件中推断出正确的结构是没有意义的。 缓存模型是基于基尼系数和最大客户集中度的稳健回归。CPU 模型是带有缓存乘数和高 CPU 加权的稳健回归。余量分析是对缩放后流量场景的搜索。 我从中得到的教训是，当特征捕捉到底层系统行为时，特征工程仍然重要。基尼系数之所以有效，是因为它描述了关于边缘流量的真实情况。它将“热门的东西缓存效果好”这一模糊的操作直觉转化为模型可用的可测量输入。 这就是为什么一个宏观经济指标最终进入了 Fastly 的容量模型，以及为什么模型变得更简单时反而变得更强大。