Vzory návrhu pro víceklientské aplikace SaaS a Azure AI Vyhledávač

Víceklientová aplikace je aplikace, která poskytuje stejné služby a možnosti libovolnému počtu tenantů, kteří nevidí nebo sdílejí data žádného jiného tenanta. Tento článek popisuje strategie izolace tenanta pro víceklientské aplikace vytvořené pomocí služby Azure AI Vyhledávač.

Koncepty služby Azure AI Vyhledávač

Azure AI Vyhledávač jako řešení typu vyhledávání jako služba umožňuje vývojářům přidávat do aplikací bohaté možnosti vyhledávání, aniž by museli spravovat infrastrukturu nebo se stát odborníkem na načítání informací. Data se nahrají do služby a pak se uloží do cloudu. Pomocí jednoduchých požadavků na rozhraní API služby Azure AI Vyhledávač je pak možné data upravit a prohledávat.

Vyhledávací služby, indexy, pole a dokumenty

Než začnete diskutovat o vzorech návrhu, je důležité pochopit několik základních konceptů.

Služba Azure AI Vyhledávač obsahuje jeden nebo více indexů. Každý index je nezávislá prohledávatelná datová struktura s vlastním schématem. Schéma indexu definuje pole a chování vyhledávání pro obsah. Data načtete do indexu jako dokumenty , které odpovídají schématu indexu.

Operace indexování a dotazování cílí na jeden index. Když aplikace odešle dotaz, Azure AI Vyhledávač prohledá vybraný index a vrátí odpovídající dokumenty. Schéma používá datové typy polí podporované Azure AI Vyhledávač. Když tenanti sdílejí index, musí jejich dokumenty odpovídat stejnému schématu.

Škálovatelnost a službou spravované partitionování

V cenovém modelu Dedicated se služba Azure AI Vyhledávač škáluje ve dvou dimenzích:

• Přidejte oddíly pro zvýšení kapacity úložiště a kapacity pro indexování.
• Přidejte repliky pro zvýšení propustnosti a dostupnosti dotazů.

Azure AI Vyhledávač distribuuje dokumenty v každém indexu napříč partitiony služby. Partitiony služby jsou jednotky kapacity, nikoli hranice izolace tenanta. Nezadáte vlastní klíč oddílu ani neřídíte umístění dokumentů na oddílech služby. Když přidáte oddíly nebo repliky, změníte kapacitu celé služby, která je sdílena všemi indexy v této službě.

Zvolte cenovou úroveň a kapacitu na základě předpokládaných souhrnných a na jednotlivé tenanty rozložených pracovních zátěží pro úložiště, indexování a dotazy. Úroveň služby určuje limity pro službu, indexy, dokumenty a úložiště. Další informace najdete v tématech Odhad a správa kapacity a Omezení služby ve službě Azure AI Vyhledávač.

Aby vyhrazená služba splňovala podmínky SLA dostupnosti, nakonfigurujte alespoň dvě repliky pro úlohy jen pro dotazy nebo tři repliky pro úlohy, které zahrnují indexování. Diskové oddíly nemají vliv na nárok na SLA.

Omezení služby a indexu ve službě Azure AI Vyhledávač

Azure AI Vyhledávač nabízí několik cenových úrovní s různými limity a kvótami. Některá omezení platí pro službu, zatímco jiné platí pro indexy nebo oddíly.

S3 s vysokou hustotou

Standard 3 High Density (S3 HD) je režim hostování vhodný pro scénáře s více tenanty, které vyžadují mnoho malých indexů v jedné vyhledávací službě. Může snížit náklady na jednoho tenanta a provozní režii, když model indexu na tenanta obsluhuje velký počet menších tenantů.

S3 HD podporuje podstatně více indexů než jiné úrovně Dedicated. Přidání oddílů zvyšuje počet indexů, které může služba hostovat, ale každý index má pevnou maximální velikost. Než vyberete tento režim, zkontrolujte aktuální omezení pro index, funkci a indexer S3 HD. Další informace najdete v tématu Omezení služeb ve službě Azure AI Vyhledávač.

Důležité informace o víceklientských aplikacích

Víceklientní aplikace musí efektivně distribuovat prostředky mezi tenanty a současně zachovat určitou úroveň ochrany osobních údajů mezi různými tenanty. Při návrhu architektury pro takovou aplikaci je potřeba vzít v úvahu několik aspektů:

• Izolace tenanta: Vývojáři aplikací musí přijmout vhodná opatření, aby se zajistilo, že žádní tenanti nemají neoprávněný nebo nežádoucí přístup k datům jiných tenantů. Kromě hlediska ochrany osobních údajů vyžadují strategie oddělení tenantů efektivní správu sdílených prostředků a ochranu před hlučnými sousedy.

• Náklady na cloudové prostředky: Stejně jako u jakékoli jiné aplikace musí softwarová řešení zůstat nákladově konkurenceschopná jako součást víceklientských aplikací.

