Une base de données managée ne vous dispense pas de savoir administrer une base, elle vous dispense de certaines tâches précises. Confondre les deux conduit à la panne la plus banale du cloud : une équipe qui découvre, le jour où elle en a besoin, que personne n'a jamais testé la restauration. Cette page explique ce que le fournisseur prend en charge, ce qui reste à vous, comment choisir entre les familles de services de données, et ce que la haute disponibilité coûte réellement.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Décider entre un service managé et une base que vous installez vous-même.
- Choisir la bonne famille : relationnel, NoSQL, cache, file d'attente, flux.
- Distinguer réplication et sauvegarde, deux choses qui ne protègent pas du même risque.
- Estimer ce que coûte réellement une base hautement disponible.
- Éviter le piège de la restauration jamais testée.
Managé ou auto-géré : ce que la ligne déplace
Section intitulée « Managé ou auto-géré : ce que la ligne déplace »Un service managé reprend l'exploitation du moteur, pas la responsabilité de vos données. Voici la répartition réelle, celle qui compte quand quelque chose tourne mal.
| Tâche | Base managée | Base que vous installez |
|---|---|---|
| Installer et configurer le moteur | fournisseur | vous |
| Appliquer les correctifs de sécurité | fournisseur, sur une fenêtre qu'il impose | vous, quand vous voulez |
| Sauvegarder automatiquement | fournisseur | vous |
| Vérifier que la restauration fonctionne | vous | vous |
| Concevoir le schéma et les index | vous | vous |
| Régler les paramètres du moteur | vous, dans les limites autorisées | vous, sans limite |
| Choisir la stratégie de réplication | vous | vous |
Les deux lignes en gras sont celles qu'on oublie. Le fournisseur garantit qu'une sauvegarde a été prise, pas qu'elle est exploitable pour votre cas : c'est à vous de restaurer périodiquement dans un environnement de test et de vérifier que les données sont là.
Le managé apporte un vrai gain quand votre équipe n'a pas d'administrateur de bases, et il impose deux contraintes qu'il faut accepter les yeux ouverts : les fenêtres de maintenance décidées par le fournisseur, et l'accès limité au moteur, sans compte super-utilisateur ni extension arbitraire.
Cinq familles, cinq questions
Section intitulée « Cinq familles, cinq questions »Chaque famille de service de données répond à une question différente, et les mélanger produit des architectures qui fonctionnent mal sans qu'on sache pourquoi.
| Famille | La question | Exemples de moteurs |
|---|---|---|
| Relationnel | Mes données ont-elles des relations et des règles à garantir ? | PostgreSQL, MySQL |
| NoSQL documentaire | Ai-je beaucoup d'objets peu structurés, lus par identifiant ? | MongoDB, DynamoDB |
| Cache | Puis-je éviter de recalculer ou de relire la même chose ? | Redis, Valkey, Memcached |
| File d'attente | Dois-je découpler un producteur d'un consommateur ? | RabbitMQ, SQS |
| Flux d'événements | Dois-je rejouer l'historique, ou servir plusieurs consommateurs ? | Kafka, Kinesis |
Le relationnel reste le bon choix par défaut, et ce conseil n'est pas conservateur. Une base relationnelle gère les transactions, garantit la cohérence, et supporte des volumes très supérieurs à ce que la plupart des projets atteindront. Choisissez autre chose quand vous savez précisément pourquoi, pas par anticipation d'une échelle hypothétique.
La différence entre une file et un flux mérite d'être claire, car elles se ressemblent. Dans une file, un message consommé disparaît : un seul destinataire le traite. Dans un flux, les messages restent lisibles pendant une durée de rétention, et plusieurs consommateurs indépendants avancent chacun à leur rythme. Si vous devez rejouer l'historique après une correction de bogue, il vous faut un flux.
Le cache, et les deux difficultés qu'il apporte
Section intitulée « Le cache, et les deux difficultés qu'il apporte »Un cache résout un problème de performance et en crée deux autres, qu'il vaut mieux connaître avant de l'ajouter.
L'invalidation. Une donnée mise en cache devient fausse dès que la source change. Décider quand la jeter est la partie difficile, et il n'existe pas de réponse générale : une durée de vie courte simplifie tout au prix de moins de gains, une durée longue oblige à invalider explicitement à chaque écriture.
La panne du cache. Si votre application ne fonctionne plus quand le cache est vide, ce n'est plus un cache mais une base de données, et elle n'a ni les garanties ni les sauvegardes d'une base. Testez le comportement à froid : après un redémarrage du cache, votre application doit ralentir, pas tomber.
Un usage particulièrement rentable, et souvent négligé : stocker les sessions utilisateur dans un cache partagé plutôt qu'en mémoire du serveur. C'est ce qui rend l'application sans état, donc réellement répartissable, comme l'explique la leçon sur la répartition de charge.
Réplication et sauvegarde ne protègent pas du même risque
Section intitulée « Réplication et sauvegarde ne protègent pas du même risque »C'est la confusion la plus coûteuse de tout ce chapitre. Les deux mécanismes sont utiles, ils ne se remplacent pas. Le vocabulaire complet de ce cursus, qui distingue haute disponibilité, réplication, instantané, sauvegarde, restauration à un instant donné, archive et reprise après sinistre, est posé dans résilience, haute disponibilité et reprise.
| Réplication | Sauvegarde | |
|---|---|---|
| Protège de | la panne d'un serveur ou d'une zone | l'erreur humaine et la corruption |
| Délai de retour | secondes à minutes | minutes à heures |
Face à un DROP TABLE | inutile, la suppression est répliquée aussitôt | c'est la seule protection |
| Face à un rançongiciel | inutile, le chiffrement se réplique | utile, si les sauvegardes sont hors de portée |
Une réplique n'est pas une sauvegarde. Tout ce que vous faites à la base principale, y compris une suppression accidentelle, arrive sur la réplique en quelques secondes. Il faut donc les deux : la réplication pour la disponibilité, la sauvegarde pour l'erreur.
La restauration à un instant donné, souvent appelée PITR, est la fonction qui compte vraiment : elle permet de revenir à l'état d'avant l'incident, à la minute près. Vérifiez qu'elle est activée, et surtout quelle fenêtre elle couvre : sept jours par défaut chez beaucoup de fournisseurs, ce qui est court si personne ne s'aperçoit du problème avant la deuxième semaine.
Ce que la haute disponibilité coûte
Section intitulée « Ce que la haute disponibilité coûte »Une base hautement disponible coûte environ le double d'une base simple, et c'est logique : vous payez une seconde instance qui ne sert qu'à attendre.
Les postes à anticiper, au-delà du calcul :
- Le stockage est dupliqué, donc facturé deux fois.
- Le trafic entre zones est facturé chez plusieurs fournisseurs, et une réplication synchrone en génère en permanence.
- Les sauvegardes au-delà du quota inclus se facturent au gigaoctet, et leur volume croît avec la rétention.
Cela ne veut pas dire qu'il faut y renoncer, mais qu'il faut choisir où la mettre. Une base de production porte une haute disponibilité ; une base de recette n'en a pas besoin, et la lui donner double une facture sans réduire aucun risque réel.
-
Écrivez le RPO et le RTO acceptables, en discutant avec ceux qui subiront la panne. « Combien de minutes de données pouvons-nous perdre ? » et « combien de temps peut-on rester arrêtés ? ».
-
Déduisez-en l'architecture, plutôt que l'inverse. Un RPO de quelques minutes se satisfait de sauvegardes fréquentes ; un RPO proche de zéro impose une réplication synchrone, plus chère et plus contraignante.
-
Mesurez ce que vous obtenez vraiment, par une restauration chronométrée. C'est le seul chiffre qui vaut, et il diffère presque toujours de celui du contrat.
Réplica de lecture ou réplica de secours ?
Section intitulée « Réplica de lecture ou réplica de secours ? »Les deux s'appellent « réplica », ils se créent au même endroit dans la console, et ils ne servent pas du tout au même usage. Les confondre conduit à croire qu'on est protégé alors qu'on a seulement soulagé les lectures, ce qui est la mauvaise surprise classique le jour de la panne.
| Réplica de lecture | Réplica de secours | |
|---|---|---|
| Ce qu'il apporte | de la capacité de lecture supplémentaire | la continuité de service si l'instance principale tombe |
| Mode de réplication | asynchrone, avec un retard variable | synchrone chez la plupart des fournisseurs |
| Peut-on l'interroger ? | oui, c'est son objet | souvent non : il attend, sans servir de trafic |
| Ce qu'il coûte | le prix d'une instance de plus | le prix d'une instance de plus, sans capacité en échange |
| Sa promotion en cas de panne | possible, mais elle perd les écritures non répliquées | automatique et sans perte |
Le retard du réplica de lecture est le point à comprendre. Il se compte habituellement en millisecondes, il grimpe à plusieurs secondes sous forte écriture, et il est invisible depuis l'application. Une donnée écrite puis relue immédiatement sur le réplica peut être absente : c'est un cas concret de cohérence à terme, et le symptôme perçu est un formulaire enregistré qui « n'a pas marché ».
La règle d'usage tient en une phrase : envoyez sur un réplica de lecture ce qui tolère de voir un état légèrement ancien, rapports, tableaux de bord, recherches, exports. Gardez sur l'instance principale tout ce qu'un utilisateur relit juste après l'avoir écrit.
Que se passe-t-il vraiment pendant une bascule ?
Section intitulée « Que se passe-t-il vraiment pendant une bascule ? »Une bascule automatique ne rend pas la panne transparente : elle la raccourcit. Pendant quelques dizaines de secondes à quelques minutes, la base n'accepte rien, les connexions ouvertes sont rompues, et votre application voit des erreurs. Ce qui distingue une architecture solide n'est pas d'éviter ce moment, c'est de le traverser sans intervention humaine.
Le mécanisme est presque toujours le même : le fournisseur bascule le nom de domaine de la base vers la nouvelle instance principale. Vous continuez à utiliser la même adresse, elle pointe désormais ailleurs.
Pourquoi la base refuse-t-elle de nouvelles connexions ?
Section intitulée « Pourquoi la base refuse-t-elle de nouvelles connexions ? »Le nombre de connexions simultanées d'une base managée est plafonné, et ce plafond dépend de la taille de l'instance. C'est une limite que l'on rencontre bien avant de saturer le processeur, et son symptôme ressemble à une panne générale : l'application ne se connecte plus, alors que la base est peu chargée.
Deux évolutions modernes rendent ce mur beaucoup plus proche qu'avant :
- La mise à l'échelle automatique. Chaque machine applicative ajoutée ouvre son propre lot de connexions. Vingt machines avec un pool de vingt connexions en réclament quatre cents, et le plafond d'une petite instance est souvent inférieur.
- Les fonctions serverless. Chaque exécution concurrente peut ouvrir sa propre connexion, sans mutualisation possible entre elles. Une centaine d'exécutions simultanées épuise le plafond en quelques secondes.
La réponse n'est pas de grossir l'instance, mais d'intercaler un répartiteur de connexions. Ce composant maintient un petit nombre de connexions réellement ouvertes vers la base et les prête aux clients. Les fournisseurs proposent leur version managée, et les projets libres équivalents existent depuis longtemps pour PostgreSQL et MySQL. Grossir l'instance déplace le mur de quelques centaines de connexions et multiplie la facture ; le répartiteur règle le problème pour une fraction du prix.
Comment joindre une base managée sans passer par Internet ?
Section intitulée « Comment joindre une base managée sans passer par Internet ? »Une base managée est joignable par un nom de domaine public, et c'est la configuration par défaut à corriger. Le service écoute derrière un pare-feu qui n'autorise que vos adresses, mais le chemin réseau, lui, passe par l'extérieur : votre trafic sort, transite, revient, et se facture au passage.
Deux réglages complémentaires ferment cette porte :
- Désactiver l'accessibilité publique de l'instance, de sorte qu'elle ne dispose que d'une adresse dans votre réseau privé. C'est le réglage le plus important, et il se fait à la création : le changer ensuite impose parfois de recréer l'instance.
- Passer par un point de terminaison privé pour les services qui n'ont pas d'adresse dans votre réseau, ce qui supprime au passage le traitement facturé par la passerelle NAT. Le mécanisme et son effet sur la facture sont détaillés dans exposer une application.
Vérifiez le résultat plutôt que de le supposer. Depuis une machine extérieure à votre réseau, une tentative de connexion sur le port de la base doit expirer, pas être refusée : une expiration prouve que rien ne route jusqu'à elle, un refus prouve seulement qu'un pare-feu a dit non, ce qui est un filet nettement plus mince.
À retenir
Section intitulée « À retenir »- Réplica de lecture et réplica de secours ne protègent pas du même risque. Le premier ajoute de la capacité, le second de la continuité, et l'un ne remplace jamais l'autre.
- Un réplica de lecture est en retard, parfois de plusieurs secondes : n'y envoyez rien qu'un utilisateur vient d'écrire.
- Une bascule raccourcit la panne, elle ne la supprime pas. Et une bascule jamais déclenchée volontairement reste une hypothèse.
- L'application qui reste en panne après une bascule a mis en cache le nom de domaine. C'est la cause la plus fréquente, et la plus déroutante.
- Le plafond de connexions arrive avant la saturation du processeur. Un répartiteur de connexions règle le problème, grossir l'instance ne fait que le déplacer.
- Une base managée est publique par défaut : coupez l'accessibilité publique à la création, et vérifiez par une expiration de connexion, pas par un refus.
- Le managé reprend l'exploitation, pas la responsabilité de vos données. Vérifier la restauration reste à vous, dans les deux cas.
- Vérifiez la liste des extensions autorisées avant de concevoir : c'est le point de blocage le plus fréquent d'une migration vers du managé.
- Le relationnel est le bon choix par défaut. Changez quand vous savez pourquoi, pas par anticipation.
- Une file distribue un message à un consommateur, un flux le garde pour plusieurs et permet de rejouer l'histoire.
- Si votre application tombe quand le cache est vide, ce n'est plus un cache mais une base sans garanties.
- Une réplique n'est pas une sauvegarde : un
DROP TABLEse réplique en quelques secondes. - Vérifiez la fenêtre de restauration à un instant donné, souvent sept jours seulement.
- Une sauvegarde non testée est une hypothèse. Restaurez chaque trimestre, chronomètre en main.
- La haute disponibilité double environ la facture : réservez-la à ce qui doit vraiment survivre.