Von Montag, dem 11. Juli, bis Mittwoch, dem 13. Juli, erlebten Proton Mail, Proton VPN(neues Fenster) und Proton Drive sporadische Störungen, die einige Nutzer für eine Stunde oder länger betrafen. Diese resultierten aus einem unerwarteten Fehler, nicht aus einem Angriff oder anderen böswilligen Aktivitäten.
Das entspricht nicht den Standards, die wir uns selbst setzen, noch ist es das, was die Proton-Community von uns erwartet. Wir entschuldigen uns bei dir und haben Maßnahmen ergriffen, um diese Arten von Unterbrechungen in Zukunft deutlich unwahrscheinlicher zu machen. Nachfolgend erklären wir, was passiert ist, wie wir die Situation stabilisiert haben und was wir unternommen haben, um zukünftige Unterbrechungen zu verhindern.
Hintergrund
In den letzten Monaten hat unser Datenbank-Team unsere relationalen Datenbanken aktualisiert, um zuverlässiger, schneller und skalierbarer zu sein. Wir haben diese Upgrades gründlich getestet und bis zu diesem Zeitpunkt Dutzende davon ohne Vorfälle durchgeführt.
Wir haben das letzte Upgrade am Sonntag, den 10. Juli, abgeschlossen. Wir haben diese spezielle Datenbank zuletzt reserviert, da sie die endgültige Quelle für die Daten zu Kontoinformationen und E-Mail-Adressen von Mitgliedern der Community ist. Sie ist auch sehr, sehr beschäftigt. Wir hatten diese hohe Nutzung dieser Datenbank als Risiko identifiziert. Wir hatten bereits mehrere Initiativen in Planung, um die Arbeitslast zu reduzieren und die Leistung zu verbessern, um das gesamte System widerstandsfähiger und skalierbarer zu machen.
Wir beschlossen, die Datenbank vor Abschluss dieser Initiativen zu aktualisieren, da die umfangreichen Tests und unsere Erfahrungen von den vorherigen Datenbank-Upgrades darauf hindeuteten, dass die neue Datenbank schneller sein würde. Im Rahmen dieses Upgrades haben wir auch die Datenbank auf einen neueren, schnelleren Server verschoben. Wir glaubten, dass diese Kombination aus neuer Software und Hardware die Leistung verbessern würde und uns eine zusätzliche Marge bieten würde, um unsere invasiveren Datenbank-Optimierungen sicher umzusetzen.
Der Vorfall
Alle Dienste und Messwerte waren bis Montag, dem 11. Juli, um 14:35 Uhr UTC normal. Als der Verkehr zunahm, fingen neue Verbindungen zur neuen Datenbank an zu scheitern, was automatische Schutzmaßnahmen aktivierte, die neue Verbindungen verhinderten. Wir bemühten uns herauszufinden, was falsch war und die Last der Datenbank zu reduzieren, indem wir optionale oder weniger wichtige Dienste wie Nachrichtenbenachrichtigungen ausschalteten.
Normalerweise würden wir, wenn ein Problem wie dieses auftritt, 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 erforderte, und wir hatten bereits mehr als 24 Stunden Änderungen mit der neuen Version aufgezeichnet. Das bedeutete, dass wir unter Zeitdruck standen, die beobachteten Symptome zu mildern, die Ursache zu finden und einen dauerhaften Weg nach vorne zu finden.
Wir wissen jetzt, dass die Datenbanksoftware nach dem Upgrade schneller war, die neuen Verbindungen zu dieser Datenbank jedoch nicht. Ein Teil dieser zusätzlichen Verbindungslatenz war im neuen Datenbank-Code inhärent, aber jede neue Verbindung hatte auch eine zusätzliche Hin- und Rück-Rundreise-Netzwerkkommunikation, die die Belastung eines bereits stark beanspruchten Netzwerk-Stacks erhöhte.
Diese zusätzliche Hin- und Rück-Kommunikation wurde durch eine neue Standardauthentifizierung verursacht, die in einem kürzlichen Patch der Datenbanksoftware eingeführt wurde. Das mag nicht viel erscheinen, 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-Netzwerkniveau zu überlasten.
Unsere Antwort
Bis Montagabend hatten wir diese zusätzlichen Pakete nicht entdeckt, also während wir weiterhin ermittelten, arbeiteten wir auch daran, die Verbindungsrate der Datenbank zu reduzieren. Die Schritte, die wir unternahmen, beinhalteten:
- Verschieben von mehr schreibgeschützten Arbeitslasten vom schreibbaren Datenbankserver
- Zusätzliches Caching von Objekten und häufigen Abfragen, wenn möglich
- Verschieben von niedrigprioritären Mails, um Zustellspitzen abzufangen
Wir bestätigten das Authentifizierungsproblem am Mittwoch, dem 13. Juli, um 1 Uhr UTC. Um dies zu mildern, arbeitete unser Team daran, neue Server online zu bringen, die wir nutzten, um die Last auf mehrere Server zu verteilen und zu verhindern, dass ein einzelner überlastet wird.
Um 8:42 Uhr UTC änderten wir den Authentifizierungsparameter zurück auf die Standardwerte der vorherigen Version. Das half, die Aktivitätslast auf dem Datenbankserver zu reduzieren und schadete zusammen mit den bereits vorgenommenen Optimierungen, die im Wesentlichen die Fehler und Warnungen, die wir in den letzten zwei Tagen bekommen hatten, beseitigte.
Allerdings entdeckten wir ein sekundäres Problem um 14:14 Uhr UTC, das begann, als wir die Arbeitslast auf mehrere Server verteilt hatten. Diese neuen Replikat-Server widmeten mehr als 50 % ihrer Rechenleistung zur Überprüfung ihrer Synchronisation mit der schreibbaren Primärdatenbank. Das bedeutete, dass zu Spitzenzeiten die Anzahl der Verbindungen die Replikat-Server überlasten würde, was dazu führte, dass der Verkehr zur Hauptdatenbank umgeleitet wurde, was wiederum Instabilität verursachte und gelegentlich den Dienst bis zur Reduzierung des Aktivitätsniveaus unterbrach.
Wir haben diese Synchronisationslast (durch Caching) kurz vor 16:00 Uhr UTC beseitigt und die Replikat-Datenbanken stabilisiert, was die intermittierende Instabilität dauerhaft behob.
Für die Zukunft
In den Tagen nach dem Vorfall haben wir die erste von mehreren geplanten Aufteilungen dieser Datenbank entwickelt, validiert und durchgeführt, um die Arbeitslast dauerhaft zu reduzieren. Unser Team hat diese Aufteilungen erfolgreich umgesetzt, ohne unseren Dienst zu stören. Wir haben auch Initiativen in Planung, um unser Verbindungs-Pooling zu verbessern, damit dieses spezifische Problem in Zukunft nicht wieder auftritt.
Diese Maßnahmen sind zwar notwendig, reichen aber nicht aus. Sie machen uns besser vorbereitet auf den letzten Krieg, aber sie antizipieren keine zukünftigen Probleme oder adressieren den Entscheidungsprozess, der zu diesem Vorfall geführt hat.
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 Fehlermodi besser zu verstehen und wie wir diese mildern können. Die Prüfer bestehen aus Dienstverantwortlichen und anderen Teammitgliedern, um sicherzustellen, dass wir über Fachwissen und frische Perspektiven verfügen. Der Schwerpunkt dieser Überprüfung liegt darauf, Ausfälle zu verhindern, aber auch potenzielle Ausfälle zu lokalisieren und Kaskaden sowie großangelegte Serviceunterbrechungen so gut wie möglich zu verhindern. Einige Lösungen werden schnell sein, andere sind architektonisch und nehmen Zeit in Anspruch, aber wir sind entschlossen, die Proton-Dienste so zuverlässig zu machen, wie die Proton-Community es erwartet und verdient.
In Bezug auf den Entscheidungsprozess haben wir den Prozess und die Eingaben, die zur Entscheidung führten, das Upgrade vor der Aufteilung durchzuführen, genau unter die Lupe genommen, um sicherzustellen, dass wir beim nächsten Mal die richtige Entscheidung treffen. Sehr, sehr wenige Änderungen, die wir vornehmen, sei es an der Infrastruktur oder am Anwendungscode, sind irreversibel, und das aus gutem Grund. In der Tat ist dies die einzige solche Änderung in den letzten Jahren. In diesem Fall wäre es nicht machbar gewesen, die Änderung umkehrbar zu gestalten. Aber die Tatsache, dass es irreversibel war, hätte einen vorsichtigeren Genehmigungsprozess für Änderungen auslösen sollen, und die zuvor erfolgreiche Erfolgsbilanz dieses Upgrades machte uns zuversichtlich, dass diese Datenbank sich gleich verhalten würde, trotz ihrer erheblich schwereren Arbeitslast.
Dies ist eine Gelegenheit für uns, unseren Infrastrukturansatz neu zu bewerten, und letztendlich wird es dazu führen, dass wir in Zukunft widerstandsfähiger und besser vorbereitet sind. Danke an alle in der Proton-Community für eure Geduld während der Dienstunterbrechung. Wir haben viele Lektionen gelernt, die uns dabei helfen werden, ein Internet aufzubauen, in dem Privatsphäre die Norm ist, und wir danken euch erneut für eure Unterstützung.
