Zabijamy Pana Gąbkę zawodowo wraz z Fotka.pl

W kolejnej części wywiadów (o tym jak radzić sobie z wydajnością serwisów internetowych) na moje pytania odpowiedział Rafał Agnieszczak (fotka.pl), który utrzymuje jeden z największych serwisów społecznościowych w Polsce.

Rafał na moje pytania odpowiedział bardzo konkretnie, bardzo szczegółowo i dodał również wiele ciekawych informacji o tym jak zbudowana jest fotka.pl od środka. Mimo, iż tekst jest dość długi to jednak dla każdego kto chce dowiedzieć się wielu ciekawych informacji na temat walki z wydajnością będzie on z pewnością bardzo ciekawy i pouczający.

Czy tak zwana "wydajność" to duży procent w budżecie takiego serwisu jak twój?, jak dużo wydajesz na utrzymanie infrastruktury (mogą to być przybliżone kwoty lub widełki)

Z biegiem czasu na infrastrukturę wydajemy proporcjonalnie coraz mniej pieniędzy. Oczywiście ilość potrzebnych serwerów i łącz ciągle rośnie, ale przychody Fotka.pl zwiększają się zdecydowanie szybciej. W tej chwili myślę, ze koszty te nie przekraczają 20% przychodów. W ciągu roku chcemy zejść do poziomu 10% - to branżowy standard. Warto tu zauważyć, że rozwijamy infrastrukturę w większym komforcie niż 2-3 lata temu. Nie kupujemy już sprzętu potrzebnego "na wczoraj”, ale z wyprzedzeniem i w ilościach pozwalających nie martwic się o to, na jakie funkcjonalności w serwisie możemy sobie pozwolić, a na jakie jeszcze nie.

Jak radzisz sobie z utrzymanie odpowiedniej wydajności serwisu, czy zatrudniałeś (zatrudniasz) specjalistów w tej dziedzinie?

W elblaskim biurze mamy cale IT w tym 5 administratorów, kilku programistów i Andrzeja, który od początku istnienia serwisu dba o to, żeby wszystko działało jak należy. Cala wiedza na temat utrzymywania takiego dużego serwisu jest efektem wewnątrz firmowej pracy nad optymalizacja. To setki godzin podczas których sprawdziliśmy na żywym organizmie dziesiątki rozwiązań - tego nie da się wyczytać z prezentacji dostępnych w sieci.

Czytaj dalej poniżej

Po konferencji Internet 2K8 – krótkie podsumowanie. Grzegorz Marczak

Muzyka w profilu na grono.net, ale nie dla wszystkich. Grzegorz Marczak

Czy w tych czasach (dostępnych technologii i taniejących serwerów, łączy itp) wydajność może być permanentnym problemem - czy też powinna być rozwiązywana wraz z "kolejną dostawą serwerów"

Serwery i łącza już jakiś czas temu przestały być problemem. Nie trzeba inwestować dużych pieniędzy na starcie - można wynająć serwery w zachodnich datacenter wraz z łączami w przyzwoitej cenie zamiast zamawiać "kolejna dostawę serwerów" do swojej kolokacji. Do tego dostępność sprzętu została skrócona do kilku godzin /duże datacenter w USA/ lub nawet minut /odpalenie zwirtualizowanego serwera na Amazon EC2/. Problemem nie jest wiec sprzęt i łącza ale rozwiązania. O ile serwowanie obrazków można wydzielić do zewnętrznej firmy, o tyle sam serwis WWW trzeba utrzymywać samemu co przy dużej skali staje się problematyczne. Jest, bowiem duża różnica miedzy infrastrukturą złożoną z kilku, kilkunastu maszyn, a ta liczoną w setkach czy tysiącach. Pewne elementy serwisu jak bazy danych są trudno skalowane i kluczem do rozwiązania problemu jest nie tylko odpowiednie zastosowanie dostępnych narzędzi, ale tez wiedza i zdobyte doświadczenie. Jeśli ktoś tej wiedzy nie posiadł to rzeczywiście może mięć permanentny problem, bo skalowanie to nie jest zwykle dodawanie kolejnych klocków - najpierw trzeba wymyślić w jaki sposób te klocki powinny współgrać.

Serwery Fotka.pl

Twitter to już chyba symbol problemów z dostępnością serwisu internetowego w tych czasach - co według Ciebie może być główną przyczyną tych problemów i jaka kwota pieniędzy powinna je definitywnie rozwiązać?

