是否有可能在連接到API網關的Lambda上使用AWS KPL

我正嘗試在AWS服務之上構建數據收集管道。下面給出整體架構;是否有可能在連接到API網關的Lambda上使用AWS KPL

總結系統應該從API網關（1）（每個事件的一個請求）獲取事件並將數據寫入Kinesis（2）。

我期待〜每秒100k事件。我的問題與Lambda函數的KPL使用有關。在第2步中，我計劃用KPL編寫一個Lambda方法在Kinesis上以高吞吐量寫入事件。但是我不確定這是可能的，因爲API網關分別爲每個事件調用lambda函數。

在這樣的架構中使用KPL有可能/合理嗎？或者我應該使用Kinesis Put API來代替？

 1        2        3        4 
+----------------+    +----------------+    +----------------+   +----------------+ 
|    |    |    |    |    |   |    | 
|    |    |    |    |    |   |    | 
| AWS API GW +-----------> | AWS Lambda +-----------> | AWS Kinesis +----------> | AWS Lambda | 
|    |    | Function with |    | Streams  |   |    | 
|    |    | KPL   |    |    |   |    | 
|    |    |    |    |    |   |    | 
+----------------+    +----------------+    +----------------+   +-----+-----+----+ 
                            |  | 
                            |  | 
                            |  | 
                            |  | 
                            |  | 
                       5     |  |    6 
                     +----------------+  |  |  +----------------+ 
                     |    |  |  |  |    | 
                     |    |  |  |  |    | 
                     | AWS S3  <-------+  +----> | AWS Redshift | 
                     |    |     |    | 
                     |    |     |    | 
                     |    |     |    | 
                     +----------------+     +----------------+

我也在考慮直接寫入S3而不是從api-gw調用lambda函數。如果第一種結構是不合理的，這可能是一個解決方案，但在這種情況下，我將有一個延遲，直到將數據寫入到KINESIS

 1        2       3        4        5 
+----------------+    +----------------+  +----------------+    +----------------+   +----------------+ 
|    |    |    |  |    |    |    |   |    | 
|    |    |    |  |    |    |    |   |    | 
| AWS API GW +-----------> | AWS Lambda +------> | AWS Lambda +-----------> | AWS Kinesis +----------> | AWS Lambda | 
|    |    | to write data |  | Function with |    | Streams  |   |    | 
|    |    | to S3   |  | KPL   |    |    |   |    | 
|    |    |    |  |    |    |    |   |    | 
+----------------+    +----------------+  +----------------+    +----------------+   +-----+-----+----+ 
                                   |  | 
                                   |  | 
                                   |  | 
                                   |  | 
                                   |  | 
                              6     |  |    7 
                            +----------------+  |  |  +----------------+ 
                            |    |  |  |  |    | 
                            |    |  |  |  |    |

來源

2017-07-03 ygk

我不認爲使用KPL這裏是正確的選擇。 KPL的關鍵概念是，記錄將在客戶端收集，然後作爲批處理操作發送給Kinesis。由於每次調用Lambdas都是無狀態的，因此存儲聚合記錄（在將它發送給Kinesis之前）將非常困難。

我想你應該看看下面的AWS文章，它解釋瞭如何將API-Gateway直接連接到Kinesis。這樣，您可以避免只是轉發您的請求的額外Lambda。

Create an API Gateway API as an Kinesis Proxy

來源

2017-07-03 09:24:47

您對第二架構有何看法。我不想面對休息終點的任何延遲（步驟1）。如果我使用kinesis端點直接使用api網關，則步驟2變爲不必要的同步寫入。 – ygk

第二個架構是我在Kinesis選項出現之前實現的。它可以工作，但是它嚴重限制了S3調用的數量。 S3會在某些時候降低你的速度，你的API將不得不拒絕新的傳入請求。因此，如果您不想將節流傳播到客戶端，那麼將數據放入聚合Kinesis是更好的選擇。每秒撥打10萬個電話，我不確定S3會接受這麼多電話。 –

是否有可能在連接到API網關的Lambda上使用AWS KPL

回答

相關問題