pondělí 26. srpna 2013

Postřehy Release It!

Kniha Release It! mě nadchla. Přestože byla vydána skoro před sedmi roky (2007) obsahuje plno velmi užitečných rad a postřehů k návrhu a nasazení aplikací do provozu. Mimochodem samotný podtitul by to řekl přesněji Design and Deploy Production-Ready software. V krátkém review na GoodReads jsem napsal, že bych si přál knihu číst před třemi roky, protože by mi ušetřila pár bezesných nocí během hašení požárů na produkci.

Kniha vychází z jednoduché premisy.


Enterprise software must be cynical. Cynical software expect bad things to happen and is never surprised when they do. Cynical software doesn't even trust itself, so it puts up internal barriers to protect itself from failures. It refuses to get too intimate with other systems, because it could get hurt.

Dnešní aplikace, ty webové především, nejsou monolitické ve smyslu závislostí na dalších systémech, ale jedná se o kompozici několika služeb viz. platební systém, mailling systém apod. Pro architekturu aplikací tvořených službami se vžilo označení Service Oriented Architecture (SOA), které se bohužel později dost zprofanovalo. Bez ohledu na to, jestli se jedná o služby interní nebo externí, každá interakce s nimi představuje riziko.

Efekt sněhové koule a pavouk na skle

Představte si, že jedete po silnici a od protijedoucího vozu odlétne kamínek, který naruší vaše přední sklo. Udělá se na něm pavouk. Od jeho středu se šíří praskliny do všech směrů. Když máte štěstí, můžete s tím ještě dojet do servisu. V opačném případě se vám celé sklo vysype a vy můžete auto v nejlepším odstavit a počkat na odtahovou službu.

V životě software máte jenom jednu jistotu: Bugs will happen. They cannot be eliminated, so they must be survived instead. Díky tomu, že architektura aplikací se změnila ve prospěch kompozice služeb, se chyba v jedné ze služeb může velmi rychle rozšířit do služby jiné a vést řetězové reakci v podobě efektu sněhové koule.

The biggest issues stat with something very small. A tiny programming error starts the snowball rolling downhill. As it gains momentum, the scale of the problem keeps getting bigger and bigger.

Šíření chyb jedné služby do jiné v rámci systému se nazývá Failure modes. Platí pravidlo, že selhání v jedné části systému zvyšuje pravděpodobnost selhání jiné části systému. To vše se umocňuje komplexitou systému, která způsobuje že dané selhání se může šířit mnoha směry.

The original trigger and the way the crack spreads to the rest of the system, together with the result of the damage, are collectively called a failure mode.
No matter what, your system will have variety of failure modes. Denying the inevitability of failures robs you of your power to control and contain them.

Once you accept that failures will happen, you have ability to design your system's reaction to specific failures

Stabilita

Stabilita je schopnost systému odolávat selháním/chybám v jeho jednotlivých částech. Selhání vznikají z impulzů a ty vedou k přetížení jednotlivých částí systémů. Představte si, že vaše marketingové oddělení dalo k dispozici slevový kupon na nedostatkové zboží nebo, že jste se dostali na titulní stranu serveru typu Slashdot. Náhlá horda uživatelů, která se na vaší aplikaci nahrne způsobí přetížení části systému, které může vést k jeho selhání. To se potom může šířit libovolnými směry.
V knize jsou popsané antivzory způsobující snížení stability systému a vzory působící naopak na její posílení.



Circuit breaker

Jako příklad vzorů zlepšujícího stabilitu jsem si vybral Circuit breaker (jistič). Podle něj je totiž navržena knihovna Hystrix (doporučuji vaší pozornosti). Místu, kde se aplikace integruje s jinou službou se nazývá integration point. Právě v tomto místě se selhání volané služby akcelerují (cascading failures) a propagují dále nebo se zde zastaví. Circuit breaker je komponenta, která se používá v integračních bodech, aby šíření selhání zabránila.
Circuit breaker je v podstatě proxy, která má tři stavy (polohy) regulující volání dané služby.

  • zavřený - požadavky jdou skrz, v případě chyby se zvýší failure counter a při dosažení určité hranice dojde k přepnutí do stavu otevřeno
  • otevřeno - požadavky se neprovádějí, volající dostává ihned informaci, že volání není možné provést (umožňuje fail fast), po dosažení timeoutu dochází k přepnutí do stavu zkušební provoz
  • zkušební provoz - požadavky se pustí skrz, pokud projdou, zresetuje se failure counter a přejde se do stavu zavřeno. V opačném případě dochází zpět k přechodu do stavu otevřeno.

Aby mohl Circuit breaker správně fungovat, je nutné použít izolovaný thread pool a samozřejmě timeouty, aby nedocházelo k blokujícím vláknům.