Odpowiedz jest prosta i skalda się tylko z 3 liter: RoR. Ruby to coraz popularniejszy i "modny" język ale jego wydajność i skalowalność nadal pozostawia wiele do życzenia. W porównaniu do konkurencyjnej kombinacji czyli Python i framework Django to znacząca różnica. Oczywiście znajda się tacy, którzy powiedzą, że to tylko wina kiepskich programistów, a nie języka jednak nie da się zaprzeczyć, ze nawet DHH /twórca Ruby on Rails/ do niektórych swoich projektów uzywa PHP bo uznaje to za lepsze rozwiązanie. W przypadku Twittera nie winiłbym ani administratorów /nawet świetny nie zdziała cudów musząc optymalizować nieprzemyślane oprogramowanie/ ani Joyent /to do niedawna ich firma hostingowa udostępniająca zwirtualizowane boxy na Solarisie, dostawiane na zawalanie i loadbalancowane przez F5 BigIP/.

Z całym szacunkiem do wszystkich wyznawców RoR - to nie jest dobra platforma na miliardy odsłon. Stare, poczciwe PHP radzi tu sobie dużo lepiej, a dla entuzjastów nowości rozsądna alternatywa to Python/Django, szczególnie po wprowadzeniu Google App Engine. GAE to oczywiście środowisko dla aplikacji webowych oparte o rozwiązania Google. To zupełnie nowe, rewolucyjne podejście do tematu infrastruktury, w założeniu bliższe platformie Facebooka niż typowym platformom hostingowym. Nie jest jednak tak pięknie jak można by się spodziewać - Jaiku, konkurent Twittera tuz po premierze GAE zadeklarowal przeniesienie serwisu na platformę jako jeden z pierwszych na świecie. Minął miesiąc, a Jaiku nadal leci z Finlandii - widać wiec, ze to nie takie proste. Tylko "specjaliści" w komentarzach maja doświadczenie w optymalizacji wszystkiego i na dowolna skale - niestety nie chcą się dzielić wiedza ;).

Jakieś rady dla tych, którzy właśnie zauważyli, że ich popularny startup zaczyna wolno działać?

Jeśli jakiś "popularny startup" zaczyna wolno działać to znaczy, ze należy wymienić zagraniczny hosting za 7 dolarów na cos bardziej profesjonalnego za 500-600 złotych, najlepiej w Polsce. Mowie całkiem poważnie - duża cześć seriwsów jest po prostu żle napisana i wystarczy dobra optymalizacja kodu aby nigdy nie zaznać problemów typowej skalowalności. Powiedzmy sobie jasno: serwisów, dla których skalowalność jest wyzwaniem mamy w kraju raptem ze 20-cia, to te mające powyzej 200 mln odsłon miesięcznie. Reszta to tzw. bulka z masłem wymagająca co najwyżej kilku mocniejszych serwerów, myślącego admina i znajomości kombinacji paru magicznych haseł w stylu Ngnix, Lighttpd, Memcached, Pound, Squid, Varnish, HAproxy, round robin DNS, replikacja master/slave itp. Bawią mnie wiec rady tych, co radzą np. Naszej-Klasie jak sobie poradzić z ich popularnością. To tak jakby kierowca z prawem jazdy kategorii B, któremu udaje się prowadzić dostawczaka z przekonaniem twierdził, ze kierowanie 24-tonowego TIRa jest tak samo proste. Nie ma wiec chyba sensu rozpisywać na czynniki pierwsze jak z kilku klocków poukładać coś, co się nie rozpadnie przy kilkudziesięciu tysiącach wizyt dziennie - liczba prezentacji na ten temat jest dość duża.

W zamian, pewnie bardziej w kategoriach ciekawostki, mogę opowiedzieć jak funkcjonuje Fotka.pl /70-80 milionów odsłon i 3 miliony wizyt każdego dnia/. Otóż podstawa to bazy danych, tutaj mamy autorskie rozwiązanie nazywane przez nas Gridem gdzie dane użytkowników dzielone są na poszczególne nody, każdy składający się z 2 serwerów /po to aby w każdej chwili można było wyłączyć jeden z nich lub przetrwać awarie dociążając druga maszynę/. Dodatkowo skalujemy się na poziomie "serwerów cronowych" wykorzystywanych do skalowania zdjęć, sprawdzania wiadomości w Gmailu, wysyłania powiadomień itd - tutaj mamy wydzielone narzędzie pozwalające na płynne dokładanie nowych maszyn w zależności od aktualnego obciążenia.

