Pocałunek śmierci

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


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?


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



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...


- 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.


Zrobiłem to wszystko. Co dalej?


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.


koszt

ilość cpu

skalowanie pionowe

skalowanie poziome


...

+ =


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



... 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!



... 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

:-(

:-)



... 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' ???


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!


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

......


Jeśli jesteś tutaj to masz przynajmniej milion użytkowników! ;-)4)

Jak się przeskalować?Piotr Karwatka - Biznes20.pl

http://highscalability.com/flickr-architecture


LiveJournal

http://highscalability.com/livejournal-architecture


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


Q & A

[email protected]

Biznes20.plBizneswiki.pl


Pocałunek śmierci

Documents

Transcript of Pocałunek śmierci