Model nasazování kolků

Článek
08/11/2021
11 min ke čtení

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é kopii se říká kolek nebo někdy jednotka služby nebo jednotka škálování. V prostředí s více tenanty může každý kolek nebo jednotka škálování obsluhovat předdefinovaný počet tenantů. Pro škálování řešení téměř lineárně a obsluhující rostoucí počet tenantů je možné nasadit několik razítek. Tento přístup může zlepšit škálovatelnost vašeho řešení, umožnit nasazení instancí napříč několika oblastmi a oddělit zákaznická data.

Kontext a problém

Při hostování aplikace v cloudu je třeba vzít v úvahu určité aspekty. Jednou z klíčových věcí, kterou je třeba mít na paměti, je výkon a spolehlivost vaší aplikace. Pokud hostíte jednu instanci vašeho řešení, může pro vás být uvedená následující omezení:

Omezení škálování. Nasazení jedné instance aplikace může vést k omezením přirozeného š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í se nemusí škálovat lineárně s počtem požadavků nebo množstvím dat. Místo toho může po překročení prahové hodnoty dosáhnět náhlého snížení výkonu nebo zvýšení nákladů. Můžete například použít databázi a zjistit, že mezní náklady na přidání další kapacity (horizontální navýšení kapacity) jsou přílišné a že horizontální navýšení kapacity je cenově výhodnější strategie. Podobně platí, Azure Front Door má vyšší ceny za doménu, když se nasadí vysoký počet vlastních domén, a může být lepší vlastní domény rozložit napříč několika Front Door instancemi.
Oddělení zákazníků. Možná budete muset zachovat určitá data zákazníků izolovaná od dat jiných zákazníků. Podobně můžete mít některé zákazníky, kteří potřebují ke službě více systémových prostředků než jiní, a zvážit jejich seskupení do různých sad infrastruktury.
Zpracování instancí s jedním a více tenanty Můžete mít několik velkých zákazníků, kteří potřebují vlastní nezávislé instance vašeho řešení. Můžete mít také fond menších zákazníků, kteří mohou sdílet nasazení s více tenanty.
Složité požadavky na nasazení. Možná budete muset do služby nasazovat aktualizace řízeným způsobem a v různou dobu je nasazovat do různých podmnožiny zákaznické základny.
Frekvence aktualizací. Můžete mít některé zákazníky, kteří jsou tolerantní k častým aktualizacím vašeho systému, zatímco jiní naopak mohou být riziková a chtějí občasné aktualizace systému, který své požadavky poskytuje. Může mít smysl, aby se tito zákazníci nasadili do izolovaných prostředí.
Geografická nebo geopolitická omezení. Pokud chcete nasazovat architekturu s nízká latence nebo splňovat požadavky na suverenitu dat, můžete některé ze svých zákazníků nasadit do konkrétních oblastí.

Ř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í několika 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 je možné je nasadit a aktualizovat nezávisle. Jedna geografická oblast může obsahovat jeden kolek nebo může obsahovat více razítek, aby bylo možné horizontální škálování v rámci oblasti. Kolky obsahují podmnožinu vašich zákazníků.

Příklad sady stampů nasazení

Nasazovací razítka můžete použít 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 obojího. Úlohy IaaS obvykle vyžadují větší zásah při škálování, takže tento 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 je možné použít k implementaci okruhů nasazení. Pokud skupině zákazníků chcete dostávat aktualizace služeb s různou frekvencí, můžete je seskupit do různých razítek a každý kolek může mít aktualizace nasazené v různou frekvenci.

Vzhledem k tomu, že kolky běží nezávisle na sobě, data se implicitně sharduje. Kromě toho může jeden kolek využívat další horizontální dělení, aby bylo možné interně zajistit škálovatelnost a elasticitu v rámci kolku.

Model razítka nasazení používá interně řada služeb Azure, včetně App Service, Azure Stacka Azure Storage.

Razítka nasazení se vztahují k geodám , ale liší se od geografických razítek. V architektuře razítka nasazení se nasadí několik nezávislých instancí systému, které obsahují podmnožinu vašich zákazníků a uživatelů. V geografických lokacích mohou všechny instance obsluhovat žádosti od libovolného uživatele, ale tato architektura je často složitější navrhovat a sestavovat. Můžete také zvážit kombinaci těchto dvou vzorů v rámci jednoho řešení. Příkladem takového hybridního scénáře je níže popsaný přístup ke směrování provozu.

Nasazení

Vzhledem ke složitosti, která je součástí nasazení identických kopií stejných komponent, jsou dobré DevOps postupy pro zajištění úspěchu při implementaci tohoto modelu. Zvažte popis infrastruktury jako kódu, například pomocí Bicep,JSON Azure Resource Manager (šablony ARM), Terraformua skriptů. S tímto přístupem můžete zajistit, aby nasazení jednotlivých razítek 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 razítek paralelně. V takovém případě můžete zvážit technologie, jako jsou šablony Resource Manager nebo Azure Deployment Manager, abyste koordinovaly nasazení infrastruktury Resource Manager aplikací. Alternativně se můžete rozhodnout, že aktualizace postupně zasazovat nejprve do některých razítek a pak postupně u ostatních. Azure Deployment Manager tento typ fázi zavedení také spravovat, nebo můžete zvážit použití nástroje pro správu verzí, jako je Azure Pipelines k orchestraci nasazení do jednotlivých razítek. Další informace naleznete v tématu:

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

