Tento článek obsahuje pokyny pro optimalizaci škálovatelnosti a výkonu při společném používání služby Azure Event Hubs a Azure Functions ve vašich aplikacích.
Seskupování funkcí
Funkce obvykle zapouzdřuje jednotku práce v datovém proudu zpracování událostí. Funkce může například transformovat událost na novou datovou strukturu nebo rozšířit data pro podřízené aplikace.
Ve službě Functions poskytuje aplikace funkcí kontext spuštění pro funkce. Chování aplikace funkcí se vztahuje na všechny funkce, které aplikace funkcí hostuje. Funkce v aplikaci funkcí se nasazují společně a škálují se společně. Všechny funkce v aplikaci funkcí musí být ve stejném jazyce.
Způsob seskupení funkcí do aplikací funkcí může mít vliv na výkon a možnosti škálování aplikací funkcí. Můžete seskupit podle přístupových práv, nasazení a vzorů použití, které volají váš kód.
Pokyny k osvědčeným postupům služby Functions pro seskupení a další aspekty najdete v tématu Osvědčené postupy pro spolehlivé funkce Azure Functions a zlepšení výkonu a spolehlivosti azure Functions.
Následující seznam obsahuje pokyny pro seskupování funkcí. Pokyny se týkají aspektů skupiny úložiště a příjemců:
Hostování jedné funkce v aplikaci funkcí: Pokud služba Event Hubs aktivuje funkci, můžete omezit kolize mezi danou funkcí a dalšími funkcemi, izolovat ji ve své vlastní aplikaci funkcí. Izolace je obzvláště důležitá v případě, že ostatní funkce jsou náročné na procesor nebo paměť. Tato technika pomáhá, protože každá funkce má vlastní nároky na paměť a vzory využití, které můžou přímo ovlivnit škálování aplikace funkcí, která ji hostuje.
Dejte každé aplikaci funkcí svůj vlastní účet úložiště: Vyhněte se sdílení účtů úložiště mezi aplikacemi funkcí. Pokud aplikace funkcí používá účet úložiště, nepoužívejte tento účet pro jiné operace nebo potřeby úložiště. Zvlášť důležité je vyhnout se sdílení účtů úložiště pro funkce, které služba Event Hubs aktivuje, protože tyto funkce můžou mít velký objem transakcí úložiště z důvodu vytváření kontrolních bodů.
Vytvořte vyhrazenou skupinu příjemců pro každou aplikaci funkcí: Skupina příjemců je zobrazení centra událostí. Různé skupiny příjemců mají různá zobrazení, což znamená, že stavy, pozice a posuny se mohou lišit. Skupiny uživatelů umožňují více aplikacím, které využívají, mít vlastní zobrazení datového proudu událostí a číst stream nezávisle vlastním tempem a s vlastními posuny. Další informace o skupinách příjemců najdete v tématu Funkce a terminologie ve službě Azure Event Hubs.
Skupina příjemců má přidruženou jednu nebo více uživatelských aplikací a aplikace příjemce může používat jednu nebo více skupin příjemců. V řešení zpracování datových proudů se každá aplikace příjemce rovná skupině příjemců. Aplikace funkcí je základním příkladem aplikace příjemce. Následující diagram obsahuje příklad dvou aplikací funkcí, které čtou z centra událostí, kde každá aplikace má svou vlastní vyhrazenou skupinu příjemců:
Nesdílejte skupiny příjemců mezi aplikacemi funkcí a jinými aplikacemi příjemců. Každá aplikace funkcí by měla být samostatná aplikace s vlastní přiřazenou skupinou příjemců, aby se zajistila integrita posunu pro každého příjemce a zjednodušila závislosti v architektuře streamování událostí. Tato konfigurace společně s poskytováním každé funkce aktivované centrem událostí má vlastní aplikaci funkcí a účet úložiště, pomáhá nastavit základ pro optimální výkon a škálování.
Plány hostování funkcí
Každá aplikace funkcí je hostovaná podle jednoho ze tří plánů hostování. Informace o těchto plánech najdete v tématu Možnosti hostování služby Azure Functions. Poznamenejte si, jak se škáluje tři možnosti.
Plán Consumption je výchozí. Aplikace funkcí v plánu Consumption se škálují nezávisle a jsou nejúčinnější, pokud se vyhýbají dlouhotrvajícím úlohám.
Plány Premium a Dedicated se často používají k hostování více aplikací funkcí a funkcí, které jsou náročnější na procesor a paměť. S plánem Dedicated spustíte funkce v plánu služby Aplikace Azure s pravidelnými tarify plánu služby App Service. Je důležité si uvědomit, že všechny aplikace funkcí v těchto plánech sdílejí prostředky přidělené plánu. Pokud mají funkce různé profily zatížení nebo jedinečné požadavky, je nejlepší je hostovat v různých plánech, zejména v aplikacích pro zpracování datových proudů.
Škálování služby Event Hubs
Když nasadíte obor názvů služby Event Hubs, je potřeba správně nastavit několik důležitých nastavení, abyste zajistili špičkový výkon a škálování. Tato část se zaměřuje na úroveň Standard služby Event Hubs a na jedinečné funkce této úrovně, které mají vliv na škálování při použití funkcí. Další informace o úrovních služby Event Hubs najdete v tématu Basic vs. Standard vs. Premium vs. Dedicated tiers.
Obor názvů služby Event Hubs odpovídá clusteru Kafka. Informace o tom, jak služba Event Hubs a Kafka vzájemně souvisí, najdete v tématu Co je Azure Event Hubs pro Apache Kafka.
Principy jednotek propustnosti (TU)
Na úrovni Event Hubs Standard se propustnost klasifikuje jako množství dat, která se zadávají a čtou z oboru názvů za jednotku času. Jednotky TU jsou předem zakoupené jednotky kapacity propustnosti.
Jednotky TU se účtují po hodinách.
Všechna centra událostí v oboru názvů sdílejí jednotky TU. Abyste správně vypočítali potřeby kapacity, musíte zvážit všechny aplikace a služby, a to jak vydavatelé, tak spotřebitelé. Funkce ovlivňují počet bajtů a událostí publikovaných do centra událostí a jejich čtení z centra událostí.
Důraz na určení počtu jednotek TU je v bodě příchozího přenosu dat. Agregace pro aplikace příjemců, včetně míry zpracování těchto událostí, však musí být zahrnuta také do výpočtu.
Další informace o jednotkách propustnosti služby Event Hubs najdete v tématu Jednotky propustnosti.
Vertikální navýšení kapacity pomocí automatického nafouknutí
Automatické nafouknutí je možné povolit v oboru názvů služby Event Hubs tak, aby vyhovovalo situacím, ve kterých zatížení překračuje nakonfigurovaný počet jednotek TU. Použití automatického nafouknutí zabraňuje omezování aplikace a pomáhá zajistit, aby zpracování, včetně ingestování událostí, pokračovalo bez přerušení. Vzhledem k tomu, že nastavení tu má vliv na náklady, pomůže použití automatického nafouknutí řešit obavy týkající se nadměrného zřízení.
Automatické nafouknutí je funkce služby Event Hubs, která se často zaměňuje s automatickým škálováním, zejména v kontextu bezserverových řešení. Automatické nafouknutí, na rozdíl od automatického škálování, se ale při přidání kapacity už nevyžaduje vertikální snížení kapacity.
Pokud aplikace potřebuje kapacitu, která překračuje maximální povolený počet jednotek TU, zvažte použití úrovně Event Hubs Premium nebo úrovně Dedicated.
Oddíly a souběžné funkce
Při vytvoření centra událostí je nutné zadat počet oddílů . Počet oddílů zůstane pevný a nejde ho změnit s výjimkou úrovní Premium a Dedicated. Když Služba Event Hubs aktivuje aplikace funkcí, je možné, že počet souběžných instancí se může rovnat počtu oddílů.
V plánech hostování Consumption a Premium se instance aplikace funkcí dynamicky škálují tak, aby v případě potřeby splňovaly počet oddílů. Plán vyhrazeného hostování spouští funkce v plánu služby App Service a vyžaduje ruční konfiguraci instancí nebo nastavení schématu automatického škálování. Další informace najdete v tématu Vyhrazené plány hostování pro Azure Functions.
Relace 1:1 mezi počtem oddílů a instancemi aplikace funkcí je v konečném důsledku ideální cíl pro maximální propustnost v řešení pro zpracování datových proudů. Aby bylo dosaženo optimálního paralelismu, mají ve skupině příjemců více příjemců. U funkcí se tento cíl překládá na mnoho instancí aplikace funkcí v plánu. Výsledek se označuje jako paralelismus na úrovni oddílu nebo maximální stupeň paralelismu, jak je znázorněno v následujícím diagramu:
Může se zdát, že je vhodné nakonfigurovat co nejvíce oddílů, abyste dosáhli maximální propustnosti a zohlednili možnost vyššího objemu událostí. Při konfiguraci mnoha oddílů je však potřeba vzít v úvahu několik důležitých faktorů:
- Větší počet oddílů může vést k vyšší propustnosti: Vzhledem k tomu, že stupeň paralelismu je počet příjemců (instancí aplikace funkcí), čím více oddílů existuje, tím vyšší může být souběžná propustnost. Tato skutečnost je důležitá, když sdílíte určený počet jednotek TU pro centrum událostí s jinými aplikacemi příjemců.
- Více funkcí může vyžadovat více paměti: S rostoucím počtem instancí aplikace funkcí se tak zvyšuje nároky na paměť prostředků v plánu. V určitém okamžiku může příliš mnoho oddílů zhoršovat výkon pro uživatele.
- Existuje riziko zpětného tlaku z podřízených služeb: S tím, jak se generuje větší propustnost, můžete riskovat zahlcení podřízených služeb nebo příjem zpětného tlaku z nich. Při zvažování důsledků okolních prostředků se musí počítat s ventilátorem pro spotřebitele. Možné důsledky zahrnovaly omezování z jiných služeb, sytosti sítě a dalších forem kolizí prostředků.
- Oddíly se dají řídce naplnit: Kombinace mnoha oddílů a nízkého objemu událostí může vést k řídké distribuci dat napříč oddíly. Místo toho může menší počet oddílů poskytovat lepší výkon a využití prostředků.
Dostupnost a konzistence
Pokud není zadaný klíč oddílu nebo ID, služba Event Hubs směruje příchozí událost do dalšího dostupného oddílu. Tento postup poskytuje vysokou dostupnost a pomáhá zvýšit propustnost pro uživatele.
Při objednání sady událostí může producent událostí určit, že se má konkrétní oddíl použít pro všechny události sady. Aplikace příjemce, která čte z oddílu, přijímá události ve správném pořadí. Tento kompromis poskytuje konzistenci, ale ohrožuje dostupnost. Tento přístup nepoužívejte, pokud není nutné zachovat pořadí událostí.
U funkcí se řazení dosáhne, když se události publikují do konkrétního oddílu a funkce aktivovaná službou Event Hubs získá zapůjčení stejného oddílu. V současné době se nepodporuje možnost konfigurace oddílu s výstupní vazbou služby Event Hubs. Místo toho je nejlepší použít jednu ze sad SDK služby Event Hubs k publikování do konkrétního oddílu.
Další informace o tom, jak Služba Event Hubs podporuje dostupnost a konzistenci, najdete v tématu Dostupnost a konzistence ve službě Event Hubs.
Trigger služby Event Hubs
Tato část se zaměřuje na nastavení a aspekty optimalizace funkcí, které služba Event Hubs aktivuje. Mezi faktory patří dávkové zpracování, vzorkování a související funkce, které ovlivňují chování vazby triggeru centra událostí.
Dávkování aktivovaných funkcí
Můžete nakonfigurovat funkce, které centrum událostí aktivuje ke zpracování dávky událostí nebo jedné události najednou. Zpracování dávky událostí je efektivnější, protože eliminuje některé režijní náklady na vyvolání funkcí. Pokud nepotřebujete zpracovat pouze jednu událost, měla by být vaše funkce při vyvolání nakonfigurovaná tak, aby zpracovávala více událostí.
Povolení dávkování pro vazbu triggeru služby Event Hubs se liší mezi jazyky:
- JavaScript, Python a další jazyky umožňují dávkování, pokud je vlastnost kardinality nastavená na mnoho v souboru function.json pro funkci.
- V jazyce C# se kardinalita automaticky nakonfiguruje , když je pole určené pro typ v atributu EventHubTrigger .
Další informace o tom, jak je povolené dávkování, najdete v tématu Trigger služby Azure Event Hubs pro Azure Functions.
Nastavení aktivační události
Několik nastavení konfigurace v souboru host.json hraje klíčovou roli v charakteristikách výkonu vazby triggeru služby Event Hubs pro funkce:
- maxEventBatchSize: Toto nastavení představuje maximální počet událostí, které může funkce přijímat při vyvolání. Pokud je počet přijatých událostí menší než tato částka, funkce se stále vyvolá s tolika událostmi, kolik je k dispozici. Nemůžete nastavit minimální velikost dávky.
- prefetchCount: Počet předběžného načtení je jedním z nejdůležitějších nastavení při optimalizaci výkonu. Podkladový kanál AMQP odkazuje na tuto hodnotu a určí, kolik zpráv se má načíst a uložit do mezipaměti pro klienta. Prefetch count by měl být větší nebo roven hodnotě maxEventBatchSize a obvykle je nastaven na násobek této částky. Nastavení této hodnoty na číslo menší než nastavení maxEventBatchSize může poškodit výkon.
- batchCheckpointFrequency: Při zpracování dávek funkce určuje tato hodnota rychlost vytvoření kontrolních bodů. Výchozí hodnota je 1, což znamená, že je kontrolní bod vždy, když funkce úspěšně zpracuje dávku. Kontrolní bod se vytvoří na úrovni oddílu pro každého čtenáře ve skupině příjemců. Informace o tom, jak toto nastavení ovlivňuje přehrání a opakování událostí, najdete v tématu Centrum událostí aktivované funkcí Azure: Přehrání a opakování (blogový příspěvek).
Proveďte několik testů výkonnosti a určete hodnoty, které se mají nastavit pro vazbu triggeru. Doporučujeme měnit nastavení přírůstkově a konzistentně měřit, aby se tyto možnosti vyladily. Výchozí hodnoty jsou rozumným výchozím bodem pro většinu řešení zpracování událostí.
Vytváření kontrolních bodů
Kontrolní body označují pozice čtenáře nebo označují pozice čtenáře v posloupnosti událostí oddílu. Za zpracování událostí a splnění nastavení frekvence dávkového kontrolního bodu zodpovídá hostitel Služby Functions. Další informace o vytváření kontrolních bodů najdete v tématu Funkce a terminologie ve službě Azure Event Hubs.
Následující koncepty vám pomůžou pochopit vztah mezi kontrolním bodem a způsobem, jakým funkce zpracovává události:
- Výjimky se stále počítají k úspěchu: Pokud se proces funkce při zpracování událostí neukončí, považuje se dokončení funkce za úspěšné, i když došlo k výjimkám. Po dokončení funkce hostitel functions vyhodnotí batchCheckpointFrequency. Pokud je čas na kontrolní bod, vytvoří ho bez ohledu na to, jestli došlo k výjimkám. Skutečnost, že výjimky nemají vliv na vytváření kontrolních bodů, by neměly mít vliv na správné použití kontroly a zpracování výjimek.
- Dávkové frekvence záleží: V řešeních pro streamování událostí s velkým objemem může být užitečné změnit nastavení batchCheckpointFrequency na hodnotu větší než 1. Zvýšení této hodnoty může snížit míru vytváření kontrolních bodů a v důsledku toho počet vstupně-výstupních operací úložiště.
- K přehrání může dojít: Při každém vyvolání funkce pomocí vazby triggeru služby Event Hubs použije nejnovější kontrolní bod k určení, kde pokračovat ve zpracování. Posun pro každého příjemce se uloží na úrovni oddílu pro každou skupinu příjemců. K přehrání dojde, když během posledního vyvolání funkce nedojde k kontrolnímu bodu a funkce se znovu vyvolá. Další informace o duplikátech a technikách odstranění duplicitních dat najdete v tématu Idempotence.
Pochopení kontrolních bodů je důležité, když zvažujete osvědčené postupy pro zpracování chyb a opakování, což je téma, které je popsáno dále v tomto článku.
Vzorkování telemetrie
Služba Functions poskytuje integrovanou podporu application Insights, rozšíření služby Azure Monitor, které poskytuje možnosti monitorování výkonu aplikací. Pomocí této funkce můžete protokolovat informace o aktivitách funkcí, výkonu, výjimkách modulu runtime a dalších funkcích. Další informace najdete v přehledu Application Insights.
Tato výkonná funkce nabízí několik klíčových možností konfigurace, které ovlivňují výkon. Mezi důležité nastavení a důležité aspekty monitorování a výkonu patří:
- Povolte vzorkování telemetrie: Ve scénářích s vysokou propustností byste měli vyhodnotit množství telemetrie a potřebné informace. Zvažte použití funkce vzorkování telemetrie ve službě Application Insights, abyste se vyhnuli snížení výkonu vaší funkce s nepotřebnými telemetrií a metrikami.
- Konfigurace nastavení agregace: Zkontrolujte a nakonfigurujte frekvenci agregace a odesílání dat do Application Insights. Toto nastavení konfigurace je v souboru host.json spolu s mnoha dalšími možnostmi souvisejícími s vzorkováním a protokolováním. Další informace najdete v tématu Konfigurace agregátoru.
- Zakázat AzureWebJobDashboard: Pro aplikace, které cílí na verzi 1.x modulu runtime Functions, uloží toto nastavení připojovací řetězec do účtu úložiště, který sada Azure SDK používá k uchovávání protokolů pro řídicí panel WebJobs. Pokud se Application Insights používá místo řídicího panelu Webových úloh, mělo by se toto nastavení odebrat. Další informace najdete v tématu AzureWebJobsDashboard.
Když je služba Application Insights povolená bez vzorkování, odešle se veškerá telemetrie. Odesílání dat o všech událostech může mít nepříznivý vliv na výkon funkce, zejména ve scénářích streamování událostí s vysokou propustností.
Využití vzorkování a průběžného posuzování vhodného množství telemetrie potřebné pro monitorování je zásadní pro optimální výkon. Telemetrie by se měla používat pro obecné vyhodnocení stavu platformy a pro občasné řešení potíží, ne pro zachycení základních obchodních metrik. Další informace najdete v tématu Konfigurace vzorkování.
Výstupní vazba
Pomocí výstupní vazby služby Event Hubs pro Azure Functions zjednodušte publikování do streamu událostí z funkce. Mezi výhody použití této vazby patří:
- Správa prostředků: Vazba zpracovává životní cyklus klienta i připojení za vás a snižuje potenciál problémů, ke kterým může dojít při vyčerpání portů a správě fondu připojení.
- Méně kódu: Vazba abstrahuje podkladovou sadu SDK a snižuje množství kódu, který potřebujete k publikování událostí. Pomůže vám psát kód, který se snadněji píše a udržuje.
- Dávkování: Pro několik jazyků se podporuje dávkování, které efektivně publikuje do streamu událostí. Dávkování může zvýšit výkon a zjednodušit kód, který odesílá události.
Důrazně doporučujeme, abyste si prostudovali seznam jazyků, které Functions podporuje , a příručky pro vývojáře pro tyto jazyky. V části Vazby pro každý jazyk najdete podrobné příklady a dokumentaci.
Dávkování při publikování událostí
Pokud vaše funkce publikuje pouze jednu událost, konfigurace vazby tak, aby vrátila hodnotu, je běžný přístup, který je užitečný v případě, že provádění funkce vždy končí příkazem, který událost odešle. Tato technika by měla být použita pouze pro synchronní funkce, které vracejí pouze jednu událost.
Dávkování je doporučeno ke zlepšení výkonu při odesílání více událostí do datového proudu. Dávkování umožňuje vazbu publikovat události nejúčinnějším způsobem.
Podpora použití výstupní vazby k odesílání více událostí do služby Event Hubs je dostupná v jazyce C#, Javě, Pythonu a JavaScriptu.
Výstup více událostí (C#)
Při odesílání více událostí z funkce v jazyce C# použijte typy ICollector a IAsyncCollector.
- ICollector <T>. Metoda Add() se dá použít v synchronních i asynchronních funkcích. Spustí operaci přidání hned po zavolání.
- IAsyncCollector<T>. Metoda AddAsync() připraví události, které se mají publikovat do streamu událostí. Pokud napíšete asynchronní funkci, měli byste použít IAsyncCollector k lepší správě publikovaných událostí.
Příklady použití jazyka C# k publikování jedné a více událostí najdete ve výstupní vazbě služby Azure Event Hubs pro Azure Functions.
Omezování a zpětný tlak
Aspekty omezování platí pro výstupní vazbu, nejen pro službu Event Hubs, ale také pro služby Azure, jako je Azure Cosmos DB. Je důležité se seznámit s limity a kvótami, které se na tyto služby vztahují, a podle toho plánovat.
Pokud chcete zpracovat podřízené chyby, můžete zabalit AddAsync a FlushAsync do obslužné rutiny výjimky pro funkce .NET, aby se zachytily výjimky z IAsyncCollectoru. Další možností je použít sady SDK služby Event Hubs přímo místo použití výstupních vazeb.
Kód funkce
Tato část popisuje klíčové oblasti, které je potřeba zvážit při psaní kódu pro zpracování událostí ve funkci, kterou služba Event Hubs aktivuje.
Asynchronní programování
Doporučujeme, abyste funkci napsali tak, aby používala asynchronní kód, a vyhnuli se blokování volání, zejména v případě, že jsou zahrnutá volání vstupně-výstupních operací.
Tady jsou pokyny, které byste měli dodržovat při zápisu funkce pro asynchronní zpracování:
- Všechny asynchronní nebo všechny synchronní: Pokud je funkce nakonfigurovaná tak, aby běžela asynchronně, měly by být všechna volání vstupně-výstupních operací asynchronní. Ve většině případů je částečně asynchronní kód horší než kód, který je zcela synchronní. Zvolte buď asynchronní, nebo synchronní, a držte se výběru až po celý postup.
- Vyhněte se blokování volání: Blokování volání se vrátí volajícímu až po dokončení volání, na rozdíl od asynchronních volání, která se okamžitě vrátí. Příkladem v jazyce C# je volání Task.Result nebo Task.Wait na asynchronní operaci.
Další informace o blokování volání
Použití blokujících volání asynchronních operací může vést k hladovění fondu vláken a způsobit chybové ukončení procesu funkce. K chybovému ukončení dochází, protože blokující volání vyžaduje, aby se vytvořilo další vlákno, které bude vyrovnávat původní volání, které teď čeká. V důsledku toho vyžaduje k dokončení operace dvakrát tolik vláken.
Zabránění této synchronizaci prostřednictvím asynchronního přístupu je zvlášť důležité, pokud je součástí služby Event Hubs, protože chyba funkce neaktualizuje kontrolní bod. Při příštím vyvolání funkce může docházet k tomuto cyklu a zdá se, že se zasekne nebo se pomalu přesune, protože provádění funkcí nakonec vyprší.
Řešení potíží s tímto jevem obvykle začíná kontrolou nastavení triggeru a spouštěním experimentů, které můžou zahrnovat zvýšení počtu oddílů. Šetření můžou také vést ke změně několika možností dávkování, jako je maximální velikost dávky nebo počet předběžného načtení. Dojem je, že se jedná o problém s propustností nebo nastavení konfigurace, které je potřeba odpovídajícím způsobem ladit. Základní problém je ale v samotném kódu a musí se tam vyřešit.
Přispěvatelé
Tento článek spravuje Microsoft. Původně byl napsán následujícím přispěvatelem.
Hlavní autor:
- David Barkol | Hlavní specialista řešení GBB
Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.
Další kroky
Než budete pokračovat, zvažte kontrolu těchto souvisejících článků:
- Monitorování spuštění v Azure Functions
- Spolehlivé zpracování událostí ve službě Azure Functions
- Návrh služby Azure Functions pro stejný vstup
- ASP.NET pokyny pro asynchronní synchronizaci Core.
- Trigger služby Azure Event Hubs pro Azure Functions