ECS 服务自动扩展与负载均衡

ECS 服务上固定的期望数量无法应对流量波动——您要么过度配置（浪费资金），要么配置不足（性能下降）。ECS Service Auto Scaling 会根据 CloudWatch 指标自动调整任务的期望数量。它在底层使用 Application Auto Scaling 服务——与 DynamoDB、Aurora 和 ElastiCache 使用的框架相同。ECS 服务自动扩展支持目标跟踪、分步扩展和计划扩展策略。

在添加扩展策略之前，请在 Application Auto Scaling 中将 ECS 服务注册为可扩展目标。请指定最小和最大任务数、集群名称，并将服务名称用作资源 ID。这会创建自动扩展运行的边界。最小数量可确保始终具备基本容量；最大数量则可防止扩展失控，耗尽 Fargate 容量或 EC2 实例资源。

对于大多数 ECS 服务而言，Target Tracking 是推荐的自动扩展策略。最常用的目标指标是 ECSServiceAverageCPUUtilization——将目标设置为 50% 至 70%，ECS 就会添加或移除任务，以维持该 CPU 水平。另一个强大的指标是 ALBRequestCountPerTarget：跟踪每个任务接收的 ALB 请求数，并进行扩展以维持每个实例的目标请求速率。AWS 会自动处理扩展和缩减，并设置适当的冷却时间。

将应用程序负载均衡器（ALB）附加到 ECS 服务后，HTTP/HTTPS 流量会分配到所有正在运行的任务。ALB 目标组会注册每个任务的 IP（适用于 Fargate/awsvpc）或容器端口（适用于 bridge 模式）。ECS 会在新任务启动时自动将其注册到目标组，并在任务停止时取消注册。ALB 会对每个任务执行运行状况检查；对于运行状况不佳的任务，系统会先将其排空（优雅地关闭连接），然后由服务终止任务。

一种强大的模式是使用 ALB 基于路径的路由，将不同的 URL 路径路由到不同的 ECS 服务。单个带有一个 HTTPS 侦听器的 ALB 可以将以下路径分别路由到相应服务：/api/orders/* 路由到 Orders ECS 服务，/api/users/* 路由到 Users ECS 服务，/api/products/* 路由到 Products ECS 服务——每个服务都由独立扩展的 ECS 服务提供支持。这样就不需要为每个微服务配置单独的负载均衡器，从而降低成本并简化 DNS 管理。

当 ECS 任务即将终止（在缩减或部署期间）时，ALB 会将其标记为排空中，并停止向其路由新请求，同时允许正在处理的请求完成。取消注册延迟（默认为 300 秒，可配置范围为 0 至 3600 秒）是 ALB 在强制关闭连接前等待的时间。对于请求持续时间较短的 ECS 服务，请将取消注册延迟设置得更低（30 至 60 秒），以加快部署和缩减操作。对于长连接（WebSocket、文件上传），请保持较高的延迟。

除了 CPU 和内存之外，还可以从应用程序发布自定义 CloudWatch 指标（队列深度、活跃会话数、业务 KPI），并使用这些指标驱动扩展。例如，如果每个 ECS 任务可以同时处理 50 条队列消息，则可以将 SQS 队列深度发布为自定义指标，并创建以每个任务 50 条消息为目标的目标跟踪策略。这样，扩展就直接由业务逻辑驱动，而不是依赖可能无法反映应用程序负载的基础设施指标。

与 EC2 Auto Scaling 类似，ECS 支持任务缩减保护。正在运行的任务可以通过 ECS API 设置自己的缩减保护标志，以便在处理关键作业期间防止自己被缩减终止。这对于充当 SQS 工作进程的 ECS 任务很有用——刚刚取出一个长时间运行作业的工作进程可以保护自己，完成作业后再移除保护。如果没有此机制，缩减可能会终止正在处理作业的任务，从而导致作业重复或数据丢失。

请谨慎选择扩展指标。CPU 利用率是默认指标，适用于受计算能力限制的工作负载。内存利用率（ECSServiceAverageMemoryUtilization）适用于受内存限制的应用程序，但增加内存需要添加任务——如果任务受限于每个任务的内存，而不是并发处理能力，那么修改任务定义中的内存分配可能更合适。ALBRequestCountPerTarget与用户体验直接相关，是 Web API 最具可操作性的指标——应根据每个任务的实际请求速率进行扩展。

ECS Deployment Circuit Breaker 会自动检测失败的部署，并回滚到上一个稳定版本。如果没有该机制，错误的部署（无法通过运行状况检查的容器）会导致 ECS 无限期地持续尝试启动新任务。启用熔断器后，如果在检测时间窗口内，新启动任务中有一定比例未通过运行状况检查，ECS 会将部署标记为 FAILED，并自动回滚到上一个任务定义修订版本。这可以防止错误部署造成长时间的服务性能下降。

一种适用于生产环境的容器化 Web API 架构如下：Route 53 将域名解析到 ALB 的 DNS 名称；ALB 终止 HTTPS（ACM 证书）、应用 WAF 规则，并将请求路由到ECS 服务目标组；位于 3 个 AZ 的私有子网中的 Fargate 任务处理请求；使用 ALBRequestCountPerTarget 进行目标跟踪的 ECS Service Auto Scaling 将任务数从 2 调整到 50；任务连接到位于私有子网中的 RDS Aurora 和 ElastiCache。所有日志都会发送到 CloudWatch Logs；指标则用于驱动 CloudWatch 控制面板和警报。

请测试您对本课 AWS Solutions Architect（SAA-C03）概念的理解。

本课介绍了：ECS Service Auto Scaling 使用 Application Auto Scaling，通过目标跟踪（CPU、ALB 请求或自定义指标）在配置的最小和最大边界之间调整任务数；ALB 基于路径的路由可将 URL 路径路由到不同的目标组，使一个负载均衡器能够为多个 ECS 微服务提供服务；Deployment Circuit Breaker 会自动回滚失败的部署，避免其造成长时间的服务性能下降。至此，ECS 和容器模块已完成；接下来我们将学习 AWS 上用于 Kubernetes 的 Amazon EKS。