Modal associe une session à un seul conteneur et conserve le contexte lors de la reconnexion

Un bot vocal discute avec un utilisateur, la connexion est coupée, l'utilisateur se reconnecte, et tombe sur un processus qui ne sait rien de lui. Pour une infrastructure serveur, il peut s'agir d'une répartition de charge tout à fait normale. Pour le produit, c'est une conversation brisée. Modal a présenté les Sticky Sessions : un mécanisme qui dirige les requêtes d'une même session vers le même conteneur et fait évoluer l'infrastructure en fonction du nombre de sessions actives.

En pratique, le développeur peut conserver un état temporaire à proximité du code en cours d'exécution : le contexte d'un agent vocal, l'état d'un décodeur de reconnaissance vocale ou une salle de jeu partagée. Lors d'une reconnexion, la requête revient là où cet état se trouve déjà, tant que la session reste active.

Pourquoi un WebSocket seul ne suffit pas

Imaginons un service d'entraînement aux entretiens d'embauche avec une IA vocale. Dans le conteneur fonctionnent l'agent et le traitement audio, et c'est là aussi que se trouve l'état de la conversation en cours. L'utilisateur passe du Wi-Fi à la connexion mobile. Il faut rétablir la connexion, mais le produit doit reprendre l'entretien exactement là où il s'était arrêté.

Comme l'explique Modal, dans ses Web Functions, un WebSocket est lié à un appel de fonction donné. Après une rupture, un nouvel appel est créé, qui peut atterrir dans un autre conteneur. Le WebSocket seul ne résout donc pas le problème du retour vers le processus d'origine.

Une solution de contournement consiste à limiter l'application à un seul conteneur. Les requêtes n'ont alors nulle part ailleurs où aller, mais avec le problème de routage disparaît aussi la possibilité de la mise à l'échelle horizontale. Modal Servers propose aussi un routage via l'en-tête Modal-Affinity-Routing-Key, mais il fonctionne au mieux (best effort) : le conteneur peut être arrêté ou remplacé.

Les Sticky Sessions introduisent une association plus stricte pendant la durée de la session. C'est particulièrement utile pour les applications Gradio et Streamlit, où l'état utilisateur est lié à un processus serveur précis. Le développeur n'a pas besoin de maintenir tout le service en une seule instance pour assurer la continuité de certains parcours utilisateurs.

Comment une requête retrouve le bon processus

Pour activer le mécanisme, on marque la classe Modal Server avec le décorateur @modal.sessioned(), puis on crée une session via le SDK ou l'API HTTP. Dans l'exemple fourni par l'entreprise, l'appel sessions.start(idle_timeout=600) renvoie un objet contenant un jeton. Le client transmet ce jeton dans l'en-tête Modal-Authorization lors des requêtes suivantes.

Le jeton est signé et contient les informations nécessaires au routage. Le proxy le vérifie et envoie la requête au conteneur auquel la session appartient. Ainsi, le proxy n'a pas besoin de maintenir sur toutes ses instances une table de correspondance cohérente entre sessions et conteneurs.

Un même jeton peut être partagé entre plusieurs participants d'une salle commune. Par exemple, deux utilisateurs se connectent au même chat et travaillent sur l'état d'un seul processus. La reconnexion ramène le participant dans la même salle pendant la durée de vie de celle-ci. Comme le jeton donne accès à la session, l'application doit le traiter comme un identifiant sensible.

L'unité de mise à l'échelle change également. Un conteneur accepte un nombre défini de sessions simultanées. Lorsqu'il n'y a plus de place, les nouvelles sessions attendent la fin des sessions existantes ou la disponibilité d'un conteneur supplémentaire. L'autoscaling tient compte des sessions actives et de la file d'attente, car une conversation déjà commencée ne peut pas être transférée arbitrairement vers un processus voisin.

Ce qu'il faut vérifier avant le déploiement

La principale limite : l'association de la route ne garantit pas la conservation des données en cas de panne du conteneur. La publication décrit la continuité des requêtes au sein d'une session, mais ne promet pas la restauration de sa mémoire après un incident. L'historique des conversations, les résultats de travail et d'autres données importantes doivent toujours être sauvegardés séparément si le produit doit survivre à de tels événements.

Il y a aussi la question de la répartition de la charge. Deux sessions peuvent consommer des ressources très différentes : une courte conversation textuelle et un flux audio continu produisent des charges radicalement différentes. Le nombre de sessions par conteneur devra donc être choisi en fonction du scénario réel. Le mécanisme ne déplace pas automatiquement une session lourde existante pour équilibrer la charge.

Pour une équipe qui développe des agents vocaux ou une interface dépendant de la mémoire du processus, c'est l'occasion de vérifier le comportement en cas de coupure de connexion et d'évaluer le coût des sessions longues. Les Sticky Sessions comblent une lacune d'infrastructure précise : elles permettent de combiner l'ajout automatique de conteneurs avec le retour de l'utilisateur vers un processus déjà en cours. Le plan de reprise après sinistre reste une partie de l'architecture de l'application.