Notre bot Slack a géré 200 messages par jour pendant trois mois sans sourciller. Puis un blogueur tech en a parlé dans une newsletter, et nous sommes passés de 200 à 12 000 messages en 48 heures.
Tout a craqué. Pas de façon dramatique — le serveur n’a pas pris feu ni quoi que ce soit. Il a juste… ralenti. Et encore plus. Puis a commencé à perdre des messages. Et ensuite, il s’est complètement tu alors que 12 000 personnes se demandaient pourquoi le bot AI dont elles venaient d’entendre parler ne répondait pas.
Voici ce qui s’est passé, ce que nous avons fait, et comment nous sommes passé de “projet annexe amusant” à “chose dont les gens dépendent réellement” en une semaine.
Les 6 premières heures : Déni et Panique
La newsletter est arrivée dans les boîtes de réception à 9 heures un mardi. À 10 heures, notre file d’attente de messages comptait un retard de 400 messages. À midi, la file atteignait 2 000 et le temps de réponse était de 45 secondes (normalement moins de 3 secondes).
Ma première réaction : “Eh bien, c’est beaucoup de messages.” Ma seconde réaction, 20 minutes plus tard : “Oh non.”
Le goulot d’étranglement n’était pas le CPU ou la mémoire — c’était l’API du modèle AI. Chaque message nécessitait un appel à l’API, et nous atteignions les limites de taux de manière drastique. Notre plan API en version gratuite permettait 60 requêtes par minute. Nous en avions besoin de plus de 200 par minute.
Solution rapide : mettre à niveau le plan API. Nous avons obtenu notre limite de taux à 500 requêtes par minute en 30 minutes en passant à un plan payant. La file a commencé à s’épuré. Crise partiellement évitée.
Mais ensuite, la seconde vague est arrivée.
Heures 6-24 : Tout le reste casse
Augmenter le débit de l’API a révélé tous les autres goulots d’étranglement que nous n’avions pas remarqués à faible volume.
Connexions à la base de données saturées. Chaque message déclenchait une recherche dans la base de données pour le contexte utilisateur. À 200 messages/jour, pas de problème. À 12 000, notre pool de connexions était épuisé. Les utilisateurs recevaient des erreurs “service indisponible”.
Solution : augmentation de la taille du pool de connexions, ajout de pool de connexions avec PgBouncer et mise en place de réplicas en lecture pour les recherches de contexte.
Fuite de mémoire dans le gestionnaire de messages. Une variable qui stockait le contexte de la conversation grossissait sans être nettoyée. À faible volume, elle grossissait lentement et était effacée par des redémarrages occasionnels. À haut volume, elle consommait toute la mémoire disponible en environ 4 heures.
Solution : ajout d’un nettoyage approprié après le traitement de chaque message. Ce bug était présent depuis le premier jour — il n’importait jamais jusqu’à ce qu’il le fasse.
Traitement à thread unique. Les messages étaient traités séquentiellement. Un à un. À 200 messages/jour, ça allait. À 12 000, cela signifiait que chaque message attendait derrière chaque autre message.
Solution : mise en place d’un traitement parallèle avec une véritable file d’attente de tâches. Les messages sont répartis sur plusieurs travailleurs. Cela a réduit le temps de réponse moyen de 45 secondes à moins de 5.
Le moment “Oh, nous avons besoin d’une vraie infrastructure”
Au bout de 24 heures, j’ai réalisé que notre architecture “ça fonctionne sur un VPS à 10 $/mois” n’allait pas supporter une croissance soutenue. Nous avions besoin de :
Un véritable équilibreur de charge. Pas parce que nous avions besoin de plusieurs serveurs encore, mais parce que nous avions besoin de vérifications de santé, de redémarrages automatiques et de la capacité à déployer des mises à jour sans temps d’arrêt.
Une file d’attente de messages. Une file d’attente de tâches soutenue par Redis qui découple la réception des messages du traitement des messages. Si le modèle AI est lent, les messages attendent dans la file au lieu de temporairement échouer. Si un travailleur plante, le message est réessayé au lieu d’être perdu.
Surveillance qui alerte réellement. Nous avions des journaux. Nous n’avions pas d’alerte. La différence compte quand les choses se cassent à 2 heures du matin et que personne ne regarde les journaux.
Scalabilité horizontale. La capacité d’ajouter plus de travailleurs lorsque la charge augmente. Notre architecture s’auto-scalait désormais : si la profondeur de la file dépasse un seuil, de nouveaux travailleurs se mettent en marche automatiquement.
Ce que nous avons livré en une semaine
Jour 1-2 : Mise à niveau d’urgence de la limite de taux, correction du pool de connexions, correction de la fuite de mémoire.
Jour 3-4 : Mise en œuvre de la file d’attente de messages, traitement parallèle.
Jour 5-6 : Équilibreur de charge, surveillance avec alertes, scalabilité horizontale.
Jour 7 : Enfin dormi.
Le coût total de l’infrastructure est passé de 10 $/mois à environ 120 $/mois. Mais nous sommes passés de la prise en charge de 200 messages/jour à la gestion confortable de 50 000. Et l’architecture peut encore évoluer simplement en ajoutant des travailleurs.
La liste de contrôle pour la scalabilité que j’aurais aimé avoir
Si votre bot AI prend de l’ampleur et que vous souhaitez être prêt avant que le pic n’arrive :
Configurez la surveillance avec alertes maintenant. Temps de réponse, taux d’erreur, profondeur de la file, utilisation de la mémoire. Seuils d’alerte à 2x les valeurs normales. Vous voulez être informé des problèmes avant que les utilisateurs ne vous le disent.
Implémentez une file d’attente de messages. Même à faible volume. Cela découple la réception du traitement, permet des réessais et rend le passage à l’échelle horizontal trivial par la suite.
Profitez de votre utilisation des ressources par message. Combien de requêtes à la base de données par message ? Combien de mémoire ? Combien d’appels API ? Multipliez-les par votre objectif de croissance et voyez où seront les goulots d’étranglement.
Testez à 10x votre charge actuelle. Utilisez un outil de test de charge pour simuler 10x le volume de messages pendant une heure. Observez ce qui casse. Corrigez-le avant que ça ne casse en production.
Ayez un plan de montée en puissance documenté. “Si le trafic double, faites ces trois choses.” Avoir le plan écrit signifie que vous pouvez l’exécuter à 2 heures du matin quand vous êtes à moitié endormi au lieu d’essayer d’architecturer des solutions sous pression.
Ce que j’ai appris sur l’IA à grande échelle
Le modèle AI n’est généralement pas le goulot d’étranglement — tout ce qui l’entoure l’est. Requêtes de base de données, gestion du contexte, formatage des sorties, routage des messages — toute l’infrastructure “ennuyante” que vous négligez lors de la création d’un prototype. À grande échelle, les éléments ennuyeux comptent plus que les éléments AI.
Aussi : les limites de taux sont la contrainte de scalabilité la plus sous-estimée dans les applications AI. Votre architecture brillante n’a pas d’importance si l’API du modèle ne permet que 60 requêtes par minute. Vérifiez vos limites avant de lancer, et ayez un plan pour quand vous les dépassez.
Le pic viral était stressant mais finalement positif. Cela nous a forcés à construire l’infrastructure que nous aurions dû construire dès le début. Et maintenant nous sommes prêts pour le prochain pic — quand qu’il arrive.
🕒 Published: