Diagnostika a řešení potíží s výjimkami kvůli příliš vysoké frekvenci požadavků (429) ve službě Azure Cosmos DB

  • Článek

PLATÍ PRO: NoSQL

Tento článek obsahuje známé příčiny a řešení různých chyb stavového kódu 429 pro rozhraní API pro NoSQL. Pokud používáte rozhraní API pro MongoDB, přečtěte si článek Řešení běžných problémů v rozhraní API pro MongoDB , kde najdete informace o ladění stavového kódu 16500.

Výjimka "Příliš vysoká frekvence požadavků", označovaná také jako kód chyby 429, označuje, že vaše požadavky na službu Azure Cosmos DB jsou omezené rychlostí.

Při použití zřízené propustnosti nastavíte propustnost měřenou v jednotkách žádostí za sekundu (RU/s) vyžadovanou pro vaši úlohu. Databázové operace se službou, jako jsou čtení, zápisy a dotazy, spotřebovávají určitý počet jednotek žádostí (RU). Přečtěte si další informace o jednotkách žádostí.

Pokud operace spotřebovávají více než zřízené jednotky požadavků, vrátí azure Cosmos DB v dané sekundě výjimku 429. Každou sekundu se resetuje počet dostupných jednotek žádostí.

Před provedením akce ke změně RU/s je důležité porozumět původní příčině omezování rychlosti a vyřešit související problém.

Tip

Pokyny v tomto článku se týkají databází a kontejnerů, které používají zřízenou propustnost – automatické škálování i ruční propustnost.

Existují různé chybové zprávy, které odpovídají různým typům výjimek 429:

Frekvence požadavků je vysoká

Toto je nejběžnější scénář. Dochází k tomu v případě, že jednotky žádostí spotřebované operacemi s daty překročí zřízený počet RU/s. Pokud používáte ruční propustnost, dochází k tomu v případě, že jste spotřebovali více RU/s, než je zřízená ruční propustnost. Pokud používáte automatické škálování, dochází k tomu v případě, že jste spotřebovali více, než je maximální zřízený počet RU/s. Pokud máte například prostředek zřízený s ruční propustností 400 RU/s, zobrazí se hodnota 429 při spotřebování více než 400 jednotek žádostí za jednu sekundu. Pokud máte prostředek zřízený s maximálním maximálním využitím automatického škálování 4 000 RU/s (škálování mezi 400 RU/s až 4000 RU/s), zobrazí se při spotřebě více než 4 000 jednotek žádostí za jednu sekundu 429 odpovědí.

Tip

Všechny operace se účtují na základě počtu prostředků, které spotřebovávají. Tyto poplatky se měří v jednotkách žádostí. Tyto poplatky zahrnují požadavky, které se úspěšně nedokon dělají kvůli chybám aplikace, jako 400jsou , 412, 449atd. Při pohledu na omezování nebo využití je vhodné prozkoumat, jestli se ve vašem využití nezměnil nějaký vzor, což by vedlo ke zvýšení počtu těchto operací. Konkrétně zkontrolujte značky 412 nebo 449 (skutečný konflikt).

Další informace o zřízené propustnosti najdete v tématu Zřízená propustnost ve službě Azure Cosmos DB.

Krok 1: Zkontrolujte metriky a zjistěte procento požadavků s chybou 429.

Zobrazení chybových zpráv 429 nemusí nutně znamenat problém s databází nebo kontejnerem. Malé procento 429 odpovědí je normální bez ohledu na to, jestli používáte propustnost ručního nebo automatického škálování, a znamená to, že maximalizujete počet RU/s, které jste zřídili.

Postup prošetřování

Zjistěte, jaké procento vašich požadavků na vaši databázi nebo kontejner přineslo 429 odpovědí v porovnání s celkovým počtem úspěšných požadavků. V účtu služby Azure Cosmos DB přejděte naCelkový počet žádostí> o přehledy> podle stavových kódů. Vyfiltrujte konkrétní databázi a kontejner.

Ve výchozím nastavení se klientské sady SDK služby Azure Cosmos DB a nástroje pro import dat, jako jsou Azure Data Factory a knihovna bulk executor, automaticky opakují žádosti na 429. Zkusí to obvykle až devětkrát. V důsledku toho se sice v metrikách může zobrazit 429 odpovědí, ale tyto chyby se nemusí vrátit do vaší aplikace.

