Recall.ai 最近分享了他们在 AWS 上运行一个用于构建和管理会议机器人的平台的经验,他们发现 使用 WebSockets 每年会增加 100 万美元的额外成本。该团队介绍了他们是如何通过开发一个高带宽、低延迟的进程间通信(inter-process communication,IPC)替代方案来解决这一问题的。
Recall.ai 为 Zoom、Google Meet 和 Microsoft Teams 等平台上的会议机器人提供 API,它依赖于 AWS 部署环境中的实时视频处理。Recall.ai 的工程团队负责人 Elliot Levin 这样写到:
当谈到优化云成本的时候,IPC 很少会得到人们的关注。但事实证明,如果在 AWS 上每秒以 IPC 的方式传输 1TB 的视频且处理效率不高的话,那么将会产生巨额的费用。
在对机器人样本进行分析时,研究小组最初预计大部分的 CPU 使用来自视频编码和解码。但是,他们发现最大的贡献者居然是接收数据的 Python WebSocket 客户端,其次是发送数据的 Chromium WebSocket 实现。Levin 解释说:
WebSocket 似乎很适合我们的需求。它像 Web API 一样“快”,可以很方便地在 JS 运行时中进行访问,支持二进制数据,最重要的是,它已经内置在了 Chromium 中。
为了寻找更具成本效益的传输层,Recall.ai 团队考虑了三种解决方案,即原始的 TCP/IP、Unix Domain Socket 和共享内存。尽管没有通过共享内存传输数据的标准接口,但是 TCP/IP 和 Unix Domain Socket 至少都需要在用户空间和内核空间之间复制数据,团队最终决定设计一种自定义的传输方式,以降低 AWS 的成本,并选择环形缓冲(ring buffer)作为高层级的传输结构。
图片来源:Recall.ai 博客
在 Hacker News 上,有些开发人员对技术栈和视频解码器的选择提出了质疑,用户 IX-103 这样写到:
Chromium 已经内置了使用共享内存的零拷贝 IPC 机制,叫做 Mojo。这就是各种浏览器进程之间实现相互对话的方式。它们只需要将 mojo::BigBuffer 消息传递给 custom.process 即可,无需担心平台特定代码的问题。不过我觉得,编写一个自定义的环形缓冲实现也不错。
虽然在 AWS 上 使用 WebSockets 构建实时应用程序 是一种常见的方法,但 Momento 的生态系统工程师 Allen Helton 最近提出了 警告:
你需要的并不是 WebSockets,而是 PubSub。我最近一直在试用 AppSync Events,我了解到,即使抽象到超高层,使用 WebSocket 仍然很困难。我从事实时通信工作多年,唯一能让它变得简单的方法就是将协议完全抽象掉。
Duckbill Group 首席云经济学家 Corey Quinn 评论 说,WebSockets 的重点是成本优化:
单看这个很能吸引人的标题,“WebSockets 是如何让我们在 AWS 上花费上百万美元的”,它很好地说明了在大多数情况下单纯由于成本或性能原因而深入研究应用架构的深层问题是没有太大的意义的。但是在这样的环境中,它绝对是有意义的,根据 Levin 的说法,实现和部署环形缓冲后,Recall.ai 可以将机器人的 CPU 使用率最多降低 50%,从而优化 IPC 以提高 CPU 效率。这一变化使 AWS 的年度成本降低了 100 多万美元。
原文链接:
评论