Modelyancy, které je třeba zvážit pro vícetenantové řešení

Existuje mnoho různých způsobů, jak navrhnout vícetenantové řešení. Většinou toto rozhodnutí 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 s tím, jak se vaše firma škáluje a jak nasazuje více tenantů, se to rychle stane nákladnou.

Je užitečné přemýšlet o různých modelech více tenantů tím, že nejprve pochopíte, jak definujete tenanty pro konkrétní organizaci, jaké obchodní faktory máte a jak plánujete škálovat řešení.

Definování tenanta

Nejprve je potřeba 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šimi zákazníky jiné organizace, pravděpodobně budete vaše tenanty považovat za tyto zákazníky. Zvažte ale, jestli vaši zákazníci můžou mít divize (týmy nebo oddělení) nebo jestli se nachází ve více zemích. Pokud jsou pro tyto podskupiny různé požadavky, možná budete muset zvážit mapování jednoho zákazníka na více tenantů. Podobně může zákazník chtít udržovat dvě instance vaší služby, aby mohl udržovat vývojová a produkční prostředí od sebe navzájem oddělená. Obecně platí, že jeden tenant bude mít více uživatelů. Například všichni zaměstnanci vašeho zákazníka budou uživatelé v rámci stejného tenanta.
• B2C (Business-to-Consumer). Pokud jsou vaši zákazníci spotřebiteli, je často složitější souviset se zákazníky, tenanty a uživateli. V některých scénářích může být každý příjemce jejich vlastním tenantem. Zvažte ale, jestli vaše řešení můžou používat rodiny, skupiny přátel, rodina, asociace nebo jiná seskupení, která by mohla potřebovat přístup ke svým 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ě, pokud jde o jejich rozdělení do tenantů.

Vaše definice tenanta bude mít vliv na některé z věcí, které je potřeba vzít v úvahu nebo zdůraznit při architektuře řešení. Představte si například tyto různé typy tenantů:

• Pokud jsou vašimi tenanty individuální lidé nebo rodiny, možná vás bude obavy hlavně o způsob zpracování osobních údajů a zákonů o suverenitu dat v rámci každé příslušné jurisdikce.
• Pokud jsou vašimi tenanty firmy, možná budete muset mít na paměti požadavky vašich zákazníků na dodržování právních předpisů, izolaci jejich dat a splnění zadaného cíle na úrovni služby, jako je dostupnost služeb nebo dostupnost služeb.

Jak se rozhodnete, který model se má použít?

Výběr modelu tenancy není jenom technické rozhodnutí. Je to také obchodní rozhodnutí, které musíte udělat. Je potřeba zvážit následující otázky:

• Jaké jsou vaše obchodní cíle?
• Budou vaši zákazníci přijímat všechny formy vícetenancy? Jak by každý model s více klienty ovlivnil vaše požadavky na dodržování předpisů nebo požadavky zákazníka na dodržování předpisů?
• Bude řešení s jedním tenantem škálovat na budoucí růst?
• Jak velký je váš provozní tým a jak velkou část správy infrastruktury dokážete automatizovat?
• Očekávají vaši zákazníci, že budete splňovat smlouvy o úrovni služeb (SLA), nebo máte SLI, o které se snažíte?

Pokud očekáváte, že se vaše firma bude škálovat na velký počet zákazníků, bude velmi důležité nasadit sdílenou infrastrukturu. Jinak budete muset udržovat velkou a neustále rostoucí vozový park instancí. Nasazení jednotlivých prostředků Azure pro každého zákazníka bude pravděpodobně neudržitelné, pokud pro každého tenanta nezřadíte a nevyudržíte vyhrazené předplatné. Při sdílení stejného předplatného Azure mezi více tenanty se můžou 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ů se s každým novým zákazníkem stanou vyššími.

Pokud naopak očekáváte, že vaše firma bude mít jen několik zákazníků, může být vhodné zvážit použití prostředků s jedním tenantem, které jsou vyhrazené každému zákazníkovi. Podobně pokud jsou požadavky zákazníků na izolaci vysoké, může být vhodná infrastruktura s jedním tenantem.

Logické a fyzické tenanty

Dále musíte určit, co tenant znamená pro konkrétní řešení a jestli byste měli rozlišovat mezi logickými a fyzickými tenanty.

Představte si například službu streamování hudby. Na začátku můžete vytvořit řešení, které dokáže snadno zvládnout tisíce (nebo i desítky tisíc) uživatelů. S tím, jak se ale stále rozrůstáte, můžete zjistit, že je potřeba duplikovat řešení nebo některé jeho komponenty, aby bylo možné škálovat podle poptávky nových zákazníků. To znamená, že budete muset zjistit, jak přiřadit konkrétní zákazníky ke konkrétním instancím vašeho řešení. Můžete to provést náhodně, geograficky nebo vyplněním jedné instance a pak přelití do jiné. Pravděpodobně ale budete muset udržovat záznamy o tom, které zákazníky máte a ve které infrastruktuře jsou jejich data a aplikace k dispozici, abyste mohli směrovat jejich provoz do správné infrastruktury. V tomto příkladu můžete každého uživatele reprezentovat jako samostatného logického tenanta a pak je namapovat na fyzické tenanty, které představují různé instance, které jste nasadili. Máte mapování 1:M mezi logickými a fyzickými tenanty a logické tenanty můžete přesouvat mezi fyzickými tenanty podle vlastního uvážení.

Naopak zvažte společnost, která vytváří cloudový software pro právní firmy. Vaši zákazníci můžou trvat na vlastní vyhrazené infrastruktuře, aby si zachovali standardy dodržování předpisů. Proto musíte být připraveni nasadit a spravovat mnoho různých instancí vašeho řešení hned od začátku. V tomto příkladu je logický a fyzický tenant totéž.

Klíčovým rozdílem mezi logickými a fyzickými tenanty je způsob vynucení izolace. Když několik logických tenantů sdílí jednu sadu infrastruktury, obvykle se spoléháte na kód aplikace a identifikátor tenanta v databázi, aby data každého tenanta byla oddělená. Když máte fyzické tenanty, mají vlastní infrastrukturu, a proto může být méně důležité, aby váš kód věděl, že funguje ve vícetenantském prostředí.

Někdy se fyzické tenanty označují jako nasazení, supertenanty nebo razítka. Ve zbývající části tohoto dokumentu používáme termíny nasazení a fyzická nasazení , aby nedocházelo k nejasnostem mezi logickými a fyzickými tenanty.

Když obdržíte požadavek na konkrétního logického tenanta, musíte ho namapovat na fyzické nasazení, které obsahuje data tohoto tenanta, jak je znázorněno níže:

Izolace tenanta

Jedním z největších požadavků při návrhu vícetenantové architektury je úroveň izolace, kterou každý tenant potřebuje. Izolace může znamenat různé věci:

• Mít jednu sadu sdílené infrastruktury s oddělenými instancemi vaší aplikace a samostatnými databázemi pro každého tenanta.
• Sdílení některých běžných prostředků a zachování ostatních prostředků oddělených pro každého tenanta
• Uchovávání dat v samostatné fyzické infrastruktuře. V cloudu to může vyžadovat samostatné prostředky Azure pro každého tenanta, nebo dokonce může znamenat doslova nasazení samostatné fyzické infrastruktury pomocí vyhrazených hostitelů.

Místo toho, aby izolace byla diskrétní vlastnost, byste měli uvažovat o izolaci jako o kontinuu. V závislosti na vašich požadavcích můžete nasadit komponenty vaší 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 má vliv na 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 vracení odpovědí jinému nepřistupují k datům z jednoho tenanta. Pro strategii identit potřebujete pevný základ a v rámci procesu autorizace musíte vzít v úvahu identitu tenanta 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, výkon vašeho systému může utrpět, protože ho využívá více zákazníků, protože prostředky se mohou spotřebovávat rychleji.
• Spolehlivost. Pokud používáte jednu sadu sdílené infrastruktury, může problém s komponentami jednoho tenanta vést k výpadku pro všechny.
• Rychlost odezvy na potřeby jednotlivých tenantů. Když nasazujete infrastrukturu vyhrazenou pro jednoho tenanta, možná budete moct vyladit konfiguraci prostředků pro požadavky tohoto konkrétního tenanta. Můžete to dokonce zvážit ve svém cenovém modelu, kde zákazníkům umožníte platit více za izolovaná nasazení.

