WJUG 2017: 4 lata rewolucji mikrousługowej w Allegro

W prezentacji przedstawiłem jak w 2017 roku wygląda rozwój mikrousług w Allegro i z jakimi wyzwaniami na co dzień się mierzymy.

Transcript

1. 4 lata rewolucji mikrousługowej
 czyli jak w 2017 roku tworzymy usługi w Allegro Mateusz “Serafin” Gajewski (@wendigo) Warsaw Java User Group, 09.05.2017
2. Krótko o mnie • w Allegro od 111b lat… • w rolach programisty, Incident Managera (ITILv3), architekta i lidera, • twórca projektu nowej architektury Allegro (a.k.a. Projekt Rubikon), • @wendigo na Twitterze, Githubie, Keybase
3. • Krótko o historii architektury w Allegro. • Dlaczego weszliśmy w architekturę usługową? • Czym jest mikrousługa wg. Allegro, • Jak dzisiaj wygląda budowanie nowych usług. • “Czy było warto?” O czym dzisiaj
4. • Allegro powstaje w 1999 roku… • a wraz z nim monolityczna aplikacja Qeppo (PHP + Oracle), • która w 2012 roku osiąga krytyczną masę 12M LoC, • próby jej ratowania zakończyły się porażką, • rewolucja była nieunikniona… Krótkie wprowadzenie do Qeppo
5. Architektura Allegro ~ 2012
6. • statyczna architektura - brak większych zmian, • kilka repozytoriów i zależności do zainstalowania, • prosty* sposób postawienia całego środowiska, • prosta* integracja zmian do wdrożenia, • prosty* do utrzymania na produkcji, • proste* śledzenie interakcji w kodzie. Praca programisty w monolicie * w stosunku do architektury mikrousługowej
8. źródło: aukcjostat.pl Jeff Dean (Google): Right design at X may be very wrong at 10X or 100X
9. • potrzeba szybszego developmentu dla 50+ zwinnych zespołów, • potrzeba niezależnego skalowania poszczególnych części platformy, • potrzeba większej odporności platformy na awarie, • potrzeba przejścia na nowocześniejsze technologie (JVM), • potrzeba zoptymalizowania kosztów utrzymania i rozwoju, • architektura na kolejne kilka(naście) lat rozwoju Allegro. Dlaczego SOA?
12. • niezależa aplikacja, • niezależnie wersjonowana, • niezależnie wdrażana, • uruchomiona w dedykowanych i izolowanych zasobach, • z niezależnym, izolowanym źródłem danych, • ukrywająca swoją implementację za wystawionym API. Definicja mikrousługi w Allegro 12
13. Dzień z życia nowej mikrousługi z perspektywy “nowego” developera Allegro…
16. • repozytorium git z kodem z zainicjalizowanego szablonu, • plany CI/CD (testowanie, wersjonowanie i wdrażanie usługi), • dashboardy z logami aplikacyjnymi (Kibana) • dashboardy z metrykami technicznymi i biznesowymi (Graphite + Grafana), • “czujki” w systemach monitorujących, • polityki dyżurowania i eskalacji w PagerDuty, • profil usługi w katalogu usług, • wdrożenie na środowisko developerskie :) Nowa usługa generuje
19. • 450+ mikrousług w katalogu usług i konsoli AppEngine, • 7 tys. repozytoriów z kodem, • 11 tys. planów CI/CD, • 100 Gb kodu źródłowego, • 2 mln artefaktów o łącznej wielkości 5 TB (po kompresji). Wyzwania na tym etapie
20. Łatwiejsza część…
 czyli kodowanie ;)
21. • jak inne usługi mnie mogą skonsumować? • jak ja mogę skonsumować inne usługi? • jak mogę wystawić swoje API na zewnątrz? • jak mogę siebie zabezpieczyć przed innymi usługami? • jak mnie później debuggować? • jak być spójnym z całą resztą architektury? Interakcja nowej usługi z innymi usługami
23. • Hermes (rozproszony pub/sub) w sercu platformy Allegro, • każda usługa może opublikować zdarzenie, • każda usługa może skonsumować dowolne inne zdarzenie, • każde zdarzenie ma swój wersjonowany schemat, • wszystkie zdarzenia dostępne są do analityki offline. Orchiestracja usług
24. Wdróżmy coś produkcyjnie
 co może pójść nie tak?