Graf Total Requests by Status Code (Celkový počet žádostí podle stavového kódu), který zobrazuje počet požadavků 429 a 2xx.

Obecně platí, že pokud u produkčních úloh vidíte 1–5 % požadavků s 429 odpověďmi a vaše celková latence je přijatelná, znamená to, že se RU/s plně využívají. Nevyžaduje se žádná akce. V opačném případě přejděte k dalšímu postupu řešení potíží.

Důležité

Tento rozsah 1–5 % předpokládá rovnoměrné rozdělení oddílů účtu. Pokud vaše oddíly nejsou rovnoměrně rozdělené, může váš problémový oddíl vrátit velké množství chyb 429, zatímco celková míra může být nízká.

Pokud používáte automatické škálování, můžete ve vaší databázi nebo kontejneru zobrazit odpovědi 429, i když počet RU/s nebyl škálován na maximální počet RU/s. Vysvětlení najdete v části Frekvence požadavků je vysoká s automatickým škálováním .

Jednou z běžných otázek, která vyvstává, je: "Proč se mi v metrikách Služby Azure Monitor zobrazuje odpověď 429, ale ve vlastním monitorování aplikací žádná?" Pokud metriky Azure Monitoru ukazují, že máte 429 odpovědí, ale ve vlastní aplikaci jste žádnou neviděli, je to proto, že ve výchozím nastavení klientské sady SDK automatically retried internally on the 429 responses služby Azure Cosmos DB a požadavek v následných opakovaných pokusech uspěly. V důsledku toho se do aplikace nevrátí stavový kód 429. V těchto případech je celková míra odpovědí 429 obvykle minimální a dá se bezpečně ignorovat za předpokladu, že celková míra je mezi 1–5 % a latence mezi koncovými body je pro vaši aplikaci přijatelná.

Krok 2: Určení, jestli existuje horký oddíl

Horký oddíl vznikne v případě, že jeden nebo několik klíčů logického oddílu spotřebuje kvůli vyššímu objemu požadavků nepřiměřenou částku z celkového počtu RU/s. Příčinou může být návrh klíče oddílu, který nedistribuuje požadavky rovnoměrně. Výsledkem je, že mnoho požadavků je směrováno na malou podmnožinu logických (což znamená fyzické) oddíly, které se stanou "horkými". Vzhledem k tomu, že všechna data pro logický oddíl se nacházejí v jednom fyzickém oddílu a celkový počet RU/s je rovnoměrně rozdělený mezi fyzické oddíly, může horký oddíl vést k odpovědím 429 a neefektivnímu využití propustnosti.

Tady je několik příkladů strategií dělení, které vedou k horkým oddílům:

  • Máte kontejner, který ukládá data zařízení IoT pro úlohu s velkými nároky na zápis, která je rozdělená do oddílů pomocí date. Všechna data pro jedno datum se budou nacházet ve stejném logickém a fyzickém oddílu. Vzhledem k tomu, že všechna data zapsaná každý den mají stejné datum, každý den by to vedlo k horkému oddílu.
    • Místo toho by pro tento scénář klíč id oddílu (identifikátor GUID nebo ID zařízení) nebo syntetický klíč oddílu kombinující id a date přinesl by vyšší kardinalitu hodnot a lepší distribuci svazku požadavků.
  • Máte scénář s více tenanty s kontejnerem rozděleným podle tenantId. Pokud je jeden tenant mnohem aktivnější než ostatní, výsledkem je horký oddíl. Pokud má například největší tenant 100 000 uživatelů, ale většina tenantů má méně než 10 uživatelů, budete mít při dělení podle tenantIDhorkého oddílu oddíl.
    • V tomto předchozím scénáři zvažte použití vyhrazeného kontejneru pro největšího tenanta rozděleného podle podrobnější vlastnosti, jako UserIdje .

Jak identifikovat horký oddíl

Pokud chcete ověřit, jestli existuje horký oddíl, přejděte do části Insights>Throughput>Normalized RU Consumption (%) By PartitionKeyRangeID. Vyfiltrujte konkrétní databázi a kontejner.

