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

Migrez une charge globale 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 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 (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 une tarification à l'utilisation faible. 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 de travail avec une application et une base de données MongoDB, qu'il s'agisse d'un déploiement on-premise ou cloud, et qu'elle soit migrée vers OCI. Il décrit l'architecture d'état future, ses avantages, comment elle peut être déployée et quelles fonctionnalités supplémentaires peuvent être utilisées pour augmenter la charge de travail 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 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 niveau back-end et d'un niveau front-end.


Description de l'image 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 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 OCI et Autonomous JSON Database.

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

  1. Déploiement d'une instance Autonomous JSON Database, activation lors de la création de l'API Oracle Database Mongo DB
  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 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, qui, avec un seul clic ou un appel d'API, 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, des fonctionnalités supplémentaires reposant 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 sur les données JSON et utiliser SQL dans Autonomous JSON Database, ce qui 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, mais peut facilement être converti en Autonomous Transaction Processing sans serveur, prenant en charge les mêmes fonctionnalités, si les exigences 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 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 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 de l'application peuvent se connecter à partir d'Internet ou du réseau de l'entreprise
    • La connexion utilisateur est sécurisée à l'aide d'un pare-feu d'applications Web
    • La connexion utilisateur à l'application est équilibrée en charge pour une résilience et une évolutivité accrues
    • L'équilibreur de charge est déployé avec une haute disponibilité
  • Niveau back-end
    • Les serveurs d'applications sont déployés en haute disponibilité à l'aide d'un pool d'instances
    • Le pool d'instances est utilisé avec le redimensionnement automatique pour atteindre une évolutivité horizontale
    • Le pool d'instances est configuré pour déployer des instances dans le même domaine de disponibilité que la base de données JSON autonome, afin de disposer d'une colocalisation des applications et des bases de données, ce qui optimise la latence de connexion
    • Le pool d'instances est configuré pour répartir les instances entre les domaines de pannes du même domaine de disponibilité que celui dans lequel la base de données JSON Autonomous est placée, afin d'augmenter la résilience de la charge globale
  • 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.
    • Pour réduire le RTO global, vous pouvez utiliser une stratégie de récupération après sinistre à chaud, dans laquelle les ressources cloud de niveau back-end sont déjà provisionnées, ainsi que 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.
    • Les améliorations potentielles de la conception non décrites dans ce déploiement pour simplifier comprennent l'utilisation d'OCI Full Stack Disaster Recovery pour automatiser la récupération après sinistre pour l'équilibreur de charge et le niveau back-end.
  • Fonctions de réseau
    • Les passerelles de routage dynamique déployées dans les deux régions sont appairées.
    • La connectivité on-premise utilise à la fois OCI FastConnect et le VPN site à site pour la redondance.
    • Tout le trafic entrant en provenance d'Internet et sur site est d'abord acheminé vers le VCN hub, puis vers le VCN de charge de travail.
    • Utilise une conception de réseau hub et satellite pour améliorer l'état de sécurité et prendre en charge d'autres réseaux cloud virtuels de charge globale.
    • Les services sont déployés avec des adresses privées pour améliorer l'état de sécurité.
    • Le VCN de charge globale JSON est divisé en plusieurs sous-réseaux privés pour améliorer l'état de sécurité.
  • Sécurité

    Toutes les données sont sécurisées en transit et au repos.

  • Les améliorations potentielles de la conception non décrites dans ce déploiement pour des raisons de simplicité incluent l'utilisation d'une zone de renvoi complète conforme au CIS et l'utilisation d'un pare-feu réseau déployé dans le VCN hub. Un pare-feu réseau améliorera la sécurité globale en inspectant tout le trafic et en appliquant des stratégies.

Le schéma suivant illustre cette architecture.


Description de l'image 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 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.

  • Réseau cloud virtuel (VCN) et sous-réseaux

    Un VCN est un réseau personnalisable défini par logiciel que vous configurez dans une région OCI. Comme les Réseaux de centre de données traditionnels, les Réseaux cloud virtuels vous donnent un contrôle sur l'environnement réseau. Un VCN peut comporter plusieurs blocs de routage interdomaine sans classe (CIDR) qui ne se chevauchent pas et que vous pouvez modifier une fois le VCN créé. Vous pouvez segmenter un réseau cloud virtuel en plusieurs sous-réseaux ciblant une région ou un domaine de disponibilité. Chaque sous-réseau est composé d'une plage contiguë d'adresses qui ne chevauchent pas celles des autres sous-réseaux du réseau cloud 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 offre davantage d'options de bande passante et de fonctiosn de réseau plus fiables et homogène par rapports aux connexions Internet.

  • Passerelle de routage dynamique

    Le DRG est un routeur virtuel qui fournit un chemin pour le trafic de réseau privé entre les réseaux cloud virtuels d'une 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 site ou un réseau dans un autre fournisseur cloud.

  • Passerelle NAT (Network Address translation)

    Une passerelle NAT permet aux ressources privées d'un VCN d'accéder aux hôtes sur Internet, sans exposer ces ressources aux connexions Internet entrantes.

  • Passerelle de service

    Une passerelle de service fournit un accès à partir d'un VCN à d'autres services, tels qu'Oracle Cloud Infrastructure Object Storage. Le trafic entre le VCN et le service Oracle passe par la structure réseau Oracle et ne traverse pas Internet.

  • Passerelle Internet

    Une passerelle Internet permet le trafic entre les sous-réseaux publics d'un VCN et le réseau Internet public.

  • Equilibreur de charge

    Oracle Cloud Infrastructure Load Balancing fournit une distribution automatisée du trafic à partir d'un point d'entrée unique vers plusieurs serveurs.

  • Pare-feu d'applications Web

    Oracle Cloud Infrastructure Web Application Firewall (WAF) est un service d'application en périphérie basé sur les régions et attaché à un point d'application, tel qu'un équilibreur de charge ou un nom d'application Web, compatible avec le secteur des cartes de paiement (PCI). WAF protège les applications du trafic Internet malveillant et indésirable. WAF peut protéger toutes les adresses Internet, en assurant l'exécution cohérente des règles sur l'ensemble de vos applications.

  • Serveur d'applications

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

  • API Oracle Database pour MongoDB

    L'API Oracle Database pour MongoDB permet aux applications d'interagir avec les collections de documents JSON dans Oracle Database à l'aide des pilotes, outils et kits SDK MongoDB.

  • Autonomous JSON Database

    Oracle Autonomous JSON Database est un service d'une base de données de document cloud qui facilite le développement d'applications centrées sur le JSON. Il propose des API de documents simples, une mise à l'échelle sans serveur, des transactions ACID hautes performances, une sécurité complète et une tarification à l'utilisation faible. Autonomous JSON Database automatise le provisionnement, la configuration, le réglage, le redimensionnement, l'application de patches, le cryptage et le réparation de la base de données.

  • Stockage d'objet

    OCI Object Storage fournit un accès à des quantités importantes de informations structurées et non, 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 les données directement à partir d'Internet ou de la plate-forme cloud, de manière sécurisée. 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.

Variante d'architecture

L'API MongoDB entièrement gérée fournie par Autonomous JSON Database est la meilleure solution pour la plupart des workloads, 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 ci-dessous 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 le même que décrit précédemment.


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

mongodb-json-arch-variant-oracle.zip

Le niveau frontal de la variante est le suivant :
  • Le code d'application back-end est déployé dans des serveurs d'applications qui font partie d'un pool d'instances.
  • Les demandes utilisateur entrantes sont distribuées par l'équilibreur de charge, de sorte que le niveau frontal est évolutif horizontalement et n'a pas de point d'échec 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 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 le service Oracle REST Data Services géré par le client sont préinstallés et préconfigurés dans la configuration d'instance utilisée par le pool, de sorte que chaque fois qu'une instance est ajoutée au pool, elle peut exécuter le back-end 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 exigences 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 dans le VCN. Utilisez des blocs CIDR qui se trouvent dans l'espace d'adressage IP privé standard.

    Sélectionnez des blocs CIDR qui ne chevauchent aucun autre réseau (dans Oracle Cloud Infrastructure, votre centre de données sur site ou un autre fournisseur cloud) sur lequel vous prévoyez 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 de vos exigences en matière de flux de trafic et de sécurité. Associez 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 être exécutée dans des conteneurs.

  • Sécurité

    Envisagez d'utiliser Data Safe pour améliorer encore l'état de sécurité de la charge globale et être en mesure d'effectuer des audits de base de données.

  • Observation
    • Envisagez d'utiliser OCI Audit pour effectuer un audit d'analyse pour tous les services OCI au-delà d'Autonomous JSON Database.
    • Envisagez d'utiliser Monitoring, Logging et Logging Analytics pour bénéficier d'une visibilité complète sur le statut de fonctionnement de l'environnement.
  • Récupération après sinistre

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

  • Efficacité opérationnelle
    • Envisagez d'utiliser des pools élastiques si la charge de travail JSON autonome fait partie d'un parc de bases de données plus large, pour une meilleure rentabilité.
    • Envisagez d'activer 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 AJD.
  • 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 système frontal tel qu'APEX ou Oracle Analytics Cloud, 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 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 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électionner 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, afin d'augmenter la fonctionnalité et la flexibilité de la charge de travail.

En savoir plus

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

Consultez les ressources supplémentaires suivantes :

Accusés de réception

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