Od křehkosti k odolnosti (Microservices 2017, Praha)
•0 likes•463 views
Download to read offline
Report
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.
Recommended
More Related Content
Similar to Od křehkosti k odolnosti (Microservices 2017, Praha)
Similar to Od křehkosti k odolnosti (Microservices 2017, Praha)(8)
Od křehkosti k odolnosti (Microservices 2017, Praha)
- 1. Křehký → Odolný Microservices konference, Praha 2017 Michal Táborský, CTO Mall Group
- 2. Everything fails all the time —Werner Vogels (CTO Amazon)
- 3. Co se může pokazit… … to se taky pokazí 1
- 4. 4 úrovně odolnosti systému ▪Křehký (Fragile) ▪Robustní (Robust) ▪Odolný (Resilient) ▪Antifragilní (Anti-fragile)
- 6. Skupiny chyb ▪Síťové chyby ▪Pomalá odezva ▪Zaseknutí ▪Sémantické chyby
- 7. 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
- 8. Monitoring Monitoring a logování jsou nezbytné funkční požadavky každé microservice
- 9. Obrana Jak se vyrovnat s krutostí světa počítačů 2
- 10. Redundance
- 12. Vzor „Závod“ Pošlu požadavek rovnou na více instancí a čekám kdo se ozve dříve
- 13. Caching ▪ Snížení zátěže ▪ Ochrana zdroje ▪ Poslední záchrana
- 14. Vzor „Pojistka“ ▪ Detekce výpadku ▪ „Fail fast“ ▪ Nahození
- 15. Protitlak / Přepážka Naučte se říkat „ne“ ▪ Fronty ▪ Thread pools
- 16. Vítáme chaos Když něco bolí, dělejte to co nejčastěji 3
- 17. Testování ▪ Unit testy ▪ Regresní testy ▪ Integrační testy ▪ Akceptační testy ▪ …
- 18. „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/
- 20. „Game day“ cvičení ▪ Transparentnost ▪ kill -9 ▪ rm –rf / ▪ Vypojení kabelu
- 21. Chaos monkey ▪ „Every day is game day“ ▪ Netflix Simian Army ▪ Saboteur
- 22. Vstřikování chyb ▪ „Kanárek“ ▪ Generování chyb ▪ Náhodná latence
- 23. Rekapitulace ▪ „Trust no one“ ▪ Bez monitoringu nelze zlepšovat ▪ Redundance, Timeouty, Cache, Pojistky ▪ Chaos problémy nezpůsobuje, jen odhaluje
- 24. 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