Z

ałóżmy, że chcemy na naszą aplikację webową nałożyć warstwę cache w celu przyśpieszenia jej działania, zredukowania serwerów front-endowych i odciążenia back-endu. W zależności od skali ruchu sieciowego i wielkości naszej aplikacji – jeden serwer typu proxy cache czasami nie wystarczy. Przyjmijmy, że skala wymaga pięciu serwerów typu cache (wykorzystajmy Varnish’a). Bez sensu jest postawienie przed tymi serwerami urządzenia lub aplikacji do wykonywania load balancingu w trybie round robin, ponieważ spowoduje to powielanie obiektów w pamięci cache serwerów i nieoptymalne ich wykorzystanie.

Jednym z rozwiązań jest uri hashing, który pozwala na inteligentne zrównoważenie żądań – nie w oparciu o charakterystykę klienta, ale w oparciu o żądane zasoby. Na przykład wszystkie żądania HTTP o www.strona.pl/artykuly zostaną wysłane przez load balancer do serwera cache1, a www.strona.pl/kontakt do serwera cache2. Ponieważ każdy serwer cache dostaje do obsługi swoją część aplikacji – zawsze będzie miał unikalną i najnowszą wersję w swojej pamięci podręcznej. Metoda ta pozwala na skuteczne wykorzystanie pamięci cache wszystkich serwerów, które nie muszą przechowywać zduplikowanych obiektów. W dodatku dodanie większej ilości serwerów cache pozwala na skalowanie poziome, gdyż zmniejsza się ilość zasobów URI przypadających na jeden serwer cache – słuszność tego stwierdzenia zależy oczywiście od rodzaju algorytmu, jaki został zastosowany do generowania uri hashy.

Znany problem z algorytmem uri hash jest taki, że gdy liczba serwerów cache ulegnie zmianie – zostanie obliczony nowy hash dla polityki ruchu i reszta serwerów zacznie otrzymywać żądania o nowe zasoby, które wcześniej nie były przez nie obsługiwane, czyli o te, których nie posiadają jeszcze w pamięci cache. W szczycie ruchu może doprowadzić to przeciążenia reszty serwerów – ponieważ warstwa cache nie będzie “wygrzana” i serwery zaczną przekazywać przez jakiś czas większość ruchu bezpośrednio do serwerów aplikacji.

Drugim problemem jest charakterystyka ruchu do samej aplikacji. Przy polityce rozkładania ruchu typu round robin nie jesteśmy w stanie stwierdzić od strony ilości połączeń z load balancera do serwerów, które adresy uri cieszą się większą lub mniejszą popularnością, ponieważ są one rozrzucane na wszystkie serwery. Dane te możemy i powinniśmy wyciągnąć z statystyk zanim wdrożymy uri hashing w warstwie cache. Dlaczego? Ponieważ nagle po wdrożeniu może okazać się, że 4 z 5 serwerów cache otrzymują od load balancera po średnio 100 połączeń, a 5’ty serwer musi obsłużyć ich 1000 bo akurat jemu przypadła obsługa najbardziej popularnego adresu w całej aplikacji (varnishtop -i RxURL). Wówczas w zależności od tego, czy adres ten polega umieszczaniu w pamięci cache lub nie – możemy zdecydować się z wykluczenia go z algorytmu uri hash i zastosowaniu tylko dla niego polityki round robin, aby ilość żądań i obciążenie dla wszystkich serwerów cache było w miarę równe.

Więcej informacji: Overview of the CARP hash algorithm, URL Hashing Description