Passage à l'échelle des API d'agents IA avec état grâce aux principes des microservices

À mesure que les agents IA passent du stade de prototypes expérimentaux à celui de systèmes de production, les ingénieurs sont confrontés à un défi de mise à l'échelle que les architectures web traditionnelles peinent à gérer. Contrairement aux utilisateurs humains, les agents génèrent des rafales rapides de requêtes avec état nécessitant un contexte cohérent sur plusieurs répliques de serveurs. Une récente analyse technique démontre comment l'application de modèles classiques de microservices — notamment l'absence d'état (statelessness), les cloisonnements (bulkheads) et les points d'accès intelligents (smart endpoints) — peut résoudre ces points de friction sans réinventer la roue.

Ce qui s'est passé

La plupart des applications IA modernes reposent sur des protocoles structurés, tels que l'API compatible OpenAI, pour gérer les conversations multi-tours. Bien que ces interfaces fonctionnent bien dans des configurations à réplique unique, elles échouent souvent lors d'une mise à l'échelle horizontale. Dans un benchmark typique de preuve de concept, une API monolithique exécutée sur une seule machine a géré 800 tours avec zéro perte de contexte. Cependant, lorsque le même système a été distribué sur trois machines derrière un équilibreur de charge, il a perdu le contexte dans 75 % des interactions. Le modèle continuait de répondre avec des codes d'état HTTP 200, mais les réponses manquaient de l'historique de conversation nécessaire car les requêtes arrivaient sur des serveurs ne conservant pas l'état local.

La cause profonde réside dans la différence fondamentale entre le trafic des agents et le trafic web standard. Les boucles des agents sont avec état, alors que chaque requête HTTP est indépendante. Sans sessions collantes (sticky sessions) ou stockage partagé durable, la distribution de ces requêtes sur les répliques rompt le fil conducteur de la conversation. De plus, les agents fonctionnent à la vitesse machine, générant des rafales de travail avec peu de temps de réflexion entre les tours. Ils effectuent également des tentatives agressives en cas d'erreur, ce qui peut amplifier la pression sur les dépendances en aval. Ces caractéristiques créent une forme de charge que les conceptions traditionnelles avec état ne peuvent absorber efficacement.

Pour y remédier, l'analyse propose de reconstruire les API adaptées aux agents en utilisant les principes de la littérature sur les microservices des années 2010. En décomposant l'application en une passerelle, un service de mémoire et un service d'outils, les développeurs peuvent isoler les domaines de défaillance. La passerelle gère le protocole OpenAI sans conserver d'état, tandis que le service de mémoire possède l'historique des conversations et les pistes d'audit. Cette décomposition permet à chaque composant de monter en charge indépendamment et d'appliquer des contrôles de concurrence spécifiques, garantissant que l'utilisation intensive d'outils ne bloque pas les complétions de chat standard.

Comment cela fonctionne

L'architecture proposée repose sur trois mécanismes clés : l'absence d'état, les cloisonnements et le stockage de données convergent. L'absence d'état garantit que l'état de la conversation est déplacé hors du processus d'application vers un magasin partagé. Cela permet à toute réplique de servir n'importe quel tour de n'importe quelle conversation, éliminant le besoin d'affinité de session. Les cloisonnements isolent différentes parties du système pour empêcher les défaillances en cascade. Par exemple, des emplacements de concurrence distincts sont attribués aux requêtes de chat simples et aux requêtes contenant des outils. Si une recherche vectorielle lente ou un appel d'API externe bloque le chemin des outils, le chemin de chat standard reste disponible pour les autres utilisateurs.

La convergence des données est obtenue en utilisant un moteur de base de données unifié plutôt qu'en répartissant les données sur plusieurs magasins spécialisés. Dans de nombreuses architectures IA, les développeurs pourraient utiliser Postgres pour les données relationnelles, Redis pour la mise en cache et une base de données vectorielle séparée pour les embeddings. Cette approche introduit des défis complexes de cohérence, surtout lorsqu'un seul tour d'agent nécessite d'écrire simultanément l'état de la conversation, les enregistrements d'outils, les faits de mémoire et les entrées d'idempotence. En utilisant une base de données comme Oracle AI Database Free, qui prend en charge les données relationnelles, JSON et vectorielles dans un seul moteur, ces écritures peuvent être traitées dans une transaction unique. Cela garantit l'atomicité et simplifie la gestion des sauvegardes et des identifiants.

