AWS 中的自動擴展服務，無需重復 cron 作業

Question

我有一個（golang web 服務器）服務在 EC2 上的 AWS 上運行（無自動縮放）。 該服務有一些全天運行的 cron 作業，這些作業在服務啟動時啟動。

我想在 AWS 上以某種形式利用 Auto Scaling。 一直在看 ECS 和 Beanstalk。

當我添加自動縮放時，由於外部 API 的速率限制，我需要 cron 作業僅在其中一項縮放服務上執行。 現在，cron 作業在服務中緊密耦合，我正在尋找一個不需要將 cron 作業移動到自己的服務的選項。

如何使用 AWS 以一種好的方式實現這一目標？

Answer 1

在 cron 不能/不應該多次運行的任何可擴展應用程序中，您都會遇到這個問題。 這並不是真正的 AWS 特定的。 我不確定您希望在多大程度上保持耦合或您的 crons 當前如何運行，但這里有一些可能對您有用的建議：

創建一個限制運行 crons 的“cron runner”實例

您可以創建一個單獨的 ECS 服務，該服務沒有自動縮放和 1 個實例的固定值。 此實例將運行與“正常”實例相同的代碼副本，並將運行 crons。 您將在“正常”實例上關閉 crons。 您可能會發現這可能是一個非常小的實例，因為它不處理任何 web 流量。

創建一個遠程觸發 crons 的“cron 觸發器”實例

在這里，您創建一個“觸發器”實例，該實例通過 ALB 向您的普通實例發送請求。 因為您的 ALB 會將請求路由到它后面的 1 個服務器，所以 cron 只會運行一次。 需要注意的是，如果您的 cron 長時間運行，您可能需要考慮您的請求超時。 您還必須考慮重試等，但我假設您已經有一個可以適應的過程。

---

上述解決方案可以適用於消息隊列等，但兩者的基礎是存在另一種啟動 cron 的實例，並且與您的普通服務器分開。 根據您的 cron 運行時間，您可能只需要每天運行這個 cron 實例幾個小時，因此執行此類操作可能具有成本效益。

就我個人而言，我在多租戶應用程序中使用了這兩種方法，我不得不 go 選擇像這樣運行 cron，因為租戶的數量和一次為所有租戶運行 cron 所需的時間/資源：

• Cloudwatch 計划觸發 lambda 向 SQS 發送消息，以分別為每個租戶排隊 cron。
• Cron 服務器（與主要的 web 服務器完全分開，但運行相同/相似的代碼）提取消息並為每個租戶單獨運行 cron。 在 redis 中為 cron 存儲一個密鑰，這對於僅運行一次以停止“至少一次”交付問題至關重要，因此 cron 不會運行兩次。

這也有助於處理 SQS 中管理的重試策略和死信隊列的故障。

最終，您需要從一個地方啟動這些 crons。 如果可能，請更改您的 crons，這樣它們是否運行兩次都沒關系。 它使處理重試和類似的事情變得更容易。