Unité 5.4 : bases de données NoSQL (Managed MongoDB)

Introduction

La base de données relationnelle Cluster de l'unité 5.3 ancre les systèmes d'enregistrement de FinCorp : soldes de comptes, grand-livres et transactions où un schéma fixe et une forte cohérence sont essentiels. Mais pas toutes les charges de travail de FinCorp veulent un schéma fixe. Le service de notation de fraude ingère des documents d'événements hétérogènes dont les champs diffèrent selon le canal et évoluent à chaque sprint, et le service customer-360 assemble des données de profil, de consentement et d'interaction imbriquées qui sinon s'étaleraient sur une douzaine de tables jointes. Ce sont des charges de travail de documents, et sur IONOS, elles atterrissent sur Managed MongoDB.

Cette unité commence à la décision de modèle (lorsque le document bat la relation) et à la décision d'édition (qui est permanente d'une manière qui compte), puis crée un Cluster dans le Data Center Designer et s'y connecte. Deux limites IONOS façonnent chaque choix de conception ici, nous les énonçons donc clairement et concevons autour d'elles : Managed MongoDB n'a pas de réplication de flux de modification gérée vers une deuxième Cluster, et le Backup Service basé sur Acronis ne sauvegarde pas les bases de données gérées du tout.

1. Le modèle de document et quand il convient par rapport au modèle relationnel

Le MongoDB stocke les données sous forme de documents BSON regroupés en collections, sans schéma de table imposé. C'est la principale raison de l'utiliser. Une charge de travail de documents convient lorsque les enregistrements sont des agrégats auto-contenus dont la forme varie ou évolue, lorsque la plupart des lectures extraient un objet imbriqué riche plutôt que de joindre de nombreuses lignes normalisées, et lorsque le schéma doit changer sans migration coordonnée. Le niveau relationnel reste la bonne réponse lorsque vous avez besoin de transactions ACID multi-lignes sur des tables normalisées, d'intégrité référentielle imposée par le moteur, ou d'analyses SQL ad-hoc sur un schéma stable. Pour FinCorp, le grand livre reste sur le Managed PostgreSQL ; le magasin d'événements de fraude et l'agrégat client-360 passent au Managed MongoDB car leurs documents sont irréguliers et leur schéma tourne constamment.

Le gestionnaire de base de données IONOS prend en charge les versions 6.0 et 7.0 du MongoDB, entièrement gérées (provisionnement, correction, mises à jour et surveillance sont gérés par la plateforme). Le contrôle d'accès à l'intérieur de la base de données utilise les rôles intégrés du MongoDB (lecture, lecture-écriture, lectureAnyDatabase, lecture-écritureAnyDatabase, dbAdmin, dbAdminAnyDatabase et clusterMonitor) ; il s'agit d'un affectation de rôle au niveau de la base de données, distinct du modèle de groupe et d'octroi d'accès IONOS, où le privilège "Accéder et gérer le DBaaS" contrôle qui peut ouvrir le gestionnaire de base de données.

1.1 Éditions et topologie

La décision d'édition est la plus importante dans cette unité, car elle est effectivement permanente. Passer de l'édition Business à l'édition Enterprise est une migration de plateforme (un déplacement manuel de données dans une nouvelle instance provisionnée de Cluster), et non une modification de taille sur place, et les downgrades ne sont pas pris en charge. Choisissez l'édition en fonction de l'endroit où la charge de travail sera dans un an, et non où elle commence.

Le tableau suivant est la comparaison des éditions IONOS ; utilisez-le pour placer une charge de travail avant de provisionner quoi que ce soit.

Au-dessus des deux éditions de production se trouve le Playground : une instance fixe de 1 vCPU / 2 GB RAM / 50 GB, destinée aux tests et explicitement exclue de tout SLA. Traitez-le comme un bac à sable, jamais comme un substitut de production pour un Cluster.

La topologie suit l'édition. L'édition Business est toujours un ensemble de réplicas unique avec un nombre de Node de 1 ou 3 (utilisez 3 en production pour une haute disponibilité). Les ensembles de réplicas Enterprise s'étendent à 5 ou 7 nœuds pour la distribution et la résilience des lectures, et seul l'Enterprise peut fragmenter. La fragmentation est une mise à l'échelle horizontale : les collections sont partitionnées sur des fragments à l'aide d'une clé de fragmentation, avec un minimum de 2 fragments (le nombre peut être augmenté mais non diminué). Chaque Cluster fragmenté provisionne automatiquement trois instances de serveur de configuration (2 cœurs / 4 Go / 40 Go de stockage chacune) qui sont exclues des ressources facturées ; les ressources facturées totales sont les ressources par Node multipliées par le nombre d'instances et le nombre de fragments. L'activation de la fragmentation sur une collection nécessite le rôle enableSharding.

