限制 TCP 连接到 AWS Application Load Balancer 后面的目标

Question

我在 AWS ALB 后面有一个应用程序/目标，并且希望对其将接收的 TCP 连接数设置硬性上限。

如果我理解正确的话，ALB 目标可以是

• 健康 - ALB 会将流量路由到目标。

或者

• 不健康 - ALB 不会将流量路由到目标。此外，将尽快耗尽/取消注册/重新启动目标（我在文档中找不到这一点，但这是我观察到的行为）。

理想情况下，当达到连接上限时，我会将目标置于第三种状态，即“不要杀死我，但也不要将流量路由到我”（随后我将生成更多目标来满足需求）。

没有这样的第三种状态，但是有其他方法可以对连接数设置上限吗？

Answer 1

这个问题本身存在一个主要的误解，所以我首先解决这个问题

\n

\n

ALB 目标可能 [...] 不健康 - ALB 不会将流量路由到目标。此外，将尽快耗尽/取消注册/重新启动目标（我在文档中找不到这一点，但这是我观察到的行为）。

\n

\n

实际情况并非如此。

\n

ALB是一个负载均衡器：它会根据您可以在一定程度上配置的某些路由逻辑将请求路由到目标。

\n

它还将执行健康检查，从 ALB 的角度来看，健康检查将用于确定目标是否健康。

\n

这是一个误解：当目标被认为不健康时，ALB唯一会做的就是停止向其发送新请求。就这样。

\n

ALB 本身无法 (1) 取消注册或 (2) 重新启动目标。事实上，它本身会继续执行健康检查，每当目标再次健康时，它就会再次开始发送流量。

\n

您所描述的您观察到的行为也可能并不完全是所发生的情况。你说目标被注销并重新启动。除非您有一些令人难以置信的自定义内容（极不可能），否则目标不会重新启动，但会被替换。这是一个巨大的差异。

\n

让我们假设这是实际发生的行为。

\n

发生这种情况的原因几乎可以肯定是有一个与 ALB 集成的AutoScaling 组（这是 AWS 上最常见的设计之一）。AutoScaling Group 可以将运行状况检查与 ALB 集成（即目标运行状况的 ALB 报告由 ASG 使用）。当ASG确定某个实例不健康（例如，通过与 ALB 集成）时，ASG 会继续替换它，以便它维持多个实例处于健康状态（等于DesiredCapacity）。

\n\n

现在，回到问题 \xe2\x80\x94 简而言之，在 ALB 级别，您无法对目标将收到的连接数设置硬性上限。

\n

实际上，您需要 (1) 从一开始就防止饱和情况发生，(2) 决定发生这种情况时该怎么办。

\n

为了防止这种情况发生，您需要确保始终有足够的实例来处理当前的流量，以及从您检测到流量增加到新实例启动并投入使用之间的预计流量增加。例如，您可以使用基于每个目标上的平均连接数的警报，并触发自动缩放（在采用该路线之前，确保“连接数”确实是最佳缩放指标非常重要） 。检查将新实例投入使用的速度，并检查需要维护多少超额配置，以便在检测到负载增加到新实例准备就绪之间有足够的时间。

\n

发生时该怎么办？您在这里主要有两个一般选择：

\n

\n

• 您的目标可以在可能“降级”的情况下接受并处理请求（即，您处理的请求比您的规范多，因此它们都可能会变慢，或者可能由于下游问题等而失败）；

  \n
\n

• 或者您可以快速拒绝该请求（但请仔细检查它不是 ALB 请求！您应该继续接受并处理这些请求）并向调用者返回错误消息（也称为负载卸载）。

  \n
\n

\n

无论哪种情况，您都应该决定是要“等待”，还是启动一个过程来添加新实例来处理额外的负载。这一决定通常归结为确定流量增加是持续增加还是只是暂时的、短暂的峰值的可能性有多大。

\n

您不应该做的一件事就是为此目的搞乱健康检查。如果您拒绝来自 ALB 的运行状况检查请求，它将将该实例归类为不运行状况，并且如果您有 ASG（您应该这样做），ASG 将终止该实例（导致剩余实例上的负载更大，而该实例处于运行状态）更换）。此外，对于 ALB 来说，“我很健康，但已经饱和”的情况与“我确实有问题，需要被替换”是无法区分的。

\n

最后一点：请记住，ALB 并不是真正处理“连接”，而是处理“请求”（即，它是更高级别的抽象）。这意味着“连接数”现在可能是一个很好的扩展衡量标准，因为 ALB 可以并且很可能将来自大量客户端的请求多路复用为到目标的较少数量的连接。也就是说，如果 ALB 接收来自 10 个不同客户端的 TCP 连接，它可能仅打开 5 个（或任何其他数量）到目标的连接，并仅通过这 5 个连接发送来自所有 10 个客户端的请求。

\n