Vzory tenantů víceklientské databáze SaaS

Článek
07/31/2023

Tento článek popisuje různé modely tenantů dostupné pro víceklientské aplikace SaaS.

Při návrhu víceklientské aplikace SaaS musíte pečlivě zvolit model tenantů, který nejlépe vyhovuje potřebám vaší aplikace. Model tenantů určuje, jak se data jednotlivých tenantů mapují na úložiště. Váš výběr modelu tenantů má vliv na návrh a správu aplikací. Přechod na jiný model později je někdy nákladný.

Odpověď: Koncepty a terminologie SaaS

V modelu Software jako služba (SaaS) vaše společnost neprodává licence k vašemu softwaru. Místo toho každý zákazník provádí splátky pronájmu vaší společnosti, takže každý zákazník je tenantem vaší společnosti.

Za cenu placení pronájmu obdrží každý tenant přístup ke komponentám aplikace SaaS a má svá data uložená v systému SaaS.

Model tenantů označuje způsob uspořádání uložených dat tenantů:

Jednoklientská architektura: Každá databáze ukládá data pouze z jednoho tenanta.
Víceklientská architektura: Každá databáze ukládá data z více samostatných tenantů (s mechanismy pro ochranu osobních údajů dat).
K dispozici jsou také hybridní modely tenantů.

B. Výběr vhodného modelu tenantů

Obecně platí, že model tenantů nemá vliv na funkci aplikace, ale pravděpodobně ovlivňuje další aspekty celkového řešení. K posouzení jednotlivých modelů se používají následující kritéria:

Škálovatelnost:
- Počet tenantů
- Úložiště pro jednotlivé tenanty
- Úložiště v agregaci.
- Pracovního vytížení.
Izolace tenanta: Izolace a výkon dat (jestli úloha jednoho tenanta ovlivňuje ostatní).
Náklady na tenanta: Náklady na databázi.
Složitost vývoje:
- Změny schématu
- Změny dotazů (vyžadované vzorem)
Provozní složitost:
- Monitorování a správa výkonu
- Správa schémat.
- Obnovení tenanta
- Zotavení po havárii.
Přizpůsobitelnost: Usnadnění podpory přizpůsobení schématu, která jsou specifická pro tenanta nebo pro konkrétní třídu tenanta.

Diskuze o tenantech se zaměřuje na datová vrstva. Chvíli ale zvažte aplikační vrstvu. Aplikační vrstva se považuje za monolitickou entitu. Pokud aplikaci rozdělíte na mnoho malých komponent, může se váš výběr modelu tenantů změnit. S některými komponentami můžete zacházet odlišně než s jinými, pokud jde o tenanty i použitou technologii úložiště nebo platformu.

C. Samostatná aplikace s jedním tenantem s databází s jedním tenantem

Izolace na úrovni aplikace

V tomto modelu se celá aplikace nainstaluje opakovaně, jednou pro každého tenanta. Každá instance aplikace je samostatná instance, takže nikdy nekomunikuje s žádnou jinou samostatnou instancí. Každá instance aplikace má pouze jednoho tenanta, a proto potřebuje jenom jednu databázi. Tenant má celou databázi.

Design of standalone app with exactly one single-tenant database.

Každá instance aplikace je nainstalovaná v samostatné skupině prostředků Azure. Skupina prostředků může patřit do předplatného, které vlastní dodavatel softwaru nebo tenant. V obou případech může dodavatel spravovat software pro tenanta. Každá instance aplikace je nakonfigurovaná tak, aby se připojila k příslušné databázi.

Každá databáze tenanta se nasadí jako jedna databáze. Tento model poskytuje největší izolaci databáze. Izolace ale vyžaduje, aby se každému databázi přidělily dostatečné prostředky, aby zvládly zatížení ve špičce. V této části je důležité, aby elastické fondy nebylo možné použít pro databáze nasazené v různých skupinách prostředků nebo pro různá předplatná. Díky tomuto omezení je tento samostatný model aplikace s jedním tenantem nejnákladnější z hlediska celkových nákladů na databázi.

Správa dodavatelů

Dodavatel má přístup ke všem databázím ve všech samostatných instancích aplikací, i když jsou instance aplikací nainstalované v různých předplatných tenantů. Přístup se dosahuje prostřednictvím připojení SQL. Tento přístup mezi instancemi umožňuje dodavateli centralizovat správu schématu a dotaz mezi databázemi pro účely generování sestav nebo analýz. Pokud je tento druh centralizované správy žádoucí, musí se nasadit katalog, který mapuje identifikátory tenanta na identifikátory URI databáze. Azure SQL Database poskytuje knihovnu horizontálního dělení, která se používá společně k poskytování katalogu. Knihovna horizontálního dělení se formálně nazývá klientská knihovna elastické databáze.

