Données managées : bases, caches et files dans le cloud

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 leçon explique ce que le fournisseur prend en charge, ce qui reste à vous, et comment choisir entre les familles de services de données. Elle s'adresse à des personnes qui connaissent une base de données et doivent choisir où et comment l'exploiter ; la protection de la base (réplication, sauvegarde, bascule) et son raccordement privé ont chacun leur leçon, citées ci-dessous.

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.
• Éviter le piège de la restauration jamais testée.
• Anticiper les deux difficultés d'un cache : l'invalidation et sa panne.

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

Glissez pour voir

La ligne en gras est celle 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.

La question à poser avant de choisir le managé

« De quelles extensions ou de quels réglages mon application a-t-elle besoin ? »

C'est le point de blocage le plus fréquent, et il se découvre tard. Une base PostgreSQL managée n'autorise que la liste d'extensions que le fournisseur a validée. Si votre application en exige une qui n'y figure pas, la migration s'arrête là.

Vérifiez cette liste avant de concevoir, pas après. Elle est publiée par chaque fournisseur et évolue lentement.

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

Glissez pour voir

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

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, une application qui s'en sert pour des données recalculables doit ralentir, pas tomber. Les sessions utilisateur font exception, comme le montre le paragraphe suivant.

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. Ce choix a un prix : le cache devient alors le seul endroit où vivent les sessions, et un cache vidé déconnecte tous les utilisateurs, sans que l'application « tombe ». C'est un compromis assumé, qui se traite en connaissance de cause : une session perdue oblige à se reconnecter, ce qui est acceptable pour beaucoup d'applications, et ne l'est pas pour un paiement en cours. Si la perte est inacceptable, la session va dans une base, pas dans un cache.

Où se traitent la réplication, la sauvegarde et le raccordement privé ?

La protection d'une base et son raccordement au réseau se traitent dans deux autres leçons du module. La leçon Répliquer, sauvegarder et basculer une base explique pourquoi un réplica n'est pas une sauvegarde, ce que coûte la haute disponibilité, quel réplica choisir et ce que fait une bascule. La leçon Limiter les connexions et joindre une base en privé traite le plafond de connexions d'une base managée et son accès sans passer par Internet. Pour le geste sur une base auto-gérée, la leçon Sauvegarder et restaurer PostgreSQL apprend pg_dump, pg_restore et le contrôle d'une restauration.

À retenir

• 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 ; seules les sessions font exception, au prix d'une reconnexion des utilisateurs.
• Un cache résout un problème de performance et en crée deux : l'invalidation et la panne.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →