Existuje mnoho způsobů, jak ve vašem řešení pracovat s tenanty. Volba přístupu závisí na tom, jestli a jak sdílíte prostředky mezi tenanty. Intuitivně se můžete chtít vyhnout sdílení jakýchkoli prostředků, ale tento přístup se rychle ztěžuje, protože vaše obchodní škálování a onboardujete více tenantů.
Když uvažujete o různých modelech víceklientské architektury, je vhodné nejprve vzít v úvahu, jak definujete tenanty pro vaši organizaci, jaké obchodní faktory jsou a jak plánujete škálovat řešení. Tento článek obsahuje pokyny k tomu, aby pracovníci s rozhodovací pravomocí pomohli vyhodnotit modely tenantů a jejich kompromisy.
Definování tenanta
Nejprve musíte definovat tenanta pro vaši organizaci. Zvažte, kdo je váš zákazník. Jinými slovy, komu poskytujete své služby? Existují dva běžné modely:
- B2B (Business to Business). Pokud jsou vaši zákazníci dalšími organizacemi, pravděpodobně namapujete tenanty na tyto zákazníky. Zvažte ale, jestli mají vaši zákazníci divize (týmy nebo oddělení) a jestli jsou přítomni ve více zemích nebo oblastech. Pokud pro tyto podskupiny existují různé požadavky, budete možná muset namapovat jednoho zákazníka na více tenantů. Podobně může zákazník chtít udržovat dvě instance vaší služby, aby si mohl udržovat vývojová a produkční prostředí oddělená od sebe. Obecně platí, že jeden tenant má více uživatelů. Například všichni zaměstnanci zákazníka jsou uživatelé v rámci jednoho tenanta.
- B2C (Business to Consumer). Pokud jsou vaši zákazníci spotřebiteli, je často složitější spojit zákazníky, tenanty a uživatele. V některých scénářích může být každý příjemce samostatným tenantem. Zvažte ale, jestli by vaše řešení mohly používat rodiny, skupiny přátel, kluby, asociace nebo jiné skupiny, které by mohly potřebovat přístup k datům a spravovat je společně. Služba streamování hudby může například podporovat jednotlivé uživatele i rodiny a může s těmito typy účtů zacházet odlišně, když je rozdělí do tenantů.
Definice tenanta má vliv na některé věci, které je potřeba vzít v úvahu nebo zdůraznit při návrhu řešení. Představte si například tyto typy tenantů:
- Pokud jsou vaši tenanti jednotliví lidé nebo rodiny, budete se možná muset zabývat zejména tím, jak zpracováváte osobní údaje, a zákony o suverenitě dat v každé jurisdikci, kterou používáte.
- Pokud jsou vaši tenanti podniky, možná budete muset mít na paměti požadavky zákazníků na dodržování právních předpisů, izolaci jejich dat a zajištění splnění zadaného cíle na úrovni služeb (SLO), jako je dostupnost provozu nebo dostupnosti služeb.
Jak se rozhodnete, který model použít?
Výběr modelu tenantů není jen technické rozhodnutí. Je to také obchodní rozhodnutí. Je potřeba vzít v úvahu otázky, jako jsou tyto:
- Jaké jsou vaše obchodní cíle?
- Budou vaši zákazníci přijímat všechny formy víceklientské architektury? Jak každý model s více tenanty ovlivňuje vaše požadavky na dodržování předpisů nebo požadavky vašich zákazníků na dodržování předpisů?
- Bude řešení s jedním tenantem škálovat na vaše budoucí růstové očekávání?
- Jak velký je provozní tým a kolik vaší správy infrastruktury můžete automatizovat?
- Očekávají vaši zákazníci, že splníte smlouvy o úrovni služeb (SLA), nebo máte cíle smluv SLA, na které se zaměřujete?
Pokud očekáváte, že vaše firma bude škálovat na velký počet zákazníků, je důležité nasadit sdílenou infrastrukturu. Jinak budete muset udržovat velkou a rostoucí skupinu instancí prostředků. Nasazení jednotlivých prostředků Azure pro každého zákazníka pravděpodobně nebude možné, pokud nezřídíte a nepoužijete vyhrazené předplatné pro každého tenanta. Když sdílíte stejné předplatné Azure napříč několika tenanty, můžou se začít uplatňovat kvóty a limity prostředků Azure a provozní náklady na nasazení a překonfigurování těchto prostředků u každého nového zákazníka.
Pokud naopak očekáváte, že vaše firma bude mít jenom několik zákazníků, můžete zvážit použití prostředků s jedním tenantem, které jsou vyhrazené pro každého zákazníka. Pokud jsou požadavky vašich zákazníků na izolaci vysoké, může být vhodný přístup k infrastruktuře s jedním tenantem, i když je nákladnější.
Tenanti a nasazení
Dále musíte určit, co znamená tenant pro konkrétní řešení a jestli byste měli rozlišovat mezi logickými tenanty a nasazeními.
Představte si například službu streamování hudby. Zpočátku můžete vytvořit řešení, které může snadno zvládnout tisíce (nebo dokonce desítky tisíc uživatelů). S tím, jak budete pokračovat, ale můžete zjistit, že budete muset duplikovat své řešení nebo některé jeho komponenty, aby bylo možné škálovat na nové požadavky zákazníků. To znamená, že potřebujete určit, jak přiřadit konkrétní zákazníky ke konkrétním instancím vašeho řešení. Zákazníky můžete přiřadit náhodně nebo geograficky, nebo vyplněním jedné instance a následným spuštěním jiné instance (balení přihrádek). Pravděpodobně ale budete muset udržovat záznam o vašich zákaznících a o tom, na jaké infrastruktuře jsou jejich data a aplikace k dispozici, abyste mohli směrovat provoz do správné infrastruktury. V tomto příkladu můžete každého zákazníka reprezentovat jako samostatného tenanta a pak namapovat uživatele na nasazení, které obsahuje jejich data. Máte mapování 1:N mezi tenanty a nasazeními a tenanty můžete přesouvat mezi nasazeními podle vlastního uvážení.
Naproti tomu zvažte společnost, která vytváří cloudový software pro právní firmy. Vaši zákazníci můžou trvat na tom, aby měli vlastní vyhrazenou infrastrukturu pro zachování standardů dodržování předpisů. Proto musíte být připraveni na nasazení a správu mnoha různých instancí vašeho řešení od začátku. V tomto příkladu nasazení vždy obsahuje jednoho tenanta a tenant se mapuje na vlastní vyhrazené nasazení.
Klíčovým rozdílem mezi tenanty a nasazeními je způsob vynucení izolace. Když několik tenantů sdílí jedno nasazení (sadu infrastruktury), obvykle spoléháte na kód aplikace a identifikátor tenanta, který je v databázi, aby byla data každého tenanta oddělená. Pokud máte tenanty s vlastními vyhrazenými nasazeními, mají vlastní infrastrukturu, takže může být méně důležité, aby váš kód věděl, že funguje ve víceklientském prostředí.
Nasazení se někdy označují jako supertenanti nebo razítka.
Když obdržíte žádost o konkrétního tenanta, musíte ji namapovat na nasazení, které obsahuje data daného tenanta, jak je znázorněno tady:
Další informace najdete v tématu Mapování požadavků na tenanty.
Izolace tenanta
Jedním z největších aspektů návrhu víceklientické architektury je úroveň izolace, kterou každý tenant potřebuje. Izolace může znamenat různé věci:
- Mít jednu sdílenou infrastrukturu s samostatnými instancemi vaší aplikace a samostatnými databázemi pro každého tenanta.
- Sdíleníněkterýchch
- Udržování dat v samostatné fyzické infrastruktuře V cloudu může tato konfigurace vyžadovat samostatné prostředky Azure pro každého tenanta. V extrémních situacích může dokonce znamenat nasazení samostatné fyzické infrastruktury pomocí vyhrazených hostitelů.
Spíše než přemýšlet o izolaci jako diskrétní vlastnost, měli byste přemýšlet o tom, že je na kontinuu. V závislosti na vašich požadavcích můžete nasadit komponenty architektury, které jsou více nebo méně izolované než jiné komponenty ve stejné architektuře. Následující diagram znázorňuje kontinuum izolace:
Úroveň izolace ovlivňuje mnoho aspektů vaší architektury, včetně následujících:
- Zabezpečení. Pokud sdílíte infrastrukturu mezi více tenanty, musíte být obzvláště opatrní, abyste při návratu odpovědí do jiného nemuseli přistupovat k datům z jednoho tenanta. Potřebujete silný základ pro strategii identity a v procesu autorizace je potřeba zvážit jak identitu tenanta, tak i uživatele.
- Náklady: Sdílenou infrastrukturu může používat více tenantů, takže je levnější.
- Výkon. Pokud sdílíte infrastrukturu, může výkon vašeho systému trpět tím, že ho používají více zákazníků, protože prostředky můžou být využity rychleji. Problémysch
- Spolehlivost. Pokud používáte jednu sadu sdílené infrastruktury, může problém s jednou komponentou způsobit výpadek pro všechny tenanty.
- Rychlost odezvy na potřeby jednotlivých tenantů Když nasadíte infrastrukturu vyhrazenou pro jednoho tenanta, možná budete moct přizpůsobit konfiguraci pro prostředky tak, aby odpovídaly požadavkům daného tenanta. Tuto funkci můžete dokonce zvážit ve svém cenovém modelu, což zákazníkům umožní platit za izolovaná nasazení.
Vaše architektura řešení může ovlivnit dostupné možnosti izolace. Představte si například třívrstvou architekturu řešení:
- Vaše úroveň uživatelského rozhraní může být sdílená víceklientská webová aplikace se všemi tenanty, kteří přistupují k jednomu názvu hostitele.
- Střední vrstvou může být sdílená aplikační vrstva se sdílenými frontami zpráv.
- Vaše datová vrstva může být izolovaná databáze, tabulky nebo kontejnery objektů blob.
Na každé úrovni můžete zvážit použití různých úrovní izolace. Měli byste se rozhodnout, co je sdílené a co je izolované na mnoha aspektech, včetně nákladů, složitosti, požadavků zákazníků a počtu prostředků, které můžete nasadit před dosažením kvót a limitů Azure.
Běžné modely tenantů
Po vytvoření požadavků je vyhodnoťte podle některých běžných modelů tenantů a odpovídajících vzorů nasazení.
Automatizovaná nasazení s jedním tenantem
V automatizovaném modelu nasazení s jedním tenantem nasadíte vyhrazenou sadu infrastruktury pro každého tenanta, jak je znázorněno v tomto příkladu:
Vaše aplikace zodpovídá za iniciování a koordinaci nasazení prostředků jednotlivých tenantů. Řešení, která tento model používají, obvykle používají infrastrukturu jako kód (IaC) nebo rozhraní API Azure Resource Manageru. Tento přístup můžete použít v případě, že potřebujete pro každého zákazníka zřídit zcela samostatné infrastruktury. Při plánování nasazení zvažte použití vzoru Razítka nasazení.
Výhody: Klíčovou výhodou tohoto přístupu je, že data pro každého tenanta jsou izolovaná, což snižuje riziko náhodného úniku. Tato ochrana může být důležitá pro některé zákazníky, kteří mají vysokou režii na dodržování právních předpisů. Tenanti navíc pravděpodobně nemají vliv na výkon systému ostatních, což je problém, který se někdy označuje jako problém hlučného souseda . Aktualizace a změny je možné postupně zavádět napříč tenanty, což snižuje pravděpodobnost výpadku celého systému.
Rizika: Pokud používáte tento přístup, je nákladová efektivita nízká, protože nesdílíte infrastrukturu mezi tenanty. Pokud jeden tenant vyžaduje určité náklady na infrastrukturu, 100 tenantů pravděpodobně vyžaduje 100krát vyšší náklady. Průběžná údržba (například použití nových konfigurací nebo aktualizací softwaru) bude pravděpodobně časově náročná. Zvažte automatizaci provozních procesů a zvažte postupné aplikování změn v prostředích. Měli byste také zvážit další operace napříč nasazeními, jako jsou vytváření sestav a analýzy napříč celým flotilou. Stejně tak nezapomeňte naplánovat, jak můžete dotazovat a manipulovat s daty napříč několika nasazeními.
Plně víceklientských nasazení
Naopak můžete zvážit plně víceklientského nasazení, kde se sdílí všechny komponenty. K nasazení a údržbě máte jenom jednu sadu infrastruktury a všichni tenanti ji používají, jak je znázorněno v následujícím diagramu:
Výhody: Tento model je atraktivní, protože provozování řešení se sdílenými komponentami je levnější než použití jednotlivých prostředků pro jednotlivé tenanty. I když potřebujete nasadit vyšší úrovně nebo skladové položky prostředků, aby se zohlednilo zvýšené zatížení, celkové náklady na nasazení jsou často nižší než náklady na sadu prostředků s jedním tenantem. Navíc pokud uživatel nebo tenant potřebuje přesunout data do jiného tenanta, možná budete moct aktualizovat identifikátory a klíče tenanta a nemusí být nutné migrovat data mezi dvěma samostatnými nasazeními.
Riskuje:
Nezapomeňte oddělit data pro každého tenanta a nevratit data mezi tenanty. Možná budete muset spravovat data horizontálního dělení. Kromě toho možná budete muset mít obavy o účinky, které můžou mít jednotliví tenanti na celkový systém. Pokud se například velký tenant pokusí provést náročný dotaz nebo operaci, může to mít vliv na jiné tenanty.
Zjistěte, jak sledovat a přidružit náklady na Azure k tenantům, pokud je to pro vás důležité.
Údržba může být jednodušší s jedním nasazením, protože stačí aktualizovat jenom jednu sadu prostředků. Je ale také často riskantní, protože změny můžou mít vliv na celou zákaznickou základnu.
Možná budete muset zvážit také škálování. Pokud máte sdílenou sadu infrastruktury, pravděpodobně dosáhnete limitů škálování prostředků Azure. Pokud například používáte účet úložiště jako součást vašeho řešení, s rostoucím škálováním může počet požadavků na tento účet úložiště dosáhnout limitu toho, co může účet úložiště zpracovat. Abyste se vyhnuli dosažení limitu kvóty prostředků, můžete zvážit nasazení fondu více instancí prostředků (například více clusterů AKS nebo účtů úložiště). Můžete dokonce zvážit distribuci tenantů napříč prostředky, které nasadíte do několika předplatných Azure.
Pravděpodobně existuje omezení toho, jak daleko můžete škálovat jedno nasazení, a náklady na to mohou zvyšovat nelineárně. Pokud máte například jednu sdílenou databázi, můžete při velmi velkém měřítku vyčerpat její propustnost a potřebujete platit čím dál více za vyšší propustnost, abyste udrželi krok s vaší poptávkou.
Vertikálně dělené nasazení
Nemusíte si vybírat jednu z extrémních hodnot těchto škál. Místo toho můžete zvážit vertikální dělení tenantů pomocí tohoto přístupu:
- Použijte kombinaci nasazení s jedním tenantem a více tenanty. Můžete mít například většinu dat a aplikačních vrstev vašich zákazníků ve víceklientských infrastrukturách, ale nasazovat infrastruktury s jedním tenantem pro zákazníky, kteří vyžadují vyšší výkon nebo izolaci dat.
- Nasaďte více instancí vašeho řešení geograficky a namapujte každého tenanta na konkrétní nasazení. Tento přístup je zvlášť efektivní, pokud máte tenanty v různých zeměpisných oblastech.
Tady je příklad, který znázorňuje sdílené nasazení pro některé tenanty a jednoklientské nasazení pro jiné:
Výhody: Protože stále sdílíte určitou infrastrukturu, můžete získat některé z výhod nákladů při používání sdílených víceklientských nasazení. Pro určité zákazníky můžete nasadit levnější sdílené prostředky, jako jsou zákazníci, kteří vyhodnocují vaši službu pomocí zkušební verze. Zákazníkům můžete dokonce účtovat vyšší sazbu za použití nasazení s jedním tenantem, což vám pomůže obnovit některé náklady.
Rizika: Základ kódu je potřeba navrhnout tak, aby podporoval nasazení s více tenanty i jednoklienty. Pokud plánujete povolit migraci mezi nasazeními, je potřeba zvážit, jak migrovat zákazníky z víceklientského nasazení do vlastního nasazení s jedním tenantem. Potřebujete také vědět, kteří z vašich tenantů se nacházejí v každém nasazení, abyste mohli sdělit informace o problémech se systémem nebo upgradech příslušným zákazníkům.
Horizontálně dělené nasazení
Můžete také zvážit horizontální dělení nasazení. V horizontálním nasazení máte některé sdílené komponenty, ale udržujete další komponenty s nasazeními s jedním tenantem. Můžete například vytvořit jednu aplikační vrstvu a pak nasadit jednotlivé databáze pro každého tenanta, jak je znázorněno v tomto diagramu:
Výhody: Horizontálně dělené nasazení vám můžou pomoct zmírnit problém s hlučným sousedem: pokud zjistíte, že většina zatížení systému je způsobená konkrétními komponentami, můžete pro každého tenanta nasadit samostatné komponenty. Například vaše databáze můžou absorbovat většinu zatížení systému, protože zatížení dotazu je vysoké. Pokud jeden tenant odešle do vašeho řešení velký počet požadavků, může to mít negativní vliv na výkon databáze, ale databáze ostatních tenantů (a sdílené komponenty, jako je aplikační vrstva), zůstanou nedotčené.
Rizika: Při horizontálně děleném nasazení je stále potřeba zvážit automatizované nasazení a správu komponent, zejména komponenty používané jedním tenantem.
Testování modelu izolace
Bez ohledu na to, který model izolace zvolíte, nezapomeňte otestovat vaše řešení a ověřit, že data jednoho tenanta nejsou omylem unikla do jiného a že všechny hlučné sousedské účinky jsou přijatelné. Zvažte použití nástroje Azure Chaos Studio k úmyslu zavést chyby, které simulují výpadky reálného světa a ověřují odolnost vašeho řešení i v případě, že komponenty nefungují správně.
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í softwarový inženýr
Další přispěvatelé:
- Chad Kittel | Hlavní softwarový inženýr
- 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.