Déploiement d'une charge globale MongoDB migrée vers Oracle Autonomous Transaction Processing Serverless

Migrez une charge globale existante qui utilise une base de données de documents, dans le cas présent MongoDB, vers la base de données Oracle Autonomous Transaction Processing Serverless (ATP Serverless) sur Oracle Cloud Infrastructure (OCI) pour moderniser le développement de vos applications centrées sur JSON ainsi que d'autres charges de travail multimodèles.

Les charges de travail et les applications qui utilisent des documents et des bases de données de documents pour faire évoluer les schémas de données et les applications sont populaires en raison de la flexibilité qu'elles offrent aux développeurs. La flexibilité des schémas, le développement rapide et l'évolutivité permettent un prototypage accéléré des fonctionnalités d'application, une évolution plus facile des applications et la possibilité de créer des applications et des fonctionnalités itératives plus petites que les développeurs peuvent adapter pour répondre à une grande base d'utilisateurs. Cependant, ces types de charges de travail présentent des défis, notamment des garanties transactionnelles plus faibles, la polyvalence des requêtes de données et l'incapacité à prendre en charge d'autres charges de travail sur des documents, tels que les analyses ou le machine learning.

Et si ces charges de travail pouvaient bénéficier des avantages des bases de données de documents traditionnelles et tirer parti des avantages des bases de données relationnelles ? Par exemple, bénéficiez de garanties transactionnelles plus solides et de fonctionnalités supplémentaires telles que l'analyse et le machine learning, sans avoir à répliquer les données vers une autre base de données ou un autre système.

Autonomous Transaction Processing Serverless est un service de base de données entièrement automatisé optimisé pour exécuter simultanément des charges de travail transactionnelles, analytiques et par lots. Pour accélérer les performances, il est préconfiguré pour le format de ligne, les index et la mise en cache des données, tout en offrant évolutivité, disponibilité, sécurité transparente et analyses opérationnelles en temps réel. Les développeurs d'applications et les administrateurs de base de données peuvent développer et déployer rapidement et économiquement des applications sans sacrifier les fonctionnalités ou les propriétés d'atomicité, de cohérence, d'isolation et de durabilité (ACID).

Architecture fonctionnelle

Cette architecture de référence suppose que vous disposez d'une charge de travail avec une application et une base de données MongoDB, sur site ou dans le cloud, et que vous effectuerez une migration vers OCI. Il décrit l'architecture d'état future, ses avantages, la façon dont vous pouvez la déployer et les fonctionnalités supplémentaires que vous pouvez utiliser pour augmenter la charge de travail existante.

Cette architecture de référence se concentre sur le déploiement de la charge globale migrée et non sur le processus de migration lui-même. Pour plus d'informations sur le processus de migration, reportez-vous à la section En savoir plus.

L'un des produits clés utilisés dans cette architecture est l'API Oracle Database pour MongoDB, qui permet aux applications d'interagir avec les collections de documents JSON dans Oracle Database à l'aide des pilotes, outils et kits SDK MongoDB. Cela permet au code d'application existant de travailler avec des données stockées dans Autonomous Transaction Processing Serverless (ATP Serverless) sans avoir à refactoriser le code.

Le diagramme suivant représente une application standard composée d'une base de données, de niveaux back-end et front-end.



mongodb-atp-s-logical-arch-migration-oracle.zip

La pile MEAN est une pile populaire utilisée pour implémenter ce modèle :
  • MongoDB : base de données de documents
  • Express : structure back-end
  • Angular : Cadre frontal
  • Node.js : serveur back-end

Cet exemple utilise une pile MEAN pour migrer un déploiement existant vers OCI et ATP Serverless.

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

  1. Déployez une instance ATP Serverless, activant au moment de la création l'API Oracle Database Mongo DB.
  2. Migrez les métadonnées et les données de MongoDB vers ATP Serverless.
  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é qu'ATP Serverless.
  4. Déployez le code d'application back-end sur les serveurs d'applications.
  5. Connectez l'application back-end à ATP Serverless à l'aide des mêmes outils et pilotes MongoDB que ceux utilisés sur l'application actuelle.
  6. Connectez les utilisateurs au nouvel URI d'application.

Une fois la charge de travail migrée vers ATP Serverless, plusieurs fonctionnalités sont disponibles pour augmenter les fonctionnalités existantes, que ce soit pour 1) prendre en charge des exigences non fonctionnelles supplémentaires telles que l'amélioration facile de l'évolutivité, de la résilience ou de la haute disponibilité ou 2) disposer de fonctionnalités supplémentaires telles que le reporting opérationnel, les analyses et le machine learning, sans avoir à copier les données hors de la base de données.

Pour améliorer l'évolutivité et la haute disponibilité, utilisez la fonctionnalité de redimensionnement automatique sans serveur d'Autonomous Transaction Processing. Avec un simple clic ou un appel d'API, la charge globale peut utiliser jusqu'à 3 fois la capacité de référence sans aucun temps d'arrêt. Notez qu'Autonomous Transaction Processing Serverless 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 pour assurer la haute disponibilité et l'évolutivité des applications.

