[Kraków] ach te systemy rozproszone

Wygląda na to, że rok 2018 to rok pierwszych razów i przełamywania własnych granic, i tak 9 września wystąpiłam na konferencji! Rzecz działa się w Krakowie w ramach Java Developer Days, dwudniowego dorocznego spotkania, na którym można dowiedzieć się o nowościach w świecie języka programowania Java, wymienić doświadczeniami, a także posłuchać wykładów po prostu ze świata programowania i komputerów. Moja prelekcja należała właśnie do tej ostatniej kategorii i mówiła o tym, że budowanie systemów rozproszonych jest trudne.

Identyfikator. To się dzieje naprawdę!

Harmonogram! To się dzieje NAPRAWDĘ!
Wtorek, godzina dziesiąta, sala trzecia, język angielski.

fanty czekające na mnie jako prelegenta w pokoju hotelowym. Słodycze
rozumiem, ale małpki? To tak dla kurażu przed wystąpieniem?

Po krótkiej nocy (wszak trzeba było dopracować slajdy i po raz setny powtórzyć przemowę, a ta nigdy nie jest doskonała). Prezentacja jest do obejrzania na youtubie.

to już za chwilę!

opowiadam!

tyle zdjęć mi zrobili, ale na każdym mówię,
więc mam otwartą buzię :( mogli
powiedzieć, że przerwa na fotki!

[1] dzień dobry

[2] to ja. kiedy mam wolną chwilę, wsiadam na rower

[3] to jest świat. Świat jest duży. Z 7 miliardów Ziemian internetu w
zeszłym roku użyła ponad połowa. Ilu z nich słyszało / używa Google'a?

[4] a przecież Google to nie tylko wyszukiwarka. To nawet nie tylko
osiem serwisów, które mają po miliardzie użytkowników miesięcznie.
To dużo dużo więcej różnie popularnych serwisów.

[5] chcemy, by każdy z nich był jak najlepszy i jak najbardziej niezawodny
Do tego potrzeba mocy obliczeniowej. Dużo mocy.

[6] potrzebujemy być blisko naszych klientów, mamy centra danych
i mocy obliczeniowej w wielu miejscach na świecie (to tylko podzbiór,
ale pełnej mapy pokazać nie mogę).

[7] przy tylu serwisach tysiące inżynierów Google'a nie powinno wciąż
i na nowo odkrywać Ameryki, czyli rozwiązywać tych samych problemów.

[8] a jakie to problemy? Zarządzanie zasobami, takimi jak procesor,
pamięć i dysk. Zamiast zostawiać każdemu programiście problem, ile
zasobów zużywa jego serwis, lepiej napisać wewnętrzną aplikację,
która oszacuje to dla wszystkich wewnętrznych serwisów.

[9] gdzie wystartować serwis? Z jakim priorytetem (priorytety ustala się,
bo w przypadku gdy zasobów jest za mało, któryś proces musi zostać
wywłaszczony na rzecz ważniejszego)? A co ze skryptami
uruchamianymi regularnie (np. we wtorki o 10)?

[10] jak wypuszczać nowe wersje serwisów? Najlepiej często, szybko,
automatycznie i dogłębnie przetestowane.

[11] a zewnętrzni programiści? Przecież oni rozwiązują te same problemy!

[12] dla nich jest Chmura (Google Cloud), gdzie można wykupić sobie
instancje - czyli wirtualne komputery, którymi nie trzeba się opiekować,
przeglądać ich, a można uruchamiać na nich wszystko co się chce.

[13] klienci najpierw zaczynają z jedną maszyną wirtualną.
Startują, eksperymentują, testują.

[14] gdy są pewni, co i jak robić - tworzą grupę wirtualnych maszyn.
Każda maszyna w grupie jest identyczna, obsługuje zapytania
użytkowników w ten sam sposób i jest tworzona z jednego szablonu.

[15] żeby użytkownik nie musiał kontrolować liczby potrzebnych maszyn
może użyć autoskalera, który dodaje instancje, kiedy ruch u klienta jest
większy, a kasuje je, kiedy docelowi użytkownicy śpią (albo robią inne
 rzeczy, ale nie używają serwisu) celem ograniczenia kosztów.

[16]  żeby skonfigurować autoskalowanie, trzeba podać kilka ustawień -
przede wszystkim określić sygnał, po którym chcemy się skalować (np.
obciążenie procesora) i średnią wartość tego sygnału w grupie.
Przykładowo jeżeli wybierzemy 60%, a prawdziwe zużycie będzie
większe, nowe maszyny będą dostawiane, by zaspokoić
zapotrzebowanie.

[17] oprócz tradycyjnych grup maszyn, mamy też regionalne - gdzie
w obrębie jednej grupy, instancje tworzone są w różnych lokalizacjach.
Jeżeli Chmura Google'a będzie miała problemy w jednej z nich, serwis
użytkownika nadal będzie działał w dwóch pozostałych.

[18] wracając do problemów, których nie chcemy rozwiązywać wielokrotnie,
kolejnym z nich byłaby skala - instancji jest bardzo dużo, a nasze serwisy
analizują w związku z tym bardzo bardzo bardzo dużo danych.

[19] ponadto dobre serwisy powinny być zreplikowane, czyli być
uruchamiane w więcej niż jednej kopii (bo co jeśli jedna z jakiegoś powodu
się zawiesi?). To rodzi kolejny problem - tylko jedna z tych kopii może
być najważniejsza i mieć uprawnienia modyfikowania świata (np.
dodawania czy kasowania instancji w grupach użytkowników);
>pytanie tylko - która.

[20] innym z problemów jest komunikacja między kopiami serwisu -
potrzebują one przesyłać sobie informacje i dane. Jak? Na to też mamy
patent.

[21] i kolejny - spójność danych. Nie możemy zakładać, że dane
wczytywane z różnych źródeł są w każdej chwili zgodne i serwisy nie
powinny padać, jeżeli tak nie jest.

[22] i ostatni aspekt - mimo że Googlowe serwisy same z siebie nie padają,
projektujemy je tak, żeby wytrzymywały i robiły sensowne rzeczy,
jeżeli padną te, na których one zależą - np ich źródła danych.

[23] - podsumowanie ciekawych problemów, pojawiających się w systemach
rozproszonych.

[24] koniec.