architektura serwisow webowych

Architektura serwisów webowych

szybko i boleśnie

Robert Janeczek

G-Forces Web Management Polska

Monetyzacja vs koszty infrastruktury

Monetyzacja vs koszty infrastruktury

Monetyzacja vs koszty infrastruktury

Monetyzacja vs koszty infrastruktury

Monetyzacja vs koszty infrastruktury

Monetyzacja vs koszty infrastruktury

Monetyzacja vs koszty infrastruktury

Monetyzacja vs koszty infrastruktury

Monetyzacja vs koszty infrastruktury

Monetyzacja vs koszty infrastruktury

Monetyzacja vs koszty infrastruktury

Monetyzacja vs koszty infrastruktury

Monetyzacja vs koszty infrastruktury

Monetyzacja vs koszty infrastruktury

Architektura – o co chodzi?

Jak maksymalizować wykorzystanie istniejącej infrastruktury?Jak zwiększać wydajność infrastruktury?Jak minimalizować wydatki na nową infrastrukturę?

Statyczna strona WWW

Statyczna strona WWW

1200 odwiedzających/sekundę1 plik1200 wyświetleń/sekundę

Statyczna strona WWW

1200 odwiedzających/sekundę1 plik1200 wyświetleń/sekundę

3mld odsłon miesięcznie!

• łatwo serwować

• szybkość

• skalowalność

• tanio (tylko transfer)

• pierwsza piątka Megapanelu ;)

Statyczna strona + pliki dodatkowe

1200 żądań/sekundę80 plików15 wyświetleń/sekundę

Statyczna strona + pliki dodatkowe

1200 żądań/sekundę80 plików15 wyświetleń/sekundę

Bądź cache-friendly!

• oszczędzaj żądania

• plik niewysłany jest lepszy od wysłanego

• wciąż ładnie się skaluje

• wypadliśmy z Megapanelu :(

Dynamiczna strona

750 żądań/sekundę80 plików9 wyświetleń/sekundę

Dynamiczna strona

750 żądań/sekundę80 plików9 wyświetleń/sekundę

Dynamika szkodzi!

• unikaj żądań dynamicznych

• przechowuj wyniki zamiast obliczać

• cache kodu (APC)

Połączenie z bazą danych

500 żądań/sekundę80 plików6 wyświetleń/sekundę

Połączenie z bazą danych

500 żądań/sekundę80 plików6 wyświetleń/sekundę

Podziel przez liczbę zapytań…

• nie łącz się z bazą jeśli nie musisz

• przechowuj wyniki zamiast o nie pytać bazę

• nie zakładaj, że indeksy „są”

Wymiękamy: WWW nie wyrabia

Zanim zaczniesz kombinować

Szybsza maszyna?Przekaż serwowanie statycznych plików na zewnątrzKolejkowanie zadańWielopoziomowy cache (zapytania, fragmenty, strony)ProfilerSpójrz na dane z innej perspektywy, a może się okazać, że wszystko jest cache’owalne

Load balancer/reverse proxy• konfigurujemy reverse-proxy

• dodajemy kilka serwerów WWW

• ruch płynie przez reverse-proxy

Load balancer/reverse proxy• konfigurujemy reverse-proxy

• dodajemy kilka serwerów WWW

• ruch płynie przez reverse-proxy

• dociera do jednego z serwerów WWW

• wraca przez reverse-proxy

• szybkie zamknięcie połączenia

• wynik przechowany jeśli nagłówki pozwalają

Load balancer/reverse proxy• konfigurujemy reverse-proxy

• dodajemy kilka serwerów WWW

• ruch płynie przez reverse-proxy

• dociera do jednego z serwerów WWW

• wraca przez reverse-proxy

• szybkie zamknięcie połączenia

• wynik przechowany jeśli nagłówki pozwalają

• część (większość!) ruchu nie dojdzie nawet do serwerów WWW

• zmniejszone obciążenie

• dodaj maszyny – więcej mocy

Load balancer/reverse proxy - uwagi• jak load balancer kieruje ruch?

• sesje w plikach

• konieczność synchronizacji zawartości serwerów WWW

• HA przy okazji (tylko dla WWW!)

• nie skaluje się w nieskończoność

Wymiękamy: baza nie wyrabia

Zanim zaczniesz kombinować

Szybsza maszyna?Zmniejsz liczbę zapytań – cache wynikówZmniejsz liczbę zapytań – nie pytaj o niepotrzebne daneZmniejsz liczbę zapytań – nie pytaj kilka razy o to samoDenormalizacja struktury bazyTuning (bufory bazy, filesystem)

Master-slave• wszystkie zapisy wędrują do bazy Master

Master-slave• wszystkie zapisy wędrują do bazy Master

• baza Master umieszcza kilka kopii danych w bazach Slave

Master-slave• wszystkie zapisy wędrują do bazy Master

• baza Master umieszcza kilka kopii danych w bazach Slave

• odczyty wykonywane z baz Slave, czyli teoretycznie liniowa skalowalność odczytów

Master-slave - uwagi• synchronizacja może stać się wąskim gardłem

• Master i wszystkie Slave muszą być w stanie udźwignąć samodzielnie wszystkie zapisy

• czy Twitter/Blip może tak się skalować?

• sprawdza się przy znacznej przewadze odczytów

Jesteśmy Twitterem i wciąż mamy problem

ShardingRezygnacja z relacyjnych baz (MemcacheDB, SimpleDB, Google AppEngine Data Store…)Ogranicz sztucznie dostępność danychKolejkuj zapisy (np. importy, powiadomienia znajomych)Bądź otwarty na alternatywy dla SQL(np. Sphinx do przeszukiwania MySQL)

Porównanie obciążenia

LB (~75% ruchu)

WWW (~25% ruchu)

DB (<25% ruchu)

Na co zwrócić szczególną uwagę

Elastyczny monitoringWydajna strategia backupowania i zapisywania logówHASynchronizacja maszyn, czyszczenie cacheZłożoność obliczeniowa zadańOdczyt z dysku vs odczyt z RAM po sieci

Dziękuję za uwagę

robert.janeczek@gforces.pl