Model razítka nasazení

Model razítka nasazení zahrnuje zřizování, správu a monitorování heterogenní skupiny prostředků pro hostování a provoz více úloh nebo tenantů. Každá jednotlivá 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 může každé razítko nebo jednotka škálování obsluhovat předdefinovaný počet tenantů. Ke škálování řešení je možné nasadit více kolků téměř lineárně a poskytovat rostoucí počet tenantů. Tento přístup může zlepšit škálovatelnost vašeho řešení, umožňuje nasadit instance napříč několika oblastmi a oddělit zákaznická data.

Kontext a problém

Při hostování aplikace v cloudu je důležité zvážit výkon a spolehlivost vaší aplikace. Pokud hostujete jednu instanci vašeho řešení, může se jednat o následující omezení:

• Omezení škálování Nasazení jedné instance aplikace může vést k přirozeným omezením škálování. Můžete například použít služby, které mají omezení počtu příchozích připojení, názvů hostitelů, soketů TCP 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 dojít k náhlému snížení výkonu nebo zvýšení nákladů po dosažení prahové hodnoty. Můžete například použít databázi a zjistit, že mezní náklady na přidání větší kapacity (vertikální navýšení kapacity) jsou zakázané a že horizontální navýšení kapacity je nákladově efektivnější strategie.
• Oddělení zákazníků. Možná budete muset zachovat data určitých zákazníků izolovaná od dat jiných zákazníků. Podobně můžete mít některé zákazníky, kteří ke službě vyžadují více systémových prostředků než jiné, a zvažte jejich seskupení v různých sadách infrastruktury.
• Zpracování jednoklientských instancí a instancí s více tenanty Můžete mít některé velké zákazníky, kteří potřebují vlastní nezávislé instance vašeho řešení. Můžete mít také fond menších zákazníků, kteří můžou sdílet nasazení s více tenanty.
• 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.
• Frekvence aktualizace Můžete mít některé zákazníky, kteří jsou tolerantní k častým aktualizacím vašeho systému, zatímco jiné můžou být rizikové a chtějí občasné aktualizace systému, který jejich požadavky obsluhuje. Může být vhodné, aby tito zákazníci nasadili do izolovaných prostředí.
• Geografická nebo geopolitické omezení. Pokud chcete architektovat nízkou latenci 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 nezávislé dodavatele softwaru (ISV), kteří vytvářejí software jako službu (SaaS), které jsou často navržené tak, aby byly víceklientské. Stejná omezení ale můžou platit i pro jiné scénáře.

Řešení

Pokud se chcete těmto problémům vyhnout, zvažte seskupení prostředků v jednotkách škálování a zřízení více kopií razítek. Každá jednotka škálování bude hostovat a obsluhovat podmnožinu vašich tenantů. Kolky fungují nezávisle na sobě a lze je nasadit a aktualizovat nezávisle. Jedna geografická oblast může obsahovat jedno razítko nebo může obsahovat několik razítek, které umožní horizontální horizontální horizontální navýšení kapacity v rámci oblasti. Razítka obsahují podmnožinu vašich zákazníků.

Razítka nasazení můžou platit bez ohledu na to, jestli vaše řešení používá komponenty infrastruktury jako služby (IaaS) nebo paaS (platforma jako služba) nebo kombinaci obou. Úlohy IaaS obvykle vyžadují větší zásah ke škálování, takže model může být užitečný pro úlohy náročné na IaaS, které umožňují horizontální navýšení kapacity.

Razítka se dají použít k implementaci okruhů nasazení. Pokud různí zákazníci chtějí dostávat aktualizace služeb v různých frekvencích, můžou být seskupené na různá razítka a každé razítko může mít nasazené aktualizace v různých intervalech.

Vzhledem k tomu, že kolky běží nezávisle na sobě, data se implicitně horizontálně dělí. Kromě toho může jedno razítko využít další horizontální dělení, které interně umožňuje škálovatelnost a elasticitu v rámci razítka.

Model razítka nasazení používá interně mnoho služeb Azure, včetně App Service, Azure Stacku a Azure Storage.

