Iniziamo con cosa significa esattamente 4 9:
Quattro nove sono 4,38 minuti di downtime al mese, o 52,56 minuti all’anno.
Questo è probabilmente più che accettabile per quasi tutti i servizi su Internet, non tutti, ma quasi tutti. Quindi la tua email è giù per 4 minuti ogni mese, non è la fine del mondo. Voglio dire, probabilmente non te ne accorgeresti nemmeno. Nel momento in cui andrai a controllare Twitter per vedere se sei solo tu o no, sarà di nuovo attivo.
In genere per ottenere un buon uptime, pensiamo di aggiungere ridondanza e replicazione in modo che se un server fallisce, ne hai già altri in funzione che subentrano immediatamente. Il problema con questo approccio è che è complicato e costoso. Hai bisogno di più server, di solito 3 o più sia per la tua app che per il tuo database, in più avrai bisogno di un bilanciatore di carico davanti. E poi dovete gestire/monitorare tutte queste macchine.
E con la nuova tendenza dei microservizi in cui le persone stanno dividendo le loro app in servizi più piccoli, dovete ripetere queste complicate configurazioni per ogni servizio.
Se state costruendo un microservizio, meno “roba” avete bisogno per farlo funzionare, meglio è. Non vuoi dover andare a configurare un nuovo database replicato ogni volta che vuoi mettere insieme una piccola API, vero? Voglio essere super produttivo, voglio essere in grado di sfornare un servizio velocemente senza avere a che fare con tutte quelle cose complicate e che fanno perdere tempo.
Quindi mi sono messo a pensare, “beh, e se ci fosse un modo per essere… abbastanza affidabili?” Voglio dire, quante delle cose che costruisci hanno effettivamente bisogno di essere altamente disponibili? Quanti servizi non possono permettersi di essere giù per qualche minuto qua e là o di perdere un po’ di dati una volta ogni tanto a causa di un guasto fatale del server?
Io credo che non ci siano molti servizi che non possono permettersi di perdere una quantità molto piccola di dati e avere qualche minuto di inattività all’anno. Anche se architetti l’inferno dal tuo servizio, probabilmente avrai comunque dei tempi di inattività per qualche motivo. Quindi perché non mantenerlo semplice.
Primo, alcuni numeri: diciamo che in media, un’istanza EC2 di AWS fallisce ogni sei mesi. Penso che sia molto meno di questo al giorno d’oggi, ma nessuno lo sa veramente, quindi saremo conservatori. Questo ci dà circa 26,5 minuti per recuperare l’app ogni sei mesi, pur avendo ancora 4 9 di uptime.
Ecco come si possono ottenere 4 9 su una singola macchina.
Step 1) Lanciare il server, distribuire l’app e cambiare lo script DNS
La prima cosa di cui abbiamo bisogno è un semplice script che possa lanciare una nuova istanza, avviare l’app (Docker lo rende facile) e cambiare i DNS per puntare alla nuova istanza. Non entrerò nel dettaglio di questo passo in questo post, ma se potete fare uno script one liner che possa fare questi passi, siete a posto. Service fails: run script.
Step 2) Database con Auto Backup e Auto Recover
Se puoi assicurarti di avere dei backup molto recenti del tuo database e questi sono memorizzati in un luogo facilmente accessibile come S3, allora puoi creare un’app che può recuperare se stessa quando si avvia. L’utilizzo di un database incorporato rende tutto più semplice, dal momento che hai solo bisogno di distribuire una sola cosa: la tua app.
Ho usato molto BoltDB ultimamente, soprattutto perché scrivo molto su Go e Bolt è un semplice database incorporato disponibile in un pacchetto Go che si usa come qualsiasi altra dipendenza. Quindi non è necessario eseguire un database separato a cui connettersi e avere a che fare con il mantenerlo in esecuzione. Basta usare la libreria e i dati vengono scritti sul tuo disco locale.
Ora questo è anche il problema con Bolt, i dati sono solo sulla tua macchina locale insieme alla tua applicazione. Se la macchina fallisce, perdi tutti i tuoi dati.
Ebbene, che ne dici di fare un backup ogni minuto o 2? Ed essere in grado di recuperare automaticamente da quel backup quando l’app si avvia?
Ho creato un lib che fa proprio questo, chiamato Bolt Backup e semplicemente cambiando la linea di inizializzazione di BoltDb, farà automaticamente il backup del database su S3 e meglio ancora, quando si avvia l’app, recupererà dal backup più recente.
Puoi facilmente testare questo aggiungendo dati al tuo database Bolt, uccidendo la tua app, cancellando il file di dati Bolt, poi riavviando la tua app. Continuerà da dove ha lasciato, non importa dove riavvii la tua app.
Ecco un’app di esempio che lo usa e che puoi provare: https://github.com/treeder/bolt-backup/tree/master/example
Conclusione
Con i semplici concetti di cui sopra, puoi recuperare la tua app in meno di 26 minuti e quindi ottenere 4 9 o meglio di uptime. Assicuratevi solo che sia tutto automatizzato con uno script di lancio e il recupero automatico del database come la libreria Bolt Backup menzionata sopra.
Il valore della semplicità può a volte perdersi quando ci eccitiamo con la “scala web”, ma spesso si può risparmiare un sacco di tempo e dolore se si mantengono le cose semplici. E un sacco di soldi.