Modelli di progettazione per le applicazioni SaaS multi-tenant e Azure AI Search

Un'applicazione multi-tenant è un'applicazione che fornisce gli stessi servizi e funzionalità a un numero qualsiasi di tenant che non possono vedere o condividere i dati di nessun altro tenant. Questo articolo illustra le strategie di isolamento dei tenant per le applicazioni multi-tenant compilate con Azure AI Search.

Concetti di Azure AI Search

Come soluzione di ricerca come servizio, Azure AI Search consente agli sviluppatori di aggiungere esperienze di ricerca avanzate alle applicazioni, senza dover gestire un'infrastruttura o diventare esperti in recupero delle informazioni. I dati vengano caricati nel servizio e quindi archiviati nel cloud. Tramite semplici richieste all'API Azure AI Search, i dati possono essere modificati e ricercati.

Servizi di ricerca, indici, campi e documenti

Prima di discutere dei criteri di progettazione, è importante comprendere alcuni concetti di base.

Quando si usa Azure AI Search, si sottoscrive un servizio di ricerca. Quando i dati vengono caricati in Azure AI Search, vengono archiviati in un indice all'interno del servizio di ricerca. In un solo servizio possono essere presenti molti indici. Facendo riferimento ai familiari concetti relativi ai database, il servizio di ricerca può essere paragonato a un database, mentre gli indici all'interno di un servizio possono essere paragonati alle tabelle di un database.

Ogni indice all'interno di un servizio di ricerca ha un proprio schema, definito da un certo numero di campipersonalizzabili. I dati vengono aggiunti a un indice di Azure AI Search sotto forma di singoli documenti. Ogni documento deve essere caricato in un indice specifico e deve adattarsi allo schema di tale indice. Quando si eseguono ricerche di dati tramite Azure AI Search, vengono eseguite query di ricerca full-text su un particolare indice. Facendo riferimento ai database, i campi possono essere paragonati alle colonne e i documenti alle righe di una tabella del database.

Scalabilità

Qualsiasi servizio di Azure AI Search nel piano tariffario Standard può essere ridimensionato in due sensi: archiviazione e disponibilità.

• partizioni per aumentare lo spazio di archiviazione di un servizio di ricerca.
• repliche a un servizio per aumentare la velocità effettiva delle richieste che un servizio di ricerca può gestire.

Aggiungendo e rimuovendo partizioni e repliche si consentirà alla capacità del servizio di ricerca di crescere in base alla quantità di dati e al traffico richiesti dall'applicazione. Affinché un servizio di ricerca rispetti un contratto di serviziodi lettura, sono necessarie due repliche. Affinché un servizio rispetti un contratto di serviziodi lettura-scrittura, sono necessarie tre repliche.

Limiti dei servizi e degli indici in Azure AI Search

Esistono vari piani tariffari per Azure AI Search, ciascuno dei quali presenta quote e limiti differenti. Alcuni di questi limiti sono a livello di servizio, altri sono a livello di indice e altri ancora a livello di partizione.

S3 ad alta densità

Nel piano tariffario S3 di Azure AI Search è disponibile un'opzione per la modalità a densità elevata (HD) progettata specificamente per gli scenari multi-tenant. In molti casi è necessario supportare un numero elevato di tenant più piccoli in un singolo servizio, per ottenere vantaggi come semplicità e convenienza.

S3 HD consente di comprimere numerosi indici di piccole dimensioni, che vengono quindi gestiti da un singolo servizio di ricerca, sacrificando la possibilità di aumentare il numero di indici che usano le partizioni in cambio dell'hosting di un maggior numero di indici in un singolo servizio.

Un servizio S3 è progettato per ospitare un numero fisso di indici (al massimo 200) e consentire a ogni indice di ridimensionare le dimensioni orizzontalmente man mano che vengono aggiunte nuove partizioni al servizio. L'aggiunta di partizioni ai servizi S3 HD aumenta il numero massimo di indici che il servizio può ospitare. La dimensione massima ideale per un singolo indice S3HD è di circa 50 - 80 GB, anche se non esiste alcun limite di dimensioni rigido per ogni indice imposto dal sistema.

Considerazioni per le applicazioni multi-tenant

Le applicazioni multi-tenant devono distribuire in modo efficace le risorse tra i tenant mantenendo al tempo stesso un certo livello di privacy tra i vari tenant. Quando si progetta l'architettura di un'applicazione di questo tipo, ci sono alcuni aspetti da considerare:

• Isolamento del tenant: gli sviluppatori di applicazioni devono adottare misure appropriate per assicurarsi che nessun tenant non autorizzato o indesiderato acceda ai dati di altri tenant. Oltre alla questione della privacy dei dati, le strategie di isolamento tenant richiedono una gestione efficace delle risorse condivise e la protezione da vicini fastidiosi.

• Costi delle risorse del cloud: come con qualsiasi altra applicazione, le soluzioni software devono rimanere competitive quando sono componenti di un'applicazione multi-tenant.

• Semplicità delle operazioni: quando si sviluppa un'architettura multi-tenant, l'impatto sulle operazioni e la complessità dell'applicazione è un fattore importante. Azure AI Search ha un contratto di servizio al 99,9%.

• Footprint globale: le applicazioni multi-tenant spesso devono servire tenant distribuiti in tutto il mondo.

• Scalabilità: gli sviluppatori di applicazioni devono mantenere le applicazioni a un livello di complessità sufficientemente ridotto e allo stesso tempo progettarle in maniera che siano scalabili in base al numero di tenant e alla dimensione dei dati e del carico di lavoro dei tenant.

Azure AI Search offre alcuni limiti che consentono di isolare i dati e il carico di lavoro dei tenant.

Modellazione del multi-tenancy con Azure AI Search

Nel caso di uno scenario multi-tenant, lo sviluppatore dell'applicazione usa uno o più servizi di ricerca e divide i tenant tra i servizi, gli indici o entrambi. Azure AI Search offre alcuni modelli comuni per la modellazione di uno scenario multi-tenant:

• Un indice per tenant: ogni tenant ha un proprio indice all'interno di un servizio di ricerca che è condiviso con altri tenant.

• Un servizio per tenant: ogni tenant ha un proprio servizio Azure AI Search dedicato, il che offre un livello più elevato di separazione dei dati e del carico di lavoro.

• Combinazione di entrambi: ai tenant più grandi e attivi vengono assegnati servizi dedicati mentre ai tenant più piccoli vengono assegnati singoli indici all'interno di servizi condivisi.

Modello 1: un indice per tenant

In un modello con un indice per tenant più tenant occupano un singolo servizio di Azure AI Search in cui ogni tenant ha un proprio indice.

I tenant ottengono l'isolamento dei dati perché tutte le richieste di ricerca e le operazioni sui documenti sono emesse a livello di indice in Azure AI Search. Nel livello dell'applicazione si rileva la necessità di indirizzare il traffico dei diversi tenant agli indici corretti gestendo al tempo stesso le risorse a livello di servizio tra tutti i tenant.

Una caratteristica importante del modello "indice per tenant" è la possibilità per lo sviluppatore di applicazioni di eseguire l'oversubscription della capacità di un servizio di ricerca tra i tenant dell'applicazione. Se la distribuzione del carico di lavoro fra i tenant non è uniforme, è possibile distribuire una combinazione ottimale di tenant tra gli indici di un servizio di ricerca in modo da sistemare un certo numero di tenant molto attivi e che richiedono molte risorse, servendo al tempo stesso una lunga coda di tenant meno attivi. Lo svantaggio del modello è la sua incapacità di gestire le situazioni in cui tutti i tenant sono simultaneamente molto attivi.

Il modello con un indice per tenant costituisce la base per un modello di costo variabile, in cui un intero servizio di Azure AI Search viene prima acquistato e poi completato con i tenant. In questo modo la capacità inutilizzata può essere destinata ad account di prova e gratuiti.

Per le applicazioni con una presenza globale, il modello con un indice per tenant potrebbe non essere il più efficiente. Se i tenant di un'applicazione vengono distribuiti in tutto il mondo, potrebbe essere necessario un servizio diverso per ogni area, duplicando quindi i costi per ognuno di essi.

Azure AI Search consente il ridimensionamento verso l'alto dei singoli indici e anche l'incremento del numero totale di indici. Se viene scelto un piano tariffario appropriato, possono essere aggiunte partizioni e repliche all'intero servizio di ricerca quando un singolo indice all'interno del servizio diventa troppo grande in termini di archiviazione o traffico.

