Zpracování přechodných chyb
Všechny aplikace, které komunikují se vzdálenými službami a prostředky, musí být citlivé na přechodné chyby. Toto se týká hlavně aplikací, které běží v cloudu, kde povaha prostředí a připojení přes internet znamená, že je možný výskyt těchto typů chyb častější. K přechodným chybám patří momentální ztráta síťového připojení ke komponentám a službám, dočasná nedostupnost služby nebo vypršení časových limitů, ke kterému dochází, když je služba přetížená. Tyto chyby se často opravují sama, a pokud se akce opakuje po vhodné prodlevě, je pravděpodobné, že bude úspěšná.
Tento dokument popisuje obecné pokyny pro zpracování přechodných chyb. Informace o zpracování přechodných chyb při použití služeb Microsoft Azure najdete v pokynech k opakování specifických pro služby Azure.
Proč dochází k přechodným chybám v cloudu?
Přechodné chyby můžou nastat v jakémkoli prostředí, na všech platformách a operačních systémech a v jakékoliv aplikaci. V řešeních, která běží na místní infrastruktuře, se výkon a dostupnost aplikace a jejích komponent obvykle udržují prostřednictvím nákladné a často podušené hardwarové redundance a komponenty a prostředky jsou umístěné blízko sebe. I když je tento přístup méně pravděpodobný, může i tak vést k přechodným chybám – a dokonce i k výpadku při nepředvídatelných událostech, jako jsou problémy s externím zdrojem napájení nebo sítí nebo jiné scénáře havárie.
Hostování cloudu, včetně systémů privátního cloudu, může nabízet vyšší celkovou dostupnost pomocí sdílených prostředků, redundance, automatického převzetí služeb při selhání a dynamického přidělování prostředků napříč mnoha komoditním výpočetními uzly. Povaha těchto prostředí ale může znamenat, že jsou přechodné chyby pravděpodobnější. Tady je několik důvodů:
Mnoho prostředků v cloudovém prostředí se sdílí a přístup k nim podléhá omezování z důvodu ochrany prostředku. Některé služby odmítnou připojení, pokud zatížení přeroste konkrétní úroveň, nebo je dosaženo maximální propustnosti, aby bylo možné povolit zpracování existujících žádostí a zachovat výkon služby pro všechny uživatele. Omezování pomáhá udržovat kvalitu služby pro okolí a jiné tenanty používající sdílený prostředek.
Cloudová prostředí jsou vytvořená pomocí velkého množství komoditních hardwarových jednotek. Poskytují výkon dynamickým rozdělováním zatížení mezi víc výpočetních jednotek a komponent infrastruktury a zaručují spolehlivost automatickou recyklací nebo náhradou selhávajících jednotek. Tato dynamická povaha znamená, že přechodné chyby a dočasná selhání připojení můžou občas nastat.
Mezi aplikací a využívanými prostředky a službami existují často další hardwarové komponenty, včetně síťové infrastruktury, jako jsou například routery a nástroje pro vyrovnávání zatížení. Tato další infrastruktura může příležitostně přidávat další latenci připojení a přechodné chyby připojení.
Podmínky v síti mezi klientem a serverem se můžou měnit, zejména v případě, že komunikace prochází internetem. I v místních umístěních může velké zatížení provozu zpomalit komunikaci a způsobit přerušované selhání připojení.
Výzvy
Přechodné chyby mohou mít velký vliv na vnímanou dostupnost aplikace, i když byla důkladně otestována za všech předvídatelných okolností. Aby se zajistilo, že aplikace hostované v cloudu fungují spolehlivě, musí být schopné reagovat na následující problémy:
Aplikace musí být schopna zjistit chyby při jejich výskytu a určit, zda tyto chyby jsou pravděpodobně přechodné, déletrvající, nebo se jedná o fatální selhání. Různé prostředky můžou při chybě vracet různé odezvy a tyto odezvy se můžou lišit v závislosti na kontextu operace. Odezva na chybu při čtení z úložiště může být například jiná než odezva na chybu při zápisu do úložiště. Mnoho prostředků a služeb má dobře dokumentované kontrakty přechodných chyb. Ale pokud nejsou takové informace k dispozici, může být obtížné zjistit povahu chyby, a zda je pravděpodobně přechodná.
Aplikace musí být schopná operaci zopakovat, pokud určí, že chyba je pravděpodobně přechodná, a sledovat počet opakování operace.
Aplikace musí používat vhodnou strategii pro opakované pokusy. Tato strategie určuje počet opakovaných pokusů, zpoždění mezi jednotlivými pokusy a akce, které se provedou po neúspěšném pokusu. Odpovídající počet pokusů a zpoždění mezi nimi je často obtížné určit a liší se v závislosti na typu prostředku i aktuálních provozních podmínkách prostředku a vlastní aplikace.
Obecné pokyny
Následující pokyny vám pomůžou navrhnout vhodný mechanismus zpracování přechodných chyb pro vaše aplikace:
Zjištění, jestli existuje integrovaný mechanismus opakovaní:
Mnoho služeb poskytuje sadu SDK nebo klientskou knihovnu, která obsahuje mechanismu pro zpracování přechodných chyb. Zásady opakovaných pokusů, které používá, jsou obvykle přizpůsobené podstatě a požadavkům cílové služby. Případně rozhraní REST pro služby může vrátit informace, které jsou užitečné při určování, zda je opakování pokusu vhodné a jak dlouho čekat před dalším pokusem.
Pokud nemáte specifické a dobře pochopitelné požadavky, které udělovat vhodnější chování při opakování, použijte integrovaný mechanismus opakování tam, kde je k dispozici.
Určení, zda je operace vhodná k opakování:
Měli byste opakovat jenom operace, kde jsou chyby přechodné (obvykle určeno povahou chyby) a kde je alespoň nějaká pravděpodobnost, že operace při opakování proběhne úspěšně. Nemá žádný bod k opětovnému zpracování operací, které indikují neplatnou operaci, například aktualizaci databáze na položku, která neexistuje, nebo požadavky na službu nebo prostředek, u které došlo k závažné chybě.
Obecně platí, že byste měli implementovat opakování jenom tam, kde se dá určit úplný dopad a podmínky jsou správně pochopené a jde je ověřit. V opačném případě ponechte implementaci opakování na volajícím kódu. Nezapomeňte, že chyby vrácené z prostředků a služeb mimo vaši kontrolu se můžou v průběhu času vyvíjejí a může být nutné logiku zjišťování přechodných chyb revidovat.
Když vytváříte služby nebo komponenty, zvažte implementaci kódů chyb a zpráv, které klientům pomůžou určit, jestli mají nezdařené operace opakovat. Konkrétně indikujte, zda má klient operaci opakovat (například vrácením hodnoty isTransient), a navrhněte vhodnou prodlevu před dalším pokusem. Pokud vytváříte webovou službu, zvažte vracení vlastních chyb definovaných v rámci kontraktů vaší služby. I když obecní klienti nemusí být schopní je číst, budou užitečné při vytváření vlastních klientů.
Určení vhodného počtu opakování a intervalu:
Je důležité optimalizovat počet opakování a interval podle způsobu použití. Pokud neprovedete dostatečný počet opakování, aplikace nebude moct dokončit operaci a pravděpodobně selže. Pokud budete operaci opakovat příliš mnohokrát nebo s příliš krátkým intervalem mezi pokusy, aplikace může potenciálně držet prostředky, například vlákna, připojení nebo paměť, dlouhou dobu, což nepříznivě ovlivní stav aplikace.
Vhodné hodnoty pro časový interval a počet opakovaných pokusů závisí na typu prováděné operace. Například pokud je operace součástí interakce s uživatelem, interval by měl být krátký s pouze několika opakovanými pokusy, aby uživatelé nečekali na odpověď (což drží otevřené připojení a může snížit dostupnost pro ostatní uživatele). Pokud je operace součástí dlouhotrvajícího nebo kritického pracovního postupu, kde je zrušení a restartování procesu nákladné nebo časově náročné, je vhodné počkat mezi pokusy déle a opakovat vícekrát.
Určení vhodných intervalů mezi pokusy je nejobtížnější částí navrhování úspěšné strategie. Typické strategie používají následující typy intervalu opakování:
Exponenciální back-off. Aplikace čeká po krátkou dobu před prvním opakováním a pak exponenciálně prodlužuje časy mezi každým dalším pokusem. Může například operaci opakovat za 3 sekundy, 12 sekund, 30 sekund a tak dále.
Přírůstkové intervaly. Aplikace čeká po krátkou dobu před prvním opakováním a pak přírůstkově prodlužuje časy mezi každým dalším pokusem. Může například operaci opakovat za 3 sekundy, 7 sekund, 13 sekund a tak dále.
Pravidelné intervaly. Aplikace čeká mezi jednotlivými pokusy stejnou dobu. Například může operaci opakovat každé 3 sekundy.
Okamžité opakování. Přechodná chyba je někdy krátká, třeba kvůli události, jako je kolize síťových paketů nebo špička v hardwarové komponentě. V takovém případě je vhodné zkusit operaci znovu okamžitě, protože může být úspěšná, když došlo k vyřešení situace v době, kterou aplikaci trvá sestavit a odeslat další požadavek. Nikdy by však nemělo dojít k více než jednomu okamžitému pokusu o opakování a měli byste přepnout na alternativní strategie, jako jsou exponenciální back-off nebo záložní akce, pokud dojde k okamžitému opakování.
Randomizace. Každá z uvedených strategií opakování může zahrnovat randomizaci, aby se zabránilo více instancím klientů v odesílání následných pokusů ve stejnou dobu. Například jedna instance může operaci opakovat po 3 sekundách, 11 sekundách, 28 sekundách atd., zatímco jiná instance může operaci opakovat po 4 sekundách, 12 sekundách, 26 sekundách atd. Randomizace je užitečná technika, kterou jde kombinovat s dalšími strategiemi.
V rámci obecných pokynů používejte exponenciální regresní strategii pro operace na pozadí a strategii opakování nebo pravidelných intervalů pro interaktivní operace. V obou případech je třeba vybrat zpoždění a počet opakování tak, aby maximální latence pro všechny pokusy o opakování odpovídala požadavku na celkovou požadovanou latenci.
Vezměte v úvahu kombinaci všech faktorů, které přispívají k celkovému maximálnímu časovému limitu opakované operace. Mezi tyto faktory patří čas potřebný pro to, aby chybové připojení vytvořilo odpověď (obvykle nastaveno hodnotou časového limitu v klientovi), a také prodleva mezi pokusy a maximální počet opakování. Součet všech těchto časů může vést k dlouhé celkové době operace, zejména při použití strategie exponenciálního zpoždění, kdy interval mezi opakováními po každém selhání rychle roste. Pokud proces musí splňovat konkrétní smlouvu o úrovni služeb (SLA), celková doba provozu včetně všech časových limitů a zpoždění musí být v mezích definovaných ve smlouvě SLA.
Příliš agresivní strategie opakování, které mají příliš krátké intervaly nebo příliš časté opakování, mohou mít nežádoucí vliv na cílový prostředek nebo službu. To může bránit prostředku nebo službě zotavení ze stavu přetížení a blokování nebo odmítání žádostí bude pokračovat. Výsledkem je začarovaný kruh, kdy je prostředku nebo službě posíláno víc a víc požadavků a v důsledku toho jej schopnost zotavení ještě nižší.
Při výběru intervalů opakování vezměte v úvahu časový limit operací, aby se zabránilo spouštění následujících pokusů okamžitě (například pokud časový limit je podobný intervalu mezi opakováním). Abyste celkový čas zkrátili, zvažte také, jestli je potřeba dodržet celé možné období (časový limit plus intervaly opakování). Operace, které mají neobvykle krátký nebo velmi dlouhý časový limit, můžou ovlivnit dobu čekání i četnost opakování operace.
Použijte typ výjimky a případná obsažená data nebo kódy chyb a zprávy vrácené službou k optimalizaci intervalu a počtu opakovaných pokusů. Například některé výjimky nebo chybové kódy (například kód HTTP 503 – Služba není k dispozici s hlavičkou Retry-After v odpovědi) můžou uvádět, jak dlouho může chyba trvat nebo že služba selhala a na následné pokusy nebude reagovat.
Vyhnutí se antivzorům:
V převážné většině případů byste se měli vyhnout implementacím, které obsahují duplicitní vrstvy kódu opakování. Vyhněte se návrhům, které zahrnují kaskádové mechanismy opakování nebo které implementují opakování v každé fázi operace, která zahrnuje hierarchii požadavků, pokud nemáte konkrétní požadavky, které to vyžadují. Za těchto výjimečných okolností použijte zásady, které brání nadměrnému počtu opakovaných pokusů a období zpoždění, a ujistěte se, že chápete důsledky. Například pokud jedna komponenta odešle požadavek jiné, která pak přistupuje k cílové službě, a implementujete opakování s počtem tři pro obě volání, dojde u služby celkově k devíti pokusům o opakování. Mnoho služeb a prostředků implementuje integrovaný mechanismus opakování a měli byste prozkoumat, jak ho můžete zakázat nebo změnit, pokud potřebujete implementovat opakování na vyšší úrovni.
Nikdy implementujte mechanismus s nekonečným počtem opakování. To může bránit prostředku nebo službě v zotavení z přetížení a způsobit, že omezení a odmítání připojení pokračuje po delší dobu. Použijte konečný počet opakování nebo implementujte model jističe, aby se služba mohla zotavit.
Nikdy neprovádějte okamžité opakování víc než jednou.
Při přístupu ke službám a prostředkům v Azure nepoužívejte pravidelné intervaly opakování, zejména v případě, že máte velký počet pokusů o opakování. Optimální přístup v tomto scénáři je exponenciální regresní strategie s funkcí jističe.
Zabraňte více instancím stejného klienta nebo více instancím různých klientů v odesílání pokusů o opakování ve stejnou dobu. Pokud k tomu pravděpodobně může dojít, zaveďte do intervalů opakování randomizaci.
Testování strategie opakování a implementace:
Zajistěte otestování implementace vaší strategie opakování na nejširší možné sadě okolností, zejména v případě, že aplikace i používané cílové prostředky nebo služby jsou extrémně zatížené. Chcete-li zkontrolovat chování při testování, můžete provést následující:
Vložení přechodných a nepřechodných chyb do služby. Například odešlete neplatné požadavky nebo přidejte kód, který zjišťuje požadavky testu a odpovídá různými typy chyb. Příklad použití TestApi najdete v popisu testování vkládáním selhání pomocí TestApi a části 5 úvodu do TestApi o spravovaných rozhraních API kódu vkládání chyb.
Vytvořte model prostředku nebo služby, který vrací celou řadu chyb, které může vrátit skutečná služba. Ujistěte se, že jste zahrnuli všechny typy chyb, který má strategie opakování zjišťovat.
Vynutit přechod k přechodným chybám tím, že službu dočasně zakážete nebo převedete, pokud se jedná o vlastní službu, kterou jste vytvořili a nasadili (samozřejmě jste se nepokoušeli přetížit žádné sdílené prostředky nebo sdílené služby v rámci Azure).
Pro rozhraní API založená na protokolu HTTP zvažte použití knihovny FiddlerCore v automatizovaných testech, abyste změnili výsledky požadavků protokolu HTTP, buď přidáním delších dob odezvy, nebo změnou odpovědi (například stavového kódu protokolu HTTP, záhlaví, textu nebo jiných faktorů). To umožňuje deterministické testování podmnožiny podmínek selhání, ať už se jedná o přechodné chyby, nebo jiné typy selhání. Další informace najdete v popisu FiddlerCore. Příklady použití knihovny, zejména třídy HttpMangler, najdete ve zdrojovém kódu sady SDK Azure Storage.
Proveďte testy vysokého zatížení a souběžnosti, abyste zajistili, že mechanismus a strategie opakování funguje za těchto podmínek správně a nemá negativní vliv na činnosti klienta nebo nezpůsobuje kontaminaci mezi požadavky.
Správa konfigurací zásad opakování:
Zásady opakování jsou kombinací všech prvků strategie opakování. Definuje mechanismus detekce, který určuje, zda chyba může být přechodná, a typ použitého intervalu (například pravidelný, exponenciální regresní a randomizace), skutečné hodnoty intervalu a počet opakování.
Opakování musí být i v nejjednodušší aplikaci implementované na mnoha místech a v každé vrstvě složitějších aplikací. Místo pevného kódování prvků jednotlivých zásad v několika místech zvažte použití centrálního bodu pro ukládání všech zásad. Uložte například hodnoty intervalu a počtu opakování v konfiguračních souborech aplikace, přečtěte si je za běhu a programově vytvořte zásady opakování. To usnadňuje správu nastavení a úpravu a vyladění hodnot, aby bylo možné reagovat na měnící se požadavky a scénáře. Systém však navrhněte tak, aby hodnoty spíš ukládal, než je vždycky znovu četl z konfiguračního souboru, a ujistěte se, že se používá vhodné výchozí nastavení, pokud nelze získat hodnoty z konfigurace.
V aplikaci Azure Cloud Services zvažte uložení hodnot, které se používají k vytvoření zásady opakování za běhu v konfiguračním souboru služby, aby je bylo možné změnit bez nutnosti restartování aplikace.
Využijte integrovanou nebo výchozí strategii opakování, která je k dispozici v používaných klientských rozhraních API, ale pouze tam, kde se hodí pro váš scénář. Tyto strategie jsou obvykle všeobecně zaměřené. V některých případech mohou stačit, ale v jiných scénářích nemusí nabízet úplnou sadu možností, které by vyhovovaly konkrétním potřebám. Je potřeba pochopit, jak nastavení ovlivní vaši aplikaci prostřednictvím testování, a tak určit nejvhodnější hodnoty.
Protokolování a sledování přechodných a nepřechodných chyb:
Jako součást vaší strategie opakování přidejte zpracování výjimek a další instrumentaci, která protokoluje opakované pokusy. I když je potřeba očekávat příležitostné přechodné selhání a opakovat pokus a Neoznačovat problém, pravidelný a rostoucí počet opakovaných pokusů, často je indikátorem problému, který může způsobit selhání nebo momentálně mění výkon a dostupnost aplikace.
Protokolujte přechodné chyby spíš jako upozornění než chyby, aby systémy monitorování je nepovažovaly za chyby aplikace a neaktivovaly falešné výstrahy.
Zvažte uložení hodnoty do položky protokolu, která udává, jestli byly opakované pokusy způsobené omezením šířky pásma v rámci služby nebo jiným typem chyby, jako jsou selhání připojení, abyste je mohli během analýzy dat odlišit. Zvýšení počtu chyb omezení často slouží v aplikaci jako ukazatel problémů návrhu nebo nutnosti přechodu na službu úrovně Premium, která nabízí vyhrazený hardware.
Zvažte měření a protokolování celkového času potřebného pro operace, které zahrnují i mechanismus opakování. Toto je vhodný indikátor celkového efektu přechodných chyb na dobu odezvy pro uživatele, latenci procesu a efektivitu případů použití aplikace. Také protokolujte počet opakování, ke kterým došlo, abyste pochopili faktory, které přispívají k prodloužení doby odezvy.
Zvažte implementaci telemetrie a monitorování systému, které můžou vyvolat výstrahy, když se počet a četnost chyb, průměrný počet opakování nebo celkové doby potřebné k úspěšnému dokončení operací zvyšují.
Správa operací, které nepřetržitě selhávají:
Existují okolnosti, kdy operace soustavně při každém pokusu selhávají, a je důležité rozmyslet, jak takovou situaci obsloužíte:
I když strategie opakování definuje maximální počet pokusů, kolikrát se má operace zopakovat, nezabrání to aplikaci v dalším opakování operace se stejným počtem pokusů. Například pokud služba zpracování objednávky selže s kritickou chybou, která ji trvale vyřadí ze hry, strategie opakování může zjistit vypršení časového limitu připojení a považovat to za přechodnou chybu. Kód provede zadaný počet pokusů o opakování operace a pak to vzdá. Pokud ale další zákazník zadá objednávku, pokusy o operaci se provedou znovu, i když je jasné, že se všechny nezdaří.
Aby se zabránilo dalším opakovaným pokusům pro operace, které soustavně selhávají, zvažte implementaci modelu jističe. Když v tomto modelu překročí počet selhání v rámci zadaného časového okna prahovou hodnotu, požadavky se vrátí volajícímu okamžitě jako chyby, bez pokusu o přístup k problémovému prostředku nebo službě.
Aplikace může pravidelně testovat službu, a to občas a s dlouhými intervaly mezi požadavky, aby zjistila, kdy bude k dispozici. Odpovídající interval závisí na scénáři, jako je například závažnost operace a povaha služby, a může se jednat o pár minut až několik hodin. V okamžiku, kdy je test úspěšný, může aplikace obnovit normální provoz a předat požadavky nově zotavené službě.
Mezi tím může být možné přejít k jiné instanci služby (třeba v jiném datovém centru nebo aplikaci), použít podobnou službu, která nabízí kompatibilní (možná jednodušší) funkce, nebo provádět některé alternativní operace v naději, že služba bude brzy dostupná. Například může být vhodné ukládat požadavky na službu ve frontě nebo úložišti data a později je přehrát. V opačném případě je možné přesměrovat uživatele na alternativní instanci aplikace, snížit výkon aplikace, ale stále nabízet přijatelnou funkčnost, nebo jenom vrátit zprávu pro uživatele, že aplikace není v současné době k dispozici.
Další důležité informace
Při rozhodování o hodnotách počtu opakovaných pokusů a intervalů opakování pro zásadu zvažte, jestli je operace se službou nebo prostředkem součástí dlouhotrvající nebo více kroků operace. Může být obtížné nebo nákladné při selhání jednoho kroku kompenzovat všechny ostatní operační kroky, které už úspěšně proběhly. V takovém případě může být přijatelný velmi dlouhý interval a velký počet opakování, dokud nedochází k blokování jiných operace držením nebo uzamčením omezených prostředků.
Zvažte, jestli opakování stejné operace nemůže způsobit nekonzistence v datech. Pokud se některé části procesu s více kroky opakují a operace nejsou idempotentní, může dojít k nekonzistenci. Pokud se například opakuje operace, která zvyšuje hodnotu, výsledek bude neplatný. Opakování operace, která odešle zprávu do fronty může způsobit nekonzistenci v příjemci zpráv, pokud neumí detekovat duplicitní zprávy. Chcete-li tomu zabránit, ujistěte se, že je každý krok navržený jako idempotentní operace. Další informace o idempotence najdete v tématu vzory idempotence.
Vezměte v úvahu rozsah operací, které se budou opakovat. Například může být snadnější implementovat kód opakování na úrovni, která zahrnuje několik operací, a opakovat je všechny, pokud jedna selže. Může to ale vést k problémům idempotence nebo nepotřebným operacím vrácení zpět.
Pokud zvolíte rozsah opakování, který zahrnuje několik operací, vezměte při určování intervalů opakování v úvahu jejich celkovou latenci, kdy sledujete potřebný čas a čas před vyvoláním výstrahy při selhání.
Zvažte, jak strategie opakování může ovlivnit okolí a jiné tenaty ve sdílené aplikaci nebo při používání sdílených prostředků a služeb. Agresivní zásady opakování můžou způsobit růst počtu přechodných chyb, ke kterým dochází pro tyto ostatní uživatele a pro aplikace, které sdílejí prostředky a služby. Podobně může být vaše aplikace ovlivněna zásadami opakování implementovanými jinými uživateli prostředků a služeb. Pro kritické aplikace se můžete rozhodnout použít služby na úrovni Premium, které nejsou sdílené. To vám poskytuje mnohem lepší kontrolu nad zatížením a následným omezováním těchto prostředků a služeb, což může ospravedlnit vyšší náklady.