1. Kiedy popularność jest pocałunkiem śmierci... Skalowalność serwisów internetowych w dobie Web 2.0 Piotr Karwatka - Biznes20.pl
2. 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
3. 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
4. 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
5.
6. - 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
7. 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, o dchudzony apache jako proxy, .. serwer DNS?), - sprzętowe (cisco!) lepsze ale droższe, sporo droższe. Piotr Karwatka - Biznes20.pl
8. koszt ilość cpu skalowanie pionowe skalowanie poziome Skalowanie aplikacji jest proste... ... + = Piotr Karwatka - Biznes20.pl
9. 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
10. 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
11. 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 master master master master master TB: users TB: photos :-( :-) Piotr Karwatka - Biznes20.pl
12. 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 A - F G - O P - Z A - Z A - Z A - Z A - Z 1 2 3 A - Z 4 .... Table3 JOIN Table2 ??? ... WHERE Table.Imie = 'Alfons' AND Table.Imie = 'Zenon' ??? Piotr Karwatka - Biznes20.pl
13. 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
14. 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órz klastry 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 www sql memcache storage ... ... Piotr Karwatka - Biznes20.pl
15. Jeśli jesteś tutaj to masz przynajmniej milion użytkowników! ;-) 4) Jak się przeskalować? Piotr Karwatka - Biznes20.pl
18. 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
19. Q & A [email_address] Biznes20.pl Bizneswiki.pl Piotr Karwatka - Biznes20.pl
