Distribuire una soluzione GraphQL ad alta scalabilità

Questa architettura di riferimento dimostra come distribuire una soluzione basata su GraphQL facilmente scalabile per soddisfare le richieste dei carichi di lavoro.

GraphQL, un linguaggio di query e manipolazione dei dati open source per le API e un runtime per l'esecuzione delle query con i dati esistenti, è un componente ideale per tali implementazioni, ad esempio applicazioni mobile che definiscono in modo esplicito gli attributi necessari. Offre le interfacce API in cui un client potrebbe richiedere i dati di tutte le entità correlate per ottimizzare il flusso di richieste e risposte, ad esempio riducendo al minimo il traffico di rete mobile per le applicazioni mobile. GraphQL offre anche un mezzo efficace per aiutare i consumatori di API a capire come le soluzioni backend possono essere implementate fornendo un unico schema che può coprire molti servizi backend diversi.

Architettura

Questa architettura definisce instradamenti diversi per il contenuto API statico e dinamico. Questo approccio semplifica l'accesso al contenuto statico configurando le opzioni di inserimento nella cache a diversi livelli, incluso l'utilizzo di una rete di distribuzione dei contenuti (CDN), al load balancer e all'interno dei servizi backend che caricano e gestiscono il contenuto.

I servizi backend vengono implementati con microservizi in questa architettura. Questi servizi potrebbero anche distribuire una soluzione CMS, come Oracle Content and Experience, tramite opzioni CMS open source. Poiché il contenuto è statico, i rischi per la sicurezza sono notevolmente inferiori.

Il contenuto delle API viene instradato tramite un gateway API in modo che le richieste API possano essere convalidate e controllate (ad esempio, una frequenza limitata). Il traffico viene quindi inviato al load balancer del motore Oracle Kubernetes, il punto di ingresso nel cluster, che lo indirizza a un server GraphQL. Idealmente, se per servire il contenuto statico vengono utilizzati microservizi, i servizi che supportano GraphQL e il contenuto statico vengono conservati in spazi di nomi separati per migliorare l'isolamento e il controllo.

Questa implementazione adotta il server Apollo GraphQL open source per ricevere i richiami e decomporre il lavoro per separare i microservizi che ospitano la logica del risolutore e del mutatore. Puoi ridimensionare l'implementazione in modo più efficiente implementando i vari sottodomini all'interno del modello di dati utilizzando servizi separati. Pertanto, è più facile sintonizzare la soluzione con qualsiasi caching in-memory.

Il diagramma riportato di seguito mostra questa architettura di riferimento.

Segue la descrizione di deployment-hs-graphql.png
Descrizione dell'immagine deployment-hs-graphql.png

deployment-hs-graphql.zip

Il codice e la documentazione per implementare l'architettura, inclusi i servizi di esempio, sono disponibili nel repository GitHub pertinente (vedere l'argomento Distribuisci riportato di seguito). L'instradamento API utilizza un server Apollo GraphQL e servizi Python per ogni sottodominio. Ulteriori dettagli sono disponibili nella documentazione su GitHub fornita.