Předplatné obvykle bude obsahovat všechny prostředky pro jedno řešení, takže obecně zvažte použití jednoho předplatného pro všechny kolky. Některé služby Azurevšak zasahují kvóty pro celé předplatné, takže pokud tento model používáte k umožnění vysokého stupně škálování na více než jeden, možná budete muset zvážit nasazení kolků napříč různými předplatným.
Skupiny prostředků se obecně používají k nasazení komponent se stejným životním cyklem. Pokud máte v plánu nasadit aktualizace do všech razítek najednou, zvažte použití jedné skupiny prostředků, která bude obsahovat všechny komponenty pro všechny vaše razítka, a pomocí zásad vytváření názvů prostředků a značek identifikujte komponenty, které patří ke každému razítku. Případně pokud máte v plánu nasadit aktualizace do jednotlivých razítek nezávisle, zvažte nasazení každého razítka 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ý kolek pojmout. Metriky zatížení mohou být založené na počtu zákazníků nebo tenantů, které může jeden kolek pojmout, nebo metrik ze služeb, které vysílaly komponenty v rámci kolku. Ujistěte se, že máte dostatečnou instrumentaci pro měření toho, kdy se daný kolek blíží ke své kapacitě, a schopnost rychle nasadit nové kolky pro reakci na poptávku.

Směrování provozu

Model Razítko nasazení funguje dobře, pokud se každý kolek řeší nezávisle. Pokud třeba Contoso nasadí stejnou aplikaci API napříč několika kolky, může zvážit použití DNS ke směrování provozu na příslušné razítko:

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

Klienti jsou pak zodpovědní za připojení ke správnému kolku.

Pokud se vyžaduje jeden bod příchozího přenosu dat pro veškerý provoz, může být služba směrování provozu použita k překladu razítka pro daný požadavek zákazníka nebo tenanta. Služba směrování provozu buď smě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ředávat provoz na příslušný kolek, aniž by o tom klient věděl.

Centralizovaná služba směrování provozu může být složitou komponentou pro návrh, zejména v případě, že řešení běží napříč několika oblastmi. Zvažte nasazení služby směrování provozu do několika oblastí (potenciálně včetně všech oblastí, ve které jsou nasazené razítka) a zajištění synchronizace úložiště dat (mapování tenantů na razítka). Komponenta směrování provozu může být sama instancí vzoru geografické geografické oblasti.

Můžete například nasadit službu Azure API Management, která bude fungovat v roli služby směrování provozu. Může určit vhodný kolek pro požadavek tak, že bude hledat data v kolekci Cosmos DB, která ukládá mapování mezi tenanty a kolky. API Management pak dynamicky nastavit back-endovou adresu URL na službu API příslušného kolku.

Pokud chcete povolit geografickou distribuci požadavků a geografickou redundanci služby směrování provozu, API Management jemožné nasadit napříč několika oblastmi nebo Azure Front Door je možné použít ke směrování provozu do nejbližší instance. Front Door můžete nakonfigurovat s back-endovýfondem, který umožňuje směrovat požadavky na nejbližší dostupnou API Management instanci. Pokud vaše aplikace není přístupná prostřednictvím PROTOKOLU HTTP/S, můžete k distribuci příchozích Azure Load Balancer do regionálních Load Balancerů Azure použít nástroj pro vyrovnávání zatížení napříč oblastmi. Funkci globální distribuce služby Azure Cosmos DB je možné použít k aktualizaci mapových informací v jednotlivých oblastech.

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

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 služby, jako je ověřování tokenů, omezování a autorizace.

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 se důrazně doporučuje mít automatizované a plně opakovatelné procesy nasazení. Zvažte použití modulů Bicep, JSON ARMnebo Terraform k deklarativně definovat kolek.
Operace napříč razítky. Když se vaše řešení nasadí nezávisle na několika razítecích, můžete si klást otázky jako "kolik zákazníků máme napříč všemi našimi kolky?". může být složitější pro zodpovězení. U každého razítka a výsledků, které jsou shrnuty, může být nutné provést dotazy. Případně můžete zvážit, že všechna razítka publikují data do centralizovaného datového skladu pro konsolidovaná hlášení.
Určování zásad škálování na více instancí. Razítka mají konečnou kapacitu, která může být definována pomocí metriky proxy serveru, jako je například počet klientů, které lze do razítka nasadit. Je důležité monitorovat dostupnou kapacitu a využitou kapacitu pro jednotlivá razítka a aktivně nasazovat další razítka, aby bylo možné do nich směrovat nové klienty.
Náklady: Vzor razítka nasazení zahrnuje nasazení více kopií vaší komponenty infrastruktury, což bude mít za následek výrazné zvýšení nákladů na provoz vašeho řešení.
Přesun mezi razítky. Jelikož je každé razítko nasazeno a provozováno nezávisle, přesun klientů mezi razítky může být obtížné. Vaše aplikace bude potřebovat vlastní logiku pro přenos informací o daném zákazníkovi na jiné razítko a následné odebrání informací o klientovi z původního razítka. Tento proces může vyžadovat plán pro komunikaci mezi razítky a dále zvyšovat složitost celkového řešení.
Směrování provozu. Jak je popsáno výše, směrování provozu do správného razítka pro danou žádost může vyžadovat další komponentu k překladu klientů na razítka. Tato součást pak může být potřeba nastavit jako vysoce dostupný.
Sdílené součásti. Je možné, že máte některé komponenty, které lze sdílet přes razítka. pokud máte například sdílenou jednostránkovou aplikaci pro všechny klienty, zvažte její nasazení do jedné oblasti a použití Azure CDN k jejímu replikaci globálně.

