Multi-region VS AWS Backbone: ottenere performance globali contenendo costi e complessità

Introduzione

Quando si tratta di distribuzione globale dei servizi, viene automatico pensare ad una architettura multi-region.

Tuttavia, esistono casi in cui sfruttando l’AWS Backbone, è possibile ottenere prestazioni del tutto simili, a costi più contenuti. 

L’AWS backbone, o AWS Global Network, è l’infrastruttura in fibra ottica privata ad alte prestazioni di Amazon Web Services che collega tra loro AWS Regions, Availability Zones ed Edge Locations dislocate in tutto il mondo. Gestisce il routing e le performance di rete, garantendo costantemente bassa latenza e throughput elevato tra i servizi AWS.

In questo articolo, vediamo quando preferire questa rete ad alta velocità e bassa latenza rispetto alla replica dell’infrastruttura su più region e come sfruttarla in modo ottimale per migliorare l’esperienza utente.

AWS Edge Services

Gli AWS Edge Services sono funzionalità cloud progettate per portare elaborazione, storage e networking più vicini all’utente finale, invece di affidarsi esclusivamente a un’infrastruttura centralizzata nelle AWS Regions. L’obiettivo è ridurre la latenza accorciando fisicamente la distanza che i dati devono percorrere.

Alcuni esempi di edge services sono:

• Amazon CloudFront: una content delivery network (CDN) globale per distribuire contenuti statici e dinamici a bassa latenza, grazie alla cache nelle edge locations.
  
• CloudFront Functions: una funzionalità serverless di CloudFront che permette di eseguire funzioni JavaScript leggere per personalizzazioni del CDN sensibili alla latenza.
  
• AWS WAF: un Web Application Firewall che protegge le applicazioni da exploit comuni e attacchi bot. Integrato con una distribuzione CloudFront, applica le regole in tutte le edge locations.
  
• AWS Global Accelerator: un servizio di networking che ottimizza il routing del traffico sfruttando l’AWS backbone per migliorare le performance.
  
• Amazon Route 53: un Domain Name System (DNS) scalabile e ad alta disponibilità che utilizza la rete delle edge locations per garantire bassa latenza.
  
• AWS Storage Gateway: un servizio di storage ibrido che mette in cache i dati localmente per consentire un accesso a bassa latenza.
  

Uno di questi servizi è stato la chiave della nostra soluzione.

Use Case: Global Remote Desktop Service

L’obiettivo era creare una web application che consentisse agli operatori di distributori automatici di caffè di accedere alle macchine e fornire supporto remoto in caso di problemi. In passato questo veniva fatto con TeamViewer, ma i nuovi modelli di macchine non lo supportavano più, perciò è stata necessaria una soluzione custom basata sul Remote Desktop Protocol (RDP).

Abbiamo deciso di utilizzare Apache Guacamole, un gateway clientless per il remote desktop che supporta RDP.

Quando un operatore installa una nuova macchina, la registra tramite la web app, che la inserisce nell’OpenVPN server e invia il profilo VPN al servizio di telemetria.

Il servizio di telemetria è una web app che utilizza IoT Core e gira nello stesso account AWS della soluzione per il remote desktop. Questo servizio gestisce e fornisce informazioni e funzionalità relative alle macchine da caffè.

Se un utente ha un problema con una macchina, può premere un pulsante per inviare una richiesta di supporto, dando inizio al seguente flusso:

1. La macchina si connette al VPN server e avvia il flusso RDP.
   
2. Grazie al canale VPN, la macchina può contattare un API Gateway privato per fornire tutte le informazioni necessarie alla connessione RDP: indirizzo IP, utente e password.
   
3. Una Lambda function esegue queste operazioni:
   
   • avvia un ECS task da un’AMI con installati Apache Guacamole e il client OpenVPN (Guacamole è esposto pubblicamente ma protetto da password),
     
   • recupera dal servizio di telemetria quale operatore deve essere notificato,
     
   • invia una notifica all’operatore tramite la web app, sfruttando SNS e Web Push Notifications.
4. L’operatore utilizza la web app per avviare la connessione RDP verso la macchina da caffè.
   
5. L’operatore si collega alla macchina via RDP ed esegue le operazioni di supporto.
   
6. Una volta terminato, l’operatore chiude le connessioni VPN e RDP tramite la web app.

Il limite del Single-Region

L’intera applicazione era stata distribuita nella Region Irlanda (eu-west-1), la stessa del servizio di telemetria.

Purtroppo la connessione RDP presentava problemi di latenza. Le macchine erano sparse in tutto il mondo e alcune aree disponevano di connessioni internet lente o instabili. In queste condizioni, la connessione RDP risultava quasi inutilizzabile.

