4 lata rewolucji mikrousługowej w Allegro

W prezentacji przedstawiam aktualną (na 2017 rok) mikrousługową architekturę Allegro.

Transcript

1. 4 lata rewolucji mikrousługowej
 czyli jak w 2017 roku tworzymy usługi w Allegro Mateusz “Serafin” Gajewski (@wendigo) 4developers, 03.04.2017
2. Krótko o mnie • w Allegro od 111b lat… • w rolach programisty, Incident Managera, 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 mikroserwisy? • Jak dzisiaj wygląda budowanie nowych usług. • Wnioski - słowem: “czy było warto”? O czym dzisiaj
4. • Allegro powstaje w 1999 roku… • a wraz z nim monolit zwany Qeppo (PHP), • który w 2012 roku osiąga masę 12M LoC, • próby jego ratowania zakończyły się porażką, • rewolucja architektoniczna 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: Right design at X may be very wrong at 10X or 100X
9. • potrzeba szybszego developmentu dla 50+ zespołów, • potrzeba niezależnego skalowania poszczególnych części platformy, • potrzeba większej odporności platformy na awarie, • potrzeba przejścia na nowe technologie (JVM), • potrzeba zoptymalizowania kosztów utrzymania, • architektura na kolejne kilka(naście) lat rozwoju Allegro. Dlaczego SOA?
12. Dzień z życia nowej mikrousługi z perspektywy “nowego” developera Allegro…
15. • repozytorium git z kodem z zainicjalizowanego szablonu, • plany CI/CD (testowanie, artefakty, wdrożenie), • dashboardy z logami (Kibana) • dashboardy z metrykami (Graphite + Grafana), • “czujki” w systemach monitorujących, • polityki eskalacji w PagerDuty, • profil usługi w katalogu usług, • wdrożenie na środowisko developerskie :) Nowa usługa generuje
18. • 400+ 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
19. Łatwiejsza część…
 czyli kodowanie ;)
20. • 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
22. • Hermes (rozproszony pub/sub) w sercu platformy Allegro, • każda usługa może opublikować zdarzenia, • każda usługa może skonsumować dowolne inne zdarzenie, • każde zdarzenie ma swój schemat, • wszystkie zdarzenia dostępne są do analityki offline. Orchiestracja usług
23. Wdróżmy coś produkcyjnie
 co może pójść nie tak?
26. • 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 marcu: • 1421 (prod), • 3277 (test), • 3218 (dev) • 43 wdrożenia na godzinę (co 1min 20s) Mesos/Marathon w liczbach
27. • ogromna zmienność środowiska: • częsta zmiana lokalizacji usług, • częsta zmiana wersji, • integracja wszystkich usług ze sobą, • wiele zintegrowanych ze sobą systemów, • asynchroniczność wielu procesów (np. wpinanie do LB) Wyzwania na tym etapie
28. A gdy pójdzie coś nie tak…
 w końcu testujemy na produkcji ;)
30. • 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
31. • ~ 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
32. Co dalej?
 świat na produkcji się nie kończy
33. • 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
34. Podsumowując nie ma lekko :)
35. • “ż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
36. • zmiana struktury organizacji, • ogromna inwestycja w pozyskanie nowych technologii, • automatyzacja większości procesów, • zbudowanie szeregu 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
37. Czy warto? Oczywiście ale nie każdą firmę na to stać
38. • nowa mikrousługa na środowisku produkcyjnym w niecałe 30 minut, • szybsze realizowanie 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?
39. Dziękuję za uwagę! :) @wendigo