Multitenancy e Azure Managed Redis

Azure Managed Redis è un archivio dati in memoria basato su Redis Enterprise. Azure Redis gestito viene comunemente usato per migliorare le prestazioni della soluzione, ridurre il carico sul database o altri componenti del livello dati e ridurre al minimo la quantità di stato archiviata nei nodi di calcolo.

Questo articolo descrive alcune delle funzionalità di Azure Redis gestite utili nelle soluzioni multi-tenant. Fornisce anche collegamenti a linee guida che consentono di pianificare come usare Azure Redis gestito nella soluzione.

Modelli di isolamento

Quando si usa un sistema multi-tenant che usa Azure Redis gestito, è necessario determinare il livello di isolamento da usare. Azure Managed Redis supporta due modelli di isolamento primari.

La tabella seguente riepiloga le differenze tra i principali modelli di isolamento della tenancy per Azure Managed Redis.

Istanza della cache condivisa

È consigliabile distribuire una singola cache e usarla per archiviare i dati memorizzati nella cache per alcuni o tutti i tenant. Questo approccio viene comunemente usato quando si dispone di una singola istanza dell'applicazione condivisa da tutti i tenant.

Quando si valuta la distribuzione di una cache condivisa per più tenant, tenere presente quanto segue:

• Separazione dei dati: Quando si segue questo approccio, l'applicazione è responsabile esclusivamente della separazione dei dati del tenant. È possibile usare i prefissi chiave per distinguere i dati da tenant diversi, ma l'applicazione deve essere diligente sull'accesso solo ai dati per il tenant con cui lavora. In alternativa, è possibile prendere in considerazione l'uso di strutture di dati Redis, ad esempio set o hash, per i dati di ogni tenant. Ciascuno di questi approcci supporta un numero elevato di chiavi, in modo che possa scalare a molti tenant. Tuttavia, è necessario gestire l'autorizzazione all'interno dell'applicazione anziché all'interno della cache.

• Identificatori del tenant e prefissi di chiave: Quando si esegue l'onboarding di un nuovo tenant in una cache condivisa, stabilire una convenzione di prefisso chiave univoca e resistente alle collisioni, ad esempio usando un identificatore del tenant. Se la soluzione usa moduli Redis, pianificare la selezione del modulo in fase di creazione dell'istanza perché non è possibile aggiungere moduli in un secondo momento. Quando si esegue l'offboarding di un tenant, usare il comando SCAN con un modello specifico per identificare ed eliminare le chiavi del tenant. Se è necessario eseguire la migrazione di un tenant da una cache condivisa a un'istanza dedicata, usare la funzionalità di importazione/esportazione per trasferire i dati.

  Azure Redis gestito è configurato internamente per utilizzare il clustering su tutti i livelli e gli SKU. Il clustering può influire sulla modalità di gestione dei dati del tenant introducendo CROSSSLOT restrizioni sui comandi multichiavi. Per evitare CROSSSLOT errori quando si opera sui dati di un singolo tenant, è opportuno considerare l'uso di hash tag Redis, come {tenantId}, come parte della convenzione di denominazione delle chiavi. I tag hash assicurano che tutte le chiavi per un singolo tenant si trovino nella stessa partizione.

• Criteri del cluster: La scelta dei criteri del cluster influisce sull'approccio multi-tenancy. I criteri del cluster OSS offrono prestazioni ottimali, ma richiedono librerie client con riconoscimento del cluster. I criteri del cluster Enterprise utilizzano un singolo endpoint e sono più semplici da configurare, ma possono diventare un collo di bottiglia con un valore di throughput elevato. I criteri non cluster sono disponibili solo per le istanze di 25 GB o inferiori ed è utile per gli scenari di migrazione da istanze non cluster Azure Cache for Redis.

• Evitare problemi di interferenza tra tenant: Quando condividi un'istanza della cache tra tenant, considera che tutti i tenant condividono le stesse risorse di calcolo sottostanti per la cache. Questo approccio può essere vulnerabile al problema del vicino rumoroso. Assicurarsi di seguire le procedure consigliate per Azure Redis gestito per usare le risorse della cache in modo efficiente e ridurre eventuali effetti adiacenti rumorosi. Le procedure consigliate includono:

  • Ridimensionamento
  • Gestione della memoria
  • Gestione del carico del server

  Prendere in considerazione il monitoraggio delle risorse della cache, ad esempio CPU e memoria. Se si osserva una pressione delle risorse, considerare le mitigazioni seguenti:

  • Scalare verso un livello di cache con risorse più elevate. Azure Managed Redis offre i livelli Memory Optimized, Balanced e Compute Optimized, ciascuno con diversi rapporti memoria-vCPU.
  • Scalare su più cache partizionando i tuoi dati nella cache. Un'opzione consiste nel partizionare in base al tenant, in cui alcuni tenant usano la cache A e altri usano la cache B. In alternativa, è possibile partizionare in base al sottosistema, in cui una parte della soluzione memorizza nella cache A i dati per tutti i tenant, mentre un'altra parte della soluzione memorizza nella cache B.

• Limits: Ogni SKU Redis gestito Azure ha un numero di connessioni client. Questo limite aumenta con livelli di prestazioni superiori e dimensioni di istanza maggiori. Quando si pianifica il numero di tenant da gestire da una cache condivisa, valutare se il numero totale di connessioni da tutti i tenant potrebbe raggiungere questo limite.