Questa architettura contiene i componenti riportati di seguito.
  • Tenancy

    Una tenancy copre tutte le aree in uso. Per ottimizzare le prestazioni e la resilienza, desideri replicare la distribuzione in diverse aree del mondo e combinare l'instradamento DNS pubblico in modo che i clienti arrivino all'area più vicina per ridurre la latenza. Questa operazione richiederebbe la replica dei dati backend tra le aree.

  • Area

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

  • Compartimento

    I compartimenti sono partizioni logiche tra più aree all'interno di una tenancy di Oracle Cloud Infrastructure. Usare i compartimenti per organizzare le risorse in Oracle Cloud, controllare l'accesso alle risorse e impostare le quote d'uso. Per controllare l'accesso alle risorse in un determinato compartimento, puoi definire i criteri che specificano chi può accedere alle risorse e quali azioni possono eseguire. I controlli del compartimento per questa architettura possono essere aggiunti a separare il livello di accesso pubblico e il backend per ridurre al minimo il rischio di creare percorsi diretti al livello di sicurezza inavvertitamente.

  • domini di disponibilità

    I domini di disponibilità sono data center indipendenti e autonomi all'interno di un'area geografica. Le risorse fisiche presenti in ogni dominio di disponibilità sono isolate dalle risorse presenti negli altri domini di disponibilità, garantendo quindi la tolleranza agli errori. I domini di disponibilità non condividono infrastrutture, quali alimentazione o raffreddamento, o la rete del dominio di disponibilità interna. Pertanto, è improbabile che l'errore di un dominio di disponibilità influisca sugli altri domini di disponibilità nell'area. In questa architettura di riferimento, i nodi di lavoro Kubernetes vengono distribuiti sia nei domini di errore che di disponibilità per garantire massima resilienza.

  • domini di errore

    Un dominio di errore è un raggruppamento di hardware e infrastruttura all'interno di un dominio di disponibilità. Ogni dominio di disponibilità dispone di tre domini di errore, dotati di alimentazione e hardware indipendenti. Quando si distribuiscono le risorse su più domini di errore, le applicazioni possono tollerare l'errore fisico del server, la manutenzione del sistema e gli errori di alimentazione all'interno di un dominio di errore.

  • Rete cloud virtuale (VCN) e subnet

    Una VCN è una rete personalizzabile definita dal software che si imposta in un'area Oracle Cloud Infrastructure. Analogamente alle reti di data center tradizionali, i VCN offrono un controllo completo sull'ambiente di rete. Una VCN può avere più blocchi CIDR non sovrapposti che è possibile modificare dopo aver creato la VCN. Puoi suddividere una VCN in subnet, che possono essere definite in un'area o in un dominio di disponibilità. Ogni subnet è composta da un intervallo contiguo di indirizzi che non si sovrappongono alle altre subnet nella VCN. Puoi modificare la dimensione di una subnet dopo la creazione. Una subnet può essere pubblica o privata.

  • Load balancer

    Il servizio Oracle Cloud Infrastructure Load Balancing offre la distribuzione automatica del traffico da un singolo punto di ingresso a più server nel backend. In questa architettura di riferimento, il load balancer includerà i criteri di instradamento per separare il traffico indirizzato al gateway API per i dati dinamici e il contenuto statico (ad esempio immagini, pagine Web e così via). Questa operazione potrà quindi sfruttare le funzionalità WAA (Web Application Acceleration) del load balancer.

  • Lista di sicurezza

    Per ogni subnet, puoi creare regole di sicurezza che specifichino l'origine, la destinazione e il tipo di traffico che devono essere consentiti verso e dall'esterno.

  • Gateway NAT

    Il 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

    Il 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 su fabric di rete Oracle e non passa mai su Internet.

  • Cloud Guard

    È possibile utilizzare Oracle Cloud Guard per monitorare e gestire la sicurezza delle risorse in Oracle Cloud Infrastructure. Cloud Guard utilizza le ricette del rilevatore che puoi definire per esaminare le risorse per individuare i punti deboli della sicurezza, nonché per monitorare operatori e utenti per attività a rischio. Quando viene rilevata un'attività di configurazione errata o non sicura, Cloud Guard consiglia azioni correttive e supporta l'esecuzione di tali azioni in base alle ricette del rispondente che è possibile definire.

  • Zona di sicurezza

    Le zone di sicurezza garantiscono fin dall'inizio le procedure ottimali di sicurezza di Oracle applicando criteri quali la cifratura dei dati e la prevenzione dell'accesso pubblico alle reti per un intero compartimento. Una zona di sicurezza è associata a un compartimento con lo stesso nome e include i criteri della zona di sicurezza o un "recipe" che si applica al compartimento e ai relativi compartimenti secondari. Impossibile aggiungere o spostare un compartimento standard in un compartimento della zona di sicurezza.

  • Database autonomo

    I database autonomi Oracle Cloud Infrastructure sono ambienti di database completamente gestiti e preconfigurati che puoi utilizzare per l'elaborazione delle transazioni e i carichi di lavoro di data warehousing. Non è necessario configurare o gestire alcun componente hardware né installare software. Oracle Cloud Infrastructure gestisce la creazione del database, nonché il backup, l'applicazione di patch, l'upgrade e il tuning del database.

  • Container Engine for Kubernetes

    Oracle Cloud Infrastructure Container Engine for Kubernetes è un servizio completamente gestito, scalabile e ad alta disponibilità che puoi utilizzare per distribuire le tue applicazioni gestite in container nel cloud. Puoi specificare le risorse di computazione necessarie alle tue applicazioni e Container Engine for Kubernetes eseguirne il provisioning su Oracle Cloud Infrastructure in una tenancy esistente. Container Engine for Kubernetes utilizza Kubernetes per automatizzare la distribuzione, la scalabilità e la gestione delle applicazioni gestite in container in vari cluster di host. Il cluster Kubernetes avrà nodi allocati a zone di vault e zone di disponibilità diverse per massimizzare la resilienza e la disponibilità. Il cluster Kubernetes avrà idealmente la funzionalità Istio o un'altra rete di servizi per gestire e monitorare i microservizi. Il servizio GraphQL esisterà nel proprio pod, con i vari resolver e mutatori distribuiti nel cluster Kubernetes come propri microservizi.

  • Registro

    Oracle Cloud Infrastructure Registry è un registro gestito da Oracle che consente di semplificare il flusso di lavoro sviluppo-produzione. Il registro semplifica la memorizzazione, la condivisione e la gestione degli artifact di sviluppo, come le immagini Docker. L'architettura ad alta disponibilità e scalabile di Oracle Cloud Infrastructure ti consente di distribuire e gestire le tue applicazioni in modo affidabile.

