Mandantenfähigkeit und Azure Queue Storage

Azure Queue Storage speichert Nachrichten für die asynchrone Verarbeitung. In diesem Artikel werden Partitionierungsstrategien, Isolationsmodelle und Warteschlangenspeicherfeatures für Multitenant-Lösungen beschrieben. Es enthält Anleitungen, mit denen Sie die Nachrichtenlast verteilen, die Nachrichten der Mandanten isolieren und Zugriff, Verschlüsselung und Nutzung verwalten können.

Partitionierungsstrategien

Queue Storage macht innerhalb einer Warteschlange keinen Partitionsschlüssel und keine Unterwarteschlange verfügbar. Die Warteschlange ist die kleinste Grenze, die Sie zum Verteilen der Nachrichtenlast verwenden können, und das Speicherkonto ist die nächsthöhere Grenze. Eine freigegebene Warteschlange bietet keinen mandantenspezifischen Durchsatz oder keine Leistungsisolation.

Bei Nachrichten mit 1 KiB verfügt eine einzelne Warteschlange über einen Zieldurchsatz von bis zu 2.000 Nachrichten pro Sekunde, und ein Speicherkonto hat eine maximale Anforderungsrate von 20.000 Nachrichten pro Sekunde. Nachrichtengröße und Zugriffsmuster wirken sich auf den von Ihrer Workload erreichten Durchsatz aus. Warteschlangennachrichten können bis zu 64 KiB sein. Bei größeren Nachrichten oder erweiterten Brokerfeatures sollten Sie Azure Service Bus verwenden.

Wenn Ihre Workload das Ziel pro Warteschlange überschreiten kann, verteilen Sie Nachrichten über mehrere Warteschlangen hinweg. Abhängig von Ihren Routing- und Betriebsanforderungen können Sie Warteschlangen nach Mandant, Mandantengruppe oder Dienstebene, funktionaler Workload, Bereitstellungsstempel oder Region partitionieren. Ein Mandant mit hohem Volumen, der sich mit anderen Mandanten eine Warteschlange teilt, kann einen unverhältnismäßigen Anteil des Durchsatzes der Warteschlange beanspruchen und eine Drosselung für andere Mandanten verursachen.

Mehrere Warteschlangen im selben Speicherkonto teilen weiterhin die Kapazitäts- und Kontokonfiguration des Kontos. Wenn die aggregierte Workload das Ziel des Speicherkontos überschreitet oder ein Mandant eine unabhängige Skalierung oder regionale Konfiguration benötigt, verteilen Sie Warteschlangen über mehrere Speicherkonten. Überwachen Sie das System auf Drosselung, verwenden Sie Wiederholungsversuche mit exponentiellem Backoff, und testen Sie Ihre Workload anhand der dokumentierten Skalierbarkeitsziele für Queue Storage. Informationen zu Mandantenzugriffs- und Datenisolationsoptionen finden Sie unter Isolationsmodelle.

Isolationsmodelle

Nachdem Sie bestimmt haben, wie die Nachrichtenlast verteilt werden soll, bestimmen Sie die Ebene der anzuwendenden Mandantenisolation. Der Warteschlangenspeicher unterstützt freigegebene Warteschlangen, Warteschlangen für jeden Mandanten und Speicherkonten für jeden Mandanten. In der folgenden Tabelle sind die Unterschiede zwischen den Wichtigsten Mandantenisolationsmodellen für Warteschlangenspeicher zusammengefasst.

Consideration Freigegebene Warteschlangen Warteschlangen für jeden Mandanten Speicherkonten für jeden Mandanten
Datenisolation Niedrig Die Anwendung erzwingt die Isolation. Low-medium Hoch
Leistungsisolation Low Niedrig Die meisten Kontingente und Grenzwerte gelten für das gesamte Speicherkonto. Hoch
Bereitstellungskomplexität Low Medium Hoch
Komplexität des Betriebs Low Medium Hoch
Beispielszenario Eine große Mehrinstanzenlösung verfügt über eine freigegebene Anwendungsebene. Es werden mandantenbezogene SAS-URLs (Shared Access Signature) ausgestellt. Jeder Mandant verfügt über einen eigenen Bereitstellungsstempel.

Hinweis

Berücksichtigen Sie Kontingente und Grenzwerte, wenn Sie ein Isolationsmodell auswählen. Zu diesen Grenzwerten gehören Azure Dienstgrenzwerte, Skalierbarkeitsziele für Warteschlangenspeicher und Skalierbarkeitsziele für den Speicherressourcenanbieter.

Freigegebene Warteschlangen

