使用 AWS ECS 和 EFS 扩展有状态 Streamlit 聊天机器人

本文详细介绍了在 AWS 上部署可扩展且有状态的 Streamlit 应用程序，解决从本地开发迁移到生产云环境时面临的常见挑战。 重点是克服 Streamlit 默认内存状态管理的限制，该限制会导致页面刷新或服务器重新启动时数据丢失，尤其是在重负载下。

Streamlit 的可扩展性挑战： Streamlit 擅长快速 Web 应用程序开发，但其固有的内存状态管理不足以支持多用户、基于云的部署。 单纯增加VM资源是一种短视的解决方案，并不能解决数据持久化的核心问题。

建议的架构 (AWS)： 提出的解决方案使用强大的架构来处理可扩展性和状态性：

• 应用程序负载均衡器 (ALB)： 在多个实例之间均匀分配传入流量。
• Fargate 上的弹性容器服务 (ECS)： 管理 Docker 容器，无需服务器管理开销即可轻松扩展。 利用arm64架构和优化的资源分配（0.25vCPU/0.5GB RAM）来提高成本效率。
• 弹性文件系统（EFS）：提供可扩展且持久的文件系统，挂载到多个ECS节点。这确保了跨可用区 (AZ) 的数据冗余和持久性，解决了核心状态问题。
• CloudFront（可选）：提高性能并通过 CDN 功能添加 HTTPS 安全性。

为什么不选择 AWS Lambda？： Lambda 虽然对无服务器计算很有吸引力，但由于 Streamlit 依赖于 websocket 二进制帧，而 Lambda 的 API 网关不支持，因此与 Streamlit 不兼容。

EFS 与其他选项： 比较表突出了 EFS 相对于 RDS、DynamoDB、ElasticCache 和 S3 等替代方案的优势，强调了其针对此特定选项的易于设置、可扩展性和成本效益用例。

解决负载均衡器成本：本文承认 ALB 的固有成本，但认为其好处（流量分配、HTTP/2 支持、AWS 集成）超过了费用，特别是考虑到可靠性和性能的提高用于生产应用程序。

解决方案：此解决方案的关键是结合使用浏览器端本地存储（通过 streamlit-local-storage）来存储会话密钥，并使用 EFS 来存储持久会话数据。 这可以最大程度地减少内存状态，同时确保跨 ECS 节点和扩展事件的数据持久性。 这种方法的简单性得到了凸显——核心应用程序代码在本地开发和云部署之间基本保持不变。

项目模板和伪代码：提供了一个示例LLM聊天机器人项目（https://www.php.cn/link/f3a3cc4e1b8b4b0438505c0a38efad9f），以及说明会话数据如何处理的伪代码使用 pickle 进行序列化和 EFS 进行存储进行管理。 该代码演示了基于唯一会话 ID 检索和保存会话数据，即使不同的 ECS 任务处理同一会话也能确保一致性。

部署步骤：本文提供了部署应用程序的简明指南：克隆存储库、部署 CloudFormation 堆栈、构建和部署 Docker 映像、访问聊天机器人以及（隐式）启用自动缩放以实现最佳可扩展性。

结论： 这种方法为在 AWS 上部署可扩展且有状态的 Streamlit 应用程序提供了实用且高效的解决方案，使开发人员能够专注于应用程序逻辑而不是复杂的基础设施管理。该解决方案优先考虑简单性和成本效益，同时确保数据持久性和高可用性。

以上是使用 AWS ECS 和 EFS 扩展有状态 Streamlit 聊天机器人的详细内容。更多信息请关注PHP中文网其他相关文章！