Razítka nasazení se vztahují, ale liší se od geografických razítek. V architektuře razítka nasazení se nasadí několik nezávislých instancí vašeho systému a bude obsahovat podmnožinu vašich zákazníků a uživatelů. V geodách můžou všechny instance obsluhovat požadavky od všech uživatelů, ale tato architektura je často složitější pro návrh a sestavení. Můžete také zvážit kombinování těchto dvou vzorů v rámci jednoho řešení; Přístup směrování provozu popsaný dále v tomto článku je příkladem takového hybridního scénáře.

Nasazení

Kvůli složitosti, která se týká nasazování identických kopií stejných komponent, jsou dobré postupy DevOps nezbytné k zajištění úspěchu při implementaci tohoto modelu. Zvažte popis infrastruktury jako kódu, například pomocí bicep, šablon Azure Resource Manageru (šablon ARM), Terraformu a skriptů. Díky tomuto přístupu můžete zajistit, aby nasazení každého kolku bylo předvídatelné a opakovatelné. Snižuje také pravděpodobnost lidských chyb, jako jsou náhodné neshody v konfiguraci mezi kolky.

Aktualizace můžete nasadit automaticky do všech kolek paralelně, v takovém případě můžete zvážit technologie, jako jsou bicep nebo šablony Resource Manageru, aby bylo možné koordinovat nasazení infrastruktury a aplikací. Alternativně se můžete rozhodnout postupně zavádět aktualizace některých známek a pak postupně pro jiné. Zvažte použití nástroje pro správu verzí, jako je Azure Pipelines nebo GitHub Actions k orchestraci nasazení do jednotlivých kolků. Další informace naleznete v tématu:

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

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í, takže obecně zvažte použití jednoho předplatného pro všechna razítka. Některé služby Azure však ukládají kvóty pro celé předplatné, takže pokud tento model používáte, abyste umožnili vysoký stupeň horizontálního navýšení kapacity, možná budete muset zvážit nasazení kolků napříč různými předplatnými.
• Skupiny prostředků se obvykle používají k nasazení komponent se stejným životním cyklem. Pokud plánujete nasadit aktualizace všech razítek najednou, zvažte použití jedné skupiny prostředků, která bude obsahovat všechny komponenty pro všechny kolky, a pomocí konvencí vytváření názvů prostředků a značek identifikujte komponenty, které patří do každého razítka. Případně pokud plánujete nasadit aktualizace jednotlivých kolek nezávisle, zvažte nasazení každého kolku 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žené na počtu zákazníků nebo tenantů, na které se dá umístit jedno razítko, nebo metriky ze služeb, které komponenty v rámci kolku vygenerují. Ujistěte se, že máte dostatečnou instrumentaci pro měření, když se dané razítko blíží své kapacitě, a možnost rychle nasadit nové razítka, aby reagovala na poptávku.

Směrování provozu

Vzor razítka nasazení funguje dobře, pokud se každé razítko řeší nezávisle. Pokud například Contoso nasadí stejnou aplikaci API napříč několika razítky, může zvážit použití DNS ke směrování provozu do příslušného razítka:

• unit1.aus.myapi.contoso.com směruje provoz do kolku unit1 v rámci australské oblasti.
• unit2.aus.myapi.contoso.com směruje provoz do kolku unit2 v rámci australské oblasti.
• unit1.eu.myapi.contoso.com směruje provoz do kolku unit1 v rámci evropského regionu.

Klienti pak zodpovídají za připojení ke správnému razítku.

Pokud se vyžaduje jeden bod příchozího přenosu dat pro veškerý provoz, dá se služba směrování provozu použít k vyřešení kolku 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 pomocí stavového kódu odpovědi HTTP 302), nebo může fungovat jako reverzní proxy server a přesměrovávat provoz na příslušné razítko, aniž by 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, do které se nasazují razítka) a pak se ujistěte, že je úložiště dat (mapování tenantů na kolky) synchronizované. Komponenta směrování provozu může být sama o sobě instancí vzoru geode.

Služba Azure API Management může být například nasazena tak, aby fungovala v roli služby směrování provozu. Může určit odpovídající razítko pro požadavek vyhledáním dat v kolekci Azure Cosmos DB , do které se uloží mapování mezi tenanty a razítky. Služba API Management pak může dynamicky nastavit back-endovou adresu URL na příslušnou službu rozhraní API razítka.

