Distribuire un carico di lavoro MongoDB migrato in Oracle Autonomous JSON Database

Esegui la migrazione di un carico di lavoro esistente che utilizza un database di documenti, in questo caso MongoDB, a Oracle Autonomous JSON Database su Oracle Cloud Infrastructure (OCI) per modernizzare lo sviluppo delle tue applicazioni incentrate su JSON.

I carichi di lavoro e le applicazioni che utilizzano documenti e database di documenti per evolvere schemi e applicazioni di dati sono molto popolari a causa della flessibilità che offrono agli sviluppatori. La flessibilità dello schema, lo sviluppo rapido e la scalabilità consentono la prototipazione rapida delle funzioni dell'applicazione, una più semplice evoluzione delle applicazioni e la garanzia 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.

E se questi carichi di lavoro potessero trarre vantaggio da tutti i vantaggi dei database di documenti tradizionali, ma allo stesso tempo sfruttare i vantaggi dei database relazionali? Ad esempio, hai garanzie transazionali più solide e utilizza funzionalità aggiuntive come analytics e machine learning, senza la necessità di replicare i dati in un altro database o sistema.

Autonomous JSON Database dispone di API di documenti in stile NoSQL (Simple Oracle Document Access (SODA) e Oracle Database API for MongoDB), scalabilità serverless, transazioni ACID ad alte prestazioni, sicurezza completa e prezzi pay-per-use bassi. Autonomous JSON Database automatizza il provisioning, la configurazione, l'ottimizzazione, il ridimensionamento, l'applicazione di patch, la cifratura e la riparazione dei database, eliminando la gestione del database e offrendo una disponibilità del 99,95%.

Architettura funzionale

Questa architettura si basa sul presupposto che, come punto di partenza, esista un carico di lavoro con un'applicazione e un database MongoDB, sia on-premise sia una distribuzione cloud, che verrà migrata 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.

Una delle funzioni chiave utilizzate 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. Il codice delle applicazioni esistenti può funzionare con i dati memorizzati in Autonomous JSON Database, senza doverlo rifattorizzare.

Nel diagramma seguente è illustrata un'applicazione tipica composta da un database, un back-end e un livello front-end.


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

mongodb-json-logico-arch-migrazione-oracle.zip

Uno stack popolare, utilizzato per implementare questo pattern, è lo stack MEAN, utilizzando MongoDB come database di documenti, Express come framework back-end, Angular come framework front-end e Node.js come server back-end. Questo documento utilizza uno stack MEAN come esempio di una distribuzione esistente di cui verrà eseguita la migrazione a OCI e Autonomous JSON Database.

La migrazione di questo carico di lavoro a OCI e ad Autonomous JSON Database è semplice e consiste, a livello avanzato, nei seguenti passi:

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

Tenere presente che 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, consulta la sezione Scopri di più.

Dopo la migrazione del carico di lavoro ad Autonomous JSON Database, puoi utilizzare diverse funzioni per aumentare le funzionalità esistenti, indipendentemente dal fatto che ciò sia 1) supportare requisiti non funzionali aggiuntivi, come la facilità migliorare 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 scalabilità automatica di Autonomous JSON Database, che 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 JSON Database utilizza la tecnologia Oracle Real Application Clusters (Oracle RAC) per l'alta disponibilità. Per il livello back-end, utilizza i pool di istanze di computazione, con regole di scalabilità automatica, consentendo così l'alta disponibilità e la scalabilità delle applicazioni.

Poiché Autonomous JSON Database si basa su una tecnologia di database multimodello e multiworkload, è possibile aggiungere funzionalità aggiuntive che si basano su tipi di dati relazionali, spaziali, grafici o vettoriali, lavorando a fianco dell'applicazione esistente. È comune che gli utenti vogliano eseguire analytics sui dati JSON e utilizzare SQL in Autonomous JSON Database, semplifica la creazione di report operativi e analitici utilizzando lo stesso motore e gli stessi dati.

