Mise à l'échelle automatique de PostgreSQL et MariaDB : comment la mise à l'échelle « full-stack » comble le fossé en matière de bases de données

Quand les fournisseurs de plateformes parlent d’auto-scaling, ils font généralement référence à une seule chose : l’auto-scaling des applications, c’est-à-dire l’ajout ou la suppression d’instances web en fonction du trafic. Le principe est bien connu : tu définis un indicateur, tu fixes un seuil, et tu laisses la plateforme s’en charger.

La plupart des plateformes traitent encore la capacité des bases de données comme un problème à part, généralement géré manuellement. Les équipes prévoient soit une capacité pour l’heure la plus chargée de la pire journée, soit des plans de mise à niveau selon un calendrier, soit elles mettent en place leur propre logique de mise à l’échelle sur Kubernetes ou RDS. Le résultat est le même dans tous les cas : une capacité qui ne correspond pas à la demande et une charge opérationnelle qui ne se justifie pas.

Ce que l’« auto-scaling full-stack » permet réellement de faire évoluer

Cette expression est souvent utilisée à tort et à travers. Voici comment on l’utilise chez Upsun :

Mise à l’échelle automatique « full-stack » : chaque couche de ta stack s’adapte automatiquement à la demande, de manière native, sur une seule plateforme : applications, workers et bases de données gérées.

Concrètement, trois éléments s’adaptent horizontalement sur la même primitive Upsun :

• Les applications : ta couche web.
• Les workers : les processus en arrière-plan et asynchrones, comme les paiements, le transcodage vidéo, l’inférence IA et les tâches batch planifiées.
• Bases de données gérées : répliques en lecture seule de PostgreSQL et MariaDB

Ces trois éléments réagissent aux mêmes signaux : l’utilisation moyenne du processeur et de la mémoire sur l’ensemble des instances en cours d’exécution. Ils suivent tous la même logique : ajouter de la capacité lorsque l’utilisation reste au-dessus d’un seuil, et en retirer lorsqu’elle reste en dessous. Ils font tous partie du même projet, sur la même facture, avec un modèle conceptuel unique.

Comment fonctionne l’autoscaling des répliques de lecture

Sur Upsun, l’autoscaling est horizontal : il ajoute ou supprime des instances entières d’un service. Pour les bases de données, ça signifie faire évoluer le pool de répliques en lecture de ton service PostgreSQL ou MariaDB principal. Tu configures une réplique de référence une seule fois ; l’autoscaling ajuste ensuite la taille du pool en fonction de la charge.

La plateforme surveille l’utilisation moyenne du processeur et de la mémoire de ton pool de répliques en cours d’exécution. Lorsque l’utilisation reste supérieure à ton seuil d’augmentation pendant la période d’évaluation, une réplique supplémentaire rejoint le cluster. Lorsqu’elle reste inférieure à ton seuil de réduction pendant la période d’évaluation, une réplique supplémentaire est supprimée. Une période de pause entre les actions empêche le pool d’osciller à la hausse et à la baisse lors de pics de charge de courte durée.

Les valeurs par défaut te donnent une idée de la configuration :

• Seuil d’augmentation : 80 % du CPU pendant 5 minutes
• Seuil de réduction : 20 % du CPU pendant 5 minutes
• Période de latence : 5 minutes entre chaque action de mise à l’échelle
• Limites d'instances : de 1 à 8 par environnement, en fonction de la région

Tu peux utiliser le CPU, la mémoire ou les deux comme déclencheurs, et tu peux ajuster chaque seuil par environnement, y compris en développement et en préproduction, pas seulement en production.

Deux détails techniques sont importants pour avoir des attentes réalistes :

1. La réplication est asynchrone. Les écritures sont d’abord enregistrées sur le serveur principal, puis transmises aux répliques. Les délais sont généralement de quelques millisecondes, mais si ton application a besoin d’une cohérence « lecture après écriture » sur des données critiques et ne peut pas tolérer ce décalage, redirige ces requêtes vers le serveur principal.
2. Les répliques sont strictement en lecture seule. Les tentatives d’écriture sur une réplique renvoient une erreur SQL. Cette règle est appliquée au niveau du moteur, et non dans la logique de l’application.

C’est à ton code d’application de diriger les requêtes de lecture vers la réplique. La chaîne de connexion est accessible via PLATFORM_RELATIONSHIPS sous le nom de la relation de réplique (par exemple, database-readonly). La plupart des ORM et des bibliothèques de bases de données prennent en charge ce modèle avec une connexion de lecture distincte. Il s’agit d’une modification du code, pas d’une modification de l’infrastructure.

Pourquoi le mot « natif » est-il si important ?

Il existe aujourd’hui trois autres façons d’obtenir une mise à l’échelle automatique des bases de données. Chacune est une solution viable, mais chacune comporte des compromis qu’Upsun cherche explicitement à éviter.

1. Bases de données serverless tierces : certaines plateformes redirigent les clients vers un moteur de base de données distinct. Netlify, par exemple, propose son produit de base de données sur Neon. Ça fonctionne, mais ça place tes données chez un autre fournisseur, avec un SLA différent, une facture différente et souvent un appariement de régions différent de celui de ton application.
2. Faire soi-même sur Kubernetes : tu peux exécuter un opérateur PostgreSQL avec HPA, configurer des adaptateurs de métriques personnalisés et obtenir ainsi la mise à l’échelle automatique. Tu seras également responsable des mises à jour de l’opérateur, de la topologie de haute disponibilité, des tests de basculement et de la rotation des astreintes pour tout ça. 
3. Mise à l’échelle manuelle chez les fournisseurs de cloud : sur AWS, tu peux configurer le HPA pour ton application, définir des répliques de lecture RDS avec une mise à l’échelle planifiée ou déclenchée par des alarmes, configurer les métriques CloudWatch et gérer l’ensemble. Même résultat fonctionnel, mais une charge opérationnelle nettement plus importante, et c’est toi qui gères chaque élément de l’intégration.

La mise à l’échelle automatique des répliques de lecture d’Upsun s’exécute directement sur les services PostgreSQL et MariaDB gérés qui alimentent déjà ton projet. Pas besoin de moteur tiers, de couche supplémentaire ni de configuration.

Quand la mise à l’échelle automatique des répliques de lecture est la solution idéale

Cette fonctionnalité a une portée délibérément limitée. Elle est conçue pour les charges de travail où l’ajout de capacité de lecture permet réellement de soulager la pression sur la base de données.

Elle convient particulièrement :

• Les applications de production à forte intensité de lecture, notamment les pages de listes, les tableaux de bord et les interfaces utilisateur basées sur la recherche
• Les tâches de reporting et d’analyse qui exploitent les données de production
• Les tâches en arrière-plan qui interrogent souvent la base mais y écrivent rarement
• Le trafic lié à des campagnes ou à des événements, comme les ventes flash, les mises en vente de billets, les périodes d’inscription et les lancements de contenu
• Les applications fonctionnant sur PostgreSQL ou MariaDB gérés via Upsun Flex

Ce n'est pas la solution idéale pour :

• Les charges de travail à forte intensité d’écriture : si ton goulot d’étranglement réside dans le débit d’écriture sur la base de données principale, ajouter des répliques de lecture ne servira à rien. La scalabilité en écriture est un tout autre problème, généralement résolu par le sharding, le partitionnement ou une architecture de stockage fondamentalement différente. Cette fonctionnalité ne vise pas à résoudre ça.
• Les charges de travail prévisibles et à faible variance : un tableau de bord interne à l’utilisation stable et modérée est souvent mieux géré avec un nombre d’instances fixe et des ressources verticales optimisées. L’auto-scaling apporte une réelle valeur ajoutée lorsque la demande varie réellement.
   

Comment ça marche en pratique

Prenons l’exemple d’une application de e-commerce sur une base de données PostgreSQL gérée. Un jour de semaine normal, une ou deux répliques gèrent la charge de lecture, avec une utilisation du processeur (CPU) oscillant entre 30 et 40 %. 

Le vendredi soir, une campagne est lancée. Voici ce qui se passe ensuite :

• Le trafic est multiplié par cinq. Alors que les répliques absorbent la charge de lecture supplémentaire, l'utilisation du processeur dépasse les 80 %.
• Upsun ajoute une réplique. L’utilisation du processeur se stabilise brièvement, mais le trafic continue d’augmenter.
• Un autre seuil est franchi. Une autre réplique est ajoutée. Au pic, le pool est passé de deux répliques à six.
• Pas de redémarrage, pas de basculement. Les pools de connexion vers les répliques existantes restent actifs. De nouvelles répliques rejoignent le cluster et commencent à traiter le trafic. Les pages produits, la recherche et le tunnel d’achat restent dans les limites de latence attendues.
• Pendant la nuit, le trafic redescend. L’utilisation du processeur passe sous la barre des 20 %. Upsun supprime les répliques une par une, en respectant des délais de refroidissement entre chaque, jusqu’à ce que le pool revienne à son niveau de base.

La facture suivante reflète la capacité réellement utilisée pendant le pic, et non la capacité prévue à l’avance pour y faire face. Le rappel de calendrier, l’augmentation manuelle, le rappel de retour à la capacité initiale… tout ça, c’est fini.

Pour commencer

La mise en place de l’auto-scaling des répliques de lecture nécessite deux niveaux de configuration :

1. Définis le service de répliques en YAML

Dans ton fichier .upsun/config.yaml :

• Ajoute un service postgres-replica ou mariadb-replica
• Définis un point de terminaison de réplication sur le serveur principal
• Ajoute une relation « database-readonly » à ton application

Les documentations de PostgreSQL et MariaDB expliquent la configuration en détail.

2. Active l'auto-scaling pour la réplique

Active la mise à l'échelle automatique pour le service de réplique depuis :

• Console : accède à l'onglet « Configurer les ressources » de l'environnement.
• CLI Upsun : exécute la commande autoscaling:set :
  upsun autoscaling:set --service db-replica1 --metric cpu

Les paramètres correspondent à ceux de l'auto-scaling des applications et des workers :

• Seuils d'augmentation et de réduction.
• Période d'évaluation.
• Fenêtre de temps de pause.
• Limites minimales et maximales d'instances.

Des applications, des workers et des bases de données gérées sur une seule plateforme, avec une seule entité, sur une seule facture. C'est ça, la mise à l'échelle automatique « full-stack ».

Pour en savoir plus

Si tu n’as pas encore configuré de réplique de lecture, ces ressources te proposent un guide pas à pas pour définir le service. Plus d’infos sur la configuration, le réglage et les concepts associés :

Si tu n’as pas encore configuré de réplique en lecture, ces ressources te proposent un guide pas à pas pour définir le service. Pour en savoir plus sur la configuration, l’optimisation et les concepts associés :

• Présentation de l'auto-scaling 
• Réplication en lecture seule de PostgreSQL
• Réplication en lecture seule de MariaDB
• Configuration des ressources