Base de données intégrée ou externe ? Comment choisir une architecture de base de données pour une application auto-hébergée

Commencez par le périmètre opérationnel, et non par l’option qui semble la plus sophistiquée

Pour une application basée sur Docker, une base de données intégrée signifie généralement que l’application et le service de base de données pris en charge sont définis dans la même application Compose. Ils peuvent s’exécuter dans des conteneurs distincts, tandis que la base de données conserve ses données dans un volume Docker. Une base de données externe est un service de base de données exploité séparément, auquel l’application accède au moyen d’une connexion configurée.

Aucune de ces organisations n’est, par nature, plus fiable, plus sécurisée ou plus professionnelle que l’autre. La question utile est la suivante : quelle équipe possède l’intégralité du périmètre de service, et cette équipe peut-elle bien exploiter ses dépendances, ses changements et ses procédures de restauration ?

Une base de données intégrée peut être la conception présentant le moins de risques lorsque l’application la prend officiellement en charge et qu’une petite équipe a besoin d’une stack contenue avec un cycle de vie clair. Une base de données distincte peut être appropriée lorsque la documentation de l’application l’exige, lorsque des charges de travail approuvées ont réellement besoin d’un service partagé, ou lorsqu’une équipe base de données ou infrastructure dispose déjà de procédures d’exploitation définies pour ce service.

• Choisissez le plus petit périmètre opérationnel qui répond aux exigences documentées de l’application.
• Ne considérez pas « externe » comme un synonyme de résilient, ni « intégrée » comme un synonyme de jetable.
• Prenez la décision pour chaque application et pour chaque modèle de déploiement documenté, plutôt que d’adopter une règle unique pour toutes les charges de travail.

Vérifiez le modèle de déploiement pris en charge par l’application avant de concevoir l’infrastructure

La documentation de l’application elle-même fait autorité pour déterminer si elle prend en charge une base de données intégrée, une base de données externe, ou les deux. Effectuez ce travail avant de provisionner un hôte ou de migrer des données de production. Une chaîne de connexion techniquement possible ne prouve pas qu’un modèle de déploiement est pris en charge lors des mises à niveau, des migrations ou de la restauration après incident.

Vérifiez le moteur de base de données documenté et les exigences de version. Vérifiez ensuite précisément comment l’application reçoit les paramètres de connexion, comment elle exécute les migrations de schéma, si elle attend une extension de base de données ou une étape d’initialisation particulière, et si elle documente des hypothèses de haute disponibilité ou de sauvegarde.

Le comportement au démarrage est également important. Dans Compose, le fait qu’une dépendance ait démarré ne signifie pas à lui seul qu’elle est prête à accepter des connexions à la base de données. Docker indique que Compose attend normalement qu’un conteneur de dépendance soit en cours d’exécution, et non qu’il soit prêt. Lorsque le déploiement de l’application l’exige, un contrôle de santé de la base de données et une condition de dépendance service_healthy peuvent empêcher l’application de tenter sa connexion initiale trop tôt.

• Moteur de base de données pris en charge, version majeure et éventuelles extensions requises.
• Paramètres de connexion pris en charge, et indication que TLS, les certificats ou les règles réseau sont des exigences documentées.
• Commande de migration, moment de la migration, comportement en cas d’échec et recommandations de retour en arrière.
• Chemin de mise à niveau pris en charge pour l’application comme pour la base de données.
• Recommandations de sauvegarde, de restauration et de haute disponibilité publiées par l’éditeur de l’application.
• Séquençage du démarrage et attentes relatives aux contrôles de santé.

Cartographiez l’ensemble du chemin de données : la base de données relationnelle est rarement tout le système

Avant de sélectionner une architecture de base de données, identifiez chaque composant qui conserve un état persistant ou critique pour la sécurité. La base de données relationnelle peut faire autorité pour les enregistrements de l’application, mais cette même application peut aussi dépendre du stockage de fichiers, du stockage d’objets, d’un cache, d’un index de recherche, d’une file d’attente, de fichiers de configuration et de secrets. Chacun peut avoir un modèle différent de persistance, de sauvegarde et de restauration.

Docker Compose distingue des ressources telles que les services, les volumes, les configurations et les secrets. Cette distinction est importante sur le plan opérationnel. Un volume Docker nommé peut survivre à la suppression d’un conteneur, ce qui sépare le cycle de vie d’un conteneur de base de données de celui de ses données. Cela n’établit toutefois pas qu’une simple copie d’un répertoire de données de base de données actif constitue une sauvegarde cohérente.

Établissez un inventaire qui identifie la source faisant autorité pour chaque type de données. C’est le fondement d’un plan de restauration, d’un plan de migration et d’une réponse précise à la question : « Que perdons-nous si ce composant est indisponible ou restauré à partir d’un point antérieur ? »