Autonomous JSON Database ha un limite di 20 Gb di dati non JSON, ma può essere facilmente convertito in Autonomous Transaction Processing Serverless, supportando le stesse funzioni, se i requisiti del volume di dati cambiano. Tieni presente che lo storage delle viste e delle viste materializzate non viene conteggiato nel limite di dati non JSON di Autonomous JSON Database da 20 Gb, quindi possono essere facilmente creati e utilizzati, ad esempio, per supportare l'analitica operativa utilizzando SQL sopra i documenti JSON.

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
    • 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à del database Autonomous JSON, in modo da garantire la collocazione dell'applicazione e del database, ottimizzando quindi la latenza di connessione
    • Il pool di istanze è configurato per distribuire le istanze tra domini di errore nello stesso dominio di disponibilità in cui viene posizionato il database JSON autonomo, per aumentare la resilienza del carico di lavoro
  • Livello database
    • Autonomous JSON Database fornisce l'alta disponibilità come Oracle Real Application Clusters (Oracle RAC) e diversi nodi del database sono 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 Autonomous JSON Database consente di utilizzare il codice applicazione esistente senza modifiche.
    • Oracle Database API for MongoDB è altamente resiliente e tale resilienza è garantita internamente da Autonomous JSON Database.
    • Autonomous JSON Database può utilizzare il ridimensionamento automatico, adattandosi agli aumenti e alle riduzioni del carico di sistema.
    • La continuità aziendale del database JSON autonomo viene raggiunta attraverso il disaster recovery cross-area basato su backup. In alternativa, è possibile utilizzare cloni aggiornabili.
  • Disaster recovery
    • Due region supportano il disaster recovery tra più aree per l'intera distribuzione cloud.
    • Autonomous JSON Database nell'area primaria dispone di un peer tra più aree basato su backup nell'area secondaria.
    • La seconda regione viene implementata con una topologia simile per ridurre l'obiettivo complessivo dei tempi di recupero.
    • Per ridurre l'RTO complessivo, puoi utilizzare una strategia di recupero da errori irreversibili, in cui viene già eseguito il provisioning delle risorse cloud di livello back-end, insieme al database di standby Autonomous JSON Database.
    • In alternativa, è possibile eseguire il provisioning delle risorse di livello back-end in caso di errore, riducendo il costo di esecuzione delle risorse DR ma aumentando l'RTO complessivo.
    • I potenziali miglioramenti alla progettazione non descritti in questa distribuzione per semplicità includono l'uso di OCI Full Stack Disaster Recovery per automatizzare il disaster recovery per il load balancer e il livello back-end.
  • Networking
    • Viene eseguito il peering dei gateway di instradamento dinamico distribuiti in entrambe le aree.
    • La connettività on-premise utilizza sia OCI FastConnect che VPN site-to-site per la ridondanza.
    • Tutto il traffico in entrata da on-premise e da Internet viene prima instradato nella VCN 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.

Il seguente diagramma descrive l'architettura.


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

mongodb-json-physical-arch-oracle.zip

L'architettura ha i seguenti componenti:

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

  • Application server

    Gli Application Server utilizzano un peer secondario che, come il database, subentrerà all'elaborazione in caso di errore irreversibile. Gli Application Server utilizzano la configurazione e i metadati memorizzati sia nel database che nel file system. Il clustering di Application Server fornisce protezione nell'ambito di una singola area, ma le modifiche continue e le nuove distribuzioni devono essere replicate nella posizione secondaria su base continuativa per un disaster recovery coerente.

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

  • Autonomous JSON Database

    Oracle Autonomous JSON Database è un servizio in cloud di documenti database che semplifica lo sviluppo di applicazioni basate su JSON. È dotato di API di documenti semplici, scalabilità serverless, transazioni ACID ad alte prestazioni, sicurezza completa e prezzi pay-per-use bassi. Autonomous JSON Database automatizza il provisioning, la configurazione, l'ottimizzazione, il ridimensionamento, l'applicazione di patch, la cifratura e la riparazione del database.

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

