Modely tenantů SaaS Database pro více tenantů

PLATÍ PRO: Azure SQL Database

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

Při navrhování aplikace SaaS pro více tenantů musíte pečlivě vybrat model architektury, který nejlépe vyhovuje potřebám vaší aplikace. Model tenantů určuje, jak jsou data každého klienta namapována na úložiště. Váš výběr modelu architektury ovlivňuje návrh a správu aplikací. Pozdější přepnutí na jiný model 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 jednotliví zákazníci propůjčují platby do vaší společnosti, takže každý z nich bude mít tenanta vaší společnosti.

Při návratu k placenému pronajmutí každý tenant získá přístup k komponentám vaší aplikace SaaS a jeho data jsou uložená v SaaS systému.

Pojem model tenantů odkazuje na uspořádání uložených dat v klientech:

• Jediná architektura:   Každá databáze uchovává data pouze z jednoho tenanta.
• Víceklientská architektura :   Každá databáze uchovává data z několika samostatných klientů (s mechanismy ochrany osobních údajů).
• K dispozici jsou také modely hybridních tenantů.

B. Jak zvolit vhodný model architektury

Obecně platí, že model architektury nemá vliv na funkci aplikace, ale může to mít vliv na jiné aspekty celkového řešení. Následující kritéria slouží k vyhodnocení každého modelu:

• Škálovatelnost

  • Počet tenantů.
  • Úložiště pro každého tenanta.
  • Úložiště je agregované.
  • Úlohy.

