Cloudflare operiert in einem so großen Maßstab, dass es selbst nach jahrelanger Arbeit hier nicht real erscheint. Wir haben Tausende von Servern auf der ganzen Welt mit Petabytes an RAM und Millionen von CPU-Kernen, und all das wird bis zum Maximum ausgereizt. So gewaltig diese Ressourcen auch erscheinen mögen, sie sind dennoch endlich, und wenn jeder Dienst auf jedem Knoten laufen muss, bleibt kein Raum für Verschwendung. In diesem Maßstab werden kleine Verbesserungen stark vergrößert, sodass selbst Verbesserungen von 1 % auf einmal gefeiert werden sollten. Und manche Anpassungen summieren sich zu viel mehr: In diesem Beitrag sehen wir uns an, wie kleine Änderungen an einem einzigen Algorithmus den Speicherbedarf eines unserer Pingora-basierten Dienste erheblich reduziert haben. Dadurch konnten wir weltweit über 100TB RAM zurückgewinnen, zusätzlich zu den 100TB Speicher, die das DNS-Team letzten Monat freisetzen konnte.

Nicht verschwenden Die Aufrechterhaltung einer gerechten Ressourcenteilung zwischen Teams ist nicht einfach, besonders in großen Organisationen. Eine der Möglichkeiten, wie Cloudflare sicherstellt, dass das Gleichgewicht gewahrt bleibt, sind die unermüdlichen Bemühungen des wunderbaren Performance-Teams. Diese Geschichte beginnt mit einem Ticket, das Ivan eingereicht hat und in dem er feststellte: Übermäßige Speichernutzung durch pingora-ketama im Pingora Backend Router. Die Feststellung war, dass unser interner Load-Balancing-Dienst, der Pingora Backend Router (ja, PBR), deutlich mehr Speicher als erwartet verwendete — insbesondere in Strukturen, die mit pingora-ketama verbunden sind, unserer Open-Source-Bibliothek für Consistent Hashing. Um darüber zu sprechen, wie wir diese scheinbare Übernutzung des Speichers angegangen sind, müssen wir darüber sprechen, was Consistent Hashing überhaupt ist, warum wir es in PBR verwenden und wie es so speicherhungrig wurde. Unterwegs lernen wir etwas Rust und sogar ein wenig Mathematik.

Consistent Hashing Consistent Hashing ist eine weit verbreitete Methode zur Verteilung von Aufgaben auf mehrere Server, die keine großen Änderungen erfordert, wenn Server hinzugefügt oder entfernt werden. Intern verwenden wir es, um cachefähige Anfragen per URL an Server weiterzuleiten. Dadurch können wir nur eine Kopie einer Datei pro Rechenzentrum speichern und erhalten eine stabile Möglichkeit, den Speicherort jeder Datei zu finden. Wir haben dieses System bereits erwähnt, aber lassen Sie uns die Zeit nehmen, durchzugehen, wie und warum dieser Algorithmus verwendet wird und wie er funktioniert. Das Schlüsselkonzept des Consistent Hashing ist, dass Hash-Funktionen zwar jede Art von Eingabe akzeptieren können, ihre Ausgabe jedoch auf eine einzelne vorzeichenlose Ganzzahl beschränkt ist (32-, 64- oder 128-Bit-Ganzzahlen, je nach Hash-Funktion). Dadurch können wir Aufgaben und Server auf konsistente Weise zueinander in Beziehung setzen. In den meisten Diskussionen über Consistent Hashing wird man dazu angehalten, sich diesen Ausgaberaum als einen kontinuierlichen, kreisförmigen Ring vorzustellen, der von seinem Maximalwert auf Null umläuft. Diese Darstellung ermöglicht einige schöne Visualisierungen, kann aber auch das einfache Konzept der Ganzzahlbereiche komplizierter erscheinen lassen, als es sein muss. Für unsere Diskussion werden wir die 32-Bit-Ausgabe unserer Hash-Funktion als Zahlenstrahl darstellen. Nehmen wir nun an, wir haben eine Menge von Servern, A, B und C, und eine Menge von Aufgaben t-z. Wir können jede davon basierend auf dem Hash ihrer repräsentativen Werte auf den Zahlenstrahl abbilden, also etwa IP-Adressen für Server und Cache-Schlüssel für Aufgaben. Die Zuweisung von Aufgaben zu Servern ist jetzt nur noch eine Frage des Findens des ersten Servers links von jeder Aufgabe. Wir können dies visuell darstellen, indem wir den Bereich der Hashes einfärben, der jedem Server zugeordnet wird. Beachten Sie, dass der von Server C abgedeckte Bereich zum Anfang umläuft, daher die Idee, dass Hashes in einem Ring existieren. Und das ist alles. Auf einer grundlegenden Ebene ist Consistent Hashing so einfach — aber es dauert nicht lange, um zu erkennen, dass es Raum für Verbesserungen gibt. Beachten Sie, dass der von Server A in unserem Beispiel abgedeckte Bereich deutlich größer ist als der von B oder C. Das ist ein Problem, denn der Anteil der Anfragen, die ein Server bearbeitet, wird proportional zur Größe seines Bereichs auf dem Zahlenstrahl sein. Idealerweise möchten wir garantieren, dass jeder Server die gleiche Größe hat, aber da Hashes im Wesentlichen Zufallszahlen sind, müssen wir...