Kdy se má tento model použít

Tento model je užitečný v případě, že máte následující:

Přírodní omezení škálovatelnosti. Pokud například některé součásti nemůžou nebo by neměly přesahovat určitý počet zákazníků nebo žádostí, zvažte horizontální navýšení kapacity pomocí razítek.
Požadavek na oddělení určitých klientů od ostatních. Pokud máte zákazníky, kteří se nedají nasadit do víceúrovňového razítka s jinými zákazníky kvůli bezpečnostním hlediskům, dají se nasadit na vlastní izolované razítko.
Musíte mít nějaké klienty v různých verzích řešení současně.
Aplikace s více oblastmi, ve kterých se data a přenosy každého klienta přesměrují do konkrétní oblasti.
Přání dosáhnout odolnosti během výpadků. Jelikož jsou razítka nezávislá na sobě, pokud výpadek ovlivňuje jedno razítko, neměli by to mít vliv na klienty nasazené na jiná razítka. Tato izolace pomáhá obsahovat "" vysokého "poloměru incidentu nebo výpadku.

Tento model není vhodný pro:

Jednoduchá řešení, která nemusíte škálovat na vysoký stupeň.
Systémy, které je možné snadno škálovat v rámci jedné instance, například zvětšením velikosti vrstvy aplikace nebo zvýšením rezervované kapacity pro databáze a vrstvu úložiště.
Řešení, ve kterých mají být data replikována napříč všemi nasazenými instancemi. Zvažte vzor Geode pro tento scénář.
Řešení, ve kterých je třeba škálovat pouze některé součásti, ale ne jiné. Například zvažte, zda může být řešení upraveno tak, že horizontálního dělení úložiště dat místo nasazení nové kopie všech součástí řešení.
Řešení skládající se výhradně ze statického obsahu, jako je aplikace front-end JavaScript. Zvažte uložení takového obsahu v účtu úložiště a pomocí Azure CDN.

Podpůrné technologie

Infrastruktura jako kód. Například Správce prostředků šablony, Azure CLI, Terraformu, PowerShell, bash.
Správce nasazení, která může orchestrovat nasazení řešení napříč více razítky.
Přední dveře Azure, které můžou směrovat provoz na konkrétní razítko nebo na službu Směrování provozu.

Příklad

následující příklad nasadí několik razítek jednoduchého řešení PaaS s app service a SQL Database v každém razítku. I když lze razítka nakonfigurovat v libovolné oblasti, která podporuje služby nasazené v šabloně, pro ilustraci Tato šablona nasadí dvě razítka v Západní USA 2 oblasti a další razítko v Západní Evropa oblasti. Služba App Service v rámci razítka obdrží svůj vlastní veřejný název hostitele DNS a může přijímat připojení nezávisle na všech ostatních razítkách.

Upozornění

následující příklad používá účet správce SQL Server. Obecně se nedoporučuje používat účet správce z vaší aplikace. v případě reálné aplikace zvažte použití spravované identity pro připojení z vaší aplikace k databázi SQLnebo použijte účet s oprávněními k minimálnímu oprávnění.

Kliknutím na níže uvedený odkaz nasazení řešení nasadíte.

Poznámka

Existují alternativní přístupy k nasazení razítek pomocí šablony Správce prostředků, včetně použití vnořených šablon nebo propojených šablon k oddělení definice všech razítek z iterace potřebné k nasazení více kopií.

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

V následujícím příkladu se nasadí implementace řešení směrování provozu, které se dá použít se sadou razítek nasazení pro hypotetickou aplikaci API. V rámci umožnění geografické distribuce příchozích požadavků se přední dveře nasazují společně s více instancemi API Management na úrovni spotřeby. každá instance API Management čte ID tenanta z adresy URL požadavku a pak vyhledá příslušné razítko pro požadavek z geograficky distribuovaného úložiště dat Cosmos DB. Požadavek se pak přepošle na příslušné razítko back-endu.