D. Aplikace s více tenanty s databází na tenanta

Tento další model používá aplikaci s více tenanty s mnoha databázemi, což jsou všechny databáze s jedním tenantem. Pro každého nového tenanta se zřídí nová databáze. Aplikační vrstva se vertikálně navyšuje přidáním dalších prostředků na uzel. Nebo se aplikace horizontálně horizontálně horizontálně navyšuje přidáním dalších uzlů. Škálování je založené na úloze a je nezávislé na počtu nebo škálování jednotlivých databází.

Design of multi-tenant app with database-per-tenant.

Přizpůsobení pro tenanta

Stejně jako model samostatné aplikace poskytuje použití databází s jedním tenantem silnou izolaci tenanta. V libovolné aplikaci, jejíž model určuje pouze databáze s jedním tenantem, je možné schéma pro libovolnou danou databázi přizpůsobit a optimalizovat pro svého tenanta. Toto přizpůsobení nemá vliv na ostatní tenanty v aplikaci. Tenant možná potřebuje data nad rámec základních datových polí, která potřebují všichni tenanti. Další datové pole navíc může potřebovat index.

Při použití databáze na tenanta je přizpůsobení schématu pro jednoho nebo více jednotlivých tenantů jednoduché. Dodavatel aplikace musí navrhnout postupy pro pečlivou správu přizpůsobení schématu ve velkém měřítku.

Elastické fondy

Když jsou databáze nasazené ve stejné skupině prostředků, je možné je seskupit do elastických fondů. Fondy poskytují nákladově efektivní způsob sdílení prostředků napříč mnoha databázemi. Tato možnost fondu je levnější, než vyžaduje, aby každá databáze byla dostatečně velká, aby vyhovovala špičkám využití, ke kterým dochází. I když databáze ve fondu sdílejí přístup k prostředkům, stále můžou dosáhnout vysoké míry izolace výkonu.

Design of multi-tenant app with database-per-tenant, using elastic pool.

Azure SQL Database poskytuje nástroje potřebné ke konfiguraci, monitorování a správě sdílení. Metriky výkonu na úrovni fondu i databáze jsou k dispozici na webu Azure Portal a prostřednictvím protokolů služby Azure Monitor. Metriky můžou poskytovat skvělé přehledy o agregovaném výkonu i výkonu specifickém pro tenanty. Jednotlivé databáze je možné přesouvat mezi fondy, aby poskytovaly rezervované prostředky konkrétnímu tenantovi. Tyto nástroje umožňují zajistit dobrý výkon nákladově efektivním způsobem.

Škálování operací pro databáze na tenanta

Azure SQL Database má mnoho funkcí pro správu, které jsou navržené pro správu velkého počtu databází ve velkém měřítku, například více než 100 000 databází. Díky těmto funkcím je model databáze na tenanta přijatelný.

Předpokládejme například, že systém má jako jedinou databázi 1000 tenantů. Databáze může mít 20 indexů. Pokud se systém převede na 1 000 databází s jedním tenantem, množství indexů se zvýší na 20 000. V Azure SQL Database jako součást automatického ladění jsou funkce automatického indexování ve výchozím nastavení povolené. Automatické indexování spravuje pro vás všech 20 000 indexů a jejich průběžné vytváření a odstraňování optimalizací. K těmto automatizovaným akcím dochází v rámci jednotlivých databází a nejsou koordinované nebo omezené podobnými akcemi v jiných databázích. Automatické indexování zpracovává indexy v zaneprázdněné databázi jinak než v méně zaneprázdněné databázi. Tento typ přizpůsobení správy indexů by byl nepraktický na úrovni databáze na tenanta, pokud by se tato obrovská úloha správy musela provést ručně.

Mezi další funkce správy, které se dobře škálují, patří:

Předdefinované zálohy
Vysoká dostupnost
Šifrování na disku
Telemetrie výkonu

Automatizace

Operace správy se dají skriptovat a nabízet prostřednictvím modelu DevOps . Operace lze dokonce automatizovat a vystavit v aplikaci.

Můžete například automatizovat obnovení jednoho tenanta do dřívějšího bodu v čase. Obnovení stačí obnovit jenom jednu databázi s jedním tenantem, která tenanta ukládá. Toto obnovení nemá žádný vliv na ostatní tenanty, což potvrzuje, že operace správy jsou na jemně členité úrovni každého jednotlivého tenanta.

E. Aplikace s více tenanty s více tenanty s databázemi s více tenanty

