Navrhování odolných aplikací pomocí sad SDK služby Azure Cosmos DB

  • Článek

PLATÍ PRO: NoSQL

Při vytváření klientských aplikací, které interagují se službou Azure Cosmos DB prostřednictvím kterékoli 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 navrhnout odolné aplikace.

Přehled

Video s přehledem konceptů probíraných v tomto článku najdete tady:

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 režimu přímého připojení, 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 používá protokol TCP.

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

Stručně řečeno, u sad SDK v režimu brány můžete očekávat provoz HTTP, zatímco u sad SDK v režimu Direct můžete očekávat kombinaci přenosů HTTP a TCP za různých okolností (například inicializace, 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 Singleton na účet a aplikaci. Připojení HTTP i TCP jsou vymezena na instanci klienta. Většina výpočetních prostředí má omezení, pokud jde o počet připojení, která se dají otevřít současně, a když dosáhnete těchto limitů, ovlivní to 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í, ve kterém běží.
  • Síť, která zahrnuje libovolnou komponentu mezi vaší aplikací a koncovým bodem služby Azure Cosmos DB.
  • Koncový bod služby Azure Cosmos DB.

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

Azure Cosmos DB má komplexní sadu smluv SLA o 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, která ovlivňuje operace. Tyto stavy selhání můžou ovlivnit operace sad SDK a obvykle se vyjevují jako chyby s konkrétními kódy.

Vaše aplikace by měla být odolná vůči určitému stupni potenciálních selhání napříč těmito komponentami díky implementaci zásad opakování na odpovědi poskytované 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é kódy chyb nebo stavových kódů nejsou přechodné. Níže uvedená tabulka je podrobně popisuje:

Stavový kód Mělo by se přidat opakování Opakování sad SDK Popis
400 No No Chybný požadavek
401 No No Neautorizováno
403 Volitelné No Zakázáno
404 No No Prostředek se nenašel.
408 Yes Yes Vypršel časový limit žádosti.
409 No No Selhání konfliktu nastane, když existující prostředek převzal identitu (ID a klíč oddílu) zadanou pro prostředek při operaci zápisu nebo když došlo k porušení omezení jedinečného klíče .
410 Yes Yes Odstraněné výjimky (přechodné selhání, které by nemělo narušovat smlouvu SLA)
412 No No Selhání předběžné podmínky je místo, kde operace určila eTag, která se liší od verze dostupné na serveru. Jedná se o chybu optimistické souběžnosti . Po načtení nejnovější verze prostředku a aktualizaci značky ETag v požadavku zkuste požadavek zopakovat.
413 No No Příliš velká entita požadavku
429 Yes Yes Je bezpečné zkusit to znovu na 429. Projděte si průvodce odstraňováním potíží s HTTP 429.
449 Yes Yes Přechodná chyba, ke které dochází pouze při operacích zápisu a je bezpečné ji opakovat. To může ukazovat 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 No Operace selhala kvůli neočekávané chybě služby. Obraťte se na podporu tím, že podpora Azure problém.
503 Yes Yes Nedostupná služba

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

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é může vaše aplikace reagovat. Pokud se například zobrazí chyba oznamující, že klíč oddílu je plný, můžete se rozhodnout změnit klíč oddílu dokumentu, který se pokoušíte napsat, na základě nějakého obchodního pravidla.

HTTP 429

Sady SDK služby Azure Cosmos DB se budou ve výchozím nastavení opakovat s chybami HTTP 429 po konfiguraci klienta a při dodržení hlavičky odpovědi x-ms-retry-after-ms služby tím, že počká na určený čas a zkusí to znovu.

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

HTTP 449

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

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 nejběžnější chyby patří vypršení časového limitu sítě a selhání připojení. Sady SDK služby Azure Cosmos DB jsou samy o sobě odolné a budou opakovat vypršení časových limitů a problémy s připojením napříč protokoly HTTP a TCP, pokud je to možné:

  • V případě operací čtení se sady SDK pokusí opakovat jakékoli chyby související s vypršením časového limitu nebo připojením.
  • U 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 se žádost dostala do služby.

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

Vzhledem k povaze vypršení č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.

Pro aplikace se doporučuje mít pro tyto scénáře vlastní zásady opakování a zvážit, jak řešit časové limity zápisu. Například opakováním časového limitu vytvoření může dojít k chybě HTTP 409 (konflikt), pokud se předchozí požadavek do služby dostal, ale pokud ne, bude úspěšný.

Podrobnosti implementace specifické pro konkrétní jazyk

Další podrobnosti o implementaci jazyka najdete tady:

Mají opakování vliv na latenci?

Z pohledu klienta všechny opakování ovlivní latenci operace od konce do konce. Při ovlivnění latence P99 aplikace je důležité porozumět opakovaným pokusům a jejich řešení.

Sady SDK služby Azure Cosmos DB poskytují podrobné informace ve svých protokolech a diagnostice, které vám můžou pomoct určit, které opakování probíhá. Další informace najdete v tématu o tom, jak shromažďovat diagnostiku sady .NET SDK a jak shromažďovat diagnostiku sady Java SDK.

A co regionální výpadky?

Sady SDK služby Azure Cosmos DB pokrývají regionální dostupnost a můžou provádět opakované pokusy v jiných oblastech účtu. Pokud chcete zjistit, které scénáře zahrnují jiné oblasti, přečtěte si článek o scénářích a konfiguracích opakování prostředí s více oblastmi.

Kdy kontaktovat zákaznickou podporu

Než se obrátíte na zákaznickou podporu, proveďte tyto kroky:

  • Jaký je dopad měřený objemem ovlivněných operací v porovnání s úspěšnými operacemi? Je v rámci smluv SLA služby?
  • Týká se latence P99?
  • Souvisí selhání s kódy chyb , se kterými by se moje aplikace měla pokusit znovu, a pokrývá tyto 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 si související dokumenty pro řešení potíží ve výše uvedené tabulce, abyste vyloučili problém v prostředí aplikace?

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

Další kroky