Aspekty návrhu aplikací pro klíčové úlohy

Tento článek se zaměřuje na aspekty spolehlivosti a odolnosti klíčové aplikace, jako je asynchronní zpracování požadavků a jak dosáhnout vysoké propustnosti v rámci řešení. Tato série článků používá jednoduchý scénář online katalogu jako příklad vysoce spolehlivé úlohy, ve které můžou uživatelé procházet katalog položek, kontrolovat podrobnosti o položkách a publikovat hodnocení a komentáře k položkám.

Složení aplikace

U vysoce důležitých aplikací musíte optimalizovat architekturu pro komplexní škálovatelnost a odolnost. Komponenty můžete oddělit do funkčních jednotek, které mohou fungovat nezávisle. Toto oddělení použijte na všech úrovních zásobníku aplikací, aby každá část systému byla možné škálovat nezávisle a uspokojovat změny v poptávce.

Aplikace používá bezstavové koncové body rozhraní API, které oddělují dlouhotrvající požadavky na zápis asynchronně prostřednictvím zprostředkovatele zasílání zpráv. Složení pracovní zátěže umožňuje kdykoli odstranit a znovu vytvořit celé clustery Azure Kubernetes Service (AKS) a další závislosti v prostředí. Mezi hlavní komponenty aplikace patří:

• Uživatelské rozhraní (UI):: Jednostráková webová aplikace, ke které mají uživatelé přístup. Uživatelské rozhraní je hostované na hostování statického webu účtu Azure Storage.

• API (CatalogService): Rozhraní REST API, které volá aplikace uživatelského rozhraní, ale je stále k dispozici pro další potenciální klientské aplikace.

• Pracovní proces (BackgroundProcessor): Pracovní proces na pozadí, který naslouchá novým událostem ve sběrnici zpráv a zpracovává požadavky na zápis do databáze. Tato komponenta nezpřístupňuje žádná rozhraní API.

• Rozhraní API služby Health Service (HealthService): Rozhraní API, které hlásí stav aplikace kontrolou, jestli fungují důležité komponenty, jako je databáze nebo sběrnice zasílání zpráv.

  

Úloha se skládá z aplikací pro rozhraní API, pracovní proces a kontrolu stavu. Vyhrazený obor názvů AKS, který se nazývá workload hostuje úlohy jako kontejnery. Mezi pody nedojde k přímé komunikaci. Pody jsou bezstavové a lze je škálovat nezávisle.

Mezi další podpůrné komponenty, které běží v clusteru, patří:

• NGINX vstupní kontrolér: Směruje příchozí požadavky na úlohy a provádí vyrovnávání zátěže mezi pody. Kontroler příchozího přenosu dat NGINX je přístupný přes Azure Load Balancer s veřejnou IP adresou, ale dá se k němu přistupovat jenom přes Azure Front Door.

• Cert manager: Jetstack automaticky zajišťuje certifikáty pro Transport Layer Security (TLS) pomocí Let's Encrypt pro pravidla přístupu.

• Secrets Store CSI Driver: Zprostředkovatel služby Azure Key Vault pro Secrets Store CSI Driver bezpečně čte tajné položky, jako jsou připojovací řetězce ze služby Key Vault.

• Agent monitorování: Výchozí konfigurace agenta Azure Monitor je upravena tak, aby se snížil objem monitorovacích dat odesílaných do pracovního prostoru protokolů Azure Monitor.

Připojení k databázi

Vzhledem k dočasné povaze značek nasazení se vyhněte ukládání stavu ve značce, pokud je to možné. V externím úložišti dat byste měli zachovat stav. Pro podporu cíle na úrovni služby spolehlivosti (SLO) vytvořte odolné úložiště dat. Doporučujeme používat řešení spravovaná nebo platforma jako služba (PaaS) v kombinaci s nativními knihovnami SDK, které automaticky zpracovávají časové limity, odpojení a další stavy selhání.

