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

Question

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

1. 为我们的静态 HTML/JS 提供 S3 集成的HTTP API 网关，以及ANY /api/{proxy+} 通往可通过Cloud Map访问的 Fargate 服务/任务的路由
2. 具有“API 服务”的ECS 集群使用Fargate和通过awsvpc. 没有自动缩放。最低健康：100%，最高：200%。
3. 使用SRVDNS 记录的服务发现 TTL 60
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

尽管我们无法真正查明问题所在，但我们得出的结论是，这是以下因素的结合：

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

用 Cloudfront 功能取代 API 网关并引入 AWS Application Load Balancer 改变了服务发现的方法：ELB 不再使用 Route 53 区域，而是自行管理可用的 ECS/Fargate 任务。除了其他一些小问题之外，这还为我们解决了这个问题。