Každý PartitionKeyRangeId se mapuje na jeden fyzický oddíl. Pokud existuje jeden PartitionKeyRangeId, který má mnohem vyšší normalizovanou spotřebu RU než ostatní (například jeden má konzistentně 100 %, ale ostatní mají 30 % nebo méně), může to být příznak horkého oddílu. Přečtěte si další informace o metrikě Normalizovaná spotřeba RU.

Graf Normalizovaná spotřeba RU podle PartitionKeyRangeId s horkým oddílem

Pokud chcete zjistit, které klíče logických oddílů spotřebovávají nejvíce RU/s, použijte diagnostické protokoly Azure. Tento ukázkový dotaz sečte celkový počet jednotek žádostí spotřebovaných za sekundu u každého klíče logického oddílu.

Důležité

Povolením diagnostických protokolů se za službu Log Analytics účtují samostatné poplatky, které se účtují na základě objemu přijatých dat. Doporučujeme zapnout diagnostické protokoly po omezenou dobu pro ladění a vypnout, když už nejsou potřeba. Podrobnosti najdete na stránce s cenami .

 CDBPartitionKeyRUConsumption
 | where TimeGenerated >= ago(24hour)
 | where CollectionName == "CollectionName"
 | where isnotempty(PartitionKey)
 // Sum total request units consumed by logical partition key for each second
 | summarize sum(RequestCharge) by PartitionKey, OperationName, bin(TimeGenerated, 1s)
 | order by sum_RequestCharge desc

Tento ukázkový výstup ukazuje, že za určitou minutu spotřeboval klíč logického oddílu s hodnotou Contoso přibližně 12 000 RU/s, zatímco klíč logického oddílu s hodnotou "Fabrikam" spotřeboval méně než 600 RU/s. Pokud byl tento vzor konzistentní během časového období, kdy došlo k omezení rychlosti, znamená to horký oddíl.

Klíče logických oddílů spotřebovávají nejvíce jednotek žádostí za sekundu.

Tip

V každé úloze bude mezi logickými oddíly přirozená odchylka objemu požadavků. Měli byste zjistit, jestli příčinou horkého oddílu je základní nerovnoměrnost z důvodu volby klíče oddílu (která může vyžadovat změnu klíče) nebo dočasné špičky kvůli přirozené variabilitě vzorů úloh.

Projděte si pokyny k výběru vhodného klíče oddílu.

Pokud existuje vysoké procento požadavků s omezenou rychlostí a žádný horký oddíl:

Pokud existuje vysoké procento požadavků omezených rychlostí a existuje základní horký oddíl:

  • V dlouhodobém horizontu zvažte změnu klíče oddílu, pro zajištění nejlepších nákladů a výkonu. Klíč oddílu nejde aktualizovat, takže to vyžaduje migraci dat do nového kontejneru s jiným klíčem oddílu. Azure Cosmos DB pro tento účel podporuje nástroj pro migraci dat za provozu.
  • V krátkodobém horizontu můžete dočasně zvýšit celkovou počet RU/s prostředku, abyste umožnili větší propustnost horkého oddílu. To se nedoporučuje jako dlouhodobá strategie, protože to vede k nadměrnému zřizování RU/s a vyšším nákladům.
  • Krátkodobě můžete pomocí funkce redistribuce propustnosti napříč oddíly (Preview) přiřadit více RU/s fyzickému oddílu, který je horký. To se doporučuje pouze v případě, že je horký fyzický oddíl předvídatelný a konzistentní.

Tip

Když zvýšíte propustnost, operace vertikálního navýšení kapacity se buď dokončí okamžitě, nebo bude trvat až 5 až 6 hodin v závislosti na počtu RU/s, na které chcete vertikálně navýšit kapacitu. Pokud chcete zjistit nejvyšší počet RU/s, který můžete nastavit, aniž byste aktivovala asynchronní operaci vertikálního navýšení kapacity (která vyžaduje, aby služba Azure Cosmos DB zřídila více fyzických oddílů), vynásobte počet jedinečných Id rozsahu klíčů oddílů číslem 10 0000 RU/s. Pokud máte například zřízených 30 000 RU/s a 5 fyzických oddílů (6 000 RU/s přidělených na fyzický oddíl), můžete v rámci okamžité operace vertikálního navýšení kapacity zvýšit kapacitu až na 50 000 RU/s (10 000 RU/s na fyzický oddíl). Zvýšení na >50 000 RU/s by vyžadovalo asynchronní operaci vertikálního navýšení kapacity. Přečtěte si další informace o osvědčených postupech pro škálování zřízené propustnosti (RU/s).