Dalším dostupným vzorem je ukládání mnoha tenantů v databázi s více tenanty. Instance aplikace může mít libovolný počet databází s více tenanty. Schéma databáze s více tenanty musí mít jeden nebo více sloupců identifikátorů tenanta, aby bylo možné data z libovolného tenanta selektivně načíst. Schéma navíc může vyžadovat několik tabulek nebo sloupců, které používají jenom podmnožina tenantů. Statický kód a referenční data se však ukládají jenom jednou a sdílí je všechny tenanty.

Izolace tenanta je obětována

Data: Databáze s více tenanty nutně obětuje izolaci tenanta. Data více tenantů jsou uložená společně v jedné databázi. Během vývoje zajistěte, aby dotazy nikdy nezpřístupnily data z více než jednoho tenanta. SQL Database podporuje zabezpečení na úrovni řádků, které může vynutit, aby data vrácená z dotazu byla vymezena na jednoho tenanta.

Zpracování: Databáze s více tenanty sdílí výpočetní prostředky a prostředky úložiště ve všech svých tenantech. Databázi jako celek je možné monitorovat, aby se zajistilo, že funguje přijatelně. Systém Azure ale nemá žádný integrovaný způsob, jak monitorovat nebo spravovat používání těchto prostředků jednotlivými tenanty. Proto víceklientské databáze přináší zvýšené riziko výskytu hlučných sousedů, kdy úloha jednoho nadaktivního tenanta ovlivňuje výkon jiných tenantů ve stejné databázi. Další monitorování na úrovni aplikace může monitorovat výkon na úrovni tenanta.

Nižší náklady

Obecně platí, že databáze s více tenanty mají nejnižší náklady na tenanta. Náklady na prostředky pro jednu databázi jsou nižší než u elastického fondu s ekvivalentní velikostí. Kromě toho pro scénáře, kdy tenanti potřebují jenom omezené úložiště, můžou být potenciálně miliony tenantů uloženy v jedné databázi. Žádný elastický fond nemůže obsahovat miliony databází. Řešení obsahující 1 000 databází na fond s 1 000 fondy by však mohlo dosáhnout rozsahu milionů s rizikem, že se stane nepraktným pro správu.

V následujícím článku jsou popsány dvě varianty modelu databáze s více tenanty, přičemž model horizontálně dělených více tenantů je nejflexibilnější a nejflexibilnější.

F Aplikace s více tenanty s jednou databází s více tenanty

Nejjednodušší vzor databáze s více tenanty používá jednu databázi k hostování dat pro všechny tenanty. Při přidání dalších tenantů se databáze škáluje s větším úložištěm a výpočetními prostředky. Toto vertikální navýšení kapacity může být vše, co je potřeba, i když existuje vždy konečný limit škálování. Ale dlouho před dosažením limitu se databáze stane nepraktným pro správu.

Operace správy zaměřené na jednotlivé tenanty jsou složitější pro implementaci v databázi s více tenanty. A ve velkém měřítku se tyto operace můžou stát nepřijatelně pomalým. Jedním z příkladů je obnovení dat k určitému bodu v čase pouze pro jednoho tenanta.

G. Víceklientská aplikace s horizontálně dělenými databázemi s více tenanty

Většina aplikací SaaS přistupuje k datům pouze jednoho tenanta najednou. Tento model přístupu umožňuje distribuci dat tenanta napříč několika databázemi nebo horizontálními oddíly, kde všechna data pro každého tenanta jsou obsažená v jednom horizontálním oddílu. V kombinaci se vzorem víceklientské databáze umožňuje horizontálně dělený model téměř neomezené škálování.

Design of multi-tenant app with sharded multi-tenant databases.

Správa horizontálních oddílů

Horizontální dělení zvyšuje složitost návrhu i provozní správy. Vyžaduje se katalog, ve kterém se má udržovat mapování mezi tenanty a databázemi. Kromě toho se ke správě horizontálních oddílů a základního tenanta vyžadují postupy správy. Například postupy musí být navržené tak, aby přidávaly a odebíraly horizontální oddíly, a přesouvat data tenanta mezi horizontálními oddíly. Jedním ze způsobů škálování je přidání nového horizontálního oddílu a jeho naplnění novými tenanty. Jindy můžete hustě naplněný horizontální oddíl rozdělit do dvou méně hustě naplněných horizontálních oddílů. Po přesunutí nebo ukončení několika tenantů můžete sloučit řídce naplněné horizontální oddíly dohromady. Sloučení by vedlo k nákladově efektivnějšímu využití prostředků. Tenanti se také můžou přesouvat mezi horizontálními oddíly, aby se vyrovnávají úlohy.

