Flera klientorganisationer och Azure Cache for Redis
Azure Cache for Redis används ofta för att öka prestandan för din lösning, för att minska belastningen på databasen eller andra komponenter på datanivå och för att minska mängden tillstånd som du lagrar på beräkningsnoder. I den här artikeln beskriver vi några av funktionerna i Azure Cache for Redis som är användbara för lösningar med flera klientorganisationer och sedan tillhandahåller vi länkar till vägledningen som kan hjälpa dig när du planerar hur du ska använda Azure Cache for Redis.
Isoleringsmodeller
När du arbetar med ett system med flera klientorganisationer som använder Azure Cache for Redis måste du fatta ett beslut om vilken isoleringsnivå du vill använda. Azure Cache for Redis stöder flera isoleringsmodeller.
I följande tabell sammanfattas skillnaderna mellan de viktigaste modellerna för innehavarisolering för Azure Cache for Redis:
| Att tänka på | Delad cache, delad databas | Delad cache och databas, åtkomstkontrolllista | Delad cache, databas per klientorganisation | Cacheminne per klientorganisation |
|---|---|---|---|---|
| Dataisolering | Låg. Använda Redis-datastrukturer eller nyckelprefix för att identifiera varje klientorganisations data | Hög. Data isoleras baserat på nyckelprefix | Låg. Data separeras men ingen säkerhetsisolering tillhandahålls | Högt |
| Prestandaisolering | Låg. Alla klienter delar samma beräkningsresurser | Låg. Alla klienter delar samma beräkningsresurser | Låg. Alla klienter delar samma beräkningsresurser | Högt |
| Distributionskomplexitet | Låg | Låg medelhög | Medium | Medelhög |
| Driftkomplexitet | Låg | Låg medelhög | Låg | Medelhög |
| Resurskostnad | Låg | Låg | Låg | Hög |
| Exempelscenario | Stor lösning för flera klientorganisationer med en delad programnivå | Stor lösning för flera klientorganisationer med distinkta programidentiteter som har åtkomst till cacheminnet | Migrera ett program med en klientorganisation så att det är multitenant-medvetet | Enskilda programinstanser per klientorganisation |
Delad cacheinstans och delad databas
Du kan överväga att distribuera en enda cache med en enda Redis-databas och använda den för att lagra cachelagrade data för alla dina klienter. Den här metoden används ofta när du har en enda programinstans som alla dina klienter delar.
När du följer den här metoden är ditt program ensamt ansvarigt för att hålla klientdata åtskilda. Du kan använda nyckelprefix för att skilja data från olika klienter, men ditt program måste vara noga med att bara komma åt data för den klientorganisation som det arbetar med. Du kan också överväga att använda Redis-datastrukturer, till exempel uppsättningar eller hashvärden, för varje klientorganisations data. Var och en av dessa metoder stöder ett stort antal nycklar, så att de kan skalas till många klienter. Du måste dock hantera auktorisering i ditt program i stället för i cacheminnet.
När du delar en cacheinstans och databas mellan klientorganisationer bör du tänka på att alla dina klienter delar samma underliggande beräkningsresurser för cachen. Den här metoden kan därför vara sårbar för problem med bullriga grannar. Se till att du följer metodtipsen för Azure Cache for Redis för att få den mest effektiva användningen av cachens resurser och för att minimera eventuella störningar i grannens effekter. Metodtips är:
Överväg också att övervaka cachens resurser, till exempel CPU och minne. Om du observerar resursbelastning bör du överväga följande åtgärder:
- Skala upp till en cache-SKU eller nivå med högre resursnivåer.
- Skala ut till flera cacheminnen genom att partitionera cachelagrade data. Ett alternativ är att fragmentera efter klientorganisation, där vissa klienter använder cache A och vissa använder cache B. Eller så kan du sharda efter undersystem, där en del av din lösning cachelagrar data så att alla klienter cachelagrar A och en annan del av lösningen cachelagrar på cache B.
Delad cache och databas med åtkomstkontrollistor
Om programnivån använder distinkta identiteter för att komma åt cachen för varje klientorganisation använder du Redis-åtkomstkontrollistor. Med åtkomstkontrollistor kan du begränsa åtkomsten till klientorganisationens information till specifika identiteter. Du identifierar de data som identiteten får åtkomst till baserat på nyckelnamn eller prefix. Den här metoden kan passa bra när du har olika programinstanser för varje klientorganisation, eller om du har ett delat program som använder flera identiteter för att komma åt underordnade tjänster baserat på klientkontexten.
På samma sätt som den tidigare isoleringsmodellen innebär delning av cacheminnet och databasen att du måste vidta försiktighetsåtgärder för att undvika problemet med den bullriga grannen.
Delad cacheinstans med en databas per klientorganisation
En annan metod som du kan överväga är att distribuera en enda cacheinstans och distribuera klientspecifika Redis-databaser i instansen. Den här metoden ger en viss grad av logisk isolering av varje klientorganisations data, men den ger ingen prestandaisolering eller skydd mot bullriga grannar.
Den här metoden kan vara användbar för migreringsscenarier. Anta till exempel att du moderniserar ett program med en enda klientorganisation som inte är utformat för att fungera med flera klienter, och du konverterar det gradvis till att vara multitenancy-medveten genom att inkludera klientkontexten i alla begäranden. Du kan få vissa kostnadseffektiviteter med hjälp av en enda delad cache och du behöver inte uppdatera programmets logik för att använda klientnyckelprefix eller klientspecifika datastrukturer.
Azure Cache for Redis begränsar antalet databaser som kan skapas i en enda cache. Innan du implementerar den här metoden bör du överväga antalet klienter som du förväntar dig att växa till.
Dessutom ger den här metoden inga fördelar för säkerhetsisolering av data. I Azure Cache for Redis utförs autentisering och auktorisering på cacheinstansnivå.
Kommentar
Azure Cache for Redis stöder flera databaser på specifika nivåer och stöder inte flera databaser när du använder klustrade instanser.
Cacheinstans per klientorganisation
Du kan överväga att distribuera en separat instans av Azure Cache for Redis för varje klientorganisation. Det finns ingen gräns för hur många cacheminnen du kan distribuera i en enda Azure-prenumeration. Den här metoden ger den starkaste nivån av data och prestandaisolering.
Varje cache debiteras dock som en separat Azure-resurs, så när du växer till ett stort antal klienter kan det medföra mer kostnader. Dessutom använder den här metoden ofta inte varje caches resurser effektivt, eftersom varje Azure Cache for Redis-instans vanligtvis stöder stora mängder begäranden. Det är bäst att bara överväga den här isoleringsmetoden om du har strikta krav på data- eller prestandaisolering.
Funktioner i Azure Cache for Redis som stöder flera klientorganisationer
Listor för åtkomstkontroll
Azure Cache for Redis tillhandahåller ett kraftfullt rollbaserat åtkomstkontrollsystem som gör att du kan skapa omfattande principer för dataåtkomst för att framtvinga dina autentiserings- och auktoriseringsregler. Dessa regler kan anges på olika nivåer av kornighet, inklusive för att tillåta en användare åtkomst till cachenycklar som följer ett specifikt mönster. Genom att använda nyckelmönster kan du dela en enda cacheinstans och databas mellan flera klienter, var och en med sina egna användarkonton. Azure Cache for Redis framtvingar klientisolering för att säkerställa att en användare bara kan komma åt sin egen uppsättning nycklar som följer mönstret.
Anta till exempel att du har en klientorganisation med namnet Fabrikam. Programnivån ska bara kunna komma åt cachedata som rör Fabrikam och inte från andra klienter. Du kan definiera en anpassad åtkomstprincip som tillåter läsning och inställning av alla cachenycklar som börjar med Fabrikam:
+@read +set ~Fabrikam*
Du kan sedan tilldela principen till den Microsoft Entra-identitet som din Fabrikam-programinstans använder. När du har konfigurerat cacheminnet kan Fabrikam-användaren komma åt nycklar med namnet FabrikamData1 och FabrikamUserDetails, men inte ContosoData1.
Aktiv geo-replikering
Många lösningar för flera klientorganisationer måste vara geo-distribuerade. Du kan dela en globalt distribuerad programnivå, där dina programinstanser läser från och skriver till en närliggande cache för att upprätthålla acceptabel prestanda. Enterprise-nivån i Azure Cache for Redis stöder länkning av flera cacheminnen mellan regioner i en aktiv-aktiv konfiguration.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudsakliga författare:
- John Downs | Huvudprogramtekniker
- Kommer Velida | Kundtekniker 2, FastTrack för Azure
Övriga medarbetare:
- Carl Dacosta | Principal Software Engineering Manager, Azure Cache for Redis
- Kyle Teegarden | Senior Program Manager, Azure Cache for Redis
- Arsen Vladimirskiy | Huvudkundtekniker, FastTrack för Azure
Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.
Nästa steg
Granska lagrings- och datametoder för flera klientorganisationer.