Strategie di instradamento in DynamoDB

Forse la parte più complessa di una implementazione di tabelle globali è la gestione dell'instradamento delle richieste. Le richieste devono prima essere inviate da un utente finale a una regione scelta e destinataria dell'instradamento. La richiesta rileva alcuni servizi in tale regione, incluso un livello di calcolo composto da un sistema di bilanciamento del carico supportato da una funzione AWS Lambda, un container o un nodo Amazon Elastic Compute Cloud (Amazon EC2) e forse altri servizi tra cui un altro database. Questo livello di calcolo comunica con DynamoDB mediante l'endpoint locale per tale regione. I dati nella tabella globale vengono replicati in tutte le altre regioni partecipanti e ogni regione ha uno stack di servizi simile attorno alla propria tabella DynamoDB.

A ogni stack nelle varie regioni la tabella globale fornisce una copia locale degli stessi dati. È possibile considerare l'ipotesi di progettare un unico stack in un'unica regione e prevedere di effettuare chiamate remote all'endpoint DynamoDB di una regione secondaria in caso di problemi con la tabella DynamoDB locale. Questa non è una best practice. Se c’è un problema in una Regione causato da DynamoDB (o, più probabilmente, causato da qualcos’altro nello stack o da un altro servizio che dipende da DynamoDB), è meglio indirizzare l’utente finale verso un’altra Regione per l’elaborazione e utilizzare il livello di calcolo dell’altra Regione, che comunicherà con l’endpoint DynamoDB locale. Questo approccio riguarda interamente la Regione problematica. Per garantire la resilienza, è necessario eseguire la replica su più Regioni, con la replica dei livelli di calcolo e dati.

Esistono numerose tecniche alternative per instradare una richiesta dell'utente finale a una regione per l'elaborazione. La scelta ottimale dipende dalla modalità di scrittura e dalle considerazioni relative al failover. Questa sezione illustra quattro opzioni di instradamento: basato sul client, livello di calcolo, Route 53 e Global Accelerator.

Instradamento delle richieste basato sul client

Con l’instradamento delle richieste basato sul client, illustrato nel diagramma seguente, il client dell’utente finale (un’applicazione, una pagina web con JavaScript o un altro client) tiene traccia degli endpoint applicativi validi (ad esempio, un endpoint Gateway Amazon API anziché un endpoint DynamoDB letterale) e utilizza la propria logica incorporata per scegliere la Regione con cui comunicare. Potrebbe scegliere in base alla selezione casuale, alle latenze più basse rilevate, alle misurazioni della larghezza di banda più elevata rilevate o ai controlli di integrità eseguiti localmente.

Il vantaggio dell’instradamento delle richieste basato sul client è che può adattarsi relativamente a fattori come le condizioni reali del traffico Internet pubblico e che pertanto può cambiare Regione in caso di peggioramento delle prestazioni. Il client deve conoscere tutti i potenziali endpoint, ma il lancio di un nuovo endpoint regionale non è un evento frequente.

Con la modalità di scrittura in qualsiasi Regione, un client può selezionare unilateralmente il suo endpoint preferito. Se il suo accesso a una regione viene compromesso, il client può reindirizzare le richieste a un altro endpoint.

Con la modalità scrittura in una regione, il client avrà bisogno di un meccanismo per instradare le sue operazioni di scrittura alla regione attualmente attiva. Questa operazione potrebbe essere semplice, come verificare empiricamente quale Regione accetta le scritture rilevando eventuali errori di scrittura e ricorrendo eventualmente a un’alternativa, oppure complessa, come chiamare un coordinatore globale per richiedere lo stato corrente dell’applicazione (basato sul controllo di instradamento del Sistema di controllo Amazon per il ripristino delle applicazioni (ARC) che fornisce un sistema basato su quorum a 5 Regioni per mantenere lo stato globale per esigenze di questo tipo). Il client può decidere se le letture possono essere instradate a una regione qualsiasi per ottenere un'eventuale coerenza o se devono essere indirizzate alla regione attiva per una maggiore coerenza. Per ulteriori informazioni, consulta l'argomento relativo al funzionamento di Route 53.

Con la modalità di scrittura nella propria regione, il client deve determinare la regione di origine del set di dati che sta usando. Ad esempio, se il client corrisponde a un account utente e ogni account utente si trova in una regione specifica, il client può richiedere l'endpoint appropriato da un sistema di accesso globale.

Ad esempio, una società di servizi finanziari che aiuta gli utenti a gestire le proprie finanze aziendali tramite il Web potrebbe utilizzare tabelle globali con la modalità di scrittura nella propria regione. Ogni utente deve accedere a un servizio centrale. Tale servizio restituisce le credenziali e l'endpoint per la regione in cui tali credenziali funzioneranno. Le credenziali sono valide per un breve periodo. Successivamente, la pagina web negozia automaticamente un nuovo accesso, che offre l'opportunità di reindirizzare potenzialmente l'attività dell'utente verso una nuova regione.

Instradamento delle richieste al livello di calcolo