N'utilisez la fragmentation que lorsque une instance unique atteint un mur vertical. Une instance unique Enterprise peut mettre à l'échelle jusqu'à 31 vCPU et 230 Go RAM, prend en charge environ 114 000 connexions et est limitée à 30 000 écritures IOPS (atteintes autour d'un Volume de 600 Go) et à environ 600 Mo/s de débit séquentiel. Dépassez ces seuils (ensemble de travail supérieur à 230 Go, demande de connexion supérieure à environ 114 000 ou écritures IOPS supérieures à 30 000) et vous fragmentez pour agréger la capacité sur les fragments ; en dessous de ces seuils, un ensemble de réplicas mis à l'échelle verticalement est plus simple et moins cher. Pour FinCorp, le magasin d'événements de fraude commence comme un ensemble de réplicas Business à 3 Node, avec un chemin documenté vers l'Enterprise si les événements Volume obligent à dépasser le mur RAM d'une instance unique Node. Notez une conséquence de gestion des connexions : IONOS ne fournit pas de pooler de connexions géré pour le MongoDB, donc le plafond de connexion est un budget applicatif dur. Les pilotes doivent gérer les connexions eux-mêmes.

1.2 Conception autour des deux limites

Pas de réplication de flux de modifications gérée. IONOS ne propose pas de réplication gérée de Cluster pour le MongoDB : vous ne pouvez pas pointer une instance gérée de Cluster vers une autre et avoir la plateforme diffuser les modifications entre elles. Le modèle natif est la capture des modifications au niveau de l'application, exactement le remplacement introduit dans l'unité 1.3. L'application (ou un consommateur de flux de modifications MongoDB qu'elle exécute) publie des événements de modification sur Managed Kafka (unité 5.6), et les consommateurs en aval projettent ces événements partout où ils sont nécessaires. Pour FinCorp, les résultats de notation de fraude sont publiés sous forme d'événements plutôt que répliqués au niveau de la couche de base de données, ce qui donne également à la couche d'analyse un flux d'événements propre sans la coupler à la couche de stockage opérationnelle.

Le Backup Service ne couvre pas les bases de données gérées. Le Backup Service basé sur Acronis (unité 5.7) protège uniquement les VM et les Block Storage ; il ne sauvegarde pas les Managed MongoDB. La continuité de la base de données est assurée entièrement par le modèle de sauvegarde du Cluster lui-même. La plateforme prend une sauvegarde de base lorsque le Cluster est créé (synchronisation initiale, généralement en moins de 24 heures), après chaque restauration, toutes les 24 heures, et une sauvegarde complète tous les dimanches. Les instantanés sont conservés pendant sept jours, et vous pouvez restaurer à partir de n'importe quelle sauvegarde prise avec la même ou une version de correctif plus ancienne du MongoDB. La récupération ponctuelle, qui vous permet de restaurer à un moment choisi entre 1 et 24 heures dans le passé (24 heures par défaut), est réservée à l'Enterprise. Les restaurations sont effectuées sur place dans le même Cluster et ne peuvent utiliser que les propres instantanés de ce Cluster ; seule une tâche de restauration s'exécute à la fois, et le Cluster est occupé pendant une restauration et ne doit pas recevoir de connexions. Pour une rétention à long terme au-delà de sept jours, ou pour migrer des données à l'intérieur ou à l'extérieur, le chemin est mongodump / mongorestore, la même discipline de sauvegarde et de restauration que le niveau relationnel. Le journal des opérations sous-tend la réplication et la récupération ponctuelle : dimensionnez-le pour conserver au moins 24 heures d'historique ; il peut être redimensionné plus tard sans temps d'arrêt en utilisant replSetResizeOplog. Les clusters Enterprise peuvent également placer des sauvegardes hors site dans une région différente de celle du Cluster (de, eu-south-2, eu-central-3), ce qui est la façon dont FinCorp conserve une copie géographiquement distincte sous résidence de données allemande.

