Zespół NK opowiada o walce z wydajnością - czyli jak zabito Pana Gąbkę

Ciąg dalszy serii o walce z przysłowiowym Panem Gąbką. Tym razem udało mi się namówić oryginalnych gąbka killerów (czyli zespół nasza-klasa.pl), na opowiedzenie o ich walce z wydajnością.

Najnowsze statystyki odnośnie NK jakie podał mi Maciek Popowicz robią wrażenie. W chwili obecnej serwis zalicza 350 milionów odsłon dziennie (ponad 10 miliardów miesięcznie). Transfer danych jaki generują te odsłony to 6 GB na sekundę. W chwili obecnej nasza-klasa stoi na 500 serwerach (a kolejne 32 są już zamówione). Zdjęcia dodawane przez użytkowników przekroczyły już 1,5 miliarda sztuk - trzymane są one na 500 dyskach w macierzach. Codziennie z serwisu korzysta 5,5 miliona osób.

Poniższy tekst tworzony był przez Pawla Olchawe, z poprawkami Tomka Paszkowskiego, Joanny Gajewskiej, Arka Pernala i Maćka Popowicza.

Aktualnie nasz system opiera się na architekturze zaprojektowanej na przełomie listopada i grudnia 2007. Składa się on z dwóch niemalże zupełnie odrębnych części. Jedną z nich jest obsługa składowania i serwowania zdjęć, a drugą - aplikacja z bazami danych. W przeszłości zmagaliśmy się głównie z aplikacją i bazami danych, ponieważ to od nich zależała szybkość ładowania się strony. Obecnie skupiamy się na optymalizacji systemu zdjęć.

Desperacja Pana Gąbki - gryzie kable od serwerów

Dotychczas do serwowania zdjęć używaliśmy gotowego projektu open-source o nazwie MogileFS. Niestety rozwiązanie to nie spełniło naszych oczekiwań (ruch, którym dysponujemy obnażył słabości jego systemu) i dlatego obecnie wdrażamy autorski system składowania i serwowania zdjęć.

Obecnie zdjęcia przechowywane są bezpośrednio jako pojedyncze pliki na dysku w systemie plików XFS (używamy do tego 160 komputerów: Celerony, Pentium IV, Core2Duo). Każde zdjęcie jest składowane na co najmniej 3 różnych serwerach. Codziennie 3-4 serwery mają problemy z błędami XFS-a, co powoduje utratę kopii niektórych zdjęć. Automatycznie jednak z pozostałych kopii tych zdjęć tworzone są repliki, które składowane są na kolejnych serwerach, dzięki temu utrzymujemy bezpieczną liczbę kopii każdego zdjęcia. Wąskim gardłem w tym przypadku jest prędkość dysków twardych, dlatego dodatkowo część miniaturek zdjęć jest osłaniana serwerami Squid, które przetrzymują je w RAMie.

Aby wspomóc te serwery, zakupiliśmy macierze dyskowe Promise posiadające łącznie 480 dysków SATA/SAS i właśnie kopiujemy zdjęcia na te macierze. Jeśli wszystko pójdzie zgodnie z planem, maksymalnie za dwa miesiące zdjęcia na nk będą się ładowały błyskawicznie, nawet w godzinach szczytu. Aby ustrzec się błędów XFS-a napisaliśmy własny moduł do Lighttpd, przez który serwowane będą zdjęcia. Macierze te będą udostępniać zdjęcia po FC(Fibre Channel) serwerom wpiętym do switcha FC, a te będą w stanie je serwować.Dodatkowo wszystkie miniaturki będą serwowane przez znajdujące się przed nimi serwery keszujące Squid. Aby uniknąć sytuacji, w której wszystkie serwery Squid przetrzymują w RAMie ten sam zestaw miniaturek, podzieliliśmy je na grupki i każda z nich odpowiada za inny zbiór miniaturek.

Od strony aplikacji najwięcej problemów sprawiły nam bazy danych. Gdy tworzyliśmy portal, postawiliśmy na MySQL, ponieważ konto na home.pl z tą bazą danych było tańsze od konta z PostgreSQL :). Jednak przy tak dużym obciążeniu jak nasze bardzo szybko musieliśmy się zmierzyć z błędami MySQLa, a szczególnie z bardzo niskopoziomowymi aspektami działania tej bazy, zarówno dla INNODB jak i InnoDB.

Musieliśmy zapoznać się z kodem źródłowym InnoDB, co miłą lekturą nie jest :D. Dla tworzenia aplikacji, w których występuje masa operacji modyfikujących istotne jest dokładne zrozumienie zasad działania różnych blokad. Miesiące walk sprawiły, że posiadamy obecnie własną, bardzo specyficzną, konfigurację MySQLa. Przykładowo zamiast indeksów FullText w MySQLu do wyszukiwania osób na portalu używamy własnego serwera indeksującego wszystkich użytkowników raz na dobę, który został napisany przez Michała Bartoszkiewicza w C++ z użyciem bibliotek STL oraz boost, i który ani razu (sic!) od samego początku jego istnienia nas nie zawiódł. To, że działa tak bezproblemowo spowodowało, że zupełnie o nim zapomnieliśmy, przez co przy ostatniej migracji tabeli z użytkownikami zapomnieliśmy zmienić mu adres IP w ustawieniach :-)

Z zapytaniami, które bazy nie modyfikują, jest o wiele łatwiej, w ich przypadku wystarczy wspomóc się warstwą keszującą w postaci klastra serwerów Memcached, założeniem potrzebnych indeksów (w
granicach rozsądku) oraz „explainowaniem" każdego z zapytań. Nadal trzeba jednak uważać, bo zbyt długo wykonujące się zapytanie może mieć drastyczne skutki (zwłaszcza w przypadku INNODB).

Reszta w następnym odcinku:) - czyli będzie część 2.