Suggerimenti

Utilizzare i seguenti suggerimenti come punto di partenza.I requisiti potrebbero essere diversi dall'architettura descritta qui.
  • VCN

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

    Selezionare i blocchi CIDR che non si sovrappongono ad altre reti (in Oracle Cloud Infrastructure, nel data center on premise o in un altro provider cloud) in cui si desidera impostare connessioni private.

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

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

  • Sicurezza

    Usa Oracle Cloud Guard per monitorare e gestire in modo proattivo la sicurezza delle risorse in Oracle Cloud Infrastructure. Cloud Guard utilizza le ricette del rilevatore che puoi definire per esaminare le risorse per individuare i punti deboli della sicurezza, nonché per monitorare operatori e utenti per attività a rischio. Quando viene rilevata un'attività di configurazione errata o non sicura, Cloud Guard consiglia azioni correttive e supporta l'esecuzione di tali azioni in base alle ricette del rispondente che è possibile definire. Per le risorse che richiedono la massima sicurezza, Oracle consiglia di utilizzare le zone di sicurezza. Una zona di sicurezza è un compartimento associato a una ricetta dei criteri di sicurezza definita da Oracle basata su migliori prassi. Ad esempio, le risorse di una zona di sicurezza non devono essere accessibili dalla rete Internet pubblica e devono essere cifrate utilizzando chiavi gestite dal cliente. Quando si creano e si aggiornano risorse in una zona di sicurezza, Oracle Cloud Infrastructure convalida le operazioni rispetto ai criteri nella ricetta della zona di sicurezza e nega le operazioni che violano uno qualsiasi dei criteri.

  • Cloud Guard

    Duplica e personalizza le ricette predefinite fornite da Oracle per creare ricette personalizzate di rilevatore e rispondente. Queste ricette consentono di specificare il tipo di violazioni della sicurezza che generano un'avvertenza e le azioni che possono essere eseguite su di esse. Ad esempio, potresti voler rilevare i bucket di storage degli oggetti che hanno visibilità impostata su public. Applicare Cloud Guard a livello di tenancy per coprire l'ambito più ampio e ridurre il carico amministrativo dovuto alla gestione di più configurazioni. È inoltre possibile utilizzare la funzione Lista gestita per applicare determinate configurazioni ai rilevatori.

  • Gruppi di sicurezza di rete (NSG)

    È possibile utilizzare i gruppi di sicurezza di rete per definire un set di regole di entrata e uscita valide per VNIC specifiche. Consigliamo di usare i gruppi di sicurezza di rete anziché le liste di sicurezza perché i gruppi di rete consentono di separare l'architettura della subnet della VCN dai requisiti di sicurezza della tua applicazione.

    È possibile utilizzare i gruppi di sicurezza di rete per definire un set di regole di entrata e uscita valide per VNIC specifiche. Consigliamo di usare i gruppi di sicurezza di rete anziché le liste di sicurezza perché i gruppi di rete consentono di separare l'architettura della subnet della VCN dai requisiti di sicurezza della tua applicazione.

  • Larghezza di banda del load balancer

    Durante la creazione del load balancer, puoi selezionare una forma predefinita che fornisce una larghezza di banda fissa o specificare una forma personalizzata (flessibile) in cui impostare un intervallo di larghezza di banda e lasciare che il servizio scali automaticamente la larghezza di banda, in base ai pattern di traffico. Grazie a entrambi i metodi, puoi modificare la forma in qualsiasi momento dopo aver creato il load balancer.

  • Gateway API
    Il gateway API può essere utilizzato per fornire un livello iniziale di screening e controlli dell'uso, ad esempio:
    • Autenticazione e autorizzazione servizio
    • Controlli del servizio come la limitazione della tariffa
    • Acquisizione dell'analisi dei dati sull'uso del servizio
    Inoltre, il gateway API (non il firewall o il load balancer) dovrebbe eseguire l'instradamento basato sulla soluzione che garantisce che tutti gli endpoint non soddisfatti dalle funzionalità GraphQL possano essere indirizzati alla posizione corretta. Tenuto conto di quanto precede, è opportuno prevedere limiti di frequenza ragionevoli, sia in base alla capacità di prestazioni massime supportate dalle soluzioni backend che alla abilitazione di picco di qualsiasi utente del servizio.