Azure Cosmos DB slouží jako hlavní úložiště dat pro aplikaci. Azure Cosmos DB poskytuje zápisy do více oblastí. Každé razítko může zapisovat do repliky služby Azure Cosmos DB ve stejné oblasti a Azure Cosmos DB interně zpracovává replikaci a synchronizaci dat mezi oblastmi. Azure Cosmos DB for NoSQL podporuje všechny funkce databázového stroje.

Další informace najdete v tématu Datová platforma pro klíčové úlohy.

Poznámka:

Pro nové aplikace použijte Azure Cosmos DB for NoSQL. U starších aplikací, které používají jiný protokol NoSQL, vyhodnoťte cestu migrace ke službě Azure Cosmos DB.

Pro klíčové aplikace, které upřednostňují dostupnost oproti výkonu, doporučujeme zápis v jedné oblasti a čtení ve více oblastech se silnou konzistencí .

Azure Storage slouží k dočasnému uložení stavu v razítku pro vytváření kontrolních bodů služby Azure Event Hubs.

Všechny komponenty úloh používají ke komunikaci s databází sadu Azure Cosmos DB .NET SDK. SDK obsahuje robustní logiku pro udržování připojení k databázi a zpracování selhání. Mezi klíčová nastavení konfigurace patří:

• Režim přímého připojení: Toto nastavení je výchozí pro sadu .NET SDK v3, protože nabízí lepší výkon. Režim přímého připojení má méně síťových skoků v porovnání s režimem Gateway, který používá HTTP.

• Vrácení obsahu při zápisu: Tento přístup je zakázán, aby klient služby Azure Cosmos DB nemohl vrátit dokument při vytvoření, aktualizaci, vložení nebo opravě a nahrazení, což snižuje síťový provoz. Další zpracování na klientovi nevyžaduje toto nastavení.

• Vlastní serializace: Tento proces nastaví zásadu pojmenovávání vlastností JSON tak, aby vlastnosti .NET převedl na standardní vlastnosti JSON. Může také přeložit vlastnosti JSON na vlastnosti .NET. Výchozí podmínka ignorování ignoruje vlastnosti s hodnotami null, například JsonIgnoreCondition.WhenWritingNull, během serializace.

• ApplicationRegion: Tato vlastnost je nastavena na oblast razítka, která sadě SDK umožňuje najít nejbližší koncový bod připojení. Koncový bod by měl být nejlépe ve stejné oblasti.

Asynchronní zasílání zpráv

Když implementujete volné párování, služby nemají závislosti na jiných službách. Volný aspekt umožňuje, aby služba fungovala nezávisle. Aspekt párování umožňuje komunikaci mezi službami prostřednictvím dobře definovaných rozhraní. Pro kritickou aplikaci volné vazby zabraňují tomu, aby selhání v dolní části přecházela k front-endům nebo jiným instancím nasazení, což zajišťuje vysokou dostupnost.

Mezi klíčové charakteristiky asynchronního zasílání zpráv patří:

• Služby nemusí používat stejnou výpočetní platformu, programovací jazyk ani operační systém.

• Služby se škálují nezávisle.

• Podřízená selhání nemají vliv na klientské transakce.

• Transakční integrita se obtížně udržuje, protože vytváření a trvalost dat probíhá v samostatných službách. Transakční integrita je výzvou napříč službami zpráv a službami uložení dat. Další informace naleznete v tématu Idempotentní zpracování zpráv.

• Kompletní trasování vyžaduje komplexní orchestraci.

Doporučujeme používat dobře známé vzory návrhu, jako vzory vyrovnávání zatížení založené na frontě a vzory konkurenčních spotřebitelů. Tyto vzory distribuují zatížení od producenta k spotřebitelům a umožňují asynchronní zpracování u spotřebitelů. Například pracovník umožní rozhraní API přijmout žádost a rychle odpovědět volajícímu, zatímco pracovník zpracovává operaci zápisu do databáze samostatně.

