L’autoscaling suit une demande variable, mais une mauvaise règle peut augmenter les coûts ou saturer la base. Voici comment préparer capacité, limites et suivi.
Décrire la charge à absorber
Mesurez d’abord la demande réelle : requêtes par minute, messages en attente, utilisateurs actifs ou tâches simultanées. Reliez cette mesure à une capacité observable, comme le temps de réponse ou le nombre d’opérations traitées par instance. Le CPU seul ne décrit pas toujours la file d’attente d’un worker ni la limite d’un fournisseur externe.
Identifiez les variations prévisibles. Une campagne, une clôture comptable ou un import mensuel peut être planifié avec une capacité minimale temporaire. Une hausse imprévisible demande un déclenchement basé sur la demande et une limite qui protège le budget.
Choisir le bon signal
Pour une API, le taux de requêtes et la latence peuvent guider l’ajout d’instances. Pour un traitement asynchrone, la longueur de la file et l’âge du message donnent souvent une information plus directe. Pour une base de données, le nombre de connexions, les verrous et les lectures lentes peuvent devenir la limite avant le CPU.
Chaque signal nécessite une fenêtre et un seuil. Une alerte sur une valeur instantanée réagit à un pic très court et provoque des changements répétés. Une moyenne trop longue laisse les utilisateurs attendre avant l’ajustement. Comparez le délai de démarrage de la capacité avec la vitesse à laquelle la charge augmente.
Protéger les dépendances
Ajouter des serveurs web ne sert pas si la base, le service de paiement ou l’API partenaire possède une limite fixe. Définissez un plafond de concurrence par instance et mettez en place une file lorsque le producteur avance plus vite que le consommateur. Les retries doivent respecter un délai et une limite, car plusieurs clients qui réessaient ensemble peuvent amplifier la charge.
Lisez les quotas du fournisseur cloud et surveillez leur consommation. Les limites de taux ne doivent pas être découvertes pendant une campagne. Lorsque le service externe ne peut pas suivre, une réponse différée ou un statut en attente est parfois préférable à des tentatives immédiates.
Fixer un minimum et un maximum
Le minimum évite de démarrer un service à froid à chaque requête et réserve une capacité de base. Le maximum protège une base de données et le budget, mais il faut documenter ce qui arrive lorsque la limite est atteinte. Une file qui augmente, une réponse 429 ou une page dégradée sont des comportements à choisir et à tester.
Calculez le coût de la capacité minimale sur une période normale, puis celui du maximum pendant un pic. Les estimations doivent inclure stockage, transfert, logs et services annexes. Google recommande d’associer l’optimisation des coûts à la performance, à la fiabilité et aux besoins métier, plutôt que de réduire une ressource sans mesurer l’effet.
Tester les scénarios avant production
Créez une charge représentative sur un environnement isolé et observez le temps de lancement, la répartition des requêtes, les erreurs et le retour à la capacité minimale. Vérifiez la gestion des sessions, des connexions à la base et des fichiers temporaires. Un test de montée en charge doit aussi confirmer que les alertes arrivent à la bonne personne.
Répétez le test avec une dépendance lente ou indisponible. Le système doit limiter les appels, préserver les messages qui peuvent être rejoués et fournir une erreur compréhensible. Pour les opérations non idempotentes, définissez un identifiant avant d’autoriser les retries automatiques. Notre article sur l’intégration API et les doublons décrit ce point.
Suivre le coût et la qualité
Chaque variation de capacité devrait apparaître dans les métriques et dans la facturation. Ajoutez des tags ou des comptes séparés pour relier les ressources à une application. Examinez les heures où le maximum est atteint, les périodes où des instances restent inutilisées et les changements de configuration associés.
Révisez les règles après une évolution du trafic ou du code. Une optimisation peut réduire les instances tout en augmentant la latence, ou diminuer le coût d’une API tout en surchargeant un worker. L’objectif reste la capacité nécessaire au niveau de service défini dans vos SLO.
Pour cadrer une migration ou une politique de coûts, consultez notre accompagnement DevOps et cloud au Maroc et le guide sur le FinOps en PME. Sources : Google Cloud, principes d’optimisation des coûts, AWS, auto scaling.