Embed Size (px)
Citation preview
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ą
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 zkrótkim TTL
Content Delivery Network - CDN
static assets games files
gog.com pages secure.gog.com
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ą,
Inwalidacja plików na CDN przez zmianę nazwy
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
ADN/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