Variante architettura

L'API MongoDB completamente gestita fornita da Autonomous JSON Database è la soluzione migliore per la maggior parte dei carichi di lavoro poiché è più facile da gestire.

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-json-arch-variant.png
Descrizione dell'illustrazione mongodb-json-arch-variant.png

mongodb-json-arch-variant-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

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

    Quando crei una VCN, determina il numero di blocchi CIDR necessari e la dimensione di ciascun blocco in base al numero di risorse che prevedi di collegare alle subnet nella VCN. Utilizzare blocchi CIDR che si trovano all'interno dello spazio degli indirizzi IP privati standard.

    Seleziona blocchi CIDR che non si sovrappongono a nessun'altra rete (in Oracle Cloud Infrastructure, nel tuo data center on-premise o in un altro provider cloud) a cui intendi impostare connessioni private.

    Dopo aver creato una VCN, è possibile modificare, aggiungere e rimuovere i relativi blocchi CIDR.

    Quando si progettano le subnet, considerare il flusso di traffico e i requisiti di sicurezza. Collegare tutte le risorse all'interno di un livello o ruolo specifico alla stessa subnet, che può fungere da limite di sicurezza.

  • Distribuzione applicazione

    Prendi in considerazione l'utilizzo di una distribuzione basata su container utilizzando Oracle Kubernetes Engine (OKE) se l'applicazione può essere eseguita in container.

  • Sicurezza

    Prendere in considerazione l'uso di Data Safe per aumentare ulteriormente il livello di sicurezza del carico di lavoro ed essere in grado di eseguire l'audit del database.

  • Osservabilità
    • Prendi in considerazione l'utilizzo di OCI Audit per eseguire l'audit forense per tutti i servizi OCI oltre Autonomous JSON Database.
    • Prendere in considerazione l'utilizzo di Monitoring, Logging e Logging Analytics per avere una visibilità completa dello stato operativo dell'ambiente.
  • Disaster recovery

    Prendi in considerazione l'utilizzo di OCI Full Stack Disaster Recovery per automatizzare e orchestrare il disaster recovery di tutti i livelli dello stack.

  • Efficienza operativa
    • Prendi in considerazione l'uso di Elastic Pool se il carico di lavoro Autonomous JSON fa parte di una flotta di database più ampia, per una maggiore efficienza in termini di costi.
    • Prendi in considerazione l'abilitazione di Gestione database, un servizio OCI che fornisce un set completo di funzioni di monitoraggio e gestione delle prestazioni del database, per semplificare la gestione delle istanze AJD.
  • Evoluzione delle applicazioni
    • Prendi in considerazione l'implementazione di analytics operativi e reporting in tempo reale in Autonomous JSON Database utilizzando SQL e un front-end come APEX o Oracle Analytics Cloud, senza spostare i dati dal database, per un'analisi dei dati affidabile e in tempo reale
    • Prendi in considerazione l'utilizzo di Autonomous JSON Database per il machine learning utilizzando Oracle Machine Learning (OML), per creare e addestrare modelli con dati JSON senza la necessità di spostamento dei 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 Autonomous JSON Database. Selezionare le viste AI e database che eseguono query su JSON e contengono metadati, in modo che gli utenti possano eseguire query sui dati JSON utilizzando il linguaggio naturale
    • Prendi in considerazione l'uso di Autonomous JSON Database per memorizzare ulteriori tipi di dati (relazionali, vettoriali, spaziali o grafici), fino a 20 Gb, per aggiungere funzionalità e flessibilità del carico di lavoro.

Scopri di più

Scopri di più sulle caratteristiche di questa architettura:

Esaminare le seguenti risorse aggiuntive:

Conferme

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