Déploiement d'une charge globale MongoDB migrée vers Oracle Autonomous JSON Database@Azure

Migrez une charge de travail existante qui utilise une base de données de documents, dans ce cas MongoDB, vers Azure et Oracle Autonomous JSON Database déployés dans Azure, un service de base de données de documents cloud qui facilite la modernisation du développement de vos applications centrées sur JSON.

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 très 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 rapide des fonctionnalités d'application, une évolution plus facile des applications et l'assurance de créer des applications et des fonctionnalités itératives plus petites que les développeurs peuvent faire évoluer 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 de tous les avantages des bases de données de documents traditionnelles, tout en tirant parti des avantages des bases de données relationnelles ? Par exemple, bénéficiez de garanties transactionnelles plus solides et utilisez des 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 JSON Database propose des API de documents de type NoSQL (Oracle Simple Oracle Document Access (SODA) et Oracle Database API for MongoDB), une mise à l'échelle sans serveur, des transactions ACID hautes performances, une sécurité complète et des tarifs à faible paiement à l'utilisation. Autonomous JSON Database automatise le provisionnement, la configuration, le réglage, la mise à l'échelle, l'application de patches, le chiffrement et la réparation des bases de données, éliminant ainsi la gestion des bases de données et offrant une disponibilité de 99,95 %.

Architecture fonctionnelle

Cette architecture suppose, comme point de départ, qu'il existe une charge globale avec une application et une base de données MongoDB, 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 pour 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 des applications existantes peut fonctionner avec les données stockées dans Oracle Autonomous JSON Database sans avoir à les refactoriser.

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.

description de l'illustration mongodb-ajd-azure-logical-arch.png,

mongodb-ajd-azure-logical-arch-oracle.zip

Une pile populaire, utilisée pour implémenter ce modèle, est la pile MEAN, utilisant MongoDB comme base de données de documents, Express comme structure back-end, Angular comme structure front-end et Node.js comme serveur back-end. Ce document utilise une pile MEAN comme exemple de déploiement existant qui sera migré vers Azure et Autonomous JSON Database.

La migration de cette charge globale vers Azure et Autonomous JSON Database est simple et comprend, à haut niveau, les étapes suivantes :

1. Déployez une instance Autonomous JSON Database, en activant l'API Oracle Database MongoDB lors de sa création.
2. Migrez les métadonnées et les données de MongoDB vers Autonomous JSON Database.
3. Déployez des serveurs d'applications pour exécuter Node.js et 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 Autonomous JSON Database.
4. Déployez le code d'application back-end sur les serveurs d'applications.
5. Connectez l'application back-end à Autonomous JSON Database en utilisant les mêmes outils et pilotes MongoDB que ceux utilisés sur l'application en cours.
6. Demandez aux utilisateurs de se connecter 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, reportez-vous à la section En savoir plus.

Une fois la charge globale migrée vers Autonomous JSON Database, vous pouvez utiliser plusieurs fonctionnalités pour augmenter les fonctionnalités existantes, que ce soit pour 1) prendre en charge des exigences non fonctionnelles supplémentaires, telles que facilement améliorer l'évolutivité, la résilience ou la haute disponibilité ou 2) disposer de fonctionnalités supplémentaires telles que le reporting opérationnel, l'analyse et le machine learning, 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 d'Autonomous JSON Database. Un appel d'API ou d'un simple clic permet à la charge globale d'utiliser jusqu'à 3 fois la capacité de référence sans aucun temps d'arrêt. Autonomous JSON Database utilise la technologie Oracle Real Application Clusters (Oracle RAC) pour la haute disponibilité. Pour le niveau back-end, utilisez des pools d'instances de calcul avec des règles de redimensionnement automatique, ce qui permet une haute disponibilité et une évolutivité des applications.

Autonomous JSON Database étant basé sur une technologie de base de données multimodèle à charges multiples, vous pouvez ajouter des fonctionnalités qui s'appuient sur des types de données relationnelles, spatiales, graphiques ou vectorielles qui fonctionnent avec l'application existante. Il est courant que les utilisateurs souhaitent effectuer des analyses sur les données JSON. L'utilisation de SQL dans Autonomous JSON Database simplifie la création de rapports opérationnels et analytiques, à l'aide du même moteur et des mêmes données.

Autonomous JSON Database a une limite de 20 Go de données non JSON. Si vos exigences en matière de volume de données changent, vous pouvez facilement effectuer la conversion vers Oracle Autonomous Database Serverless, qui prend en charge les mêmes fonctionnalités. Le stockage des vues et des vues matérialisées ne compte pas dans la limite de données non JSON Autonomous JSON Database de 20 Go, de sorte que celles-ci peuvent être facilement créées et utilisées, par exemple, pour prendre en charge les analyses opérationnelles à l'aide de SQL sur les documents JSON.

Architecture physique