Con l’instradamento delle richieste al livello di calcolo, illustrato nel seguente diagramma, il codice in esecuzione nel livello di calcolo stabilisce se elaborare la richiesta localmente o passarla a una copia di se stesso in esecuzione in un’altra Regione. Quando si utilizza la modalità di scrittura in una Regione, il livello di calcolo può rilevare che la Regione non è la Regione attiva e consentire operazioni di lettura locali mentre inoltra tutte le operazioni di scrittura a un’altra Regione. Questo codice al livello di calcolo deve conoscere la topologia dei dati e le regole di instradamento e applicarle in modo affidabile in base alle impostazioni più recenti che specificano le Regioni attive e i dati da utilizzare. Lo stack software esterno all’interno della Regione non deve conoscere il modo in cui il microservizio instrada le richieste di lettura e scrittura. In una progettazione affidabile, la regione ricevente verifica se è la regione primaria corrente per l'operazione di scrittura. In caso contrario, genera un errore che indica che lo stato globale deve essere corretto. La regione ricevente potrebbe anche memorizzare l'operazione di scrittura nel buffer per un breve intervallo, se la regione primaria è in fase di modifica. In ogni caso, lo stack di calcolo in una regione effettua la scrittura solo sul proprio endpoint DynamoDB locale, ma gli stack di calcolo potrebbero comunicare tra loro.

Vanguard Group utilizza un sistema denominato Global Orchestration and Status Tool (GOaSt) e una libreria denominata Global Multi-Region library (GMRlib) per questo processo di instradamento, presentato a re:Invent 2022. L’azienda utilizza un modello primario singolo di tipo follow-the-sun. GOaST mantiene lo stato globale, in modo simile al controllo di instradamento dell’ARC discusso nella sezione precedente. Viene utilizzata una tabella globale per monitorare la Regione primaria e controllare quando è programmato il passaggio alla Regione primaria successiva. Tutte le operazioni di lettura e scrittura passano attraverso GMRlib, che si coordina con GOaST. GMRlib consente di eseguire operazioni di lettura localmente, a bassa latenza. Per le operazioni di scrittura, GMRlib verifica se la Regione locale è la Regione primaria corrente. In caso affermativo, l’operazione di scrittura viene completata direttamente. In caso contrario, GMRlib inoltra l’attività di scrittura a GMRlib nella Regione primaria. La libreria ricevente conferma di essere la regione primaria e genera un errore in caso contrario, il che genera un ritardo di propagazione con lo stato globale. Questo approccio offre un vantaggio in termini di convalida in quanto non viene effettuata una scrittura diretta su un endpoint DynamoDB remoto.

Instradamento delle richieste Route 53

Il sistema ARC è una tecnologia DNS (Domain Name Service). Con Route 53, il client richiede il proprio endpoint mediante la ricerca di un nome di dominio DNS noto; Route 53 restituisce l'indirizzo IP corrispondente agli endpoint regionali ritenuti più appropriati. Il diagramma seguente ne è l'illustrazione. Route 53 dispone di un lungo elenco di policy di instradamento che utilizza per determinare la Regione appropriata. Può anche eseguire il routing di failover per deviare il traffico dalle Regioni in cui non vengono superati i controlli dell’integrità.

Con la modalità di scrittura in qualsiasi regione o combinato con l'instradamento delle richieste al livello di calcolo sul backend, Route 53 può avere l'accesso completo per restituire la regione in base a regole interne complesse come la regione più vicina alla rete o la prossimità geografica più vicina o qualsiasi altra scelta.

Con la modalità di scrittura in una Regione, Route 53 può essere configurato in modo da restituire la Regione attualmente attiva (utilizzando il sistema ARC Route 53). Se il client desidera connettersi a una Regione passiva (ad esempio, per operazioni di lettura), potrebbe cercare un nome DNS diverso.

Con la modalità di scrittura nella propria regione, è consigliabile evitare l'uso di Route 53 a meno che non si utilizzi anche l'instradamento delle richieste al livello di calcolo.

Instradamento delle richieste Global Accelerator

Con AWS Global Accelerator, illustrato nel diagramma seguente, un client cerca il nome di dominio noto in Route 53. Tuttavia, invece di recuperare un indirizzo IP corrispondente a un endpoint Regionale, il client riceve un indirizzo IP statico anycast che viene instradato alla posizione edge AWS più vicina. A partire da tale posizione edge, tutto il traffico viene instradato sulla rete privata AWS e verso alcuni endpoint (come un sistema di bilanciamento del carico o un Gateway API) in una regione scelta in base alle regole di instradamento gestite in Global Accelerator. Rispetto all'instradamento basato sulle regole Route 53, l'instradamento delle richieste Global Accelerator presenta latenze inferiori perché riduce la quantità di traffico sulla rete Internet pubblica. Inoltre, poiché Global Accelerator non dipende dalla scadenza del TTL del DNS per modificare le regole di instradamento, può modificare l’instradamento più rapidamente.

Con la modalità di scrittura in qualsiasi regione o combinato con l'instradamento delle richieste al livello di calcolo sul backend, Global Accelerator funziona senza problemi. Il client si connette alla posizione edge più vicina e non deve preoccuparsi di quale regione riceve la richiesta.

Con la modalità di scrittura in una regione, le regole di instradamento di Global Accelerator devono inviare le richieste alla regione attualmente attiva. È possibile utilizzare i controlli dell'integrità per segnalare artificialmente un guasto in qualsiasi regione non considerata dal sistema globale come regione attiva. Come con il DNS, è possibile utilizzare un nome di dominio DNS alternativo per instradare le richieste di lettura se le richieste possono provenire da qualsiasi regione.

Con la modalità di scrittura nella propria regione, è consigliabile evitare l'uso di Global Accelerator a meno che non si utilizzi anche l'instradamento delle richieste al livello di calcolo.