Mehrinstanzenfähigkeit und Azure Cache for Redis

Im Allgemeinen verwenden Sie Azure Cache for Redis, um die Leistung Ihrer Lösung zu verbessern, die Last Ihrer Datenbank oder anderer Komponenten auf Datenebene zu reduzieren und die auf Computeknoten gespeicherte Menge an Zustandsdaten zu verringern. In diesem Artikel werden einige der Features von Azure Cache for Redis beschrieben, die für mehrinstanzenfähige Lösungen nützlich sind. Im Anschluss stellen wir Links zu Leitfäden zur Verfügung, die Sie beim Planen der Verwendung von Azure Cache for Redis unterstützen können.

Isolationsmodelle

Bei der Arbeit mit einem mehrinstanzenfähigen System mit Azure Cache for Redis müssen Sie entscheiden, welche Isolationsstufe Sie verwenden möchten. Azure Cache for Redis unterstützt mehrere Isolationsmodelle.

In der folgenden Tabelle werden die Unterschiede der wichtigsten Mandantenisolationsmodelle für Azure Cache for Redis erläutert:

Aspekt	Shared Cache, Shared Datenbank	Shared Cache, Datenbank pro Mandant	Cache pro Mandanten
Datenisolation	Niedrig. Verwenden von Redis-Datenstrukturen oder Schlüsselpräfixen zum Identifizieren der Daten der einzelnen Mandanten	Niedrig. Daten werden getrennt, aber keine Sicherheitsisolation bereitgestellt	High
Leistungsisolation	Niedrig. Alle Mandanten teilen die gleichen Computeressourcen	Niedrig. Alle Mandanten teilen die gleichen Computeressourcen	High
Bereitstellungskomplexität	Niedrig	Medium	Mittelhoch
Komplexität des Betriebs	Niedrig	Niedrig	Mittelhoch
Ressourcenkosten	Niedrig	Niedrig	High
Beispielszenario	Große Lösung mit mehreren Mandanten mit freigegebener Anwendungsebene	Migrieren einer Einzelmandantenanwendung zur Multitmandant-Berücksichtigung	Einzelne Anwendungsinstanzen pro Mandant

Freigegebene Cache-Instanz und freigegebene Datenbank

Sie können einen einzelnen Cache mit einer einzigen Redis-Datenbank bereitstellen und diese zum Speichern der zwischengespeicherten Daten für all Ihre Mandanten verwenden. Dieser Ansatz wird meist verwendet, wenn Sie über eine einzelne Logikschicht verfügen, die von allen Mandanten gemeinsam genutzt wird.

Zum Isolieren mandantenspezifischer Daten innerhalb jedes Caches sollten Sie die Verwendung von Schlüsselpräfixen erwägen, die der Mandanten-ID vorangestellt werden. Ihre Anwendung kann dann auf spezifische Daten für einen bestimmten Mandanten zugreifen. Alternativ können Sie Redis-Datenstrukturen wie Sets oder Hashes für die Daten jedes Mandanten verwenden. Sowohl Sets als auch Hashes unterstützen eine große Anzahl von Schlüsseln, sodass dieser Ansatz auf viele Mandanten skaliert werden kann.

Wenn Sie eine einzelne Cache-Instanz verwenden, muss die Anwendung für den Zugriff auf den gesamten Cache autorisiert werden. Azure Cache for Redis bietet keine präzise Zugriffssteuerung innerhalb eines Caches.

Wenn Sie diesen Ansatz verwenden, sollten Sie berücksichtigen, dass all Ihre Mandanten die gleichen zugrunde liegenden Computeressourcen für den Cache gemeinsam nutzen. Dieser Ansatz kann daher anfällig für das Noisy Neighbor-Problem sein. Stellen Sie sicher, dass Sie die bewährten Methoden für Azure Cache for Redis für die Skalierung, Arbeitsspeicherverwaltung und Serverlast befolgen, um die Ressourcen Ihres Caches effizient zu nutzen und die negativen Auswirkungen von Noisy Neighbor-Effekten zu reduzieren.

Erwägen Sie zudem, die Ressourcen Ihres Caches zu überwachen, z. B. CPU und Arbeitsspeicher. Wenn Sie eine Ressourcenüberlastung beobachten, sollten Sie zur Entschärfung des Problems die folgenden Gegenmaßnahmen in Betracht ziehen:

