[PL] We all make distributed systems - RG Dev

Growing complexity of web and mobile apps makes then distributed systems. That's why it's reasonable to apply some results of distributed system research to web and mobile apps.

Slides for a talk given on Rzeszów Developer Meetup: https://www.meetup.com/rg-dev/events/236341099/.
I show how CAP theorem can be used to understand and handle limitations in modern web and mobile applications.

Transcript

1. WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE DISTRIBUTED SYSTEMS DISTRIBUTED SYSTEMS DISTRIBUTED SYSTEMS DISTRIBUTED SYSTEMS DISTRIBUTED SYSTEMS DISTRIBUTED SYSTEMS MACIEJ RZĄSA @mjrzasa
2. SERIO? SYSTEMY ROZPROSZONE? źródło: goodfreephotos.com
3. KIM JESTEM? Software Engineer główne zainteresowania Ruby writing software that matters samoorganizacja systemy rozproszone (okazjonalnie) dzielenie się wiedzą Rzeszów Ruby User Group ( ) Politechnika Rzeszowska rrug.pl
4. O CZYM POWIEM? Why? - dlaczego warto się zająć systemami rozproszonymi What? - ograniczenia systemów rozproszonych How? - case study
5. Zestaw niezależnych komputerów, sprawiający na jego użytkownikach wrażenie jednego, logicznie zwartego systemu. źródło: Wikipedia SYSTEM ROZPROSZONY
6. PROSTE JAK APLIKACJA WEBOWA?
7. Zestaw niezależnych komputerów, sprawiający na jego użytkownikach wrażenie jednego, logicznie zwartego systemu. źródło: Wikipedia SYSTEM ROZPROSZONY
8. NO I CO Z TEGO? źródło: pinterest.com
9. 3 CECHY Consistency - spójność Availability - dostępność Partition tolerance - odporność na podziały
10. single-copy consistency nie to samo co w ACID zapisuję na androidzie, czytam na komputerze CONSISTENCY
11. każdy działający węzeł odpowiada poprawnie np: mogę skorzystać z każdego klienta (web/android/iOS/WP) AVAILABILITY
12. system działa pomimo przerwania komunikacji błąd sieci: utrata pewnej ilości pakietów offline-mode timeout PARTITION TOLERACE
13. nie można mieć wszystkich 3 dowód: spróbuj zapisać offline i przeczytać gdzie indziej CAP THEOREM
14. spójność i dostępność rezygnujemy z obsługi podziałów jeden host sieć jest zawodna CA: I FEEL LUCKY
15. spójność i odporność na podziały zapewniona spójność nie ma offline, działa tylko jak jest sieć ew. ograniczone funkcje (read-only) proste pobranie danych po powrocie połączenia CP: ORDNUNG MUSS SEIN
16. dostępność i odporność na podziały aplikacja dostępna offline konieczna dwustronna synchronizacja AP: WORK AROUND THE CLOCK
17. CASE STUDY jak na to trafiłem? dziedzina: recycling aplikacja mobilna dla agentów + webowy panel admina offline: skupowanie, rejestr płatności
18. ARCHITEKTURA offline: AP, reszta: CP wymagana synchronizacja i rozwiązywanie konfliktów wyzwania rozmiar danych walidacje spójność (ACID) po stronie klienta identyfikacja edycja offline
19. SYNCHRONIZACJA pobieranie dużej ilości danych po powrocie połączenia dwustronna synchronizacja wspólna edycja danych retransmisja
20. SYNC SYNC SYNC SYNC SYNC SYNC SYNC SYNC SYNC SYNC ALL THE DATA! ALL THE DATA! ALL THE DATA! ALL THE DATA! ALL THE DATA! ALL THE DATA! źródło: memegenerator.com
21. SYNC - ONE WAY (CP) cenniki, publikowane ~1/tydzień, wiele o tej samej porze pierwsza wersja: wszystkie zmiany na raz większa ilość danych: timeouty, braki pamięci na androidzie rozwiązanie: paginacja!
22. PAGINACJA GET /items? page=1 GET /items? since=1234 to=3456 GET /items? since=1234 page_size=3
23. ONE WAY SYNC pobieranie danych do odczytu offline klient przechowuje timestamp klient może decydować o ilości przesyłanych danych
24. SYNC - TWO WAY (AP) zapis paragonów (paragon, kupione przedmioty) skupowanie offline (!) każdy klient (android) tworzy swoje paragony i dodaje przedmioty paragony dostępne na serwerze i rozsyłane do innych klientów
25. CLIENT SERVER SYNC - TWO WAY (AP) def sync() timestamp = get_timestamp() client_changes = choose_updated(timestamp) server_changes = send(client_changes, timestamp) # wait... store(server_changes) set_timestamp(Time.now()) end def sync(client_changes, timestamp) server_changes = choose_updated(timestamp) store(client_changes) send(server_changes) end
26. EDYCJA PARAGONÓW anulowanie paragonów (zakupów) na serwerze zmienione paragony wysyłane do klientów FAIL! obie strony edytują paragon: serwer wygrywa rozwiązanie: synronizacja zmian statusu, a nie całych paragonów
27. ONE DOES NOT SIMPLY ONE DOES NOT SIMPLY ONE DOES NOT SIMPLY ONE DOES NOT SIMPLY ONE DOES NOT SIMPLY ONE DOES NOT SIMPLY ONE DOES NOT SIMPLY ONE DOES NOT SIMPLY ONE DOES NOT SIMPLY ONE DOES NOT SIMPLY SYNC MUTABLE STATE SYNC MUTABLE STATE SYNC MUTABLE STATE SYNC MUTABLE STATE SYNC MUTABLE STATE SYNC MUTABLE STATE źródło: youtube.com
28. RETRANSMISJA Klient płatności wysyła płatności Serwer zapisuje i uaktualnia stany kont Co jeśli po zapisie klient utraci połączenie?
29. RETRANSMISJA I IDENTYFIKACJA def sync(data) create_transaction(data) account.redeem(data.amount) end PUT /transactions { amount: 1000 } def sync(data) transaction = find_transaction(data.uuid) if transaction return end create_transaction(data) account.redeem(data.amount) end PUT /transactions { uuid: "2db1ec4c-...", amount: 1000 }
30. WSPÓŁDZIELONE IDENTYFIKATORY AUTOINCREMENT z bazy danych nie wystarczy ;-) UUID (v4) bardzo niskie ryzyko kolizji może być generowany po stronie klienta pomocniczy identyfikator albo klucz główny e4043456-b29e-4d80-afaf-4d65246f1d36
31. SKUTEK: IDEMPOTENTNOŚĆ If all you have is a timeout, everything looks like a partition synchronizacja może być powtarzana dowolną ilość razy pomocne przy błędach (sieci, serwera, klienta) zastosowanie: tworzenie danych po stronie klienta offline: notatki zakupy commity ;-)
32. CZEGO SIĘ NAUCZYŁEM?
33. CZEGO SIĘ NAUCZYŁEM? paginacji przy pomocy timestampów i rozmiaru strony poprawnej synchronizacji dwustronnej dbania o bezpieczeństwo danych podczas błędów (idempotencja) GET /items? since=1234 page_size3
34. PODSUMOWANIE naturalne ograniczenia z systemów rozproszonych w web/mobile są naturalne ;-) CAP: spójność - dostępność - odporność na podziały: nie możesz mieć wszystkiego synchronizuj to, co niezmienne i aplikuj od zmiennego (events vs entities) idempotency matters :) w jednej aplikacji można stosować zarówno podejście CP jak i AP sieć jest zawodna ikony w diagramach pochodzą ze strony: http:/ /www.flaticon.com
35. MATERIAŁY ikony w diagramach pochodzą ze strony: : testy bezpieczeństwa (safety) systemów rozproszonych : o zawodności sieci http:/ /www.flaticon.com CAP 12 years later Jepsen Netwok is reliable