如何在 AWS HTTP API 网关和 Fargate/ECS 上空闲/重新部署后修复间歇性 503 服务不可用？

Question

我们有一个非常简单的设置，这让我们很头疼：

1. HTTP API Gateway with a S3 Integration for our static HTML/JS and a ANY /api/{proxy+} route to a Fargate Service/Tasks accessible via Cloud Map
2. ECS 集群具有使用Fargate的“API 服务”和通过awsvpc公开端口 8080 的容器任务。 没有自动缩放。 最小健康：100%，最大：200%。
3. 使用TTL 60的SRV DNS 记录的服务发现
4. ECS 服务/任务完全无聊/空闲，并且在记录请求时总是乐于接受请求。

问题：

我们收到间歇性HTTP 503 Service Unavailable对于我们的某些请求。 新的部署（带有任务重新部署）会提高速度，但即使在 10-15 分钟后，它们仍然会间歇性地发生。

在 Cloud Watch 中，我们看到失败的 503 请求

2020-06-05T14:19:01.810+02:00 xx.117.163.xx - - [05/Jun/2020:12:19:01 +0000] "GET ANY /api/{proxy+} HTTP/1.1" 503 33 Np24bwmwsiasJDQ=

但似乎他们没有到达一个活的后端实例。

我们启用了 VPC 流日志，似乎HTTP API 网关希望将一些请求路由到停止的任务，即使它们已经很久了（远远超过 60 秒）。

更令人费解的是：如果我们让系统保持忙碌状态，速率会下降到几乎为零。 否则，在较长时间的闲置之后，间歇性错误似乎再次发生。

问题

1. 我们如何解决这个问题？
2. 是否有进一步查明根本问题的选项？

Answer 1

我正面临这个问题，并通过将我的 ALB 配置为internal而不是面向互联网（关于方案）来解决它。 希望它可以帮助有同样问题的人。

上下文：环境为 API 网关 + ALB(ECS)

更新我配置的第一个 ALB 是为了管理我的后端服务。 最近我还做了另一个 ALB（处理我的前端实例），在这种情况下，我暴露了一个公共 IP（而不仅仅是一个私有 IP）。 这可以通过将方案更改为面向互联网来实现，起初我认为这会带来与以前相同的问题，然后我认为这很简单。 我只需要添加一个策略以允许从 Internet 到我创建的 ALB 的流量。

Answer 2

尽管我们从未能够真正确定问题所在，但我们得出的结论是，这是

• 临时内部 AWS 问题导致 HTTP API 网关采用 Route 53 区域更新（用于服务发现）和
• 缺少弹性负载均衡器 (ELB)

用 Cloudfront 功能替换 API 网关并引入 AWS 应用程序负载均衡器切换了服务发现方法：ELB 代替 Route 53 区域，自行管理可用的 ECS/Fargate 任务。 除了其他一些小问题之外，这为我们挽救了这个问题。

Answer 3

对我有用的是，除了像xaalves那样将 ALB 的方案配置为内部方案外，还将 ALB 置于隔离或私有子网中。 以前我在公共子网中有我的 ALB。 本托洛尔的经历让我想到某种 DNS 分辨率正在失控，果然情况确实如此。 现在我的 HTTP 调用 100% 成功完成。