Jak Digg walczy z panem Gąbką czyli o wydajności ciąg dalszy.

Autorem tekstu jest Piotr Błaszyński
Jakiś czas temu pojawiał się na tym blogu temat wydajności i architektury serwisów Web2.0, chciałbym aby ten post został potraktowany jako jego skromne uzupełnienie. Twórcy Digga postanowili uchylić rąbka tajemnicy i pokazali z czego składa się i jak działa ten jeden z największych zbiorów rekomendacji. Celowo nie piszę o linkach, bo część rekomendacyjna Digga urosła już do całkiem poważnych rozmiarów. Wygląda na to, że jedną z dróg rozwoju jest przygotowanie dwóch blogów: dla społeczności i technologicznego. Na razie postów malutko, ale z czasem pewnie się coś ciekawego znajdzie.
Cała architektura jest zbudowana z kilku elementów: przede wszystkim bazy danych, serwery plików, serwery aplikacyjne, serwery odpowiedzialne za równoważenie obciążenia pomiędzy maszyny oraz to czym Digg się od niedawna chwali, czyli serwer odpowiedzialny za rekomendacje.

Architektura Digga
+

Według tego co piszą na blogu kopacze (a dokładnie szef zespołu odpowiedzialnego za architekturę systemu) nie "wiedzą" ile jest faktycznie maszyn. Więcej jest tych bazodanowych niż webowych (czyli aplikacyjnych), do tego 6 maszyn na wyliczanie rekomendacji, i 6-10 serwujących pliki przez MogileFS. Specjalnie nie ma co się dziwić tej "niewiedzy", ja też nie wiem na jakich maszynach pracują pisane przeze mnie programy, dopóki działają odpowiednio szybko.

Zapytania zaczynają swą drogę od serwerów równoważących obciążenie. Mają one za zadanie nie tylko rozkładać ruch pomiędzy poszczególne serwery, ale również monitorować serwery aplikacji, przechowywać w cache'u obrazki, pliki CSS i JavaScript. Moim zdaniem przy tak dużym obciążeniu algorytm paradoksalnie się upraszcza, zapytanie idzie po prostu do kolejnego serwera, a jak któryś nie odpowiada, to na chwilę nie wysyła się do niego żądań. Z rysunku wynika, że serwery są dwa a działają (według autorów opisu) jak bicie serca. Prawda jest taka, że te maszyny po prostu monitorują siebie nawzajem, a analogia, choć obrazowa, to jednak jest lekko nieuprawniona. Ze zbliżonych rozwiązań typu FOSS (http://pl.wikipedia.org/wiki/FLOSS) autorzy polecają Linux Virtual Server i Squid.

Następnie zapytanie jest kierowane do serwera aplikacji. Zestaw składa się między innymi następujących elementów: Apache w duecie z PHP, ale również Memcached (cache dla danych) i Gearman (głównie balansowanie obciążenia i przekazywanie go do maszyn, mogących lepiej zrealizować dane żądanie). Powyższa część serwerów łączy się z warstwą danych, która oprócz serwerów bazodanowych, składa się również z systemu plików opartego o MogileFS, czyli rozproszony system plików (to, memcached i Gearman do ściągnięcia z http://danga.com/ i już można ćwiczyć). W systemie plików są przechowywane obrazki oraz kopie linkowanych stron, między innymi dzięki zbieraniu i analizowaniu tych danych funkcjonują rekomendacje.

Z technicznego punktu widzenia jest to dostosowana do takich obliczeń (wyznaczanie powiązań, określanie wag tych powiązań) baza danych przygotowana przez dział badawczy digga. Bazy są oparte o kolejne rozwiązanie FOSS, czyli znany i lubiany MySQL. Zorganizowane jest to w ten sposób, że są cztery bazy główne (master) i każda z nich ma kilka baz pomocniczych (slave). Aby uniknąć problemów z blokowaniem, każdy zapis danych jest kierowany do bazy głównej, natomiast dane są odczytywane z baz pomocniczych. Bazy danych różnią się od tego co możemy zobaczyć w "klasycznym" projekcie wysokim stopniem denormalizacji (swoją drogą mogliby napisać, kiedy pojawiła się denormalizacja, czy dopiero w momencie wystąpienia problemów z wydajnością, czy na etapie budowania funkcjonalności).

Dodatkowo używany jest Memcached i specjalny program monitorujący połączenia i zamykający te wiszące zbyt długo.

Podsumowując: Digg korzysta z następujących elementów: Debian GNU/Linux, MySQL, Memcached, MogileFS, Python, PHP, Apache, Gearman i kilku pomniejszych. Powyższa infrastruktura obsługuje miliardy zapytań miesięcznie (a codziennie jest ich coraz więcej!). Moim zdaniem architektura ta pokazuje pewne trendy w aplikacjach sieciowych. Oprócz pracy programistów duże nakłady idą na architekturę, ale na jej przemyślaną budowę, a nie tylko bezpośrednio w sprzęt, bo już wielu się przekonało, że samo dokupienie maszyn może nie spowodować przyśpieszenia, nawet w niektórych przypadkach pogorszenie wydajności.

Druga, warta zauważenia, sprawa to rekomendacje, po liczbie deklarowanych maszyn można określić, że jest on poważnie "traktowany". Być może niedługo podobne rozwiązania pojawią się w innych serwisach zagranicznych, a w przyszłości np. w wykopie, który moim zdaniem cierpi na wysoki stosunek szumu do sygnału.