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.
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
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/
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