Architektura vašeho řešení může ovlivnit možnosti, které máte k dispozici pro izolaci. Podívejme se například na příklad třívrstvé architektury řešení:

• Vaší úrovní uživatelského rozhraní může být sdílená vícetenantová webová aplikace a všichni vaši tenanti přistupuje 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ší datovou vrstvou mohou být izolované databáze, tabulky nebo kontejnery objektů blob.

Můžete zvážit kombinaci a párování různých úrovní izolace na jednotlivých úrovních. Vaše rozhodnutí o tom, co je sdílené a co je izolované, bude založeno na mnoha aspektech, včetně nákladů, složitosti, požadavků vašich 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 tenatů

Jakmile požadavky stanovíte, vyhodnoťte je podle některých běžných modelů a vzorů tenatů.

Automatizovaná nasazení s jedním tenantem

V modelu automatizovaného nasazení s jedním tenantem nasadíte pro každého tenanta vyhrazenou sadu infrastruktury, jak je znázorněno v tomto příkladu:

Vaše aplikace zodpovídá za zahájení a koordinaci nasazení prostředků každého tenanta. Řešení vytvořená pomocí tohoto modelu se typicky využívají k rozsáhlému používání infrastruktury jako kódu (IaC) nebo rozhraní API pro Azure Resource Manager. Tento přístup můžete použít, pokud potřebujete zřídit zcela samostatné infrastruktury pro každého ze svých zákazníků. Při plánování nasazení Vezměte v úvahu vzor razítek 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. To může být důležité pro některé zákazníky s vysokými nároky na dodržování předpisů. Klienti navíc nepříznivě ovlivňují výkon systému, který se někdy označuje jako problém s hlučnými sousedními počítači. Aktualizace a změny je možné postupně nastavovat napříč klienty, což snižuje pravděpodobnost výpadku v rámci celého systému.

Rizika: Vaše cenová efektivita je nízká, protože nesdílíte infrastrukturu mezi vašimi klienty. Pokud jeden tenant vyžaduje útratu určitou částku v infrastruktuře, je pravděpodobný, že 100 klienti budou potřebovat 100 náklady ve výdajích. Průběžná údržba (jako je třeba použití nové konfigurace nebo aktualizací softwaru) může být navíc časově náročná. Zvažte automatizaci provozních procesů a zvažte možnost průběžné provádění změn prostřednictvím vašich prostředí. Měli byste taky zvážit další operace mezi nasazeními, jako je vytváření sestav a analýzy v celé nemovitosti. Stejně tak nezapomeňte naplánovat, jak se můžete dotazovat a manipulovat s daty napříč různými nasazeními.

Plně víceklientské nasazení

Na opačném případě můžete zvážit plné víceklientské nasazení, kde jsou všechny komponenty sdílené. Máte jenom jednu sadu infrastruktury pro nasazení a údržbu a všichni klienti ji používají, jak je znázorněno v následujícím diagramu:

Výhody: Tento model je atraktivní z důvodu nižších nákladů na provoz řešení se sdílenými komponentami. I když potřebujete nasadit vyšší úrovně nebo SKU prostředků, často se jedná o případ, že celkové náklady na nasazení jsou nižší než sada prostředků s jedním klienty. Kromě toho, pokud uživatel nebo tenant potřebuje přesunout svá data do jiného logického tenanta, nemusíte migrovat data mezi dvěma samostatnými nasazeními.

Riziko

• Dbejte na to, abyste se ujistili, že oddělíte data pro každého tenanta, a nemůžete mezi klienty přebírat data. Možná budete muset spravovat data horizontálního dělení sami. Kromě toho se může stát, že budete muset mít obavy z toho, jak můžou mít jednotliví klienti v celém systému. Pokud se například jeden velký tenant pokusí provést velký dotaz nebo operaci, bude mít vliv na ostatní klienty?

• Pokud je to pro vás důležité, určete, jak sledovat a přidružit náklady Azure ke klientům. Údržbu můžete zjednodušit pomocí jediného nasazení, protože stačí aktualizovat jenom jednu sadu prostředků. Často se ale často riskier, protože jakékoli změny můžou ovlivnit celou základnu zákazníků.