Se il numero totale di indici diventa troppo grande per un singolo servizio, è necessario eseguire il provisioning di un altro servizio per accogliere i nuovi tenant. Se è necessario spostare determinati indici tra i servizi di ricerca quando vengono aggiunti nuovi servizi, i dati dell'indice devono essere copiati manualmente da un indice all'altro in quanto Azure AI Search non consente di spostare un indice.

Modello 2: un servizio per tenant

In un'architettura "servizio per tenant" ogni tenant dispone di un proprio servizio di ricerca.

In questo modello l'applicazione ottiene il massimo livello di isolamento per i suoi tenant. Ogni servizio ha risorse di archiviazione e velocità effettiva dedicate per la gestione delle richieste di ricerca. Ogni tenant ha la proprietà individuale delle chiavi API.

Per le applicazioni in cui ogni tenant ha grandi dimensioni o il carico di lavoro è poco variabile da un tenant all'altro, il modello con un servizio per tenant è una scelta efficace in quanto le risorse non sono condivise tra i carichi di lavoro dei diversi tenant.

Un modello "servizio per tenant" offre inoltre il vantaggio della stimabilità dei costi fissi. Non è necessario alcun investimento iniziale in un intero servizio di ricerca fino a quando non c'è un tenant che lo occupa, tuttavia il costo per tenant è superiore rispetto al modello con un indice per tenant.

Il modello "servizio per tenant" è una scelta efficiente per le applicazioni con una presenza globale. Con i tenant distribuiti geograficamente è facile avere il servizio di ciascun tenant nell'area appropriata.

Problematiche di scalabilità di questo modello si verificano quando i singoli tenant diventano troppo grandi per il servizio. Azure AI Search attualmente non supporta l'aggiornamento del piano tariffario di un servizio di ricerca, pertanto tutti i dati dovranno essere copiati manualmente in un nuovo servizio.

Modello 3: ibrido

Un'altra possibilità per la modellazione multi-tenancy consiste nell'unione delle due strategie "indice per tenant" e "servizio per tenant".

Combinando i due modelli, i tenant più grandi di un'applicazione possono occupare servizi dedicati mentre la lunga coda di tenant più piccoli e meno attivi può occupare gli indici in un servizio condiviso. Questo modello garantisce ai tenant più grandi di ottenere prestazioni elevate e coerenti dal servizio, contribuendo al tempo stesso a proteggere i tenant più piccoli da eventuali vicini fastidiosi.

L'implementazione di questa strategia si basa tuttavia sulla previsione di quali tenant richiederanno un servizio dedicato e non un indice in un servizio condiviso. La complessità dell'applicazione aumenta con la necessità di gestire entrambi questi modelli multi-tenancy.

Raggiungimento di una granularità ancora maggiore

I modelli di progettazione descritti sopra per la modellazione di scenari multi-tenant in Azure AI Search si basano sul presupposto di un ambito uniforme in cui ogni tenant è un'istanza completa di un'applicazione. Le applicazioni tuttavia possono gestire a volte numerosi ambiti più piccoli.

Se i modelli con un servizio per tenant e con un indice per tenant non hanno un ambito sufficientemente piccolo, è possibile modellare un indice per ottenere un livello di granularità ancora più preciso.

Per ottenere che un singolo indice si comporti in modo diverso per endpoint del client diversi, è possibile aggiungere un campo a un indice che stabilisce un determinato valore per ogni possibile client. Ogni volta che un client chiama Azure AI Search per eseguire una query o modificare un indice, il codice dall'applicazione client specifica il valore appropriato per quel campo mediante la funzionalità di filtro di Azure AI Search in fase di query.

Questo metodo può essere usato per ottenere funzionalità di account utente diversi, livelli di autorizzazione diversi e persino applicazioni completamente diverse.

Nota

L'uso dell'approccio descritto sopra per configurare un singolo indice per più tenant influisce sulla pertinenza dei risultati della ricerca. I punteggi di pertinenza della ricerca vengono calcolati a livello di indice, non a livello di tenant, quindi tutti i dati dei tenant vengono incorporati nelle statistiche dei punteggi di pertinenza, ad esempio la frequenza del termine.

Passaggi successivi

Azure AI Search è una scelta interessante per molte applicazioni. Quando si valutano i vari modelli di progettazione per le applicazioni multi-tenant, è opportuno considerare i vari piani tariffari e i rispettivi limiti del servizio per adattare al meglio Azure AI Search ad architetture o carichi di lavoro applicativi di qualsiasi dimensione.