Model razítka nasazení

Nasaďte několik nezávislých kopií komponent aplikace, včetně úložišť dat, jako jednu skupinu prostředků. Každá kopie se nazývá kolek nebo někdy jednotka služby, jednotka škálování nebo buňka. V prostředí s více tenanty každá instance obsluhuje předdefinovaný počet tenantů. Nasaďte více stamps, abyste řešení škálovali téměř lineárně, obsloužili rostoucí počet tenantů, nasadili instance do několika regionů a oddělili data zákazníků.

Note

Další informace najdete v tématu Návrh víceklientských řešení v Azure.

Kontext a problém

Při hostování aplikace v cloudu zvažte výkon a spolehlivost vaší aplikace. Pokud hostujete jednu instanci řešení, můžou platit následující omezení:

• Omezení škálování: Jedna instance vaší aplikace může dosáhnout přirozených limitů škálování. Používané služby mohou například omezit počet příchozích připojení, názvů hostitelů, soketů TCP (Transmission Control Protocol) nebo jiných prostředků.

• Nelineární škálování nebo náklady: Některé komponenty vašeho řešení nemusí být škálovatelné lineárně s počtem požadavků nebo množstvím dat. Místo toho může výkon po splnění prahové hodnoty klesnout nebo mohou náklady prudce vzrůst. Můžete například zjistit, že přidání větší kapacity do databáze nebo vertikálního navýšení kapacity se stává příliš nákladným a že horizontální navýšení kapacity je cenově výhodnější.

• Oddělení zákazníků: Možná budete muset izolovat data jednoho zákazníka od dat jiného zákazníka. Můžete mít také zákazníky, kteří spotřebovávají více systémových prostředků než ostatní. Můžete je seskupit do různých sad infrastruktury.

• Instance pro jednoho nájemníka a více nájemníků: Někteří z velkých zákazníků mohou potřebovat nezávislé instance vašeho řešení. Menší zákazníci mohou sdílet víceuživatelské nasazení.

• Složité požadavky na nasazení: Možná budete muset nasadit aktualizace do vaší služby řízeným způsobem a nasadit je do různých podmnožina zákaznické základny v různých časech.

• Četnost aktualizací: Někteří zákazníci tolerují časté aktualizace, zatímco zákazníci s riziky chtějí občasné aktualizace systému, který jejich požadavky obsluhuje. Tyto zákazníky můžete nasadit do izolovaných prostředí.

• Geografická nebo geopolitické omezení: Pokud chcete dosáhnout nízké latence nebo splnit požadavky na suverenitu dat, můžete některé zákazníky nasadit do konkrétních oblastí.

Tato omezení se často vztahují na společnosti pro vývoj softwaru, které vytvářejí software jako službu (SaaS), které obvykle navrhují jako víceklientské. Stejná omezení se můžou vztahovat i na jiné scénáře.

Řešení

Pokud se chcete těmto problémům vyhnout, zvažte seskupení prostředků do jednotek škálování a zřízení více kopií razítek. Každá jednotka škálování slouží a obsluhuje podmnožinu vašich tenantů. Moduly běží nezávisle na sobě a můžete je nasadit a aktualizovat samostatně. Jedna geografická oblast může obsahovat jedno razítko nebo více razítek, která umožňují horizontální škálování v rámci této oblasti. Každé razítko slouží podmnožině vašich zákazníků.

Diagram znázorňuje pět skládaných řádků. Každý řádek představuje jedno razítko nasazení. Každý řádek má popisek v levém horním rohu, který udává název razítka a oblast služby Azure, a popisek v pravém horním rohu, který popisuje tenanty, jimž razítko slouží. Pod těmito popisky jsou dvě komponenty: vlevo Azure App Service a vpravo databáze SQL. Odshora dolů jsou razítka 1 v oblasti USA – západ 2, která obsluhuje tenanty A, B a C; Kolek 2 v oblasti USA – západ 2, který slouží tenantovi D; Razítko 3 v oblasti USA – východ, které slouží tenantům E, F a G; Kolek 4 v západní Evropě, který slouží tenantům H, I a J; a Stamp 5 v Austrálii – východ, který slouží tenantům K, L a M. Pět razítek sdílí stejné vnitřní složení, ale liší se v oblasti a v sadě tenantů, které jsou jim přiřazeny, a oblast USA – západ 2 obsahuje dvě samostatná razítka, zatímco každá z ostatních oblastí obsahuje jedno razítko.

