Vzory tenantů víceklientské databáze SaaS

Platí pro:Azure SQL databáze

Tento článek popisuje různé modely tenantů, které jsou k dispozici pro víceklientské aplikace SaaS.

Při navrhování 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áš zvolený model tenantu ovlivňuje návrh a správu aplikace. Přechod na jiný model později je někdy nákladný.

A. 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 nájemníků se týká organizace uložených dat nájemníků:

• 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 klientů (s mechanismy pro ochranu dat).
• K dispozici jsou také hybridní modely nájemců.

B. Jak vybrat vhodný model pronájmu

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
  • Agregované úložiště
  • Pracovní zátěž.

• 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 nájemních vztazích se zaměřuje na datovou vrstvu. 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.

Každá instance aplikace je nainstalovaná v samostatné skupině prostředků Azure. Buď dodavatel softwaru, nebo tenant může vlastnit předplatné, které vlastní skupinu prostředků. 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 nájemce je nasazena jako samostatná 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. Je důležité vědět, že elastické fondy nelze použít pro databáze nasazené v různých skupinách prostředků nebo v rámci různých předplatných. 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 jednotných prostředků databáze (URI). Azure SQL Database poskytuje knihovnu horizontálního dělení, která se používá společně pro vytvoření katalogu. Knihovna horizontálního dělení se formálně nazývá Elastic Database Client Library.

D. Víceklientní aplikace s databází na tenanta

Tento další model používá víceklientovou aplikaci 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ě škáluje 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í.

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ž situace, kdy by každá databáze musela být dostatečně velká, aby zvládla špičky využití. Ačkoli sdílené databáze mají přístup k prostředkům, stále mohou dosáhnout vysoké míry izolace výkonnosti.

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ázi pro každého nájemce

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í databáze jsou ve výchozím nastavení povolené funkce automatického indexování. Automatické indexování spravuje všech 20 000 indexů a průběžně optimalizuje jejich vytváření a rušení. 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

Automation

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

Například můžete automatizovat obnovení jednotlivého tenanta do předchozí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. víceklientská aplikace s víceklientskými databázemi

Dalším dostupným vzorem je ukládání mnoha tenantů do víceklientských databází. Instance aplikace může mít libovolný počet víceklientských databází. Schéma víceklientských databází 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: Víceklientová databáze nutně obětuje izolaci nájemce. 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í: Víceklientová databáze 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. Monitorování na úrovni aplikace může monitorovat výkon na úrovni tenanta.

Nižší náklady

Obecně platí, že víceklientské databáze mají nejnižší náklady na nájemce. 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á skupina nemůže obsahovat miliony databází. Řešení obsahující 1 000 databází na fond s 1 000 fondy by totiž mohlo dosáhnout rozsahu milionů s rizikem, že bude obtížně řiditelné.

V následujícím článku jsou popsány dvě varianty modelu víceklientské databáze, přičemž horizontálně dělený víceklientský model je nejflexibilnější a škálovatelný.

F. Víceklientová aplikace s jednou víceklientovou databází

Nejjednodušší vzor víceklientských databází používá jednoúčelovou databázi k hostování dat pro všechny tenanty. Při přidání dalších tenantů je databáze rozšiřována o dodatečné úložiště a výpočetní 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 nepraktickou pro správu.

Operace správy zaměřené na jednotlivé tenanty jsou složitější pro implementaci ve víceklientských databázích. A ve velkém měřítku se tyto operace můžou stát nepřijatelně pomalé. 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 víceklientské databázemi

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í.

Správa shardů

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ě fragmentů a populace nájemníků vyžadují postupy správy. Například postupy musí být navržené tak, aby přidávaly a odebíraly shardy, a přesouvaly data tenanta mezi shardy. Jedním ze způsobů škálování je přidání nového shardu a jeho naplnění novými nájemníky. 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 řídké shardy. Sloučení by vedlo k nákladově efektivnějšímu využití prostředků. Tenanti se také můžou přesouvat mezi shardami, aby se vyrovnaly úlohy.

SQL Database poskytuje nástroj pro rozdělení nebo sloučení, který funguje 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 s novým mapováním a označí nájemníka jako znovu online.

Menší databáze snadněji spravované

Rozdělením nájemců mezi několik databází vede šaržované víceklientské řešení k menším databázím, které se snáze spravují. 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

Podle toho, jaký přístup byl použit k sharding, mohou být uložena další omezení na schéma databáze. Aplikace rozdělení/spojování SQL databází vyžaduje, aby schéma obsahovalo klíč pro horizontální rozdě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 shardy

Horizontálně dělené víceklientské databáze je možné umístit do elastických fondů. Obecně, mít ve fondu mnoho databází pro jediného nájemce je stejně nákladově efektivní jako mít mnoho nájemců v několika vícenájemcových databázích. Víceklientské databáze jsou výhodné, pokud existuje velký počet relativně neaktivních nájemců.

H. Hybridní model databáze s rozdělenými částmi pro více klientů.

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šechno víceklientské databáze. 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í víceklientové databáze. 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, nemají zaručenou stejnou vysokou úroveň výkonu jako ti, kteří si předplatili. Zásady můžou být pro tenanty ve fázi bezplatné zkušební verze uložené ve víceklientové databázi, která se sdílí mezi všemi bezplatnými zkušebními tenanty. Když se tenant bezplatné zkušební verze přihlásí k odběru úrovně služby Basic, může být tenant přesunut do jiné víceklientové databáze, 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ů správy tenantů

Následující tabulka shrnuje rozdíly mezi hlavními nájemními modely.

Měrný systém	Samostatná aplikace	Databáze pro nájemce	Horizontálně dělené víceklientské
Měřítko	Střední (1–100 s)	Vysoká (1–100 000 s)	Neomezené (1–1 000 000)
Izolace nájemců	Vysoká	Vysoká	Nízký; s výjimkou jednoho tenanta (který je sám v databázi MT).
Náklady na databázi na tenanta	Vysoký výkon; má velikost pro špičkové zatížení.	Nízká kapacita; používané zdroje.	Nejnižší pro malé nájemce v databázích MT.
Monitorování a správa výkonu	Pouze pro jednotlivé tenanty	Agregát + pro jednotlivé nájemce	Agregované; i když je určeno pouze pro jednotlivé nájemníky.
Složitost vývoje	Nízká	Nízká	Středně; kvůli šardování.
Provozní složitost	Nízký-Vysoký. Individuálně jednoduché, komplexní ve velkém měřítku.	Nízká/střední Vzory řeší složitost ve velkém měřítku.	Nízký-Vysoký. Správa jednotlivých tenantů je složitá.

Související obsah

• Centrum architektury Azure: Úvodní webová aplikace pro vývoj SaaS