Ontwerppatronen voor SaaS-toepassingen met meerdere tenants en Azure AI Search
Een multitenant-toepassing is een toepassing die dezelfde services en mogelijkheden biedt aan een willekeurig aantal tenants die de gegevens van een andere tenant niet kunnen zien of delen. In dit artikel worden tenantisolatiestrategieën besproken voor multitenant-toepassingen die zijn gebouwd met Azure AI Search.
Concepten van Azure AI Search
Als search-as-a-service-oplossing kunnen ontwikkelaars met Azure AI Search uitgebreide zoekervaringen toevoegen aan toepassingen zonder infrastructuur te beheren of een expert te worden op het gebied van het ophalen van gegevens. Gegevens worden geüpload naar de service en vervolgens opgeslagen in de cloud. Met eenvoudige aanvragen voor de Azure AI Search-API kunnen de gegevens vervolgens worden gewijzigd en doorzocht.
Search-service s, indexen, velden en documenten
Voordat u ontwerppatronen bespreekt, is het belangrijk om een aantal basisconcepten te begrijpen.
Wanneer u Azure AI Search gebruikt, abonneert u zich op een zoekservice. Wanneer gegevens worden geüpload naar Azure AI Search, worden deze opgeslagen in een index in de zoekservice. Er kan een aantal indexen binnen één service zijn. Als u de vertrouwde concepten van databases wilt gebruiken, kan de zoekservice worden gekoppeld aan een database, terwijl de indexen in een service kunnen worden liken aan tabellen in een database.
Elke index in een zoekservice heeft een eigen schema, dat wordt gedefinieerd door een aantal aanpasbare velden. Gegevens worden toegevoegd aan een Azure AI Search-index in de vorm van afzonderlijke documenten. Elk document moet worden geüpload naar een bepaalde index en moet voldoen aan het schema van die index. Bij het doorzoeken van gegevens met behulp van Azure AI Search worden de query's voor zoekopdrachten in volledige tekst uitgevoerd op basis van een bepaalde index. Als u deze concepten wilt vergelijken met die van een database, kunnen velden worden vergeleken met kolommen in een tabel en documenten kunnen worden vergeleken met rijen.
Schaalbaarheid
Elke Azure AI-Search-service in de prijscategorie Standard kan worden geschaald in twee dimensies: opslag en beschikbaarheid.
- Partities kunnen worden toegevoegd om de opslag van een zoekservice te vergroten.
- Replica's kunnen worden toegevoegd aan een service om de doorvoer van aanvragen te verhogen die een zoekservice kan verwerken.
Als u partities en replica's toevoegt en verwijdert, kan de capaciteit van de zoekservice toenemen met de hoeveelheid gegevens en verkeer die de toepassing vereist. Voor een zoekservice om een lees-SLA te bereiken, zijn er twee replica's vereist. Voor een service om een SLA voor lezen/schrijven te realiseren, zijn er drie replica's vereist.
Service- en indexlimieten in Azure AI Search
Er zijn enkele verschillende prijscategorieën in Azure AI Search, elk van de lagen heeft verschillende limieten en quota. Sommige van deze limieten bevinden zich op serviceniveau, sommige bevinden zich op indexniveau en sommige op partitieniveau.
S3 High Density
In de prijscategorie S3 van Azure AI Search is er een optie voor de high-densitymodus (HD) die speciaal is ontworpen voor scenario's met meerdere tenants. In veel gevallen is het nodig om een groot aantal kleinere tenants onder één service te ondersteunen om de voordelen van eenvoud en kostenefficiëntie te realiseren.
Met S3 HD kunnen de vele kleine indexen worden verpakt onder het beheer van één zoekservice door de mogelijkheid om indexen uit te schalen met behulp van partities voor de mogelijkheid om meer indexen in één service te hosten.
Een S3-service is ontworpen om een vast aantal indexen (maximaal 200) te hosten en elke index horizontaal te schalen wanneer nieuwe partities aan de service worden toegevoegd. Het toevoegen van partities aan S3 HD-services verhoogt het maximum aantal indexen dat door de service kan worden gehost. De ideale maximale grootte voor een afzonderlijke S3HD-index is ongeveer 50 - 80 GB, hoewel er geen vaste groottelimiet is voor elke index die door het systeem wordt opgelegd.
Overwegingen voor multitenant-toepassingen
Multitenant-toepassingen moeten resources effectief verdelen over de tenants, met behoud van een zekere mate van privacy tussen de verschillende tenants. Er zijn enkele overwegingen bij het ontwerpen van de architectuur voor een dergelijke toepassing:
Tenantisolatie: toepassingsontwikkelaars moeten passende maatregelen nemen om ervoor te zorgen dat geen tenants onbevoegde of ongewenste toegang hebben tot de gegevens van andere tenants. Naast het perspectief van gegevensprivacy vereisen tenantisolatiestrategieën effectief beheer van gedeelde resources en bescherming tegen lawaaierige buren.
Kosten voor cloudresources: net als bij elke andere toepassing moeten softwareoplossingen concurrerend blijven als onderdeel van een multitenant-toepassing.
Gemak van bewerkingen: bij het ontwikkelen van een architectuur met meerdere tenants is de impact op de bewerkingen en complexiteit van de toepassing een belangrijke overweging. Azure AI Search heeft een SLA van 99,9%.
Wereldwijde footprint: Multitenant-toepassingen moeten vaak tenants bedienen die over de hele wereld worden gedistribueerd.
Schaalbaarheid: toepassingsontwikkelaars moeten overwegen hoe ze afstemmen tussen het onderhouden van een voldoende laag niveau van toepassingscomplexiteit en het ontwerpen van de toepassing om te schalen met het aantal tenants en de grootte van de gegevens en workload van tenants.
Azure AI Search biedt enkele grenzen die kunnen worden gebruikt om de gegevens en workload van tenants te isoleren.
Multitenancy modelleren met Azure AI Search
In het geval van een scenario met meerdere tenants verbruikt de toepassingsontwikkelaar een of meer zoekservices en verdeelt de tenants tussen services, indexen of beide. Azure AI Search heeft enkele veelvoorkomende patronen bij het modelleren van een scenario met meerdere tenants:
Eén index per tenant: elke tenant heeft een eigen index binnen een zoekservice die wordt gedeeld met andere tenants.
Eén service per tenant: elke tenant heeft een eigen toegewezen Azure AI-Search-service, met het hoogste niveau van gegevens- en workloadscheiding.
Combinatie van beide: grotere, actievere tenants worden toegewezen toegewezen services, terwijl kleinere tenants afzonderlijke indexen binnen gedeelde services krijgen toegewezen.
Model 1: Één index per tenant
In een index-per-tenantmodel bezetten meerdere tenants één Azure AI-Search-service waarbij elke tenant een eigen index heeft.
Tenants bereiken gegevensisolatie omdat alle zoekaanvragen en documentbewerkingen worden uitgegeven op indexniveau in Azure AI Search. In de toepassingslaag is er behoefte aan bewustzijn om het verkeer van de verschillende tenants naar de juiste indexen te leiden en tegelijkertijd resources op serviceniveau te beheren voor alle tenants.
Een belangrijk kenmerk van het index-per-tenantmodel is de mogelijkheid voor de ontwikkelaar van de toepassing om de capaciteit van een zoekservice te overschrijven tussen de tenants van de toepassing. Als de tenants een ongelijke verdeling van de werkbelasting hebben, kan de optimale combinatie van tenants worden verdeeld over de indexen van een zoekservice om een aantal zeer actieve, resourceintensieve tenants te bieden en tegelijkertijd een lange staart van minder actieve tenants te leveren. De afweging is het onvermogen van het model om situaties te verwerken waarbij elke tenant gelijktijdig zeer actief is.
Het index-per-tenantmodel biedt de basis voor een variabel kostenmodel, waarbij een volledige Azure AI-Search-service vooraf wordt gekocht en vervolgens wordt gevuld met tenants. Hierdoor kan ongebruikte capaciteit worden aangewezen voor proefversies en gratis accounts.
Voor toepassingen met een wereldwijde footprint is het index-per-tenantmodel mogelijk niet de meest efficiënte. Als de tenants van een toepassing over de hele wereld worden verdeeld, kan een afzonderlijke service nodig zijn voor elke regio, waardoor de kosten voor elk van deze regio's worden gedupliceerd.
Met Azure AI Search kunt u de schaal van zowel de afzonderlijke indexen als het totale aantal indexen vergroten. Als u een geschikte prijscategorie kiest, kunnen partities en replica's worden toegevoegd aan de hele zoekservice wanneer een afzonderlijke index binnen de service te groot wordt in termen van opslag of verkeer.
Als het totale aantal indexen te groot wordt voor één service, moet een andere service worden ingericht voor de nieuwe tenants. Als indexen moeten worden verplaatst tussen zoekservices wanneer er nieuwe services worden toegevoegd, moeten de gegevens uit de index handmatig van de ene index naar de andere worden gekopieerd, omdat Azure AI Search niet toestaat dat een index wordt verplaatst.
Model 2: Één service per tenant
In een service-per-tenantarchitectuur heeft elke tenant een eigen zoekservice.
In dit model bereikt de toepassing het maximale isolatieniveau voor de tenants. Elke service heeft toegewezen opslag en doorvoer voor het verwerken van zoekaanvragen. Elke tenant heeft afzonderlijk eigendom van API-sleutels.
Voor toepassingen waarbij elke tenant een grote footprint heeft of de workload weinig variabiliteit heeft van tenant tot tenant, is het service-per-tenantmodel een effectieve keuze omdat resources niet worden gedeeld over de workloads van verschillende tenants.
Een service per tenantmodel biedt ook het voordeel van een voorspelbaar, vast kostenmodel. Er is geen investering vooraf in een hele zoekservice totdat er een tenant is om deze te vullen, maar de kosten per tenant zijn hoger dan een index-per-tenantmodel.
Het service-per-tenantmodel is een efficiënte keuze voor toepassingen met een wereldwijde footprint. Met geografisch gedistribueerde tenants is het eenvoudig om de service van elke tenant in de juiste regio te hebben.
De uitdagingen bij het schalen van dit patroon ontstaan wanneer afzonderlijke tenants hun service ontgroeien. Azure AI Search biedt momenteel geen ondersteuning voor het upgraden van de prijscategorie van een zoekservice, zodat alle gegevens handmatig naar een nieuwe service moeten worden gekopieerd.
Model 3: Hybride
Een ander patroon voor het modelleren van multitenancy is het combineren van index-per-tenant- en service-per-tenantstrategieën.
Door de twee patronen te combineren, kunnen de grootste tenants van een toepassing toegewezen services bezetten, terwijl de lange staart van minder actieve, kleinere tenants indexen in een gedeelde service kunnen innemen. Dit model zorgt ervoor dat de grootste tenants consistent hoge prestaties van de service hebben en tegelijkertijd de kleinere tenants beschermen tegen lawaaierige buren.
Het implementeren van deze strategie is echter afhankelijk van het voorspellen van welke tenants een toegewezen service versus een index in een gedeelde service nodig hebben. De complexiteit van toepassingen neemt toe met de noodzaak om beide multitenancymodellen te beheren.
Nog fijnere granulariteit bereiken
In de bovenstaande ontwerppatronen voor het modelleren van scenario's met meerdere tenants in Azure AI Search wordt ervan uitgegaan dat elke tenant een volledig exemplaar van een toepassing is. Toepassingen kunnen echter soms veel kleinere bereiken verwerken.
Als service-per-tenant- en index-per-tenant-modellen niet voldoende kleine bereiken zijn, is het mogelijk om een index te modelleren om een nog nauwkeurigere mate van granulariteit te bereiken.
Als u één index anders wilt laten werken voor verschillende clienteindpunten, kan een veld worden toegevoegd aan een index, die een bepaalde waarde aanwijst voor elke mogelijke client. Telkens wanneer een client Azure AI Search aanroept om een index op te vragen of te wijzigen, geeft de code van de clienttoepassing de juiste waarde voor dat veld op met behulp van de filterfunctie van Azure AI Search tijdens het uitvoeren van query's.
Deze methode kan worden gebruikt voor het bereiken van functionaliteit van afzonderlijke gebruikersaccounts, afzonderlijke machtigingsniveaus en zelfs volledig afzonderlijke toepassingen.
Notitie
Het gebruik van de hierboven beschreven benadering om één index te configureren voor meerdere tenants, is van invloed op de relevantie van zoekresultaten. Scores voor zoekrelevantie worden berekend op indexniveau, niet een bereik op tenantniveau, dus alle tenantgegevens worden opgenomen in de onderliggende statistieken van relevantiescores, zoals termfrequentie.
Volgende stappen
Azure AI Search is een aantrekkelijke keuze voor veel toepassingen. Houd bij het evalueren van de verschillende ontwerppatronen voor multitenant-toepassingen rekening met de verschillende prijscategorieën en de respectieve servicelimieten om Azure AI Search het beste aan te passen aan toepassingsworkloads en architecturen van alle grootten.