Vom Montag, den 11. Juli, bis Mittwoch, den 13. Juli, erlebten Proton Mail, Proton VPN(new window) und Proton Drive intermittierende Dienstunterbrechungen, von denen einige Nutzer eine Stunde oder länger betroffen waren. Diese resultierten aus einem unerwarteten Fehler, nicht aus einem Angriff oder anderer bösartiger Aktivität.
Das entspricht nicht den Standards, die wir an uns selbst stellen, noch ist es das, was die Proton-Gemeinschaft von uns erwartet. Wir entschuldigen uns bei dir und haben Schritte unternommen, um solche Unterbrechungen in Zukunft viel unwahrscheinlicher zu machen. Unten erklären wir, was passiert ist, wie wir die Situation stabilisiert haben und was wir getan haben, um zukünftige Störungen zu verhindern.
Hintergrund
In den letzten Monaten hat unser Datenbankteam unsere relationalen Datenbanken aktualisiert, um sie zuverlässiger, schneller und skalierbarer zu machen. Wir haben diese Upgrades umfangreich getestet und bis zu diesem Zeitpunkt Dutzende davon ohne Zwischenfälle durchgeführt.
Wir haben das letzte Upgrade am Morgen des Sonntag, den 10. Juli, abgeschlossen. Wir haben diese spezielle Datenbank zuletzt gespeichert, weil sie die ultimative Quelle der Wahrheit für die Konten- und E-Mail-Adressinformationen unserer Gemeinschaftsmitglieder ist. Sie ist auch sehr, sehr beschäftigt. Wir hatten die hohe Nutzung dieser Datenbank als Risiko identifiziert. Es liefen bereits mehrere Initiativen, um ihre Arbeitslast zu reduzieren und die Leistung zu verbessern, um das Gesamtsystem widerstandsfähiger und skalierbarer zu machen.
Wir entschieden uns, die Datenbank zu aktualisieren, bevor diese Initiativen abgeschlossen waren, weil die umfangreichen Tests und unsere Erfahrungen aus den vorherigen Datenbankupgrades darauf hinwiesen, dass die neue Datenbank schneller sein würde. Im Rahmen dieses Upgrades haben wir die Datenbank auch auf einen neueren, schnelleren Server umgezogen. Wir glaubten, dass diese Kombination aus neuerer Software und Hardware die Leistung verbessern und uns zusätzlichen Spielraum verschaffen würde, um unsere eingreifenderen Datenbankoptimierungen sicher umzusetzen.
Der Vorfall
Alle Dienste und Metriken waren normal bis Montag, den 11. Juli, um 14:35 Uhr UTC. Als der Verkehr zunahm, begannen neue Verbindungen zur neuen Datenbank zu scheitern, was automatische Schutzmaßnahmen aktivierte, die neue Verbindungen verhinderten. Wir arbeiteten schnell daran, herauszufinden, was falsch war, und die Last der Datenbank zu verringern, indem wir optionale oder niedrigprioritäre Dienste wie Nachrichtenbenachrichtigungen abschalteten.
Normalerweise würden wir bei einem solchen Problem einfach das Update rückgängig machen und zur vorherigen Softwareversion zurückkehren. Leider war dieses spezielle Upgrade irreversibel, da es eine Änderung der Datenformate der Datenbank beinhaltete und wir bereits mehr als 24 Stunden an Änderungen mit der neuen Version aufgezeichnet hatten. Das bedeutete, dass wir unter Zeitdruck standen, um die Symptome, die wir beobachteten, zu lindern, die Ursache zu finden und einen dauerhaften Weg nach vorn zu finden.
Wir wissen jetzt, dass die Datenbanksoftware nach dem Upgrade schneller war, aber die neuen Verbindungen zu dieser Datenbank waren es nicht. Ein Teil dieser zusätzlichen Verbindungslatenz war der neuen Datenbanksoftware inhärent, aber jede neue Verbindung verursachte auch eine zusätzliche Rundreise-Netzwerkkommunikation, was die Belastung eines bereits beschäftigten Netzwerkstapels erhöhte.
Diese zusätzliche Rundreise-Kommunikation wurde durch eine neue Authentifizierungsstandard verursacht, der in einem kürzlichen Patch der Datenbanksoftware eingeführt wurde. Das mag nicht nach viel klingen, aber diese Datenbank verarbeitet so viele Verbindungen, dass die zwei zusätzlichen Pakete, die der neue Authentifizierungsprozess hinzufügte, und die zusätzliche inhärente Verbindungslatenz ausreichten, um den Server sowohl auf MySQL- als auch auf Kernel-Netzwerkebene zu überlasten.
Unsere Reaktion
Bis zum Ende des Montags hatten wir diese zusätzlichen Pakete nicht entdeckt, also setzten wir unsere Untersuchungen fort und arbeiteten gleichzeitig daran, die Verbindungsrate der Datenbank zu reduzieren. Die Schritte, die wir unternahmen, umfassten:
- Verlagerung von mehr schreibgeschützten Arbeitslasten weg vom beschreibbaren Datenbankserver
- Zusätzliches Caching von Objekten und häufigen Abfragen, wo möglich
- Verschiebung von E-Mails mit niedriger Priorität, um Auslieferungsspitzen zu glätten
Wir bestätigten das Authentifizierungsproblem am Mittwoch, den 13. Juli, um 1 Uhr morgens UTC. Um es zu mildern, arbeitete unser Team daran, neue Server in Betrieb zu nehmen, die wir nutzten, um die Last auf mehrere Server zu verteilen und zu verhindern, dass ein einzelner überlastet wird.
Um 8:42 Uhr morgens UTC änderten wir den Authentifizierungsparameter zurück auf den Standard der vorherigen Version. Dies half, die Aktivitätslast auf dem Datenbankserver zu reduzieren und zusammen mit den bereits gemachten Optimierungen, die Fehler und Warnmeldungen der letzten zwei Tage im Wesentlichen zu eliminieren.
Allerdings entdeckten wir um 14:14 Uhr UTC ein sekundäres Problem, das begann, als wir die Arbeitslast auf mehrere Server verteilten. Diese neuen Replikationsserver widmeten mehr als 50% ihrer Rechenleistung der Überprüfung ihrer Synchronisation mit der beschreibbaren Hauptdatenbank. Das bedeutete, dass zu Spitzenzeiten die Anzahl der Verbindungen die Replikationsserver überwältigen würde, was dazu führte, dass der Verkehr zurück zur Hauptdatenbank umgeleitet wurde, was wiederum Instabilität verursachte und gelegentlich den Dienst unterbrach, bis das Aktivitätsniveau sank.
Wir beseitigten diese Synchronisationslast (durch Caching) kurz vor 16:00 Uhr UTC und stabilisierten die Replikationsdatenbanken, was die intermittierende Instabilität dauerhaft löste.
Weiterleitung wird fortgesetzt
In den Tagen nach dem Vorfall entwickelten, validierten und führten wir die erste von mehreren geplanten Aufteilungen dieser Datenbank durch, um ihre Arbeitslast dauerhaft zu reduzieren. Unser Team führte diese Aufteilungen erfolgreich durch, ohne unseren Dienst zu stören. Außerdem haben wir Initiativen in Arbeit, um unser Connection Pooling zu verbessern, sodass dieses spezifische Problem in Zukunft nicht wieder auftreten kann.
Diese Maßnahmen sind zwar notwendig, aber nicht ausreichend. Sie machen uns besser darauf vorbereitet, den letzten Kampf zu bestehen, aber sie antizipieren keine zukünftigen Probleme oder adressieren den Entscheidungsprozess, der zu diesem Vorfall führte.
Um dieses Ziel zu erreichen, führen unsere Infrastruktur- und Anwendungsteams eine gründliche, mehrstufige Überprüfung aller Dienste und Systeme durch, um mögliche Ausfallmodi besser zu verstehen und wie wir sie mildern können. Die Gutachter bestehen aus Diensteigentümern und anderen Teammitgliedern, um sicherzustellen, dass wir Fachwissen und frische Perspektiven haben. Der Schwerpunkt dieser Überprüfung liegt darauf, Ausfälle zu verhindern, aber auch potenzielle Ausfälle zu lokalisieren und Kaskaden und großflächige Dienstunterbrechungen so weit wie möglich zu verhindern. Einige Korrekturen werden schnell gehen, andere sind architektonischer Natur und werden Zeit benötigen, aber wir sind entschlossen, die Proton-Dienste so zuverlässig zu machen, wie es die Proton-Gemeinschaft erwartet und verdient.
Auf der Entscheidungsseite haben wir den Prozess und die Eingaben, die zur Entscheidung führten, das Upgrade vor der Aufteilung durchzuführen, analysiert, um sicherzustellen, dass wir das nächste Mal die richtige Entscheidung treffen. Sehr, sehr wenige Änderungen, die wir vornehmen, ob an der Infrastruktur oder am Anwendungscode, sind irreversibel, und das aus gutem Grund. Tatsächlich ist dies die einzige solche Änderung in den letzten Jahren. In diesem Fall wäre der Versuch, die Änderung reversibel zu machen, nicht machbar gewesen. Aber die Tatsache, dass sie irreversibel war, hätte einen vorsichtigeren Genehmigungsprozess für die Änderung auslösen sollen, und die bisher erfolgreiche Erfolgsbilanz des Upgrades machte uns überzuversichtlich, dass sich diese Datenbank trotz ihrer wesentlich höheren Arbeitslast genauso verhalten würde.
Dies ist eine Gelegenheit für uns, unseren Infrastrukturansatz neu zu bewerten, und letztlich wird es dazu führen, dass wir in Zukunft widerstandsfähiger und besser vorbereitet sind. Danke an alle in der Proton-Gemeinschaft für eure Geduld während der Dienstunterbrechung. Wir haben viele Lektionen gelernt, die uns gut dienen werden, wenn wir daran arbeiten, ein Internet aufzubauen, in dem Privatsphäre der Standard ist, und wir danken dir erneut für deine Unterstützung.