Le Managed MongoDB hérite de la structure standard de SLA de DBaaS : un ensemble HA à 3 Node ou plus comporte un engagement d'uptime de 99,95 % par service, un Cluster unique ou à double Node comporte 99,9 %, et le Playground ne comporte aucun SLA. C'est une raison de plus pour laquelle le magasin de fraude de production de FinCorp s'exécute sur 3 nœuds dès le premier jour.

2. DCD Déploiement étape par étape

Nous allons provisionner le magasin d'événements de fraude de FinCorp : un jeu de répliques métier 3-Node MongoDB sur le centre de données privé existant de FinCorp VDC, puis nous nous connecterons à celui-ci à partir d'un client dans le VDC. Cela réalise le niveau de document de l'architecture en couches, situé derrière le niveau d'application en privé, exactement comme le fait la base de données relationnelle Cluster. MongoDB n'a pas de gestion d'adresse IP automatique et le seul sous-réseau pris en charge est /24, donc le réseau doit être préparé au préalable.

Prérequis : le VDC de FinCorp avec un centre de données privé dédié ; au moins un serveur client attaché à ce centre de données qui peut résoudre les adresses DNS publiques (la base de données est accessible via un nom mongodb+srv) ; le privilège "Accéder et gérer DBaaS" sur votre groupe ; et une adresse IP privée libre par instance (trois adresses IP pour un jeu de répliques 3-Node Cluster), choisies de manière à ne pas entrer en conflit avec la plage DHCP. Sur un réseau IONOS-DHCP /24, choisissez des adresses entre x.x.x.3/24 et x.x.x.10/24, que le DHCP n'attribue jamais.

Objectif de construction : Provisionner une base de données Cluster et établir une connexion.

Étapes (dans le Data Center Designer) :

