Distribuire un carico di lavoro MongoDB migrato in Oracle Autonomous Transaction Processing Serverless@Azure
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 (ATP) Serverless è un servizio di database completamente automatizzato ottimizzato per eseguire carichi di lavoro transazionali, analitici e in batch contemporaneamente. 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 presuppone, come punto di partenza, che esista un carico di lavoro con un'applicazione e un database MongoDB, una distribuzione on-premise o cloud e che venga eseguita la migrazione in Azure e Oracle Database@Azure. 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 dell'applicazione esistente può funzionare con i dati memorizzati in Oracle Autonomous Transaction Processing serverless, senza la necessità di rifattorizzare il codice.
Nel diagramma seguente è illustrata un'applicazione tipica composta da un database, livelli back-end e front-end.
mongodb-atp-s-azure-logico-arch-migration.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
Questo documento utilizza uno stack MEAN come esempio di una distribuzione esistente di cui verrà eseguita la migrazione in Azure e ATP Serverless.
La migrazione di questo carico di lavoro ad Azure e ATP Serverless è semplice e consiste, ad alto livello, nei seguenti passaggi:
- Distribuire un'istanza ATP Serverless, abilitando al momento della creazione l'API MongoDB di Oracle Database.
- Eseguire la migrazione di metadati e dati da MongoDB ad ATP Serverless.
- Distribuisci gli application server per eseguire
Node.jsed Express utilizzando Azure App Service, VM, container o Kubernetes, nella stessa area e nello stesso dominio di disponibilità di ATP Serverless. - Distribuire il codice dell'applicazione backend negli Application Server.
- Connettere l'applicazione backend ad ATP Serverless utilizzando gli stessi strumenti e driver MongoDB utilizzati nell'applicazione corrente.
- Connettere gli utenti 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, vedere la sezione Scopri di più.
Dopo la migrazione del carico di lavoro su ATP Serverless, sono disponibili diverse funzioni per aumentare le funzionalità esistenti, indipendentemente dal fatto che siano 1) che supportino requisiti non funzionali aggiuntivi, come il semplice miglioramento della scalabilità, della resilienza o dell'alta disponibilità, oppure 2) che dispongano di funzionalità aggiuntive come reporting operativo, analytics e machine learning, senza la necessità di copiare i dati dal database.
Per migliorare la scalabilità e l'alta disponibilità, utilizza la funzione di scalabilità automatica 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, utilizzare Azure VM Scale Sets con impostazione di scala automatica o un servizio PaaS come Servizio applicazioni con impostazione di scala automatica per abilitare l'alta disponibilità e la scalabilità delle applicazioni.
Poiché ATP Serverless si basa sulla tecnologia di database multi-modello e multi-carico di lavoro, è possibile 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 Autonomous Transaction Processing Serverless distribuito utilizzando subnet delegate in due aree di 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 Azure Front Door.
- La connessione utente viene 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
- ATP Serverless offre l'alta disponibilità, in quanto Oracle Real Application Clusters (Oracle RAC) e diversi nodi di database sono alla base dell'istanza del servizio. Pertanto, per impostazione predefinita, il livello di database è altamente disponibile e resiliente.
- Oracle Database API for MongoDB abilitato 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 ottenuta tramite Autonomous Data Guard tra più aree.
- Disaster recovery
- 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 back-end viene già eseguito insieme al database di standby ATP Serverless.
- 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.
- ATP Serverless viene distribuito con un endpoint privato per aumentare la postura della sicurezza.
- L'applicazione Web del servizio applicazioni Azure viene distribuita utilizzando una subnet di integrazione e VNet per raggiungere l'istanza serverless ATP.
- L'applicazione VNet viene gestita in peering con il database VNet e il flusso di traffico è consentito tra l'applicazione Web e ATP Serverless.
- Sicurezza
- Tutti i dati sono sicuri in transito e in archivio.
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.
mongodb-atp-s-azure-physical-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 esperienze utente rapide, affidabili e sicure.
- 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 Microsoft Azure
Microsoft Azure App Service ti consente di creare, ospitare e scalare 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).
- Oracle Autonomous Database
Oracle Autonomous Database è un ambiente di database completamente gestito e preconfigurato che puoi utilizzare per l'elaborazione delle transazioni e i carichi di lavoro di data warehousing. Non è necessario configurare o gestire alcun hardware né installare alcun software. OCI gestisce la creazione, il backup, l'applicazione di patch, l'upgrade e il tuning del database.
- Oracle Autonomous Data Guard
Oracle Autonomous Data Guard consente a un database di standby (peer) di fornire protezione dei dati e disaster recovery per la tua istanza di Autonomous Database. Offre un set completo di servizi che consente di creare, gestire, gestire e monitorare uno o più database in standby per consentire ai database Oracle di produzione di rimanere disponibili senza interruzioni. Oracle Data Guard gestisce questi database in standby come copie del database di produzione. Quindi, se il database di produzione non risulta più disponibile a causa di un'indisponibilità pianificata o non pianificata, è possibile passare da un database in standby al ruolo di produzione riducendo al minimo i tempi di inattività associati all'indisponibilità.
- 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
Questa variante dell'architettura fisica proposta utilizza una distribuzione di Oracle REST Data Services gestita dal cliente in esecuzione in ciascun application server. Tuttavia, 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.
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 resto della distribuzione è uguale all'architettura fisica descritta in precedenza.
mongodb-atp-s-azure-arch-variant.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 ATP Serverless 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 ATP Serverless fa parte di una flotta di database più ampia, prendere in considerazione l'utilizzo di Elastic Pool per una maggiore efficienza dei costi.
- Prendi in considerazione la possibilità di abilitare 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 ATP Serverless.
- Evoluzione delle applicazioni
- Prendi in considerazione l'implementazione di analytics operativi e report in tempo reale in ATP Serverless 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 ATP Serverless per il machine learning utilizzando Oracle Machine Learning (OML), per creare e addestrare modelli con dati JSON senza alcun bisogno di spostamento dei dati e per distribuire i modelli insieme al carico di lavoro esistente per un'inferenza efficiente.
- Per ulteriori casi d'uso oltre il core dell'applicazione, prendere in considerazione l'utilizzo di ATP Serverless Select AI e delle viste di 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 ATP Serverless per memorizzare ulteriori tipi di dati (relazionali, vettoriali, spaziali o grafici) per una maggiore funzionalità e flessibilità del carico di lavoro.
Scopri di più
Scopri di più sulle caratteristiche di questa architettura:
Esaminare le seguenti risorse aggiuntive:
- Piattaforma dati Oracle
- Documentazione di Oracle Autonomous Transaction Processing Serverless
- Servizi Autonomous Database per Azure
- API database Oracle per MongoDB
- Uso di Oracle Autonomous Database Serverless
Esaminare le seguenti risorse aggiuntive: