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

4 lata rewolucji mikrousługowej w Allegro

4 lata rewolucji mikrousługowej w Allegro

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

7f1dfa02fd3771699d5bac40fc54a21c?s=128

Mateusz Gajewski

April 03, 2017
Tweet

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
  7. None
  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?
  10. None
  11. None
  12. Dzień z życia nowej mikrousługi z perspektywy “nowego” developera Allegro…

  13. None
  14. None
  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
  16. None
  17. None
  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
  21. None
  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?

  24. None
  25. None
  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 ;)
  29. None
  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

  40. None