• Měřítko může být faktor i pro zvážení. Pokud máte sdílenou sadu infrastruktury, budete mít pravděpodobně přístup k omezením pro škálování prostředků Azure . Pokud například jako součást svého řešení použijete účet úložiště, pak se při zvyšování rozsahu může počet požadavků na tento účet úložiště dosáhnout limitu, který může účet úložiště zpracovat. Abyste se vyhnuli započetím kvóty prostředků, můžete zvážit nasazení více instancí prostředků (například více clusterů AKS nebo účtů úložiště), nebo můžete dokonce rozsazovat klienty mezi prostředky, které jste nasadili do více předplatných Azure.

• Může se stát, že budete mít omezení, jak daleko můžete škálovat jedno nasazení a náklady na to by se nelineárně zvýšily. Pokud máte například jednu sdílenou databázi, můžete při spuštění ve velmi velkém měřítku vyčerpat svou propustnost a při zvýšené propustnosti věnovat větší nároky.

Vertikálně dělená nasazení

Nemusíte mít na extrémních těchto měřítkech. Místo toho můžete zvážit vertikální dělení klientů pomocí následujících kroků:

• Použijte kombinaci nasazení s jedním a více klienty. Například můžete mít většinu dat vašich zákazníků a aplikačních vrstev ve víceklientské infrastruktuře, ale můžete nasadit infrastruktury pro jednoho tenanta pro zákazníky, kteří vyžadují vyšší výkon nebo izolaci dat.
• Nasaďte více instancí řešení geograficky a připnutím každého tenanta ke konkrétnímu nasazení. To je výhodné zejména v případě, že máte klienty v různých geografických oblastech.

Tady je příklad, který ilustruje sdílené nasazení pro některé klienty a nasazení jednoho tenanta pro jiný:

Výhody: Vzhledem k tomu, že stále spolupracujete s infrastrukturou, můžete i nadále využívat některé z výhod, které je třeba sdílet s nasazením víceklientské architektury. Pro určité zákazníky můžete nasadit levnější a sdílené prostředky, jako jsou uživatelé, kteří si vyzkoušeli vaši službu ve zkušební verzi. Zákazníkům můžete dokonce fakturovat větší sazbu, která bude v nasazení s jedním nájemcem, takže recouping některé z vašich nákladů.

Rizika: Váš základ kódu bude pravděpodobně muset být navržený tak, aby podporoval nasazení víceklientské architektury i jednoho tenanta. Pokud plánujete migraci mezi infrastrukturami, musíte zvážit, jak migrujete zákazníky ze víceklientské nasazení na své vlastní nasazení s jedním klientem. Také musíte mít jasné informace o tom, které z vašich logických klientů jsou na kterých sadách fyzické infrastruktury, abyste mohli sdělovat informace o systémových problémech nebo upgradech pro příslušné zákazníky.

Horizontálně dělená nasazení

Můžete také zvážit horizontální rozdělení nasazení. To znamená, že máte nějaké sdílené součásti a zároveň zachováte jiné součásti s nasazením s jedním nájemcem. Můžete například vytvořit jednu aplikační vrstvu a následně nasadit jednotlivé databáze pro každého tenanta, jak je znázorněno na následujícím obrázku:

Výhody: Horizontální dělené nasazení vám může přispět k omezení problému s vysokou úrovní potíží, pokud jste zjistili, že většina zatížení systému je způsobená konkrétními součástmi, které můžete nasadit samostatně pro každého tenanta. Vaše databáze může například absorbovat většinu zatížení systému, protože zatížení dotazů je vysoké. Pokud jeden tenant pošle vašemu řešení velký počet požadavků, může být výkon databáze negativně ovlivněný, ale ostatní databáze tenantů (a sdílené součásti, jako je aplikační vrstva), zůstávají neovlivněné.

Rizika: Díky horizontálnímu nasazování oddílů je stále potřeba vzít v úvahu automatizované nasazení a správu vašich komponent, zejména součásti používané jedním klientem.

Další kroky

Vezměte v úvahu životní cyklus klientů.