[PL] Wszyscy tworzymy systemy rozproszone - 4developers 2.04.2017

Slides for my talk at 4developers 2017, Warsaw. Slightly different from previous versions of the same presentation.

Transcript

1. WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? MACIEJ RZĄSA @mjrzasa
2. SERIO? SYSTEMY ROZPROSZONE? źródło: goodfreephotos.com
3. ALL DEVELOPMENT IS WEB DEVELOPMENT Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript. Writing Photoshop, Word, or Excel in JavaScript makes zero engineering sense, but it's inevitable. (...) all programming will be web programming Jeff Atwood (2009)
4. KIM JESTEM? Ruby Developer @ TextMaster główne zainteresowania Ruby writing software that matters samoorganizacja systemy rozproszone dzielenie się wiedzą Rzeszów Ruby User Group ( ) Politechnika Rzeszowska rrug.pl
5. PROSTE JAK APLIKACJA WEBOWA
6. PROSTE JAK APLIKACJA WEBOWA?
7. Zestaw niezależnych komputerów, sprawiający na jego użytkownikach wrażenie jednego, logicznie zwartego systemu. Andrew Tanenbaum System rozproszony to taki, w którym maszyna o której nigdy nie słyszałem powoduje, że mój program nie działa. Leslie Lamport PROSTE JAK APLIKACJA WEBOWA?
8. KOMUNIKACJA: 3 CECHY Consistency - spójność Availability - dostępność Partition tolerance - odporność na podziały
9. single-copy consistency nie to samo co w ACID zapisuję na androidzie, czytam na komputerze CONSISTENCY
10. każdy działający węzeł odpowiada poprawnie np: mogę skorzystać z każdego klienta (web/android/iOS/WP) AVAILABILITY
11. system działa pomimo przerwania komunikacji błąd sieci: utrata pewnej ilości pakietów offline-mode timeout PARTITION TOLERACE
12. nie można mieć wszystkich 3 dowód: spróbuj zapisać offline i przeczytać gdzie indziej CAP THEOREM
13. CAP + LATENCY = PACELC If all you have is a timeout, everything looks like a partition - @nkeywal
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 korzystne dla klienta AP: WORK AROUND THE CLOCK
17. CAP CA - I feel lucky CP - Ordnung muss sein AP - Work around the clock The choice of availability over consistency is a business choice, not a technical one. - @coda
18. CASE STUDY CASE STUDY CASE STUDY CASE STUDY CASE STUDY CASE STUDY CASE STUDY CASE STUDY CASE STUDY CASE STUDY źródło: wikipedia.org
19. CASE STUDY jak na to trafiłem? dziedzina: recycling aplikacja mobilna dla agentów + webowy panel admina offline: skupowanie, rejestr płatności
20. WYZWANIA walidacje spójność (ACID) po stronie klienta edycja offline synchronizacja i rozwiązywanie konfliktów rozmiar danych
21. SYNCHRONIZACJA pobieranie dużej ilości danych po powrocie połączenia dwustronna synchronizacja wspólna edycja danych retransmisja
22. 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
23. SYNC - ONE WAY (CP) cenniki, publikowane ~1/tydzień, wiele o tej samej porze wersja 1.0: wszystkie zmiany na raz większa ilość danych: timeouty, braki pamięci na androidzie
24. PAGINACJA GET /items? page=1 GET /items? since=1234 to=3456 GET /items? since=1234 page_size=3
25. 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
26. 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
27. EDYCJA PARAGONÓW anulowanie paragonów (zakupów) na serwerze zmienione paragony wysyłane do klientów FAIL! obie strony edytują paragon: zamiany są nadpisywane
28. 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
29. 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?
30. RETRANSMISJA 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 }
31. 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 skutek: idempotencja e4043456-b29e-4d80-afaf-4d65246f1d36
32. RETRANSMISJA
33. CZEGO SIĘ NAUCZYŁEM? pozwól decydować klientowi o rozmiarze i zakresie danych nie wysyłaj z powrotem otrzymanych właśnie danych synchronizuj to, co niezmienne i buduj zmienny stan używaj rozproszonych identyfikatorów, żeby zachować idempotencję Kto już to umiał? git, cassandra, CRDT, ...
34. PODSUMOWANIE naturalne ograniczenia z systemów rozproszonych w web/mobile są naturalne ;-) sieć jest zawodna CAP: spójność - dostępność - odporność na podziały: nie możesz mieć wszystkiego w jednej aplikacji można stosować zarówno podejście CP jak i AP synchronizuj to, co niezmienne i aplikuj do zmiennego (events vs entities)
35. A couple of months in the laboratory can frequently save a couple of hours in the library. Frank Westerheimer
36. I went through life like this, discovering next something that had first beed discovered in 1889, then something from 1921... And finally I discovered something that had the same date as when I discovered it. (...) You are unlikely to discover something new without a lot of practice on old stuff. Richard Feynman, Feynman Lectures on Computation
37. 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