Cloudflare maakt ruim 100 TB RAM vrij met kleinere verdeeltabellen

Cloudflare heeft wereldwijd meer dan 100 TB werkgeheugen vrijgemaakt in zijn Pingora Backend Router, meldt het bedrijf op 18 september. Die dienst stuurt webverzoeken naar achterliggende servers. Opslaggewichten en verschillende combinaties van serverfuncties hadden het aantal punten en aparte verdeelringen opgedreven. De ingreep combineert compacter opgeslagen verdeelpunten met 90 procent minder van zulke punten. Cloudflare voerde de omschakeling stapsgewijs per datacentergroep en verkeersdeel uit. Het gerapporteerde resultaat betreft geheugen in zijn infrastructuur; er staat geen gemeten snelheidswinst voor Nederlandse of Belgische bezoekers tegenover.

Waarom moeten webverzoeken worden verdeeld?

Veel websites gebruiken een cache: een tijdelijke voorraad eerder verstuurde antwoorden. Denk aan een afbeelding die verschillende bezoekers opvragen. Als het opgeslagen antwoord opnieuw gebruikt mag worden, hoeft het niet telkens opnieuw bij de oorspronkelijke webserver te worden opgehaald. De internetstandaard voor caching, RFC 9111, beschrijft hoe dat wachttijd en netwerkverkeer kan verminderen. Een gedeelde cache kan meerdere gebruikers bedienen; de privévoorraad in je browser is voor één gebruiker bestemd.

Hergebruik kent voorwaarden. Een antwoord kan bijvoorbeeld nog vers zijn, of eerst opnieuw worden gecontroleerd bij de oorspronkelijke server. Ook de inhoud van het verzoek telt mee: dezelfde URL hoeft niet voor iedere bezoeker hetzelfde antwoord op te leveren. De routeringspuzzel draait dus om het efficiënt terugvinden van bruikbare antwoorden, binnen die bestaande regels. Alleen meer opslagruimte beschikbaar hebben vervangt die controles niet.

Hoe vindt een verzoek de juiste server?

Een hashfunctie zet een sleutel, bijvoorbeeld een bestandsadres, om in een getal. De oorspronkelijke Ketama-bibliotheek legt een verdeelmethode uit waarbij servers meerdere posities op een denkbeeldige cirkel krijgen. Ook de sleutel krijgt een positie. Vanaf daar zoek je het eerstvolgende serverpunt; voorbij het einde begin je weer vooraan. Zo kan dezelfde sleutel steeds bij dezelfde server uitkomen zonder een aparte adreslijst voor ieder bestand bij te houden.

Dat heeft vooral waarde wanneer een server erbij komt of verdwijnt. Bij een eenvoudige verdeling via de rest van een deling door het serveraantal kunnen veel sleutels ineens ergens anders terechtkomen. Ketama beperkt die verhuizing tot een deel van de sleutels. Een server met meer beschikbare opslag kan bovendien een groter gewicht krijgen: hij krijgt dan meer posities op de cirkel. De aantallen punten vormen zo samen de verdeeltabel.

Waarom leveren twee bytes minder niet vanzelf ruimte op?

In Rust beslaat een getal van het type u32 vier bytes; een u16 gebruikt er twee. Toch is een gegevensblok met beide velden niet noodzakelijk zes bytes groot. De officiële taalreferentie beschrijft uitlijning: velden moeten op passende geheugenadressen beginnen en de totale blokgrootte houdt daar rekening mee. Bij een uitlijning van vier bytes moet een volgend blok weer op een veelvoud van vier kunnen beginnen. Daardoor kunnen twee opvulbytes nodig blijven.

Die lege ruimte is geen bestand dat je kunt verwijderen. Ze hoort bij de manier waarop gegevens in het geheugen liggen. Een aaneengesloten array van zes losse bytes heeft wél precies zes bytes aan elementen. De software kan daaruit afzonderlijk de getallen reconstrueren. Voor programmeurs is dat het praktische verschil tussen een kleiner getal kiezen en daadwerkelijk een kleinere geheugenindeling gebruiken.

Wat verandert er in de openbare code?

De vastgelegde Pingora-broncode laat beide varianten zien. PointV1 bevat twee getallen van vier bytes. PointV2 bewaart zijn gegevens in een array van zes bytes: vier voor de hash en twee voor het servernummer. Het verschil tussen acht en zes is 25 procent per opgeslagen punt. Bij een miljoen punten betekent dat, zelf nagerekend, acht tegenover zes miljoen bytes. Die vergelijking betreft uitsluitend de punten; andere onderdelen van een programma gebruiken ook geheugen.

Verder bevat de nieuwe variant een instelbare vermenigvuldigingsfactor voor het aantal punten. De oorspronkelijke versie gebruikt 160 per gewichtseenheid: gewicht twee levert dus 320 punten op. De standaardversie in deze code blijft V1; V2 staat achter een afzonderlijke softwareoptie. Wie de bibliotheek gebruikt, krijgt daarmee geen bewijs dat zijn eigen toepassing automatisch evenveel geheugen zal besparen.

Hoeveel nauwkeurigheid koop je met extra punten?

Meer punten maken de verdeling doorgaans gelijkmatiger, maar de opbrengst neemt af. De aparte wiskundige afleiding van Cloudflare-auteur Kevin Guthrie maakt dat berekenbaar. Ons voorbeeld met honderd gelijk gewogen servers geeft bij 160 punten per server circa 7,87 procent relatieve spreiding; bij 640 circa 3,93 procent. Viermaal zoveel punten halveert hier ongeveer de spreiding. Dat is een statistische standaardafwijking ten opzichte van het verwachte aandeel, geen maximale fout of percentage mislukte verzoeken. Het model gebruikt een doorlopende getallenlijn; botsende echte hashes zijn daarin niet meegenomen.

Is een gelijkmatige tabel ook een snelle website?

Dat volgt er niet automatisch uit. Googles bestaande SRE-handboek over betrouwbare systemen legt uit waarom aantallen verzoeken een onvolledige maat voor belasting zijn. Sommige verzoeken kosten veel meer rekenwerk dan andere. Machines kunnen verschillen en concurrerende processen kunnen dezelfde middelen opeisen. Een keurige verdeling op papier vertelt daarom nog niet hoeveel werk iedere server werkelijk moet doen. Daarvoor zijn metingen aan het draaiende systeem nodig.

Dat onderscheid maakt de optimalisatie interessant voor wie zelf websites of apps bouwt. Een drukste server kan de bruikbare capaciteit van een hele groep beperken terwijl elders capaciteit overblijft, beschrijft Google. Minder geheugen voor de verdeeltabel en een evenwichtige werkverdeling zijn dus twee afzonderlijke doelen. Bij het beoordelen van zo’n wijziging tellen naast geheugengebruik ook wachttijden, fouten en beschikbare rekenruimte. De cijfers in de rekengrafiek mogen die praktijkmetingen niet vervangen.