Per failover si intende la messa a punta di un sistema che sia in grado di mitigare o evitare gli effetti negativi di un improvviso disservizio o blackout (outage) dovuto a molteplici fattori, da un guasto sulla rete del fornitore di energia elettrica o del provider di connettività fino a problematiche interne dell’infrastruttura (errore umano, hardware danneggiato etc.). L’obiettivo, in sintesi, è quello di avere sempre a disposizione (in standby) delle apparecchiature che subentrino a quelle principali in caso di “fallimento”.
In un interessante post pubblicato sul OpenSource.com,
L’idea di migliorare il sistema di failover è maturata anche in seguito ad alcuni episodi verificatisi (inevitabilmente) nel primo decennio di attività. Tra gli eventi più gravi un downtime di 7 ore (fine 2012) causato dal servizio Elastic Load Balancer AWS: tutte le interazioni tra l’utente e la piattaforma passano per AWS, sottolinea Amjith; solo quando l’user clicca sul pulsante di avvio viene chiamato in causa il CDN (content delivery network) Netflix – che si occupa di servire il contenuto appena richiesto.
AWS è organizzata in region ed availability zone. Ogni region offre diverse “zone” indipendenti tra loro ma collegate da connessioni a bassa latenza. Fonte: sito ufficiale AWS.
Multi region e descrizione della procedura
Per fare in modo che eventuali blackout possano essere gestiti agilmente, la compagnia ha pensato di estendere la piattaforma a 3 region AWS ovvero US East, US West ed European Union. Il cosiddetto setup multi region ha permesso in primo luogo di allocare la capacità necessaria ad affrontare il downtime di un’intera region. La procedura di failover si divide in quattro passaggi:
- identificazione del problema. SPS o stream starts per second è l’unità di misura che gli ingegneri sono in grado di monitorare costantemente in ogni region per stabilire se vi siano o meno dei problemi. Il valore tiene conto del numero di utenti che è riuscito ad avviare lo streaming di un qualsiasi contenuto. Se il grafico mostra dei valori al di sotto della media significa molto probabilmente che alcuni utenti non riescono a fruire del servizio. Amjith specifica che se i valori di SPS sono anomali in due o in tutte le region, Netflix non è in grado di effettuare la procedura di failover. Quest’ultima può essere inoltre non eseguibile in caso di attacchi DDoS, poichè il reindirizzamento del traffico scaricherebbe “i dati spazzatura” sulle region di supporto.
- Preparazione delle region di supporto. Le region di supporto, dette anche savior (salvatore), riceveranno dopo le dovute procedura di preparazione il traffico della region che sta avendo delle difficoltà. In questo passaggio entra in gioco l’analisi dello storico dei picchi di traffico in ciascuna region: per via dei fusi orari, gli utenti dell’US non utilizzano Netflix alla medesima ora di quelli europei. “Il picco di traffico nella region US East è tre ore avanti rispetto all’US West la quale è circa 8 ore indietro rispetto all’UE. Quando [eseguiamo il failover] dell’US East, spostiamo il traffico dall’US East all’UE e dal South America all’US West. Ciò serve a diminuire le latenze e assicurare ai nostri clienti la migliore esperienza d’utilizzo possibile”.
- Proxying del traffico. In questa fase gli ingegneri si affidano al proxy opensource Zuul (sviluppato da Netflix). Il proxying è progressivo, afferma l’ingegnere, in quanto “consente ai nostri servizi di utilizzare le policy di scaling per [eseguire qualsiasi azione reattiva di scaling necessaria a gestire il traffico in arrivo. Ciò serve a compensare [eventuali differenze tra il volume di traffico previsto e quello effettivo alla fine delle procedure di scaling di ciascun cluster]”.
- DNS. La fase conclusiva riguarda il redirect dei record DNS che puntano alla regione in “difficoltà”. Una volta che “punteranno” verso le region savior, il traffico abbandonerà completamente l’area e la procedura potrà considerarsi ultimata.
Il problema del meccanismo di failover, afferma l’ingegnere, era però il tempo totale impiegato, ovvero 45 minuti (nelle giornate migliori), di cui 35 destinati alla preparazione delle region savior (scaling dei cluster).
Volevamo completare i failover in meno di 10 minuti. […] La nostra idea era di mantenere un pool di istanze in hot standby per ciascun microservizio. Quando siamo pronti per il failover, possiamo semplicemente [effettuare l’injection delle istanze in] hot standby nei cluster [e] ricevere il traffico […] Invece del tradizionale metodo di scaling che [chiama in causa AWS] per il provisioning delle istanze, effettuiamo l’injection delle istanze dai cluster ombra a quelli live. Questo processo richiede circa 4 minuti, contro i 35 [del precedente metodo].
Il nuovo meccanismo di failover, soprannominato Project Nimble, ha permesso di abbassare i tempi di reazione e mantenere inalterati i costi infrastrutturali (viene utilizzata la capacità già allocata presso AWS). Il software utilizzato per orchestrare il tutto, conclude, è stato realizzato in Python da un team di 3 ingegneri.