L'architecture physique inclut une base de données JSON autonome déployée à l'aide de sous-réseaux délégués dans deux régions Microsoft 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 de Microsoft Azure Front Door.
  • La connexion utilisateur est sécurisée à l'aide d'Azure Web Application Firewall.
  • 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 d'Azure App Service.
  • Azure App Service AutoScale est utilisé pour atteindre une évolutivité horizontale.
• Niveau base de données
  • Autonomous JSON Database 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 pour MongoDB activée dans Autonomous JSON Database 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 en interne par Autonomous JSON Database.
  • Autonomous JSON Database peut utiliser le redimensionnement automatique, en s'adaptant aux augmentations et aux diminutions de la charge système.
  • La continuité des activités d'Autonomous JSON Database est assurée par une récupération après sinistre inter-région basée sur la sauvegarde. Vous pouvez également utiliser des clones actualisables.
• Récupération après sinistre
  • Deux régions prennent en charge la récupération après sinistre inter-région pour l'ensemble du déploiement cloud.
  • La base de données JSON autonome de la région principale dispose d'un homologue inter-région basé sur la sauvegarde sur la région secondaire.
  • 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 Autonomous JSON Database.
  • 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 de l'application à partir d'Internet et sur site est acheminé par Azure Front Door.
  • Autonomous JSON Database est déployé avec une adresse privée pour améliorer l'état de sécurité.
  • Le service d'application Azure est une application Web déployée à l'aide d'un sous-réseau d'intégration et de VNet pour atteindre l'instance Autonomous JSON Database.
  • L'application VNet est appairée à la base de données VNet et le trafic est autorisé à circuler entre l'application Web et Autonomous JSON Database.
• Sécurité
  • Toutes les données sont sécurisées en transit et à rest.
  • 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.

Le schéma suivant illustre cette architecture de référence.

Description de l'illustration mongodb-ajd-azure-physical-arch.png

mongodb-ajd-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, offrant une livraison de contenu haute performance, 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 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 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 Azure

  Azure App Service est une plate-forme en tant que service entièrement gérée (PaaS) qui permet de créer, d'héberger et de mettre à l'échelle 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.

• 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 Autonomous JSON Database est la meilleure solution pour la plupart des charges globales, 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 rest du déploiement est le même que l'architecture physique décrite précédemment.

description de l'illustration mongodb-ajd-azure-arch-variant.png,

mongodb-ajd-azure-arch-variant-oracle.zip

La section suivante décrit le niveau front-end de la variante :

• 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

Utilisez les recommandations suivantes comme point de départ pour améliorer et faire évoluer la charge de travail. Vos exigences peuvent différer de l'architecture décrite ici.

• 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 d'Autonomous JSON Database 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 Autonomous JSON Database 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 Oracle Cloud Infrastructure Database Management, un service OCI qui fournit un ensemble complet de fonctionnalités de gestion et de surveillance des performances de base de données, afin de rationaliser la gestion de l'instance Autonomous JSON Database.
• Evolution des applications
  • Envisagez de déployer des analyses opérationnelles et des rapports en temps réel dans Autonomous JSON Database à l'aide de SQL et d'un front-end tel qu'APEX ou PowerBI, sans déplacer les données hors de la base de données, pour une analyse de données fiable et en temps réel
  • Envisagez d'utiliser Autonomous JSON Database 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éplacement de données et de déployer les modèles avec la charge de travail existante pour une inférence efficace.
  • Pour d'autres cas d'utilisation au-delà du cœur de l'application, envisagez d'utiliser Autonomous JSON Database. Sélectionnez des vues d'IA et de base de données interrogeant JSON et contenant des métadonnées, afin que les utilisateurs puissent interroger des données JSON en langage naturel.
  • Envisagez d'utiliser Autonomous JSON Database pour stocker des types de données supplémentaires (relationnel, vectoriel, spatial ou graphique) jusqu'à 20 Go pour une fonctionnalité et une flexibilité de charge de travail supplémentaires.

En savoir plus

En savoir plus sur les fonctionnalités de cette architecture :

• Plate-forme de données Oracle
• Documentation sur Autonomous JSON Database
• Services Autonomous Database pour Azure
• API Oracle Database pour MongoDB
• Utilisation d'Oracle Autonomous Database Serverless
• Migration d'une base de données MongoDB exécutée sur Atlas MongoDB ou sur site vers Oracle Autonomous JSON Database (tutoriel)

Consultez les ressources supplémentaires suivantes :

• Documentation d'Oracle Cloud Infrastructure
• Structure bien conçue pour Oracle Cloud Infrastructure
• Estimateur de coût Oracle Cloud
• Structure d'adoption du cloud
• Développement d'applications modernes

Accusés de réception

• Auteurs : José Cruz
• Contributeurs : Massimo Castelli, Simon Griffith, Hermann Baer, Matt DeMarco, Julian Dontcheff