WIELOWARSTWOWY CACHE Na przykładzie serwisu GOG.com Maciej Włodarkiewicz
O mnie GOG.com Head of Web Development GG Network S.A. Web Backend Lead 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% 7% 30% spadku sprzedaży przy wydłużeniu ładowania Amazon.com o 100 ms spadku konwersji po każdej sekundzie ładowania Amazon.com użytkowników opuszcza Amazon.com jeśli czas ładowania przekracza 4 sek 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 EA Exclusives Weekend Promo Fall Insomnia Promo DRM-Free Winter Sale Free Game: Dungeon Keeper
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 Rozwiązanie: Zastosowanie CDN / ADN content bliżej użytkownika obliczenia dalej odbywają się w jednym datacenter Każdy błąd powoduje retransmisje danych
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: Push sami uploadujemy na serwery zewnętrzne Open niezabezpieczone, dostępne dla wszystkich Pull ADN (Application Delivery Network); aplikacja pobiera zawartość 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 CDN Browser ADN Backend
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 Sposoby ich rozwiązania: Aby zniwelować braki ADN używamy lokalnego reverse-proxy cache Varnish-Cache Brak dobrej obsługi SSL
Varnish-Cache CDN Browser ADN Backend
Varnish-Cache CDN Browser ADN Varnish Backend
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 CDN Browser ADN Varnish Backend
Cache wewnętrzny CDN Browser ADN Varnish Backend Cache wewnętrzny
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 CDN Browser ADN Varnish Backend Cache wewnętrzny
Browser cache CDN Browser Browser ADN Varnish Backend cache Cache wewnętrzny
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
Podsumowanie 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
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 Plany: Stworzenie od podstaw własnego systemu klasy ADN (już jesteśmy w trakcie pierwszych testów!) Rozproszenie reszty architektury Krótki TTL mocno upraszcza logikę
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ÓW Więcej informacji u mnie lub na stronie GOG.com/work
SZUKAMY WEBDEVÓW Więcej informacji u mnie lub na stronie GOG.com/work DZIĘKUJĘ ZA UWAGĘ i zapraszam po darmowego Wiedźmina :)