Architektura skalowalnych serwisów internetowych        Michał Gruchała
Architektura skalowalnych     serwisów internetowych   Serwis   Wprowadzamy zmiany          Modularność          Cache...
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)          Wp...
Serwis   Struktura bazy
Serwis   Blog    select * from User where id=ID    select * from Message where id=ID order by ts desc limit …   Stream  ...
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ą od...
Wprowadzamy zmiany
Wprowadzamy zmiany   Rozdzielamy ma moduły
Wprowadzamy zmiany   Rozdzielamy ma moduły          Partycjonowanie funkcjonalne          User (API)          Message ...
Wprowadzamy zmiany   Moduły są niezależne          Ma swój zestaw maszyn                  Load balancery, Workery, Bazy...
Wprowadzamy zmiany   Blog          Front => User (podaj dane użytkownika X)          Front => Message (podaj wpisy użyt...
Wprowadzamy zmiany   Zalety          Moduł Front prostszy          Wiemy gdzie są wąskie gardła          Separacja obo...
Wprowadzamy zmiany   Dodajemy cache
Wprowadzamy zmiany   Dodajemy cache          Każdy moduł zarządza swoim cache          Dwa poziomy cache               ...
Wprowadzamy zmiany   Blog          Front => Message (podaj wpisy użytkownika X)                  Message API LB (cache)...
Wprowadzamy zmiany   Stream          Front=> User (podaj listę obserwowanych)          Front => Message (podaj blogi uż...
Wprowadzamy zmiany   Dodaj wpis           Front => Message (dodaj wpis użytkownika X)                   Worker Message ...
Wprowadzamy zmiany   Zalety          Jest szybciej          Odciążamy DB i sieć(!)          Duże hit-ratio na memcache...
Wprowadzamy zmiany   Shardujemy
Wprowadzamy zmiany   Shardujemy          Partycjonowanie horyzontalne          Shardy są niezależne                  M...
Wprowadzamy zmiany   Shardujemy          Tabela Follow                  Klucz who_id                  Funkcja who_id m...
Wprowadzamy zmiany   Zalety          Zwiększamy wydajność zapisów (i odczytów)          Zwiększamy pojemność bazy      ...
Podsumowanie
Podsumowanie   Prosty serwis          Zrobił się skomplikowany          Skomplikowanie wydelegowane do modułów ;)      ...
Dziękuję  Pytania?
Upcoming SlideShare
Loading in …5
×

Architektura Skalowalnych Serwisow Internetowych

1,461 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,461
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Architektura Skalowalnych Serwisow Internetowych

  1. 1. Architektura skalowalnych serwisów internetowych Michał Gruchała
  2. 2. Architektura skalowalnych serwisów internetowych Serwis Wprowadzamy zmiany  Modularność  Cache  Shardowanie Podsumowanie
  3. 3. O mnie 2005-2011 GG Network S.A. 2011 Politechnika Warszawska 2011 scaleIT
  4. 4. Serwis
  5. 5. Serwis Dodaj wpis Zobacz  Ostatnie wpisy (wszystkich)  Wpisy moich znajomych (stream)  Wpisy (blog) danej osoby Obserwuj
  6. 6. Serwis Struktura bazy
  7. 7. 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 ...
  8. 8. Serwis Gdzie jesteśmy? Replikacja danych użytkownik PHP MySQL HaProxy
  9. 9. Serwis Gdzie jesteśmy?  LB i workery ”dokładamy w nieskończoność”  Kolejne repliki bazy zwiększają odczyt  Nie zapis  Nie pojemność  full-mesh
  10. 10. Wprowadzamy zmiany
  11. 11. Wprowadzamy zmiany Rozdzielamy ma moduły
  12. 12. Wprowadzamy zmiany Rozdzielamy ma moduły  Partycjonowanie funkcjonalne  User (API)  Message (API) Front  Front  Moduł stanowy (sesja)  Prezentacja User Message  Agregacja danych z API użytkownik Moduł
  13. 13. Wprowadzamy zmiany Moduły są niezależne  Ma swój zestaw maszyn  Load balancery, Workery, Bazy  Jedna maszyna = jedna rola Moduł A nie wie jak zorganizowany jest moduł B  Wie tylko jak go używać (API) Komunikacja między modułami  tylko za pomocą API (dostępne przez LB)
  14. 14. 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
  15. 15. 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?)
  16. 16. Wprowadzamy zmiany Dodajemy cache
  17. 17. Wprowadzamy zmiany Dodajemy cache  Każdy moduł zarządza swoim cache  Dwa poziomy cache  Loadbalancery (zamieniamy haproxy na varnisha)  ”chroni” workery, memcached, DB  Memcached  ”chroni” DB  Dwie metody  Odczyt z DB, zapis do cache na X sekund  Odczyt z DB, zapis do cache ”w nieskończoność” (!)
  18. 18. Wprowadzamy zmiany Blog  Front => Message (podaj wpisy użytkownika X)  Message API LB (cache)  MessageAPI Worker => DB  Lista wiadomości zapisana w  Memcached ?  Varnish ?
  19. 19. 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
  20. 20. 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....
  21. 21. 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
  22. 22. Wprowadzamy zmiany Shardujemy
  23. 23. Wprowadzamy zmiany Shardujemy  Partycjonowanie horyzontalne  Shardy są niezależne  Mają inne dane  Nic nie wiedzą o sobie  Funkcja(klucz) = numer sharda
  24. 24. Wprowadzamy zmiany Shardujemy  Tabela Follow  Klucz who_id  Funkcja who_id modulo liczba shardów  Tabela Message  Klucz owner_id  Funkcja owner_id modulo liczba shardów  Tabela User  Bez shardowania
  25. 25. 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
  26. 26. Podsumowanie
  27. 27. 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 ?
  28. 28. Dziękuję Pytania?

×