**发布时间:** 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全文翻译 -->