Distribuire un carico di lavoro MongoDB migrato in Oracle Autonomous Transaction Processing Serverless

Esegui la migrazione di un carico di lavoro esistente che utilizza un database di documenti, in questo caso MongoDB, nel database Oracle Autonomous Transaction Processing Serverless (ATP Serverless) su Oracle Cloud Infrastructure (OCI) per modernizzare lo sviluppo delle tue applicazioni incentrate su JSON insieme ad altri carichi di lavoro multi-modello.

I carichi di lavoro e le applicazioni che utilizzano documenti e database di documenti per evolvere schemi e applicazioni di dati sono popolari grazie alla flessibilità che offrono agli sviluppatori. La flessibilità dello schema, lo sviluppo rapido e la scalabilità consentono la prototipazione accelerata delle funzioni dell'applicazione, una più semplice evoluzione delle applicazioni e la possibilità di creare applicazioni e funzionalità iterativamente più piccole che gli sviluppatori possono scalare per soddisfare una vasta base di utenti. Tuttavia, questi tipi di carichi di lavoro hanno le loro sfide, tra cui garanzie transazionali più deboli, versatilità delle query sui dati e incapacità di supportare altri carichi di lavoro su documenti, come analytics o machine learning.

Cosa succede se questi carichi di lavoro possono trarre vantaggio dai vantaggi dei database di documenti tradizionali e sfruttare i vantaggi dei database relazionali? Ad esempio, hai garanzie transazionali più solide e funzionalità aggiuntive come analytics e machine learning, senza la necessità di replicare i dati in un altro database o sistema.

Autonomous Transaction Processing Serverless è un servizio di database completamente automatizzato ottimizzato per eseguire contemporaneamente carichi di lavoro transazionali, analitici e batch. Per accelerare le prestazioni, è preconfigurato per il formato di riga, gli indici e l'inserimento dei dati nella cache, fornendo al contempo scalabilità, disponibilità, sicurezza trasparente e analytics operativi in tempo reale. Gli sviluppatori di applicazioni e i DBA possono sviluppare e distribuire applicazioni in modo rapido ed economico senza sacrificare le proprietà ACID (funzionalità o atomicità, coerenza, isolamento e durata).

Architettura funzionale

Questa architettura di riferimento si basa sul presupposto che Voi abbiate un carico di lavoro con un'applicazione e un database MongoDB, sia on-premise che nel cloud, e la migrazione a OCI. Descrive l'architettura di stato futura, i vantaggi, le modalità di distribuzione e le funzioni aggiuntive che è possibile utilizzare per aumentare il carico di lavoro esistente.

Questa architettura di riferimento si concentra sulla distribuzione del carico di lavoro migrato e non sul processo di migrazione stesso. Per ulteriori dettagli sul processo di migrazione, vedere la sezione Scopri di più.

Uno dei prodotti chiave utilizzati in questa architettura è Oracle Database API for MongoDB, che consente alle applicazioni di interagire con raccolte di documenti JSON in Oracle Database utilizzando driver, strumenti e SDK MongoDB. Ciò consente al codice dell'applicazione esistente di funzionare con i dati memorizzati in Autonomous Transaction Processing Serverless (ATP Serverless) senza la necessità di rifattorizzare il codice.

Il diagramma seguente mostra un'applicazione tipica composta da un database, livelli back-end e front-end.


Segue la descrizione di mongodb-atp-s-logical-arch-migration.png
Descrizione dell'illustrazione mongodb-atp-s-logical-arch-migration.png

mongodb-atp-s-logico-arch-migrazione-oracle.zip

Lo stack MEAN è uno stack popolare utilizzato per implementare questo pattern:
  • MongoDB: database dei documenti
  • Express: framework backend
  • Angolare: Struttura frontale
  • Node.js: server backend

In questo esempio viene utilizzato uno stack MEAN per eseguire la migrazione di una distribuzione esistente a OCI e ATP Serverless.