Event Hubs zprostředkuje zprávy mezi rozhraním API a pracovním procesem.

Důležité

Nepoužívejte zprostředkovatele zpráv jako trvalé úložiště dat po dlouhou dobu. Služba Event Hubs podporuje funkci zachycení. Funkce zachycení umožňuje centru událostí automaticky zapisovat kopii zpráv do propojeného účtu úložiště. Tento proces řídí využití a slouží jako mechanismus pro zálohování zpráv.

Podrobnosti implementace operací zápisu

Operace zápisu, jako je hodnocení příspěvku a komentář, se zpracovávají asynchronně. API nejprve odešle zprávu se všemi relevantními informacemi, jako je typ akce a údaje o komentářích, do fronty zpráv a okamžitě vrátí odpověď HTTP 202 (Accepted) s Location hlavičkou objektu, který bude vytvořen.

BackgroundProcessor instance zpracovává zprávy ve frontě a řídí komunikaci s databází pro operace zápisu. BackgroundProcessor škáluje a škáluje se dynamicky na základě svazku zpráv fronty. Limit horizontálního navýšení kapacity instancí procesoru je definován maximálním počtem oddílů služby Event Hubs, což je 32 pro úrovně Basic a úrovně Standard, 100 pro úroveň Premium a 1 024 pro vyhrazenou úroveň.

Knihovna procesoru Azure Event Hubs ve BackgroundProcessor službě Azure Blob Storage používá ke správě vlastnictví oddílů, vyrovnávání zatížení mezi různými instancemi pracovních procesů a sledování průběhu pomocí kontrolních bodů. Kontrolní body se po každé události nezapisují do úložiště blob, protože to způsobuje nákladné zpoždění pro každou zprávu. Místo toho jsou kontrolní body napsané ve smyčce časovače a můžete nakonfigurovat dobu trvání. Výchozí nastavení je 10 sekund.

Pokud aplikace procesoru narazí na chybu nebo je zastavena, než může zprávu zpracovat:

• Další instance převezme zprávu pro opětovné zpracování, protože nebyla správně označena ve službě Storage.

• Ke konfliktu dojde, pokud předchozí pracovník uložil dokument do databáze před tím, než selhal. K této chybě dochází, protože se používá stejné ID a klíč oddílu. Procesor může zprávu bezpečně ignorovat, protože dokument je již zachován.

• Nová instance zopakuje kroky a dokončí persistentnost, pokud byla předchozí pracovní instance ukončena před tím, než se zapsala do databáze.

Podrobnosti implementace operací čtení

Rozhraní API přímo zpracovává operace čtení a okamžitě vrací data zpět uživateli.

Není zavedena metoda back-channel pro komunikaci s klientem, kdyby se operace úspěšně dokončila. Klientská aplikace musí proaktivně dotazovat rozhraní API na aktualizace o položce zadané v Location hlavičce HTTP.

Škálovatelnost

Jednotlivé komponenty úloh by se měly škálovat nezávisle, protože každá komponenta má různé vzory zatížení. Požadavky na škálování závisí na funkčnosti služby. Některé služby přímo ovlivňují uživatele a musí agresivně navýšovat kapacitu, aby se zajistily rychlé odpovědi a pozitivní uživatelské prostředí.

Zabalte služby jako image kontejnerů a pomocí chartů Helm nasaďte služby do každého razítka. Služby jsou nakonfigurované tak, aby měly očekávané požadavky a limity Kubernetes a předem nakonfigurované pravidlo automatického škálování. CatalogService Komponenty BackgroundProcessor úloh se můžou škálovat a škálovat jednotlivě, protože obě služby jsou bezstavové.