27. • prod: 3500 CPU, 6.5 TB pamięci, 1500 kontenerów, • test: 512 CPU, 1 TB pamięci RAM, 500 kontenerów, • dev: 1200 CPU, 2 TB pamięci RAM, 2200 kontenerów, • wdrożenia produkcyjne w kwietniu: • 1341 (prod), • 2899 (test), • 2775 (dev) • 46 wdrożenia na godzinę (co 1min 18s) Mesos/Marathon w liczbach
28. • ogromna zmienność środowiska: • częsta zmiana lokalizacji usług, • częsta zmiana wersji, • integracja wszystkich usług ze sobą, • wiele zintegrowanych ze sobą, zależnych systemów, • asynchroniczność wielu procesów (np. wpinanie do LB) Wyzwania na tym etapie
29. A gdy pójdzie coś nie tak…
 w końcu testujemy na produkcji ;)
31. • health checki (Marathon, Consul), • statystyki kontenerów, • metryki aplikacji (Graphite) + czujki na nich (Alamo), • trace’y (Zipkin)*, • logi aplikacji + czujki na nich (Sentry), • monitoring frontendu (Appdex), • automatyzacja obsługi incydentów (Pagerduty). Monitoring mikrousług * niestety jeszcze nie produkcyjne ze względu na ilość danych
32. • ~ 9.7 mln metryk na minutę, • ~ 60 GB logów na minutę, • aktualność parametrów czujek, • usługi bez właścicielstwa, • przekazywanie właścicielstwa usług (kto jest odpowiedzialny?), • domeny awarii i efekt domina, • testowanie HA (Chaos Monkey, Chaos Gorilla), • integracja wielu źródeł danych o stanie usługi. Wyzwania na tym etapie
33. Co dalej?
 świat na produkcji się nie kończy
34. • bezpieczeństwo danych i przetwarzania (!!!), • zarządzanie danymi (właścicielstwo, jakość, dostępność) oraz analityka BigData, • (de)duplikacja usług, • mierzenie kosztów poszczególnych usług. Dalsze wyzwania w świecie mikrousług
35. Podsumowując nie ma lekko :)
36. • “żyjąca” architektura - wszystko ciągle się zmienia :) • rozbudowany katalog usług, repozytoriów, planów i projektów, • niemożliwość postawienia systemu w całości na laptopie, • trudność w integracji całego systemu, • trudność w zachowaniu spójności systemu, • trudność w zrozumieniu interakcji między usługami. Praca programisty w świecie mikrousługowym
37. • zmiana struktury organizacji, • rewolucja devopsowa, • ogromna inwestycja w pozyskanie nowych technologii, • automatyzacja większości procesów, • koszt zbudowania wyspecjalizowanych systemów, • chwilowe “spowolnienie” rozwoju funkcjonalności biznesowych, • pozyskanie nowych, trudnych do zdobycia na rynku kompetencji, • zmiana “mindsetu” inżyniera. Koszt poniesiony przez Allegro
38. Czy warto? Oczywiście ale nie każdą firmę na to stać
39. • nowa mikrousługa na środowisku produkcyjnym w niecałe 30 minut, • szybsze wdrażanie pomysłów biznesu, • mniejsze niestabilności i awarie - większa dostępność, • większa odpowiedzialność zespołów za to co wytwarzają, • dokładne mierzenie kosztów usług, • szybsza ewolucja nowej architektury i możliwa wymiany jej komponentów, • nowy “mindset” inżyniera - “da się” - architektura nie jest ograniczeniem. Co udało się osiągnąć w 4 lata?
40. Dziękuję za uwagę! :) @wendigo
41. Join Allegro: Software Test Engineer (http://bit.ly/alletester) Software Engineer (http://bit.ly/allejava)