• Skalieren Sie auf eine Cache-SKU oder -Ebene mit einer höheren Ressourcenmenge hoch.
• Skalieren Sie auf mehrere Caches auf, indem Sie Ihre zwischengespeicherten Daten horizontal partitionieren. Sie können die horizontale Partitionierung nach Mandanten oder nach Subsystem vornehmen. Bei der Partitionierung nach Mandanten verwenden einige Mandanten Cache A und einige Cache B. Bei der Partitionierung nach Subsystem speichert ein Teil Ihrer Lösung Daten für alle Mandanten in Cache A zwischen, und ein anderer Teil der Lösung verwendet Cache B zum Zwischenspeichern.

Freigegebene Cache-Instanz mit einer Datenbank pro Mandanten

Ein weiterer Ansatz, den Sie in Erwägung ziehen können, besteht darin, eine einzelne Cache-Instanz und mandantenspezifische Redis-Datenbanken innerhalb der Instanz bereitzustellen. Dieser Ansatz bietet einen gewissen Grad an logischer Isolation für die Daten jedes Mandanten, jedoch keine Leistungsisolation oder Schutz vor Noisy Neighbor-Effekten.

Dieser Ansatz kann für Migrationsszenarien nützlich sein. Angenommen, Sie modernisieren eine Anwendung mit einem einzigen Mandanten, die nicht für die Verwendung mit mehreren Mandanten konzipiert ist, und konvertieren sie schrittweise in eine mehrinstanzenfähige Anwendung, indem Sie den Mandantenkontext in alle Anforderungen einschließen. Durch die Verwendung eines einzelnen freigegebenen Caches können Sie die Kosteneffizienz verbessern, und Sie müssen die Logik der Anwendung nicht zur Verwendung von Mandantenschlüsselpräfixen oder mandantenspezifischen Datenstrukturen aktualisieren.

Bei Azure Cache for Redis gelten Grenzwerte für die Anzahl von Datenbanken, die in einem einzigen Cache erstellt werden können. Bevor Sie diesen Ansatz implementieren, müssen Sie daher wissen, auf wie viele Mandanten Ihre Anwendung erweitert werden soll.

Darüber hinaus bietet dieser Ansatz keinerlei Vorteile hinsichtlich der Sicherheitsisolation von Daten. In Azure Cache for Redis werden Authentifizierung und Autorisierung auf der Ebene der Cache-Instanz ausgeführt.

Hinweis

Azure Cache for Redis unterstützt mehrere Datenbanken auf bestimmten Ebenen, bietet aber keine Unterstützung für mehrere Datenbanken, wenn Sie gruppierte Instanzen verwenden.

Cache-Instanz pro Mandanten

Sie können ggf. eine separate Instanz von Azure Cache for Redis für jeden Mandanten bereitstellen. Die Anzahl von Caches, die innerhalb eines einzelnen Azure-Abonnements bereitgestellt werden können, ist nicht begrenzt. Dieser Ansatz bietet die höchste Isolationsstufe für Daten und Leistung.

Jeder Cache wird jedoch als separate Azure-Ressource abgerechnet, sodass bei einer großen Anzahl von Mandanten mehr Kosten anfallen. Darüber hinaus werden bei diesem Ansatz die Ressourcen der einzelnen Caches oft nicht effizient genutzt, da jede Azure Cache for Redis-Instanz im Allgemeinen eine große Anzahl von Anforderungen unterstützt. Erwägen Sie diesen Isolationsansatz daher nur, wenn Sie strenge Anforderungen bezüglich der Daten- oder Leistungsisolation haben.

Features von Azure Cache for Redis, die Mehrinstanzenfähigkeit unterstützen

Aktive Georeplikation

Viele mehrinstanzenfähige Lösungen müssen geografisch verteilt werden. Sie können eine global verteilte Logikschicht freigeben und für Lese- und Schreibvorgänge Ihrer Anwendungsinstanzen einen in der Nähe befindlichen Cache verwenden, um eine akzeptable Leistung zu erzielen. Die Enterprise-Dienstebene von Azure Cache for Redis unterstützt das regionsübergreifende Verknüpfen mehrerer Caches in einer Aktiv/Aktiv-Konfiguration.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

• John Downs | Principal Customer Engineer, FastTrack for Azure
• Will Velida | Customer Engineer 2, FastTrack for Azure

Andere Mitwirkende:

• Carl Dacosta | Principal Software Engineering Manager, Azure Cache für Redis
• Kyle Teegarden | Senior Program Manager, Azure Cache für Redis
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Überprüfen Sie die Speicher- und Datenansätze für mehrere Mandanten.