La migrazione di questo carico di lavoro a OCI e ATP Serverless è semplice e consiste, ad alto livello, nei seguenti passaggi:

  1. Distribuire un'istanza ATP Serverless, abilitando al momento della creazione l'API DB Oracle Database Mongo.
  2. Eseguire la migrazione dei metadati e dei dati da MongoDB ad ATP Serverless.
  3. Distribuisci gli application server per eseguire Node.js ed Express utilizzando VM, container o Kubernetes, nello stesso dominio di area e disponibilità di ATP Serverless.
  4. Distribuire il codice dell'applicazione backend negli Application Server.
  5. Connettere l'applicazione backend ad ATP Serverless utilizzando gli stessi strumenti e driver MongoDB utilizzati nell'applicazione corrente.
  6. Connettere gli utenti al nuovo URI applicazione.

Dopo la migrazione del carico di lavoro su ATP Serverless, sono disponibili diverse funzioni per aumentare le funzionalità esistenti, indipendentemente dal fatto che ciò sia 1) supportare requisiti non funzionali aggiuntivi come migliorare facilmente la scalabilità, la resilienza o l'alta disponibilità o 2) disporre di funzionalità aggiuntive come reporting operativo, analytics e machine learning in atto, senza la necessità di copiare i dati dal database.

Per migliorare la scalabilità e l'alta disponibilità, utilizza la funzione di ridimensionamento automatico serverless di Autonomous Transaction Processing. Con un singolo clic o una chiamata API, consente al carico di lavoro di utilizzare fino a 3 volte la capacità di base senza tempi di inattività. Si noti che Autonomous Transaction Processing Serverless utilizza la tecnologia Oracle Real Application Clusters (Oracle RAC) per l'alta disponibilità. Per il livello backend, utilizza i pool di istanze di computazione con regole di scalabilità automatica per abilitare l'alta disponibilità e la scalabilità delle applicazioni.

Poiché Autonomous Transaction Processing Serverless si basa sulla tecnologia di database multi-modello e multi-carico di lavoro, puoi aggiungere funzionalità che si basano su tipi di dati relazionali, spaziali, grafici o vettoriali che funzionano insieme all'applicazione esistente.

Architettura fisica

L'architettura fisica include subnet pubbliche e private in OCI con un'area di backup secondaria per supportare l'alta disponibilità.