• Base de données relationnelle : enregistrements transactionnels de l’application, identités, paramètres ou métadonnées, lorsque cela est documenté.
• Stockage de fichiers ou d’objets : téléversements, pièces jointes, exports générés, médias ou documents, lorsqu’ils sont utilisés.
• Cache : déterminez s’il peut être reconstruit sans risque ou s’il contient un état qui affecte la restauration.
• Index de recherche ou magasin vectoriel : déterminez s’il fait autorité ou s’il peut être reconstruit à partir d’une autre source.
• État de file d’attente ou de flux de travail : identifiez si les travaux en attente doivent être préservés et comment ils sont restaurés.
• Configuration de l’application et secrets : conservez la configuration nécessaire pour reconnecter les composants et déchiffrer les données protégées ou y accéder.

Quand une base de données intégrée est un choix judicieux

Une base de données intégrée est souvent appropriée lorsqu’il s’agit d’un déploiement d’application officiellement documenté, que la charge de travail a un périmètre restreint et que la même équipe peut exploiter l’application et la base de données comme un seul service. Elle limite le nombre de systèmes indépendants qui doivent être configurés, surveillés, modifiés et restaurés ensemble.

Ce choix ne signifie pas qu’il faut traiter la base de données comme un composant secondaire sans importance. Elle a toujours besoin d’un stockage persistant, d’identifiants, d’une couverture de sauvegarde, d’une surveillance de la croissance du stockage, d’un chemin de mise à niveau documenté et de tests de restauration. Son avantage est un périmètre de responsabilité plus simple, et non l’absence d’opérations sur la base de données.

Pour une petite équipe technique, cela peut être plus simple à appréhender qu’un service distant impliquant des routes réseau distinctes, des règles de pare-feu, la gestion des comptes et des fenêtres de changement. Gardez le périmètre clair : la stack applicative et sa base de données sont déployées, mises à jour et restaurées comme un système coordonné.

• L’éditeur documente le déploiement intégré comme étant pris en charge.
• Une seule équipe possède le cycle de vie de l’application et de la base de données.
• Un service de base de données dédié n’est pas exigé par la politique, l’architecture ou les recommandations de l’éditeur.
• L’équipe peut sauvegarder et restaurer la base de données ainsi que tous les magasins associés faisant autorité.
• La stack dispose d’un modèle clair de stockage persistant au lieu de s’appuyer sur le système de fichiers transitoire du conteneur.

Quand une base de données externe est justifiée

Utilisez une base de données exploitée séparément lorsqu’il existe une exigence concrète, plutôt qu’une préférence pour la séparation. Parmi les raisons valables figurent l’architecture documentée d’une application, une équipe base de données existante avec des responsabilités et des procédures de restauration claires, ou un besoin réel pour plusieurs charges de travail approuvées d’utiliser un service de base de données partagé.

Un service partagé ne doit pas devenir un espace de dépôt informel pour des applications sans lien entre elles. Chaque charge de travail a toujours besoin de rôles de base de données définis, de limites d’accès, d’une coordination de la maintenance et d’une décision de restauration. Partager un moteur ou un cluster ne supprime pas la nécessité d’isoler les identifiants et de décider qui peut effectuer des changements.

Une plateforme de base de données spécialisée ou une équipe d’infrastructure interne peut être mieux adaptée lorsque l’organisation possède déjà les compétences, les contrôles et le modèle de service nécessaires pour l’exploiter. Cette équipe devrait pouvoir indiquer qui gère les accès, les mises à niveau, la vérification des sauvegardes, la restauration, la capacité et la réponse aux incidents. Si ces réponses ne sont pas claires, déplacer la base de données ailleurs peut uniquement déplacer du travail sans responsable.

• L’éditeur de l’application indique qu’une base de données externe est requise ou prise en charge pour le déploiement envisagé.
• Une équipe désignée possède les opérations de base de données et dispose d’une procédure de restauration testée.
• La connectivité réseau, l’authentification et la gestion du pare-feu ont des responsables clairement définis.
• Le besoin d’un service partagé est réel, approuvé et compatible avec une isolation adéquate des accès.
• La maintenance de l’application et de la base de données peut être coordonnée, y compris les migrations de schéma et les mises à niveau de version majeure.

Ne confondez pas séparation et résilience

Une base de données externe introduit une limite de service supplémentaire. L’application dépend alors de l’accessibilité réseau, de la résolution de nom d’hôte, des règles de pare-feu et de routage, des identifiants, des règles d’authentification, de la configuration de l’écouteur de la base de données et du calendrier de maintenance du service externe. Chacune de ces dépendances doit avoir un responsable et un chemin de réponse aux incidents.

Pour PostgreSQL en particulier, l’exposition des connexions TCP/IP est régie par des paramètres tels que listen_addresses, tandis que l’authentification des clients contrôle qui peut se connecter. PostgreSQL utilise également des rôles pour la gestion des privilèges, et l’utilisateur actif de la base de données détermine l’accès aux objets de la base. Ce sont des contrôles utiles, mais ils doivent être conçus et maintenus délibérément.

La séparation peut améliorer l’architecture d’une organisation lorsqu’elle correspond à des capacités établies. Elle peut aussi ajouter de la latence, davantage de coordination de gestion des changements et une surface de défaillance plus étendue. Évaluez l’ensemble du chemin entre le processus applicatif et la base de données, et pas seulement l’hôte de la base de données.