Razítka nasazení můžou platit bez ohledu na to, jestli vaše řešení používá komponenty IaaS (infrastruktura jako služba) nebo paaS (platforma jako služba) nebo kombinaci obou. Úlohy IaaS obvykle vyžadují větší zásah ke škálování, takže tento model může pomoct škálovat úlohy náročné na IaaS.

Razítka můžete použít k implementaci okruhů nasazení. Pokud různí zákazníci chtějí aktualizace služeb v různých frekvencích, seskupte je do různých instancí a nasazujte aktualizace na jednotlivé instance v různé frekvenci.

Razítka fungují nezávisle, takže implicitně rozčleňují vaše data. Jedno razítko může také interně použít další horizontální dělení, aby bylo možné škálovat a zůstat elastické.

Nasazení identických kopií stejných komponent je složité, proto jsou důležité osvědčené postupy DevOps. Popište svou infrastrukturu jako kód, aby nasazení každého prostředí bylo předvídatelné a opakovatelné.

Razítka nasazení se vztahují k geodes, ale liší se od nich. V architektuře nasazení typu 'stamp' každá nezávislá instance vašeho systému slouží části vašich zákazníků a uživatelů. V architektuře geode může každá instance obsluhovat požadavky od libovolného uživatele, ale tento přístup je obvykle složitější pro návrh a sestavení. Tyto dva vzory můžete také zkombinovat v rámci jednoho řešení. Příkladem takového hybridního scénáře je přístup směrování provozu popsaný dále v tomto článku.

Problémy a důležité informace

Při rozhodování o implementaci tohoto modelu zvažte následující body:

• Proces nasazení: Když nasadíte více razítek, automatizujte a plně zopakujte procesy nasazení. Pomocí modulů Bicep nebo Terraform deklarativně definovat razítka a zachovat konzistentní definice.

• Operace křížového razítka: Když řešení nasadíte nezávisle na několika razítkech, může být obtížné určit, kolik zákazníků máte na všech svých razítkech. Možná budete muset zadávat dotazy na každé razítko a agregovat výsledky. Alternativně můžete mít všechna razítka publikující data do centralizovaného datového skladu pro konsolidované vytváření sestav.

• Zásady horizontálního navýšení kapacity: Uzly mají omezenou kapacitu, kterou můžete definovat pomocí zástupné metriky, například počtem nájemníků, které lze nasadit na uzel. Monitorujte dostupnou a použitou kapacitu jednotlivých instancí a proaktivně nasaďte další instance, abyste na ně mohli směrovat nové zákazníky.

• Minimální počet razítek: Při použití vzoru Razítka nasazení nasaďte aspoň dvě razítka vašeho řešení. Pokud nasadíte jenom jedno razítko, můžete do kódu nebo konfigurace snadno pevně zakódovat předpoklady, které se při horizontálním navýšení kapacity nepoužijí.

• Náklady: Model Razítka nasazení nasazuje několik kopií komponent infrastruktury, což výrazně zvyšuje náklady na provoz vašeho řešení.

• Přechod mezi razítky: Každé razítko běží nezávisle, takže přesun tenantů mezi razítky může být obtížný. Vaše aplikace potřebuje vlastní logiku k přenosu informací zákazníka do jiného razítka a následnému odebrání informací o tenantovi z původního razítka. Tento proces může vyžadovat použití základní desky ke komunikaci mezi moduly, což dále zvyšuje složitost vašeho řešení.

• Směrování provozu: Jak je popsáno výše v článku, směrování provozu na správné "stamp" pro daný požadavek může vyžadovat další součástku, která překládá nájemníky na "stampy." Tato komponenta by možná mohla být vysoce dostupná.

• Pozorovatelnost napříč instancemi: S rostoucím počtem instancí je obtížnější porozumět celkovému zdraví a rychle detekovat incidenty. Pomocí Azure Monitor můžete shromažďovat a korelovat metriky, protokoly, tras, a výstrahy napříč všemi instancemi. Tato data slouží k identifikaci kolků, které nejsou v pořádku, a k diagnostice problémů.

• Dopad na regionální selhání: Stamps běží nezávisle, ale nejsou automaticky redundantní mezi regiony. Pokud oblast, která hostuje jedno nebo více razítek, přestane být dostupná, nájemníci na těchto razítkách ztratí přístup, dokud se oblast neobnoví, nebo dokud nemigrujete nájemníky na razítka v jiné oblasti. Pokud chcete naplánovat tento scénář, zdokumentujte postupy obnovení, nastavte očekávání tenanta a zvažte, jestli kritické tenanty potřebují geograficky redundantní umístění razítka.

