この記事では、スケーラブルでステートフルな Streamlit アプリケーションを AWS にデプロイする方法について詳しく説明し、ローカル開発から実稼働クラウド環境に移行するときに直面する一般的な課題に対処します。 Streamlit のデフォルトのメモリ内状態管理の制限を克服することに重点が置かれています。この制限は、特に負荷が高い場合に、ページの更新やサーバーの再起動時にデータ損失を引き起こします。
Streamlit のスケーラビリティの課題: Streamlit は迅速な Web アプリ開発に優れていますが、その固有のメモリ内状態管理はマルチユーザーのクラウドベースの展開には不十分です。 VM リソースを単に増やすだけでは近視眼的な解決策であり、データの永続性という中核的な問題には対処できません。
提案されたアーキテクチャ (AWS): 提示されたソリューションは、スケーラビリティとステートフルネスを処理するために堅牢なアーキテクチャを使用しています:
なぜ AWS Lambda ではないのか?: Lambda はサーバーレス コンピューティングには魅力的ですが、Streamlit は WebSocket バイナリ フレームに依存しているため、Streamlit とは互換性がありません。これは Lambda の API ゲートウェイがサポートしていません。
EFS と他のオプション: 比較表では、RDS、DynamoDB、ElasticCache、S3 などの代替手段と比較した EFS の利点が強調されており、この特定の場合のセットアップの容易さ、拡張性、費用対効果が強調されています。ユースケース。
ロードバランサーのコストへの対処: この記事は、ALB に固有のコストを認めていますが、特に信頼性とパフォーマンスの向上を考慮すると、その利点 (トラフィック分散、HTTP/2 サポート、AWS 統合) が費用を上回ると主張しています。本番アプリケーション用。
ソリューション アプローチ: このソリューションの鍵は、セッション キーにブラウザー側のローカル ストレージ (streamlit-local-storage 経由) と永続セッション データに EFS を組み合わせて使用することです。 これにより、ECS ノード間でのデータの永続性とスケーリング イベントが確保されながら、メモリ内の状態が最小限に抑えられます。 このアプローチのシンプルさが強調されています。コア アプリケーション コードは、ローカル開発とクラウド デプロイの間でほとんど変更されていません。
プロジェクト テンプレートと疑似コード: サンプル LLM チャットボット プロジェクト (https://www.php.cn/link/f3a3cc4e1b8b4b0438505c0a38efad9f) が、セッション データの方法を示す疑似コードとともに提供されます。シリアル化には pickle を使用し、EFS を使用して管理されます。 ストレージ。 このコードは、一意のセッション ID に基づいてセッション データを取得および保存することを示し、異なる ECS タスクが同じセッションを処理する場合でも一貫性を確保します。
デプロイメント手順: この記事では、アプリケーションをデプロイするための簡潔なガイドを提供します。リポジトリのクローン作成、CloudFormation スタックのデプロイ、Docker イメージの構築とデプロイ、チャットボットへのアクセス、(暗黙的な) 自動有効化などです。最適なスケーラビリティのためのスケーリング。
結論: このアプローチは、スケーラブルでステートフルな Streamlit アプリケーションを AWS にデプロイするための実用的で効率的なソリューションを提供し、開発者が複雑なインフラストラクチャ管理ではなくアプリケーション ロジックに集中できるようにします。このソリューションは、データの永続性と高可用性を確保しながら、シンプルさとコスト効率を優先します。
以上がAWS ECS と EFS を使用してステートフル Streamlit チャットボットを拡張するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