L'architettura supporta quanto segue:

  • Livello front-end
    • Gli utenti dell'applicazione possono connettersi da Internet o dalla rete aziendale.
    • La connessione utente è protetta mediante un Web Application Firewall OCI.
    • La connessione utente all'applicazione è bilanciata dal carico per una maggiore resilienza e scalabilità.
    • Il load balancer viene distribuito con High Availability.
  • Livello back-end
    • Gli Application Server vengono distribuiti in modalità High Availability utilizzando un pool di istanze.
    • Il pool di istanze viene utilizzato con la scalabilità automatica per ottenere la scalabilità orizzontale.
    • Il pool di istanze è configurato per distribuire le istanze nello stesso dominio di disponibilità di ATP Serverless in modo da disporre della stessa struttura logistica di data center dell'applicazione e del database, ottimizzando così la latenza della connessione.
    • Il pool di istanze è configurato per distribuire le istanze tra domini di errore nello stesso dominio di disponibilità in cui viene posizionato ATP Serverless, per aumentare la resilienza del carico di lavoro.
  • Livello database
    • ATP Serverless offre l'alta disponibilità come Oracle Real Application Clusters (Oracle RAC) e diversi nodi di database alla base dell'istanza del servizio. Pertanto, per impostazione predefinita, il livello di database è altamente disponibile e resiliente.
    • L'API Oracle Database per MongoDB abilitata in ATP Serverless consente di utilizzare il codice applicazione esistente senza modifiche.
    • Oracle Database API for MongoDB è altamente resiliente e tale resilienza è garantita internamente da ATP Serverless.
    • ATP Serverless può utilizzare la scalabilità automatica, regolandosi per aumentare e diminuire il carico di sistema.
    • La continuità aziendale serverless ATP viene raggiunta con il disaster recovery tra più aree basato su Oracle Autonomous Data Guard.
    • L'obiettivo del tempo di recupero in standby (RTO) di Oracle Autonomous Data Guard tra più aree è di quindici minuti e l'obiettivo del punto di recupero (RPO) è di un minuto.
  • Disaster recovery
    • Due region supportano il disaster recovery tra più aree per l'intera distribuzione cloud.
    • La standby region supporta un warm standby in cui le istanze cloud sono predeployed per ridurre l'obiettivo RTO (Total Recovery Time Objective).
    • ATP Serverless nella region primaria dispone di un peer tra più aree Oracle Autonomous Data Guard nella standby region
    • Il pool di istanze di livello backend è preconfigurato con una quantità minima di istanze nel pool e il piano DR OCI Full Stack Disaster Recovery, che automatizza ogni passo del failover, può modificare il numero di istanze di computazione che devono essere in esecuzione dopo il failover. La configurazione di scala automatica basata su metriche viene definita per determinare il numero minimo e massimo di istanze nel pool, nonché le metriche utilizzate per eseguire lo scale-out e lo scale-in.
    • La standby region viene implementata con una topologia simile per ridurre l'obiettivo dei tempi di recupero complessivi.
    • OCI Full Stack Disaster Recovery automatizza il failover per l'intero stack nella standby region e i fallback nella region primaria.
  • Networking
    • Viene eseguito il peering dei gateway di instradamento dinamico distribuiti in entrambe le aree.
    • La connettività on-premise sfrutta sia Oracle Cloud Infrastructure FastConnect che la VPN site-to-site per la ridondanza.
    • Tutto il traffico in entrata da on-premise e da Internet viene prima instradato nella VCN dell'hub e poi nella VCN del carico di lavoro.
    • Utilizza una progettazione di rete hub e spoke per aumentare le impostazioni di sicurezza e gestire altre reti VCN del carico di lavoro.
    • I servizi vengono distribuiti con endpoint privati per aumentare il livello di sicurezza.
    • La VCN del carico di lavoro JSON è separata in diverse subnet private per aumentare il livello di sicurezza.
  • Sicurezza
    • Tutti i dati sono sicuri in transito e in archivio.
    • I potenziali miglioramenti alla progettazione non illustrati in questa distribuzione per motivi di semplicità includono l'uso di una zona di destinazione conforme a CIS completa e l'utilizzo di un firewall di rete distribuito nella VCN hub. Un firewall di rete migliorerà il livello di sicurezza generale ispezionando tutto il traffico e applicando i criteri.

Segue la descrizione dell'immagine mongodb-atp-s-physical-arch.png
Descrizione dell'illustrazione mongodb-atp-s-physical-arch.png

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

