Gentlent schneller und zuverlässiger machen

Ah ja, die komplexe Welt der Server- und Cloud-Infrastruktur. Was für ein wunderbarer Ort, um hart verdientes Geld und Zeit zu verbringen, von denen bereits viel zu wenig übrig ist.

G-Core ist das, was wir den monströsen Code von Gentlent nennen, der Domain Name Server (DNS), SMTP (für E-Mails), Tools zur Ankündigung unserer Anycast- und Unicast-IP-Bereiche über das Border Gateway Protocol (BGP) an die Router unserer Rechenzentren enthält, oder einfach nur die grundlegende Geo-IP-API, die Sie in Ihrem nächsten Projekt verwenden könnten. Es laufen sogar noch mehr Dienste darauf, die hier nicht aufgeführt sind, und es skaliert gut, wirklich gut. Aber wie bei allen großartigen Dingen hat es einen großen Fehler. Ein Fehler, den wir bisher noch nicht angegangen sind:

Geht es um Laufwerke? Geht es um Strom? Es geht darum, die Dienste neu zu starten. Um unsere Infrastruktur zuverlässig wie ein Fels zu machen - und ich hoffe, ihr habt die Anspielung verstanden - mussten wir sie verbessern, um für die Mehrheit, wenn nicht alle, unserer zukünftigen Updates und damit Neustarts unterbrechungsfreie Zeiten zu gewährleisten.

Nun, Gentlents Aktualisierungen seines Kerns erfolgen mehrmals täglich, egal ob es sich um eine kleine Optimierung, eine Fehlerbehebung oder eine große Feature-Veröffentlichung handelt. Jedes Update startet denselben Prozess des langsamen Schließens offener Verbindungen, Stoppen der IP-Ankündigungen zum Cluster, Herunterladen des neuen Images und Hochfahren des neuen Containers mit all seinen Diensten, Listenern und Ankündigungen. Updates wurden bereits als "Rolling Updates" durchgeführt, was bedeutet, dass wir nicht alle Server gleichzeitig aktualisieren. Allerdings hosten wir auch teilweise unsere eigenen Nameserver und das Hochfahren dieser Container-Images dauert etwas. Zumindest genug, um von unseren verschiedenen internen und externen Überwachungsdiensten erkannt zu werden. Wir beobachteten auch Zeitüberschreitungen und verweigerte Verbindungen während der Updates.

Was wir haben:

• Unsere Rolling Updates erfordern Neustarts, die DNS und BGP herunterfahren.
• Obwohl BGP Benutzer automatisch zum nächsten nächstgelegenen Rechenzentrum umleitet, wird es immer noch fehlschlagen, bis propagiert wird, und verhindern, dass Cache-Misses unsere öffentlichen und internen Domains korrekt auflösen.

Um diese Probleme anzugehen, haben wir beschlossen, einen weiteren Dienst einzuführen, der während der Updates 24/7 online bleibt und in der Lage ist, den Traffic auf andere Server zu verteilen, falls die Kerndienste auf der Maschine aktualisiert oder neu gestartet werden. Da der Software-Load-Balancer (LB), bei dem es sich in diesem Fall um einen Reverse-Proxy handelt, mit unserem aktuellen Leistungs- und Sicherheitsniveau mithalten muss, haben wir uns für Open-Source-Software entschieden, die dafür optimiert ist.

Diese Reverse-Proxy-Typen von Load-Balancern hatten den Vorteil, dass sie stark optimiert wurden und auf Sprachen wie C++ basierten, die normalerweise eine erhebliche Leistungssteigerung bieten, die die hinzugefügte Latenz kompensieren könnte.

Schnell nach der Implementierung eines ersten Prototyps des neuen Systems stellten wir auch fest, dass wir zwei der schwersten und CPU-intensivsten Aufgaben an den LB auslagern konnten: SSL/TLS-Beendigung und Komprimierung. Dies verringerte unsere gesamten Ladezeiten um mehr als 50 % und erhöhte die Verfügbarkeit und Zuverlässigkeit unserer Infrastruktur immens.

Weitere DNS-Verbesserungen

Wie Sie sich vorstellen können, brauchte es viele Stunden des Versuchs und Irrtums, und wie Sie oben gelesen haben, haben wir es schließlich geschafft, diese Migration abzuschließen. Wir nutzten die Gelegenheit, um unser internes DNS weiter zu verbessern, indem wir alle Zonen aktiv in den lokalen Speicher luden, was die Ladezeiten beschleunigte und die Latenz verringerte. Wir verwendeten die Tools von KeyCDN, um unsere DNS-Leistung mit recht schlechten Ergebnissen zu messen:

Leistungstest

Obwohl unsere Datenbankserver ziemlich schnell sind, dauerte es beim Server in Tokio fast ein Drittel einer Sekunde, um auf eine einzelne DNS-Abfrage zu antworten. Dies geschah nur in bestimmten Fällen, wenn die Anfrage oder Antwort erstmals an einen beliebigen Server gerichtet wurde und daher nicht zwischengespeichert wurde. Es dauerte bis zu einigen hundert Millisekunden, um alle Daten live abzurufen, was massive Latenzspitzen bei der Anfrage hinzufügte.

Dies lag daran, dass der Server eine vollständige Rundreise über den Ozean nach Asien, dann Europa und in unseren zentralen Datenbankserver machte. Durch aktives Laden und Zwischenspeichern aller Zonen werden die 4 asynchronen Datenbankanfragen einschließlich deren Latenz übersprungen und in den Abgrund der Hintergrunddienste ausgelagert.

Wir haben es von über 100 Millisekunden auf durchschnittlich unter 6 ms bei aktiv gesund geprüften lokalen Anfragen reduziert.

Wieder eine enorme Verbesserung, die erledigt, bereitgestellt und komplettiert wurde. Aber wir hören hier nicht auf.