Architektura skalowalnych serwisów internetowych

Architektura skalowalnych
serwisów internetowych
Michał Gruchała
Architektura skalowalnych
serwisów internetowych

Serwis

Wprowadzamy zmiany


Modularność

Cache

Shardowanie
Podsumowanie
O mnie

2005-2011 GG Network S.A.

2011 Politechnika Warszawska

2011 scaleIT
Serwis
Serwis

Dodaj wpis

Zobacz


Ostatnie wpisy (wszystkich)

Wpisy moich znajomych (stream)

Wpisy (blog) danej osoby
Obserwuj
Serwis

Struktura bazy
Serwis

Blog
select * from User where id=ID
select * from Message where id=ID order by ts desc limit …

Stream
select * from User where id=JA
select Message.*, User.* from Message
join Follow on Message.owner_id=Follow.whom_id
join User on Message.owner_id=User.id where
Follow.who_id=JA; (!)

Dodaj wpis
insert into Message(`owner_id`,`message`) values ...
Serwis

Gdzie jesteśmy?
Replikacja danych
użytkownik
PHP
MySQL
HaProxy
Serwis

Gdzie jesteśmy?

LB i workery ”dokładamy w nieskończoność”

Kolejne repliki bazy zwiększają odczyt



Nie zapis
Nie pojemność
full-mesh
Wprowadzamy zmiany
Wprowadzamy zmiany

Rozdzielamy ma moduły
Wprowadzamy zmiany

Rozdzielamy ma moduły

Partycjonowanie funkcjonalne

User (API)

Message (API)

Front



Front
Moduł stanowy (sesja)
Prezentacja
Agregacja danych z API
User
użytkownik
Message
Moduł
Wprowadzamy zmiany

Moduły są niezależne

Ma swój zestaw maszyn



Moduł A nie wie jak zorganizowany jest moduł B


Load balancery, Workery, Bazy
Jedna maszyna = jedna rola
Wie tylko jak go używać (API)
Komunikacja między modułami

tylko za pomocą API (dostępne przez LB)
Wprowadzamy zmiany


Blog

Front => User (podaj dane użytkownika X)

Front => Message (podaj wpisy użytkownika X)
Stream



Front => User (podaj listę obserwowanych przez
użytkownika X)
Front => Message (podaj ostatnie wpisy
użytkowników o zadanych id)
Zrób join na liscie użytkowników i wpisów
Wprowadzamy zmiany


Zalety

Moduł Front prostszy

Wiemy gdzie są wąskie gardła

Separacja obowiązków
Wady

Więcej maszyn

Workery Front robią joiny

Odciąża bazy, workery można dokładać

Jest wolniej

Spójność danych (skasowanie użytkownika?)
Wprowadzamy zmiany

Dodajemy cache
Wprowadzamy zmiany

Dodajemy cache

Każdy moduł zarządza swoim cache

Dwa poziomy cache

Loadbalancery (zamieniamy haproxy na varnisha)


Memcached


”chroni” workery, memcached, DB
”chroni” DB
Dwie metody


Odczyt z DB, zapis do cache na X sekund
Odczyt z DB, zapis do cache ”w nieskończoność” (!)
Wprowadzamy zmiany

Blog

Front => Message (podaj wpisy użytkownika X)



Message API LB (cache)
MessageAPI Worker => DB
Lista wiadomości zapisana w


Memcached ?
Varnish ?
Wprowadzamy zmiany

Stream


Front=> User (podaj listę obserwowanych)
Front => Message (podaj blogi użytkowników z
listy)
Message: dla każdego użytkownika z listy
 pobierz wpisy użytkownika (blog)
 join w workerze
Tak zwane pull on demand


Wprowadzamy zmiany

Dodaj wpis

Front => Message (dodaj wpis użytkownika X)



Worker Message dodaje wpis do bazy
Worker Message dodaje wpis do memcached
Worker niszczy (łatwiej) listę wpisów (blog)
 ze swojego varnisha
 ze swojego memcached
troche się skomplikowało....
Wprowadzamy zmiany


Zalety

Jest szybciej

Odciążamy DB i sieć(!)

Duże hit-ratio na memcached przy blogach

Brak dog-pile effect (varnish)
Wady

Trudniej (więcej worker-side)

Spójność cache i baz danych

Im więcej lb, tym mniejsze hit-ratio
Wprowadzamy zmiany

Shardujemy
Wprowadzamy zmiany

Shardujemy

Partycjonowanie horyzontalne

Shardy są niezależne



Mają inne dane
Nic nie wiedzą o sobie
Funkcja(klucz) = numer sharda
Wprowadzamy zmiany

Shardujemy

Tabela Follow



Tabela Message



Klucz who_id
Funkcja who_id modulo liczba shardów
Klucz owner_id
Funkcja owner_id modulo liczba shardów
Tabela User

Bez shardowania
Wprowadzamy zmiany


Zalety

Zwiększamy wydajność zapisów (i odczytów)

Zwiększamy pojemność bazy

Więcej mniejszych baz (zarządzanie, szybkość)
Wady

Komplikacja logiki

Kto mnie obserwuje


Cross-shard query
Dokładanie shardów
Podsumowanie
Podsumowanie

Prosty serwis

Zrobił się skomplikowany

Skomplikowanie wydelegowane do modułów ;)

Dodaliśmy sporo maszyn

Optymalizacja jeszcze ważniejsza (IO)

Sieć dostaje w kość

Dużo pracy
może scale-up ?
Dziękuję
Pytania?