SQL Database poskytuje nástroj pro rozdělení/sloučení, který funguje ve spojení s knihovnou horizontálního dělení a databází katalogu. Poskytnutá aplikace může rozdělit a sloučit horizontální oddíly a může přesouvat data tenanta mezi horizontálními oddíly. Aplikace také během těchto operací udržuje katalog a před přesunutím tenantů označí ovlivněné tenanty jako offline. Po přesunutí aplikace znovu aktualizuje katalog novým mapováním a označí tenanta jako back-online.

Menší databáze snadněji spravované

Distribuce tenantů napříč několika databázemi vede k tomu, že horizontálně dělené víceklientské řešení vede k jednodušší správě menších databází. Například obnovení konkrétního tenanta k určitému bodu v čase teď zahrnuje obnovení jedné menší databáze ze zálohy, nikoli větší databáze, která obsahuje všechny tenanty. Velikost databáze a počet tenantů na databázi je možné zvolit k vyvážení úloh a úsilí o správu.

Identifikátor tenanta ve schématu

V závislosti na použitém přístupu k horizontálnímu dělení může být u schématu databáze vynucena další omezení. Aplikace SQL Database rozdělení nebo sloučení vyžaduje, aby schéma obsahovalo klíč horizontálního dělení, což je obvykle identifikátor tenanta. Identifikátor tenanta je předním prvkem primárního klíče všech horizontálně dělených tabulek. Identifikátor tenanta umožňuje rozdělené nebo slučovací aplikaci rychle vyhledat a přesunout data přidružená ke konkrétnímu tenantovi.

Elastický fond pro horizontální oddíly

Horizontálně dělené víceklientské databáze je možné umístit do elastických fondů. Obecně platí, že mít mnoho databází s jedním tenantem ve fondu je stejně nákladově efektivní jako mít mnoho tenantů v několika databázích s více tenanty. Databáze s více tenanty jsou výhodné, pokud existuje velký počet relativně neaktivních tenantů.

H. Hybridní model horizontálně dělené databáze s více tenanty

V hybridním modelu mají všechny databáze identifikátor tenanta ve schématu. Všechny databáze jsou schopné ukládat více než jednoho tenanta a databáze je možné horizontálně dělit. Takže ve smyslu schématu jsou to všechny databáze s více tenanty. Některé z těchto databází ale v praxi obsahují pouze jednoho tenanta. Bez ohledu na počet tenantů uložených v dané databázi nemá žádný vliv na schéma databáze.

Přesun tenantů

Kdykoli můžete přesunout konkrétního tenanta do vlastní databáze s více tenanty. A kdykoli můžete změnit názor a přesunout tenanta zpět do databáze, která obsahuje více tenantů. Při zřizování nové databáze můžete také přiřadit tenanta k nové databázi s jedním tenantem.

Hybridní model svítí, když existují velké rozdíly mezi potřebami prostředků identifikovatelných skupin tenantů. Předpokládejme například, že tenanti, kteří se účastní bezplatné zkušební verze, nezaručují stejnou vysokou úroveň výkonu, jako jsou přihlášení k odběru tenantů. Zásady můžou být pro tenanty ve fázi bezplatné zkušební verze uložené v databázi s více tenanty, která se sdílí mezi všemi bezplatnými zkušebními tenanty. Když se bezplatný zkušební tenant přihlásí k odběru úrovně služby Basic, můžete tenanta přesunout do jiné databáze s více tenanty, která může mít méně tenantů. Předplatitel, který platí za úroveň služby Premium, se dá přesunout do vlastní nové databáze s jedním tenantem.

Skupiny

V tomto hybridním modelu je možné umístit databáze s jedním tenantem pro předplatitele do fondů prostředků, aby se snížily náklady na databázi na tenanta. To se také provádí v modelu databáze pro jednotlivé tenanty.

I. Porovnání modelů tenantů

Následující tabulka shrnuje rozdíly mezi hlavními modely tenantů.

Měrný systém	Samostatná aplikace	Databáze na tenanta	Horizontálně dělené víceklientské
Měřítko	střední 1–100s	Velmi vysoká 1–100 000	Bez omezení 1–1 000 000
Izolace tenanta	Velmi vysoká	Nejvyšší	Nízké; s výjimkou jednoho tenanta (který je sám v databázi MT).
Náklady na databázi na tenanta	Vysoké; je velikost pro špičky.	Nízké; použité fondy.	Nejnižší pro malé tenanty v MTB.
Monitorování a správa výkonu	Pouze pro jednotlivé tenanty	Aggregate + per-tenant	Agregace; i když je pro jednotlivé tenanty pouze pro jednotlivé.
Složitost vývoje	Nejnižší	Nejnižší	Střední; kvůli horizontálnímu dělení.
Provozní složitost	Low-High. Individuálně jednoduché, složité ve velkém měřítku.	Nízká-střední. Vzory řeší složitost ve velkém měřítku.	Low-High. Správa jednotlivých tenantů je složitá.