Déployer une charge de travail MongoDB migrée vers Oracle Autonomous Transaction Processing Serverless@Azure
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 (ATP) 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 suppose, comme point de départ, qu'une charge de travail avec une application et une base de données MongoDB existe, qu'il s'agisse d'un déploiement sur place ou en nuage, et sera migrée vers Azure et Oracle Database@Azure. Il décrit l'architecture de l'état futur, ses avantages, la façon dont elle peut être déployée et les fonctionnalités supplémentaires que vous pouvez utiliser pour augmenter la charge globale existante.
L'une des principales caractéristiques utilisées dans cette architecture est l'API Oracle Database API for 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. Le code d'application existant peut fonctionner avec les données stockées dans Oracle Autonomous Transaction Processing sans serveur, sans avoir à refactoriser le code.
Le diagramme suivant présente une application type composée d'une base de données, d'un système dorsal et de niveaux frontaux.
mongodb-atp-s-azure-logical-arch-migration.zip
La pile MEAN est une pile populaire utilisée pour implémenter ce modèle :
- MongoDB : Documenter la base de données
- Express : Cadre dorsal
- Angulaire : Cadre frontal
Node.js: Serveur dorsal
Ce document utilise une pile MEAN comme exemple d'un déploiement existant qui sera migré vers Azure et ATP Serverless.
La migration de cette charge de travail vers Azure 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 MongoDB d'Oracle Database.
- 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 du service d'applications Azure, des machines virtuelles, des conteneurs ou 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.
Notez que cette architecture de référence se concentre sur le déploiement de la charge globale 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.
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 la production de 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 utilise la technologie sans serveur d'Oracle Real Application Clusters (Oracle RAC) pour assurer la haute disponibilité. Pour le niveau dorsal, utilisez des jeux d'ajustement de machine virtuelle Azure avec configuration d'ajustement automatique ou un service PaaS tel que le service d'application avec configuration d'ajustement automatique pour activer la haute disponibilité et l'évolutivité de l'application.
Étant donné que ATP Serverless est construit sur la technologie de base de données multi-modèles et à charges de travail multiples, vous pouvez ajouter des fonctionnalités qui reposent sur des types de données relationnelles, spatiales, graphiques ou vectorielles qui fonctionnent avec l'application existante.
Architecture physique
L'architecture physique inclut Autonomous Transaction Processing Serverless déployé à l'aide de sous-réseaux délégués dans deux régions Azure pour prendre en charge la haute disponibilité. Les services OCI prennent en charge la sauvegarde automatique vers Oracle Cloud Infrastructure Object Storage.
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 acheminée vers la région active qui exécute l'application, à l'aide de Porte d'entrée Azure.
- La connexion d'utilisateur est sécurisée à l'aide du pare-feu d'application Web Azure.
- La connexion de l'utilisateur à l'application est équilibrée à l'aide du service d'application.
- Niveau dorsal
- L'application est déployée en mode haute disponibilité à l'aide du service d'application Azure.
- Le service d'application Azure AutoScale est utilisé pour atteindre l'extensibilité horizontale.
- Niveau de base de données
- ATP Serverless offre une haute disponibilité, car les 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.
- Oracle Database API for MongoDB activé dans ATP Serverless vous permet d'utiliser le code d'application existant sans modification.
- L'API Oracle Database API for MongoDB est hautement résiliente et cette résilience est garantie en 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é sans serveur ATP est assurée au moyen d'Autonomous Data Guard inter-régions.
- Récupération après sinistre
- La deuxième région est déployée avec une topologie similaire pour réduire l'objectif global de temps de récupération.
- Utilisez une stratégie de reprise après sinistre chaude pour réduire l'ODR global. Dans une stratégie de reprise après sinistre dynamique, les ressources en nuage de niveau dorsal sont déjà provisionnées en même temps que la base de données de secours ATP Serverless.
- Vous pouvez également provisionner les ressources de niveau dorsal en cas de défaillance, ce qui réduit le coût d'exécution des ressources de récupération après sinistre mais augmente l'ODR global.
- Service de réseau
- Tout le trafic entrant d'application à partir d'Internet et sur place est acheminé par Azure Front Door.
- ATP Serverless est déployé avec un point d'extrémité privé pour améliorer la sécurité.
- L'application Web du service d'application Azure est déployée à l'aide d'un sous-réseau d'intégration et de VNet pour atteindre l'instance ATP sans serveur.
- L'application VNet est appairée à la base de données VNet et le trafic est autorisé à circuler entre l'application Web et ATP Serverless.
- Sécurité
- Toutes les données sont sécurisées en transit et au repos.
Les améliorations de conception potentielles suivantes ne sont pas décrites dans ce déploiement pour des raisons de simplicité :
- Automatisez la récupération après sinistre de l'application à l'aide des dossiers d'exploitation Azure Automation pour changer de point d'extrémité de porte d'entrée et valider l'état de l'application après basculement.
- Tirer parti d'une topologie en étoile ou Hub pour assurer une sécurité réseau centralisée.
- Tirez parti d'un pare-feu de réseau, déployé dans le concentrateur VNet, pour améliorer la sécurité globale en inspectant tout le trafic et en appliquant les politiques.
mongodb-atp-s-azure-physique-arch.zip
L'architecture comporte les composants Microsoft suivants :
- Gestionnaire de pare-feu Azure
Azure Firewall Manager est un service centralisé de gestion de la sécurité qui simplifie le déploiement et la configuration d'Azure Firewall dans plusieurs régions et abonnements. Il permet une gestion hiérarchique des politiques, permettant une application cohérente des politiques de pare-feu globales et locales. Lorsqu'il est intégré à Azure Virtual WAN (vWAN) et à un concentrateur sécurisé, Azure Firewall Manager améliore la sécurité en automatisant le routage et le filtrage du trafic sans avoir besoin de routes définies par l'utilisateur. Cette intégration garantit que le trafic entre les réseaux virtuels, les succursales et Internet est géré et surveillé en toute sécurité, offrant une solution de sécurité réseau robuste et rationalisée.
- Porte d'entrée Azure
Azure Front Door est un service en nuage qui agit comme point d'entrée mondial pour les applications Web. Il fournit une livraison de contenu haute performance, un équilibrage de charge intelligent de couche 7 et des fonctions de sécurité intégrées telles que le pare-feu d'application Web (WAF) et la protection DDoS pour assurer une expérience utilisateur rapide, fiable et sécurisée.
- Région Azure
Une région Azure est une zone géographique dans laquelle résident un ou plusieurs centres de données Azure physiques, appelés zones de disponibilité. 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).
Les régions Azure et OCI sont des zones géographiques localisées. Pour Oracle Database@Azure, une région Azure est connectée à une région OCI, avec des zones de disponibilité dans Azure connectées à des domaines de disponibilité (AD) dans OCI. Des paires de régions Azure et OCI sont sélectionnées pour réduire la distance et la latence.
- Zone de disponibilité Azure
Les zones de disponibilité Azure sont des emplacements physiquement séparés au sein d'une région Azure, conçus pour assurer une haute disponibilité et résilience en fournissant une alimentation, un refroidissement et un réseau indépendants.
- Réseau virtuel Azure (VNet)
Azure Virtual Network (VNet) est le bloc de construction fondamental de votre réseau privé dans Azure. VNet permet à de nombreux types de ressources Azure, telles que les machines virtuelles Azure, de communiquer en toute sécurité entre elles, sur Internet et sur les réseaux sur place.
- Service d'application Microsoft Azure
Le service d'applications Microsoft Azure vous permet de créer, d'héberger et d'adapter des applications Web, des API et des dorsales mobiles sans gérer l'infrastructure sous-jacente.
- Sous-réseau d'intégration du service d'application Azure
Sous-réseau dédié au sein d'un réseau virtuel Azure qui est spécifiquement délégué pour utilisation par les plans de service d'application, ce qui permet aux applications Web d'établir des connexions sortantes à des ressources privées au sein du réseau virtuel ou de ses réseaux appairés, mais pas de recevoir le trafic entrant depuis VNet.
- Sous-réseau délégué Azure
Un sous-réseau délégué vous permet d'insérer un service géré, en particulier un service de plate-forme-service (PaaS), directement dans votre réseau virtuel en tant que ressource. Vous disposez d'une gestion complète de l'intégration des services PaaS externes dans vos réseaux virtuels.
L'architecture comporte les composants Oracle suivants :
- Région OCI
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).
- Oracle Autonomous Database
Oracle Autonomous Database est un environnement de base de données préconfiguré entièrement géré que vous pouvez utiliser pour le traitement des transactions et les charges de travail d'entreposage de données. Il n'est pas nécessaire de configurer ou de gérer du matériel ni d'installer des logiciels. OCI gère la création, la sauvegarde, l'application de correctifs, la mise à niveau et le réglage de la base de données.
- Oracle Autonomous Data Guard
Oracle Autonomous Data Guard permet à une base de données de secours (pair) d'assurer la protection des données et la récupération après sinistre de votre instance Autonomous Database. Il fournit un ensemble complet de services qui créent, maintiennent, gèrent et surveillent une ou plusieurs bases de données de secours pour permettre aux bases de données Oracle de production de rester disponibles sans interruption. Oracle Data Guard tient à jour ces bases de données de secours en tant que copies de la base de production. Ensuite, si la base de données de production devient indisponible en raison d'une interruption planifiée ou non planifiée, vous pouvez basculer n'importe quelle base de données de secours vers le rôle de production, réduisant ainsi le temps d'arrêt associé à l'interruption.
- Service de stockage d'objets pour OCI
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'applications 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.
- Point d'extrémité privé OCI
Le point d'extrémité privé OCI fournit un accès sécurisé, privé et sans frais à l'un des nombreux services OCI à partir d'un réseau en nuage virtuel (VCN) ou d'un réseau sur place.
Variante d'architecture
Cette variante de l'architecture physique proposée utilise un déploiement Oracle REST Data Services géré par le client qui s'exécute dans chaque serveur d'applications. Toutefois, l'API MongoDB entièrement gérée fournie par ATP Serverless est la meilleure solution pour la plupart des charges de travail, car elle est plus facile à gérer.
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 suivant décrit 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 identique à l'architecture physique décrite précédemment.
mongodb-atp-s-azure-arch-variant.zip
- Les demandes d'utilisateur entrantes sont réparties par l'équilibreur de charge du service d'application. Le niveau frontal est donc extensible horizontalement et ne comporte pas de point de défaillance unique.
- L'application dorsale est déployée dans les programmes de l'unité d'échelle de service d'application.
- L'application est déployée à l'aide du conteneur comme méthode de publication.
- Créez, installez et configurez le conteneur avec l'application et Oracle REST Data Services, qui permet à la fois de s'exécuter dans le même conteneur.
- Chaque programme exécute l'image de conteneur qui colocalise l'application et Oracle REST Data Services dans le même environnement d'exécution.
- Les programmes Oracle REST Data Services gérés par le client sont configurés 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 l'image de conteneur utilisée par les programmes. Lorsque le service d'application évolue horizontalement, les nouveaux travailleurs peuvent exécuter l'application dorsale et se connecter à la base de données après le provisionnement.
Recommandations
- Déploiement d'application
- Envisagez d'utiliser un déploiement basé sur des conteneurs à l'aide du service Azure Kubernetes (AKS) si vous avez besoin de fonctionnalités avancées d'orchestration, de réseau et de sécurité qui pourraient ne pas être disponibles dans le service d'application.
- Sécurité
- Envisagez d'utiliser Oracle Data Safe pour renforcer la sécurité de la charge de travail et effectuer des vérifications de base de données.
- Observabilité
- Envisagez d'utiliser Azure Monitor, pour surveiller les mesures ATP Serverless ainsi que toutes les autres données de surveillance des services Azure.
- Récupération après sinistre
- Envisagez d'automatiser et d'orchestrer le sinistre et la récupération pour toutes les couches de la pile à l'aide d'Azure Site Recovery ou de scripts personnalisés qui détectent les défaillances et lancent des processus de basculement.
- Efficacité opérationnelle
- Si la charge de travail ATP Serverless fait partie d'un parc de bases de données plus large, envisagez d'utiliser des pools élastiques pour une meilleure rentabilité.
- Envisagez d'activer le service Oracle Cloud Infrastructure Database Management, un service OCI qui fournit un ensemble complet de fonctions de surveillance et de gestion de la performance des bases de données, afin de rationaliser la gestion de l'instance ATP sans serveur.
- Évolution des applications
- Envisagez de déployer 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 PowerBI, sans déplacer les données hors de la base de données, pour une analyse fiable et en temps réel des données
- Envisagez d'utiliser ATP Serverless pour l'apprentissage automatique en utilisant Oracle Machine Learning (OML), pour créer et entraîner des modèles à l'aide de données JSON sans déplacement des données et pour déployer les modèles en même temps que la charge de travail existante en cas d'inférence efficace.
- Pour d'autres cas d'utilisation au-delà du cœur de l'application, envisagez d'utiliser ATP Serverless Select AI et des vues de base de données interrogeant JSON et contenant des métadonnées, afin que les utilisateurs puissent interroger les données JSON à l'aide du langage naturel.
- Envisagez d'utiliser 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 :
Vérifiez ces ressources supplémentaires :
- Plateforme de données d'Oracle
- Documentation sur Oracle Autonomous Transaction Processing Serverless
- Services Autonomous Database pour Azure
- API Oracle Database pour MongoDB
- Utilisation de la base de données Oracle Autonomous Database sans serveur
Vérifiez ces ressources supplémentaires :