• Sdílené komponenty: Možná máte komponenty, které můžete sdílet napříč instancemi. Pokud máte například sdílenou jednostránkovou aplikaci pro všechny tenanty, nasaďte ji do jedné oblasti a použijte k globální replikaci Azure Front Door ukládání do edge mezipaměti.

• Odchylka správy a konfigurace: S rostoucím počtem instancí je obtížnější zachovat zásady zabezpečení, RBAC (řízení přístupu na základě role), síťové kontroly, monitorovací schopnosti a konfigurace služeb konzistentní. Pomocí Azure Policy můžete zacházet se zásadami správného řízení jako s kódem a průběžně ověřovat všechna razítka, aby nedocházelo k nekonzistentnímu chování a mezerám v dodržování předpisů.

Kdy použít tento vzor

Tento model použijte v těchto případech:

• Vaše řešení má přirozené limity škálovatelnosti. Pokud například některé komponenty nemůžou nebo by se neměly škálovat nad rámec určitého počtu zákazníků nebo požadavků, použijte razítka k horizontálnímu navýšení kapacity.

• Potřebujete oddělit určité tenanty od ostatních. Pokud vám obavy o zabezpečení brání v nasazení některých zákazníků do víceklientského razítka, nasaďte je na vlastní izolované razítko.

• Některé tenanty musíte hostovat na různých verzích vašeho řešení najednou.

• Vytváříte aplikace ve více oblastech, které potřebují směrovat data a provoz jednotlivých tenantů do konkrétní oblasti.

• Chcete dosáhnout odolnosti během výpadků. Kolky se spouštějí nezávisle, takže pokud výpadek ovlivní jedno razítko, tenanti na jiných razítkech zůstanou nedotknuti. Tato izolace omezuje dosah incidentu nebo výpadku.

Tento vzor nemusí být vhodný v těchto případech:

• Vaše řešení je jednoduché a nemusí se škálovat na vysoký stupeň.

• Kapacitu systému můžete vertikálně navyšovat nebo navyšovat v rámci jedné instance, například zvýšením velikosti aplikační vrstvy nebo zvýšením rezervované kapacity pro databáze a vrstvu úložiště.

• Potřebujete replikovat data napříč všemi nasazenými instancemi. Zvažte model Geode pro tento scénář.

• Potřebujete škálovat jenom některé komponenty, nikoli jiné. Zvažte například, jestli můžete řešení škálovat horizontálním dělením úložiště dat místo nasazení nové kopie všech součástí řešení.

• Vaše řešení se skládá výhradně ze statického obsahu, jako je front-endová javascriptová aplikace. Doručovat tento obsah službou Content Delivery Network.

Návrh úloh

Vyhodnoťte, jak v návrhu úlohy využít vzor nasazovacích razítek k dosažení cílů a principů popsaných v pilířích Azure Well-Architected Framework. Následující tabulka obsahuje pokyny, jak tento model podporuje cíle jednotlivých pilířů.

Pilíř	Jak tento model podporuje cíle pilíře
Spolehlivostní rozhodnutí o návrhu pomáhají vaší pracovní zátěži stát se odolná proti poruchám a zajistit, aby se po selhání obnovila do plně funkčního stavu.	Datové známky fungují nezávisle, takže selhání v jednom razítku je izolované a nemá vliv na tenanty na jiných razítkách. Nasazení několika instancí napříč regiony také poskytuje základ pro plánování redundance a obnovy, což snižuje důsledky oblastních výpadků. - RE:05 Redundance - RE:07 Sebezáchování
Efektivita provozu pomáhá poskytovat kvalitu úloh prostřednictvím standardizovaných procesů a týmové soudržnosti.	Tento model podporuje neměnné cíle infrastruktury, pokročilé modely nasazení a může usnadnit bezpečné postupy nasazení. - OE:05 Infrastruktura jako kód - Postupy bezpečného nasazení OE:11
efektivita výkonu pomáhá vašim úlohám efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Tento vzor často odpovídá definovaným jednotkám škálování ve vaší úloze. Pokud potřebujete více kapacity než jedna jednotka škálování, nasadíte další razítko pro horizontální navýšení kapacity. - PE:05 Škálování a dělení

