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.
Witaj, nazywam się Grzegorz Marczak i jestem autorem tego bloga. Piszę tutaj o serwisach społecznościowych, nowych technologiach i nowych trendach w internecie.
Ciekawe, czy mają Apache a nie np. Lighttp, bo wyszły lepiej w testach wydajnościowych, czy “siła przyzwyczajenia” ;)
Ciekawy wpis! Kiedyś czytałem jak mają na DIGG zorganizowane tabele w MySQL – też ciekawa architektura. Podrzucił bym linka, ale nie mogę znaleźć.
O tym jak DIGG poważnie traktuje rekomendacje już pisaliście: http://antyweb.pl/jay-adelson-o-collaborative-filtering/ . A ostatnio chyba eioba.pl uruchomiła coś podobnego u siebie – tylko tutaj bardziej oparte o znajomych niż o “algorytmy predykcyjne”.
Tak samo jak można síę zastanawiać, czy nie byli by szybsi na Postgresie zamiast na mysql.
Pozatym sam Lighttpd nie jest aż dużo szybszy aby był sens im przechodzić na niego.
Może pomodyfikowali troche apache ?
Nie “działają jak bicie serca”, tylko dla monitorowania siebie nawzajem działają w konfiguracji “heartbeat”. To takie pojęcie domenowe High-Availability, oznaczające właśnie to, co następuje dalej w tekście.
Muczachan: Zgoda, choć w tekście inspirującym jest: “This is often referred to as a “heartbeat””, w tekstach o HA jest bez cudzysłowów, zmyliło mnie to trochę. Dziękuję za uwagę, można to było jakoś lepiej określić.
Ciekawy, artykul. Na techit.pl jest bardzo dobry film w ktory administrator mowi o podobny systemie ktory dziala na interia.pl
zgaduję, że z czasem i tak będą musieli upchnąć do tego jeszcze map-reduce, zapewne do budowania indexu dla wyszkuiwania oraz systemu rekomendacji (analiza grafu), więc całe rozwiązanie zrobi się bardziej javowe albo pythonowe
@mantrid
nie masz pojęcia co to map-reduce, skoro kojarzy ci się to z javą albo pythonem
@ms
ech, epuls.pl :)