• Cost allocation: Quando più tenant condividono una cache, è complesso misurare il contributo ai costi di ogni tenant perché la fatturazione di Azure Managed Redis avviene a livello di istanza. Valutare la possibilità di implementare la misurazione a livello di applicazione per tenere traccia del consumo delle risorse per tenant. Per le istanze dedicate, usare Azure tag di risorsa per attribuire i costi ai singoli tenant.

Istanza della cache per cliente

È possibile valutare la possibilità di distribuire un'istanza separata di Azure Redis gestita per ogni tenant. Non esiste alcun limite al numero di cache che è possibile distribuire all'interno di una singola sottoscrizione Azure. Questo approccio offre il livello più elevato di isolamento dei dati e delle prestazioni. È anche possibile configurare l'istanza di ogni tenant con un livello diverso, ad esempio Calcolo ottimizzato per i tenant Premium e Bilanciato per i tenant standard.

Quando si valuta la distribuzione di una cache per ogni tenant, tenere presente quanto segue:

• Gestione costi: Ogni cache viene fatturata come risorsa Azure separata. Questo modello di isolamento significa che man mano che il numero di tenant aumenta, potresti incorrere in costi maggiori. Inoltre, questo approccio spesso non usa in modo efficiente le risorse di ogni cache perché ogni istanza di Redis gestita di Azure supporta in genere volumi elevati di richieste. È consigliabile considerare questo approccio di isolamento solo se si hanno requisiti rigorosi di isolamento dei dati o delle prestazioni.

• Networking: Azure Managed Redis usa private endpoint per l'isolamento della rete. L'inserimento della rete virtuale non è supportato. Se la soluzione richiede l'isolamento di rete per tenant, ogni tenant necessita di un'istanza di cache separata con il proprio endpoint privato.

• Encryption: Azure Managed Redis crittografa i dati in transito tramite TLS e supporta customer-managed keys (CMK) per la crittografia del disco. La CMK è applicata a ogni istanza della cache, non per tenant. I dati archiviati in memoria non vengono crittografati dal servizio. Se i tenant hanno requisiti rigorosi di protezione dei dati, è consigliabile implementare la crittografia a livello di applicazione prima di scrivere dati sensibili nella cache.

Funzionalità di Azure Redis gestito che supportano la multi-tenancy

Le funzionalità Azure Redis gestite seguenti supportano la multi-tenancy.

autenticazione Microsoft Entra ID

Azure Managed Redis usa Microsoft Entra ID per l'autenticazione per impostazione predefinita. Quando si crea una nuova cache, l'autenticazione della chiave di accesso è disabilitata. Aggiungi singoli utenti di Microsoft Entra o entità del servizio all'elenco degli utenti Redis dell'istanza della cache.

Gli utenti autenticati ricevono l'accesso completo ai dati a tutte le chiavi nella cache. Azure Redis gestito non supporta attualmente criteri di accesso ai dati personalizzati che limitano l'accesso a chiavi o modelli chiave specifici. Nelle soluzioni multi-tenant la mancanza di restrizione dell'accesso a livello di chiave significa che non è possibile limitare un'identità specifica per accedere solo alle chiavi di un tenant specifico all'interno di una cache condivisa. Se la soluzione richiede il controllo di accesso per tenant a livello di cache, è consigliabile usare istanze della cache separate per ogni tenant.

Replica geografica attiva

Molte soluzioni multi-tenant devono essere distribuite geograficamente. È possibile condividere un livello applicazione distribuito a livello globale. In questo scenario, le istanze dell'applicazione leggono e scrivono in una cache vicina per mantenere prestazioni accettabili. Azure Redis gestito supporta l'interconnessione di più cache tra regioni in una configurazione attiva-attiva.

Moduli Redis

Azure Managed Redis supporta moduli Redis, che estendono le strutture di dati Redis di base con funzionalità aggiuntive. L'elenco seguente contiene alcuni moduli Redis che possono essere utili nelle soluzioni multi-tenant:

• RediSearch offre la ricerca full-text, l'indicizzazione secondaria e la ricerca di somiglianza vettoriale. In un contesto multi-tenant è possibile creare indici di ricerca per tenant all'interno di un'istanza della cache condivisa.
• RedisJSON consente di archiviare ed eseguire query su dati in formato JSON. È possibile usare RedisJSON per archiviare documenti strutturati specifici del tenant.
• RedisBloom aggiunge strutture di dati probabilistiche come filtri bloom e filtri cuckoo che sono utili per la deduplicazione tra tenant.
• RedisTimeSeries offre un'archiviazione di serie temporali ottimizzata che può essere utile per i dati di telemetria per tenant o per il monitoraggio dei dati. RedisTimeSeries non è disponibile nel livello Ottimizzato per Flash.

Contributori

Microsoft gestisce questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autori principali:

• Daniel Scott-Raynsford | Partner Solution Architect, Data & AI

Altri contributori:

• Philip Laussermair | Senior Solutions Architect, Redis Inc

Per visualizzare i profili di LinkedIn non pubblici, accedere a LinkedIn.

" output is necessary.)

• Approcci di archiviazione e dati per la multitenancy
• modelloCache-Aside
• modello di partizionamento orizzontale
• Migrare ad Azure Redis gestito