Une file d’attente ne crée pas de capacité

Une API reçoit mille tâches par seconde. Ses workers en exécutent huit cents. Ajouter une file évite de rejeter immédiatement les deux cents tâches restantes. Cela donne du temps, pas de la capacité : chaque seconde passée dans cette situation augmente le travail en retard.

Le piège apparaît après le pic. Les graphiques CPU redeviennent normaux, les requêtes entrantes ont baissé, mais les utilisateurs attendent encore. Le système consomme sa capacité à traiter le passé.

Le modèle du réservoir

Appelons $\lambda$ le débit d'arrivée et $\mu$ le débit de traitement, en tâches par seconde. Tant que la file n'est pas vide, son évolution moyenne simplifiée est :

$$\frac{dB}{dt}=\lambda-\mu$$

Sur un pic de cinq minutes à $\lambda=1000$ avec $\mu=800$, le backlog augmente de $200\times300=60\,000$ tâches. Si le trafic retombe ensuite à $700$, il ne reste que $100$ tâches par seconde pour résorber le retard :

$$T_{\mathrm{rattrapage}}=\frac{B}{\mu-\lambda} =\frac{60\,000}{800-700}=600\ \mathrm{s}$$

Cinq minutes de surcharge ont produit dix minutes de rattrapage. Si le trafic retombe seulement à $790$, le même calcul donne $6000$ secondes, soit cent minutes. Une petite différence dans la marge disponible produit une très grande différence dans le retour à la normale.

La moyenne cache encore quelque chose

Le modèle précédent suppose des tâches comparables et des débits réguliers. Dans une file aléatoire, on peut attendre même lorsque la capacité moyenne dépasse le trafic moyen. Pour un modèle M/M/1 — arrivées de Poisson, durées exponentielles, un serveur — le temps moyen dans le système vaut :

$$W=\frac{1}{\mu-\lambda}$$

Avec $\mu=100$ tâches par seconde et $\lambda=50$, il vaut $20\ \mathrm{ms}$. À $\lambda=95$, il atteint $200\ \mathrm{ms}$. À $\lambda=99$, une seconde. Ce résultat n'est pas une prévision exacte pour un cluster de workers ; il montre comment la proximité de la saturation amplifie l'attente dans un modèle explicite.

Une autre relation, la loi de Little, relie le nombre moyen de tâches présentes $L$, le débit effectif $\lambda$ et le temps moyen passé $W$ dans un système stable :

$$L=\lambda W$$

Il faut conserver le même périmètre et les mêmes unités. Compter seulement les messages disponibles dans la file puis utiliser une latence qui inclut l'exécution mélange deux frontières différentes. En surcharge sans régime stable, lire la formule comme une garantie de latence est également trompeur.

Quand les retries alimentent le réservoir

Un timeout peut entraîner une répétition alors que la première tentative travaille encore. Le débit réel devient le débit métier multiplié par le nombre moyen de tentatives. Si chaque requête engendre en moyenne $1{,}4$ tentatives, un trafic métier de $600$ par seconde impose $840$ traitements potentiels par seconde.

Ajouter des workers n'aide que si une ressource en aval peut les servir. Si tous attendent la même base saturée, augmenter la concurrence peut allonger les transactions et aggraver les timeouts. Il faut mesurer le débit effectivement terminé, pas seulement le nombre de processus actifs.

L'article d'AWS Avoiding insurmountable queue backlogs examine ces situations et les stratégies d'isolation. Notre exemple numérique en est une lecture élémentaire : la file absorbe un écart temporaire, mais ne peut pas rendre soutenable un écart permanent.

Choisir ce qui a encore de la valeur

Une tâche de recalcul de recommandation vieille d'une heure peut être devenue inutile ; un événement comptable conserve sa valeur. On ne peut donc pas appliquer la même expiration à toutes les files. Pour un état remplaçable, conserver seulement la dernière demande par clé peut économiser beaucoup de travail. Pour un événement à conserver, il faut prévoir la capacité et une récupération durable.

Une politique d'admission explicite borne la mémoire et l'attente. Refuser temporairement une nouvelle tâche, avec un signal exploitable par l'appelant, peut mieux servir les utilisateurs qu'accepter tout et livrer trop tard. La décision doit correspondre au contrat fonctionnel.

Le tableau de bord qui aide à décider

Trois mesures se complètent : profondeur de la file, âge du plus ancien travail utile et débit terminé. La profondeur seule devient difficile à interpréter si la durée des tâches varie. L'âge révèle directement qu'une promesse de délai est menacée.

Un test de charge pertinent inclut la récupération après le pic, pas seulement le plateau de charge. Il enregistre combien de temps le système met à retrouver une file vide et combien de tâches ont expiré ou été répétées. La capacité annoncée doit inclure cette marge de rattrapage. Dimensionner un service exactement sur son débit moyen, c'est décider implicitement qu'il n'aura jamais de retard à effacer.