• Snadné operace: Při vývoji víceklientské architektury je důležitým aspektem dopad na provoz a složitost aplikace. Azure AI Vyhledávač má smlouvu SLA o 99,9 %.

• Celosvětová působnost: Víceklientské aplikace často musí sloužit tenantům, kteří jsou distribuováni po celém světě. Naplánujte, jak regionální umístění, synchronizace dat a směrování požadavků ovlivňují každý model izolace tenantů. Další informace najdete v tématu Nasazení ve více oblastech ve službě Azure AI Vyhledávač.

• Škálovatelnost: Vývojáři aplikací musí zvážit, jak dosáhnout souladu mezi zachováním dostatečně nízké úrovně složitosti aplikace a návrhem aplikace tak, aby se škálovala s počtem uživatelů a velikostí dat a úloh uživatelů.

Azure AI Vyhledávač nabízí několik hranic, které je možné použít k izolaci dat a úloh tenantů.

Modelování víceklientské architektury pomocí služby Azure AI Vyhledávač

V případě scénáře s více tenanty vývojář aplikace využívá jednu nebo více vyhledávacích služeb a rozděluje tenanty mezi služby, indexy nebo obojí. Azure AI Vyhledávač má několik běžných vzorů při modelování scénáře s více tenanty:

• Jeden index na tenanta: Každý tenant má svůj vlastní index ve vyhledávací službě, která je sdílená s ostatními tenanty.

• Jedna služba na tenanta: Každý tenant má vlastní vyhrazenou službu Azure AI Vyhledávač, která nabízí nejvyšší úroveň dat a oddělení úloh.

• Kombinace obou: Větší a aktivnější tenanti se přiřazují vyhrazené služby, zatímco menší tenanti mají přiřazené jednotlivé indexy ve sdílených službách.

• Jeden index pro více tenantů: Index sdílí více tenantů a každý dokument obsahuje identifikátor tenanta, který aplikace používá k filtrování výsledků.

Model 1: Jeden index na tenanta

V modelu indexu pro každý tenanta, více tenantů využívá jedinou službu Azure AI Vyhledávač, kde má každý tenant svůj vlastní index.

Všechny žádosti o vyhledávání a operace s dokumentem cílí na index. Název indexu v požadavku ale není autorizační hranicí. Pokud se tenanti připojují přímo k Azure AI Vyhledávač, použijte role vymezené na úroveň indexu k omezení jednotlivých tenantů na vlastní index. Jinak směrujte žádosti přes důvěryhodnou aplikační vrstvu, která odvozuje index tenanta z ověřeného kontextu a brání volajícím v výběru indexu jiného tenanta. Nezadávejte tenantům klíče rozhraní API pro sdílenou službu, protože klíče rozhraní API udělují přístup na úrovni služby.

Klíčovým atributem modelu index-per-tenant je schopnost vývojáře aplikací přepsat kapacitu vyhledávací služby mezi tenanty aplikace. Pokud mají nájemníci nerovnoměrně rozložené pracovní zatížení, je možné optimální kombinaci nájemníků distribuovat napříč indexy vyhledávací služby, aby vyhovovala řadě vysoce aktivních, intenzivně využívajících zdrojů nájemníků a zároveň obsloužila velký počet méně aktivních nájemníků. Kompromisem je nemožnost modelu zvládnout situace, kdy je každý tenant současně vysoce aktivní.

Model indexu na nájemníka poskytuje základ pro model proměnných nákladů, kde je služba Azure AI Vyhledávač zakoupena předem a poté je naplněna nájemníky. To umožňuje určit nevyužitou kapacitu pro zkušební verze a bezplatné účty.

U aplikací s globálními nároky nemusí být model indexu na tenanta nejúčinnější. Pokud jsou tenanti aplikace rozmístěni po celém světě, možná budete potřebovat samostatnou sdílenou službu v každé oblasti, která duplikuje kapacitu a zvyšuje provozní složitost. Další informace najdete v tématu Nasazení ve více oblastech ve službě Azure AI Vyhledávač.

Azure AI Vyhledávač umožňuje škálovat jak jednotlivé indexy, tak celkový počet indexů, které se mají zvětšit. Pokud zvolíte odpovídající cenovou úroveň, oddíly a repliky se dají přidat do celé vyhledávací služby, když se jednotlivé indexy v rámci služby z hlediska úložiště nebo provozu příliš rozrůstají.

Pokud se celkový počet indexů pro jednu službu příliš rozrůstá, musí být zřízena jiná služba, aby vyhovovala novým tenantům. Pokud je potřeba přesouvat indexy mezi vyhledávacími službami při přidání nových služeb, je nutné data z indexu ručně zkopírovat z jednoho indexu do druhého, protože Azure AI Vyhledávač neumožňuje přesun indexu.

Model 2: Jedna služba na tenanta

V architektuře služby na tenanta má každý tenant vlastní vyhledávací službu.