L'architettura ha i seguenti componenti principali:

  • Area

    Un'area geografica OCI è un'area geografica localizzata che contiene uno o più data center, che ospitano domini di disponibilità. Le regioni sono indipendenti da altre regioni e vaste distanze possono separarle (tra paesi o addirittura continenti).

  • Rete e subnet cloud virtuale (VCN)

    Una VCN è una rete personalizzabile e definita dal software impostata in un'area OCI. Come le reti di data center tradizionali, le reti VCN ti danno il controllo sul tuo ambiente di rete. Una VCN può avere più blocchi CIDR (Classless Inter-Domain Routing) non sovrapposti che è possibile modificare dopo aver creato la VCN. È possibile segmentare una VCN in subnet, che possono essere definite in un'area o in un dominio di disponibilità. Ogni subnet è costituita da un intervallo contiguo di indirizzi che non si sovrappongono alle altre subnet nella VCN. È possibile modificare le dimensioni di una sottorete dopo la creazione. Una subnet può essere pubblica o privata.

  • FastConnect

    Oracle Cloud Infrastructure FastConnect crea una connessione dedicata e privata tra il tuo data center e OCI. FastConnect offre opzioni di larghezza di banda più elevata e un'esperienza di networking più affidabile se confrontata con le connessioni basate su internet.

  • Gateway di instradamento dinamico (DRG)

    Il gateway DRG è un router virtuale che fornisce un percorso per il traffico di rete privato tra le reti VCN nella stessa area, tra una VCN e una rete esterna all'area, ad esempio una VCN in un'altra area OCI, una rete on premise o una rete in un altro provider cloud.

  • Gateway NAT (Network Address Translation)

    Un gateway NAT consente alle risorse private in una VCN di accedere agli host su Internet, senza esporre tali risorse alle connessioni Internet in entrata.

  • Gateway del servizio

    Un gateway di servizi fornisce l'accesso da una VCN ad altri servizi, ad esempio Oracle Cloud Infrastructure Object Storage. Il traffico dalla VCN al servizio Oracle viaggia sul fabric di rete Oracle e non attraversa Internet.

  • Gateway Internet

    Un gateway Internet consente il traffico tra le subnet pubbliche di una VCN e la rete Internet pubblica.

  • Load balancer

    Oracle Cloud Infrastructure Load Balancing fornisce una distribuzione automatica del traffico da un unico punto di accesso a più server.

  • Web Application Firewall

    Oracle Cloud Infrastructure Web Application Firewall (WAF) è un servizio PCI (Payment Card Industry) conforme, basato su regioni e di applicazione perimetrale collegato a un punto di applicazione, ad esempio un load balancer o un nome di dominio di un'applicazione Web. WAF protegge le applicazioni da traffico Internet dannoso e indesiderato. WAF è in grado di proteggere qualsiasi endpoint che si interfaccia con Internet, garantendo un'applicazione coerente delle regole tra le tue applicazioni.

  • Oracle Autonomous Transaction Processing Serverless

    Oracle Autonomous Transaction Processing Serverless è un servizio di database completamente automatizzato ottimizzato per eseguire contemporaneamente carichi di lavoro transazionali, analitici e batch. Per accelerare le prestazioni, è preconfigurato per il formato di riga, gli indici e l'inserimento dei dati nella cache, fornendo al contempo scalabilità, disponibilità, sicurezza trasparente e analytics operativi in tempo reale. Gli sviluppatori di applicazioni e i DBA possono sviluppare e distribuire applicazioni in modo rapido, semplice ed economico senza sacrificare funzionalità o proprietà di atomicità, coerenza, isolamento e durata (ACID).

  • Full Stack Disaster Recovery

    Oracle Cloud Infrastructure Full Stack Disaster Recovery è un servizio di orchestrazione e gestione che fornisce funzionalità complete di disaster recovery per tutti i livelli di uno stack di applicazioni, tra cui infrastruttura, middleware, database e applicazione.

  • Memorizzazione degli oggetti

    Lo storage degli oggetti OCI fornisce l'accesso a grandi quantità di dati strutturati e non strutturati di qualsiasi tipo di contenuto, inclusi backup del database, dati analitici e contenuti avanzati come immagini e video. Puoi archiviare i dati in modo sicuro e sicuro direttamente da Internet o dalla piattaforma cloud. È possibile ridimensionare lo storage senza subire alcun deterioramento a livello di prestazioni o affidabilità del servizio.

    Utilizza lo storage standard per lo storage "caldo" a cui devi accedere in modo rapido, immediato e frequente. Utilizzare lo storage di archivio per lo storage "a freddo" che si conserva per lunghi periodi di tempo e a cui si accede raramente o raramente.

  • API database Oracle per MongoDB

    Oracle Database API for MongoDB consente alle applicazioni di interagire con raccolte di documenti JSON in Oracle Database utilizzando driver, strumenti e SDK MongoDB.

Variante architettura fisica

L'API MongoDB completamente gestita fornita da ATP Serverless è la soluzione migliore per la maggior parte dei carichi di lavoro poiché è più facile da gestire. Questa variante dell'architettura fisica utilizza una distribuzione di Oracle REST Data Services gestita dal cliente in esecuzione in ciascun application server.

Se è necessario controllare manualmente la configurazione e la gestione di Oracle REST Data Services, è possibile utilizzare Oracle REST Data Services gestito dal cliente. Ad esempio, per consentire all'applicazione di utilizzare connection pool più grandi.

Nota

Utilizzare questa variante dell'architettura se è necessario un carico di lavoro specifico per farlo. Solo gli utenti avanzati devono distribuire questa variante dell'architettura.

Questa sezione descrive solo le differenze rispetto all'architettura fisica descritta in precedenza, pertanto tutti i principi di progettazione dell'architettura fisica sono validi se non diversamente specificato.