Considerazioni

Considerare i seguenti punti durante la distribuzione di questa architettura di riferimento.

  • Prestazioni

    Questa architettura fornirà un mezzo per costruire la capacità di prestazioni sia verticalmente che orizzontalmente. Anche con i microservizi più ottimizzati, il tempo di esecuzione dei nuovi nodi è in ritardo, pertanto questa operazione deve essere consentita quando si gestisce la scalabilità manualmente o in modo dinamico. Ciò sarà particolarmente vero per il livello di persistenza di qualsiasi soluzione.

  • Sicurezza

    La sicurezza a livello di applicazione deve essere garantita dal gateway API. Tuttavia, è possibile gestire una sicurezza specifica con filtro GraphQL, ad esempio l'accesso a livello di attributo, utilizzando direttive GraphQL quali @auth.

  • Disponibilità
    • Kubernetes

      I domini di errore garantiscono resilienza all'interno di un dominio di disponibilità. Puoi configurare i nodi di lavoro Kubernetes per la distribuzione in varie zone di disponibilità.

    • Gateway API, load balancer e così via

      La disponibilità dei servizi gestiti, ad esempio il gateway API, viene gestita all'interno di un'area geografica. Puoi configurare i load balancer per garantire il coordinamento tra le zone di disponibilità.

    Se necessario, puoi migliorare ulteriormente la disponibilità adottando un modello di implementazione multiregion, sebbene ciò aumenti la complessità e il coordinamento.
  • Costo

    Maggiore è la disponibilità e la resilienza richieste, maggiore è il costo operativo. Ciò accade perché aumenta il volume necessario di risorse di computazione ridondanti. Considerate quale implementazione di GraphQL utilizzerete e quali, se presenti, sono imposti vincoli di licenza e se l'implementazione è supportata dal fornitore.

Distribuzione

Distribuire manualmente questa architettura seguendo le istruzioni nel repository Github DevRel di Oracle. Il caricamento delle immagini dei container nel registro e la distribuzione di Kubernetes sono processi manuali oppure puoi farlo seguendo il processo descritto nei dettagli di implementazione inclusi nella documentazione su GitHub.

Conferme

Autore: Phil Wilkins