Pokud tento model představuje kompromisy v rámci pilíře, zvažte je proti cílům ostatních pilířů.

Příklad

Následující ukázková architektura používá Azure Front Door, Azure API Management a Azure Cosmos DB ke globálnímu směrování provozu na řadu regionálně specifických datových center.

Na úplně levé straně představuje vstupní bod Azure Front Door (globální). Uprostřed diagramu jsou tři vrstvy směrování regionálního provozu skládané svisle, jedna pro USA – západ 2, USA – východ a Austrálie – východ. V každé vrstvě se instance služby API Management nachází na levé straně a instance Azure Cosmos DB se nachází napravo a obousměrná šipka označená dotazem na razítko tenanta je spojuje. Svislé obousměrné šipky označené jako geografická replikace propojují tři Azure Cosmos DB instance. Azure Front Door se připojí pomocí obousměrných šipek ke všem třem instancím služby API Management. Úplně vpravo je pět razítek naskládané svisle. Každé razítko zobrazuje název a oblast, tenanty, které obsluhuje, a instanci služby App Service spárovanou s databází SQL. Razítka jsou razítka 1 (USA – západ 2) pro tenanty A, B a C; Razítko 2 (USA – západ 2) pro tenanta D; Razítko 3 (USA – východ) pro tenanty E, F a G; Razítko 4 (Západní Evropa) pro tenanty H, I a J; a Razítko 5 (Austrálie – východ) pro tenanty K, L a M. Zakřivené šipky vedou z instancí služby API Management na odpovídající razítka vpravo.

Předpokládejme, že se uživatel nachází v New Yorku. Razítko 3 v oblasti USA – východ ukládá data.

Pokud uživatel cestuje do Kalifornie a přistupuje k systému, systém přesměruje své připojení přes oblast USA – západ 2, protože tato oblast je k nim nejblíže, když žádost provede. Razítko 3 však musí požadavek nakonec obslouužit, protože ukládá data. Systém směrování provozu směruje požadavek na správné razítko.

Deployment

Popište infrastrukturu jako kód pomocí Bicep nebo Terraform. Tento přístup zajišťuje, že nasazení každé instance je předvídatelné a opakovatelné. Snižuje také pravděpodobnost lidských chyb, jako jsou náhodné neshody v nastavení mezi razítky.

Aktualizace můžete nasadit automaticky paralelně do všech instancí. Technologie jako Bicep mohou koordinovat nasazení infrastruktury a aplikací. Alternativně se můžete rozhodnout postupně zavádět aktualizace některých razítek a poté postupně na jiná razítka. Zvažte použití nástroje pro správu verzí, jako je Azure Pipelines nebo GitHub Actions, pro orchestrace nasazení do jednotlivých instancí.

Pečlivě zvažte topologii předplatných Azure a skupin prostředků pro vaše nasazení:

• Předplatné obvykle obsahuje všechny prostředky pro jedno řešení, proto zvažte použití jednoho předplatného pro všechna razítka. Nicméně, některé služby Azure ukládají kvóty na úrovni předplatného. Pokud tento model použijete k zajištění vysokého stupně horizontálního navýšení kapacity, možná budete muset nasadit razítka napříč různými předplatnými.

• Skupiny prostředků obvykle obsahují komponenty, které sdílejí stejný životní cyklus. Pokud plánujete provést aktualizace ve všech instancích najednou, můžete použít jednu skupinu prostředků, která obsahuje všechny komponenty pro všechny instance. Pomocí konvencí pojmenování prostředků a značek identifikujte komponenty, které patří do každého razítka. Případně, pokud plánujete nasadit aktualizace do každé instance nezávisle, můžete každou instanci nasadit do vlastní skupiny prostředků.

Plánování kapacity

Pomocí zátěžového a výkonnostního testování určete přibližné zatížení, které může dané razítko pojmout. Metriky načítání můžou být založeny na počtu zákazníků nebo tenantů, které může pojmout jeden stempel, nebo na metrikách, které generují služby ve stemplu. Instrumentujte každé razítko, abyste mohli měřit, kdy se blíží její kapacitě, a ujistěte se, že můžete rychle nasadit nové razítka, abyste mohli reagovat na poptávku.

Směrování provozu

Šablona Deployment Stamps funguje dobře, když řešíte každé razítko nezávisle. Pokud contoso například nasadí stejnou aplikaci API napříč několika razítky, může contoso použít dns (Domain Name System) ke směrování provozu na příslušné razítko:

• unit1.aus.myapi.contoso.com směruje provoz k identifikátoru unit1 v rámci australské oblasti.
• unit2.aus.myapi.contoso.com směruje provoz k identifikátoru unit2 v rámci australské oblasti.
• unit1.eu.myapi.contoso.com směruje provoz do značky unit1 v rámci evropského území.

V Azure můžete tyto záznamy hostovat v Azure DNS a pro každou oblast a razítko použít konzistentní konvenci subdomény. Tento přístup udržuje předvídatelné směrování a operace.

Klienti zodpovídají za připojení ke správnému identifikátoru.

Pokud vaše řešení vyžaduje pro veškerý provoz jeden bod příchozího přenosu dat, můžete pomocí služby směrování provozu přeložit razítko pro danou žádost, zákazníka nebo tenanta. Služba směrování provozu buď přesměruje klienta na příslušnou adresu URL razítka (například vrácením stavového kódu odpovědi HTTP 302), nebo funguje jako reverzní proxy server a předává provoz příslušnému razítku bez toho, aby klient věděl.

Centralizovaná služba směrování provozu může být složitou komponentou pro návrh, zejména pokud řešení běží napříč více oblastmi. Zvažte nasazení služby směrování provozu do několika oblastí, potenciálně včetně každé oblasti, která hostuje razítka, a synchronizaci úložiště dat, které mapuje tenanty na razítka. Komponenta směrování provozu může být sama o sobě instancí modelu Geode.

Službu API Management můžete například nasadit tak, aby fungovala jako služba směrování provozu. Služba API Management určí vhodnou značku pro požadavek na základě vyhledání dat v kolekci Azure Cosmos DB, která uchovává mapování mezi tenanty a značkami. API Management pak dynamicky nastaví back-endovou adresu URL na službu API příslušného razítka.

Pokud chcete geograficky distribuovat požadavky a poskytovat geografickou redundanci služby směrování provozu, nasadit správu API napříč několika oblastmi a "Azure Front Door" použít k směrování provozu do nejbližší brány správy API. V této topologii Azure Front Door používá origin groups, health probes a vhodnou metodu směrování k přesměrování požadavků od nefunkčních regionálních bran služby API Management. Api Management pak podle potřeby směruje na příslušné razítko pomocí mapování tenant-to-stamp a jeho back-endové konfigurace (nebo back-endových fondů), včetně pravidel převzetí služeb při selhání mezi koncovými body razítka. Pokud vaše aplikace není vystavená přes protokol HTTP nebo HTTPS, můžete k distribuci příchozích volání do regionálních Azure load balancerů použít meziregionální Azure load balancer. Pomocí globální distribuční funkce Azure Cosmos DB můžete udržovat informace o mapování aktualizované v jednotlivých regionech.

Pokud vaše řešení zahrnuje službu směrování provozu, zvažte, jestli funguje jako brána a může provádět snižování zátěže brány pro ostatní služby, jako je ověřování tokenů, omezování a autorizace.

Další kroky

• Azure Front Door
• Integrace Bicep se službou Azure Pipelines
• Integrace šablon JSON ARM se službou Azure Pipelines

Contributors

Společnost Microsoft udržuje tento článek. Tento článek napsali následující přispěvatelé.

Hlavní autor:

• John Downs | Hlavní softwarový inženýr, vzory a postupy Azure

Další přispěvatelé:

• Federico Arambarri | Senior Software Developer, Claria Consulting
• Daniel Larsen | Hlavní zákaznický inženýr, FastTrack pro Azure
• Angel Lopez | Vedoucí softwarový inženýr, vzory a postupy Azure
• Paolo Salvatori | Hlavní zákaznický inženýr, FastTrack pro Azure
• Arsen Vladimirskiy | Hlavní zákaznický inženýr, FastTrack pro Azure

Pokud chcete zobrazit nepublikované profily LinkedIn, přihlaste se k LinkedIn.

Související prostředky

• Horizontální dělení můžete použít jako další jednodušší přístup k horizontálnímu navýšení kapacity datové vrstvy. Kolky implicitně segmentují svá data, ale horizontální dělení nevyžaduje značku nasazení. Další informace najdete v tématu Vzor horizontálního dělení.
• Pokud vaše řešení nasadí službu směrování provozu, můžete zkombinovat vzory směrování brány a přesměrování zpracování brány , abyste tuto komponentu co nejlépe využili.