• L’application peut-elle résoudre et atteindre le point de terminaison de la base de données dans les conditions de défaillance attendues ?
• Quels chemins réseau et quelles règles de pare-feu autorisent la connexion ?
• Quel rôle de base de données l’application utilise-t-elle, et de quels privilèges a-t-elle réellement besoin ?
• Comment les identifiants sont-ils fournis, renouvelés et révoqués ?
• Qui approuve les opérations de maintenance susceptibles d’affecter la connectivité de l’application ou la compatibilité du schéma ?
• Que se passe-t-il lorsque la base de données est joignable mais n’est pas prête, est surchargée ou est en cours de récupération ?

Concevez la restauration comme une procédure pour l’ensemble du système

Une sauvegarde n’est utile que si elle peut restaurer le service à un point de restauration convenu. Planifiez la restauration sur l’ensemble du chemin de données : la base de données, les fichiers téléversés ou le stockage d’objets, la configuration de l’application, les secrets ou le matériel de chiffrement, ainsi que le bon ordre de restauration. Une restauration réussie de la base de données seule peut tout de même laisser une application incapable de localiser des fichiers, de s’authentifier auprès de services ou de déchiffrer des données protégées.

Pour PostgreSQL, la planification des sauvegardes exige un choix délibéré entre les sauvegardes logiques, les sauvegardes au niveau du système de fichiers et l’archivage continu. PostgreSQL les documente comme des approches différentes, avec des forces et des faiblesses distinctes. Une sauvegarde logique créée avec pg_dump produit des commandes qui recréent l’état de la base de données capturé au moment où le dump a commencé ; elle n’est pas équivalente à la simple copie d’un volume de conteneur.

Les objectifs de restauration doivent guider le choix technique. Si le point de restauration requis impose une restauration à un instant situé entre des sauvegardes planifiées, cela exige des capacités allant au-delà des dumps logiques ordinaires. La restauration à un point dans le temps de PostgreSQL repose sur une sauvegarde de base complétée par un archivage continu des journaux d’écriture anticipée ; les sorties de pg_dump et pg_dumpall ne peuvent pas être utilisées pour rejouer ces journaux.

Testez les restaurations dans un environnement isolé. Consignez le temps de restauration, le point restauré, les contrôles de validation effectués, les étapes manuelles non résolues et la personne ayant autorisé le résultat. Considérez les preuves issues d’un test de restauration comme plus précieuses qu’une hypothèse fondée sur la réussite signalée par une tâche de sauvegarde.

• Identifiez la source faisant autorité et la méthode de sauvegarde de chaque composant persistant.
• Définissez des objectifs de point de restauration et de temps de restauration que l’équipe peut expliquer et tester.
• Documentez l’ordre de restauration, y compris les bases de données, les fichiers, la configuration et les secrets.
• Vérifiez les identités, rôles et autorisations nécessaires pour restaurer la propriété et les privilèges de la base de données.
• Effectuez périodiquement des tests de restauration et conservez-en les résultats.
• Vérifiez que la validation au niveau de l’application réussit après la restauration, et pas seulement que le service de base de données démarre.

Attribuez les responsabilités avant le lancement en production

L’architecture est incomplète tant que les responsabilités opérationnelles ne sont pas attribuées. Cela s’applique autant aux bases de données intégrées qu’aux bases de données externes. Une base de données peut être techniquement joignable tout en restant opérationnellement risquée, parce que personne n’est responsable des accès privilégiés, de la croissance du stockage, des échecs de migration ou de la vérification des restaurations.

Rendez les responsabilités explicites dans un runbook léger ou un document de responsabilité de service. L’objectif n’est pas la bureaucratie. Il s’agit de garantir qu’une migration échouée, un identifiant expiré, un volume qui croît ou une demande de restauration disposent d’un chemin de réponse connu.

Les mises à niveau de bases de données méritent une attention particulière. PostgreSQL documente des méthodes explicites de mise à niveau pour les versions majeures, notamment des approches par exportation et restauration. Une sauvegarde au niveau du système de fichiers ne remplace pas cette méthode documentée de mise à niveau par exportation et restauration. Coordonnez les versions de base de données prises en charge par l’application avec la procédure de mise à niveau de la base de données avant une fenêtre de maintenance.

• Qui applique les mises à jour de la base de données et de l’application ?
• Qui contrôle l’accès administrateur et les rôles courants de la base de données applicative ?
• Qui renouvelle les identifiants et met à jour la configuration de l’application de manière sûre ?
• Qui surveille la capacité, les échecs de connexion et la croissance du stockage ?
• Qui approuve et exécute les migrations de schéma ?
• Qui répond si une migration échoue ou exige un retour en arrière ?
• Qui est responsable des sauvegardes, des tests de restauration et de l’autorisation de restauration ?
• Qui coordonne les mises à niveau de versions majeures de la base de données avec la compatibilité de l’application ?