Déployer une charge de travail MongoDB migrée vers Oracle Autonomous Transaction Processing Serverless
Migrez une charge de travail existante qui utilise une base de données de documents, en l'occurrence MongoDB, vers la base de données Oracle Autonomous Transaction Processing Serverless (ATP Serverless) sur Oracle Cloud Infrastructure (OCI) pour moderniser le développement de vos applications centrées sur JSON ainsi que d'autres charges de travail multimodèles.
Les charges de travail et les applications qui utilisent des documents et des bases de données de documents pour faire évoluer les schémas et les applications de données sont populaires en raison de la flexibilité qu'elles offrent aux développeurs. La flexibilité du schéma, le développement rapide et l'évolutivité permettent un prototypage accéléré des fonctions d'application, une évolution plus facile des applications et la capacité de créer des applications et des fonctions itératives plus petites que les développeurs peuvent mettre à l'échelle pour répondre à une grande base d'utilisateurs. Cependant, ces types de charges de travail ont leurs défis, notamment des garanties transactionnelles plus faibles, la polyvalence des requêtes de données et l'incapacité à prendre en charge d'autres charges de travail sur des documents, telles que l'analyse ou l'apprentissage automatique.
Et si ces charges de travail pouvaient bénéficier des avantages des bases de données documentaires traditionnelles et tirer parti des avantages des bases de données relationnelles? Par exemple, bénéficiez de garanties transactionnelles et de fonctionnalités supplémentaires renforcées, telles que l'analyse et l'apprentissage automatique, sans avoir à répliquer les données vers une autre base de données ou un autre système.
Autonomous Transaction Processing sans serveur est un service de base de données entièrement automatisé, optimisé pour exécuter simultanément des charges de travail transactionnelles, analytiques et par lots. Pour accélérer la performance, il est préconfiguré pour le format de rangée, les index et la mise en mémoire cache des données, tout en offrant évolutivité, disponibilité, sécurité transparente et analyses opérationnelles en temps réel. Les développeurs d'applications et les administrateurs de base de données peuvent développer et déployer des applications rapidement et à moindre coût sans sacrifier la fonctionnalité ou les propriétés d'atomicité, de cohérence, d'isolement et de durabilité.
Architecture fonctionnelle
Cette architecture de référence se concentre sur le déploiement de la charge de travail migrée et non sur le processus de migration lui-même. Pour plus de détails sur le processus de migration, voir la section Explorer plus.
L'un des produits clés utilisés dans cette architecture est l'API Oracle Database pour MongoDB, qui permet aux applications d'interagir avec des collections de documents JSON dans Oracle Database à l'aide de pilotes, d'outils et de trousses SDK MongoDB. Cela permet au code d'application existant de fonctionner avec les données stockées dans une base de données Autonomous Transaction Processing sans serveur (ATP Serverless) sans avoir à refactoriser le code.
Le diagramme suivant présente une application type composée d'une base de données, de niveaux dorsaux et frontaux.
mongodb-atp-s-logical-arch-migration-oracle.zip
- MongoDB : Base de données de document
- Express : Cadre dorsal
- Angulaire : Cadre frontal
Node.js: Serveur dorsal
Cet exemple utilise une pile MEAN pour migrer un déploiement existant vers OCI et ATP Serverless.
La migration de cette charge de travail vers OCI et ATP Serverless est simple et comprend, à un niveau élevé, les étapes suivantes :
- Déployez une instance ATP sans serveur, en activant au moment de la création l'API Oracle Database Mongo DB.
- Migrez les métadonnées et les données de MongoDB vers ATP Serverless.
- Déployez des serveurs d'applications pour exécuter
Node.jset Express à l'aide de machines virtuelles, de conteneurs ou de Kubernetes, dans la même région et le même domaine de disponibilité que ATP Serverless. - Déployez le code d'application dorsal sur les serveurs d'applications.
- Connectez l'application dorsale à ATP Serverless à l'aide des mêmes outils et pilotes MongoDB utilisés sur l'application courante.
- Connectez les utilisateurs au nouvel URI d'application.
Une fois la charge de travail migrée vers ATP Serverless, plusieurs fonctionnalités sont disponibles pour augmenter la fonctionnalité existante, que ce soit pour 1) prendre en charge des exigences non fonctionnelles supplémentaires telles que l'amélioration facile de l'évolutivité, de la résilience ou de la haute disponibilité ou 2) avoir des fonctionnalités supplémentaires telles que les rapports opérationnels, l'analyse et l'apprentissage automatique en place, sans avoir à copier les données de la base de données.
Pour améliorer l'évolutivité et la haute disponibilité, utilisez la fonction d'ajustement automatique sans serveur d'Autonomous Transaction Processing. En un seul clic ou appel d'API, la charge de travail peut utiliser jusqu'à 3 fois la capacité de base sans aucun temps d'arrêt. Notez qu'Autonomous Transaction Processing sans serveur utilise la technologie Oracle Real Application Clusters (Oracle RAC) pour une haute disponibilité. Pour le niveau dorsal, utilisez les groupes d'instances de calcul avec des règles d'ajustement automatique pour assurer la haute disponibilité et l'extensibilité des applications.
Comme Autonomous Transaction Processing sans serveur est fondé sur une technologie de base de données multimodèle et à charges de travail multiples, vous pouvez ajouter des fonctions qui s'appuient sur des types de données relationnelles, spatiales, graphiques ou vectorielles qui fonctionnent avec l'application existante.
Architecture physique
L'architecture physique inclut des sous-réseaux publics et privés dans OCI avec une région de sauvegarde secondaire pour prendre en charge la haute disponibilité.
L'architecture prend en charge les éléments suivants :
- Niveau frontal
- Les utilisateurs d'applications peuvent se connecter à partir d'Internet ou du réseau d'entreprise.
- La connexion d'utilisateur est sécurisée à l'aide d'un pare-feu d'application Web OCI.
- La connexion de l'utilisateur à l'application est équilibrée pour une résilience et une évolutivité accrues.
- L'équilibreur de charge est déployé avec une haute disponibilité.
- Niveau dorsal
- Les serveurs d'applications sont déployés en haute disponibilité à l'aide d'un groupe d'instances.
- Le groupe d'instances est utilisé avec l'ajustement automatique pour une évolutivité horizontale.
- Le groupe d'instances est configuré pour déployer des instances dans le même domaine de disponibilité que ATP Serverless afin d'avoir une colocalisation des applications et des bases de données, optimisant ainsi la latence de connexion.
- Le groupe d'instances est configuré pour répartir les instances entre les domaines d'erreur du même domaine de disponibilité que celui où ATP Serverless est placé, afin d'augmenter la résilience de la charge de travail.
- Niveau de base de données
- ATP Serverless offre une haute disponibilité en tant qu'Oracle Real Application Clusters (Oracle RAC) et plusieurs noeuds de base de données sous-tendent l'instance de service. Par conséquent, par défaut, le niveau base de données est hautement disponible et résilient.
- L'API Oracle Database pour MongoDB activée dans ATP Serverless vous permet d'utiliser le code d'application existant sans modification.
- L'API Oracle Database pour MongoDB est hautement résiliente et cette résilience est garantie à l'interne par ATP Serverless.
- ATP Serverless peut utiliser la mise à l'échelle automatique, en s'ajustant aux augmentations et aux diminutions de la charge du système.
- La continuité d'activité ATP sans serveur est assurée avec la récupération après sinistre inter-région basée sur Oracle Autonomous Data Guard.
- L'objectif de temps de reprise (ODR) de la base de données de secours Oracle Autonomous Data Guard inter-région est de quinze minutes et l'objectif de point de reprise (OPR) est d'une minute.
- Récupération après sinistre
- Deux régions prennent en charge la reprise après sinistre inter-région pour l'ensemble du déploiement en nuage.
- La région de secours prend en charge une base de données de secours chaude dans laquelle les instances en nuage sont prédéployées afin de réduire l'objectif de temps de récupération totale.
- Dans la région principale, ATP sans serveur dispose d'un pair inter-région Oracle Autonomous Data Guard sur la région de secours
- Le groupe d'instances du niveau dorsal est préconfiguré avec un nombre minimal d'instances dans le groupe. Le plan de reprise après sinistre de pile complète pour OCI, qui automatise chaque étape du basculement, peut modifier le nombre d'instances de calcul qui doivent s'exécuter après le basculement. La configuration d'ajustement automatique basé sur les mesures est définie pour déterminer le nombre minimal et maximal d'instances dans le groupe, ainsi que les mesures utilisées pour l'augmentation et la réduction.
- La région de secours est déployée avec une topologie similaire pour réduire l'objectif global de temps de récupération.
- Le service Récupération après sinistre de pile complète pour OCI automatise le basculement pour l'ensemble de la pile vers la région de secours et les secours vers la région principale.
- Service de réseau
- Les passerelles de routage dynamique déployées dans les deux régions sont appairées.
- La connectivité sur place exploite à la fois Oracle Cloud Infrastructure FastConnect et un RPV site à site pour la redondance.
- Tout le trafic entrant depuis les lieux et Internet est d'abord acheminé vers le VCN central, puis vers le VCN de charge de travail.
- Utilise une conception de réseau en étoile ou en étoile pour renforcer la sécurité et prendre en charge d'autres réseaux en nuage virtuels de charge de travail.
- Les services sont déployés avec des points d'extrémité privés pour renforcer la sécurité.
- Le VCN de charge de travail JSON est séparé en plusieurs sous-réseaux privés pour augmenter la sécurité.
- Sécurité
- Toutes les données sont sécurisées en transit et au repos.
- Les améliorations de conception potentielles qui ne sont pas décrites dans ce déploiement pour des raisons de simplicité incluent l'utilisation d'une zone d'atterrissage complète conforme à CIS et l'exploitation d'un pare-feu de réseau déployé dans le VCN central. Un pare-feu de réseau améliorera la sécurité globale en inspectant tout le trafic et en appliquant des politiques.
mongodb-atp-s-physical-arch-oracle.zip
L'architecture comporte les principaux composants suivants :
- Région
Une région OCI est une zone géographique localisée qui contient un ou plusieurs centres de données, des domaines de disponibilité d'hébergement. Les régions sont indépendantes les unes des autres, et de grandes distances peuvent les séparer (à travers les pays ou même les continents).
- Réseau en nuage virtuel (VCN) et sous-réseaux
Un VCN est un réseau défini par logiciel personnalisable que vous configurez dans une région OCI. Comme les réseaux de centre de données traditionnels, les réseaux en nuage virtuels vous permettent de contrôler votre environnement de réseau. Un VCN peut disposer de plusieurs blocs de routage inter-domaine (CIDR) sans chevauchement que vous pouvez modifier après avoir créé le VCN. Vous pouvez segmenter un VCN en sous-réseaux, dont la portée peut concerner une région ou un domaine de disponibilité. Un sous-réseau est constitué d'un intervalle contigu d'adresses qui ne chevauchent pas les autres sous-réseaux dans le réseau en nuage virtuel. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.
- FastConnect
Oracle Cloud Infrastructure FastConnect crée une connexion privée dédiée entre votre centre de données et OCI. FastConnect fournit des options de bande passante supérieure et permet une utilisation du réseau plus fiable par rapport aux connexions Internet.
- Passerelle de routage dynamique (DRG)
La passerelle DRG est un routeur virtuel qui fournit un chemin pour le trafic réseau privé entre des réseaux en nuage virtuels de la même région, entre un VCN et un réseau en dehors de la région, tel qu'un VCN dans une autre région OCI, un réseau sur place ou un réseau dans un autre fournisseur de nuage.
- Passerelle de traduction d'adresses de réseau (NAT)
Une passerelle NAT permet aux ressources privées d'un VCN d'accéder aux hôtes sur Internet, sans les exposer aux connexions Internet entrantes.
- Passerelle de service
Une passerelle de service fournit un accès à partir d'un VCN à d'autres services, tels que Oracle Cloud Infrastructure Object Storage. Le trafic entre le réseau VCN et le service Oracle circule sur la structure réseau Oracle et ne passe pas par Internet.
- Passerelle Internet
Une passerelle Internet permet le trafic entre les sous-réseaux publics d'un VCN et le réseau Internet public.
- Équilibreur de charge
Oracle Cloud Infrastructure Load Balancing assure la répartition automatisée du trafic d'un point d'entrée unique vers plusieurs serveurs.
- Pare-feu pour application Web
Le service Oracle Cloud Infrastructure Web Application Firewall (WAF) est un service d'application en périphérie de réseau, régional et conforme à la norme PCI (Payment Card Industry), attaché à un point d'application, tel qu'un équilibreur de charge ou un nom de domaine d'application Web. Le service WAF protège les applications contre le trafic Internet malveillant ou indésirable. Le service WAF peut protéger tout point d'extrémité accessible sur Internet en appliquant uniformément des règles à vos applications.
- Oracle Autonomous Transaction Processing Serverless
Oracle Autonomous Transaction Processing Serverless est un service de base de données entièrement automatisé, optimisé pour exécuter simultanément des charges de travail transactionnelles, analytiques et par lots. Pour accélérer la performance, il est préconfiguré pour le format de rangée, les index et la mise en mémoire cache des données, tout en offrant évolutivité, disponibilité, sécurité transparente et analyses opérationnelles en temps réel. Les développeurs d'applications et les administrateurs de base de données peuvent développer et déployer des applications rapidement, facilement et à moindre coût, sans sacrifier la fonctionnalité ou les propriétés d'atomicité, de cohérence, d'isolement et de durabilité (ACID).
- Récupération après sinistre de pile complète
Oracle Cloud Infrastructure Full Stack Disaster Recovery est un service d'orchestration et de gestion qui fournit des fonctions complètes de récupération après sinistre pour toutes les couches d'une pile d'applications, notamment l'infrastructure, l'intergiciel, la base de données et l'application.
- Stockage d'objets
Le service de stockage d'objets pour OCI donne accès à de grandes quantités de données structurées et non structurées de tous types, notamment des sauvegardes de base de données, des données analytiques et du contenu enrichi, comme des images et des vidéos. Vous pouvez stocker des données en toute sécurité directement à partir d'Internet ou de la plate-forme en nuage. Vous pouvez adapter le stockage sans que la performance ou la fiabilité des services soit affectée.
Utilisez le stockage standard pour le stockage "à chaud" auquel vous devez accéder rapidement, immédiatement et fréquemment. Utilisez le stockage d'archives pour le stockage "à froid" que vous conservez pendant de longues périodes et auquel vous accédez rarement.
- API Oracle Database pour MongoDB
L'API d'Oracle Database pour MongoDB permet aux applications d'interagir avec des collections de documents JSON dans Oracle Database à l'aide de pilotes, d'outils et de trousses SDK MongoDB.
Variante d'architecture physique
S'il y a des exigences pour contrôler manuellement la configuration et la gestion d'Oracle REST Data Services, l'utilisation d'Oracle REST Data Services géré par le client est une option. Par exemple, pour permettre à l'application d'utiliser des pools de connexions plus importants.
Note :
Utilisez cette variante d'architecture si une charge de travail spécifique est requise pour ce faire. Seuls les utilisateurs avancés doivent déployer cette variante d'architecture.Cette section ne décrit que les différences par rapport à l'architecture physique décrite précédemment, de sorte que tous les principes de conception de l'architecture physique sont valides, sauf indication contraire.
Le diagramme d'architecture ci-dessous montre comment la variante est déployée. Pour simplifier, seules les ressources en nuage déployées dans le VCN de charge de travail JSON sont représentées, car le reste du déploiement est le même que celui décrit précédemment.
mongodb-atp-s-arch-variant-oracle.zip
- Le code d'application dorsal est déployé dans les serveurs d'applications qui font partie d'un groupe d'instances.
- Les demandes d'utilisateur entrantes sont réparties par l'équilibreur de charge. Le niveau frontal est donc horizontalement évolutif et n'a pas de point de défaillance unique.
- Oracle REST Data Services géré par le client est installé sur chaque serveur d'applications et configuré pour activer l'API MongoDB afin que l'application puisse se connecter à la base de données à l'aide des outils et des pilotes MongoDB.
- Oracle REST Data Services géré par le client est configuré pour s'adapter aux exigences non fonctionnelles de la charge de travail, par exemple en configurant des groupes de connexions plus importants ou en utilisant un autre service de base de données.
- Le code dorsal et le service Oracle REST Data Services géré par le client sont préinstallés et préconfigurés dans la configuration d'instance utilisée par le groupe. Ainsi, chaque fois qu'une instance est ajoutée au groupe, elle peut exécuter le système dorsal et se connecter à la base de données, après le provisionnement de l'instance.
Recommandations
Tenez compte des points suivants :
- Déploiement d'application
Utilisez un déploiement basé sur des conteneurs avec Oracle Cloud Infrastructure Kubernetes Engine (OKE) si l'application peut s'exécuter dans des conteneurs.
- Sécurité
- Utilisez Oracle Data Safe pour renforcer la sécurité de la charge de travail et pouvoir effectuer des vérifications de base de données.
- Observabilité
- Utilisez le service Service de vérification pour OCI pour effectuer un audit médico-légal pour tous les services OCI au-delà d'Oracle Autonomous Database Serverless.
- Utilisez OCI Monitoring, OCI Logging et OCI Logging Analytics pour avoir une visibilité complète du statut de fonctionnement de l'environnement.
- Efficacité opérationnelle
- Utilisez des groupes élastiques si la charge de travail JSON ATP sans serveur fait partie d'un parc de bases de données plus large pour une efficacité accrue des coûts.
- Activer le service Oracle Cloud Infrastructure Database Management. Ce service fournit un ensemble complet de fonctions de surveillance et de gestion des performances des bases de données afin de rationaliser l'instance ATP Serverless.
- Évolution des applications
- Déployez des analyses opérationnelles et des rapports en temps réel dans ATP Serverless à l'aide de SQL et d'un système frontal, tel qu'APEX ou Oracle Analytics Cloud, sans déplacer les données de la base de données pour une analyse fiable et en temps réel.
- Utilisez ATP Serverless et Oracle Machine Learning pour créer et entraîner des modèles avec les données JSON sans déplacer les données et pour déployer les modèles parallèlement à la charge de travail existante en cas d'inférence efficace.
- Pour des cas d'utilisation supplémentaires au-delà du coeur d'application, envisagez d'utiliser Oracle Autonomous Database Select AI et des vues de base de données qui interrogent JSON et tiennent des métadonnées. Cela permet aux utilisateurs d'interroger des données JSON à l'aide du langage naturel.
- Utilisez ATP Serverless pour stocker des types de données supplémentaires (relationnel, vectoriel, spatial ou graphique) pour une fonctionnalité et une flexibilité accrues de la charge de travail.
Informations complémentaires
En savoir plus sur les caractéristiques de cette architecture et sur les architectures connexes.
Vérifiez ces ressources supplémentaires :
- Plateforme de données d'Oracle
- Documentation sur Oracle Autonomous Transaction Processing Serverless
- API Oracle Database pour MongoDB
- Migrer une base de données MongoDB exécutée sur MongoDB Atlas ou sur place vers Oracle Autonomous JSON Database (tutoriel)
- À propos d'Oracle REST Data Services dans un environnement géré par le client avec une base de données autonome
- Documentation sur Oracle Cloud Infrastructure
- Cadre structuré pour Oracle Cloud Infrastructure
- Estimateur de coûts d'Oracle Cloud
- Cadre d'adoption d'environnement en nuage
- Développement d'applications modernes