Le système utilise des sémaphores pour appliquer des limites de concurrence au niveau du service. Par exemple, la passerelle pourrait allouer 24 emplacements pour le chat et huit pour les outils. Lorsqu'une requête arrive, elle doit acquérir un emplacement avant de procéder. Cela empêche une avalanche d'appels d'outils d'épuiser toutes les ressources disponibles. De plus, des fonctionnalités au niveau de la base de données telles que SELECT ... FOR UPDATE avec des colonnes de version aident à sérialiser les mises à jour conflictuelles provenant de différentes répliques, garantissant que les tours concurrents dans la même conversation n'écrasent pas mutuellement leur état.

Détails clés

• Perte de contexte dans les monolithes : La mise à l'échelle d'une API monolithique avec état d'une à trois répliques a entraîné un taux de perte de contexte de 75 % lors des benchmarks, malgré des réponses HTTP réussies.
• Quatre propriétés du trafic des agents : Les conversations sont longues mais les requêtes sont sans état ; les appels d'outils se propagent de manière imprévisible ; les agents effectuent des tentatives agressives ; et la charge est par rafales et cadencée par la machine.
• Isolation par cloisonnement : La séparation des pools de concurrence pour le chat et les outils empêche les exécutions lentes d'outils de bloquer les requêtes de chat standard, améliorant ainsi la résilience globale du système.
• Stockage de données convergent : L'utilisation d'une base de données unique pour les données relationnelles, JSON et vectorielles évite la surcharge de cohérence liée à la gestion de plusieurs datastores spécialisés pour un seul tour d'agent.
• Points d'accès intelligents, tuyaux stupides : Le protocole de complétion de chat OpenAI sert de couche de transport stable, tandis que l'intelligence telle que le routage et l'ingénierie de la mémoire est implémentée dans la logique de l'application.
• Sécurité des transactions : Les transactions de base de données garantissent que l'état de la conversation, les audits d'outils et les embeddings de mémoire sont écrits atomiquement, empêchant les mises à jour partielles lors des tentatives.

Pourquoi c'est important

Pour les ingénieurs logiciels développant des produits IA, comprendre ces changements architecturaux est crucial pour la fiabilité. Les défaillances silencieuses, où le système semble sain mais fournit des réponses incorrectes en raison d'un contexte manquant, sont difficiles à déboguer et érodent la confiance des utilisateurs. En adoptant des conceptions sans état et un stockage partagé, les équipes peuvent faire évoluer leurs applications horizontalement sans sacrifier la continuité conversationnelle. Cette approche simplifie également les opérations, car elle supprime le besoin de configurations complexes d'affinité de session dans les équilibreurs de charge.

De plus, l'utilisation de cloisonnements et de données convergentes réduit la complexité opérationnelle et améliore les performances sous charge. L'isolation des tâches gourmandes en ressources comme les recherches vectorielles garantit que la fonctionnalité principale de chat reste réactive. La consolidation des types de données dans un seul moteur de base de données élimine le besoin de coordination au niveau de l'application entre plusieurs systèmes, réduisant la latence et le risque d'incohérence des données. Ces modèles permettent aux développeurs de construire des systèmes d'agents robustes et évolutifs en utilisant des principes d'ingénierie établis plutôt que de compter sur des solutions personnalisées fragiles.

Ce que vous pouvez faire

• Découpler l'état du calcul : Déplacez l'historique des conversations et la mémoire des agents hors de la mémoire de l'application vers un système de stockage partagé et durable accessible par toutes les répliques.
• Implémenter des cloisonnements : Utilisez des sémaphores ou des contrôles de concurrence similaires pour séparer les pools de ressources pour différents types de requêtes, tels que les complétions de chat et les exécutions d'outils.
• Converger votre couche de données : Évaluez les bases de données qui prennent en charge les données relationnelles, JSON et vectorielles dans un seul moteur pour simplifier la gestion des transactions et réduire les risques de cohérence.
• Adopter des protocoles standards : Utilisez les API compatibles OpenAI comme couche de transport pour tirer parti des SDK et outils existants, en gardant le protocole simple et stable.
• Tester la perte de contexte : Exécutez des benchmarks qui distribuent les requêtes sur plusieurs répliques pour identifier et corriger les problèmes silencieux de perte de contexte avant le déploiement en production.
• Utiliser la concurrence optimiste : Implémentez des colonnes de version et des verrouillages au niveau de la base de données pour gérer en toute sécurité les mises à jour concurrentes du même état de conversation.