Wewnętrzne rozwiązanie Pingora Backend Router odpowiada w infrastrukturze Cloudflare za rozdzielanie żądań kwalifikujących się do pamięci podręcznej pomiędzy serwerami zaplecza. Ze względu na konieczność obsługi serwerów o różnych wagach oraz zróżnicowanych kombinacji funkcji, system tworzył wiele pierścieni haszujących. Wygenerowało to ogromny narzut pamięciowy, za który odpowiadały struktury danych w bibliotece pingora-ketama.
Matematyczna analiza pozwoliła usunąć 90 procent haszy
Inżynierowie Cloudflare zastosowali rachunek prawdopodobieństwa, aby obliczyć minimalną liczbę punktów haszujących niezbędną do utrzymania wymaganego rozkładu obciążenia. Z dotychczasowych analiz wynikało, że każdy kolejny krok w dół marginesu błędu wymagał niemal dziesięciokrotnego zwiększenia liczby haszy przypadających na pojedynczy serwer, przez co kolejne zagęszczanie pierścienia przynosiło coraz mniejsze korzyści.
Przykładowo, dodanie ostatnich 90 000 haszy poprawiało precyzję rozkładu ruchu o zaledwie 0,7%. Co więcej, zgodnie z paradoksem dnia urodzin, wraz ze wzrostem liczby 32-bitowych punktów gwałtownie rosło prawdopodobieństwo kolizji, co wprowadzało dodatkowy błąd w równoważeniu obciążenia. Wnioski te pozwoliły zespołowi zredukować liczbę haszy na każdy serwer o około 90% bez zauważalnego pogorszenia precyzji działania systemu.
Zmniejszenie struktur w Rust i ochrona pamięci podręcznej
Drugim etapem prac była optymalizacja samych struktur danych w języku Rust. Dotychczasowa reprezentacja pojedynczego punktu w pierścieniu, zdefiniowana jako Point, zajmowała 8 bajtów. Inżynierowie przeprojektowali tę strukturę, mieszcząc sam hasz oraz indeks serwera w 6 bajtach, co przyniosło dalsze oszczędności pamięci operacyjnej.
Istotnym wyzwaniem okazał się sam proces publikacji zmian. Modyfikacja pierścienia haszującego zmienia lokalizację, do której trafiają poszczególne zapytania. Natychmiastowe przełączenie całej sieci unieważniłoby niemal całą zawartość pamięci podręcznej, co doprowadziłoby do gwałtownego skoku ruchu kierowanego bezpośrednio do serwerów źródłowych. Aby temu zapobiec, Cloudflare uruchomiło nową implementację równolegle ze starą, przenosząc ruch stopniowo.
Nie była to jedyna operacja tego typu w firmie: w sierpniu zespół Cloudflare odpowiedzialny za DNS opisał analogiczną redukcję zużycia pamięci podręcznej poprzez uproszczenie i optymalizację wewnętrznych struktur danych.
