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

Introduction

Le cluster relationnel de l'Unité 5.3 constitue le socle des systèmes de référence de FinCorp : soldes de comptes, registres et transactions, où un schéma fixe et une forte cohérence sont essentiels. Cependant, toutes les charges de travail de FinCorp ne nécessitent pas un schéma fixe. Le service de notation de fraude ingère des documents d'événements hétérogènes dont les champs varient selon le canal et évoluent à chaque sprint, tandis que le service customer-360 assemble des données de profil, de consentement et d'interaction imbriquées qui, autrement, se disperseraient dans une douzaine de tables jointes. Il s'agit de charges de travail documentaires, et sur IONOS CLOUD, elles sont déployées sur Managed MongoDB.

Cette unité commence par la décision de modèle (quand le document l'emporte sur le relationnel) et la décision d'édition (qui est permanente d'une manière qui a de l'importance), puis elle construit un cluster dans Data Center Designer et s'y connecte. Deux limites d'IONOS CLOUD façonnent chaque choix de conception ici, nous les énonçons donc clairement et concevons en conséquence : Managed MongoDB ne dispose pas de réplication gérée de flux de modifications vers un second cluster, et le Backup Service basé sur Acronis ne sauvegarde pas du tout les bases de données gérées.

1. Le modèle de documents et les cas où il est préférable aux modèles relationnels

MongoDB stocke les données sous forme de documents BSON regroupés en collections, sans schéma de table imposé. C'est la raison principale pour laquelle on fait appel à ce système. Une charge de travail de type document est adaptée lorsque les enregistrements sont des agrégats autonomes dont la structure varie ou évolue, lorsque la majorité des lectures récupèrent un objet imbriqué riche plutôt que de jointer de nombreuses lignes normalisées, et lorsque le schéma doit changer sans migration coordonnée. La couche relationnelle reste la bonne réponse lorsque vous avez besoin de transactions ACID multi-lignes sur des tables normalisées, d'une intégrité référentielle appliquée par le moteur, ou d'analyses SQL ad hoc sur un schéma stable. Pour FinCorp, le grand livre reste sur Managed PostgreSQL ; le stockage des événements de fraude et l'agrégat client-360 passent sur Managed MongoDB car leurs documents sont irréguliers et leur schéma évolue constamment.

Le Database Manager d'IONOS CLOUD prend en charge les versions 6.0 et 7.0 de MongoDB, entièrement gérées (le provisionnement, les correctifs, les mises à jour et la surveillance sont gérés par la plateforme). Le contrôle d'accès au sein de la base de données utilise les rôles intégrés de MongoDB (read, readWrite, readAnyDatabase, readWriteAnyDatabase, dbAdmin, dbAdminAnyDatabase et clusterMonitor) ; il s'agit d'une attribution de rôles au niveau de la base de données, distincte du modèle de groupes et d'attributions d'IONOS CLOUD, où le privilège « Access and manage DBaaS » contrôle qui peut ouvrir le Database Manager.

1.1 Éditions et topologie

Le choix de l'édition est le plus déterminant de cette unité, car il est en pratique définitif. Passer de Business à Enterprise constitue une migration de plateforme (un transfert manuel des données vers un nouveau cluster provisionné), et non un redimensionnement sur place, et les rétrogradations ne sont pas prises en charge. Choisissez l'édition en fonction de l'évolution prévisible de la charge de travail dans un an, et non de son point de départ.

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

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

La topologie suit l'édition. Business est toujours un ensemble de répliques unique avec un nombre de nœuds de 1 ou 3 (utilisez 3 en production pour la haute disponibilité). Les ensembles de répliques Enterprise prennent en charge 1, 3, 5 ou 7 nœuds, en étendant à 5 ou 7 pour la distribution des lectures et la résilience, et seul Enterprise peut utiliser le sharding. Le sharding est une mise à l'échelle horizontale : les collections sont partitionnées sur des shards par une clé de shard, avec un minimum de 2 shards (le nombre peut être augmenté mais pas diminué). Chaque cluster sharded provisionne également automatiquement trois instances de serveur de configuration (2 cœurs / 4 Go / 40 Go de stockage chacune) qui sont exclues de vos ressources facturées ; les ressources facturées totales sont les ressources par nœud multipliées par le nombre d'instances et le nombre de shards. L'activation du sharding sur une collection nécessite le rôle enableSharding.

Recourez au sharding uniquement lorsqu'une instance unique atteint une limite verticale. Une instance Enterprise unique peut être mise à l'échelle jusqu'à 31 vCPU et 230 Go de RAM, prend en charge environ 114 000 connexions et plafonne à 30 000 IOPS d'écriture (atteint autour d'un volume de 600 Go) et environ 600 Mo/s de débit séquentiel. Au-delà de ces seuils (jeu de travail supérieur à 230 Go, demande de connexions supérieure à ~114 000, ou IOPS d'écriture supérieurs à 30 000), utilisez le sharding pour agréger la capacité sur les shards ; en dessous, un ensemble de répliques mis à l'échelle verticalement est plus simple et moins coûteux. Pour FinCorp, le stockage des événements de fraude commence comme un ensemble de répliques Business à 3 nœuds, avec un chemin documenté vers Enterprise si le volume d'événements force le jeu de travail au-delà de la limite de RAM d'une instance unique. Notez une conséquence sur la gestion des connexions : IONOS CLOUD ne fournit pas de pool de connexions géré pour MongoDB, donc la limite de connexions est un budget rigide côté application. Les pilotes doivent gérer eux-mêmes le pool de connexions.

1.2 Concevoir autour des deux limites

Aucune réplication de flux de changements gérée. IONOS CLOUD n'offre pas de réplication inter-clusters gérée pour MongoDB : vous ne pouvez pas pointer un cluster géré vers un autre et laisser la plateforme diffuser les changements entre eux. Le modèle natif est la capture de changements au niveau de l'application, exactement le substitut introduit dans l'unité 1.3. L'application (ou un consommateur de flux de changements MongoDB qu'elle exécute) publie les événements de changements sur Managed Kafka (unité 5.6), et les consommateurs en aval projettent ces événements là où ils sont nécessaires. Pour FinCorp, les résultats de scoring de fraude sont publiés sous forme d'événements plutôt que répliqués au niveau de la base de données, ce qui offre également à la couche analytique un flux d'événements propre sans le coupler au stockage opérationnel.

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 le Block Storage ; il ne sauvegarde pas Managed MongoDB. La continuité de la base de données est entièrement assurée par le modèle de sauvegarde propre au cluster. La plateforme prend un Snapshot de base lorsque le cluster est créé (synchronisation initiale, généralement moins de 24 heures), après chaque restauration, toutes les 24 heures, et un Snapshot complet chaque dimanche. Les Snapshots sont conservés pendant sept jours, et vous pouvez restaurer à partir de n'importe quel Snapshot pris avec la même version de correctif MongoDB ou une version antérieure. La restauration à un instant donné, qui permet de restaurer à un moment choisi entre 1 et 24 heures dans le passé (24 heures par défaut), est réservée à Enterprise. Les restaurations sont effectuées sur place dans le même cluster et ne peuvent utiliser que les Snapshots de ce cluster ; une seule 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 vers l'intérieur ou l'extérieur, le chemin est mongodump / mongorestore, la même discipline de dump/restaurer que la couche relationnelle. L'Oplog soutient la réplication et la PITR : dimensionnez-le pour contenir au moins 24 heures d'historique ; il peut être redimensionné plus tard sans interruption 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 méthode par laquelle FinCorp conserve une copie géographiquement séparée conformément à la résidence des données allemande.

Managed MongoDB hérite de la structure standard du SLA DBaaS : une configuration HA à 3 nœuds ou plus comporte un engagement de disponibilité de 99,95 % par service, un cluster à un ou deux nœuds comporte 99,9 %, et Playground n'a aucun SLA. C'est une raison de plus pour que le stockage de fraude de production de FinCorp fonctionne avec 3 nœuds dès le premier jour.

2. Déroulement de la mise en œuvre de DCD

Nous allons provisionner le magasin d'événements de fraude de FinCorp : un ensemble de répliques MongoDB Business à 3 nœuds sur le LAN privé du VDC existant de FinCorp, puis nous y connecterons depuis un client situé dans le VDC. Cela réalise la couche documentaire de l'architecture en couches, située uniquement en mode privé derrière la couche applicative, exactement comme le fait le cluster relationnel. MongoDB ne dispose d'aucune gestion automatique des adresses IP et le seul sous-réseau pris en charge est /24, il faut donc préparer le réseau en premier lieu.

Prérequis : le VDC de FinCorp avec un LAN privé dédié ; au moins un serveur client rattaché à ce LAN capable de résoudre le DNS public (la base de données est atteinte via un nom mongodb+srv) ; le privilège « Access and manage DBaaS » sur votre groupe ; et une adresse IP privée libre par instance (trois adresses IP pour un cluster à 3 nœuds), choisies de manière à ne pas entrer en collision avec la plage DHCP. Sur un /24 DHCP d'IONOS CLOUD, choisissez des adresses comprises entre x.x.x.3/24 et x.x.x.10/24, que le DHCP n'attribue jamais.

Objectif de construction : Provisionner un cluster et s'y connecter.

Étapes (dans Data Center Designer) :

1. Ouvrez le Database Manager pour MongoDB et cliquez sur Create cluster. Le panneau Resource allocation affiche la quota de contrat utilisée et non utilisée ; le cluster y est comptabilisé.
2. Dans Properties, définissez un Cluster Name significatif, choisissez l'Emplacement (le centre de données / la région hébergeant les données ; choisissez une région allemande pour la résidence des données de FinCorp) et sélectionnez la Version MongoDB (6.0 ou 7.0).
3. Choisissez l'Édition. Sélectionnez Business, puis choisissez un Template dimensionnant la RAM / vCPU / le stockage à partir de la liste prédéfinie. (Enterprise expose à la place les curseurs de ressources flexibles et le choix entre ensemble de répliques et cluster sharded, ainsi que l'interrupteur BI Connector ; Playground est le bac à sable gratuit fixe.)
4. Définissez le nombre de nœuds à 3 instances pour l'ensemble de répliques de production (Business prend en charge 1 ou 3).
5. Dans Network configuration, sélectionnez le Datacenter et le Datacenter LAN privé depuis le menu déroulant, puis saisissez une IP/Subnet par instance. Utilisez les adresses IP privées libres réservées dans les prérequis ; c'est ce qui maintient le cluster en mode privé uniquement.
6. Définissez la Maintenance window : choisissez un Day et une Start Time (UTC). La maintenance s'exécute dans une fenêtre fixe de 4 heures, il faut donc choisir une plage à faible trafic réelle plutôt que de la laisser arbitraire.
7. Vérifiez le prix estimé, puis cliquez sur Save pour provisionner. Le cluster passe dans un état de création et devient disponible peu après.
8. Pour vous connecter, ouvrez l'onglet Cluster details du cluster et copiez l'URI de connexion (elle a la forme mongodb+srv://m-<id>.mongodb.<region>.ionos.com). Depuis un client sur le même LAN privé, exécutez mongosh sur 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 d'accès est privé uniquement.

Erreurs courantes :

• Ne choisissez pas l'édition à la légère. Le passage de Business à Enterprise est une migration manuelle de la plateforme, pas un redimensionnement, et les rétrogradations ne sont pas prises en charge. Dimensionnez l'édition pour l'avenir de la charge de travail, pas pour sa première semaine.
• Réservez et notez vos adresses IP privées avant de commencer, une par instance, dans la plage sûre x.x.x.3 à x.x.x.10 sur un /24 DHCP d'IONOS CLOUD. Le seul sous-réseau pris en charge est /24, et le cluster ne gère pas les adresses IP à votre place, donc une collision avec la plage DHCP ou un autre serveur rompt la construction.
• N'essayez pas d'atteindre le cluster depuis l'extérieur du VDC ou d'attendre un point d'accès public ; la connexion doit provenir d'un client sur le même LAN privé. Le client doit tout de même résoudre le DNS public 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é repose sur les instantanés propres au cluster (rétention de 7 jours), le PITR exclusif à Enterprise (1 à 24 heures), et mongodump / mongorestore pour tout ce qui est plus durable ou pour la migration.
• Définissez une fenêtre de maintenance réelle. C'est une plage fixe de 4 heures pendant laquelle les opérations gérées s'exécutent, placez-la donc dans une période à faible trafic.
• Planifiez le nombre de connexions par rapport à la limite par instance (environ 114 000 sur un nœud Enterprise de 230 Go) et utilisez un pool dans le pilote. Il n'y a pas de pool de connexions géré pour absorber une tempête de connexions.

Résumé

Managed MongoDB est la couche documentaire de FinCorp : c'est le lieu de stockage des agrégats irréguliers et à évolution rapide, tels que le magasin d'événements de fraude et le profil client 360, tandis que le cluster relationnel conserve le grand livre. Le choix de l'édition est pratiquement définitif (le passage de Business à Enterprise est une migration manuelle), il est donc dimensionné pour l'avenir, et la topologie en découle : Business est un seul ensemble de répliques, Enterprise ajoute des ensembles de répliques plus volumineux et du sharding pour les charges de travail qui dépassent les limites d'une instance unique. Le cluster est construit en mode privé uniquement sur un LAN /24 avec une IP réservée par nœud et est accessible via une URI mongodb+srv depuis un client au sein du VDC. Deux limites façonnent la conception : aucune réplication de flux de changements gérée, de sorte que les modifications se propagent via des événements au niveau de l'application vers Kafka, et aucune couverture par Backup Service pour les bases de données, de sorte que la continuité repose sur les instantanés du cluster lui-même, le PITR Enterprise et les opérations de dump/restauration.

Points clés :

• Choisissez le modèle documentaire plutôt que le modèle relationnel lorsque les enregistrements sont des agrégats autonomes et flexibles sur le plan du schéma, lus comme des objets entiers ; conservez les transactions ACID multi-lignes et l'analyse SQL sur la couche relationnelle.
• L'édition est quasi permanente : Business (un seul ensemble de répliques, 1 ou 3 nœuds) par rapport à Enterprise (ensembles de répliques de 1/3/5/7 nœuds, sharding, BI Connector, PITR) ; le passage de Business à Enterprise est une migration manuelle de la plateforme, et non un redimensionnement.
• Appliquez le sharding uniquement au-delà des limites d'une instance Enterprise unique (230 Go de RAM, environ 114 000 connexions, 30 000 IOPS d'écriture) ; minimum 2 shards, plus trois serveurs de configuration non facturés.
• Provisionnez en mode privé uniquement sur un LAN /24 avec une IP libre par instance dans la plage sûre pour le DHCP ; connectez-vous avec mongosh via l'URI mongodb+srv depuis un client au sein du VDC.
• Il n'y a pas de réplication de flux de changements gérée ; propagez les modifications par la publication d'événements au niveau de l'application vers Managed Kafka.
• Backup Service ne couvre pas les bases de données gérées ; la continuité repose sur les instantanés de 7 jours du cluster, le PITR réservé à Enterprise (de 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 la plus simple.
• Cluster sharded : une topologie de mise à l'échelle horizontale réservée à Enterprise qui partitionne les collections entre les shards selon la clé de shard (minimum 2 shards) plus trois serveurs de configuration non facturés.
• Oplog : le journal des opérations sous-tendant la réplication et la restauration à un instant donné ; dimensionnez-le pour au moins 24 heures d'historique et redimensionnez-le en ligne avec replSetResizeOplog.
• PITR (restauration à un instant donné) : restauration à un moment choisi entre 1 et 24 heures dans le passé ; réservé à Enterprise et effectué sur place dans le même cluster.