Distribuire un carico di lavoro MongoDB migrato in Oracle Autonomous JSON Database@Azure
Eseguire la migrazione di un carico di lavoro esistente che utilizza un database di documenti, in questo caso MongoDB, in Azure e in Oracle Autonomous JSON Database distribuito in Azure, un servizio di database di documenti cloud che semplifica lo sviluppo delle 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 (Oracle 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
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 Oracle Autonomous JSON Database senza doverlo rifattorizzare.
Nel diagramma seguente è illustrata un'applicazione tipica composta da un database, livelli back-end e front-end.
mongodb-ajd-azure-arch-logico-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 in Azure e Autonomous JSON Database.
La migrazione di questo carico di lavoro ad Azure e ad Autonomous JSON Database è semplice e consiste, ad alto livello, nei seguenti passi:
- Distribuisci un'istanza di Autonomous JSON Database, abilitando al momento della creazione l'API MongoDB di Oracle Database.
- Esegui la migrazione di metadati e dati da MongoDB ad Autonomous JSON Database.
- Distribuisci gli application server per eseguire
Node.jsed Express utilizzando Azure App Service, VM, container o Kubernetes nello stesso dominio di area e disponibilità di Autonomous JSON Database. - Distribuire il codice dell'applicazione backend negli Application Server.
- Connettere l'applicazione backend ad Autonomous JSON Database utilizzando gli stessi strumenti e driver MongoDB utilizzati nell'applicazione corrente.
- Chiedere 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. 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 è basato su una tecnologia di database multimodello e multiworkload, puoi aggiungere funzionalità che si basano su tipi di dati relazionali, spaziali, grafici o vettoriali che funzionano insieme all'applicazione esistente. È comune che gli utenti vogliano eseguire analytics oltre ai dati JSON. L'utilizzo di 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. Se i requisiti del volume di dati cambiano, puoi facilmente convertirli in Oracle Autonomous Database Serverless, che supporta le stesse funzioni. 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 creati e utilizzati facilmente, ad esempio, per supportare l'analitica operativa utilizzando SQL oltre ai documenti JSON.
Architettura fisica
L'architettura fisica include Autonomous JSON Database distribuito utilizzando subnet delegate in due aree Microsoft Azure per supportare l'alta disponibilità. I servizi OCI supportano il backup automatico in Oracle Cloud Infrastructure Object Storage.
L'architettura supporta quanto segue:
- Livello front-end
- Gli utenti dell'applicazione possono connettersi da Internet o dalla rete aziendale.
- La connessione utente viene instradata all'area attiva in cui è in esecuzione l'applicazione, utilizzando Microsoft Azure Front Door.
- La connessione utente è protetta mediante Azure Web Application Firewall.
- Il carico della connessione utente all'applicazione viene bilanciato utilizzando il servizio applicazioni.
- Livello back-end
- L'applicazione viene distribuita in modalità High Availability utilizzando il servizio applicazioni Azure.
- Azure App Service AutoScale viene utilizzato per ottenere la scalabilità orizzontale.
- 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.
- Il database Autonomous JSON nell'area primaria dispone di un peer cross region basato su backup nell'area secondaria.
- La seconda regione viene implementata con una topologia simile per ridurre l'obiettivo complessivo dei tempi di recupero.
- Utilizzare una strategia DR calda per ridurre l'RTO complessivo. In una strategia di recupero da errori irreversibili, il provisioning delle risorse cloud di livello backend viene già eseguito 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.
- Networking
- Tutto il traffico in entrata delle applicazioni da on-premise e da Internet viene instradato da Azure Front Door.
- Autonomous JSON Database viene distribuito con un endpoint privato per aumentare il livello di sicurezza.
- Azure App Service è un'applicazione Web distribuita utilizzando una subnet di integrazione e VNet per raggiungere l'istanza di Autonomous JSON Database.
- L'applicazione VNet viene gestita in peering con il database VNet e il traffico può fluire tra l'applicazione Web e Autonomous JSON Database.
- Sicurezza
- Tutti i dati sono sicuri in transito e in rest.
- I seguenti potenziali miglioramenti alla progettazione non sono illustrati in questa distribuzione per semplicità:
- Automatizza l'applicazione Disaster Recovery utilizzando i runbook di Azure Automation per cambiare gli endpoint della porta anteriore e convalidare lo stato dell'app dopo il failover.
- Sfrutta una topologia hub e spoke per applicare la sicurezza della rete centralizzata.
- Sfrutta un firewall di rete, implementato nell'hub VNet, per migliorare il livello di sicurezza generale ispezionando tutto il traffico e applicando i criteri.
Il diagramma seguente illustra questa architettura di riferimento.
mongodb-ajd-azure-fisico-arch.zip
L'architettura ha i seguenti componenti Microsoft:
- Gestione firewall Azure
Azure Firewall Manager è un servizio di gestione della sicurezza centralizzato che semplifica l'implementazione e la configurazione di Azure Firewall in più aree e sottoscrizioni. Consente la gestione gerarchica delle policy, consentendo l'applicazione coerente delle policy firewall globali e locali. Se integrato con Azure Virtual WAN (vWAN) e un hub sicuro, Azure Firewall Manager migliora la sicurezza automatizzando l'instradamento e il filtro del traffico senza la necessità di instradamenti definiti dall'utente. Questa integrazione garantisce che il traffico tra reti virtuali, filiali e Internet venga gestito e monitorato in modo sicuro, fornendo una soluzione di sicurezza di rete solida e semplificata.
- Porta anteriore di Azure
Azure Front Door è un servizio basato su cloud che funge da punto di accesso globale per le applicazioni Web, fornendo distribuzione di contenuti ad alte prestazioni, bilanciamento del carico di livello 7 intelligente e funzioni di sicurezza integrate come Web Application Firewall (WAF) e protezione DDoS per garantire un'esperienza utente rapida, affidabile e sicura.
- Area di Azure
Un'area Azure è un'area geografica in cui risiedono uno o più data center fisici di Azure, denominati zone di disponibilità. Le regioni sono indipendenti da altre regioni e vaste distanze possono separarle (tra paesi o addirittura continenti).
Azure e le aree OCI sono aree geografiche localizzate. Per Oracle Database@Azure, un'area Azure è connessa a un'area OCI, con le zone di disponibilità (AZ) in Azure connesse ai domini di disponibilità (AD) in OCI. Le coppie di aree Azure e OCI sono selezionate per ridurre al minimo la distanza e la latenza.
- Zona di disponibilità di Azure
Le zone di disponibilità di Azure sono posizioni fisicamente separate all'interno di un'area di Azure, progettate per garantire alta disponibilità e resilienza fornendo alimentazione, raffreddamento e rete indipendenti.
- Rete virtuale di Azure (VNet)
Azure Virtual Network (VNet) è il componente fondamentale per la tua rete privata in Azure. VNet consente a molti tipi di risorse Azure, come le virtual machine (VM) di Azure, di comunicare in modo sicuro tra loro, Internet e reti on-premise.
- Servizio app Azure
Azure App Service è una piattaforma-as-a-service (PaaS) completamente gestita che consente di creare, ospitare e ridimensionare applicazioni Web, API e backend mobile senza gestire l'infrastruttura sottostante.
- Subnet di integrazione di Azure App Service
Una subnet dedicata all'interno di una rete virtuale di Azure che è specificamente delegata per l'uso da parte dei piani di App Service, consentendo alle applicazioni Web di effettuare connessioni in uscita alle risorse private all'interno della rete virtuale o delle sue reti peer, ma non di ricevere traffico in entrata da VNet.
- Subnet delegata di Azure
Una subnet delegata ti consente di inserire un servizio gestito, in particolare un servizio platform-as-a-service (PaaS), direttamente nella tua rete virtuale come risorsa. Hai la gestione completa dell'integrazione dei servizi PaaS esterni all'interno delle tue reti virtuali.
L'architettura include i seguenti componenti Oracle:
- Area OCI
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).
- Memorizzazione degli oggetti OCI
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 memorizzare in tutta sicurezza i dati direttamente dalle applicazioni o dall'interno della 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.
- Endpoint privata OCI
OCI Private Endpoint fornisce un accesso gratuito, privato e sicuro a uno dei molti servizi OCI dall'interno di una rete cloud virtuale (VCN) o on-premise.
Variante architettura
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.
Nel seguente diagramma dell'architettura viene illustrato come viene distribuita la variante. Per semplicità, vengono illustrate solo le risorse cloud distribuite nella VCN del carico di lavoro JSON, poiché il rest della distribuzione è lo stesso dell'architettura fisica descritta in precedenza.
mongodb-ajd-azure-arch-variant-oracle.zip
- Le richieste utente in entrata vengono distribuite dal load balancer del servizio applicazioni, pertanto il livello front-end è scalabile orizzontalmente e non presenta un singolo punto di errore.
- L'applicazione backend viene distribuita nei worker dell'unità di scala del servizio applicazioni.
- L'applicazione viene distribuita utilizzando il contenitore come metodo di pubblicazione.
- Crea, installa e configura il contenitore con l'applicazione e Oracle REST Data Services, che consente l'esecuzione di entrambi nello stesso contenitore.
- Ogni worker esegue l'immagine del contenitore che collega l'applicazione e Oracle REST Data Services nello stesso ambiente runtime.
- I worker di Oracle REST Data Services gestiti dal cliente sono configurati per abilitare l'API MongoDB, in modo che l'applicazione possa connettersi al database utilizzando strumenti e 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 nell'immagine contenitore utilizzata nei worker. Quando il servizio applicazioni si ridimensiona orizzontalmente, i nuovi lavoratori possono eseguire l'applicazione backend e connettersi al database dopo il provisioning.
Suggerimenti
- Distribuzione applicazione
- Prendere in considerazione l'utilizzo di una distribuzione basata su container utilizzando Azure Kubernetes Service (AKS) se sono necessarie funzioni avanzate di orchestrazione, networking e sicurezza che potrebbero non essere disponibili nel servizio applicazioni.
- Sicurezza
- Prendi in considerazione l'uso di Oracle Data Safe per aumentare ulteriormente il livello di sicurezza del carico di lavoro ed eseguire l'audit del database.
- Osservabilità
- Prendi in considerazione l'utilizzo di Azure Monitor per monitorare le metriche di Autonomous JSON Database insieme a tutti gli altri dati di monitoraggio dei servizi Azure.
- Disaster recovery
- Prendi in considerazione l'automazione e l'orchestrazione del disaster recovery per tutti i livelli dello stack utilizzando Azure Site Recovery o script personalizzati che rilevano errori e avviano processi di failover.
- Efficienza operativa
- Se il carico di lavoro di Autonomous JSON Database fa parte di una flotta di database più ampia, considera l'uso di Elastic Pool per una maggiore efficienza in termini di costi.
- Prendi in considerazione l'abilitazione di Oracle Cloud Infrastructure Database Management, un servizio OCI che fornisce un set completo di funzioni di monitoraggio e gestione delle prestazioni del database, per semplificare la gestione dell'istanza di Autonomous JSON Database.
- 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 PowerBI, 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 alcuna 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, considera l'uso di Autonomous JSON Database. Seleziona 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'utilizzo di Autonomous JSON Database per memorizzare tipi di dati aggiuntivi (relazionali, vettoriali, spaziali o grafici) fino a 20 Gb per una maggiore funzionalità e flessibilità del carico di lavoro.
Scopri di più
Scopri di più sulle caratteristiche di questa architettura:
- Piattaforma dati Oracle
- Documentazione di Autonomous JSON Database
- Servizi Autonomous Database per Azure
- API database Oracle per MongoDB
- Uso di Oracle Autonomous Database Serverless
- Eseguire la migrazione di un database MongoDB in esecuzione su MongoDB Atlas o on-premise a Oracle Autonomous JSON Database (esercitazione)
Esaminare le seguenti risorse aggiuntive: