Sdílet prostřednictvím

Návrh odolných aplikací pomocí sad SDK služby Azure Cosmos DB

  • Článek

PLATÍ PRO: NoSQL

Při vytváření klientských aplikací, které komunikují se službou Azure Cosmos DB prostřednictvím některé ze sad SDK, je důležité porozumět několika klíčovým základům. Tento článek je průvodce návrhem, který vám pomůže porozumět těmto základům a návrhu odolných aplikací.

Přehled

Přehled konceptů probíraných v tomto článku najdete ve videu:

Režimy připojení

Sady SDK služby Azure Cosmos DB se můžou ke službě připojit ve dvou režimech připojení. Sady .NET a Java SDK se můžou ke službě připojit v režimu Brány i v přímém režimu, zatímco ostatní se můžou připojit jenom v režimu brány. Režim brány používá protokol HTTP a přímý režim obvykle protokol TCP.

Režim brány se vždy používá k načtení metadat, jako je účet, kontejner a informace o směrování bez ohledu na to, který režim sady SDK je nakonfigurovaný pro použití. Tyto informace se ukládají do mezipaměti a slouží k připojení k replikám služby.

V souhrnu můžete u sad SDK v režimu brány očekávat provoz HTTP, zatímco u sad SDK v režimu Direct můžete očekávat kombinaci provozu HTTP a TCP za různých okolností (například inicializace nebo načítání metadat nebo informací o směrování).

Klientské instance a připojení

Bez ohledu na režim připojení je důležité udržovat instanci klienta sady SDK na jeden účet na aplikaci. Připojení, jak HTTP, tak TCP, jsou vymezena na instanci klienta. Většina výpočetních prostředí má omezení z hlediska počtu připojení, která se dají otevřít současně a když jsou tato omezení dosažená, bude to mít vliv na připojení.

Distribuované aplikace a sítě

Při návrhu distribuovaných aplikací existují tři klíčové komponenty:

  • Vaše aplikace a prostředí, na kterém běží.
  • Síť, která zahrnuje jakoukoli komponentu mezi vaší aplikací a koncovým bodem služby Azure Cosmos DB.
  • Koncový bod služby Azure Cosmos DB.

Když dojde k selháním, často spadají do jedné z těchto tří oblastí a je důležité pochopit, že vzhledem k distribuované povaze systému je nepraktické očekávat 100% dostupnost pro některou z těchto komponent.

Azure Cosmos DB má komplexní sadu smluv SLA dostupnosti, ale žádná z nich není 100 %. Síťové komponenty, které připojují vaši aplikaci ke koncovému bodu služby, můžou mít přechodné problémy s hardwarem a ztratit pakety. Dokonce i výpočetní prostředí, ve kterém vaše aplikace běží, může mít špičku procesoru ovlivňující operace. Tyto stavy selhání můžou ovlivnit operace sad SDK a obvykle se v nich vyjeví jako chyby s konkrétními kódy.

Vaše aplikace by měla být odolná vůči určité míře potenciálních selhání napříč těmito komponentami implementací zásad opakování u odpovědí poskytovaných sadami SDK.

Měla by se moje aplikace opakovat s chybami?

Stručná odpověď je ano. Ne všechny chyby ale mají smysl opakovat, některé chybové nebo stavové kódy nejsou přechodné. Následující tabulka je podrobně popisuje:

Kód stavu Mělo by se přidat opakování. Opakovat sady SDK Popis
400 No Ne Chybný požadavek
401 No Ne Neautorizuje se
403 Volitelné No Zakázáno
404 No Ne Prostředek nebyl nalezen.
408 Ano Yes Vypršel časový limit požadavku
409 No Ne Konfliktní selhání spočívá v tom, že identita (ID a klíč oddílu) zadaná pro prostředek v operaci zápisu převzala existující prostředek nebo když došlo k porušení omezení jedinečného klíče.
410 Ano Yes Pryč výjimky (přechodné selhání, které by nemělo porušit smlouvu SLA)
412 No Ne Předpokladem selhání je, kdy operace určila eTag, která se liší od verze dostupné na serveru. Jedná se o optimistickou chybu souběžnosti . Po načtení nejnovější verze prostředku a aktualizaci značky ETag v požadavku zkuste požadavek zopakovat.
413 No Ne Příliš velká entita požadavku
429 Ano Yes Je bezpečné to opakovat na 429. Projděte si průvodce odstraňováním potíží s protokolem HTTP 429.
449 Ano Yes Přechodná chyba, ke které dochází pouze při operacích zápisu, a je bezpečná pro opakování. To může odkazovat na problém s návrhem, kdy se příliš mnoho souběžných operací pokouší aktualizovat stejný objekt ve službě Azure Cosmos DB.
500 No Ne Operace selhala kvůli neočekávané chybě služby. Obraťte se na podporu vytvořením problému podpora Azure.
503 Ano Yes Služba není k dispozici

Ve výše uvedené tabulce by všechny stavové kódy označené jako Ano ve druhém sloupci měly mít ve vaší aplikaci určitý stupeň pokrytí opakování.

HTTP 403

Sady SDK služby Azure Cosmos DB se obecně neopakují při selhání HTTP 403, ale existují určité chyby spojené s protokolem HTTP 403, na které se vaše aplikace může rozhodnout reagovat. Pokud se například zobrazí chyba oznamující, že je klíč oddílu plný, můžete se rozhodnout změnit klíč oddílu dokumentu, který se pokoušíte napsat na základě některého obchodního pravidla.

HTTP 429

Sady SDK služby Azure Cosmos DB budou ve výchozím nastavení opakovat chyby HTTP 429 podle konfigurace klienta a respektovat hlavičku odpovědi x-ms-retry-after-ms služby, a to tak, že počká na uvedenou dobu a zkusí to znovu.

Po překročení opakování sady SDK se chyba vrátí do vaší aplikace. V ideálním případě můžete v odpovědi zkontrolovat hlavičku x-ms-retry-after-ms jako nápovědu k rozhodnutí, jak dlouho čekat před opakováním požadavku. Další alternativou by byl exponenciální back-off algoritmus nebo konfigurace klienta pro rozšíření opakování v HTTP 429.

HTTP 449

Sady SDK služby Azure Cosmos DB se budou opakovat na http 449 s přírůstkovým obnovením během pevného časového období, aby vyhovovaly většiněscénářůch

Při překročení automatického opakování v rámci sady SDK bude do aplikace vrácena chyba. Chyby HTTP 449 je možné bezpečně opakovat. Vzhledem k vysoce souběžné povaze operací zápisu je lepší mít algoritmus náhodného zálohování, aby se po pevně určeném intervalu neopakovala stejná míra souběžnosti.

Mezi nejčastější chyby patří vypršení časového limitu sítě a selhání připojení. Sady SDK služby Azure Cosmos DB jsou odolné a v případě, že je opakování možné, budou opakovat problémy s vypršením časových limitů a připojením napříč protokoly HTTP a TCP:

  • V případě operací čtení budou sady SDK opakovat všechny chyby související s vypršením časového limitu nebo připojením.
  • V případě operací zápisu se sady SDK nebudou opakovat, protože tyto operace nejsou idempotentní. Když dojde k vypršení časového limitu čekání na odpověď, není možné zjistit, jestli požadavek dosáhl služby.

Pokud má účet k dispozici více oblastí, sady SDK se také pokusí o opakování mezi oblastmi.

Vzhledem k povaze časových limitů a selhání připojení se tyto chyby nemusí zobrazovat v metrikách vašeho účtu, protože se týkají pouze selhání na straně služby.

Doporučuje se, aby aplikace měly pro tyto scénáře vlastní zásady opakování a aby zohlednily, jak vyřešit vypršení časových limitů zápisu. Například opakování časového limitu vytvoření může přinést http 409 (konflikt), pokud se předchozí požadavek dostal do služby, ale pokud ne, bude úspěšný.

Podrobnosti implementace specifické pro jazyk

Další podrobnosti implementace týkající se jazyka najdete tady:

Mají opakování vliv na latenci?

Z pohledu klienta ovlivní všechny pokusy o opakování koncovou latenci operace. Když je latence P99 vaší aplikace ovlivněná, je důležité porozumět opakováním, ke kterým dochází, a jak je řešit.

Sady SDK služby Azure Cosmos DB poskytují podrobné informace v protokolech a diagnostice, které vám můžou pomoct zjistit, které pokusy probíhají. Další informace najdete v tématu shromažďování diagnostiky sady .NET SDK a shromažďování diagnostiky sady Java SDK.

Jak můžu zmírnit latenci opakování?

V závislosti na okolnostech bude sada SDK směrovat požadavky do místní oblasti, oblasti zápisu (ve scénáři zápisu do jedné oblasti) nebo první oblasti v seznamu upřednostňovaných oblastí . Tato stanovení priority minimalizuje latenci ve scénářích v pořádku tím, že se primárně připojuje k nejbližšímu nebo nejoptimálnějšímu datovému centru.

Toto stanovení priority ale také znamená, že žádosti, které budou mít za následek selhání, se v jedné konkrétní oblasti pokusí vždy nejprve pro daný scénář chyb. Pokud je v tomto scénáři upřednostňované převzetí služeb při selhání do jiné oblasti, obvykle se to zpracovává na úrovni infrastruktury (Traffic Manageru) místo na úrovni sady SDK. Správné nastavení a konfigurace infrastruktury zajistí efektivní přesměrování provozu během oblastních výpadků, čímž se zmírní latence, která může být součástí opakování napříč oblastmi ve scénáři výpadku. Podrobnější informace o nastavení převzetí služeb při selhání na úrovni infrastruktury najdete v dokumentaci k Azure Traffic Manageru. Některé sady SDK podporují implementaci podobných strategií převzetí služeb při selhání přímo na úrovni sady SDK. Podívejte se například na vysokou dostupnost sady Java SDK.

A co oblastní výpadky?

Sady SDK služby Azure Cosmos DB pokrývají regionální dostupnost a můžou provádět opakování v jiných oblastech účtu. Informace o scénářích opakování a konfiguracích v prostředích s více oblastmi najdete v článku s informacemi o tom, které scénáře zahrnují jiné oblasti.

Kdy kontaktovat zákaznickou podporu

Než se obrátíte na zákaznickou podporu, projděte si tyto kroky:

  • Jaký je dopad měřený objemem ovlivněných operací v porovnání s úspěšnými operacemi? Nachází se v rámci smluv SLA služby?
  • Týká se latence P99?
  • Souvisí selhání s kódy chyb, se kterými se má moje aplikace opakovat, a týká se těchto opakování aplikace?
  • Týkají se selhání všech instancí aplikace, nebo pouze jejich podmnožiny? Pokud je problém omezený na podmnožinu instancí, jedná se obvykle o problém související s těmito instancemi.
  • Prošli jste související dokumenty pro řešení potíží ve výše uvedené tabulce, abyste vyloučili problém v aplikačním prostředí?

Pokud jsou ovlivněny všechny instance aplikace nebo procento ovlivněných operací je mimo smlouvy SLA služby nebo ovlivňuje smlouvy SLA vaší aplikace a smlouvy P99, obraťte se na zákaznickou podporu.

Další kroky