Post on 13-Aug-2015
Kiedy popularność jest pocałunkiem śmierci...
Skalowalność serwisów internetowychw dobie Web 2.0
Piotr Karwatka - Biznes20.pl
Kiedy oglądalność jest pocałunkiem śmierci
Web 1.0 – read, Web 2.0 – read & write- serwisy web 2.0 nie wiedzą kiedy i z jakim impetem ich treści zostaną rozbudowane,- serwisy muszą być przygotowane na nagły wzrost liczby użytkowników ...
... ale nie wszystkie są przygotowane .... :-)
- co odróżnia jedne serwisy od drugich?
nasza-klasa.pl youtube.com
Piotr Karwatka - Biznes20.pl
Dlaczego istnieje problem?
Przyczyny:- dobra architektura jest droga? (niekoniecznie), - „pomyślimy o tym, gdy stanie się problemem” (za późno!),- programowanie w ruby/php/python/asp.net jest proste! :-),- korzystamy z gotowych, „profesjonalnych” rozwiązań!
większość oprogramowania jest źle zaprojektowana
gro popularnego oprogramowania jest źle zaprojektowane
i bardzo trudne w skalowaniu!
Jeśli używasz osCommerce, Drupala lub Joomli
przyhamuj swoich marketingowców!( )
... i co my teraz zrobimy?
Piotr Karwatka - Biznes20.pl
Skalowanie aplikacji jest proste...
1. Technologie
- większość największych serwisów korzysta z PHP i MySQL,
- cudeńka jak RoR mogą być pułapką ...,
- ... ale to nie prawda że języki/technologie są mniej lub bardziej skalowalne....
- ceny rozwiązań komercyjnych rosną wykładniczo wraz ze skalą!
„Każdy nowy język programowania jest jak nowa dziewczyna – nasz związek jest lepszy, bo JA jestem lepszym programistą!”
pingdom.com
Piotr Karwatka - Biznes20.pl
Skalowanie aplikacji jest proste...
2. Architektura aplikacji
- podziel aplikację na warstwy (chociażby MVC!) - inaczej nie poskalujesz!,
- podziel środowisko w którym ona pracuje na warstwy (nawet wirtualnie) –
1. serwery bazy danych, 2. serwery aplikacji, 3. storage, 4. cache
– skaluj je osobno
-stań na ramionach gigantów... - wzorce projektowe, frameworki są Twoimi
przyjaciółmi
- ... ale zachowaj zdrowy rozsądek - barokowa obiektowość nie jest szybka
(PHP i Zend Framework? ;))
- Frameworki do wszystkiego,
bywają do niczego...
Piotr Karwatka - Biznes20.pl
- używaj bytecodu (w PHP -> APC, Xcache),
- optymalizuj/profiluj, optymalizuj/profiluj, optymalizuj/profiluj
- ale nie za wcześnie!,
- wykrywaj wcześnie wąskie gardła - najczęściej dostęp do
danych i I/O,
- używaj cache'u aby je zlikwidować (memcached!)
- to jest pierwszy krok.
Skalowanie aplikacji jest proste...
Zrobiłem to wszystko. Co dalej?
Piotr Karwatka - Biznes20.pl
Skalowanie aplikacji jest proste...3. Skalowanie aplikacji na poziomie sprzętu
- pionowe - więcej ramu, lepsze CPU -> szybko docieramy do granic, drogie!
- ale pomoże bez żadnych zmian w aplikacji
- poziome – więcej tanich serwerów -> nie ma granic (w teorii!)
- ale też ew. problemy ze stanem sesji,
trudniejsza konfiguracja, trudniejsze zarządzanie (capistrano?)
- większa dostępność aplikacji (n+1, 2n ...)
- darmowe loadbalancery na poziomie aplikacji (perlball, nginx jako proxy, odchudzony apache jako proxy, .. serwer DNS?), - sprzętowe (cisco!) lepsze ale droższe, sporo droższe.
Piotr Karwatka - Biznes20.pl
koszt
ilość cpu
skalowanie pionowe
skalowanie poziome
Skalowanie aplikacji jest proste...
...
+ =
Piotr Karwatka - Biznes20.pl
Skalowanie aplikacji jest proste...4. Gotowe rozwiązania – EC2 (+enomalism.com), 3tera, rightscale.com ...
+ nie wymagają opieki nad własnym środowiskiem sprzętowym,
+ łatwe w konfiguracji i zarządzaniu (zarządzanie obrazami systemów),
+ przezroczysta obsługa wielu centrów danych – maksymalna odporność na awarie,
+ tanie przy małych i średnich projektach (kilka centów za godzinę pracy),
+ odporność na skoki!
- ale drooogie przy dużych rozwiązaniach,
- skalowanie tylko aplikacji oraz storage
wirtualizacja środowiska, elastyczne chmury obliczeniowe
Piotr Karwatka - Biznes20.pl
Skalowanie aplikacji jest proste...
... ale bazy danych nie!- rdbms to najczęstsze wąskie gardło – połączenia, req/s,
- nie ma jednego – właściwego rozwiązania a naprawdę skalowalne
rozwiązania są trudne!
Unikaj skomplikowanych rozwiązań póki to możliwe:
1) Przechwytuj wolne kwerendy i je optymalizuj
- używaj profilowania i EXPLAIN (mysql)
- optymalizuj strukturę (indeksy, denomralizacja jeśli potrzebna),
2) Używaj cache na poziomie dostępu do danych
(nie cache.. tylko memcached!)
cache
db
SELECT ..... FROM ...Hit - 90%
Miss - 10%
Nie żartuj... to wszystko dawno zrobiłem!
Piotr Karwatka - Biznes20.pl
Skalowanie aplikacji jest proste...
... ale bazy danych nie!Replikacja – odporność na awarie, szybkość dostępu
+ wiele punktów dostępu do danych – większe req/s i odporność na awarie
Zyski:
+ aplikacja która dużo czyta, mało pisze:
- aplikacja która dużo czyta i dużo pisze:
- opóźnienia replikacji, - sesje użytkowników
+ tworzenie wyspecjalizowanych serwerów DB
(kilka tabel, wyszukiwanie...),
master slave
master
mastermaster
master
master
master
TB: users
TB: photos
:-(
:-)
Piotr Karwatka - Biznes20.pl
Skalowanie aplikacji jest proste...
... ale bazy danych nie!Partycjonowanie – skalowanie poziome bazy danych
Partycjonowanie pionowe Partycjonowanie poziome - federacja
- różne tabele na różnych hostach,- prosta implementacja (replikacja),- szybko dochodzimy do ściany
- podział ogromnej tabeli pomiędzy różne serwery,- umożliwia tworzenie user-clusterów- bardzo dobre zrównoważenie zapisów i odczytów,- nigdy nie dochodzimy do ściany
Table
Table
Table
Table
A - F
G - O
P - Z
A - ZTableTable
A - Z
A - ZA - Z
Table 1
23
TableA - Z
4
.... Table3 JOIN Table2 ??? ... WHERE Table.Imie = 'Alfons' AND Table.Imie = 'Zenon' ???
Piotr Karwatka - Biznes20.pl
A co z moimi fotkami? ”Jeden nginx znaczy więcej niż 1000 apachy”
- wydziel serwery dla treści statycznych (static.serwis.pl?) - dla fotek, CSS, JS ...
Pliki użytkowników szybko rosną?
1) RAID (0, 01...)
2) NAS – (NetApp FAS?) – stosunkowo drogie, bardzo szybkie, automatyczne kopie, rozmiary powyżej 500TB,
3) Clustered File Systems (MogileFS, odłamki NFS/SMB/FTP) – chcesz być jak Google? :-) automatyczna replikacja na wielu serwerach, odporność na problemy, szybkość przy szybkiej sieci,
4) CDN (Akamai ...) – serwujesz 300 tys. strumieni wideo na raz?
5) S3 – CDN dla ubogich – stosunkowo wolny, tani przy małych i średnich ilościach danych, drogi przy duuużej skali!
One rosną jeszcze szybciej!
Piotr Karwatka - Biznes20.pl
Jak się przeskalować?primo: o ile to możliwe, projektuj z myślą o skalowaniu poziomym,
1)- skaluj pionowo dokąd tylko się da:
- optymalizuj to co wykorzystuje wąskie gardła,- korzystaj z Cache gdzie tylko można,- umieść bazę danych na osobnym serwerze
2)- wydziel serwery dla obrazków i plików statycznych,- dodaj kolejne serwery aplikacji,- stwórz klaster cache,- stosuj serwery storage – a jeśli to za mało twórzklastry rozproszonego systemu plików,- zastosuj serwery reverse proxy (SQUID, Varnish)
3)- skaluj bazę danych korzystając z replikacji,- ... ale dąż do skalowania poziomego o ile to możliwe
rosnące koszta
+
+
+
+
+
+ ...
...
++ +
proxy
wwwsql memcache storage
......
Piotr Karwatka - Biznes20.pl
Jeśli jesteś tutaj to masz przynajmniej milion użytkowników! ;-)4)
Jak się przeskalować?Piotr Karwatka - Biznes20.pl
http://highscalability.com/flickr-architecture
Piotr Karwatka - Biznes20.pl
LiveJournal
http://highscalability.com/livejournal-architecture
Piotr Karwatka - Biznes20.pl
Co dalej?
- PaaS - persistance as a service (Google BigTable, GigaSpaces IMDG, Microsoft SQL)- platform as a service – Google AppEngine (wymaga pythona, beta testy, darmowe do 5000 000 odsłon miesięcznie!)
Zupełna abstrakcja!
+ nowe podejście do wytwarzania aplikacji,
+ rezygnacja z typowych baz danych na rzecz operacji na abstrakcjach obiektowych,
+ cała platforma -> WWW, DB, Storage jako usługa. Chcesz korzystać z infrastruktury
wyszukiwarki google?
- bardzo trudna zmiana platformy technologicznej! Praktycznie niemożliwa,
- brak łatwych rozwiązań przejściowych
Piotr Karwatka - Biznes20.pl
Q & A
pkarwatka@biznes20.pl
Biznes20.plBizneswiki.pl
Piotr Karwatka - Biznes20.pl