Successfully reported this slideshow.
Your SlideShare is downloading. ×

Od křehkosti k odolnosti (Microservices 2017, Praha)

Loading in …3
×

Check these out next

1 of 24 Ad
1 of 24 Ad

Od křehkosti k odolnosti (Microservices 2017, Praha)

Download to read offline

Pokud problém v jedné Microservice způsobí, že se celá vaše aplikace zastaví, nemáte Microservices architekturu, ale distribuovaný monolit. Což je ještě horší, než mít monolit na jednom místě. Co všechno se může při provozu stát? Jak se s tím vyrovnat? Jak přijmout chaos a udělat z něj svého přítele? To jsou otázky, na které se pokusím odpovědět v této přednášce zaměřené na to ošklivé, co vás může při cestě k Microservices potkat.

Pokud problém v jedné Microservice způsobí, že se celá vaše aplikace zastaví, nemáte Microservices architekturu, ale distribuovaný monolit. Což je ještě horší, než mít monolit na jednom místě. Co všechno se může při provozu stát? Jak se s tím vyrovnat? Jak přijmout chaos a udělat z něj svého přítele? To jsou otázky, na které se pokusím odpovědět v této přednášce zaměřené na to ošklivé, co vás může při cestě k Microservices potkat.

Advertisement
Advertisement

More Related Content

Advertisement

Od křehkosti k odolnosti (Microservices 2017, Praha)

  1. 1. Křehký → Odolný Microservices konference, Praha 2017 Michal Táborský, CTO Mall Group
  2. 2. Everything fails all the time —Werner Vogels (CTO Amazon)
  3. 3. Co se může pokazit… … to se taky pokazí 1
  4. 4. 4 úrovně odolnosti systému ▪Křehký (Fragile) ▪Robustní (Robust) ▪Odolný (Resilient) ▪Antifragilní (Anti-fragile)
  5. 5. Skupiny chyb ▪Síťové chyby ▪Pomalá odezva ▪Zaseknutí ▪Sémantické chyby
  6. 6. Kaskádové chyby 1. Vypadne jeden uzel clusteru 2. Ostatní uzly přeberou jeho práci 3. Celý cluster se zpomalí 4. Dojdou worker procesy na aplikačním serveru
  7. 7. Monitoring Monitoring a logování jsou nezbytné funkční požadavky každé microservice
  8. 8. Obrana Jak se vyrovnat s krutostí světa počítačů 2
  9. 9. Redundance
  10. 10. Timeout ▪ Connection ▪ Socket
  11. 11. Vzor „Závod“ Pošlu požadavek rovnou na více instancí a čekám kdo se ozve dříve
  12. 12. Caching ▪ Snížení zátěže ▪ Ochrana zdroje ▪ Poslední záchrana
  13. 13. Vzor „Pojistka“ ▪ Detekce výpadku ▪ „Fail fast“ ▪ Nahození
  14. 14. Protitlak / Přepážka Naučte se říkat „ne“ ▪ Fronty ▪ Thread pools
  15. 15. Vítáme chaos Když něco bolí, dělejte to co nejčastěji 3
  16. 16. Testování ▪ Unit testy ▪ Regresní testy ▪ Integrační testy ▪ Akceptační testy ▪ …
  17. 17. „Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production“ http://principlesofchaos.org/
  18. 18. „Game day“ cvičení ▪ Transparentnost ▪ kill -9 ▪ rm –rf / ▪ Vypojení kabelu
  19. 19. Chaos monkey ▪ „Every day is game day“ ▪ Netflix Simian Army ▪ Saboteur
  20. 20. Vstřikování chyb ▪ „Kanárek“ ▪ Generování chyb ▪ Náhodná latence
  21. 21. Rekapitulace ▪ „Trust no one“ ▪ Bez monitoringu nelze zlepšovat ▪ Redundance, Timeouty, Cache, Pojistky ▪ Chaos problémy nezpůsobuje, jen odhaluje
  22. 22. Díky! Otázky? @whizz michal.taborsky@mall.cz PS: Pro MallGroup hledáme vývojáře!

Editor's Notes

  • Síťové chyby – není vůbec dostupná, packet loss, rozpojení (split brain)
  • Snadná záměna příčiny a důsledku
  • Nesnažit se optimalizovat MTBF (Mean time between failure)
    Minimalizovat MTTR (Mean time to recovery)
  • Je lepší rychle skončit s chybou
    Pokud to jde, je možné odpovědět „zařazeno do fronty“
    Je potřeba rychle zkusit znovu
  • Nižší efektivita
    Vhodné pro kritické komponenty
    Buď read-only nebo idempotentní operace
  • Použiju cachovanou verzi i když už vypršela
    Obecně – co zlepšuje performance zlepšuje spolehlivost
  • Counter chyb, který se resetuje při úspěšném volání
    https://martinfowler.com/bliki/CircuitBreaker.html
    Nahození – po timeoutu, nebo náhodně
    exponential backoff
  • Backpressure – bráním se tomu co mě zabije, sebezáchova
    Je potřeba znát limity – počty procesů, threadů atd.
    Cílem není je všechny odstranit
    Fronty pomáhají zvládat nárazy
    Rate limiting v API
    Pomáhá s kaskádovými chybami
  • Netflix – pionýři
    Vycházím ze stabilního stavu,
    rozdělím na kontrolní a zkušební skupinu
    Hypotéza – budou se chovat stejně
    Ve zkušební skupině zavedu nestabilitu
  • Bez monitoringu to nemá cenu
    Potřebuju vědět a znát, co je normální stav
    Koukat na metriky když je vše OK
  • Nemá testovat něco, o čem víme že nebude fungovat
    Kill procesů
    Kill serverů
    Všichni o tom ví a jsou na to připraveni
    V první fázi je dobré to dělat na testu, ale produkce má svá specifika a je potřeba to dělat i tam


  • Je potřeba mít na to kulturu
    Komunikace
    Běžet pouze když jsou všichni v práci
    Speciální scénáře pro další komponenty
  • Záměrné zavádění chybových stavů do zdravého systému
    Sandbox prostředí
    Vyčleněná instance
    Náhodně vracím chybové stavy
  • Předpokládejte, že co se může pokazit se pokazí
    Monitoring, logy a metriky

×