Krok 3: Určení požadavků, které vracejí odpovědi 429

Jak zkoumat požadavky s odpověďmi 429

Pomocí diagnostických protokolů Azure identifikujte, které požadavky vracejí odpovědi 429 a kolik jednotek RU spotřebovaly. Tento ukázkový dotaz agreguje na úrovni minut.

Důležité

Povolením diagnostických protokolů se za službu Log Analytics účtují samostatné poplatky, které se účtují na základě objemu přijatých dat. Doporučuje se zapnout diagnostické protokoly po omezenou dobu pro ladění a vypnout, když už nejsou potřeba. Podrobnosti najdete na stránce s cenami .

 CDBDataPlaneRequests
 | where TimeGenerated >= ago(24h)
 | summarize throttledOperations = dcountif(ActivityId, StatusCode == 429), totalOperations = dcount(ActivityId), totalConsumedRUPerMinute = sum(RequestCharge) by DatabaseName, CollectionName, OperationName, RequestResourceType, bin(TimeGenerated, 1min)
 | extend averageRUPerOperation = 1.0 * totalConsumedRUPerMinute / totalOperations
 | extend fractionOf429s = 1.0 * throttledOperations / totalOperations
 | order by fractionOf429s desc

Tento ukázkový výstup například ukazuje, že každou minutu bylo rychlostně omezeno 30 % požadavků na vytvoření dokumentu, přičemž každý požadavek spotřebovává v průměru 17 RU. Požadavky s chybou 429 v diagnostických protokolech

Použití plánovače kapacity služby Azure Cosmos DB

Pomocí plánovače kapacity služby Azure Cosmos DB můžete zjistit, jaká je nejlepší zřízená propustnost na základě vašich úloh (objem a typ operací a velikost dokumentů). Výpočty můžete dále přizpůsobit poskytnutím ukázkových dat, abyste získali přesnější odhad.

Odpovědi 429 na žádosti o vytvoření, nahrazení nebo upsertování dokumentů
  • Ve výchozím nastavení se v rozhraní API pro NoSQL indexují všechny vlastnosti. Vylaďte zásady indexování tak, aby indexovat pouze potřebné vlastnosti. Tím se sníží počet jednotek žádostí požadovaných pro operaci vytvoření dokumentu, což sníží pravděpodobnost zobrazení odpovědí 429 nebo umožní dosáhnout vyššího počtu operací za sekundu pro stejný počet zřízených RU/s.
Odpovědi 429 na žádosti o dokumenty dotazu
429 odpovědi na provádění uložených procedur
  • Uložené procedury jsou určené pro operace, které vyžadují transakce zápisu napříč hodnotou klíče oddílu. Nedoporučuje se používat uložené procedury pro velký počet operací čtení nebo dotazů. Pro zajištění nejlepšího výkonu by se tyto operace čtení nebo dotazování měly provádět na straně klienta pomocí sad SDK služby Azure Cosmos DB.

Frekvence požadavků je při automatickém škálování vysoká

Všechny pokyny v tomto článku se týkají propustnosti s ručním i automatickým škálováním.

Při používání automatického škálování vyvstává běžná otázka : "Je stále možné zobrazit odpovědi 429 s automatickým škálováním?"

Ano. Může k tomu dojít ve dvou hlavních scénářích.

Scénář 1: Když celková spotřeba RU/s překročí maximální počet RU/s databáze nebo kontejneru, služba odpovídajícím způsobem omezí požadavky. Je to obdobou překročení celkové ručně zřízené propustnosti databáze nebo kontejneru.

Scénář 2: Pokud existuje horký oddíl, tj. hodnota klíče logického oddílu, který má nepřiměřeně vyšší množství požadavků v porovnání s jinými hodnotami klíče oddílu, je možné, že příslušný fyzický oddíl překročí rozpočet RU/s. Pokud se chcete vyhnout horkým oddílům, doporučujeme zvolit vhodný klíč oddílu, který zajistí rovnoměrnou distribuci úložiště a propustnosti. Je to podobné, jako když je k dispozici horký oddíl při použití ruční propustnosti.

