我有一个在 AWS Lambda 上运行的简单 FastAPI REST 服务器。它正在使用 AWS Kinesis Firehose 将日志写入 S3。我从异步单个 Firehose 写入开始,速度非常慢。然后我想出了一个解决方案,以 20 个为一组写入 Firehose,速度很快,但丢失了一些事件。
我尝试了很多策略来解决丢失事件的问题。该问题与 AWS microVM 生命周期和 FastAPI 中的异步编程之间的交互有关。
以下是我尝试过的一些策略和遇到的问题。包括2个与后台任务相关的问题:
我使用 Boto3 lib 将事件发送到 Firehose,这不是异步的。为了保持较低的延迟,我将事件放入事件队列中,并将 20 个事件批量写入 Firehose,每个批次都在 FastAPI 后台任务中运行。
也许BackgroundTasks 不是适合AWS Lambda 的工具?
我还尝试让异步周期性后台任务每分钟唤醒一次,并刷新未达到批量写入 20 的事件。但是,除非端点有持续流量,否则此后台任务将关闭。此关闭还将阻止某些已启动的后台写入任务完成。
为了防止阻塞我的主线程,我在普通函数中而不是异步中批量写入 Firehose。我可以看到批量写入正在与主线程分开的单独线程中运行。然而,在进行写入时,主线程中没有发生任何事情。
也许阻塞是由 FastAPI 的服务器 Uvicorn 引起的,默认情况下它只运行 1 个工作线程。我还尝试找到一个地方来更改 Terraform 或 AWS 控制台中的 Unicorn 工作人员数量,但我还没有找到有关如何执行此操作的文档。我什至将内存大小增加到 1.8 GB,为我的 microVM 获取 2 个核心。
我无法判断我的问题是否是一个小的配置错误,或者在静态 EC2 实例上运行 FastAPI 是否会更容易。在 EC2 上,后台任务应该按预期工作,但与 API Gateway 的集成可能更困难。
经过大量实验,我找到了一个简单的解决方案,速度与我的批量方法一样快:
@app.post("/event/")
def post_sync(events: list[Event]) -> None:
平均持续时间约为 20 毫秒。
@app.post("/event_async/")
async def post_async(tasks: BackgroundTasks, events: list[Event]) -> None:
平均持续时间约为 20 毫秒。
尽管尝试了许多巧妙的策略,我还是找不到清除杂散事件的方法。另外,一些 Firehose 写入后台任务在完成之前就关闭了。
FastAPI是一个ASGI(异步服务器网关接口)框架,所以我编写了一个异步处理程序。我选择了两种超级流行的技术:FastAPI 和 AWS Lambda,并假设易于集成。但在 Lambda 上,您应该小心使用后台线程,包括 FastAPI 的 BackgroundTasks。无服务器应该是暂时的,而不是持续的。我与 AWS 程序员讨论了问题,我的结论是 AWS 有一些特性,您只需要解决这些特性即可。