Déploiement d'une charge globale 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 de données et les applications sont populaires en raison de la flexibilité qu'elles offrent aux développeurs. La flexibilité des schémas, le développement rapide et l'évolutivité permettent un prototypage accéléré des fonctionnalités d'application, une évolution plus facile des applications et la possibilité de créer des applications et des fonctionnalités itératives plus petites que les développeurs peuvent adapter pour répondre à une grande base d'utilisateurs. Cependant, ces types de charges de travail présentent des 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, tels que les analyses ou le machine learning.
Et si ces charges de travail pouvaient bénéficier des avantages des bases de données de documents traditionnelles et tirer parti des avantages des bases de données relationnelles ? Par exemple, bénéficiez de garanties transactionnelles plus solides et de fonctionnalités supplémentaires telles que l'analyse et le machine learning, sans avoir à répliquer les données vers une autre base de données ou un autre système.
Autonomous Transaction Processing (ATP) 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 les performances, il est préconfiguré pour le format de ligne, les index et la mise en 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 rapidement et économiquement des applications sans sacrifier les fonctionnalités ou les propriétés d'atomicité, de cohérence, d'isolation et de durabilité (ACID).
Architecture fonctionnelle
Cette architecture suppose, comme point de départ, qu'une charge globale avec une application et une base de données MongoDB existe, qu'il s'agisse d'un déploiement sur site ou cloud, et qu'elle soit migrée vers Azure et Oracle Database@Azure. Il décrit l'architecture d'état future, 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 fonctionnalités clés utilisées dans cette architecture est l'API Oracle Database API for MongoDB, qui permet aux applications d'interagir avec des ensembles de documents JSON dans Oracle Database à l'aide des pilotes, outils et kits 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 représente une application standard composée d'une base de données, d'un back-end et de niveaux front-end.
mongodb-atp-s-azure-logical-arch-migration.zip
La pile MEAN est une pile populaire utilisée pour implémenter ce modèle :
- MongoDB : base de données de documents
- Express : structure back-end
- Angular : Cadre frontal
Node.js: serveur back-end
Ce document utilise une pile MEAN comme exemple de déploiement existant qui sera migré vers Azure et ATP Serverless.
La migration de cette charge globale vers Azure et ATP Serverless est simple et comprend, à haut niveau, les étapes suivantes :
- Déployez une instance ATP Serverless, en activant au moment de la création l'API Oracle Database MongoDB.
- 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 d'Azure App Service, de machines virtuelles, de conteneurs ou de Kubernetes, vers la même région et le même domaine de disponibilité que ATP Serverless. - Déployez le code d'application back-end sur les serveurs d'applications.
- Connectez l'application back-end à ATP Serverless à l'aide des mêmes outils et pilotes MongoDB que ceux utilisés sur l'application actuelle.
- 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 d'informations sur le processus de migration, reportez-vous à la section En savoir plus.
Une fois la charge globale migrée vers ATP Serverless, plusieurs fonctionnalités sont disponibles pour augmenter les fonctionnalités existantes, 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) disposer de fonctionnalités supplémentaires telles que le reporting opérationnel, les analyses et le machine learning en place, sans avoir à copier les données hors de la base de données.
Pour améliorer l'évolutivité et la haute disponibilité, utilisez la fonctionnalité de redimensionnement automatique sans serveur d'Autonomous Transaction Processing. Avec un simple clic ou un appel d'API, la charge globale peut utiliser jusqu'à 3 fois la capacité de référence sans aucun temps d'arrêt. Autonomous Transaction Processing Serverless utilise la technologie Oracle Real Application Clusters (Oracle RAC) pour la haute disponibilité. Pour le niveau back-end, utilisez des ensembles de redimensionnement de machine virtuelle Azure avec une configuration de redimensionnement automatique, ou un service PaaS tel qu'App Service avec une configuration de redimensionnement automatique pour permettre la haute disponibilité et l'évolutivité des applications.
Etant donné qu'ATP Serverless repose sur une technologie de base de données multimodèle et à charge de travail multiples, vous pouvez ajouter des fonctionnalités qui s'appuient sur des types de données relationnelles, spatiales, graphiques ou vectorielles qui fonctionnent en parallèle 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 de l'application peuvent se connecter à partir d'Internet ou du réseau de l'entreprise.
- La connexion utilisateur est acheminée vers la région active qui exécute l'application à l'aide d'Azure Front Door.
- La connexion utilisateur est sécurisée à l'aide du pare-feu d'applications Web Azure.
- La connexion utilisateur à l'application est équilibrée à l'aide du service d'application.
- Niveau back-end
- L'application est déployée en haute disponibilité à l'aide du service d'application Azure.
- Le service d'application Azure AutoScale permet d'atteindre une évolutivité horizontale.
- Niveau base de données
- ATP Serverless fournit une haute disponibilité, car Oracle Real Application Clusters (Oracle RAC) et plusieurs noeuds de base de données sous-tendent l'instance de service. Par défaut, le niveau de base de données est hautement disponible et résilient.
- L'API Oracle Database API for MongoDB activée 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'adaptant aux augmentations et aux diminutions de la charge du système.
- La continuité des activités sans serveur ATP est assurée par Autonomous Data Guard inter-région.
- 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 récupération après sinistre à chaud pour réduire le RTO global. Dans le cadre d'une stratégie de récupération après sinistre à chaud, les ressources cloud de niveau back-end sont déjà provisionnées avec la base de données de secours ATP Serverless.
- Vous pouvez également provisionner les ressources de niveau back-end en cas de panne, ce qui réduit le coût d'exécution des ressources de récupération après sinistre tout en augmentant le RTO global.
- Fonctions de réseau
- Tout le trafic entrant d'application à partir d'Internet et sur site est acheminé par Azure Front Door.
- ATP Serverless est déployé avec une adresse privée pour améliorer l'état de sécurité.
- L'application Web Azure App Service est déployée à l'aide d'un sous-réseau d'intégration et de VNet pour atteindre l'instance ATP Serverless.
- 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 des applications à l'aide des guides d'exploitation Azure Automation pour changer d'adresse de porte avant et valider l'état de l'application après basculement.
- Exploiter une topologie hub et spoke pour assurer la sécurité réseau centralisée.
- Tirez parti d'un pare-feu réseau déployé dans le hub VNet pour améliorer l'état de sécurité global en inspectant tout le trafic et en appliquant des stratégies.
mongodb-atp-s-azure-physical-arch.zip
L'architecture comporte les composants Microsoft suivants :
- Gestionnaire de pare-feu Azure
Azure Firewall Manager est un service de gestion de la sécurité centralisé qui simplifie le déploiement et la configuration d'Azure Firewall dans plusieurs régions et abonnements. Il permet une gestion hiérarchique des stratégies, ce qui permet d'appliquer de manière cohérente les stratégies de pare-feu globales et locales. Lorsqu'il est intégré à Azure Virtual WAN (vWAN) et à un hub sécurisé, Azure Firewall Manager améliore la sécurité en automatisant le routage et le filtrage du trafic sans avoir besoin de routages définis 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é, fournissant une solution de sécurité réseau robuste et rationalisée.
- Porte d'entrée Azure
Azure Front Door est un service cloud qui agit comme un point d'entrée mondial pour les applications Web, fournissant une livraison de contenu hautes performances, un équilibrage de charge intelligent de couche 7 et des fonctionnalités de sécurité intégrées telles que Web Application Firewall (WAF) et la protection DDoS pour assurer des expériences utilisateur rapides, fiables et sécurisées.
- Région Azure
Une région Azure est une zone géographique dans laquelle résident des centres de données Azure physiques, appelés zones de disponibilité. Les régions sont indépendantes les une des autres et peuvent les séparer d'un pays ou d'un continent à l'autre par de grandes distances.
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é dans OCI. Les paires de régions Azure et OCI sont sélectionnées pour minimiser 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 une résilience en fournissant une alimentation, un refroidissement et un réseau indépendants.
- Réseau virtuel Azure (VNet)
Le réseau virtuel Azure (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é les unes avec les autres, Internet et les réseaux sur site.
- Service d'application Microsoft Azure
Microsoft Azure App Service vous permet de créer, d'héberger et de faire évoluer des applications Web, des API et des back-ends mobiles sans gérer l'infrastructure sous-jacente.
- Sous-réseau d'intégration Azure App Service
Sous-réseau dédié au sein d'un réseau virtuel Azure qui est spécifiquement délégué pour être utilisé par les plans de service d'application, permettant aux applications Web d'établir des connexions sortantes vers des ressources privées au sein du réseau virtuel ou de ses réseaux appairés, mais de ne pas recevoir de trafic entrant à partir de 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 en tant que 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 au sein de vos réseaux virtuels.
L'architecture comporte les composants Oracle suivants :
- Région OCI
Une région OCI est une zone géographique précise qui contient des centres de données, hébergeant des domaines de disponibilité. Les régions sont indépendantes les une des autres et peuvent les séparer d'un pays ou d'un continent à l'autre par de grandes distances.
- Oracle Autonomous Database
Oracle Autonomous Database est un environnement de base de données entièrement géré et préconfiguré que vous pouvez utiliser pour le traitement des transactions et les workloads d'entreposage de données. Vous n'avez pas besoin de configurer ni de gérer un matériel, ni d'installer un logiciel. OCI gère la création, la sauvegarde, l'application de patches, 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 (homologue) de fournir une protection des données et une récupération après sinistre pour votre instance Autonomous Database. Il fournit un ensemble complet de services capables de créer, de maintenir, de gérer et d'observer des bases de données de secours pour que les bases de données Oracle de production puissent maintenir des niveaux aux sinistres et aux altérations de données sans interruption. Oracle Data Guard gère ces bases de données d'urgence en tant que copies de la base de données de production. Ensuite, si la base de données de production devient indisponible en raison d'une coupure planifiée ou non planifiée, vous pouvez basculer n'importe quelle base de données de secours vers le rôle de base de données de production, ce qui réduit le temps d'arrêt associé à la coupure.
- OCI Object Storage
OCI Object Storage fournit un accès à des quantités importantes de informations structurées et non structurées de tout type de contenu, y compris les sauvegardes de base de donnée, les données analytiques et le contenu enrichi tel que des images et des vidéos. Vous pouvez stocker des données en toute sécurité directement à partir des applications ou de la plate-forme cloud. Vous pouvez redimensionner le stockage sans dégradation des performances ni de la fiabilité de services.
Utilisez le stockage standard pour le stockage "à chaud" auquel vous devez accéder rapidement, immédiatement et fréquemment. Utilisez le stockage d'archive pour le stockage "à froid" que vous conservez durant de longues périodes et auquel il est rare d'y accéder.
- Adresse privée OCI
OCI Private Endpoint fournit un accès sécurisé, privé et gratuit à l'un des nombreux services OCI à partir d'un réseau cloud virtuel (VCN) ou d'un réseau sur site.
Variante d'architecture
Cette variante de l'architecture physique proposée utilise un déploiement Oracle REST Data Services géré par le client exécuté sur chaque serveur d'applications. Cependant, 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.
Si vous devez contrôler manuellement la configuration et la gestion d'Oracle REST Data Services, vous pouvez utiliser Oracle REST Data Services géré par le client. Par exemple, pour permettre à l'application d'utiliser des pools de connexions plus importants.
Remarques :
Utilisez cette variante d'architecture s'il existe une exigence spécifique en matière de charge globale. Seuls les utilisateurs avancés doivent déployer cette variante d'architecture.Cette section décrit uniquement les différences par rapport à l'architecture physique précédemment décrite, de sorte que tous les principes de conception de l'architecture physique sont valides, sauf indication contraire.
Le diagramme d'architecture suivant illustre le déploiement de la variante. Pour plus de simplicité, seules les ressources cloud déployées dans le VCN de charge globale 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 utilisateur entrantes sont distribuées par l'équilibreur de charge du service d'application, de sorte que le niveau frontal est évolutif horizontalement et n'a pas de point d'échec unique.
- L'application back-end est déployée dans les salariés de l'unité App Service Scale Unit.
- L'application est déployée en utilisant le conteneur comme méthode de publication.
- Créez, installez et configurez le conteneur avec l'application et Oracle REST Data Services, ce qui permet aux deux de s'exécuter dans le même conteneur.
- Chaque processus actif exécute l'image de conteneur qui colocise l'application et Oracle REST Data Services dans le même environnement d'exécution.
- Les processus actifs 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 pilotes MongoDB.
- Oracle REST Data Services, géré par le client, est configuré pour s'adapter aux exigences non fonctionnelles de la charge globale, par exemple en configurant des pools de connexions plus importants ou en utilisant un service de base de données différent.
- Le code back-end et les services Oracle REST Data Services gérés par le client sont préinstallés et préconfigurés dans l'image de conteneur utilisée sur les workers. Lorsque App Service évolue horizontalement, les nouveaux salariés peuvent exécuter l'application back-end 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 un conteneur à l'aide d'Azure Kubernetes Service (AKS) si vous avez besoin de fonctionnalités avancées d'orchestration, de mise en réseau et de sécurité qui pourraient ne pas être disponibles dans App Service.
- Sécurité
- Envisagez d'utiliser Oracle Data Safe pour améliorer encore l'état de sécurité de la charge globale et effectuer un audit de base de données.
- Observation
- 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 pannes et lancent des processus de basculement.
- Efficacité opérationnelle
- Si la charge globale ATP Serverless fait partie d'un parc de bases de données plus étendu, envisagez d'utiliser les pools élastiques pour une meilleure rentabilité.
- Envisagez d'activer Oracle Cloud Infrastructure Database Management, un service OCI qui fournit un ensemble complet de fonctionnalités de surveillance et de gestion des performances de base de données, afin de rationaliser la gestion de l'instance ATP Serverless.
- Evolution 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 des données fiable et en temps réel
- Envisagez d'utiliser ATP Serverless pour le machine learning à l'aide d'Oracle Machine Learning (OML), de créer et d'entraîner des modèles avec des données JSON sans avoir besoin de déplacer les données et de déployer les modèles avec la charge de travail existante pour une inférence efficace.
- Pour des cas d'utilisation supplémentaires au-delà du cœur de l'application, envisagez d'utiliser ATP Serverless Select AI et les vues de base de données interrogeant JSON et contenant des métadonnées, afin que les utilisateurs puissent interroger les données JSON en langage naturel.
- Envisagez d'utiliser ATP Serverless pour stocker d'autres types de données (relationnel, vectoriel, spatial ou graphique) afin d'améliorer la fonctionnalité et la flexibilité de la charge globale.
En savoir plus
En savoir plus sur les fonctionnalités de cette architecture :
Consultez les ressources supplémentaires suivantes :
- Plate-forme de données Oracle
- Documentation Oracle Autonomous Transaction Processing Serverless
- Services Autonomous Database pour Azure
- API Oracle Database pour MongoDB
- Utilisation d'Oracle Autonomous Database Serverless
Consultez les ressources supplémentaires suivantes :