Modello dei nodi geografici

Il modello Geode prevede la distribuzione di una raccolta di servizi di backend in un insieme di nodigeografici, 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 potrebbe causare i problemi seguenti:

• 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à dal costo proibitivo della distribuzione di copie dell'infrastruttura di app in più aree per un servizio 24 ore su 24, 7 giorni su 7.

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 più distribuzioni satellite 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 bilanciatore di carico globale e utilizza un servizio di lettura/scrittura con replica geografica, come Azure Cosmos DB, per ospitare il livello dati, garantendo la coerenza dei dati tra i vari geodi. 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 hanno dipendenze al di fuori del profilo del geode e sono autonome. Nessun geode dipende da un altro per operare e, se uno muore, gli altri continuano a funzionare.
• Sono debolmente accoppiati tramite una rete edge e un piano 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 geodeti. Inoltre, la resilienza dell'intera soluzione aumenta con ogni geode aggiunto, poiché qualsiasi geode può assumere il controllo se un'interruzione a livello di area porta offline uno o più geodi.

È 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 i geodes in un footprint intra-zonale, zonale o regionale, tenendo conto dei vincoli normativi o di latenza relativi alla 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 scalare orizzontalmente le istanze delle risorse di calcolo e della capacità di elaborazione del database all'interno di un geode. Ogni geode si espande singolarmente, rispettando i vincoli comuni del backplane.
• Un servizio front-end come Frontdoor di Azure che esegue accelerazione del contenuto dinamico, routing attraverso un punto di presenza ottimale e Split TCP.
• 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 geodi con un investimento aggiuntivo minimo. Le tecnologie di fatturazione serverless e basate sul consumo riducono gli sprechi e i costi derivanti da distribuzioni duplicate geograficamente.
• Gestione API non è necessario per implementare il modello di progettazione, ma può essere aggiunto a ogni geode che fa fronte all'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 implementazioni distribuite hanno un numero maggiore di segreti e punti di ingresso che richiedono adeguate misure di sicurezza. 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 Azure Function Apps e le Function Apps ad Azure Front Door usando strumenti come 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 aggiuntivi o il passaggio ai livelli premium implica costi aggiuntivi per la memoria e la potenza di calcolo, ma questi costi non si applicano su base per transazione. Prendere in considerazione il test di carico dell'architettura API dopo la distribuzione e confrontare l'aumento del numero di geodes con l'aumento del piano tariffario, in modo che la soluzione più conveniente venga usata per le proprie esigenze.
• Determinare i requisiti di disponibilità per i dati. Azure Cosmos DB include flag opzionali per abilitare la scrittura multi-regione, 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 vari servizi di bilanciamento del carico che offrono diverse funzionalità 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 essere presenti 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 consapevole della posizione dei dati di un utente, come il componente di routing del traffico descritto nel pattern 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 implica che, teoricamente, tutti gli aggiornamenti e le richieste possono essere gestiti da tutti i nodi utilizzabili, ma i ruoli FSMO (Operazioni Flessibili del Master Singolo) indicano che non tutti gli elementi della rete (geodes) sono equivalenti.