Wenn Sie eine Warteschlange gemeinsam nutzen, teilen sich alle Mandanten deren Durchsatzziel. Ein stark ausgelasteter Mandant kann zu einer Drosselung für andere Mandanten führen. Strategien zum Verteilen der Nachrichtenlast finden Sie unter Partitionierungsstrategien.

Warteschlangen unterstützen keine Partitionierung oder Unterwarteschlangen, daher können die Daten der Mandanten vermischt werden. Ihre Anwendung muss den Mandanten für jede Nachricht identifizieren und während der Verarbeitung die Isolation erzwingen. Gewähren Sie Mandanten keinen direkten Zugriff auf eine freigegebene Warteschlange, wenn sie nicht auf nachrichten anderer Mandanten zugreifen dürfen.

Warteschlangen für jeden Mandanten

Sie können einzelne Warteschlangen für jeden Mandanten innerhalb eines einzelnen Speicherkontos erstellen. Es gibt keine Beschränkung für die Anzahl der Warteschlangen, die Sie innerhalb eines Speicherkontos erstellen können.

Warteschlangen für jeden Mandanten bieten eine Routing- und Zugriffssteuerungsgrenze, bieten jedoch keine Leistungsisolation. Alle Warteschlangen im Konto teilen sich die Kapazitäts- und Leistungsziele des Speicherkontos.

In diesem Szenario können Sie die Zugriffssteuerung für Queue Storage, einschließlich SAS, verwenden, um den Zugriff auf die Daten jedes Mandanten zu verwalten.

Wenn Sie Warteschlangen für jeden Mandanten dynamisch erstellen, überlegen Sie, wie die Anwendungsebene die Nachrichten aus der Warteschlange jedes Mandanten verarbeitet. Ziehen Sie für erweiterte Szenarien die Verwendung von Azure Service Bus in Betracht, da dieser Dienst Features wie Sitzungen, die automatische Weiterleitung von Nachrichten sowie Themen und Abonnements unterstützt.

Speicherkonten für jeden Mandanten

Die stärkste Isolationsebene verwendet ein dediziertes Speicherkonto für jeden Mandanten. Dieses Modell stellt eine vollständige Isolation von Speicherkontoschlüsseln sicher, die Unabhängig voneinander gedreht werden können. Außerdem können Sie Ihre Lösung über die Grenzwerte und Kontingente für jedes Speicherkonto skalieren. Erwägen Sie dieses Modell für Tenants, die dauerhafte hohe Nachrichtenvolumes aufweisen oder unabhängige regionale Konfigurations- oder Leistungsziele erfordern. Sie müssen jedoch auch die maximale Anzahl von Speicherkonten berücksichtigen, die innerhalb eines einzelnen Azure-Abonnements zulässig sind.

Features von Queue Storage zur Unterstützung der Mandantenfähigkeit

Die folgenden Queue Storage-Features können Ihnen helfen, Ihr ausgewähltes Isolationsmodell zu implementieren und zu betreiben.

Geteilte Zugriffssignaturen

Wenn Sie Queue Storage von einer Clientanwendung verwenden, überlegen Sie, ob Anforderungen über Ihre Anwendungsebene weitergeleitet werden sollen oder ob Clients eine direkte Verbindung mit einer Warteschlange herstellen können. Der direkte Clientzugriff kann die Last Ihrer Back-End-Anwendungen und die Anzahl der Netzwerksprünge verringern.

Mit einer shared access signature (SAS) können Sie Clientanwendungen eingeschränkten Zugriff auf eine Warteschlange gewähren. Sie können die Vorgänge einschränken, die ein Client ausführen kann, und den Zeitraum, in dem der Zugriff zulässig ist. Sie können z. B. eine SAS ausstellen, mit der ein Mandant Nachrichten zu seiner eigenen Warteschlange hinzufügen kann, ohne dass er Nachrichten lesen oder löschen darf.

Verwenden Sie das Valet Key-Muster , um eingeschränkte und bereichsbezogene SAS-Token von Ihrer Anwendungsebene aus auszugeben. Authentifizieren Sie den Client über das Authentifizierungssystem Ihrer Anwendung, ermitteln Sie, auf welche Mandantenwarteschlange der Client zugreifen darf, und stellen Sie ein Token nur für die erforderlichen Vorgänge aus.

Mithilfe von gespeicherten Zugriffsrichtlinien können Sie eine einzelne Richtlinie definieren, die verwendet werden soll, wenn Sie mehrere Dienst-SAS-Token ausstellen. Gespeicherte Zugriffsrichtlinien gelten nicht für SAS-Token für Benutzerdelegierung oder SAS-Kontotoken.

SAS für die Benutzerdelegierung

