Fargate ECS上Django+Gunicorn服务ELB健康检查提前失败，无法触发自动扩缩容求助

• Gunicorn并发能力不足导致请求堆积：当前配置2个worker+每个worker4线程，总共仅8个并发处理能力。高负载时所有线程被占满，新请求（包括ELB的健康检查请求）会被放入队列等待，一旦等待时间超过ELB健康检查的超时阈值，就会被判定为不健康，任务被注销。此时CPU没跑满是因为请求都卡在队列里，worker还没来得及处理，CPU使用率自然上不去，扩缩容策略也就无法触发。
• ELB健康检查配置不合理：如果健康检查的超时/间隔时间设置过短，或者健康检查路径本身需要消耗较多资源（比如查询数据库），高负载时健康检查请求会先于业务请求超时，直接导致实例被标记为不健康。
• Gunicorn配置与Fargate资源不匹配：2vCPU的Fargate实例，Gunicorn的worker数通常建议遵循2*CPU核心数+1的经验公式（即5个worker），当前仅配置2个worker，没有充分利用CPU资源，进一步限制了并发处理能力。

• 调整Gunicorn并发配置
  基于2vCPU的资源，建议将Gunicorn参数调整为：

  gunicorn <appname>.wsgi:application --workers 5 --threads 4 --timeout 30 --keep-alive 5
  

  其中：
  • --workers 5：遵循2*CPU核心数+1的公式，最大化利用CPU资源
  • --timeout 30：设置worker超时时间，避免长时间占用线程
  • --keep-alive 5：优化长连接，减少连接建立开销
• 优化ELB健康检查
  • 调整健康检查参数：将超时时间设为10-15秒，间隔时间设为20-30秒，不健康阈值设为3次，给服务足够的响应缓冲时间
  • 改用轻量级健康检查接口：在Django中新增一个无业务逻辑的/health接口，仅返回200 OK：

    # 在项目urls.py中添加
    from django.http import HttpResponse
    
    def health_check(request):
        return HttpResponse("OK", status=200)
    
    urlpatterns = [
        # 其他路由
        path('health/', health_check, name='health_check'),
    ]
    

• 排查请求堆积与资源瓶颈
  • 启用Gunicorn日志：添加--access-logfile - --error-logfile -将日志输出到控制台，通过CloudWatch查看请求队列长度（日志中的queue字段），确认是否存在请求堆积
  • 优化数据库连接：使用数据库连接池（如django-db-connection-pool），避免高负载时连接耗尽导致请求阻塞
  • 监控内存使用率：通过CloudWatch确认4GB内存是否充足，避免内存不足导致服务卡顿或OOM
• 调整扩缩容触发条件
  除了CPU和内存，新增基于ELB请求计数或目标组未处理请求数的扩缩容策略，比如当目标组每分钟请求数超过100时扩容，低于50时缩容，提前在请求堆积前触发扩容，避免健康检查失败。

内容的提问来源于stack exchange，提问作者Sai Chander