A partire da lunedì 11 luglio e fino a mercoledì 13 luglio, Proton Mail, Proton VPN(new window) e Proton Drive hanno riscontrato interruzioni intermittenti del servizio, alcune delle quali hanno interessato alcuni utenti per un’ora o più. Queste sono state causate da un errore imprevisto, non da un attacco o altra attività malevola.
Questo non rispetta gli standard che ci poniamo, né è ciò che la comunità Proton si aspetta da noi. Ci scusiamo con te e abbiamo preso provvedimenti per rendere queste tipologie di interruzioni molto meno probabili in futuro. Di seguito spieghiamo cosa è successo, come abbiamo stabilizzato la situazione e cosa abbiamo fatto per prevenire interruzioni future.
Contesto
Negli ultimi mesi, il nostro team di database ha lavorato all’aggiornamento dei nostri database relazionali per renderli più affidabili, veloci e scalabili. Abbiamo testato approfonditamente questi aggiornamenti e, fino a questo momento, ne abbiamo eseguiti decine senza incidenti.
Abbiamo completato l’ultimo aggiornamento la mattina di domenica 10 luglio. Abbiamo lasciato questo particolare database per ultimo perché è la fonte principale di verità per le informazioni sugli account e gli indirizzi email dei membri della comunità. È anche molto, molto sollecitato. Avevamo identificato l’alto tasso di utilizzo di questo database come un rischio. Avevamo già diverse iniziative in corso per ridurre il suo carico di lavoro e migliorare le prestazioni per rendere il sistema complessivo più resiliente e scalabile.
Abbiamo deciso di aggiornare il database prima del completamento di queste iniziative perché i test approfonditi e la nostra esperienza con i precedenti aggiornamenti indicavano che il nuovo database sarebbe stato più veloce. Come parte di questo aggiornamento, abbiamo anche spostato il database su un server più nuovo e veloce. Credevamo che questa combinazione di software e hardware più recenti avrebbe migliorato le prestazioni e ci avrebbe fornito un margine aggiuntivo per implementare con sicurezza le nostre ottimizzazioni del database più invasive.
L’incidente
Tutti i servizi e le metriche erano normali fino a lunedì 11 luglio alle 14:35 UTC. Con l’aumentare del traffico, le nuove connessioni al nuovo database hanno iniziato a fallire, attivando misure protettive automatiche che impedivano nuove connessioni. Abbiamo lavorato alacremente per capire cosa non andava e ridurre il carico sul database disattivando servizi opzionali o a bassa priorità, come le notifiche dei messaggi.
Normalmente, se si verifica un problema del genere, semplicemente annulleremmo l’aggiornamento e torneremmo alla versione software precedente. Sfortunatamente, questo particolare aggiornamento era irreversibile in quanto comportava la modifica dei formati dei dati del database e avevamo già registrato più di 24 ore di modifiche utilizzando la nuova versione. Ciò significava che eravamo sotto pressione per mitigare i sintomi osservati, trovare la causa principale e individuare 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 aggiuntiva delle connessioni era intrinseca al nuovo codice del database, ma ogni nuova connessione comportava anche una comunicazione di rete in più, aumentando lo stress su uno stack di rete già molto sollecitato.
Questa comunicazione aggiuntiva era causata da un nuovo default di autenticazione introdotto in una recente patch del software del database. Potrebbe non sembrare molto, ma questo database gestisce così tante connessioni che i due pacchetti aggiuntivi aggiunti dal nuovo processo di autenticazione e la latenza aggiuntiva intrinseca delle connessioni erano sufficienti a sovraccaricare il server sia a livello di MySQL che di rete del kernel.
La nostra risposta
Entro la fine del lunedì, non avevamo scoperto questi pacchetti extra, quindi, mentre continuavamo ad indagare, abbiamo anche lavorato per ridurre il tasso di connessione del database. Le misure che abbiamo adottato includono:
- Spostare più carichi di lavoro in sola lettura lontano dal server di database scrivibile
- Ulteriore memorizzazione nella cache di oggetti e query comuni dove possibile
- Rinviare la posta a bassa priorità per livellare i picchi di consegna
Abbiamo confermato il problema di autenticazione mercoledì 13 luglio, alle 1:00 AM UTC. Per mitigarlo, il nostro team ha lavorato per attivare nuovi server, che abbiamo utilizzato per distribuire il carico su più server ed evitare che uno solo fosse sopraffatto.
Alle 8:42 AM UTC, abbiamo ripristinato il parametro di autenticazione al valore predefinito usato nella versione precedente. Questo ha contribuito a ridurre il carico di attività sul server di database e, insieme alle ottimizzazioni già effettuate, ha praticamente eliminato gli errori e gli avvisi che avevamo ricevuto negli ultimi due giorni.
Tuttavia, abbiamo scoperto un problema secondario alle 2:14 PM 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 avrebbe sopraffatto i server replica, causando il reindirizzamento del traffico verso il database principale, che a sua volta creava instabilità e interruzioni occasionali del servizio fino a quando il livello di attività non diminuiva.
Abbiamo eliminato questo carico di sincronizzazione (tramite caching) poco prima delle 4:00 PM UTC e stabilizzato i database replica, risolvendo così definitivamente l’instabilità intermittente.
Ripristino inoltro
Nei giorni successivi all’incidente, abbiamo sviluppato, validato ed eseguito il primo di diversi previsti scissioni di questo database per ridurne permanentemente il carico di lavoro. Il nostro team ha implementato queste scissioni con successo senza interrompere il nostro servizio. Abbiamo anche iniziative in corso per migliorare il nostro pooling di connessioni in modo che questo problema specifico non possa ripetersi in futuro.
Queste misure, sebbene necessarie, non sono sufficienti. Ci rendono meglio preparati ad affrontare l’ultima guerra, ma non anticipano problemi futuri né affrontano il processo decisionale che ha portato a questo incidente.
Per raggiungere questo obiettivo, i nostri team di infrastruttura e applicazione stanno eseguendo una revisione approfondita su più livelli di tutti i servizi e sistemi per comprendere meglio le possibili modalità di fallimento e come possiamo mitigarle. I revisori sono composti da proprietari dei servizi e altri membri del team per assicurare che abbiamo competenze specifiche e nuovi punti di vista. L’obiettivo di questa revisione è prevenire i guasti ma anche localizzare i potenziali fallimenti e prevenire cascate e interruzioni del servizio su larga scala il più possibile. Alcune correzioni saranno rapide, altre sono architettoniche e richiederanno tempo, ma siamo impegnati a rendere i servizi Proton affidabili come la comunità Proton si aspetta e merita.
Sul lato decisionale, abbiamo dissezionato il processo e gli input che hanno portato alla decisione di effettuare l’aggiornamento prima della scissione per assicurarci di prendere la decisione corretta la prossima volta. Poche, pochissime modifiche che apportiamo, sia all’infrastruttura sia al codice dell’applicazione, sono irreversibili, e per buoni motivi. Infatti, questo è l’unico cambiamento del genere negli ultimi anni. In questo caso, tentare di rendere il cambiamento reversibile non sarebbe stato fattibile. Ma il fatto che fosse irreversibile avrebbe dovuto innescare un processo di approvazione del cambiamento più cauto, e il precedente track record di successo dell’aggiornamento ci ha resi troppo sicuri che questo database si sarebbe comportato allo stesso modo, nonostante il suo carico di lavoro notevolmente più pesante.
Questa è un’opportunità per noi di rivalutare il nostro approccio infrastrutturale e, in ultima analisi, ci porterà a essere più resilienti e meglio preparati in futuro. Grazie a tutti nella comunità Proton per la vostra pazienza durante l’interruzione del servizio. Abbiamo imparato molte lezioni che ci saranno utili mentre lavoriamo per costruire un internet in cui la privacy è la norma, e ti ringraziamo ancora per il tuo sostegno.