Aby bylo možné povolit geografickou distribuci požadavků a geografickou redundanci služby směrování provozu, je možné službu API Management nasadit napříč několika oblastmi nebo pomocí služby Azure Front Door směrovat provoz do nejbližší instance. Front Door je možné nakonfigurovat s back-endovým fondem, který umožňuje směrovat požadavky na nejbližší dostupnou instanci služby API Management. Pokud vaše aplikace není přístupná přes PROTOKOL HTTP/S, můžete k distribuci příchozích volání do regionálních služeb Azure Load Balancer použít Azure Load Balancer mezi oblastmi. Funkci globální distribuce služby Azure Cosmos DB je možné použít k udržování informací o mapování aktualizovaných napříč jednotlivými oblastmi.

Pokud je služba směrování provozu součástí vašeho řešení, zvažte, jestli funguje jako brána , a proto by mohla 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.

Příklad architektury směrování provozu

Podívejte se na následující příklad architektury směrování provozu, která používá Azure Front Door, Azure API Management a Azure Cosmos DB pro globální směrování provozu a pak řadu razítek specifických pro oblast:

Předpokládejme, že se uživatel obvykle nachází v New Yorku. Jejich data jsou uložená v razítku 3 v oblasti USA – východ.

Pokud uživatel cestuje do Kalifornie a pak přistupuje k systému, bude jeho připojení pravděpodobně směrováno přes oblast USA – západ 2, protože je nejblíže místu, kde jsou geograficky při vytváření žádosti. Požadavek však musí být nakonec obsluhován razítkem 3, protože tam jsou uložena jejich data. Systém směrování provozu zajišťuje směrování požadavku na správné razítko.

Problémy a důležité informace

Když se budete rozhodovat, jak tento model implementovat, měli byste vzít v úvahu následující skutečnosti:

• Proces nasazení Při nasazování více razítek je velmi vhodné mít automatizované a plně opakovatelné procesy nasazení. Zvažte použití bicep, šablon JSON ARM nebo modulů Terraformu k deklarativnímu definování razítek a zachování konzistentních definic.
• Operace křížového razítka Když se vaše řešení nasadí nezávisle na několika razítkech, můžou být otázky, jako je například "kolik zákazníků máme na všech našich kolcích?", složitější, aby bylo možné odpovědět. Dotazy může být potřeba spouštět pro každé razítko a agregované výsledky. Případně zvažte, jestli všechna razítka publikují data do centralizovaného datového skladu pro konsolidované generování sestav.
• Určení zásad horizontálního navýšení kapacity Kolky mají omezenou kapacitu, která se může definovat pomocí metriky proxy serveru, jako je počet tenantů, které je možné nasadit do kolku. Je důležité monitorovat dostupnou kapacitu a využitou kapacitu pro každé razítko a proaktivně nasadit další razítka, aby se na ně mohli nasměrovat noví tenanti.
• Minimální počet razítek. Pokud používáte model razítka nasazení, doporučujeme nasadit aspoň dvě razítka vašeho řešení. Pokud nasadíte jenom jedno razítko, je snadné náhodně pevně zakódovat předpoklady do kódu nebo konfigurace, které se při horizontálním navýšení kapacity nepoužijí.
• Náklady: Model razítka nasazení zahrnuje nasazení více kopií komponenty infrastruktury, což bude pravděpodobně znamenat značné zvýšení nákladů na provoz vašeho řešení.
• Pohyb mezi razítky. Každé razítko se nasazuje a provozuje nezávisle, takže přesun tenantů mezi kolky může být obtížné. Vaše aplikace by potřebovala vlastní logiku k přenosu informací o daném zákazníkovi 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 backplane pro komunikaci mezi kolky, což dále zvyšuje složitost celkového řešení.
• Směrování provozu. Jak je popsáno výše v tomto článku, směrování provozu na správné razítko pro danou žádost může vyžadovat další komponentu pro překlad tenantů na kolky. Tato komponenta může být zase potřeba nastavit jako vysoce dostupnou.
• Sdílené komponenty. Můžete mít některé komponenty, které se dají sdílet napříč kolky. Pokud máte například sdílenou jednostránkovou aplikaci pro všechny tenanty, zvažte nasazení do jedné oblasti a použití Azure CDN k jeho globální replikaci.

Kdy se má tento model použít

