Návrh pro samoopravení

Navrhněte svou aplikaci tak, aby se v případě chyby mohla sama opravit.

V distribuovaném systému se musí očekávat selhání. Může selhat hardware. Síť může mít přechodné výpadky. Jen zřídka dojde k přerušení celé služby, datacentra nebo dokonce oblasti Azure, ale i ty musí být navržené pro vaši architekturu úloh. Odolnost a obnovení by se měly řešit v rané fázi návrhu úloh.

Proto navrhněte aplikaci, která je samoopravená, když dojde k selháním. To vyžaduje přístup založený na třech aspektech:

• Zjišťování chyb
• Přiměřená reakce na chyby
• Protokolování a monitorování selhání za účelem poskytnutí provozního přehledu

Způsob reakce na konkrétní typ selhání závisí na požadavcích vaší aplikace na dostupnost. Pokud například požadujete vysokou dostupnost, můžete ji nasadit do několika zón dostupnosti v oblasti. Abyste se vyhnuli výpadkům, a to i v nepravděpodobném případě, že dojde k přerušení celé oblasti Azure, můžete při výpadku oblasti automaticky převzít služby při selhání sekundární oblasti. To ale bude mít vyšší náklady a potenciálně nižší výkon než nasazení v jedné oblasti.

Neuvažujte jen o velkých událostech, jako jsou regionální výpadky, které jsou obecně výjimečné. Měli byste se také (a možná víc) zaměřit na zpracování místních, krátkodobých selhání, jako je například selhání připojení k síti nebo k databázi.

Doporučení

Používejte oddělené komponenty, které komunikují asynchronně. V ideálním případě jsou komponenty oddělené z hlediska času a prostoru. Oddělení v čase znamená, že komponenty nemusí být přítomny ve stejnou dobu, aby bylo možné komunikovat. Oddělení v prostoru znamená, že odesílatel a příjemce nemusí běžet ve stejném procesu, ale může to být všude, kde je efektivnější. Oddělené komponenty ideálně používají události ke vzájemné komunikaci. To pomáhá minimalizovat pravděpodobnost kaskádových selhání.

Opakujte neúspěšné operace. K přechodným selháním může dojít kvůli momentální ztrátě připojení k síti, ukončenému připojení k databázi nebo vypršení časového limitu, když je služba zaneprázdněná. Vložte do své aplikace logiku opakovaných pokusů pro zpracování přechodných selhání. Pro řadou služeb Azure klientská sada SDK implementuje automatická opakování. Další informace najdete v tématu Zpracování přechodných chyb a vzor opakování.

Chraňte selhávající vzdálené služby (jistič). Je vhodné po přechodném selhání pokus opakovat, ale pokud chyba přetrvává, můžete skončit tak, že velké množství volajících bombarduje selhávající službu. To může vést k kaskádým selháním při zálohování požadavků. Pokud je pravděpodobné, že operace selže, použijte model Jistič k rychlému selhání (bez vzdáleného volání).

Izolujte důležité prostředky (Bulkhead). Selhání v jednom subsystému se můžou někdy kaskádově přenést. K tomu může dojít v případě, že selhání způsobí, že některé prostředky, jako jsou vlákna nebo sokety, nebudou uvolněny včas, což vede k vyčerpání prostředků. Abyste tomu předešli, pomocí modelu Bulkhead rozdělte systém do izolovaných skupin tak, aby selhání v jednom oddílu nepřinesl celý systém.

Provádějte vyrovnávání zátěže. U aplikací může docházet k náhlému nárůstu provozu, který může zahltit služby na back-endu. Abyste tomu předešli, použijte model vyrovnávání zatížení založený na frontě k asynchronnímu spuštění pracovních položek ve frontě. Fronta funguje jako vyrovnávací paměť, která vyrovnává provozní špičky.

Provádějte převzetí služeb při selhání. Pokud je instance nedostupná, proveďte převzetí služeb při selhání jinou instancí. U věcí, které jsou bezstavové, jako je webový server, umístěte několik instancí za nástroj pro vyrovnávání zatížení nebo správce provozu. U věcí, které ukládají stav, jako jsou databáze, použijte repliky a převzetí služeb při selhání. V závislosti na úložišti dat a způsobu replikace může aplikace řešit konečnou konzistenci.