Pokud například vyberete možnost maximální propustnosti 20 000 RU/s a máte 200 GB úložiště se čtyřmi fyzickými oddíly, je možné každý fyzický oddíl automaticky škálovat až na 5 000 RU/s. Pokud byl na konkrétním klíči logického oddílu horký oddíl, zobrazí se odpovědi 429, když základní fyzický oddíl, ve kterém se nachází, překročí 5 000 RU/s, to znamená, že překročí 100% normalizované využití.

Pokud chcete tyto scénáře ladit, postupujte podle pokynů v krocích 1, 2 a 3 .

Další běžná otázka, která vyvstává, je Proč je normalizovaná spotřeba RU 100 %, ale automatické škálování se neškáli na maximální počet RU/s?

K tomu obvykle dochází u úloh, u kterých dochází k dočasným nebo přerušovaným špičkám využití. Když použijete automatické škálování, Azure Cosmos DB škáluje RU/s na maximální propustnost pouze v případě, že normalizovaná spotřeba RU je 100 % po trvalé nepřetržité časové období v 5sekundovém intervalu. Cílem je zajistit, aby logika škálování byla pro uživatele nákladově přívětivá, protože zajišťuje, že jednorázové, momentální špičky nebudou vést ke zbytečnému škálování a vyšším nákladům. V případě momentální špičky se systém obvykle škáluje na vyšší hodnotu, než byla dříve škálovaná na RU/s, ale nižší než maximální počet RU/s. Přečtěte si další informace o tom, jak interpretovat metriku normalizované spotřeby RU pomocí automatického škálování.

Omezování rychlosti požadavků na metadata

K omezení rychlosti metadat může dojít při provádění velkého objemu operací s metadaty s databázemi nebo kontejnery. Mezi operace s metadaty patří:

  • Vytvoření, čtení, aktualizace nebo odstranění kontejneru nebo databáze
  • Výpis databází nebo kontejnerů v účtu služby Azure Cosmos DB
  • Dotaz na nabídky a zobrazení aktuální zřízené propustnosti

Pro tyto operace platí limit RU vyhrazený systémem, takže zvýšení zřízených RU/s databáze nebo kontejneru nebude mít žádný vliv a nedoporučuje se. Viz Omezení služby řídicí roviny.

Postup prošetřování

Přejděte do části Přehledy> žádostío systémová>metadata podle stavových kódů. V případě potřeby vyfiltrujte konkrétní databázi a kontejner.

Graf žádostí o metadata podle stavového kódu v přehledech

  • Pokud vaše aplikace potřebuje provádět operace s metadaty, zvažte implementaci zásad zpochybňování, které tyto požadavky odesílají nižší rychlostí.

  • Použití statických klientských instancí služby Azure Cosmos DB Když se inicializuje DocumentClient nebo CosmosClient, sada Azure Cosmos DB SDK načte metadata o účtu, včetně informací o úrovni konzistence, databázích, kontejnerech, oddílech a nabídkách. Tato inicializace může využívat velké množství RU a měla by se provádět jenom zřídka. Použijte jednu instanci DocumentClient a využijte ji po celou dobu životnosti vaší aplikace.

  • Názvy databází a kontejnerů se ukládají do mezipaměti. Načtěte názvy databází a kontejnerů z konfigurace nebo je při spuštění do mezipaměti. Volání jako ReadDatabaseAsync/ReadDocumentCollectionAsync nebo CreateDatabaseQuery/CreateDocumentCollectionQuery budou mít za následek volání metadat do služby, která spotřebovávají z limitu RU vyhrazeného systémem. Tyto operace by se měly provádět zřídka.

Omezování rychlosti kvůli přechodné chybě služby

Tato chyba 429 se vrátí, když požadavek narazí na přechodnou chybu služby. Zvýšení počtu RU/s v databázi nebo kontejneru nebude mít žádný vliv a nedoporučuje se.

Zkuste požadavek zopakovat. Pokud chyba přetrvává několik minut, vytvořte lístek podpory z Azure Portal.

Další kroky