Nasazení a transparentnost

Jednou ze základních vlastností, kterou by měl systém splňovat při nasazení do produkce, je transparentnost. Vývojáři často věří, že jejich práce končí ve chvíli, kdy proběhne code review a nebo proběhne formální předání oddělení kvality. Nic není vzdálenější realitě.

The true birth of a system comes not on the day that design and development begins or even when the project is conceived, but on the day it launches into production.

Transparentnost systému je především viditelnost a to na několika úrovních. Globální stav systému by měl umožnit komukoliv získat přehled o aktuální kondici systému. V knize se hovoří o dashboardu s jednoduchým semaforem (červena, oranžová zelená), který jednoduše vyjadřuje aktualní stav. V rámci tohoto stavu se monitorují a vyhodnocují následující atributy.

  • Očekávané události v aplikaci nastaly/nenastaly např. zálohy, garbage collection
  • Nastala/Nenastala nějaká neočekávaná událost např. pád serveru
  • Stav komponent/služeb aplikace např. stav Circuit breaker
  • Všechny sledované parametry jsou/nejsou v normálu

Kromě toho by měl existovat dashboard/nástroj zobrazující detailnější stav tj. přehled na nižší úrovni systému. To je typicky realizované přímým sledováním monitorovacích prostředků např. logů. Na rozdíl od Globálního stavu tento přehled slouží k řešení aktuálních problémů (troubleshooting). My za tímto účelem používáme Splunk.


Without transparency the system will drift into decay functioning a bit worse with each release.

Systems can mature well if and only if they have some degree of transparency.

Anomalies and events can remain forever mysterious or they can be valuable lessons learned. Transparency makes difference between a system that improves over time in production and one that stagnates or decays.

Technologie/Nástroje a monitorování

Existují dva přístupy k monitorování takzvaný white-box a black-box, které se liší tím jestli fungují vně a nebo uvnitř monitorovaného systému.

  • white-box monitoring je nasazen uvnitř sledovaného systému a typicky se jedná o logování.
  • black-box monitoring je nasazeny mimo sledovaný systém. Většinou se jedná o proces, který "olizuje" sledovaný systém.

Možná si pokládáte otázku, proč nestačí logy. Pokud vám sledovaný systém takzvaně zatuhne, pak neprodukuje většinou ani žádné logy. Black-box monitoring může poskytnout alespoň nějaké informace např. vytížení CPU, RAM, IO operace síť, chování garbage collectoru v JVM, které mohou pomoci při průzkumu toho co se děje.


Pro JVM je základním nástrojem pro monitoring JMX. Pokud jste tuto technologie nikdy nepoužily nebo o ní moc nevíte, doporučoval bych vám se na ní podívat. Kromě monitoringu se používá i pro management. Vystavení jednotlivých komponent aplikace přes JMX umožňuje jejich dynamickou správu. My pomocí této technologie za běhu aplikace měníme úrovně logování, provádíme health checky a nebo nastavujeme sizing jednotlivých thread poolu. Mimochodem schopnost restartovat jednotlivé komponenty a služby aplikace namísto restartů celých serverů je jedním z požadavků Recovery-oriented computingu.
Co se týká vlastních atributů, které je dobré monitorovat a tedy vystavit přes JMX a nebo jinou technologii, kterou používáte.

  • Stav/Zdraví integration points (počet chyb)
  • Indikátor provozu (počet požadavků, jejich trvání, velikost dat)
  • Stav resource poolu (počet aktivních/idle vláken, maximální počet vláken, doba čekání na vlákno)
  • Stav databázového connection poolu (počet aktivních/idle spojení, maximální počet spojení, doba čekání na spojení)
  • Stac cache - hit/miss poměr, zaplněné jednotlivých regionů, počet/velikost objektů

Rekapitulace

Samozřejmě se mi do jednoho článku nemůže povést vměstnat všechny moudra, která jsou v knize obsažena. Kniha se dost obšírně věnuje oblasti kapacity a jejího plánování a nebo SLA samostatné aplikace a vlivu externích služeb na SLA. Není ani pochyb o tom, že bych knihu doporučoval k přečtení. Nicméně bych případného čtenáře rád varoval před tím, že její některé části jsou více orientované na svět Javy - tunning a chování GC. Nečekejte, že v knize najdete informace týkající se provozu a nasazení v rámci cloudu. Kniha mi přišla na dobu vídáni pionýrská v tom, že akcentovala některé myšlenky na nichž je postavený celý DevOps.


Don't avoid one-time development expenses at the cost of recurring operational expenses.


You early decisions make the biggest impact on the eventual shape of your system. The earliest decision you make can be the hardest one to reverse later.


K dobru přidávám ještě mind mapu mých poznámek.