Dieser Artikel beschreibt die Bereitstellung einer skalierbaren und zustandsbehafteten Streamlit-Anwendung auf AWS und geht auf häufige Herausforderungen ein, die beim Übergang von der lokalen Entwicklung zu einer Produktions-Cloud-Umgebung auftreten. Der Schwerpunkt liegt auf der Überwindung der Einschränkungen der standardmäßigen In-Memory-Statusverwaltung von Streamlit, die zu Datenverlust bei Seitenaktualisierungen oder Serverneustarts führt, insbesondere bei hoher Auslastung.
Herausforderungen bei der Skalierbarkeit von Streamlit: Streamlit zeichnet sich durch eine schnelle Web-App-Entwicklung aus, aber die inhärente In-Memory-Statusverwaltung ist für cloudbasierte Mehrbenutzerbereitstellungen nicht geeignet. Die einfache Erhöhung der VM-Ressourcen ist eine kurzsichtige Lösung, die das Kernproblem der Datenpersistenz nicht angeht.
Vorgeschlagene Architektur (AWS): Die vorgestellte Lösung verwendet eine robuste Architektur, um Skalierbarkeit und Zustandsbezogenheit zu handhaben:
Warum nicht AWS Lambda?: Lambda ist zwar attraktiv für serverloses Computing, aber nicht mit Streamlit kompatibel, da Streamlit auf Websocket-Binärframes angewiesen ist, die das API-Gateway von Lambda nicht unterstützt.
EFS im Vergleich zu anderen Optionen: Eine Vergleichstabelle hebt die Vorteile von EFS gegenüber Alternativen wie RDS, DynamoDB, ElasticCache und S3 hervor und betont die einfache Einrichtung, Skalierbarkeit und Kosteneffizienz für diesen speziellen Fall Anwendungsfall.
Bewältigung der Load-Balancer-Kosten: Der Artikel erkennt die inhärenten Kosten von ALB an, argumentiert jedoch, dass seine Vorteile (Verkehrsverteilung, HTTP/2-Unterstützung, AWS-Integration) die Kosten überwiegen, insbesondere angesichts der verbesserten Zuverlässigkeit und Leistung für eine Produktionsanwendung.
Lösungsansatz: Der Schlüssel zu dieser Lösung ist die Verwendung einer Kombination aus browserseitigem lokalem Speicher (über streamlit-local-storage
) für Sitzungsschlüssel und EFS für persistente Sitzungsdaten. Dies minimiert den In-Memory-Status und gewährleistet gleichzeitig die Datenpersistenz über ECS-Knoten und Skalierungsereignisse hinweg. Die Einfachheit dieses Ansatzes wird hervorgehoben – der Kernanwendungscode bleibt zwischen lokaler Entwicklung und Cloud-Bereitstellung weitgehend unverändert.
Projektvorlage und Pseudocode: Ein Beispiel für ein LLM-Chatbot-Projekt (https://www.php.cn/link/f3a3cc4e1b8b4b0438505c0a38efad9f) wird zusammen mit einem Pseudocode bereitgestellt, der veranschaulicht, wie Sitzungsdaten verarbeitet werden wird mit pickle
für die Serialisierung und EFS für die Speicherung verwaltet. Der Code demonstriert das Abrufen und Speichern von Sitzungsdaten basierend auf einer eindeutigen Sitzungs-ID, wodurch Konsistenz gewährleistet wird, selbst wenn verschiedene ECS-Aufgaben dieselbe Sitzung verarbeiten.
Bereitstellungsschritte: Der Artikel bietet eine kurze Anleitung zur Bereitstellung der Anwendung: Klonen des Repositorys, Bereitstellen des CloudFormation-Stacks, Erstellen und Bereitstellen des Docker-Images, Zugriff auf den Chatbot und (implizit) Aktivieren der automatischen Skalierung für optimale Skalierbarkeit.
Fazit: Dieser Ansatz bietet eine praktische und effiziente Lösung für die Bereitstellung skalierbarer und zustandsbehafteter Streamlit-Anwendungen auf AWS, sodass sich Entwickler auf die Anwendungslogik statt auf komplexes Infrastrukturmanagement konzentrieren können. Die Lösung legt Wert auf Einfachheit und Kosteneffizienz und gewährleistet gleichzeitig Datenpersistenz und hohe Verfügbarkeit.
Das obige ist der detaillierte Inhalt vonSkalieren Sie einen Stateful Streamlit Chatbot mit AWS ECS und EFS. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!