Serviva quindi una soluzione per ridurre la latenza tra macchina, operatore e istanza Guacamole.

Multi-Region Deployment VS AWS Backbone

Multi-Region Deployment

Un’architettura multi-region consiste nel distribuire i carichi di lavoro in più AWS Regions, in base alla distribuzione degli utenti. In questo modo, la maggior parte degli utenti si collega a una Region geograficamente vicina, minimizzando la latenza.

Tuttavia, questo approccio comporta alcuni compromessi:

• Sincronizzazione dei dati: la replica tra più regioni introduce problemi di consistenza. Bisogna scegliere tra strong consistency (con latenza aggiuntiva) ed eventual consistency (con possibili disallineamenti temporanei).
  
• Operational overhead: ogni nuova region distribuita equivale a un nuovo ambiente da mantenere e monitorare.
  
• Costi: mantenere più distribuzioni complete può incrementare i costi di infrastruttura e di trasferimento dati, in particolare per la replica cross-region.
  

Vediamo come questi aspetti impattano il nostro caso:

• Data synchronization: non rappresentava un problema. La maggior parte dei servizi utilizzati era serverless e stateless. L’unico dato da sincronizzare era quello su DynamoDB, facilmente gestibile con DynamoDB Global Tables, che replica automaticamente i dati nelle regioni scelte per fornire performance locali veloci sia in lettura che in scrittura.
  
• Operational overhead: grazie all’utilizzo di numerosi servizi serverless, la complessità operativa rimaneva minima e quasi senza manutenzione.
  
• Costi: proprio qui stava il vero problema.
  
  Anche se la maggior parte dell’infrastruttura era serverless (con pagamento a consumo), DynamoDB Global Tables comportava costi moltiplicati per il numero di regioni (N): storage, operazioni di scrittura e aggiornamento replicate in ogni regione, più il traffico inter-region per la sincronizzazione.
  
  Nel nostro caso, il volume di dati non era enorme, quindi sostenibile.  Il costo realmente problematico era invece la replica dell’istanza EC2 con OpenVPN server. Ogni regione richiedeva una licenza separata di OpenVPN, con un costo complessivo ben superiore a quello accettabile.
  

Sapevamo però come progettare una soluzione più conveniente.

Valorizzare al massimo l’AWS Backbone tramite servizi Edge

Nel nostro caso, il vero punto di svolta è stato AWS Global Accelerator.

Grazie a Global Accelerator, abbiamo potuto distribuire l’infrastruttura in una sola Region e, al tempo stesso, ridurre la latenza, rendendo la connessione RDP fluida, come se tutti gli utenti si trovassero nella stessa Region dell’infrastruttura.

Questo è possibile perché le connessioni degli utenti e delle macchine viaggiano su Internet solo fino alla AWS Edge Location più vicina. Da lì in poi, il traffico viene instradato attraverso l’AWS Backbone, che garantisce velocità elevata e bassa latenza per la connessione RDP.

Con Global Accelerator siamo riusciti a ottenere performance molto vicine a quelle di una soluzione multi-region, ma con costi poco superiori a quelli di una distribuzione single-region.

Conclusione

Nella progettazione di soluzioni globali, la raccomandazione predefinita è spesso quella di adottare un’architettura multi-region per:

• garantire che le risorse AWS siano più vicine agli utenti, minimizzando la latenza;
• aumentare disponibilità e resilienza in caso di outage di una Region.
  

Tuttavia, abbiamo visto che non sempre la strategia multi-region è la migliore, soprattutto quando occorre contenere i costi e non è sostenibile replicare licenze o servizi onerosi in ogni regione.

In questi casi, sfruttare servizi basati sull’AWS Backbone, come AWS Global Accelerator, può rappresentare un’ottima alternativa: performance quasi equivalenti a una distribuzione multi-region, ma con costi e complessità molto più vicini a una single-region.

About Proud2beCloud

Proud2beCloud è il blog di beSharp, APN Premier Consulting Partner italiano esperto nella progettazione, implementazione e gestione di infrastrutture Cloud complesse e servizi AWS avanzati. Prima di essere scrittori, siamo Solutions Architect che, dal 2007, lavorano quotidianamente con i servizi AWS. Siamo innovatori alla costante ricerca della soluzione più all'avanguardia per noi e per i nostri clienti. Su Proud2beCloud condividiamo regolarmente i nostri migliori spunti con chi come noi, per lavoro o per passione, lavora con il Cloud di AWS. Partecipa alla discussione!