Varnish Cache – czym jest, jak działa i jakie ma zalety?

Zanim przejdziemy do omówienia samego Varnisha, wytłumaczmy sobie, czym jest cache’owanie, czyli powiązany proces. Caching jest jednym z filarów optymalizacji wydajności stron internetowych. Określa zestaw technik, które sprawiają, że witryna ładuje się szybciej.

Samo cache’owanie jest procesem, który polega na przechowywaniu danych w tymczasowej jednostce pamięci masowej. Jest kilka form stosowania tej techniki:

• page cache – odbywa się na serwerze i przechowuje cały HTML strony;
• browser cache – przechowuje zasoby strony (pliki HTML, CSS i JS, fonty oraz grafiki) w przeglądarce użytkownika, dzięki czemu przy ponownej wizycie nie musi pobierać ich na nowo z serwera;
• object cache – przechowuje zapytania do bazy danych.

Istnieje także inny rozbudowany typ cache’owania, czyli reverse proxy cache. Proxy to inaczej serwer znajdujący się między internetem a użytkownikiem. Jego celem jest filtrowanie zapytań skierowanych przez usera do konkretnej strony. W standardowej wersji (czyli forward proxy) struktura wygląda następująco:

W ten sposób przedsiębiorstwo może np. blokować dostęp pracowników z komputerów firmowych do wybranych stron. W przypadku reverse proxy struktura prezentuje się tak:

Reverse proxy jest punktem wejścia wszystkich zapytań kierowanych na stronę internetową firmy, a jego zadanie polega na filtrowaniu ich, zanim dotrą na stronę.

Większość dobrze zoptymalizowanych witryn wykorzystuje, oczywiście, kilka typów cache na raz. Gdy na przykład browser cache pozwala skrócić czas ładowania na urządzeniu konkretnego użytkownika, reverse proxy ogranicza liczbę zapytań, które serwer strony musi przetworzyć na nowo przy każdej sesji. Przy prawidłowej konfiguracji nie ma tu żadnego konfliktu – oba mechanizmy mogą działać równolegle.

Varnish to narzędzie, które wykorzystuje mechanizm reverse proxy do filtrowania zapytań i cache’owania odpowiedzi z serwera. Nie jest to, oczywiście, fizyczny serwer, a program (akcelerator) instalowany na serwerze.

Działa on jako nakładka – lub filtr, aby łatwiej było to sobie wyobrazić – przez którą przechodzą wszystkie zapytania ze strony klienta. Jeśli serwer nigdy wcześniej nie przetwarzał danego żądania, Varnish przekierowuje je w celu uzyskania odpowiedzi i zapisuje ją w swojej pamięci podręcznej. Gdy klient wyśle kiedyś identyczne żądanie, Varnish prześle kopię odpowiedzi bezpośrednio z pamięci podręcznej, przyspieszając całą wymianę danych.

Efekty najlepiej widać przy wzmożonym ruchu – wyobraź sobie duży e-commerce podczas Black Friday albo dowolny portal newsowy w trakcie wyborów. Gdyby setki, a nawet tysiące osób chciały wejść na tę samą stronę, a brakowałoby reverse proxy, backend musiałby wygenerować od zera dokładnie tę samą odpowiedź dla każdego żądania (czyli dla każdego użytkownika). Z Varnishem dużą część tego ruchu da się obsłużyć z pamięci podręcznej – serwer w tym czasie może zająć się obsługą innych żądań.

Z tym jednym zadaniem radzi sobie doskonale, dlatego jest tak chętnie wykorzystywany przez serwisy wysyłające każdego dnia ogromne ilości danych. I tu ciekawostka: twórcami projektu byli informatycy pracujący dla największego norweskiego tabloidu, VG. Ma to sens – portale informacyjne są świetnym przykładem witryn content-heavy, które na akceleratorach reverse proxy mogą zyskać najwięcej.

Co ważne, Varnish jest programem open-source’owym, chociaż ma też swoją wersję komercyjną, wspieraną przez Varnish Software.

Zanim przejdziemy dalej, warto jeszcze wyjaśnić kilka pojęć.

• Cache hit – sytuacja, w której żądana odpowiedź znajduje się już w pamięci podręcznej Varnisha i może zostać zwrócona użytkownikowi bez angażowania w to całego serwera.
• Cache miss – sytuacja odwrotna: danej odpowiedzi nie ma jeszcze w cache, więc Varnish musi pobrać ją z serwera głównego, a przy okazji zapisać na przyszłość. Pierwsze wejście na daną podstronę niemal zawsze kończy się cache missem.
• TTL (Time To Live) – czas, przez jaki dany element pozostaje w pamięci podręcznej, zanim zostanie uznany za nieaktualny i będzie trzeba go odświeżyć (zapisać ponownie). O jego konfiguracji powiemy na końcu artykułu.

Wdrożenie reverse proxy jest dobrym pomysłem, jeśli:

• znaczną część treści na stronie stanowią pliki multimedialne – np. grafiki, zdjęcia, filmy czy animacje. To one są największym obciążeniem dla serwera i potrafią znacznie wydłużyć czas ładowania nawet przy umiarkowanym natężeniu ruchu na stronie;
• witryna często mierzy się ze skokowymi wzrostami natężenia ruchu – jeśli prowadzisz e-commerce, to może być spory problem przy okazji większych promocji.

Oto inne korzyści z zastosowania Varnish Cache:

Jeśli chodzi o wady, Varnish nie ma ich wiele, ale dobrze je mieć na uwadze:

1. Narzędzie działa jedynie na serwerach z Unixem lub systemami opartymi na nim – odpada więc np. Windows Server.
2. W wersji open-source’owej Varnish nie obsługuje biblioteki SSL, więc nie jest w stanie samodzielnie przetwarzać zapytań HTTPS – dlatego też w praktyce, w większości wdrożeń ustawia się przed Varnishem dodatkową warstwę odpowiedzialną za terminację (czyli rozszyfrowywanie) SSL/TLS. Najczęściej rolę tę pełni lekki proxy TLS, taki jak Hitch – rozwijany zresztą przez Varnish Software – albo serwer Nginx skonfigurowany specjalnie pod to zadanie.
3. Przy nieprawidłowej konfiguracji istnieje ryzyko, że Varnish zapisze w swojej pamięci dane, które nie powinny być publiczne – np. zawartość czyjegoś koszyka lub dane z panelu klienta – i będzie je wysyłać przeglądarkom innych użytkowników. To jednak kwestia wyłączenia części zapytań z cache’owania.
4. Mogą pojawić się problemy z aktualnością treści – pamięć podręczna nie zawsze odzwierciedla bieżący stan witryny. Dopóki nie wygaśnie TTL danego elementu albo nie zostanie on celowo usunięty z cache, użytkownik może zobaczyć w swojej przeglądarce starszą wersję danej podstrony.
5. Po wdrożeniu Varnisha trzeba poświęcić trochę czasu na jego monitoring – należy sprawdzać, jaki jest stosunek cache hitów do cache missów, czy buforowane są właściwe zasoby, a także czy pliki w pamięci podręcznej faktycznie są odświeżane zgodnie z określonym TTL. Inaczej łatwo o sytuację, w której Varnish będzie cache’ował albo za dużo, albo za mało.

Wersja komercyjna Varnisha jest o wiele bogatsza w funkcje od tej darmowej, otwartej. Wszystkie podstawowe narzędzia znajdziesz oczywiście w obu, ale Varnish Enterprise dodaje do nich między innymi:

• Massive Storage Engine, który jest silnikiem optymalizującym cache’owanie danych na dysku i zwiększającym jego pojemność;
• Varnish Custom Statistics, czyli wbudowany silnik, który w czasie rzeczywistym zbiera dane o ruchu na stronie, zapytaniach do serwera oraz buforowanych plikach;
• możliwość deszyfrowania komunikatów SSL/TLS, co otwiera drogę do obsługi żądań HTTPS;
• opcję łączenia się z backendem za pośrednictwem szyfrowanego protokołu TLS/SSL;
• obsługę Edge Side Includes w trybie równoległym, dzięki czemu Enterprise wywołuje potrzebne treści dynamiczne „na raz”, a nie jeden po drugim, jak to jest w przypadku darmowej wersji.

Przy okazji omawiania zalet Varnisha wspomnieliśmy o tym, jak elastyczne jest to narzędzie. To jednak sprawia, że zanim pozwolisz swojemu reverse proxy działać na pełnych obrotach, trzeba ręcznie skonfigurować kilka rzeczy. Poniżej znajdziesz listę najważniejszych kwestii, którymi należy się zająć.

1. Zdefiniowanie dostępnej pamięci podręcznej (cache size) – czyli ile pamięci Varnish może przeznaczyć na przechowywanie odpowiedzi.
2. Określenie czasu, przez jaki Varnish będzie przechowywał każdy element w pamięci (Time to Live – TTL) – domyślnie są to dwie minuty, ale warto dostosować tę wartość do częstotliwości zmieniania się contentu na stronie i do tego, jaki ruch obsługuje serwer. TTL nie musi (i zwykle nie powinien) też być taki sam dla wszystkich zasobów – warto różnicować go w zależności od typu treści. Inny trzeba będzie ustawić dla evergreenowych tekstów na blogu, a inny dla kart produktów, na których np. w każdej chwili może się zmienić status dostępności.
3. Wskazanie podstron, które nie będą podlegać buforowaniu – zwykle z cache wyklucza się strony koszyka i checkoutu, panel klienta, formularze, panel administracyjny, w skrócie: wszystkie podstrony, które mogą zawierać czyjeś dane lub wymagają logowania. Najwięcej będzie ich, co jasne, na stronach e-sklepów.
4. Ustalenie zasad obsługi cookies – domyślnie Varnish nie buforuje stron z „ciasteczkami” zakładając, że skoro strona je zapisuje, musi być dynamiczna, więc jej cache’owanie nie ma sensu. Tyle że cookies zbierają też strony w pełni statyczne – bo generuje je choćby Google Analytics – więc w ich przypadku zdecydowanie warto zmienić to ustawienie.
5. Zaplanowanie regularnego „czyszczenia” cache – treści w pamięci podręcznej czasem trzeba będzie usunąć jeszcze przed upływem TTL, np. po aktualizacji artykułu czy zmianie ceny. Służą do tego mechanizmy purge (usuwa jeden konkretny element) oraz ban (usuwa całą grupę zasobów pasujących do zadanej reguły).
6. Testy przed uruchomieniem proxy na produkcji – tak jak zawsze, zanim Varnish trafi na właściwą stronę, warto przetestować jego działanie na stagingu. Radzimy tu przejść przez wszystkie główne ścieżki użytkownika, aby upewnić się, że nic, co powinno być dostępne tylko na urządzeniu jednego, konkretnego użytkownika (np. jego panel klienta albo dane wpisane w formularzu), nie zostało przypadkiem zbuforowane, a zasoby statyczne rzeczywiście serwowane są z pamięci podręcznej.

Sporo wskazówek co do konfiguracji Varnisha znajdziesz też na oficjalnym portalu Varnish Software dla developerów – warto tam zajrzeć.