Kolejna rzecz to serwowanie zdjęć: te większe serwujemy z Amazon S3, a mniejsze /w celu zredukowania zapytań radykalnie podnoszących koszty/ serwujemy ze swoich serwerów opartych na rosyjskim serwerze Ngnix. Jako pośrednika wykorzystujemy farmę serwerów proxy wraz z load-balancingiem o URL-ach, dzięki czemu zapytanie o ten sam plik trafia zawsze do tego samego serwera. Takie rozwiązanie pozwala na znaczne zwiększenie liczby danych magazynowanych przez proxy, gdyż jeden plik keszowany jest tylko na jednym serwerze, a dodatkowo w razie awarii któregoś z proxy ruch automatycznie kierowany jest na pozostale. Taka funkcjonalność jest istotna z racji serwowania zdjęć bezpośrednio z pamięci RAM - kilkudziesięciokrotnie szybszej od dysków ale tez stanowczo droższej przez co oszczędniej eksploatowanej. Najmniejszy problem to skalowanie serwerów www, tutaj wystarcza dobry hardware-owy load balancer /używamy izraelskiego Crescendo/ i można dostawiać maszyny w nieskończoność. Optymalizacja to również konieczność gzipowania serwowanych danych - często zapomina się tutaj o CSS i JS, a dzięki kompresji możemy zmniejszyć zapotrzebowanie na łącze i czas dostarczenia strony o kilkadziesiąt procent.

Fotka jako jedyna w Polsce na taka skale stosuje sprzętowe gzipowanie plików i serwuje strony w XMLu, dzięki czemu dopiero na komputerze użytkownika następuje tworzenie wyglądu strony na podstawie szablonu XSL. Szacujemy, ze tylko dzięki temu rozwiązaniu oszczędzamy około 400-500Mbit łącza.

Cala infrastruktura jest tez zoptymalizowana pod katem pracy osób dbających o rozwój i utrzymanie serwisu. Przykładowo Grid jest tak napisany, ze z punktu widzenia programisty nie jest istotne, na jakim nodzie znajdują się dane - po prostu wykonuje zwykle zapytania do bazy. Dodatkowo jesteśmy w stanie wydzielić np. popularne lub dowolnie wybrane profile na odrębne maszyny. Grid pozwala również na łatwą zmianę struktur tabel np. indexow, bez konieczności wyłączania serwisu. W przypadku optymalizacji jest to dość istotne, gdyż możemy dowolnie testować rożne sposoby indexowania danych. Oprócz tego stosujemy oczywiście powszechnie znane rozwiązania typu memcached, które pozwala na keszowanie stron w RAMie i dzieki temu szybkie serwowanie ich uzytkownikom.

Sprzęt serwisu fotka.pl

Przy kilku szafach sprzętu istotne jest tez zbieranie danych o działaniu poszczególnych maszyn - wykorzystujemy do tego wydzielony serwer i oprogramowanie Cacti. Możemy uzyskać wykres informacji o obciążeniu dysków, procesorów, zajętości pamięci, temperatur, operacji w bazach, ruchu sieciowego i wielu innych z każdego serwera w naszej sieci.

Dodatkowo do monitoringu działania używamy Naigosa, który powiadamia nas o możliwych zwiększeniach obciążenia lub tez o awariach - alerty docierają za pomocą SMSow lub Jabbera jeżeli dany administrator jest obecnie online. Już nie dla wygody ale z konieczności automatyzujemy praktycznie wszystkie możliwe zadania. Optymalizacja wymaga bardzo wielu zmian w serwisie, dlatego np. zmiana czegokolwiek np. w cfg PHP na 40 maszynach będzie udręką, jeśli nie będziemy mieli skryptów które wykonają to za nas.

Na koniec dodam, ze optymalizacja ma tez miejsce na poziomie ustawienia i połączeń miedzy serwerami - przy dużym ruchu np. backupy czy instalacje upgradow mogą znacznie wpływać na działanie serwisu, dlatego tez stosujemy politykę 3 fizycznie wydzielonych sieci: publicznej gdzie serwowane są dane do użytkowników, prywatnej gdzie odbywa się np. ruch związany z instalacja, backupami oraz sieci managementu, gdzie mamy dostęp do wirtualnych KVMow, pozwalających np. wejście do biosa czy wyłączenie serwera. Dodatkowo poszczególne szafy sprzętu są zduplikowane sprzętowo, aby bez przerw w działaniu serwisu można było wyłączać niektóre z nich i np. zaktualizować hardware lub przenieść do innej lokalizacji.

Obecnie pracujemy nad zwiększeniem wydajności serwowania małych plików. Mimo limitu zdjęć na jednym profilu użytkownicy dodają ich 200-300 tysięcy każdego dnia. W szczycie oznacza to ponad 10.000 zapytań na sekundę. Problemem nie jest tutaj zapotrzebowanie na powierzchnie /wystarczy kilka SUNow x4500 z 48 dyskami i powierzchnia 24TB/ ale ogromna liczba zapytań..