Déployer une charge de travail 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ée dans Azure, un service de base de données de documents en nuage 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 et les applications de données sont très 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 rapide des fonctions d'application, une évolution plus facile des applications et l'assurance 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 de tous les avantages des bases de données documentaires 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 l'apprentissage automatique, sans avoir à répliquer les données vers une autre base de données ou un autre système.

Autonomous JSON Database comporte des API de document de type NoSQL (Oracle Simple Oracle Document Access (SODA) et l'API Oracle Database pour MongoDB), une mise à l'échelle sans serveur, des transactions ACID haute performance, une sécurité complète et une tarification à l'utilisation faible. Le service Autonomous JSON Database automatise le provisionnement, la configuration, le réglage, la mise à l'échelle, l'application de correctifs, 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'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 fonctions supplémentaires que vous pouvez utiliser pour augmenter la charge de travail existante.

L'une des principales caractéristiques utilisées 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. Le code d'application existant peut fonctionner avec les données stockées dans Oracle Autonomous JSON Database sans avoir à le refactoriser.

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.


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

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

Une pile populaire, utilisée pour mettre en oeuvre ce modèle, est la pile MEAN, utilisant MongoDB comme base de données de document, Express comme cadre dorsal, Angular comme cadre frontal et Node.js comme serveur dorsal. Ce document utilise une pile MEAN comme exemple d'un déploiement existant qui sera migré vers Azure et Autonomous JSON Database.

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

  1. Déployez une instance Autonomous JSON Database, ce qui permet, au moment de la création, d'activer l'API MongoDB pour Oracle Database.
  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 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 Autonomous JSON Database.
  4. Déployez le code d'application dorsal sur les serveurs d'applications.
  5. Connectez l'application dorsale à une base de données JSON autonome à l'aide des mêmes outils et pilotes MongoDB que l'application courante.
  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, consultez la section Explorer plus.

Une fois la charge de travail migrée vers une base de données JSON autonome, vous pouvez utiliser plusieurs fonctions pour augmenter la fonctionnalité existante, que ce soit 1) pour 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) 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 d'Autonomous JSON Database. Un simple clic ou un appel d'API permet à la charge de travail d'utiliser jusqu'à 3 fois la capacité de base sans aucun temps d'arrêt. Notez qu'Autonomous JSON Database utilise la technologie Oracle Real Application Clusters (Oracle RAC) pour une haute disponibilité. Pour le niveau dorsal, utilisez des groupes d'instances de calcul avec des règles d'ajustement automatique, ce qui permet la haute disponibilité et l'extensibilité des applications.

Comme Autonomous JSON Database est construit sur une technologie de base de données multimodèle à 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. Il est fréquent que les utilisateurs veuillent effectuer des analyses en plus des 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.

La base de données Autonomous JSON Database a une limite de 20 Go de données non JSON. Si vos besoins en volume de données changent, vous pouvez facilement passer à Oracle Autonomous Database Serverless, qui prend en charge les mêmes fonctions. Le stockage des vues et des vues matérialisées ne compte pas pour la limite de données non JSON d'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 l'analyse opérationnelle à l'aide de SQL en plus des documents JSON.

Architecture physique

L'architecture physique comprend 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 afin de 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 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 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'applications Azure.
    • Azure App Service AutoScale est utilisé pour atteindre l'évolutivité horizontale.
  • Niveau de base de données
    • La base de données Autonomous JSON Database assure 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 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 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 à l'interne par Autonomous JSON Database.
    • Autonomous JSON Database peut utiliser l'ajustement automatique, en s'ajustant aux augmentations et aux diminutions de la charge du système.
    • La continuité des activités avec Autonomous JSON Database est assurée par la récupération après sinistre inter-région basée sur des sauvegardes. Vous pouvez également utiliser des clones actualisables.
  • 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 base de données JSON autonome de la région principale dispose d'un pair 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 reprise après sinistre chaude pour réduire l'ODR global. Dans le cadre d'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 Autonomous JSON Database.
    • 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 de l'application à partir des locaux et d'Internet est acheminé par Azure Front Door.
    • La base de données Autonomous JSON Database est déployée avec un point d'extrémité privé pour renforcer la 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 la base de données JSON autonome.
  • Sécurité
    • Toutes les données sont sécurisées en transit et chez 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 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.

Le diagramme suivant illustre cette architecture de référence.


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

mongodb-ajd-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 sert de point d'entrée mondial pour les applications Web, offrant une livraison de contenu haute performance, un équilibrage de charge intelligent de la 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 Azure

    Azure App Service est une plateforme-service (PaaS) entièrement gérée qui permet de créer, d'héberger et d'adapter des applications Web, des API et des serveurs dorsaux 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).

  • 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 exécuté dans chaque serveur d'applications. Toutefois, l'API MongoDB entièrement gérée fournie par Autonomous JSON Database 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 rest du déploiement est le même que l'architecture physique décrite précédemment.


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

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

Ce qui suit décrit le niveau frontal de la variante :
  • Les demandes entrantes des utilisateurs sont réparties par l'équilibreur de charge du service d'application. Ainsi, le niveau frontal est horizontalement évolutif et n'a 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

Utilisez les recommandations suivantes comme point de départ pour améliorer et faire évoluer la charge globale. Vos exigences peuvent différer de l'architecture décrite ici.
  • 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 de la base de données JSON autonome 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 de la base de données JSON autonome fait partie d'un parc de bases de données plus large, envisagez d'utiliser des groupes élastiques pour une efficacité accrue des coûts.
    • Envisagez d'activer le service Oracle Cloud Infrastructure Database Management, un service OCI qui fournit un jeu complet de fonctions de surveillance et de gestion de la performance des bases de données, pour rationaliser la gestion de l'instance Autonomous JSON Database.
  • Évolution 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'une application frontale telle qu'APEX ou PowerBI, sans déplacer les données de la base de données, pour une analyse fiable et en temps réel des données
    • Envisagez d'utiliser Autonomous JSON Database pour l'apprentissage automatique à l'aide d'Oracle Machine Learning (OML), pour créer et entraîner des modèles avec des données JSON sans aucun besoin de déplacement des données et pour déployer les modèles en même temps que la charge de travail existante afin d'en déduire efficacement.
    • Pour d'autres cas d'utilisation au-delà du coeur d'application, envisagez d'utiliser Autonomous JSON Database. Sélectionnez l'intelligence artificielle et les vues de base de données qui interrogent JSON et contiennent des métadonnées, afin que les utilisateurs puissent interroger les données JSON à l'aide du 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 plus de fonctionnalité et de flexibilité de charge de travail.

Informations complémentaires

En savoir plus sur les caractéristiques de cette architecture :

Vérifiez ces ressources supplémentaires :

Remerciements

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