1. Ouvrez le gestionnaire de base de données pour MongoDB et cliquez sur Créer une base de données Cluster. Le panneau d'allocation de ressources affiche les quotas de contrat utilisés et inutilisés ; la base de données Cluster est comptabilisée dans celui-ci.
2. Dans Propriétés, définissez un nom de base de données Cluster significatif, choisissez l'Emplacement (le centre de données / région qui contient les données ; choisissez une région allemande pour la résidence de FinCorp) et sélectionnez la Version MongoDB (6.0 ou 7.0).
3. Choisissez l'Édition. Sélectionnez Business, puis choisissez un Modèle qui taille le RAM / vCPU / stockage à partir de la liste prédéfinie. (Enterprise expose plutôt les curseurs de ressources flexibles et le choix entre le jeu de répliques et la base de données fragmentée, ainsi que l'option de connecteur BI ; Playground est le bac à sable fixe et gratuit.)
4. Définissez le nombre d'instances Node à 3 instances pour le jeu de répliques de production (Business prend en charge 1 ou 3).
5. Dans Configuration réseau, sélectionnez le Centre de données et le centre de données privé LAN dans le menu déroulant, puis entrez une adresse IP/Sous-réseau par instance. Utilisez les adresses IP privées libres réservées dans les prérequis ; c'est ce qui garde la base de données Cluster en privé uniquement.
6. Définissez la Fenêtre de maintenance : choisissez un Jour et une Heure de début (UTC). La maintenance s'exécute dans une fenêtre fixe de 4 heures, donc choisissez un véritable créneau de faible trafic plutôt que de le laisser arbitraire.
7. Examinez le prix estimé, puis cliquez sur Enregistrer pour provisionner. La base de données Cluster entre dans un état de création et devient disponible peu de temps après.
8. Pour vous connecter, ouvrez l'onglet Détails de la base de données Cluster et copiez l'URI de connexion (il a la forme mongodb+srv://m-<id>.mongodb.<region>.ionos.com). À partir d'un client sur le même centre de données privé LAN, exécutez mongosh contre cette URI avec votre nom d'utilisateur et votre mot de passe de base de données. La connexion doit provenir d'un client dans le VDC, car le point de terminaison est privé uniquement.

Erreurs courantes :

• Ne choisissez pas l'édition de manière cavalière. La migration de Business à Enterprise est une migration de plateforme manuelle, et non une simple mise à l'échelle, et les downgrades ne sont pas pris en charge. Dimensionnez l'édition en fonction de la charge de travail future, et non de sa première semaine.
• Réservez et enregistrez vos adresses IP privées avant de commencer, une par instance, dans la bande sûre x.x.x.3 à x.x.x.10 sur un réseau IONOS-DHCP /24. Le seul sous-réseau pris en charge est /24, et la base de données Cluster ne fait aucune gestion d'adresse IP pour vous, donc une collision avec la plage DHCP ou un autre serveur casse la construction.
• N'essayez pas de joindre la base de données Cluster de l'extérieur du VDC ou n'attendez pas un point de terminaison public ; la connexion doit provenir d'un client sur le même centre de données privé LAN. Le client doit toujours résoudre les adresses DNS publiques pour rechercher le nom mongodb+srv.
• Ne supposez pas que le Backup Service protège cette base de données. Ce n'est pas le cas. La continuité est assurée par les instantanés de la base de données Cluster (rétention de 7 jours), le PITR (1 à 24 heures) uniquement pour Enterprise, et mongodump / mongorestore pour tout ce qui est plus durable ou pour la migration.
• Définissez une véritable fenêtre de maintenance. Il s'agit d'un créneau fixe de 4 heures pendant lequel les opérations gérées s'exécutent, donc placez-le dans une période de faible trafic.
• Planifiez les comptes de connexion par rapport au plafond par instance (environ 114 000 sur une base de données Enterprise Node de 230 Go) et mettez en pool dans le pilote. Il n'y a pas de pooler de connexions géré pour absorber une tempête de connexions.

Résumé

Managed MongoDB est le niveau de document de FinCorp : le home pour les agrégats irréguliers et en évolution rapide comme le magasin d'événements de fraude et le client-360, tandis que le relationnel Cluster conserve le livre de comptes. Le choix d'édition est effectivement permanent (Business à Enterprise est une migration manuelle), il est donc dimensionné pour l'avenir, et la topologie en découle : Business est un ensemble de répliques unique, Enterprise ajoute des ensembles de répliques plus grands et un partitionnement pour les charges de travail qui dépassent les murs d'une instance unique. Le Cluster est construit en privé uniquement sur un /24 LAN avec une IP réservée par Node et accessible via un URI mongodb+srv à partir d'un client dans le centre de données virtuel. Deux limites façonnent la conception : pas de réplication de flux de modification gérée, les modifications se propagent donc via des événements au niveau de l'application dans Kafka, et pas de couverture Backup Service pour les bases de données, la continuité repose donc sur les instantanés propres au Cluster, la reprise après sinistre en temps réel (PITR) Enterprise, et la sauvegarde/restauration.

Points clés :

• Choisissez le document par rapport au relationnel lorsque les enregistrements sont des agrégats auto-contenus, flexibles en termes de schéma, lus comme des objets entiers ; conservez l'ACID multi-ligne et les analyses SQL sur le niveau relationnel.
• L'édition est quasi-permanente : Business (ensemble de répliques unique, 1 ou 3 nœuds) vs Enterprise (5/7-Node ensembles de répliques, partitionnement, connecteur BI, PITR) ; Business à Enterprise est une migration de plateforme manuelle, et non une redimensionnement.
• Partitionnez uniquement au-delà des murs d'une instance Enterprise unique (230 GB RAM, ~114 000 connexions, 30 000 écritures IOPS) ; minimum 2 partitions, plus trois serveurs de configuration non facturés.
• Mettez en place en privé uniquement sur un /24 LAN avec une IP gratuite par instance dans la plage DHCP-sûre ; connectez-vous avec mongosh via l'URI mongodb+srv à partir d'un client dans le centre de données virtuel.
• Il n'y a pas de réplication de flux de modification gérée ; propagez les modifications avec la publication d'événements au niveau de l'application vers Managed Kafka.
• Le Backup Service ne couvre pas les bases de données gérées ; la continuité est assurée par les instantanés de 7 jours du Cluster, la reprise après sinistre en temps réel (PITR) Enterprise uniquement (1 à 24 heures), et mongodump / mongorestore.

Terminologie importante :

• Ensemble de répliques : un groupe d'instances MongoDB contenant des copies des mêmes données pour la redondance et la haute disponibilité ; la seule topologie Business et la topologie Enterprise plus simple.
• Cluster partitionné : une topologie d'évolutivité horizontale uniquement pour Enterprise qui partitionne les collections à travers les partitions par clé de partition (minimum 2 partitions) plus trois serveurs de configuration non facturés.
• Oplog : le journal des opérations sous-jacent à la réplication et à la reprise après sinistre en temps réel ; dimensionnez-le pour au moins 24 heures d'historique et redimensionnez-le en ligne avec replSetResizeOplog.
• PITR (reprise après sinistre en temps réel) : restaurer à un moment choisi entre 1 et 24 heures dans le passé ; uniquement pour Enterprise et sur place dans le même Cluster.