Les VM et navigateurs cloud sont facturés au temps, ce qui expose les traitements par lots aux dépassements de quota. Il faut estimer la consommation, fixer une limite de concurrence réaliste et appliquer les mesures correctives dans le bon ordre.
Pour les ressources facturées au temps, la logique de facturation est simple : durée d'exécution multipliée par le nombre d'instances. Le quota est une limite stricte. Une fois atteinte, les tâches ne ralentissent pas seulement : elles échouent directement. De nouvelles instances ne peuvent plus être créées, des instances en cours peuvent être récupérées et les API commencent à renvoyer des erreurs de limitation. Savoir à quelle distance on se trouve de la limite est plus utile que d'augmenter le budget après coup.
Commencer par distinguer les consommations nécessaires
Un même quota peut produire des résultats très différents selon les tâches qui le consomment. Commencez par dresser un inventaire et séparez les tâches selon qu'elles nécessitent réellement une exécution en temps réel ou non.
Les tâches permanentes figurent parmi les plus gourmandes en quota. Elles peuvent fonctionner toute la journée alors qu'elles ne travaillent réellement que quelques minutes. Remplacer une surveillance continue par des déclenchements planifiés permet souvent de réduire fortement la consommation sans impact perceptible sur l'activité. Les pics concentrés sur certaines plages peuvent être décalés, tandis que les tâches ponctuelles peuvent être lancées uniquement à la demande.
Posez-vous ensuite une question : l'activité serait-elle affectée si cette tâche s'exécutait six heures plus tard ? Si oui, conservez-la sur le chemin critique et exécutez-la en temps réel. Sinon, transformez-la en traitement par lots de faible priorité et placez-la dans une période où le quota est moins tendu. Passer d'une surveillance horaire des prix des concurrents à deux vérifications par jour ne réduit généralement pas de manière significative la valeur de l'information.
Estimer la consommation et fixer la concurrence
Lorsque la facturation dépend du temps d'exécution des instances, la consommation totale d'un lot correspond approximativement à la durée moyenne d'une tâche multipliée par le nombre de tâches. Elle ne dépend pas du niveau de concurrence ; celui-ci détermine seulement le temps nécessaire pour terminer le lot. En revanche, la concurrence influe sur la pression instantanée : plus il y a d'instances lancées simultanément, plus on risque d'atteindre la limite de concurrence du pool de ressources ou la limitation imposée par la plateforme.
Commencez donc avec la concurrence minimale. Exécutez d'abord une seule tâche et mesurez sa durée moyenne et son taux de réussite. Augmentez ensuite progressivement à quelques tâches, puis à une dizaine, en enregistrant le taux d'échec et le nombre de nouvelles tentatives. Dès que le taux d'échec augmente nettement au-delà d'un certain point, vous avez trouvé la limite réellement exploitable. Aller plus loin ne fait que rendre, sous forme de nouvelles tentatives, le temps que vous pensiez avoir gagné.
N'oubliez pas les durées cachées dans vos estimations : attente de connexion, chargement des pages, étapes de vérification et nouvelles tentatives après échec. Elles sont souvent plus longues que le flux principal lui-même. Prévoir une marge par tâche est plus utile que chercher une précision à la minute.
À quoi ressemble un quota épuisé
L'épuisement du quota est parfois difficile à identifier, car il ressemble souvent à d'autres problèmes.
Une première manifestation est une tâche bloquée au démarrage parce que la création de l'environnement ou de l'instance est refusée, avec seulement un message d'échec vague dans les journaux. Une autre est la récupération d'une instance en plein traitement, qui annule le travail déjà effectué. On peut aussi observer des erreurs de limitation, un mélange de réussites et d'échecs, ou une file d'attente qui s'allonge sans être traitée.
Le cas le plus facile à mal diagnostiquer est le faux blocage : l'instance existe toujours et la tâche semble active, mais elle reste en réalité bloquée dans une attente pendant que le quota continue à se consommer avec le temps. Dans ce cas, consultez d'abord le panneau d'utilisation du quota, puis lancez une petite tâche isolée. Si elle ne démarre pas non plus, cherchez du côté du quota ou des autorisations. Si elle fonctionne normalement, le problème vient plus probablement de la concurrence ou de la réutilisation de l'environnement.
Ordre des mesures correctives
Commencez par les actions qui ne coûtent rien.
Premièrement, arrêtez les consommations permanentes de faible valeur et planifiez les tâches de surveillance. Deuxièmement, déplacez les tâches pouvant être retardées vers des périodes où le quota est plus disponible afin de lisser la courbe de consommation. Troisièmement, réduisez la limite de concurrence et ajoutez une file d'attente afin que les tâches soient traitées selon la capacité disponible au lieu de démarrer toutes ensemble. Quatrièmement, réduisez la consommation inutile : mettez en cache les mêmes ressources au lieu de les récupérer plusieurs fois, obtenez davantage de données par requête lorsque c'est pertinent, abandonnez rapidement les requêtes vouées à l'échec et évitez les nouvelles tentatives sans fin.
Après ces quatre étapes, demandez-vous seulement alors s'il faut augmenter le budget ou passer à un niveau supérieur. Vous constaterez souvent que le quota réellement nécessaire est plus faible que prévu au départ. À l'inverse, augmenter le budget en premier revient aussi à financer les mauvaises habitudes.
Ne pas compresser la couche d'environnement avec la couche de calcul
Une erreur fréquente lorsque l'on cherche à économiser du quota consiste à faire partager un même environnement de navigateur à plusieurs tâches, sous prétexte qu'il suffit de le lancer une seule fois.
Le coût apparaît immédiatement : les sessions s'écrasent mutuellement, les états de connexion se remplacent, les caches se mélangent et l'échec d'une tâche peut entraîner les autres. Le petit gain de temps d'instance est alors largement reperdu en diagnostic et en relances.
Ces deux couches doivent être considérées séparément. La couche de calcul exécute la logique des tâches, planifie à la demande et recherche l'efficacité économique. La couche d'environnement gère l'identité et l'isolation, avec un environnement indépendant par tâche pour privilégier la stabilité. Comprimer la couche d'environnement parce que la capacité de calcul est limitée revient à confondre deux catégories de coûts. La création et la récupération en masse des environnements devraient être gérées de manière centralisée par les outils de cette couche. Avec PurpleMark qui isole les sessions et les caches par environnement, les tâches et les exécuteurs de niveau supérieur peuvent être planifiés plus librement.
Dernier rappel : ne réduisez pas les coûts en contournant les règles. N'utilisez pas de services non officiels uniquement pour économiser du quota et n'essayez pas de forcer le débit en augmentant la fréquence des requêtes. Une fois la limitation déclenchée, les nouvelles tentatives consomment généralement plus de quota qu'un rythme maîtrisé.