Tento vzor je užitečný, pokud máte:

• Přirozená omezení š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ů, zvažte horizontální navýšení kapacity pomocí razítek.
• Požadavek na oddělení určitých tenantů od ostatních. Pokud máte zákazníky, kteří nemohou být nasazeni do víceklientských kolek s jinými zákazníky kvůli obavám o zabezpečení, můžete je nasadit na vlastní izolovaný kolek.
• Na různých verzích vašeho řešení je potřeba mít současně několik tenantů.
• Aplikace s více oblastmi, ve kterých by se data a provoz jednotlivých tenantů měly směrovat do konkrétní oblasti.
• Touha dosáhnout odolnosti během výpadků. Vzhledem k tomu, že kolky jsou nezávislé na sobě, pokud výpadek ovlivní jedno razítko, pak by to nemělo mít vliv na tenanty nasazené na jiné razítko. Tato izolace pomáhá obsahovat "poloměr výbuchu" incidentu nebo výpadku.

Tento model není vhodný pro:

• Jednoduchá řešení, která nemusí škálovat na vysoký stupeň.
• Systémy, které je možné snadno škálovat 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ě.
• Řešení, ve kterých se mají data replikovat napříč všemi nasazenými instancemi. Vezměte v úvahu model geografického šifrování pro tento scénář.
• Řešení, ve kterých je potřeba škálovat jenom některé komponenty, ale ne jiné. Zvažte například, jestli by vaše řešení mohlo být škálované horizontálním dělením úložiště dat, a ne nasazením nové kopie všech součástí řešení.
• Řešení se skládají výhradně ze statického obsahu, jako je front-endová javascriptová aplikace. Zvažte uložení takového obsahu do účtu úložiště a použití Azure CDN.

Návrh úloh

Architekt by měl vyhodnotit způsob použití modelu Razítka nasazení v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

Podpůrné technologie

• Infrastruktura jako kód Například Bicep, šablony Resource Manageru, Azure CLI, Terraform, PowerShell, Bash.
• Azure Front Door, který může směrovat provoz na konkrétní kolek nebo do služby směrování provozu.

Příklad

Následující příklad nasadí několik razítek jednoduchého řešení PaaS s aplikační službou a databází SQL v každém razítku. I když je možné kolky nakonfigurovat v libovolné oblasti, které podporují služby nasazené v šabloně, pro ilustraci tato šablona nasadí dvě razítka v oblasti USA – západ 2 a další razítko v oblasti Západní Evropa. V rámci razítka služba App Service obdrží vlastní veřejný název hostitele DNS a může přijímat připojení nezávisle na všech ostatních razítkech.

Kliknutím na odkaz níže nasaďte řešení.

Příklad přístupu směrování provozu

Následující příklad nasadí implementaci řešení směrování provozu, které se dá použít se sadou razítek nasazení pro hypotetickou aplikaci API. Aby bylo možné povolit geografickou distribuci příchozích požadavků, služba Front Door se nasadí společně s několika instancemi služby API Management na úrovni consumption. Každá instance služby API Management načte ID tenanta z adresy URL požadavku a pak vyhledá příslušné razítko požadavku z geograficky distribuovaného úložiště dat Azure Cosmos DB. Žádost se pak přepošla na příslušné back-endové razítko.

Kliknutím na odkaz níže nasaďte řešení.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

• John Downs | Hlavní programový manažer

Další přispěvatelé:

• Daniel Larsen | Hlavní zákaznický inženýr, FastTrack pro Azure
• Angel Lopez | Vedoucí softwarový inženýr, vzory a postupy Azure
• Paul Salvatori | Hlavní zákaznický inženýr, FastTrack pro Azure
• Vladimirskij Vladimirskij | Hlavní zákaznický inženýr, FastTrack pro Azure

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Související prostředky

• Horizontální dělení je možné použít jako jiný, jednodušší přístup k horizontálnímu navýšení kapacity datové vrstvy. Kolky implicitně shardují svá data, ale horizontální dělení nevyžaduje razítko nasazení. Další informace najdete v tématu Model horizontálního dělení.
• Pokud je nasazená služba směrování provozu, je možné společně použít vzory směrování brány a přesměrování zpracování brány, aby se tato komponenta co nejlépe využila.