Modello dei nodi geografici

Il modello Geode prevede la distribuzione di una raccolta di servizi back-end in un set di ge ographical nodes, ognuno dei quali può gestire qualsiasi richiesta per qualsiasi client in qualsiasi area. Questo modello consente di gestire le richieste in uno stile attivo-attivo , migliorando la latenza e aumentando la disponibilità distribuendo l'elaborazione delle richieste in tutto il mondo.

Contesto e problema

Molti servizi su larga scala presentano sfide specifiche per la disponibilità geografica e la scalabilità. Le progettazioni classiche spesso portano i dati nel calcolo archiviando i dati in un server SQL remoto che funge da livello di calcolo per tali dati, basandosi su scalabilità orizzontale per la crescita.

L'approccio classico può presentare una serie di sfide:

• Problemi di latenza di rete per gli utenti provenienti dall'altro lato del mondo per connettersi all'endpoint di hosting
• Gestione del traffico per picchi di domanda che possono sovraccaricare i servizi in una singola area
• Complessità non proibitiva della distribuzione di copie dell'infrastruttura di app in più aree per un servizio 24x7

L'infrastruttura cloud moderna si è evoluta per consentire il bilanciamento del carico geografico dei servizi front-end, consentendo al contempo la replica geografica dei servizi back-end. Per garantire disponibilità e prestazioni, avvicinare i dati all'utente è ottimale. Quando i dati vengono distribuiti geograficamente in una base utente molto ampia, anche gli archivi dati distribuiti geograficamente devono essere raggruppati con le risorse di calcolo che elaborano i dati. Il modello geode porta il calcolo ai dati.

Soluzione

Distribuire il servizio in una serie di distribuzioni satellitari distribuite in tutto il mondo, ognuna delle quali è denominata geode. Il modello geode sfrutta le principali funzionalità di Azure per instradare il traffico attraverso il percorso più breve a un geode nelle vicinanze, migliorando la latenza e le prestazioni. Ogni geode si trova dietro un servizio di bilanciamento del carico globale e usa un servizio di lettura/scrittura con replica geografica come Azure Cosmos DB per ospitare il piano dati, garantendo la coerenza dei dati tra geode. I servizi di replica dei dati assicurano che gli archivi dati siano identici tra i geodes, in modo che tutte le richieste possano essere gestite da tutti i geodes.

La differenza principale tra un timbro di distribuzione e un geode è che i geodes non esistono mai in isolamento. In una piattaforma di produzione dovrebbero essere sempre presenti più geode.

I geodes hanno le caratteristiche seguenti:

• È costituito da una raccolta di diversi tipi di risorse, spesso definiti in un modello.
• Non avere dipendenze al di fuori del footprint del geode e sono autonome. Nessun geode dipende da un altro per operare e, se uno muore, gli altri continuano a funzionare.
• L'accoppiamento è libero tramite una rete perimetrale e un backplane di replica. Ad esempio, è possibile usare Gestione traffico di Azure o Frontdoor di Azure per il front-end dei geodes, mentre Azure Cosmos DB può fungere da backplane di replica. I geodes non sono uguali ai cluster perché condividono un backplane di replica, quindi la piattaforma si occupa dei problemi del quorum.

Il modello geode si verifica nelle architetture di Big Data che usano hardware di base per elaborare i dati raggruppati nello stesso computer e MapReduce per consolidare i risultati tra i computer. Un altro utilizzo è il calcolo near-edge, che avvicina il calcolo alla rete perimetrale intelligente per ridurre il tempo di risposta.

I servizi possono usare questo modello su decine o centinaia di geodes. Inoltre, la resilienza dell'intera soluzione aumenta con ogni geode aggiunto, poiché qualsiasi geodes può assumere il controllo se un'interruzione a livello di area richiede uno o più geodes offline.

È anche possibile aumentare le tecniche di disponibilità locale, ad esempio le zone di disponibilità o le aree abbinate, con il modello geode per la disponibilità globale. Questo aumenta la complessità, ma è utile se l'architettura è supportata da un motore di archiviazione, ad esempio l'archiviazione BLOB che può essere replicata solo in un'area abbinata. È possibile distribuire geodes in un footprint all'interno della zona, della zona o dell'area, tenendo conto dei vincoli normativi o di latenza sulla posizione.

Considerazioni e problemi

Usare le tecniche e le tecnologie seguenti per implementare questo modello:

• Procedure e strumenti DevOps moderni per produrre e distribuire rapidamente geodes identici in un numero elevato di aree o istanze.
• Scalabilità automatica per aumentare le istanze di calcolo e velocità effettiva del database all'interno di un geode. Ogni geode scala singolarmente, all'interno dei vincoli backplane comuni.
• Un servizio front-end come Frontdoor di Azure che esegue accelerazione del contenuto dinamico, suddivisione tcp e routing Anycast.
• Archivio dati di replica come Azure Cosmos DB per controllare la coerenza dei dati.
• Le tecnologie serverless dove possibile, per ridurre i costi di distribuzione always-on, soprattutto quando il carico viene spesso ribilanciato in tutto il mondo. Questa strategia consente la distribuzione di molti geodes con un investimento aggiuntivo minimo. Le tecnologie di fatturazione serverless e basate sul consumo riducono gli sprechi e i costi dalle distribuzioni con distribuzione geografica duplicata.
• Gestione API non è necessario implementare il modello di progettazione, ma può essere aggiunto a ogni geode che precede l'app per le funzioni di Azure dell'area per fornire un livello API più affidabile, consentendo l'implementazione di funzionalità aggiuntive come la limitazione della frequenza, ad esempio.

