[新产品/新功能] 使用 Application Load Balancer 目标优化器提升应用性能

**发布时间:** 2025-11-20 **厂商:** AWS **类型:** BLOG **原始链接:** https://aws.amazon.com/blogs/networking-and-content-delivery/drive-application-performance-with-application-load-balancer-target-optimizer/ --- <!-- AI_TASK_START: AI标题翻译 --> [新产品/新功能] 使用 Application Load Balancer 目标优化器提升应用性能 <!-- AI_TASK_END: AI标题翻译 --> <!-- AI_TASK_START: AI竞争分析 --> # 产品功能分析 ## 新功能/新产品概述 ALB Target Optimizer是 **AWS Application Load Balancer (ALB)** 的一项新功能，旨在精确控制分发到每个后端目标的并发请求数量。其核心目标是解决传统负载均衡算法（如**轮询**）在处理低并发、计算密集型工作负载时可能导致目标过载、性能下降的问题。 该功能通过将负载均衡模式从“推”（push）转变为“拉”（pull）来实现。其工作原理如下： 1. 在每个目标实例上部署一个由AWS提供的 **ALB Agent**。这个代理作为 **Sidecar** 运行，充当ALB和后端应用之间的网关。 2. 用户为每个Agent配置一个最大并发请求数（**TARGET_CONTROL_MAX_CONCURRENCY**）。 3. Agent会监控当前正在处理的请求数量。当该数量低于设定的阈值时，Agent会通过一个独立的 **控制通道（control channel）** 向ALB节点发送信号，表明它已准备好接收新的请求。 4. ALB仅在收到来自某个目标的“就绪”信号后，才会将新的客户端请求转发给该目标。 此功能主要面向对并发请求数有严格限制的应用场景，特别是 **大型语言模型（LLM）** 推理、图像生成模型等运行在昂贵 **GPU** 硬件上的AI工作负载。这些应用通常一次只能高效处理极少数请求，Target Optimizer确保了资源利用率的最大化，同时避免了因过载导致的性能问题。 ## 关键客户价值 - **精确并发控制**：允许用户为每个目标实例强制设定一个最大并发请求数，最低可设为1。这对于那些处理能力有限（例如，一次只能处理1-5个请求）的专业应用至关重要，如AI推理服务。 - **降低错误率与延迟**：通过避免向目标发送超出其处理能力的请求，从根本上消除了因“热点”目标过载而产生的5xx错误。这减少了客户端重试的需要，从而降低了端到端延迟。 - **提升目标利用率**：采用“拉取”模式，目标在完成一个请求后会立即向ALB发出信号表示已就绪，可以接收下一个请求。这确保了计算资源（尤其是昂贵的GPU）始终保持在最佳工作负荷，既不空闲也不过载，实现了资源利用率最大化。 - **支持异构目标**：允许在同一个目标组中注册不同容量的实例（例如，不同规格的GPU实例）。可以为每个目标单独配置其最大并发数，使ALB能够按其真实处理能力分配流量，从而高效利用混合实例集群。 - **优化低并发负载均衡**：传统负载均衡算法（如**轮询**）在低并发场景下难以保证均匀和精确的请求分发。Target Optimizer解决了这一痛点，确保了即使在每个目标只能处理极少数并发请求的场景下，负载也能被平稳、高效地分配。 ## 关键技术洞察 - _核心机制是“推”模式到“拉”模式的转变_。传统负载均衡器（ALB节点）基于自身算法独立做出路由决策（推），而Target Optimizer则让目标实例参与决策。目标通过 **ALB Agent** 主动向ALB请求工作（拉），这是一种更智能、更具适应性的负载分配方式。 - _引入带外（Out-of-Band）控制平面_。该功能通过在目标上运行的 **ALB Agent** 与ALB节点之间建立独立的、长连接的 **控制通道（control channels）** 来实现。数据流量和控制信令分离，控制通道专门用于交换状态信息（如目标是否就绪）和指标，确保了控制逻辑的可靠性和低延迟。 - _代理与边车（Sidecar）模式实现_。**ALB Agent** 以代理形式部署在目标上，拦截ALB的流量并转发给实际应用。在容器化环境（如 **Amazon ECS** 和 **Amazon EKS**）中，它天然适合作为 **Sidecar 容器** 与应用容器一起部署，对主应用无侵入，易于集成和管理。 ## 其他信息 - **部署限制**：该功能无法在已有的目标组上启用，必须创建一个新的目标组。 - **支持的目标类型**：仅支持 **instance** 和 **IP** 类型的目标，不支持 **Lambda** 函数。 - **健康检查配置**：官方建议将目标组的健康检查端口设置为Agent接收流量的数据端口（`TARGET_CONTROL_DATA_ADDRESS`），这样可以将Agent的健康状态纳入ALB的健康检查范围。 - **算法与控制器支持**：启用此功能后，目标组的负载均衡算法固定为 **轮询（round robin）**。对于EKS用户，需要使用 v2.16 或更高版本的 **AWS Load Balancer Controller**，该版本提供了对Target Optimizer的新注解支持。 - **定价模型**：使用Target Optimizer的目标组，其流量在ALB上会有不同的计费方式。 <!-- AI_TASK_END: AI竞争分析 --> <!-- AI_TASK_START: AI全文翻译 --> # 使用 Application Load Balancer 目标优化器提升应用性能 **原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/drive-application-performance-with-application-load-balancer-target-optimizer/](https://aws.amazon.com/blogs/networking-and-content-delivery/drive-application-performance-with-application-load-balancer-target-optimizer/) **发布时间:** 2025-11-20 **厂商:** AWS **类型:** BLOG --- ### [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/) 是一款 HTTP 请求负载均衡器，旨在通过负载分发提供可扩展性，并通过目标健康状况检测和不健康目标隔离提供高可用性。今天，我们很高兴地推出 ALB 目标优化器 (Target Optimizer)，这是一个强大的新功能，通过它，ALB 可以为每个目标提供最佳的并发性。在本文中，我们将深入探讨目标优化器的工作原理，讨论其优势，并演示如何进行设置。 ALB 根据配置的负载均衡算法在目标之间分发传入的请求，默认为轮询 (round robin) 算法。传递给每个目标的并发请求数量会因传入的客户端负载、后端应用处理请求所需的时间、目标数量以及负载均衡算法的不同而有很大差异。许多应用程序难以处理过多的并发请求。一些专门的应用程序，例如大语言模型 (Large Language Models)，通常一次只能处理 1 或 2 个并发请求。传统的负载均衡算法 (如轮询) 无法确保精确地只有 1 或 2 个并发请求，这会影响这类专用应用程序的性能。 目标优化器允许您精确控制应用实例接收的并发请求数量，从而实现高效的负载均衡应用，同时保持低延迟和高可用性。在下一节中，我们将介绍它带来的主要优势。 ### 主要优势 **目标优化器提供以下优势：** - **限制并发请求：** 目标优化器允许您对目标上的并发请求数量强制执行给定的最大值。您可以使用此功能微调您的应用栈，以确保目标只接收它们能够处理的请求数量。 - **为低并发场景优化负载均衡：** 您可以将目标优化器用于那些以极低并发运行的大型应用和模型，其中每个应用实例一次只能处理少量 (例如 1-5 个) 请求。通过目标优化器，您可以强制每个目标最低只有一个并发请求。这对于需要严格控制并发请求的应用程序来说是完美的。 - **降低错误率和延迟：** 如果没有目标优化器，一些目标可能会收到过多的请求，从而产生热点 (hot spots)，而其他目标则可能未被充分利用。产生热点的目标收到的请求超出了其处理能力，导致客户端看到错误并重试请求，这会增加延迟。通过目标优化- 器，ALB 会均匀地分配负载。这消除了由热点引起的错误，从而无需客户端重试。 - **提升目标利用率：** 使用目标优化器，一个完成请求的目标会立即向 ALB 发送一个信号，表明它已准备好接收下一个请求。这使得目标能够在不过载的情况下保持繁忙。 - **使用异构目标：** 使用目标优化器，您可以将不同容量的目标注册到同一个目标组。您可以配置每个目标，使其接收与其容量成比例的请求。 ### 前提条件 在本文中，我们假设读者熟悉 ALB 的基础知识，例如创建 ALB、创建侦听器 (listeners)、添加规则以及关联目标组 (target groups)。这是理解目标优化器是什么以及它如何工作的必要条件。我们还假设读者熟悉运行容器。这将有助于理解我们接下来要演示的示例。 ### 目标优化器简介 目标优化器通过解决大型应用或模型带来的挑战来增强 ALB 的能力，这些应用或模型通常是计算密集型的，并且每个应用实例只能同时处理少量请求。诸如图像生成模型、大语言模型等推理工作负载可能运行在昂贵的 GPU 硬件上，这些硬件很容易受到负载分发中微小效率低下的影响。让我们看看 ALB 是如何工作的，以及这些低效问题是如何在常见的负载均衡算法 (如轮询、加权轮询和最少未完成请求 (LoR)) 中出现的。 高可用性和冗余是 ALB 设计中内置的特性。在底层，ALB 由分布在多个不同可用区 (AZs) 的多个独立节点组成。任何节点都可以响应传入的请求。每个 ALB 节点根据配置 ALB 时选择的负载均衡算法独立做出路由决策，而不考虑目标当前的容量。这可能导致低并发工作负载出现以下不理想的情况： - 一个目标最终可能收到的请求超过其处理能力。这可能导致 5XX 错误增加、延迟增加，并且如果缺少适当的错误处理，还会对目标的健康状况产生负面影响。 - 当请求处理时间不同时，目标利用率可能变得不均衡。例如，需要生成图像的请求可能比需要纯文本响应的请求花费更长的时间。在正常情况下，这可能导致性能不一致，从而造成某些目标利用率不足，而另一些目标错误率增加。 - 每个 ALB 节点都是独立的，并且对目标上的负载有自己的视图。由于可能有多个节点与单个目标交互，因此一个 ALB 节点无法知晓每个目标上的总负载。这可能导致错误增加，尤其是在每个目标一次只能处理少量请求的情况下。 目标优化器通过让目标参与负载分发来解决这些挑战。目标优化器采用一种 “拉取 (pull)” 模型，即目标请求 ALB 向其转发请求，而不是 ALB 仅根据算法输出将请求 “推送 (push)” 给目标的模型。您可以配置一个目标可以从 ALB 接收的最大并发请求数。如果一个目标的请求数少于您配置的最大值，它会通知 ALB，然后 ALB 使其有资格处理下一个传入的请求。ALB 仅在目标请求时才转发请求。由于目标仅在能够处理请求时才接收请求，因此请求被拒绝或需要客户端重试的可能性大大降低，而被成功处理的可能性更高。此外，由于目标在完成一个请求后会立即向 ALB 请求另一个请求，目标优化器确保了目标集群的高利用率。在下一节中，我们将了解目标优化器的工作原理。 ### 目标优化器 ALB 代理 目标优化器借助一个由 AWS 提供的、运行在目标上的代理 (agent) 来工作。您将该代理部署在应用程序目标的宿主机上，它充当您应用程序的守门人。通过该代理，您可以指定希望 ALB 发送给该应用实例的最大并发请求数。 该代理充当 ALB 和应用程序之间的代理。它与 ALB 节点建立长连接通信通道，用于发送指标和其他控制数据。代理会跟踪目标正在处理的请求数量。当请求数量低于配置的最大值时，代理会向其中一个 ALB 节点发送信号，请求另一个请求。 现在我们了解了目标优化器的工作原理，接下来我们将简要概述如何设置它，然后通过一个分步示例进行演示。  ###### 图 1: Target Optimizer 代理是 ALB 和目标应用之间的内联代理 ### 设置目标优化器 目标优化器可以通过以下三个简单步骤轻松设置。我们将在稍后的示例中更详细地介绍这些步骤。更多信息，请参阅 [ALB 用户指南](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-register-targets.html#register-targets-target-optimizer) 。 **第 1 步：在您的目标上安装和配置 ALB 代理：** 在第一步中，您将在应用程序所在的目标上安装代理。由于代理充当代理服务器，您需要通过提供它从 ALB 接收流量的端口以及它将流量代理到的端口来对其进行配置。您还需要配置希望 ALB 发送给该应用实例的最大并发请求数。如果您的应用程序运行在 Amazon Elastic Container Service 和 Amazon Elastic Kubernetes Service 上，您可以将代理作为边车 (sidecar) 与您的应用程序容器一起运行。 **第 2 步：创建一个启用了目标优化器的目标组：** 您创建一个新的目标组，并为其指定一个 “目标控制端口”。这是代理与 ALB 交换控制数据的端口。然后，您将第 1 步中创建的目标注册到此目标组。注册后，ALB 会与运行在目标上的代理建立控制通道。 **第 3 步：将流量切换到新的目标组：** 一旦您新的 “目标优化” 目标组准备就绪，您就可以修改 ALB 上的侦听器规则，将一部分流量切换到该目标组。 现在让我们在下面的部分中演示这些步骤。 ### 设置示例 ##### *这些步骤适用于基于 Linux 的机器。* **第 1 步：在您的目标上安装和配置目标优化器代理** 在这一步中，我们将启动并配置 EC2 实例，稍后将其添加到我们的 “目标优化” 目标组中。 **1.1 创建一个新的 EC2 实例并在其上安装 Docker：** ``` sudo yum install docker sudo service docker start ``` **1.2 拉取最新的代理容器：** ``` docker pull public.ecr.aws/aws-elb/target-optimizer/target-control-agent:latest ``` **1.3 使用以下变量运行代理容器：** 1. `TARGET_CONTROL_DATA_ADDRESS`: 代理将在此套接字 (IP:端口) 上从 ALB 接收应用流量。此套接字中的端口是您为目标组配置的端口。 2. `TARGET_CONTROL_CONTROL_ADDRESS`: ALB 在此套接字上与代理建立控制通道以进行管理流量。此套接字中的端口是您在第 2 步中为目标组配置的目标控制端口。 3. `TARGET_CONTROL_DESTINATION_ADDRESS`: 代理将流量代理到此套接字。您的目标应用程序应在此套接字上侦听。 4. `TARGET_CONTROL_MAX_CONCURRENCY`: 目标将从 ALB 接收的最大并发请求数。范围可以在 0-1000 之间。默认值为 1。 ``` docker run -d \ --name target-optimizer-agent \ --restart unless-stopped \ --network host \ -e TARGET_CONTROL_DATA_ADDRESS=0.0.0.0:80 \ -e TARGET_CONTROL_CONTROL_ADDRESS=0.0.0.0:3000 \ -e TARGET_CONTROL_DESTINATION_ADDRESS=127.0.0.1:8080 \ -e TARGET_CONTROL_MAX_CONCURRENCY=2 \ -p 3000:3000 \ -p 80:80 \ public.ecr.aws/aws-elb/target-optimizer/target-control-agent:latest ``` 在此示例中，运行在目标实例上的代理将从 ALB 的 80 端口接收应用流量，并将其代理到应用程序正在侦听的环回接口 (loopback interface) 的 8080 端口。它将在 3000 端口上接收来自 ALB 的管理流量。您还可以配置另外四个变量，我们将在后面的部分中介绍它们。 **第 2 步：创建一个新的目标组：** 2.1 在 AWS 管理控制台中，导航到 EC2 > 目标组。  ###### 图 2: 从 AWS 管理控制台创建目标组 2.2 为目标组提供名称和协议。对于端口，请指定您在第 1 步中为 `TARGET_CONTROL_DATA_ADDRESS` 提供的端口。  ###### 图 3: 在 AWS 管理控制台中为目标组指定名称、协议和端口 2.3 对于目标控制端口，请指定您在第 1 步中为 `TARGET_CONTROL_CONTROL_ADDRESS` 提供的端口。  ###### 图 4: 通过指定目标控制端口在目标组上启用目标优化器 2.4 将运行代理的实例注册为目标组中的目标。端口值应与您在第 1 步中为 `TARGET_CONTROL_DATA_ADDRESS` 提供的值相同。  ###### 图 5: 将目标注册到目标组 **(可选) 第 3 步：验证您的代理安装：** 这是对您刚刚创建的 “目标优化” 目标组的验证步骤。在我们将生产流量转移到该目标组之前，我们将验证代理是否已正确设置并能正确代理流量。为此，我们将在目标组中的目标上运行一个默认的 nginx 服务器。接下来，我们将在 ALB 上创建一个测试侦听器，将流量转发给代理，代理应将其转发给 Nginx 服务器。一旦我们验证了此设置，我们将用实际的应用程序替换 Nginx 容器。 3.1 在您的目标实例上，安装并在 8080 端口上运行 nginx。在 shell 中运行： **安装 Nginx** ``` sudo yum install nginx -y ``` **修改默认 Nginx 配置以侦听 8080** ``` sudo sed -i 's/listen\s*80;/listen 8080;/' /etc/nginx/nginx.conf ``` **启动 nginx** ``` sudo systemctl start nginx ``` **验证它是否在 8080 端口上侦听** ``` curl localhost:8080 ``` 3.2 在管理控制台中导航到 EC2 > 负载均衡器。选择您的 ALB。记下 ALB DNS 名称并点击添加侦听器。  ###### 图 6: 从 AWS 管理控制台向 ALB 添加侦听器 3.2 为您的测试侦听器选择一个端口 (例如 81)，并选择您在第 2 步中创建的 “目标优化” 目标组。  ###### 图 7: 从 AWS 管理控制台配置 ALB 侦听器 3.3 验证 nginx 是否正在响应。在客户端实例的 shell 中运行： `curl http://<ALB DNS name>:81` 它应该返回： `HTTP/1.1 200 OK` `Welcome to nginx!` 3.4 现在您已经验证了代理正在正确地将流量代理到 8080 端口，请停止 nginx 服务器，在 8080 端口上运行实际的应用程序，然后继续执行第 4 步。您还可以在 CloudWatch 中检查 `TargetControlActiveChannels` 指标。当该指标值增长到与您部署的代理数量相等时，表示您的代理正在响应 ALB。 ``` sudo systemctl stop nginx ``` **第 4 步：将流量转移到您新的 “目标优化” 目标组：** 4.1 在管理控制台中导航到 **EC2 > 负载均衡器**。选择您的 ALB 以及您想要添加 “目标优化” 目标组的侦听器。在 **管理侦听器** 下拉菜单中选择 **编辑侦听器**。  ###### 图 8: 从 AWS 管理控制台修改 ALB 侦听器 4.2 添加您在第 2 步中创建的 “目标优化” 目标组，并为其分配权重 1。在我们的示例中，现有的目标组权重也为 1；因此，50% 的流量将转移到新的 “目标优化” 目标组。  ###### 图 9: 通过修改 ALB 侦听器规则将流量转移到新的目标组 ### ALB 代理变量 除了第 1 步中提到的变量外，您还可以为 ALB 代理配置以下附加变量： 1. **TARGET_CONTROL_TLS_CERT_PATH:** 代理在 TLS 握手期间提供给 ALB 的 TLS 证书的位置。默认情况下，代理会在内存中生成一个自签名证书。 2. **TARGET_CONTROL_TLS_KEY_PATH:** 与代理在 TLS 握手期间提供给 ALB 的 TLS 证书相对应的私钥位置。默认情况下，代理会在内存中生成一个私钥。 3. **TARGET_CONTROL_TLS_SECURITY_POLICY:** 您为目标组配置的 ELB 安全策略。默认为 ELBSecurityPolicy-2016-08。 4. **TARGET_CONTROL_PROTOCOL_VERSION:** ALB 与代理通信的协议。默认为 HTTP1。 5. **RUST_LOG:** 代理进程的日志级别。默认为 info。 ### 指标和故障排除 您可以使用 CloudWatch 中的以下指标进行故障排除： 1. **TargetControlRequestCount:** ALB 转发给代理的请求数。 2. **TargetControlRequestRejectCount:** 由于没有目标准备好接收请求而被 ALB 拒绝的请求数。当 `TargetControlWorkQueueLength` 为零时，此指标会上升。 3. **TargetControlActiveChannelCount:** ALB 和代理之间的活动控制通道数。理想情况下，这应该等于代理的数量。较低的数字表示代理配置不正确或不可用。 4. **TargetControlNewChannelCount:** ALB 和代理之间创建的新通道数。当新目标成功添加到目标组时，您会看到此指标上升。 5. **TargetControlChannelErrorCount:** ALB 和代理之间建立失败或遇到意外错误的控制通道数。控制通道错误将导致该代理 (和目标) 无法接收任何应用流量。 6. **TargetControlWorkQueueLength:** ALB 从代理收到的请求信号数量。 7. **TargetControlProcessedBytes:** ALB 为流向启用目标优化器的目标组的流量所处理的字节数。 ### 注意事项 1. **新目标组 vs 现有目标组：** 目标优化器无法在现有目标组上启用。要使用目标优化器，您必须创建一个新的目标组。 2. **支持的目标类型：** 目标优化器支持 ‘instance’ 和 ‘IP’ 类型的目标。不支持 ‘Lambda’ 类型的目标。 3. **健康检查：** 对于目标优化器，我们建议您将目标组的健康检查端口设置为与 `TARGET_CONTROL_DATA_ADDRESS` 中的端口相同。这样，如果代理不健康，目标将无法通过健康检查。 4. **支持的属性：** 对于目标优化器，负载均衡算法类型为 ‘round robin’。 5. **AWS Load Balancer Controller:** 如果您正在使用 EKS，v2.16 版本的 AWS Load Balancer Controller 包含了针对目标优化器的新注解。 6. **ALB 代理：** 代理使用的资源微不足道，不应影响目标的健康或性能。 ### 结论 在本文中，我们介绍了 Application Load Balancer 的目标优化器功能。我们解释了它的工作原理，并演示了如何配置它。此功能允许您考虑目标的容量，并帮助您为需要严格并发控制的工作负载优化应用栈的性能和效率。 目标优化器已在所有商业 AWS 区域、AWS GovCloud (US) 区域和 AWS 中国区域提供。对于启用了目标优化器的目标组，ALB 上的流量计费方式有所不同。要了解有关该功能的更多信息，请参阅 [ALB 用户指南](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-register-targets.html#register-targets-target-optimizer) 和[定价页面](https://aws.amazon.com/elasticloadbalancing/pricing/?nc=sn&loc=3) 。 ## **关于作者** <!-- AI_TASK_END: AI全文翻译 -->