Dal lunedì 11 luglio al mercoledì 13 luglio, Proton Mail, Proton VPN(nuova finestra) e Proton Drive hanno subito interruzioni di servizio intermittenti, alcune delle quali hanno colpito gli utenti per un’ora o più. Queste sono state causate da un errore inaspettato, non da un attacco o altre attività malevole.
Questo non soddisfa gli standard a cui ci atteniamo, né è ciò che la comunità Proton si aspetta da noi. Ci scusiamo con te e abbiamo preso provvedimenti per ridurre al minimo la probabilità di queste interruzioni in futuro. Di seguito spieghiamo cosa è successo, come abbiamo stabilizzato la situazione e cosa abbiamo fatto per prevenire future interruzioni.
Background
Negli ultimi mesi, il nostro team di database ha aggiornato i nostri database relazionali per renderli più affidabili, veloci e scalabili. Abbiamo testato ampiamente questi aggiornamenti e, fino a questo punto, ne abbiamo eseguiti decine senza incidenti.
Abbiamo completato l’ultimo aggiornamento la mattina di domenica 10 luglio. Abbiamo salvato questo particolare database per ultimo perché è la fonte principale di informazioni sugli account dei membri della community e sugli indirizzi email. È anche molto, molto utilizzato. Avevamo già identificato l’alta frequenza d’uso di questo database come un rischio. Avevamo già in corso diverse iniziative per ridurre il suo carico di lavoro e migliorare le prestazioni per rendere l’intero sistema più resiliente e scalabile.
Abbiamo deciso di aggiornare il database prima che queste iniziative fossero completate perché i test approfonditi e la nostra esperienza negli aggiornamenti dei database precedenti indicavano che il nuovo database sarebbe stato più veloce. Come parte di questo aggiornamento, abbiamo anche spostato il database su un server più recente e veloce. Credevamo che questa combinazione di software e hardware più recenti avrebbe migliorato le prestazioni e ci avrebbe dato un margine aggiuntivo per implementare in modo sicuro le nostre ottimizzazioni più invasive del database.
L’incidente
Tutti i servizi e le metriche erano normali fino a lunedì 11 luglio, alle 14:35 UTC. Man mano che il traffico aumentava, nuove connessioni al nuovo database iniziavano a fallire, attivando misure protettive automatiche che impedivano nuove connessioni. Ci siamo affrettati a capire cosa non andasse e ridurre il carico del database disattivando i servizi opzionali o a bassa priorità, come le notifiche di messaggi.
Di solito, se si verifica un problema del genere, annulliamo semplicemente l’aggiornamento e torniamo alla versione precedente del software. Sfortunatamente, questo particolare aggiornamento era irreversibile poiché riguardava la modifica dei formati dei dati del database e avevamo già registrato oltre 24 ore di modifiche utilizzando la nuova versione. Questo significava che eravamo sotto pressione per mitigare i sintomi che osservavamo, trovare la causa principale e trovare una soluzione permanente.
Ora sappiamo che il software del database era più veloce dopo l’aggiornamento, ma le nuove connessioni a quel database non lo erano. Parte di questa latenza di connessione aggiuntiva era intrinseca al nuovo codice del database, ma ogni nuova connessione aveva anche una comunicazione di rete a viaggio di andata e ritorno extra, aumentando il carico su una rete già occupata.
Questa comunicazione di andata e ritorno extra è stata causata da un nuovo default di autenticazione introdotto in una recente patch del software del database. Questo potrebbe non sembrare molto, ma questo database gestisce così tante connessioni che i due pacchetti extra aggiunti dal nuovo processo di autenticazione e la latenza di connessione intrinseca erano sufficienti per sovraccaricare il server sia a livello MySQL che a livello kernel della rete.
La nostra risposta
Entro la fine di lunedì, non avevamo scoperto questi pacchetti extra, quindi mentre continuavamo a indagare, abbiamo anche lavorato per ridurre il tasso di connessione del database. I passi che abbiamo intrapreso includono:
- Spostare più carichi di lavoro in sola lettura da un server di database scrivibile
- Caching aggiuntivo di oggetti e query comuni dove possibile
- Rimandare le email a bassa priorità per smussare i picchi di consegna
Abbiamo confermato il problema di autenticazione mercoledì 13 luglio alle 1:00 UTC. Per mitigarne gli effetti, il nostro team ha lavorato per rendere operativi nuovi server, che abbiamo utilizzato per distribuire il carico su più server per evitare che uno solo venisse sopraffatto.
Alle 8:42 UTC, abbiamo ripristinato il parametro di autenticazione al default usato nella versione precedente. Questo ha contribuito a ridurre il carico di attività sul server database e, insieme alle ottimizzazioni già effettuate, ha sostanzialmente eliminato gli errori e gli avvisi ricevuti negli ultimi due giorni.
Tuttavia, abbiamo scoperto un problema secondario alle 14:14 UTC che è iniziato quando abbiamo distribuito il carico di lavoro su più server. Questi nuovi server replica dedicavano oltre il 50% della loro potenza di elaborazione per verificare la loro sincronizzazione con il database primario scrivibile. Questo significava che nei momenti di picco di attività, il numero di connessioni sopraffaceva i server replica, facendo sì che il traffico fosse reindirizzato di nuovo al database principale, creando instabilità e occasionalmente interrompendo il servizio fino a quando i livelli di attività non scendevano.
Abbiamo eliminato questo carico di sincronizzazione (caching) poco prima delle 16:00 UTC e abbiamo stabilizzato i database replica, il che ha risolto definitivamente l’instabilità intermittente.
Andando avanti
Nei giorni successivi all’incidente, abbiamo sviluppato, validato ed eseguito il primo di diversi piani di divisione di questo database per ridurre permanentemente il suo carico di lavoro. Il nostro team ha implementato queste divisioni con successo senza interrompere il nostro servizio. Abbiamo anche iniziative in corso per migliorare il nostro pooling delle connessioni in modo che questo specifico problema non possa ripresentarsi in futuro.
Queste misure, sebbene necessarie, non sono sufficienti. Ci rendono meglio preparati a combattere l’ultima guerra, ma non anticipano i problemi futuri né affrontano il processo decisionale che ha portato a questo incidente.
Per raggiungere questo obiettivo, i nostri team infrastrutturali e applicativi stanno eseguendo una revisione approfondita in più fasi di tutti i servizi e sistemi per comprendere meglio i possibili modi di guasto e come possiamo mitigarli. I revisori consistono di proprietari di servizio e altri membri del team per garantire di avere competenze specifiche e nuovi punti di vista. L’enfasi di questa revisione è prevenire i guasti ma anche localizzare potenziali guasti e prevenire cascami e interruzioni di servizio su larga scala ove possibile. Alcuni interventi saranno rapidi, mentre altri sono architettonici e richiederanno tempo, ma siamo impegnati a rendere i servizi Proton affidabili come la comunità Proton si aspetta e merita.
Dal lato decisionale, abbiamo analizzato il processo e le informazioni che hanno portato alla decisione di fare l’aggiornamento prima della divisione per assicurarci di prendere la decisione corretta la prossima volta. Molto, molto poche modifiche che apportiamo, sia all’infrastruttura che al codice dell’applicazione, sono irreversibili, e per una buona ragione. In effetti, questa è l’unica modifica di questo tipo negli ultimi anni. In questo caso, tentare di rendere la modifica reversibile non sarebbe stato fattibile. Ma il fatto che fosse irreversibile avrebbe dovuto attivare un processo di approvazione delle modifiche più cauto, e il successo precedente dell’aggiornamento ci ha reso eccessivamente sicuri che questo database si sarebbe comportato allo stesso modo, nonostante il carico di lavoro molto più pesante.
Questa è un’opportunità per noi di rivalutare il nostro approccio infrastrutturale e alla fine ci porterà ad essere più resilienti e meglio preparati in futuro. Grazie a tutti nella comunità Proton per la vostra pazienza durante la disruzione del servizio. Abbiamo imparato molte lezioni che ci serviranno bene mentre lavoriamo per costruire un internet in cui la privacy sia la norma, e ti ringraziamo ancora per il tuo supporto.