Il diagramma dell'architettura riportato di seguito mostra come viene distribuita la variante. Per semplicità, vengono illustrate solo le risorse cloud distribuite nella VCN del carico di lavoro JSON, poiché il resto della distribuzione è uguale a quello descritto in precedenza.


Segue la descrizione dell'immagine mongodb-atp-s-arch-variant.png
Descrizione dell'illustrazione mongodb-atp-s-arch-variant.png

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

Di seguito è riportato il livello front-end per la variante:
  • Il codice dell'applicazione backend viene distribuito nei server applicazioni che fanno parte di un pool di istanze.
  • Le richieste utente in entrata vengono distribuite dal load balancer, pertanto il livello front-end è scalabile orizzontalmente e non presenta un singolo punto di errore.
  • Oracle REST Data Services gestito dal cliente viene installato su ciascun Application Server e configurato per abilitare l'API MongoDB, in modo che l'applicazione possa connettersi al database utilizzando gli strumenti e i driver MongoDB.
  • Oracle REST Data Services gestito dal cliente è configurato per adattarsi ai requisiti non funzionali del carico di lavoro, ad esempio configurando connection pool più grandi o utilizzando un servizio di database diverso.
  • Sia il codice backend che il codice Oracle REST Data Services gestito dal cliente sono preinstallati e preconfigurati nella configurazione dell'istanza utilizzata dal pool, in modo che ogni volta che un'istanza viene aggiunta al pool, sia in grado di eseguire il backend e connettersi al database, dopo il provisioning dell'istanza.

Suggerimenti

Utilizza i seguenti suggerimenti come punto di partenza per migliorare ed evolvere ulteriormente il carico di lavoro. I requisiti potrebbero essere diversi dall'architettura descritta qui.

Considerare quanto riportato di seguito.

  • Distribuzione applicazione

    Utilizza una distribuzione basata su container con Oracle Cloud Infrastructure Kubernetes Engine (OKE) se l'applicazione può essere eseguita in container.

  • Sicurezza
    • Utilizzare Oracle Data Safe per aumentare ulteriormente le impostazioni di sicurezza del carico di lavoro ed essere in grado di eseguire l'audit del database.
  • Osservabilità
    • Utilizza OCI Audit per eseguire l'audit forense per tutti i servizi OCI oltre Oracle Autonomous Database Serverless.
    • Utilizza OCI Monitoring, OCI Logging e OCI Logging Analytics per avere visibilità completa sullo stato operativo dell'ambiente.
  • Efficienza operativa
    • Utilizza gli Elastic Pool se il carico di lavoro JSON ATP Serverless fa parte di una flotta di database più ampia per una maggiore efficienza in termini di costi.
    • Abilita Oracle Cloud Infrastructure Database Management. Questo servizio offre un set completo di funzioni di monitoraggio e gestione delle prestazioni del database per semplificare l'istanza serverless ATP.
  • Evoluzione delle applicazioni
    • Distribuisci analytics operativi e report in tempo reale in ATP Serverless utilizzando SQL e un frontend, come APEX o Oracle Analytics Cloud, senza spostare i dati dal database per un'analisi dei dati affidabile e in tempo reale.
    • Utilizza ATP Serverless e Oracle Machine Learning per creare e addestrare modelli con dati JSON senza spostare i dati e per distribuire i modelli insieme al carico di lavoro esistente per un'inferenza efficiente.
    • Per casi d'uso aggiuntivi oltre il core dell'applicazione, prendi in considerazione l'utilizzo di Oracle Autonomous Database Select AI e delle viste di database che eseguono query su JSON e contengono metadati. Ciò consente agli utenti di eseguire query sui dati JSON utilizzando il linguaggio naturale.
    • Utilizzare ATP Serverless per memorizzare ulteriori tipi di dati (relazionali, vettoriali, spaziali o grafici) per aggiungere funzionalità e flessibilità al carico di lavoro.

Scopri di più

Scopri di più sulle caratteristiche di questa architettura e sulle architetture correlate.

Esaminare le seguenti risorse aggiuntive:

Conferme

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