Upgrade to Pro — share decks privately, control downloads, hide ads and more …

WJUG 2017: 4 lata rewolucji mikrousługowej w Allegro

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.

7f1dfa02fd3771699d5bac40fc54a21c?s=128

Mateusz Gajewski

May 09, 2017
Tweet

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
  7. None
  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?
  10. None
  11. None
  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…

  14. None
  15. None
  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
  17. None
  18. None
  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
  22. None
  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?

  25. None
  26. None
  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 ;)
  30. None
  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)