WIELOWARSTWOWY CACHENa przykładzie serwisu GOG.com

Maciej Włodarkiewicz

O mnie

GG Network S.A.

Web Backend Lead

GOG.com

Head of Web Development

7 lat doświadczenia przy dużych aplikacjach internetowych

5 lat doświadczenia jako kierownik zespołu

Agenda

1. GOG.com - kim jesteśmy?

2. Wyzwania, którym musimy sprostać

3. Walka z odległością

4. Wykorzystanie cache w GOG.com

5. Podsumowanie i wnioski

GOG.com - kim jesteśmy?

Historia Start w 2008 pod skrzydłami CD Projekt - zespół 10 osób

Obecnie zatrudnionych jest 70 osób

Obecna pozycja #1 globalnej dystrybucji klasycznych gier na PC i Mac

#2 globalnej dystrybucji gier indie na PC i Mac

Partnerzy 180+ twórców i wydawców gier

Klienci Ponad 2.7 miliona unikalnych wejść miesięcznie z całego świata

Gry Ponad 700 tytułów w katalogu

Ponad 39 milionów gier na kontach użytkowników

Wyzwania, którym musimy sprostać

Globalny zasięg

Szybkość dostępu

Dynamika odwiedzalności

Globalny zasięg

Regularne wejścia na stronęGOG.com ma odnotowane przynajmniej jedno wejście z każdego kraju na świecie

Szybkość dostępu

1%spadku sprzedaży przy wydłużeniu ładowania Amazon.com o 100 ms

30%użytkowników opuszcza

Amazon.com jeśli czas ładowania przekracza 4 sek

7%spadku konwersji po

każdej sekundzie ładowania Amazon.com

Czas ładowania strony ma wpływ na jej pozycję w wynikach wyszukiwania Google!

http://blog.edgecast.com/post/42404930702/ecommerce-performance-website-speed-impacts-your

Dynamika odwiedzalności

Free Game: Dungeon Keeper

Fall Insomnia Promo

DRM-Free Winter Sale

EA Exclusives Weekend Promo

Walka z odległością - początki GOG.com

2008 DataCenter w Kanadzie (Montreal)

Walka z odległością

Problem:

Prędkość ograniczona do maksymalnej prędkości łącza

Każdy router powoduje opóźnienie

Połączenie narażone jest na zmiany topologii sieci oraz jej awarie

Każdy błąd powoduje retransmisje danych

Rozwiązanie:

Zastosowanie CDN / ADN

content bliżej użytkownika

obliczenia dalej odbywają się w jednym datacenter

Walka z odległością

2011 DataCenter w Polsce (Warszawa);

sieć rozproszona EdgeCast (POP’y)

Content Delivery Network - CDN

Tryby pracy: Tryby dostępu do plików:

Pull ADN (Application Delivery Network); aplikacja pobiera zawartość

Push sami uploadujemy na serwery zewnętrzne

Open niezabezpieczone, dostępne dla wszystkich

Secure chronione poprzez podpisywanie URL z krótkim TTL

Cache pełnych stron

Problem:

Nie można cachować gotowych stron – każda posiada dane spersonalizowane dla użytkownika

Czym różnią się strony dla poszczególnych użytkowników?

Czy są jakieś strony, które są całkowicie różne dla poszczególnych użytkowników?

Rozwiązanie:

Gotowy HTML trzymany w całości w cache

Personalizacja poprzez AJAX

Szybkość działania

HTML generowany jednorazowo dla wszystkich

Oszczędność transferu

Lepsze skalowanie ruchu

Cache pełnych stron globalnie

Browser ADN Backend

CDN

Problemy ADN

Problemy:

Jako zewnętrzna usługa, nie jest w pełni konfigurowalna i dostosowana do naszych potrzeb

Czym więcej punktów dostępowych (POP) tym lepsze user-experience ale też mniejsze hity

Brak dobrej obsługi SSL

Sposoby ich rozwiązania:

Aby zniwelować braki ADN używamy lokalnego reverse-proxy cache

Varnish-Cache

Browser ADN Backend

Varnish-Cache

CDN

Browser ADN Backend

Varnish-Cache

Varnish

CDN

Varnish-Cache

Zalety Łatwy w konfiguracji

Rozszerzalny przy użyciu wstawek C

Nie pozwala na dogpile

Dodatkowe możliwości Expires At

Last-Modified

GZIP

Cache wewnętrzny

Browser ADN BackendVarnish

CDN

Cache wewnętrzny

Browser ADN BackendVarnish Cache wewnętrzny

CDN

Cache wewnętrzny

Memcached

Cache pomiędzy elementami infrastruktury, np cache pokrywający bazę danych

Dane właściwe dla użytkownika takie jak lista posiadanych gier, wishlist etc.

Katalog gier z cenami uwzględniającymi promocje

XCache

Dane niezmienne i niezależne od użytkownika

Cache danych użytkowników daje bardzo mały hit-rate

Tylko na niewielkie dane, ograniczona pojemność poszczególnego obiektu, oraz ilości obiektów

Browser cache

Browser ADN BackendVarnish Cache wewnętrzny

CDN

Browser ADN BackendVarnish Cache wewnętrzny

Browser cache

Browser cache

CDN

Browser cache

HTML5 Local Storage Wspierany przez większość przeglądarek

Key / Value

Limit do 5 MB

Szybsza odpowiedź

Prawie niewidoczne oczekiwanie na personalizację

(Trochę) mniejszy ruch

Strona może działać „offline”

Wiele różnych poziomów cache

Zarządzanie inwalidacją cache Stosowanie długiego cache z wymuszeniem inwalidacji jest trudną i kosztowną operacją, czasem prawie niemożliwą jak np.: cache przeglądarki, CDN

Stosujemy krótki cache ~1 minutowy.

Nawet nałożeniu się warstw zapewnia świeżość w ~2 minuty.

Cache 1minutowy od 1 godzinnego albo 1 dniowego różni się wystarczająco nieznacznie

Wnioski:

HTML jest w cache

Koszyk trzymany jest na szybkim tymczasowym nośniku

Użytkownik jest zalogowany i jego dane są dostępne w cache lub personalizacja jest wyłączona

Efekty i korzyści:

Nie ma ruchu na bazie danych do momentu transakcji

Idealnie skalowalny system

Bardzo szybki dostęp na całym świecie

Podsumowanie

Wyzwania, którym sprostaliśmy

Globalny zasięg

Szybkość dostępu

Dynamika odwiedzalności

Podsumowanie

Wnioski:

Dostosowujmy architekturę do potrzeb

CDN znacznie zwiększa możliwości strony, szczególnie przy globalnym zasięgu

Ale to nie wystarczy, stosujmy dodatkowo cache wewnątrz infrastruktury

Krótki TTL mocno upraszcza logikę

Plany:

Stworzenie od podstaw własnego systemu klasy ADN (już jesteśmy w trakcie pierwszych testów!)

Rozproszenie reszty architektury

Technologie w GOG.com

ADN

CDN

Varnish-Cache

MemCached

PHP-XCache

HTML5 Local Storage

Browser Cache

akamai.com

edgecast.com

varnish-cache.org

memcached.org

xcache.lighttpd.net

developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage

developers.google.com/speed/docs/best-practices/caching

SZUKAMY WEBDEVÓWWięcej informacji u mnie lub na stronie GOG.com/work

DZIĘKUJĘ ZA UWAGĘ…i zapraszam po darmowego Wiedźmina :)

SZUKAMY WEBDEVÓWWięcej informacji u mnie lub na stronie GOG.com/work