Architektura serwisow webowych

Architektura serwisów webowych

szybko i boleśnie

Robert Janeczek

G-Forces Web Management Polska

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


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


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


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


Dynamiczna strona


Dynamika szkodzi!

• unikaj żądań dynamicznych

• przechowuj wyniki zamiast obliczać

• cache kodu (APC)

Połączenie z bazą danych


Połączenie z bazą danych


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




• dociera do jednego z serwerów WWW

• wraca przez reverse-proxy

• szybkie zamknięcie połączenia

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




• 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


• baza Master umieszcza kilka kopii danych w bazach Slave


• 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ę

[email protected]

Architektura serwisow webowych

Technology

Transcript of Architektura serwisow webowych