Uživatelé komunikují přímo s touto CatalogServicečástí, takže tato část úlohy musí reagovat při jakémkoli zatížení. Pro každý cluster existuje minimálně tři instance, které se mají rozložit mezi tři zóny dostupnosti v oblasti Azure. Horizontální automatické škálování podů (HPA) v AKS automaticky podle potřeby přidává další pody. Funkce automatického škálování služby Azure Cosmos DB může dynamicky zvýšit a snížit počet jednotek žádostí dostupných pro kolekci. Služba CatalogService a Azure Cosmos DB se zkombinují, aby vytvořily jednotku škálování v rámci razítka.

HPA je nasazena pomocí Helm chartu, který má konfigurovatelný maximální a minimální počet replik. Zátěžový test zjistil, že každá instance dokáže zpracovat přibližně 250 požadavků za sekundu se standardním vzorem použití.

Služba BackgroundProcessor má různé požadavky a považuje se za pracovní proces na pozadí, který má omezený vliv na uživatelské prostředí. BackgroundProcessor má jinou konfiguraci automatického škálování ve srovnání s CatalogService, a může se škálovat mezi 2 a 32 instancemi. Tento limit určete podle počtu oddílů, které používáte v event hubech. Nepotřebujete více pracovníků než oddíly.

Komponenta	minReplicas	maxReplicas
Katalogová služba	3	20
Procesor na pozadí	2	32

Každá komponenta úlohy, která zahrnuje závislosti, jako je ingress-nginx, má nakonfigurované nastavení rozpočtů narušení podů (PDB), aby se zajistilo, že při změně clusterů zůstane k dispozici minimální počet instancí.

Poznámka:

Určení skutečného minimálního počtu a maximálního počtu podů pro každou komponentu prostřednictvím zátěžového testování

Instrumentace

Vyhodnocujte výkonnostní úzká hrdla a problémy se zdravím systému pomocí instrumentace, které můžou komponenty pracovního zatížení zavést do systému. Aby vám pomohla kvantifikovat rozhodnutí, každá komponenta by měla generovat dostatečné informace prostřednictvím metrik a protokolů trasování. Při instrumentaci aplikace zvažte následující klíčové aspekty:

• Odeslat protokoly, metriky a další telemetrii do systému protokolů.
• Místo prostého textu používejte strukturované protokolování, abyste mohli dotazovat informace.
• Implementujte korelaci událostí, abyste získali kompletní zobrazení transakcí. Například každá odpověď rozhraní API obsahuje ID operace jako hlavičku HTTP pro sledovatelnost.
• Nespoléhejte jenom na záznam do stdout nebo na záznam do konzole. Tyto protokoly ale můžete použít k okamžitému řešení potíží s neúspěšným podem.

Implementujte distribuované trasování pomocí Application Insights a pracovního prostoru protokolů Azure Monitor pro sledování dat aplikací. Protokoly služby Azure Monitor můžete použít pro protokoly a metriky komponent úloh a infrastruktury. Implementujte kompletní koncové trasování požadavků, které přicházejí z rozhraní API, procházejí přes Event Hubs a následně se dostávají do databáze.

Důležité

Nasaďte prostředky pro monitorování razítek do samostatné skupiny prostředků sledování. Prostředky mají odlišný životní cyklus než razítko samotné. Další informace najdete v tématu Monitorování dat pro prostředky razítka.

Podrobnosti implementace monitorování aplikací

Komponenta BackgroundProcessor využívá Azure Monitor OpenTelemetry Distro pro získání hotové instrumentace z aplikace. Serilog se také používá pro veškeré protokolování uvnitř aplikace. Služba Application Insights je kromě jímky konzoly nakonfigurovaná jako jímka. Rozhraní API OpenTelemetry, jako ActivitySource a Meter, se používají přímo, když je potřeba sledovat další metriky.

Aby bylo možné předvést praktickou sledovatelnost požadavků, vrátí každý úspěšný a neúspěšný požadavek rozhraní API hlavičku ID korelace volajícímu. Tým podpory aplikace může prohledávat Application Insights pomocí tohoto identifikátoru a získat podrobné zobrazení celé transakce, která je znázorněna v předchozím diagramu.

