Man mano che le aziende evolvono i propri stack tecnologici in ottica cloud-native, osserviamo una tendenza ricorrente: migrazioni cloud parziali o configurazioni cloud ibride, spesso come tappa intermedia verso una migrazione completa.
Migrazione cloud
Di recente un'azienda di e-commerce stava spostando le proprie applicazioni containerizzate da AWS a GCP per sfruttare il servizio Kubernetes gestito di Google, GKE.
I file e le foto del catalogo prodotti risiedevano sul servizio di object storage di Amazon, S3, il DNS era gestito tramite AWS Route 53 e l'azienda utilizzava la CDN di Cloudflare. Come primo passo, ha migrato i database e distribuito le applicazioni in parallelo su cluster Kubernetes.
L'obiettivo successivo era passare dalla CDN di Cloudflare a quella di Google, lasciando però per il momento i file statici su S3. Un altro requisito era continuare a sfruttare il DNS gestito tramite AWS Route 53.
Esempio di percorso di migrazione cloud a più fasi per un'azienda di e-commerce
Questo articolo illustra passo passo come mettere in cache i contenuti di un bucket AWS S3 da GCP Cloud CDN sfruttando un load balancer e un network endpoint group (NEG). Per semplicità, in questo esempio non genero un certificato SSL né aggiungo un frontend HTTP(S), ma in genere si tratterebbe di un passaggio aggiuntivo standard.
Setup della demo
- Creare il bucket S3 iniziale con i file di test
Creazione del bucket S3 (annotando il nome del bucket per la successiva configurazione dell'Host sul LB)
2. Caricare i file di test e modificare i metadati per aggiungere l'header Cache-control
File di esempio caricati
Header Cache-control aggiunto (necessario per la CDN)
3. Verificare che i contenuti restituiscano gli header corretti
Configurare load balancer e NEG su GCP
- Aggiungere/modificare il backend type impostandolo su " Internet network endpoint group"
2. Selezionare un network endpoint group (NEG) esistente oppure "create new"
Nota: potrebbe essere necessario creare prima il Network Endpoint Group (NEG), in modo che compaia nel menu a tendina della configurazione backend del Load Balancer. Se non lo si vede, si può scegliere "Create Internet network endpoint group", ma occorre poi aggiornare la schermata del load balancer perché compaia.
Selezionare "Fully qualified domain name" e inserire l'FQDN del bucket S3 (a volte si dispone di una voce DNS personalizzata che punta a quell'indirizzo, ma anche in quel caso va bene).
3. Abilitare Cloud CDN e aggiungere un header personalizzato (corrispondente all'hostname del bucket S3)
Dopo aver selezionato il "Backend type" per il NEG esterno, occorre spuntare "Enable Cloud CDN" ed espandere le opzioni in fondo per creare un header personalizzato.
Il trucco per far funzionare il tutto è aggiungere un host header personalizzato corrispondente all'hostname S3, come mostrato di seguito.
4. Aggiungere/modificare il frontend
5. Salvare il load balancer e verificare che sia configurato con il NEG
6. Verificare che i contenuti vengano restituiti e che la cache funzioni
Verifica dell'accesso ai contenuti (anche da browser)
Effettuare qualche test da browser, poi controllare i log (la via più rapida sono i log di Stackdriver), espandere una voce e verificare che provenga dalla cache.
Conferma del corretto caching del traffico sul load balancer
Aggiornare le voci DNS per reindirizzare il traffico verso Cloud CDN
Una volta verificato che tutto funziona come previsto e che i contenuti arrivano dalla cache, quando si è pronti basta modificare le voci DNS.
In questo caso la CDN era fornita da Cloudflare ed esisteva una voce DNS cdn-environment-location.myco.com che puntava al CNAME something.cloudflare.com. È sufficiente creare un nuovo record A che punti all'IP esterno del load balancer Google (ad esempio gcp-lb-development-cdn.myco.com) e poi modificare il CNAME facendolo puntare a questa nuova voce.
Per precauzione, consiglio di abbreviare il TTL il giorno prima, se necessario, sulla voce CDN attiva: in questo modo, se qualcosa dovesse andare storto, dopo aver modificato il CNAME si potrà tornare indietro senza che la cache DNS dei client resti valida troppo a lungo.
Riepilogo dei passaggi:
- Abbreviare il TTL sul dominio CDN esistente
- Aggiungere un record A che punti all'IP del load balancer GCP
- Modificare il record CNAME del dominio CDN esistente (sostituendo l'FQDN di Cloudflare)
- Verificare che i contenuti vengano instradati attraverso Cloud CDN
Congratulazioni, ha funzionato! Ora non resta che metterlo in sicurezza con un frontend HTTP(S) ;-)
Attenzione ai costi delle soluzioni cloud
È possibile far passare le richieste in proxy da Cloud CDN ai bucket S3, ma per farlo è necessario aggiungere header personalizzati, e questo ha un costo. Al momento si tratta di circa 0,75 $ per ogni milione di richieste, con un tetto massimo di 500 $ al mese. Su un sito di grandi dimensioni e con molto traffico, la spesa può crescere rapidamente.
Si tratta comunque di cifre probabilmente contenute rispetto a quelle pagate a Cloudflare (prezzi non noti), ma vale comunque la pena tenerne conto. Nel lungo periodo l'idea è migrare i file statici su bucket di Google Cloud Storage e, dato che supportano la stessa API S3, le modifiche al codice richieste saranno minime, se non addirittura nulle.
In sintesi
Come si vede, migrare tra fornitori tecnologici non è così complesso come si potrebbe pensare. L'approccio più sicuro, però, resta quello di suddividere il lavoro in fasi più piccole: in caso di problemi è facile fare rollback e si riducono al minimo le interruzioni operative.