使用 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中文網其他相關文章！