如何在 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% 成功完成。