• Izolace tenanta:   Izolace a výkon dat (bez ohledu na to, jestli zatížení jednoho tenanta má vliv na 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ématu.
  • Obnovuje se tenant.
  • Zotavení po havárii.

• Úpravou:   Snadná Podpora přizpůsobení schématu, která jsou specifická pro konkrétního tenanta nebo pro třídu tenanta.

Diskuze tenantů se zaměřuje na datovou vrstvu. Ale vezměte v úvahu okamžik aplikační vrstvy. Aplikační vrstva je považována za entitu monolitické. Pokud rozdělíte aplikaci na mnoho malých komponent, může se změnit zvolený model architektury. Můžete nakládat s některými komponentami, které se týkají i architektury i technologie úložiště nebo používané platformy.

C. Samostatná aplikace pro jednoho tenanta s databází s jedním tenanta

Izolace na úrovni aplikace

V tomto modelu je celá aplikace nainstalována opakovaně, jednou pro každého tenanta. Každá instance aplikace je samostatnou instancí, takže nikdy nekomunikuje s jinou samostatnou instancí. Každá instance aplikace má pouze jednoho tenanta, a proto potřebuje pouze jednu databázi. Tenant má tuto databázi na sebe samu.

Každá instance aplikace se nainstaluje do samostatné skupiny prostředků Azure. Skupina prostředků může patřit k předplatnému, 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řipojovala k příslušné databázi.

Každá databáze tenanta je nasazena jako jediná databáze. Tento model poskytuje největší izolaci databáze. Tato izolace ale vyžaduje, aby se pro každou databázi přidělily dostatečné prostředky pro zpracování zátěže ve špičce. Tady je důležité, aby elastické fondy nemohly být používány pro databáze nasazené v různých skupinách prostředků nebo v různých předplatných. Toto omezení usnadňuje, aby tato samostatná aplikace pro jednoho tenanta byla nejdražším řešením z celkové perspektivy 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 aplikace, a to i v případě, že instance aplikace jsou nainstalované v různých předplatných tenantů. Přístup se dosahuje prostřednictvím připojení SQL. Tento přístup mezi instancemi může dodavatel umožnit centralizaci správy schématu a databázového dotazu pro účely vytváření sestav a analýzy. Pokud je žádoucí tento druh centralizované správy, je nutné nasadit katalog, který mapuje identifikátory klientů na identifikátory URI databáze. Azure SQL Database poskytuje knihovnu horizontálního dělení, která se společně používá k poskytnutí katalogu. Knihovna horizontálního dělení je formálně pojmenována jako Klientská knihovna elastic Database.

D. Víceklientská aplikace s databází – na tenanta

Tento další vzor používá aplikaci s více klienty s mnoha databázemi, přičemž všechny jsou databáze jediného tenanta. Pro každého nového tenanta se zřídí nová databáze. Aplikační vrstva se vertikálně škáluje přidáním dalších prostředků na jeden uzel. Nebo se aplikace vodorovně škáluje přidáním dalších uzlů. Škálování je založené na zatížení a je nezávislé na počtu nebo rozsahu jednotlivých databází.

Přizpůsobení pro tenanta

Podobně jako u samostatného vzoru aplikace poskytuje použití jednoho tenanta databáze silnou izolaci klientů. V libovolné aplikaci, jejíž model určuje jenom databáze s jedním klientem, se dá schéma pro každou databázi přizpůsobit a optimalizovat pro svého tenanta. Toto vlastní nastavení nemá vliv na ostatní klienty v aplikaci. Možná může klient potřebovat data nad rámec základních datových polí, která potřebují všichni klienti. Kromě toho je možné, že pole další data bude potřebovat index.

S databází pro každého tenanta je přizpůsobení schématu pro jedno nebo více jednotlivých tenantů jednoduché. Dodavatel aplikace musí navrhovat 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ů, dají se seskupit do elastických fondů. Fondy poskytují nákladově efektivní způsob sdílení prostředků napříč mnoha databázemi. Možnost fondu je levnější, než vyžaduje, aby byla každá databáze dostatečně velká, aby se vešla do špičky využití, ke kterým dojde. I když databáze ve fondu sdílejí přístup k prostředkům, můžou stále dosáhnout vysoké úrovně izolace výkonu.

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 v Azure Portal a prostřednictvím protokolů Azure Monitor. Metriky můžou poskytovat skvělé přehledy jak pro agregovanou, tak pro konkrétního tenanta. Jednotlivé databáze lze přesunout mezi fondy a poskytnout tak rezervované prostředky konkrétnímu klientovi. Tyto nástroje vám umožňují zajistit dobrý výkon za cenu.

Š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, jako je třeba i více než 100 000 databází. Tyto funkce vytvářejí vzor databáze pro plausible.

Předpokládejme například, že systém má jako jedinou databázi 1000 databázi tenanta. Databáze může mít 20 indexů. Pokud systém převede na 1000 databází s jedním tenantům, 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í standardně povolené. Automatické indexování spravuje za vás všech 20 000 indexů a jejich průběžné optimalizace vytváření a poklesu. K těmto automatizovaným akcím dochází v rámci jednotlivých databází a nejsou koordinované ani omezené podobnými akcemi v jiných databázích. Automatické indexování pracuje s indexy v zaneprázdněné databázi jinak než v méně vytížených databázích. Tento typ přizpůsobení správy indexů by byl pro škálování databáze na tenanta nepraktický, pokud by bylo nutné tuto obrovskou úlohu správy provést ručně.

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

• Integrované zálohy.
• Vysoká dostupnost
• Šifrování na disku.
• Telemetrie výkonu.

Automation

Operace správy je možné skriptovat a nabízeny prostřednictvím modelu devops. Tyto operace je možné v aplikaci dokonce automatizovat a vystavovat.

Můžete například automatizovat obnovení jednoho tenanta k dřívějšímu bodu v čase. Obnovení potřebuje pouze obnovit 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ě podrobné úrovni jednotlivých tenantů.

E. Aplikace s více tenanty s více tenanty

Dalším dostupným vzorem je uložení mnoha tenantů do databáze 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átoru tenanta, aby bylo možné selektivně načíst data z libovolného tenanta. Schéma může dále vyžadovat několik tabulek nebo sloupců, které používá pouze podmnožina tenantů. Statický kód a referenční data se ale ukládají jenom jednou a sdílí je všechny tenanty.

Izolace tenanta je neschůdná

Data:   Více tenantů databáze nutně nesnížuje izolaci tenantů. Data více tenantů se ukládají společně do jedné databáze. Během vývoje se ujistěte, že dotazy nikdy nezpřístupňuje data z více než jednoho tenanta. SQL Database podporuje zabezpečení naúrovni řádků, které může vynucovat, 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 bude přijatelně výkonná. Systém Azure ale nemá žádný integrovaný způsob, jak monitorovat nebo spravovat používání těchto prostředků jednotlivým tenantem. Proto databáze s více tenanty s sebou nese zvýšené riziko, že dojde k hlučným sousedům, kdy zatížení jednoho overaktivního tenanta má vliv na 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í. Pro scénáře, kdy tenanti potřebují jenom omezené úložiště, by se potenciálně miliony tenantů mohly ukládat do jedné databáze. Žádný elastický fond nemůže obsahovat miliony databází. Řešení obsahující 1 000 databází na fond s 1 000 fondy ale může dosáhnout škály milionů s rizikem, že bude správa neschůdná.

V následujícím článku jsou popsány dvě varianty více tenantů databázového modelu, kdy model shardovaných více tenantů je nej flexibilnější a škálovatelný.

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

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

Implementace operací správy zaměřených na jednotlivé tenanty je složitější v databázi s více tenanty. 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 bodu v čase pouze pro jednoho tenanta.

G. Aplikace s více tenanty s horizontální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 mezi více databází nebo horizontálních oddílů, kde jsou všechna data pro jednoho tenanta obsažena v jednom horizontálním oddílu. V kombinaci s modelem více tenantů umožňuje shardovaný model téměř neomezené škálování.

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

Shardování zvyšuje složitost návrhu i provozní správy. Katalog se vyžaduje, aby bylo možné udržovat mapování mezi tenanty a databázemi. Kromě toho se ke správě horizontálních oddílů a populace tenantů vyžaduje postupy správy. Například postupy musí být navržené tak, aby přidávají a odebírat horizontální oddíly a přesouvaly data tenantů mezi horizontálními oddíly. Jedním ze škálování je přidání nového horizontálního oddílu a jeho naplnění pomocí nových tenantů. V jiných časech můžete shardy s hustotou rozdělit na dva horizontální oddíly s méně hustotou. Po přesunu nebo ukončení několika tenantů můžete sloučit řídce naplněné horizontální oddíly dohromady. Sloučení by mělo za následek nákladově efektivnější využití prostředků. Tenanty je také možné přesouvat mezi horizontálními oddíly, aby bylo možné vyvážit úlohy.

SQL Database poskytuje nástroj pro dělení a slučování, 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 přesouvat data tenantů mezi horizontálními oddíly. Aplikace také udržuje katalog během těchto operací a před přesunutím těchto tenantů označit ovlivněné tenanty jako offline. Po přesunutí aplikace katalog znovu aktualizuje novým mapováním a označení tenanta jako znovu online.

Menší databáze se snadněji spravují

Distribucí tenantů mezi více databází vede řešení shardovaných více tenantů k menším databázím, které se snadněji spravují. Například obnovení konkrétního tenanta k dřívějšímu bodu v čase teď zahrnuje obnovení jedné menší databáze ze zálohy, nikoli větší databáze, která obsahuje všechny tenanty. Je možné zvolit velikost databáze a počet tenantů na databázi, aby se vyvážit zatížení a úsilí správy.

Identifikátor tenanta ve schématu

V závislosti na použitém přístupu k horizontálnímu dělení mohou být pro schéma databáze stanovených další omezení. Aplikace SQL Database rozdělení/sloučení vyžaduje, aby schéma obsahuje klíč horizontálního dělení, což je obvykle identifikátor tenanta. Identifikátor tenanta je úvodní prvek v primárním klíči všech shardovaných tabulek. Identifikátor tenanta umožňuje aplikaci pro dělení a slučování rychle vyhledat a přesunout data přidružená ke konkrétnímu tenantovi.

Elastický fond pro horizontální oddíly

Shardované databáze s více tenanty je možné umístit do elastických fondů. Obecně platí, že mít ve fondu mnoho databází s jedním tenantem 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 databáze s horizontálním dělením na více tenantů

V hybridním modelu mají všechny databáze ve schématu identifikátor tenanta. Všechny databáze jsou schopné ukládat více než jednoho tenanta a databáze je možné shardovat. Ve smyslu schématu jsou to tedy všechny databáze s více tenanty. V praxi ale některé z těchto databází obsahují pouze jednoho tenanta. Bez ohledu na to nemá množství tenantů uložených v dané databázi žá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ů. Tenanta můžete také přiřadit k nové databázi s jedním tenantem při zřizování nové databáze.

Hybridní model vynikne, 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 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á je sdílená mezi všemi tenanty bezplatné zkušební verze. Když se bezplatná zkušební verze tenanta přihlásí k odběru úrovně služby Basic, je možné tohoto tenanta přesunout do jiné více tenantské databáze, která může mít méně tenantů. Odběratel, který platí za úroveň služby Premium, může být přesunut do vlastní nové databáze s jedním tenantem.

Fondy

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

I. Porovnání modelů architektury

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

Další kroky

• Nasazení a zkoumání víceklientské aplikace Wingtip, která používá model SaaS pro jednotlivé klienty – Azure SQL Database

• Vítá vás ukázková lístky Wingtip SaaS Azure SQL Database aplikace tenantů