Kompenzujte nezdařené transakce. Obecně se vyhýbejte distribuovaným transakcím, protože vyžadují koordinaci v rámci služeb a prostředků. Místo toho tvořte operace z menších jednotlivých transakcí. Pokud se operace nezdaří ve své polovině, použijte kompenzaci transakcí, abyste vrátili všechny dokončené kroky.

Vytvářejte kontrolní body dlouhotrvajících transakcí. Kontrolní body můžou poskytovat odolnost, pokud dojde k selhání dlouhotrvajících operací. Při restartování operace (například když ji převezme jiný virtuální počítač) ji jde obnovit od posledního kontrolního bodu. Zvažte implementaci mechanismu, který zaznamenává informace o stavu úlohy v pravidelných intervalech, a uložte tento stav v trvalém úložišti, ke kterému může přistupovat libovolná instance procesu, který spouští úlohu. Tímto způsobem, pokud je proces vypnutý, lze práci, kterou prováděl, pokračovat z posledního kontrolního bodu pomocí jiné instance. Existují knihovny, které poskytují tuto funkci, jako je NServiceBus a MassTransit. Transparentně uchovávají stav, ve kterém jsou intervaly v souladu se zpracováním zpráv z front ve službě Azure Service Bus.

Snížení výkonu a udržení odezvy během selhání. V některých případech nejde problém vyřešit, ale můžete poskytovat omezenou funkčnost, která je stále užitečná. Vezměme si aplikaci, která zobrazuje katalog knih. Pokud aplikace nedokáže načíst miniatury obálek, může zobrazovat zástupné obrázky. Pro aplikaci můžou být nekritické celé subsystémy. Například na webu elektronického obchodování se zobrazením doporučení produktů je pravděpodobně méně důležité než zpracování objednávek.

Omezte klienty. Někdy malý počet uživatelů vytváří nadměrné zatížení, čímž se může omezit dostupnost vaší aplikace pro ostatní uživatele. V takovém případě klienta po určitou dobu omezte. Podívejte se na model omezování.

Blokujte nesprávně se chovající účastníky. Když klienta omezíte, neznamená to, že se klient chová závadně. Znamená to je to, že klient překročil pro službu svou kvótu. Ale pokud klient soustavně překračuje svou kvótu nebo se chová jinak nesprávně, můžete ho zablokovat. Definujte samostatný postup pro uživatele, kteří žádají o odblokování.

Používejte volbu vedoucího procesu. Pokud potřebujete úlohu koordinovat, použijte volbu vedoucího procesu a vyberte koordinátora. Tímto způsobem není koordinátor kritickým prvkem způsobujícím selhání. Pokud koordinátor selže, vybere se nový. Místo úplně nové implementace algoritmu volby vedoucího procesu zvažte možnost použít dodávané řešení, jako je Zookeeper.

Testujte vkládáním selhání. Velmi často se stává, že úspěšná cesta je dobře otestovaná, ale cesta selhání není. Systém může běžet v produkčním prostředí po dlouhou dobu, než se provede cesta selhání. Pomocí vkládání selhání otestujte odolnost systému proti chybám tak, že buď vyvoláte skutečné poruchy, nebo je budete jen simulovat.

Zapojte řízený chaos. Chaos engineering rozšiřuje pojem injektáže chyb náhodným vkládáním selhání nebo neobvyklých podmínek do produkčních instancí.

Používejte zóny dostupnosti. Řada oblastí Azure poskytuje zóny dostupnosti, které jsou izolované sady datových center v rámci oblasti. Některé služby Azure je možné nasadit zónově, což zajišťuje, že jsou umístěné v konkrétní zóně a můžou pomoct snížit latenci při komunikaci mezi komponentami ve stejné úloze. Alternativně je možné některé služby nasadit s redundancí zón, což znamená, že Azure automaticky replikuje prostředek napříč zónami kvůli zajištění vysoké dostupnosti. Zvažte, který přístup představuje nejlepší sadu kompromisů pro vaše řešení. Další informace o tom, jak navrhnout řešení tak, aby používalo zóny dostupnosti a oblasti, najdete v tématu Doporučení pro používání zón dostupnosti a oblastí.

Strukturovaný přístup k samoopravení aplikací najdete v tématu Návrh spolehlivých aplikací pro Azure.