À partir du lundi 11 juillet et jusqu’au mercredi 13 juillet, Proton Mail, Proton VPN(nouvelle fenêtre) et Proton Drive ont connu des perturbations de service intermittentes, dont certaines ont touché certains utilisateurs pendant une heure ou plus. Ceci a résulté d’une erreur inattendue, et non d’une attaque ou d’une autre activité malveillante.
Cela ne respecte pas les normes que nous nous imposons, ni ce que la communauté Proton attend de nous. Nous vous prions de nous excuser, et nous avons pris des mesures pour rendre ces types d’interruptions beaucoup moins probables à l’avenir. Ci-dessous, nous expliquons ce qui s’est passé, comment nous avons stabilisé la situation et ce que nous avons fait pour prévenir de futures perturbations.
Arrière-plan
Au cours des derniers mois, notre équipe de base de données a mis à jour nos bases de données relationnelles pour les rendre plus fiables, plus rapides et plus évolutives. Nous avons largement testé ces mises à jour et, jusqu’à présent, nous en avons effectuées des dizaines sans incident.
Nous avons terminé la dernière mise à jour le matin du dimanche 10 juillet. Nous avons réservé cette base de données particulière pour la fin car elle est la source ultime de vérité pour les informations du compte et de l’adresse e-mail des membres de la communauté. Elle est aussi très, très sollicitée. Nous avions identifié le taux d’utilisation élevé de cette base de données comme un risque. Nous avions déjà plusieurs initiatives en cours pour réduire sa charge de travail et améliorer ses performances afin de rendre l’ensemble du système plus résilient et évolutif.
Nous avons décidé de mettre à jour la base de données avant que ces initiatives ne soient terminées, car les tests approfondis et notre expérience des mises à jour précédentes indiquaient que la nouvelle base de données serait plus rapide. Dans le cadre de cette mise à jour, nous avons également déplacé la base de données vers un serveur plus récent et plus rapide. Nous pensions que cette combinaison de nouveau logiciel et matériel améliorerait les performances et nous donnerait une marge supplémentaire pour appliquer en toute sécurité nos optimisations de base de données les plus invasives.
L’incident
Tous les services et indicateurs étaient normaux jusqu’au lundi 11 juillet, à 14h35 UTC. À mesure que le trafic augmentait, les nouvelles connexions à la nouvelle base de données ont commencé à échouer, activant des mesures de protection automatiques qui empêchaient de nouvelles connexions. Nous avons travaillé pour comprendre ce qui n’allait pas et réduire la charge de la base de données en désactivant des services optionnels ou de faible priorité, comme les notifications de message.
En général, si un problème comme celui-ci se présente, nous annulerions simplement la mise à jour et reviendrions à la version précédente du logiciel. Malheureusement, cette mise à jour particulière était irréversible car elle impliquait de changer les formats de données de la base de données, et nous avions déjà enregistré plus de 24 heures de changements avec la nouvelle version. Cela signifiait que nous étions pressés de réduire les symptômes que nous avons observés, de trouver la cause profonde et de trouver un moyen permanent d’avancer.
Nous savons maintenant que le logiciel de base de données était plus rapide après la mise à jour, mais les nouvelles connexions à cette base de données ne l’étaient pas. Une partie de cette latence de connexion supplémentaire était inhérente au nouveau code de base de données, mais chaque nouvelle connexion avait également un aller-retour de communication réseau supplémentaire, augmentant la pression sur une pile réseau déjà chargée.
Cette communication aller-retour supplémentaire a été causée par un nouveau paramètre d’authentification introduit dans un patch récent du logiciel de base de données. Cela peut ne pas sembler beaucoup, mais cette base de données traite tellement de connexions que les deux paquets supplémentaires ajoutés par le nouveau processus d’authentification et la latence de connexion inhérente étaient suffisants pour submerger le serveur aux niveaux réseau MySQL et noyau.
Notre réponse
À la fin de lundi, nous n’avions pas découvert ces paquets supplémentaires, donc tout en continuant d’enquêter, nous avons également travaillé pour réduire le taux de connexion de la base de données. Les mesures que nous avons prises comprenaient :
- Déplacer davantage de charges de travail en lecture seule loin du serveur de base de données en écriture
- Mise en cache supplémentaire d’objets et de requêtes courantes lorsque cela est possible
- Différer les e-mails de faible priorité pour lisser les pics de livraison
Nous avons confirmé le problème d’authentification le mercredi 13 juillet à 1h00 UTC. Pour l’atténuer, notre équipe a travaillé pour mettre en ligne de nouveaux serveurs, que nous avons utilisés pour répartir la charge sur plusieurs serveurs afin d’éviter que l’un d’eux ne soit submergé.
À 8h42 UTC, nous avons restauré le paramètre d’authentification à la valeur par défaut utilisée dans la version précédente. Cela a contribué à réduire la charge d’activité sur le serveur de base de données et, avec les optimisations déjà effectuées, a essentiellement éliminé les erreurs et alertes que nous avons reçues au cours des deux derniers jours.
Cependant, nous avons découvert un problème secondaire à 14h14 UTC qui a commencé lorsque nous avons réparti la charge de travail sur plusieurs serveurs. Ces nouveaux serveurs réplicas consacraient plus de 50 % de leur puissance de traitement à vérifier leur synchronisation avec la base de données principale modifiable. Cela signifiait qu’aux heures d’activité maximales, le nombre de connexions submergerait les serveurs de répliques, provoquant la redirection du trafic vers la base de données principale, ce qui créait à son tour une instabilité et interrompait occasionnellement le service jusqu’à ce que les niveaux d’activité diminuent.
Nous avons éliminé cette charge de synchronisation (en mettant en cache) peu avant 16h00 UTC et stabilisé les bases de données réplicas, résolvant ainsi définitivement l’instabilité intermittente.
À l’avenir
Dans les jours qui ont suivi l’incident, nous avons développé, validé et exécuté le premier d’un certain nombre de découpages prévus de cette base de données pour réduire de manière permanente sa charge de travail. Notre équipe a mis en œuvre ces découpages avec succès sans perturber notre service. Nous avons également des initiatives en cours pour améliorer notre gestion des connexions afin que ce problème spécifique ne se reproduise plus à l’avenir.
Ces mesures, bien que nécessaires, ne sont pas suffisantes. Elles nous rendent mieux préparés à lutter contre la dernière guerre, mais elles n’anticipent pas les problèmes futurs ni n’abordent le processus de prise de décision qui a conduit à cet incident.
Pour atteindre cet objectif, nos équipes d’infrastructure et d’application réalisent un examen approfondi en plusieurs étapes de tous les services et systèmes afin de mieux comprendre les modes d’échec possibles et comment nous pouvons les atténuer. Les examinateurs se composent de responsables de services et d’autres membres de l’équipe pour garantir que nous avons l’expertise pertinente et des perspectives nouvelles. L’accent de cet examen est de prévenir les failles mais aussi de localiser les défaillances potentielles et d’empêcher les cascades et les interruptions de service à grande échelle dans la mesure du possible. Certaines corrections seront rapides, et d’autres sont structurelles et prendront du temps, mais nous nous engageons à rendre les services Proton aussi fiables que ce que la communauté Proton attend et mérite.
Du côté de la prise de décision, nous avons disséqué le processus et les éléments qui ont conduit à la décision de procéder à la mise à jour avant la séparation pour garantir que nous prenions la bonne décision la prochaine fois. Très, très peu de changements que nous apportons, que ce soit à l’infrastructure ou au code de l’application, sont irréversibles, et pour de bonnes raisons. En fait, c’est le seul changement de ce type au cours des dernières années. Dans ce cas, tenter de rendre le changement réversible n’aurait pas été faisable. Mais le fait qu’il soit irréversible aurait dû déclencher un processus d’approbation des changements plus prudent, et le bon bilan de réussite de la mise à jour nous a rendus trop confiants que cette base de données se comporterait de la même manière, malgré sa charge de travail beaucoup plus lourde.
C’est une occasion pour nous de réévaluer notre approche en matière d’infrastructure, et cela nous rendra finalement plus résilients et mieux préparés à l’avenir. Merci à tous dans la communauté Proton pour votre patience pendant la perturbation du service. Nous avons appris de nombreuses leçons qui nous seront utiles alors que nous travaillons à créer un internet où la confidentialité est la norme, et nous vous remercions encore pour votre soutien.
