控制Lambda + Kinesis成本

Question

我們有一個.NET客戶端應用程序，可以將文件上傳到S3。 在存儲桶上注冊了一個事件通知，觸發Lambda處理該文件。 如果我們需要進行維護，那么我們會暫停處理，方法是刪除事件通知，並在我們准備好恢復處理時將其添加回去。

為了處理在事件通知被禁用期間在S3中排隊的文件的積壓，我們使用S3鍵將記錄寫入kinesis流到每個文件，並且我們有一個事件映射，允許Lambda使用每個kinesis記錄。 這對我們很有用，因為它允許我們通過控制流中的分片數來處理大量積壓時控制我們的並發性。 我們最初使用SNS但是當我們有數千個需要重新處理的文件時，SNS將繼續啟動Lambdas，直到達到我們的並發執行閾值，這就是我們切換到Kinesis的原因。

我們現在面臨的問題是，盡管我們幾乎沒有使用它，但是kinesis的成本正在扼殺我們。 我們每分鍾上傳150到200個文件，而我們的lambda大約需要15秒來處理每個文件。 如果我們暫停處理幾個小時，我們最終會處理數千個文件。 我們可以使用128分片流輕松地重新處理它們，但這將花費我們1,400美元/月。 每個月運行Lambda的當前成本不到300美元。 為了能夠在恢復方案中控制我們的並發級別，我們必須將COGS增加400％似乎很糟糕。

我可以嘗試在默認情況下保持流大小較小，然后在重新處理大量積壓之前動態調整大小，但是將流從1個分片調整為128會花費相當長的時間。 如果我們試圖從意外中斷中恢復過來，那么在我們使用它之前，我們就無法忍受等待流調整大小。 所以我的問題是：

1. 任何人都可以推薦使用kinesis分片的替代模式，以便能夠控制排空隊列的並發lambd數量的上限嗎？

2. 是否有我遺漏的東西可以讓我們更經濟地使用Kinesis？

Answer 1

您可以將SQS與Lambda或Worker EC2一起使用。

以下是如何實現（2種方法）：

1.無服務器方法

• S3 - > SNS - > SQS - > Lambda Sceduler - > Lambda

• 使用SQS而不是Kinesis存儲S3路徑

• 使用Lambda Scheduler從SQS繼續輪詢消息（S3路徑）

• 從Lambda調度程序調用Lambda函數來處理文件

2. EC2方法

• S3 - > SNS - > SQS - > Beanstalk Worker

• 使用SQS而不是Kinesis存儲S3路徑

• 使用Beanstalk Worker環境自動輪詢SQS

• 在同一EC2中的HTTP服務器上本地托管的Beanstalk工作程序中實現應用程序（處理邏輯）