Déployer une charge de travail MongoDB migrée vers Oracle Autonomous JSON Database

Migrez une charge de travail existante qui utilise une base de données de documents, dans ce cas MongoDB, vers Oracle Autonomous JSON Database sur Oracle Cloud Infrastructure (OCI) pour moderniser le 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 (Simple Oracle Document Access (SODA) et 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 OCI. 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 qui peuvent être utilisées 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 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 niveau dorsal et d'un niveau frontal.


Description de mongodb-json-logical-arch-migration.png
Description de l'illustration mongodb-json-logical-arch-migration.png

mongodb-json-logical-arch-migration-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 de déploiement existant qui sera migré vers OCI et une base de données JSON autonome.

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

  1. Déployer une instance Autonomous JSON Database, ce qui permet lors de la création de l'API Mongo DB d'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 de machines virtuelles, de 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, qui, en un seul clic ou appel d'API, permet à la charge de travail d'utiliser jusqu'à 3 fois la capacité de référence, 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, afin d'assurer 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, des fonctions supplémentaires qui s'appuient sur des types de données relationnelles, spatiales, graphiques ou vectorielles peuvent être ajoutées, en collaboration avec l'application existante. Il est courant que les utilisateurs souhaitent effectuer des analyses en plus des données JSON, et utiliser 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 JSON autonome a une limite de 20 Go de données non JSON, mais peut facilement être convertie en base de données Autonomous Transaction Processing sans serveur, ce qui prend en charge les mêmes fonctions si les exigences en matière de volume de données changent. Notez que 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 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
    • 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 une mise à l'échelle automatique pour obtenir une extensibilité horizontale
    • Le groupe d'instances est configuré pour déployer des instances dans le même domaine de disponibilité que la base de données Autonomous JSON Database, afin d'avoir une colocalisation d'application et de base 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ù se trouve la base de données Autonomous JSON Database, afin d'augmenter la résilience de la charge de travail
  • 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 Autonomous JSON Database dans la région principale a 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.
    • Pour réduire l'ODR global, vous pouvez utiliser une stratégie de reprise après sinistre à chaud, dans laquelle les ressources en nuage de niveau dorsal sont déjà provisionnées, en plus de 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.
    • Les améliorations de conception potentielles qui ne sont pas décrites dans ce déploiement pour simplifier comprennent l'utilisation de la récupération après sinistre de pile complète OCI pour automatiser la récupération après sinistre pour l'équilibreur de charge et le niveau dorsal.
  • 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 OCI FastConnect et RPV site à site pour la redondance.
    • Tout le trafic entrant à partir des locaux et d'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.

Le diagramme suivant illustre cette architecture.


Description de mongodb-json-physical-arch.png
Description de l'illustration mongodb-json-physical-arch.png

mongodb-json-physical-arch-oracle.zip

L'architecture comporte les 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.

  • Serveur d'application

    Les serveurs d'applications utilisent un pair secondaire qui, comme la base de données, prend en charge le traitement en cas de sinistre. Les serveurs d'applications utilisent la configuration et les métadonnées qui sont stockées à la fois dans la base de données et dans le système de fichiers. La mise en grappe des serveurs d'applications fournit une protection dans la portée d'une seule région, mais les modifications continues et les nouveaux déploiements doivent être répliqués à l'emplacement secondaire sur une base continue pour une reprise après sinistre cohérente.

  • 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.

  • Autonomous JSON Database

    Oracle Autonomous JSON Database est un service de base de données de documents dans le nuage qui facilite le développement d'applications centrées sur JSON. Il propose des API de documents simples, une mise à l'échelle sans serveur, des transactions ACID haute performance, une sécurité complète et une tarification à l'utilisation faible. Autonomous JSON Database automatise le provisionnement, la configuration, le réglage, l'ajustement, l'application de correctifs, le chiffrement et la réparation de la base de données.

  • 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.

Variante d'architecture

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 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.


Description de mongodb-json-arch-variant.png
Description de l'illustration mongodb-json-arch-variant.png

mongodb-json-arch-variant-oracle.zip

Voici le niveau frontal de la variante :
  • 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 les services Oracle REST Data Services gérés 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

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

    Lorsque vous créez un VCN, déterminez le nombre de blocs CIDR requis et la taille de chaque bloc en fonction du nombre de ressources que vous prévoyez d'attacher aux sous-réseaux du VCN. Utilisez des blocs CIDR qui se trouvent dans l'espace d'adresses IP privées standard.

    Sélectionnez les blocs CIDR qui ne chevauchent aucun autre réseau (dans Oracle Cloud Infrastructure, votre centre de données sur place ou un autre fournisseur de services infonuagiques) auquel vous avez l'intention de configurer des connexions privées.

    Après avoir créé un VCN, vous pouvez modifier, ajouter et supprimer ses blocs CIDR.

    Lorsque vous concevez les sous-réseaux, tenez compte du flux de trafic et des exigences de sécurité. Attachez toutes les ressources d'un niveau ou d'un rôle spécifique au même sous-réseau, ce qui peut servir de limite de sécurité.

  • Déploiement d'application

    Envisagez d'utiliser un déploiement basé sur des conteneurs à l'aide d'Oracle Kubernetes Engine (OKE) si l'application peut s'exécuter dans des conteneurs.

  • Sécurité

    Envisagez d'utiliser le service de sécurité des données pour renforcer la sécurité de la charge de travail et être en mesure d'effectuer des vérifications de base de données.

  • Observabilité
    • Envisagez d'utiliser OCI Audit pour effectuer un audit médico-légal pour tous les services OCI au-delà de Autonomous JSON Database.
    • Envisagez d'utiliser Monitoring, Logging et Logging Analytics pour avoir une visibilité complète du statut de fonctionnement de l'environnement.
  • Récupération après sinistre

    Envisagez d'utiliser OCI Full Stack Disaster Recovery pour automatiser et orchestrer le sinistre et la récupération de toutes les couches de la pile.

  • Efficacité opérationnelle
    • Envisagez d'utiliser des groupes élastiques si la charge de travail Autonomous JSON Workload fait partie d'un parc de bases de données plus large, pour une rentabilité accrue.
    • Envisagez d'activer 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, pour rationaliser la gestion des instances AJD.
  • É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 solution frontale telle qu'APEX ou Oracle Analytics Cloud, 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 l'apprentissage automatique à l'aide d'Oracle Machine Learning (OML) afin de créer et d'entraîner des modèles avec des données JSON sans déplacement des données et de déployer les modèles en même temps que la charge de travail existante pour une déduction efficace
    • Pour d'autres cas d'utilisation au-delà du coeur d'application, envisagez d'utiliser Autonomous JSON Database. Sélectionner 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 une charge de travail plus fonctionnelle et plus de flexibilité.

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