Modal startet Sticky Sessions: Nutzer bleiben im selben Container

20. Oktober 2026Quelle: Modal

Modal hat Sticky Sessions vorgestellt. Die Funktion leitet alle Anfragen einer Sitzung an denselben Container und behält dabei das Autoscaling von Serverless bei. Sie baut auf den latenzarmen Modal Servers des Unternehmens auf und richtet sich an zustandsbehaftete Anwendungen wie Sprachagenten, Chaträume und Mehrspielerspiele.

Das Wichtigste in Kürze

Modal hat Sticky Sessions vorgestellt, die alle Anfragen einer Sitzung an denselben Container leiten.
Die Funktion basiert auf Modal Servers und wird mit dem Decorator @modal.sessioned() aktiviert.
Signierte Sitzungstokens tragen die Routing-Metadaten, sodass der Proxy keine Sitzungszuordnung speichert.
Das Autoscaling nutzt aktive Sitzungen als Einheit der Parallelität und stellt bei erschöpfter Kapazität in eine Warteschlange.
Zielanwendungen sind Sprachagenten, geteilte Chaträume und Mehrspielerspiele wie Curvytron.

Was Sticky Sessions leisten

Laut Modal brauchen immer mehr Workloads etwas zwischen automatisch skalierender Serverless-Rechenleistung und Sandboxes, bei denen Nutzer den Lebenszyklus der Container selbst steuern. Als Beispiele nennt das Unternehmen ein Speech-to-Text-Modell mit Decoder-Zustand für einen Audiostream, einen Sprachagenten, der ein Gespräch führt, und ein Mehrspielerspiel. In diesen Fällen müssen Nutzer bei jeder erneuten Verbindung während der gesamten Sitzung wieder im selben Container landen.

Um die Funktion zu nutzen, erstellen Entwickler einen Modal Server mit dem Decorator @modal.sessioned() und starten Sitzungen über das SDK oder die HTTP-API. In Modals Beispiel liefert der Aufruf Server.sessions.start(idle_timeout=600) eine Sitzung zurück, deren Token in einem Modal-Authorization-Header übergeben wird.

Frühere Optionen reichten laut Modal nicht aus. Eine WebSocket-Verbindung über Web Functions sei an einen Function-Input gebunden, nicht an einen Container, sodass eine neue Verbindung woanders landen könne. Mit max_containers=1 sei die Zuordnung zwar garantiert, dafür entfalle die Skalierung. Der bestehende Header Modal-Affinity-Routing-Key biete nur Routing nach bestem Bemühen, und der Container könne jederzeit herunterskaliert oder ersetzt werden.

Wie Modal die Funktion gebaut hat

Sticky Sessions nutzen die Infrastruktur hinter Modal Servers, darunter den hauseigenen zustandslosen Proxy namens fprs. Modal nennt drei Dinge, die das Routing auf Anfrageebene nicht leistete: feste Zuordnung, einen vom Host des Containers verfolgten Sitzungslebenszyklus und Autoscaling auf Basis von Sitzungen statt Anfragen.

Autorisierung: Jeder Aufruf von sessions.start() liefert ein signiertes Sitzungstoken. Modal kodiert die Routing-Metadaten direkt im Token, sodass der Proxy keine Zuordnung von Sitzung zu Container über Neustarts und Replikate hinweg speichern muss. Wer das Token teilt, ermöglicht mehreren Teilnehmern den Zugriff auf denselben Zustand.
Lastverteilung: Der Sitzungszustand liegt nur auf dem zuständigen Host. Deshalb fragen Load Balancer die Container regelmäßig nach einem Schnappschuss der verfügbaren Parallelität ab. Zusammen mit den jüngsten Routing-Entscheidungen verteilen sie damit Sitzungen und vermeiden unnötige Roundtrips zu vollen Containern.
Autoscaling: Da sich Sitzungsverkehr nicht verschieben lässt, werden Sitzungen zur Einheit der Parallelität. Ein Container kann eine oder mehrere Sitzungen gleichzeitig ausführen. Ist die Kapazität erschöpft, warten neue Sitzungen in einer Warteschlange, bis eine Sitzung endet oder ein neuer Container bereitsteht. Der Autoscaler beobachtet aktive Sitzungen und den Bedarf in der Warteschlange.

Anwendungsfälle und Bedeutung

Modal nennt drei Anwendungstypen, die die Funktion unterstützt. Der Modal Phonon Voice Bot betreibt einen Pipecat-Agenten mit Gradium Phonon Text-to-Speech über WebRTC, wobei jeder Anruf an einen Container gebunden ist, damit das Signaling die Peer-Verbindung erreicht. Ein Beispiel für einen Chatraum mit Sitzungen hinterlegt für jeden Raum eine Sitzung, sodass Clients die Verbindung verlieren und wieder in denselben Raum zurückkehren können. Spieleanwendungen können Zustand im Arbeitsspeicher halten, um Kontinuität zu wahren und Verzögerungen zu verringern. Die Funktion unterstützt sowohl das Sichern des Spielfortschritts als auch das Hosten paralleler Räume.

Modal betreibt zudem eine eigene Instanz des Mehrspielerspiels Curvytron in der Region us-east auf Modal Servers mit Sticky Sessions. Spieler erstellen einen Raum, teilen den Link und spielen gemeinsam, und Modal skaliert anhand der Zahl aktiver Räume.

Für Entwickler bedeutet die Neuerung, dass zustandsbehaftete, sitzungsgebundene Apps auf Modal laufen können, ohne dass die Flotte auf einen Container festgelegt wird. Angaben zu Preisen oder Verfügbarkeit macht die Quelle nicht.