V tomto modelu aplikace dosáhne maximální úrovně izolace pro své tenanty. Každá služba má vyhrazené úložiště a propustnost pro zpracování žádostí o vyhledávání. K autorizaci komponent a správců aplikací použijte ověřování Microsoft Entra a řízení přístupu na základě role. Pokud uživatelé tenanta přistupují k vyhledávání prostřednictvím aplikační vrstvy, zachovejte přihlašovací údaje služby v této vrstvě a vynucujte tam směrování tenant–služba. Klíče rozhraní API poskytují přístup na úrovni služby a nejsou autorizačními hranicemi zohledňujícími tenanty.

Každá vyhledávací služba se započítává do limitu služby pro svoji úroveň, předplatné a oblast. Před přijetím tohoto modelu ve velkém měřítku odhadněte požadovaný počet služeb a naplánujte navýšení kvóty, regionální distribuci nebo více předplatných Azure.

U aplikací, ve kterých má každý tenant velké nároky nebo má málo proměnlivosti mezi tenanty, je model služby na tenanta efektivní volbou, protože prostředky se nesdílejí napříč různými úlohami tenantů.

Model služby pro jednoho nájemníka také nabízí výhodu předvídatelného modelu s pevnými náklady. Neexistuje žádná počáteční investice do celé vyhledávací služby, dokud není tenant, který by ho vyplnil, ale náklady na tenanta jsou vyšší než model indexu na tenanta.

Model služby na tenanta může podporovat aplikace s globální působností, protože každou službu tenanta je možné umístit do oblasti vhodné pro daného tenanta. Vyhledávací služba je prostředek v jedné oblasti, takže pokud potřebujete odolnost proti výpadku oblasti, použijte samostatná regionální nasazení. Další informace najdete v tématu Nasazení ve více oblastech ve službě Azure AI Vyhledávač.

Problémy při škálování tohoto modelu vznikají, když jednotliví nájemníci přerostou svou službu. Stávající služby se můžou přepínat mezi úrovněmi Basic a Standard S1, S2 a S3, pokud aktuální konfigurace zapadá do limitů cílové úrovně a oblast má kapacitu. Pokud chcete přejít na jinou cenovou úroveň, vytvořte nový prostředek a znovu načtěte nebo zkopírujte obsah indexu. Další informace najdete v tématu Změna cenové úrovně.

Model 3: Hybridní

Dalším vzorem modelování multitenantní architektury je kombinace strategie indexu na tenanta se strategií služby na tenanta.

Kombinací těchto dvou vzorů mohou největší nájemci aplikace obsadit vyhrazené služby, zatímco dlouhý chvost méně aktivních, menších nájemců může využívat indexy ve sdílené službě. Tento model zajišťuje, že největší tenanti mají konzistentně vysoký výkon ze služby a zároveň pomáhají chránit menší tenanty před všemi hlučné sousedy.

Implementace této strategie spoléhá na schopnost předpovědět, kteří tenanti budou vyžadovat vyhrazenou službu versus index ve sdílené službě. Složitost aplikace se zvyšuje s nutností spravovat oba tyto víceklientské modely.

Udržujte katalog přiřazení tenantů, který mapuje každého tenanta na svou vyhledávací službu a index. Pomocí katalogu směrujte požadavky a automatizujte zřizování služeb a indexů. Když přesunete tenanta, koordinujete synchronizaci dat a aktualizace směrování a plánujete, jak zpracovávat zastaralá mapování, neúspěšná přepnutí a vrácení zpět.

Model 4: Jeden index pro více tenantů

V modelu sdíleného indexu používají dokumenty z více tenantů stejný index a schéma. Tento model poskytuje nejvyšší hustotu tenantů, ale nabízí nižší izolaci dat a výkonu než ostatní modely. Všichni tenanti sdílejí kapacitu indexu, schéma a chování vyhodnocování relevance.

Pokud chcete izolovat tenanty v rámci jednoho indexu, přidejte filtrovatelné pole, které identifikuje tenanta, který vlastní každý dokument. Důvěryhodná aplikační vrstva musí odvodit identifikátor tenanta z ověřeného kontextu a použít odpovídající filtr pro každý dotaz. Nepřijímejte identifikátor tenanta zadaný nedůvěryhodným klientem. U nahrání, aktualizace a odstranění dokumentů ověřte, že je operace pro tenanta dokumentu autorizovaná. Další informace najdete v tématu Filtry zabezpečení pro oříznutí výsledků.

Tento model použijte, pokud je hustota tenantů a nákladová efektivita důležitější než schémata specifická pro tenanty nebo silná izolace úloh a kdy aplikace dokáže spolehlivě vynutit filtry tenantů pro každou operaci.

Další kroky

Azure AI Vyhledávač je přesvědčivou volbou pro mnoho aplikací. Při vyhodnocování různých vzorů návrhu pro víceklientské aplikace zvažte různé cenové úrovně a příslušné limity služeb, které nejlépe přizpůsobí azure AI Search tak, aby vyhovovaly aplikačním úlohám a architekturám všech velikostí.

Přečtěte si tento článek společně s článkem Architektonické přístupy pro úložiště a data v multitenantních řešeních, který popisuje obecné aspekty a přístupy platné napříč datovými službami.