Prima di decidere come implementare questo modello, considerare quanto segue:

• Scegliere se elaborare i dati in locale in ogni area o distribuire aggregazioni in un singolo geode e replicare il risultato in tutto il mondo. Il processore del feed di modifiche di Azure Cosmos DB offre questo controllo granulare usando il concetto di contenitore di lease e il prefisso leasecollection nell'associazione Funzioni di Azure corrispondente. Ogni approccio presenta vantaggi e svantaggi distinti.
• I geodes possono funzionare in parallelo, usando il feed di modifiche di Azure Cosmos DB e una piattaforma di comunicazione in tempo reale come SignalR. I geodes possono comunicare con utenti remoti tramite altri geodi in un modello di mesh, senza conoscere o occuparsi della posizione dell'utente remoto.
• Questo modello di progettazione disaccoppia implicitamente tutto, ottenendo un'architettura estremamente distribuita e disaccoppiata. Si consideri come tenere traccia di componenti diversi della stessa richiesta che potrebbero essere eseguiti in modo asincrono in istanze diverse. Una strategia di monitoraggio appropriata è fondamentale. Sia Frontdoor di Azure che Azure Cosmos DB possono essere facilmente integrati con Log Analytics e Funzioni di Azure devono essere distribuiti insieme ad Application Insights per fornire un sistema di monitoraggio affidabile in ogni componente dell'architettura.
• Le distribuzioni distribuite hanno un numero maggiore di segreti e punti di ingresso che richiedono misure di sicurezza delle proprietà. Key Vault offre un livello sicuro per la gestione dei segreti e ogni livello all'interno dell'architettura API deve essere protetto correttamente in modo che l'unico punto di ingresso per l'API sia il servizio front-end come Frontdoor di Azure. Azure Cosmos DB deve limitare il traffico alle app per le funzioni di Azure e le app per le funzioni ad Azure Frontdoor usando Microsoft Entra ID o procedure come la restrizione IP.
• Le prestazioni sono drasticamente influenzate dal numero di geodi distribuiti e dai piani di servizio app specifici applicati alla tecnologia API in ogni geode. La distribuzione di geodi o spostamenti aggiuntivi verso i livelli Premium comporta costi maggiori per la memoria e il calcolo aggiuntivi, ma non lo fanno per ogni transazione. Prendere in considerazione il test di carico dell'architettura API dopo la distribuzione e il contrasto dell'aumento del numero di geodes con l'aumento del piano tariffario in modo che il modello più conveniente venga usato per le proprie esigenze.
• Determinare i requisiti di disponibilità per i dati. Azure Cosmos DB include flag facoltativi per abilitare la scrittura in più aree, le zone di disponibilità e altro ancora. Questi aumentano la disponibilità per l'istanza di Azure Cosmos DB e creano un livello di dati più resiliente, ma presentano costi aggiuntivi.
• Azure offre un'ampia gamma di servizi di bilanciamento del carico che offrono funzionalità diverse per la distribuzione del traffico. Usare l'albero delle decisioni per selezionare l'opzione corretta per il front-end dell'API.

Quando usare questo modello

Usare questo schema:

• Per implementare una piattaforma su larga scala con utenti distribuiti su un'ampia area.
• Per qualsiasi servizio che richiede caratteristiche di disponibilità e resilienza estreme, poiché i servizi basati sul modello geode possono sopravvivere alla perdita di più aree del servizio contemporaneamente.

Questo modello potrebbe non essere adatto per

• Architetture con vincoli in modo che tutti i geodes non possano essere uguali per l'archiviazione dei dati. Ad esempio, potrebbero esserci requisiti di residenza dei dati, un'applicazione che deve mantenere lo stato temporaneo per una determinata sessione o un peso elevato delle richieste verso una singola area. In questo caso, prendere in considerazione l'uso di stamp di distribuzione in combinazione con un piano di routing globale che riconosce la posizione dei dati di un utente, ad esempio il componente di routing del traffico descritto nel modello di stamp di distribuzione.
• Situazioni in cui non è richiesta alcuna distribuzione geografica. Prendere invece in considerazione le zone di disponibilità e le aree abbinate per il clustering.
• Situazioni in cui una piattaforma legacy deve essere adattata. Questo modello funziona solo per lo sviluppo nativo del cloud e può essere difficile da adattare.
• Architetture e requisiti semplici, in cui la ridondanza geografica e la distribuzione geografica non sono necessarie o vantaggiose.

Progettazione del carico di lavoro

Un architetto deve valutare come usare il modello Geode nella progettazione del carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. Ad esempio:

Come per qualsiasi decisione di progettazione, prendere in considerazione eventuali compromessi rispetto agli obiettivi degli altri pilastri che potrebbero essere introdotti con questo modello.

Esempi

• Windows Active Directory implementa una variante anticipata di questo modello. La replica multi-primaria indica che tutti gli aggiornamenti e le richieste possono essere serviti in teoria da tutti i nodi gestibili, ma i ruoli FSMO (Flexible Single Master Operation) indicano che tutti i geodes non sono uguali.
• L'acceleratore di pattern geode in GitHub presenta questo modello di progettazione in pratica ed è progettato per aiutare gli sviluppatori a implementarlo con LE API reali.
• Un'applicazione di esempio QnA in GitHub illustra questo modello di progettazione in pratica.