Poznámka:

Adaptivní vzorkování může být ve výchozím nastavení povolené v distribuci OpenTelemetry služby Azure Monitor používané ve vašich aplikacích. Adaptivní vzorkování znamená, že se do cloudu neodesílají všechny požadavky a dají se prohledávat podle ID. Klíčové aplikační týmy potřebují spolehlivě trasovat všechny požadavky. Adaptivní vzorkování by mělo být v produkčních prostředích zakázané.

Podrobnosti o implementaci monitorování Kubernetes

Nastavení diagnostiky můžete použít k odesílání protokolů a metrik AKS do protokolů služby Azure Monitor. Funkci Přehledy kontejnerů můžete použít také s AKS. Povolte službě Container Insights nasazení Azure Monitor Agenta prostřednictvím ama-logs DaemonSet Kubernetes na každém uzlu v clusterech AKS. Agent shromažďuje další protokoly a metriky z prostředí clusteru Kubernetes a odesílá je do příslušného pracovního prostoru služby Azure Monitor Logs. Tento pracovní prostor obsahuje podrobná data o podech, nasazeních, službách a celkovém stavu clusteru.

Rozsáhlé protokolování může negativně ovlivnit náklady a nepřináší žádné výhody. Z tohoto důvodu je v konfiguraci přehledů kontejnerů pro pody úloh zakázáno shromažďování protokolů stdout a scraping Prometheus, protože všechny stopy jsou již zachyceny pomocí služby Application Insights, což generuje duplicitní záznamy.

Monitorování stavu aplikace

Monitorování a pozorovatelnost aplikací můžete použít k rychlé identifikaci problémů systému a informování modelu stavu o aktuálním stavu aplikace. Monitorování zdraví můžete zobrazit prostřednictvím koncových bodů zdraví. Sondy zdraví používají data monitorování kondice k poskytování informací. Hlavní nástroj pro vyrovnávání zatížení použije tyto informace k tomu, aby nefunkční komponentu okamžitě vyřadil z rotace.

Monitorování stavu použijte na následujících úrovních:

• Pody pracovní zátěže, které běží na Azure Kubernetes Service (AKS) Tyto pody mají sondy stavu a aktivity, takže AKS může spravovat jejich životní cyklus.

• Health Service, což je vyhrazená komponenta v clusteru. Služba Azure Front Door je nakonfigurovaná tak, aby testovala službu pro kontrolu stavu na každém serveru a odebrala nefunkční servery z automatického vyvažování zátěže.

Podrobnosti implementace služby Health Service

HealthService je komponenta úlohy, která běží společně s dalšími komponentami, například CatalogService a BackgroundProcessor, ve výpočetním clusteru. HealthService poskytuje rozhraní REST API, které volání kontroly stavu služby Azure Front Door určují dostupnost razítka. Na rozdíl od základních sond živé aktivity je služba Health Service složitější komponentou, která kromě vlastního stavu poskytuje stav závislostí.

Služba Health Service nereaguje, pokud je cluster AKS nefunkční, což vykreslí úlohu, která není v pořádku. Když služba běží, provádí pravidelné kontroly kritických součástí řešení. Všechny kontroly se provádějí asynchronně a paralelně. Pokud některá z kontrol selže, celé razítko není k dispozici.

Varování

Zdravotní sondy služby Azure Front Door mohou výrazně zatížit službu Health Service, protože požadavky pocházejí z několika umístění bodů přítomnosti (PoP). Pokud chcete zabránit přetížení podřízených komponent, implementujte efektivní ukládání do mezipaměti.

Služba Health Service se také používá pro explicitně nakonfigurované ping testy URL adres s prostředkem Application Insights každého razítka.

Pro více informací o HealthService naleznete Application Health Service.

Další krok

Sítě a možnosti připojení pro klíčové úlohy