是否有可能在连接到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

回答

相关问题