Etant donné qu'Autonomous Transaction Processing Serverless repose sur une technologie de base de données multimodèle et à charges de travail multiples, vous pouvez ajouter des fonctionnalités qui s'appuient sur des types de données relationnels, spatiaux, graphiques ou vectoriels qui fonctionnent en parallèle de l'application existante.

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'OCI Web Application Firewall.
    • 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 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é qu'ATP Serverless, afin de disposer d'une colocalisation des applications et des bases de données, ce qui optimise la latence des connexions.
    • 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 ATP Serverless est placé, afin d'augmenter la résilience de la charge globale.
  • Niveau base de données
    • ATP Serverless fournit une haute disponibilité en tant qu'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 ATP Serverless 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 ATP Serverless.
    • ATP Serverless peut utiliser la mise à l'échelle automatique, en s'adaptant aux augmentations et aux diminutions de la charge du système.
    • La continuité des activités ATP Serverless est assurée grâce à la récupération après sinistre inter-région basée sur Oracle Autonomous Data Guard.
    • L'objectif de temps de récupération de secours Oracle Autonomous Data Guard inter-région est de quinze minutes et l'objectif de point de récupération d'une minute.
  • 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 région de secours prend en charge une base de données de secours à chaud où les instances cloud sont prédéployées pour réduire l'objectif de temps de récupération total (RTO).
    • ATP Serverless dans la région principale possède un homologue inter-région Oracle Autonomous Data Guard sur la région de secours
    • Le pool d'instances de niveau back-end est préconfiguré avec le nombre minimal d'instances dans le pool, et le plan de récupération après sinistre OCI Full Stack Disaster Recovery, qui automatise chaque étape du basculement, peut modifier le nombre d'instances de calcul devant être exécutées après le basculement. La configuration du redimensionnement automatique basé sur des mesures est définie pour déterminer le nombre minimal et maximal d'instances dans le pool, ainsi que les mesures utilisées pour le redimensionnement.
    • La région de secours est déployée avec une topologie similaire pour réduire l'objectif global de temps de récupération.
    • OCI Full Stack Disaster Recovery automatise le basculement de l'ensemble de la pile vers la région de secours et les basculements vers la région principale.
  • Fonctions de réseau
    • Les passerelles de routage dynamique déployées dans les deux régions sont appairées.
    • La connectivité sur site utilise à la fois Oracle Cloud Infrastructure FastConnect et le VPN site à site pour la redondance.
    • Tout le trafic entrant provenant d'un site et d'Internet 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.


mongodb-atp-s-physical-arch-oracle.zip

L'architecture comprend les composants principaux 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 d'expérience réseau plus fiable et homogènes 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.

  • Oracle Autonomous Transaction Processing Serverless

    Oracle Autonomous Transaction Processing Serverless est un service de base de données entièrement automatisé optimisé pour exécuter simultanément des charges de travail transactionnelles, analytiques et par lots. Pour accélérer les performances, il est préconfiguré pour le format de ligne, les index et la mise en cache des données, tout en offrant évolutivité, disponibilité, sécurité transparente et analyses opérationnelles en temps réel. Les développeurs d'applications et les administrateurs de base de données peuvent rapidement, facilement et de manière rentable développer et déployer des applications sans sacrifier les fonctionnalités ou les propriétés d'atomicité, de cohérence, d'isolation et de durabilité (ACID).

  • Full Stack Disaster Recovery

    Oracle Cloud Infrastructure Full Stack Disaster Recovery est un service d'orchestration et d'orchestration de la récupération après sinistre qui fournit les fonctionnalités complètes pour toutes les couches de la pile d'applications, y compris l'infrastructure, le middleware, la base de données et l'application.

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

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

Variante d'architecture physique

L'API MongoDB entièrement gérée fournie par ATP Serverless est la meilleure solution pour la plupart des charges de travail, car elle est plus facile à gérer. Cette variante de l'architecture physique utilise un déploiement Oracle REST Data Services géré par le client exécuté sur chaque serveur d'applications.

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.



mongodb-atp-s-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 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 pool. Ainsi, 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.

Prenez les éléments suivants en considération :

  • Déploiement d'application

    Utilisez un déploiement basé sur un conteneur avec Oracle Cloud Infrastructure Kubernetes Engine (OKE) si l'application peut s'exécuter dans des conteneurs.

  • Sécurité
    • Utilisez Oracle Data Safe pour améliorer encore l'état de sécurité de la charge globale et être en mesure d'effectuer un audit de base de données.
  • Observation
    • Utilisez OCI Audit pour effectuer un audit d'analyse pour tous les services OCI au-delà d'Oracle Autonomous Database Serverless.
    • Utilisez OCI Monitoring, OCI Logging et OCI Logging Analytics pour bénéficier d'une visibilité complète sur le statut d'exploitation de l'environnement.
  • Efficacité opérationnelle
    • Utilisez les pools élastiques si la charge globale JSON sans serveur ATP fait partie d'un parc de bases de données plus large pour une meilleure rentabilité.
    • Activez Oracle Cloud Infrastructure Database Management. Ce service fournit un ensemble complet de fonctionnalités de surveillance et de gestion des performances de base de données, afin de rationaliser l'instance ATP Serverless.
  • Evolution des applications
    • Déployez des analyses opérationnelles et des rapports en temps réel dans ATP Serverless à l'aide de SQL et d'un système frontal, tel qu'APEX ou 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.
    • Utilisez ATP Serverless et Oracle Machine Learning pour créer et entraîner des modèles avec des données JSON sans déplacer de données et 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 Oracle Autonomous Database Select AI et les vues de base de données en interrogeant JSON et en conservant les métadonnées. Les utilisateurs peuvent ainsi interroger des données JSON en langage naturel.
    • Utilisez ATP Serverless pour stocker des types de données supplémentaires (relationnel, vectoriel, spatial ou graphique) pour une fonctionnalité et une flexibilité accrues de la charge globale.

Accusés de réception

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