Ein Sas- oder Konto-SAS des Diensts ist mit einem Ihrer Speicherkontoschlüssel signiert. Stattdessen wird eine Benutzerdelegierungs-SAS mit Microsoft Entra Anmeldeinformationen gesichert. Ihre Anwendungsebene fordert einen Benutzerdelegierungsschlüssel mithilfe einer eigenen verwalteten Identität an und signiert dann bereichsbezogene, zeitlich begrenzte Token für jeden Mandanten. Sie verteilen oder speichern keine Kontoschlüssel. Microsoft empfiehlt die Verwendung einer Benutzerdelegierungs-SAS anstelle einer SAS mit Kontoschlüssel, wenn Ihr Design sie unterstützt.

Verwenden Sie kurze Tokenlebensdauern, und planen Sie, wie Sie den Zugriff widerrufen, wenn ein Token kompromittiert wird. Um Ihre Anwendungsprotokolle mit Warteschlangenspeicherprotokollen zu korrelieren, legen Sie eine Clientanforderungs-ID (x-ms-client-request-id) für Speicheranforderungen fest und protokollieren sie zusammen mit der Mandanten-ID.

Identitätsbasierte Zugriffssteuerung

Der Warteschlangenspeicher bietet eine identitätsbasierte Zugriffssteuerung über Microsoft Entra ID. Verwenden Sie verwaltete Identitäten und Azure rollenbasierte Zugriffssteuerung, um Ihre Anwendung für den Zugriff auf Warteschlangen zu autorisieren, ohne Kontoschlüssel zu speichern. Beschränken Sie den Zugriff auf die Warteschlange des jeweiligen Mandanten, wenn Mandanten direkten Zugriff benötigen. Die Autorisierung auf Warteschlangenebene isoliert die Nachrichten einzelner Mandanten nicht innerhalb einer freigegebenen Warteschlange.

Encryption

Der Warteschlangenspeicher verschlüsselt ruhende Daten standardmäßig mit Microsoft verwalteten Schlüsseln. Um kundenseitig verwaltete Schlüssel zu verwenden, konfigurieren Sie das Speicherkonto für die Verwendung eines kontobezogenen Verschlüsselungsschlüssels für Warteschlangen, wenn Sie das Konto erstellen. Sie können diesen Verschlüsselungsschlüsselbereich nach der Kontoerstellung nicht mehr ändern.

Wenn Mandanten separate vom Kunden verwaltete Schlüssel benötigen, verwenden Sie separate Speicherkonten. Blob Storage-Verschlüsselungsbereiche und vom Kunden bereitgestellte Schlüssel für einzelne Anfragen gelten nicht für Queue Storage. Planen Sie die Schlüsselrotation und den Schlüsselwiderruf im Einklang mit Ihrem Mandantenlebenszyklus.

Monitoring

Überlegen Sie in einer mehrinstanzenfähigen Lösung, ob Sie den Verbrauch für jeden Mandanten messen müssen. Definieren Sie die spezifischen Metriken, die nachverfolgt werden sollen, z. B. die Anzahl der Nachrichten oder Vorgänge für jeden Mandanten. Sie können die Kostenzuordnung auch verwenden, um die Kosten der Nutzung jedes Mandanten nachzuverfolgen und Rückbuchungen für mehrere Abonnements zu aktivieren.

Warteschlangenspeicher bietet integrierte Überwachungsfunktionen. Wenn Mandanten eine Warteschlange freigeben, schließen Sie Mandanten-IDs in Ihre Anwendungstelemetrie ein, sodass Sie nachrichtenverarbeitung und -verwendung dem richtigen Mandanten zuordnen können.

Überwachen Sie die Anforderungsraten sowie die Antworten HTTP 500 und 503, um Warteschlangen oder Konten zu erkennen, die sich den Skalierbarkeitszielen nähern. Korrelieren Sie diese Telemetrie mit Mandanten-IDs, damit Sie Mandanten identifizieren können, deren Nutzung sich auf die gemeinsame Kapazität auswirkt.

Sie können Anfrageprotokolle sammeln und dann zusammen mit Ihrer Anwendungstelemetrie aggregieren und analysieren. Berücksichtigen Sie bei Lösungen, die ein hohes Volumen an Anfragen erzeugen, ob der Vorteil die Kosten für die Erfassung und Verarbeitung dieser Protokolle rechtfertigt.

Contributors

Dieser Artikel wird von Microsoft gepflegt. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

  • John Downs | Principal Software Engineer, Azure Patterns & Practices

Andere Mitwirkende:

Um nicht öffentliche LinkedIn-Profile zu sehen, melden Sie sich bei LinkedIn an.

  • Zuletzt aktualisiert um