我有一个在 AWS Lambda（使用 node.js）上运行的东西，我称之为“微服务”。
基本上，它提供从几百兆字节的二进制 blob 中提取的精简摘要。有很多可能的输出，预先生成所有可能性不是一种选择，并且它需要具有合理的响应速度（最差情况下为亚秒级），因为它是通过允许快速更改参数的交互式网页访问的（通过 API 网关）。blob 中的访问模式本质上是随机的，尽管生成的任何摘要通常只访问了总数据的约 0.1-1%。数据和访问模式与将数据存储在数据库中不太兼容（尽管请参阅下面对 DynamoDB 的提及）。
我目前的方法是将大型二进制 blob 托管在 S3 上，并让 Lambda 处理程序在 Lambda 调用之间本地缓存 blob（就像 javascript 代码中的缓冲区一样，作用域在处理程序函数之外；显然 Lambda 的内存配置得足够大）。处理程序实例似乎足够持久，一旦服务器启动并运行，它就会运行良好并且响应迅速。但是至少有几个缺点：
从 S3 初始获取数据的速度似乎在 50-60MByte/s 左右（似乎与我看到的有关 S3 带宽的其他报告一致），因此第一次访问时可能会出现令人讨厌的数秒延迟。
与上一点相关，如果客户端非常活跃和/或用户负载增加，则会启动更多的服务器实例，并且用户可能会发现他们的请求被路由到在获取数据块时停滞的实例，这会导致原本运行顺畅的客户端出现令人讨厌的故障。
我坦白承认，我可能对真正意义上的“无状态”服务期望过高，因为它实际上包含大量状态（二进制 blob），但我想知道是否可以采取任何措施来改善这种情况。请注意，数据不是特别可压缩的（可能可以减少 1/3，但这不是我想要的数量级，或者至少它只是解决方案的一部分）。
关于如何更快地将数据输入 Lambda 有什么建议吗？ 我所想象的事情是：
将数据从 Lambdas 具有更高带宽的其他地方提取出来...但是什么呢？DynamoDB（根据需要拆分成 400k 二进制记录）？ElastiCache？AWS“菜单”上还有其他我没注意到的东西。
使用一些巧妙的技巧（什么？）来“预热” lambda 实例。
您使用的工具完全不合适；改用......？（我确实很喜欢 Lambda 模型；无需担心所有实例配置和自动扩展，只需专注于功能）。
如果谷歌或微软最近宣布的类似 Lambda 的产品（我对此知之甚少）具有任何可以更好地协助这种用例的属性，那么这也是非常有趣的信息。
我考虑过的一个选择是将二进制数据烘焙到“部署包”中，但 250MByte 的限制对于某些预期的用例来说太低了（即使 blob 被压缩）。
答案1
如果二进制文件只有几百兆字节，您可以将其作为“依赖项”包含在您的函数中。您可以将其作为文件添加到代码旁边并相应地引用它。
另一个选择是使用两个 lambda 函数。一个函数不做任何事情，只是提供 blob（您通过使用函数发送 blob 来创建 blob），然后您可以使用计时器（基本上是 cron）每分钟“触发”该函数以使其保持活动状态。然后您的第二个 lambda 就是执行工作的那个，它在启动时做的第一件事就是调用第一个 lambda 来获取 blob。Lambda 到 lambda 的调用带宽很高，因此启动时间不应该成为问题。
理想的解决方案是找出一种方法来汇总数据并将其存储在 DynamoDB 中，但听起来您尝试了这种方法并且对您来说没有意义。