
En bref
|
L'auto-scaling des applications existe depuis des années. Celui des bases de données a pris du retard. Aujourd’hui, ça change chez Upsun.
Les répliques de lecture gérées de PostgreSQL et MariaDB s’adaptent désormais automatiquement, rejoignant ainsi l’auto-scaling des workers en production depuis mars 2026. Les applications, les workers et les bases de données gérées s’adaptent tous automatiquement : les répliques de lecture sont saturées en premier, les pools de connexion atteignent leur maximum, le tout sur une seule plateforme – de manière native, sans moteur de base de données tiers ni couche Kubernetes à gérer.
Trois casse-têtes opérationnels viennent de disparaître. Voici ce qui a changé.
L’application résiste généralement au pic de trafic. C’est au niveau de la base de données que ça casse. Les répliques de lecture sont les premières à saturer, les requêtes s’accumulent en file d’attente, et quelqu’un se fait appeler.
À partir d’aujourd’hui, Upsun ajuste automatiquement la capacité des répliques de lecture en fonction de l’utilisation du CPU et de la mémoire. Lorsque la charge de travail sur les répliques augmente, d’autres sont ajoutées ; lorsqu’elle diminue, de la capacité est libérée. La mise à l’échelle est dynamique : pas de redémarrage, pas de basculement, pas de fenêtre de mise à niveau planifiée.
Résultat : les pics de trafic liés aux lancements, aux campagnes ou aux événements saisonniers ne se transforment plus en incidents de base de données.
Le rappel dans l’agenda avant un événement à fort trafic pour « augmenter manuellement la capacité des workers » — et le rappel suivant pour « réduire manuellement la capacité deux semaines plus tard » que personne ne suivait — tout ça, c’est fini.
La mise à l’échelle automatique des workers est opérationnelle depuis mars 2026, en fonction de l’utilisation du CPU et de la mémoire. Le traitement des paiements, le transcodage vidéo, l’inférence IA, les tâches batch planifiées — tout ce qui est asynchrone — ne se bloquent plus lors des pics de trafic. La mise à jour d’aujourd’hui étend cette fonctionnalité aux bases de données gérées.
Résultat : plus besoin de passer du temps à configurer manuellement les outils de mise à l’échelle. Les opérations de capacité de routine ne sont plus des rendez-vous à noter dans l’agenda.
La plupart des équipes surdimensionnent leur couche de base de données — en la dimensionnant pour la pire heure de pointe de la pire journée de pointe — et paient cette capacité 24 heures sur 24. Pour les charges de travail cycliques, ça représente une part importante de capacité qui reste inutilisée la plupart du temps, et qui apparaît sur chaque facture.
Upsun Autoscaling réduit la capacité aussi bien qu’il l’augmente. La capacité est supprimée lorsque le trafic baisse.
Sur la facture : les dépenses correspondent à l’utilisation réelle.
Upsun surveille l’utilisation du processeur et de la mémoire dans les pools de travailleurs et les bases de données gérées — des indicateurs qui reflètent directement la pression sur les ressources. Quand les charges de travail font grimper l’utilisation du processeur ou de la mémoire, Upsun ajoute de la capacité ; quand la charge baisse, la capacité est libérée. Les répliques rejoignent et quittent le cluster en cours d’exécution sans redémarrage ni basculement.
L’autoscaling ne doit pas s’arrêter à la couche applicative. Grâce à l’autoscaling des répliques de lecture de bases de données, Upsun fait désormais évoluer ensemble les applications, les workers et les bases de données gérées — de manière native, sur une seule plateforme. Pas de moteur de base de données tiers à intégrer. Pas de couche Kubernetes à gérer. Une infrastructure qui évolue comme un système, et non comme un ensemble de composants déconnectés.