azure - 为什么 Azure 应用服务未在实例之间均匀分配流量？

Question

我们的问题是 Azure 应用服务(S3 x 5 实例)未在 5 个实例之间均匀分配请求。结果是，一个实例被请求淹没，并且该应用服务的整体 P50 和 P95 响应时间 SLA 被违反。

我已确认应用服务已关闭 ARR 关联性。它是一个完全无状态的 Web API，因此它本身没有什么粘性。

技术细节如下，但问题本质上是这样的

Why isn't Azure evening distributing/round-robin-ing my traffic acrossall 5 instances?

就目前情况而言，扩展或缩小在这里似乎没有意义，因为我最终会得到额外的昂贵实例闲置，而 1 个实例被淹没。

技术细节

以下 2 个来自 6 月 1 日至 6 月 25 日的应用洞察图表显示了该问题。

requests
| where timestamp > datetime("2020-06-25 00:00:00")  
| where timestamp < datetime("2020-06-25 08:00:00")
//comaprison between 00:00-08:00 on June 1st vs. Today
| where url contains "**ommitted**" 
| project cloud_RoleInstance, itemCount, bin(timestamp, 1h)
| evaluate pivot(cloud_RoleInstance, sum(itemCount))
| render timechart

下面的第一张图片显示了 6 月 1 日的流量分布。分布不完全但接近。第三台服务器比第五台服务器承担的流量大约多 50%

34,708    26,436    38,313    30,617    24,355
22%       17%       25%       20%       16%

下面的下一张图片显示了今天早上同一时间段的流量分布......第 4 个实例处理的流量比下一个最接近的实例多 250%，比实例 1 多 600%

11,980  21,671  34,180  85,041  24,508
7%      12%     19%     48%     14%

Answer 1

不幸的是，您对扩展应用程序时使用的负载均衡器没有任何权力。据我所知，它是不可配置的，并且应该随机地将请求发送到实例。

尽管如此，从所附图表来看，您的分布在第一个图表中相当平衡。当然，你提出的第二天就有一个明显的问题，但我可以想象这可能只是暂时的。

随机性包括统计数据，从统计数据来看，在较小的时间窗口(有限的采样)内可能有更多的请求发送到您的实例之一。

我建议您获取更多有关负载平衡的示例，因为只有两天是不够的。我非常确定，您收集的数据越多，您就会看到曲线收敛得越多。

我可以理解 SLA 是一个问题，为此我建议升级到另一层，以便更快地满足您的请求。