Heiße Partitionen in Azure Blob Storage: Erkennung, Überwachung und Abmilderung

Azure Blob Storage verteilt Daten über Partitionen hinweg, um skalierbare Leistung zu liefern. Wenn der Datenverkehr sich auf eine einzelne Partition konzentriert, kann diese Partition zu einem Flaschenhals werden, ein Zustand, der als heiße Partition bekannt ist. Dieser Artikel erklärt, was heiße Partitionen sind, wie man sie anhand von Azure Monitor-Metriken und Ressourcenprotokollen erkennt und welche Schritte Sie unternehmen können, um die Last gleichmäßiger zu verteilen und Throttling-Fehler zu reduzieren.

Hot Partitions verstehen

Azure Blob Storage verteilt Daten automatisch über Partitionen hinweg, um Leistung und Durchsatz zu skalieren. Wenn eine einzelne Partition deutlich mehr Datenverkehr erhält als andere Partitionen, wird sie zu einer heißen Partition. Eine heiße Partition entsteht, wenn eine große Anzahl von Lese-, Schreib- oder Aktualisierungsanfragen auf dieselbe Partition geht, was die Fähigkeit des Dienstes, die Arbeitslast effektiv auszubalancieren, einschränkt. Infolgedessen erfahren Anfragen erhöhte Latenz, Drosselung und Timeout-Fehler, bis die Arbeitslast neu verteilt oder das Zugriffsmuster optimiert ist. Partitionierungs- oder Benennungsschemata, die den Datenverkehr auf einen kleinen Datensatz konzentrieren, anstatt Anfragen über mehrere Partitionen zu verteilen, führen oft zu heißen Partitionen.

Symptome und Auswirkungen von heißen Trennwänden

Wenn eine Speicherpartition heiß wird, kann sie Anfragen nicht mehr so effizient verarbeiten. Wenn die Partition ihre Skalierbarkeitsgrenzen erreicht, beginnt Azure Storage, Anfragen zu drosseln, um den Dienst zu schützen und die Zuverlässigkeit für andere Arbeitslasten zu gewährleisten. Client-Anwendungen erleben erhöhte Latenz, geringeren Durchsatz und vorübergehende Anfragefehler.

Häufige Symptome einer heißen Trennwand sind:

  • HTTP 503 (Server Busy)- Antworten, die anzeigen, dass die Partition vorübergehend keine weiteren Anfragen mehr verarbeiten kann.
  • HTTP 500 (Operation Timeout) antwortet, wenn Anfragen zu lange dauern, weil die Partition stark belastet ist.
  • Erhöhte Anfragelatenz, selbst bei Anfragen, die letztlich erfolgreich sind.
  • Automatische Client-Neuversuche, die den Datenverkehr weiter erhöhen und Leistungsprobleme verlängern können, wenn viele Clients gleichzeitig einen Neuversuch starten.
  • Reduzierter Durchsatz, bei dem die Anwendung trotz ausreichender Gesamtkapazität des Speicherkontos weniger Operationen pro Sekunde verarbeitet als erwartet.

Hot Partitions werden oft durch Zugriffsmuster verursacht, die den Datenverkehr auf eine einzelne Partition konzentrieren. Gängige Beispiele sind sequentielle Blob-Namen, Append-only-Workloads und Partitionsschlüsseldesigns, die eine unverhältnismäßig hohe Menge an Datenverkehr an eine einzelne Partition senden. Wenn die Arbeitslast nicht gleichmäßig verteilt ist, erreicht die betroffene Partition ihre Grenzen vor dem Rest des Speicherkontos, was einen Engpass schafft, der die Anwendungsleistung beeinträchtigt.

Für viele Anwendungen ist das erste Anzeichen einer heißen Partition eine Kombination aus steigender Latenz, steigenden Wiederholungsraten und steigenden Fehlerzahlen von 503 oder 500 in Zeiten hoher Nachfrage.

Erkennung von Throttling-Fehlern durch die Verwendung von Azure Monitor-Metriken und Ressourcenprotokollen

Azure Storage drosselt Anfragen, wenn eine Arbeitslast die Skalierbarkeitsziele eines Speicherkontos oder einer Partition überschreitet. Throttling zeigt sich häufig in Form von HTTP-503 (Server Busy)- oder 500 (Operation Timeout)-Antworten. Azure Storage-Clientbibliotheken versuchen oft automatisch gedrosselte Anfragen wieder, daher ist Überwachung unerlässlich, um Drosselung zu erkennen, bevor sie die Anwendungsleistung wesentlich beeinträchtigt.

Verwenden Sie Azure Monitor-Metrics, um Throttling-Fehler zu identifizieren

Um Throttling zu erkennen, analysieren Sie die Azure Monitor-Metriken für ein Speicherkonto. Die Transaktionsmetrik , kombiniert mit der ResponseType-Dimension , bietet Transparenz über das Ergebnis von Speicheranfragen und hilft Ihnen, drosselbedingte Fehler zu erkennen.

Metriken zur Erkennung von Drosselung

Die folgenden Azure Monitor-Metriken sind für die Untersuchung der Drosselung hilfreich:

Metric Purpose
Transaktionen Misst die Anzahl der vom Speicherdienst verarbeiteten Anfragen. Verwenden Sie die Dimension ResponseType, um gedrosselte Anfragen zu identifizieren.
Verfügbarkeit Zeigt den Prozentsatz der erfolgreichen Anfragen. Ein Rückgang der Verfügbarkeit kann auf Drosselung oder andere Anfragefehler hinweisen.
E2E-Wartezeit bei Erfolg Misst die End-to-End-Latenz von Anfragen, einschließlich der Netzwerkkommunikation und der Verarbeitung auf Clientseite. Erhöhungen könnten auf Wiederholungen hindeuten, die durch Drosselung verursacht wurden.
Erfolgsserver-Latenz Misst die Zeit, die der Speicherdienst benötigt, um Anfragen zu verarbeiten. Der Vergleich dieser Metrik mit der E2E-Latenz kann helfen, Service-seitige Verzögerungen von Client-Rettries zu unterscheiden.

Ein typisches Drosselungsmuster ist eine erhöhte Latenz, begleitet von einer Zunahme drosselungsbezogener Antworttypen und einer Abnahme der Verfügbarkeit.

Verwenden Sie die ResponseType-Dimension, um Drosselung zu identifizieren

Die ResponseType-Dimension ist das primäre Werkzeug zur Identifizierung von Drosselungsbedingungen in Azure Monitor-Metriken. Relevante Werte umfassen:

ResponseType-Wert Description
ServerBusyError Der Speicherdienst gab HTTP 503 zurück, weil ein Skalierbarkeitsziel überschritten wurde.
ClientThrottlingError Die Anfrage wurde gedrosselt, bevor sie den Speicherdienst erreichte.
ClientAccountRequestThrottlingError Die Grenzwerte für die Anfragerate auf Kontoebene wurden überschritten.
ClientAccountBandwidthThrottlingError Die Bandbreitenbeschränkungen des Kontos wurden überschritten.
ErfolgMitDrosselung Der Antrag wurde zunächst abgelehnt, aber nach Rückversuchen schließlich erfolgreich.

Das Verfolgen dieser Werte über die Zeit kann helfen, vorübergehende Throttling-Spitzen sowie anhaltende Skalierbarkeitsprobleme zu erkennen.

Verwenden Sie Maße, um die Quelle der Drosselung genau zu bestimmen

Azure Monitor-Metrikdimensionen können dabei helfen, den Workload zu isolieren, der die Drosselung verursacht:

Dimension Purpose
ResponseType Identifiziert den spezifischen Drosselungs- oder Fehlerzustand.
ApiName Identifiziert den Vorgang, der von Drosselung betroffen ist, z. B. PutBlob, GetBlob oder ListBlobs.
GeoType Unterscheidet den Datenverkehr zwischen primären und sekundären Endpunkten in georedundanten Speicherkonten.
Authentifizierung Hilft festzustellen, ob Throttling mit einer bestimmten Authentifizierungsmethode verbunden ist.

Wenn beispielsweise Drosselung hauptsächlich bei PutBlob Operationen auftritt, könnte die Arbeitslast schreibintensiv sein. Wenn eine bestimmte API-Operation erhöhte Drosselungsraten zeigt, können sich die Optimierungsmaßnahmen auf diese Operation und nicht auf die gesamte Anwendung konzentrieren.

Analysieren von Azure Monitor-Ressourcenprotokollen

Während Metriken auf das Vorhandensein von Throttling hinweisen, liefern Azure Monitor-Ressourcenprotokolle Details auf Anforderungsebene, die bei der Diagnose der zugrunde liegenden Ursache helfen können. Ressourcenprotokolle erfassen sowohl erfolgreiche als auch fehlgeschlagene Anfragen, einschließlich Drosselung, Timeout, Autorisierung und netzwerkbezogenen Fehlern.

Für Azure Blob Storage sind Datensätze in der StorageBlobLogs-Tabelle verfügbar, nachdem die Ressourcenprotokolle an einen Log Analytics-Arbeitsbereich gesendet wurden.

Ressourcenprotokolle nach Throttling-Ereignissen abfragen

Bevor Sie diese Abfragen ausführen, stellen Sie sicher, dass Ressourcenprotokolle an einen Log Analytics-Arbeitsbereich gesendet werden.

Verwenden Sie die Kusto Query Language (KQL), um Anfragen zu identifizieren, die folgende häufige drosselungsbezogene Statuscodes zurückgeben:

StorageBlobLogs
| where StatusCode in (500, 503)
| summarize RequestCount = count() by OperationName, StatusCode, bin(TimeGenerated, 15m)
| order by TimeGenerated desc

Erweitern Sie diese Abfrage, indem Sie die Ergebnisse nach Operation, Authentifizierungstyp, Anrufer-IP-Adresse oder Anwendungsidentität gruppieren, um die Arbeitslast zu identifizieren, die gedrosselte Anfragen erzeugt. Ressourcenprotokolle sind besonders nützlich, um festzustellen, ob die Drosselung auf eine bestimmte Anwendung, einen bestimmten Betrieb oder einen bestimmten Zeitraum konzentriert ist.

Warnkriterien bei Drosselung

Erstellen Sie Azure Monitor-Warnungen für:

  • Anhaltende Vorkommen von ServerBusyError-Transaktionen .
  • Anstieg der ResponseType-Werte im Zusammenhang mit Drosselung.
  • Die Verfügbarkeitsmetrik fällt unter einen akzeptablen Schwellenwert.
  • Anstiege der Latenz, die mit Drosselungsereignissen korrelieren.
  • Plötzliche Zunahmen des Anforderungsvolumens, die sich den Skalierbarkeitsgrenzen des Speichers nähern.
  1. Überwachen Sie die Transaktionsmetrik und teilen Sie die Ergebnisse nach ResponseType auf.
  2. Achten Sie auf Zunahmen bei Throttling-bezogenen Antworttypen wie ServerBusyError und ClientThrottlingError.
  3. Verwenden Sie die ApiName-Dimension , um betroffene Operationen zu identifizieren.
  4. Korrigiere Throttling-Ereignisse mit Änderungen in Verfügbarkeit, Success E2E-Latenz und Success Server-Latenz.
  5. Verwenden Sie Azure Monitor-Ressourcenprotokolle, um zu bestimmen, welche Anfragen, Operationen oder Anwendungen gedrosselten Datenverkehr erzeugen.
  6. Konfigurieren Sie Warnungen so, dass Throttling-Probleme erkannt werden, bevor sie Nutzer betreffen.

Durch die Kombination von Azure Monitor-Metriken, Dimensionen und Ressourcenprotokollen können Sie schnell Drosselungsbedingungen erkennen, die Quelle der übermäßigen Nachfrage identifizieren und Korrekturmaßnahmen ergreifen, bevor sich die Anwendungsleistung verschlechtert.

Heiße Partitionen abmildern

Um heiße Partitionen zu verhindern, sollten Anfragen gleichmäßig über die Partitionen verteilt werden und sichergestellt werden, dass Anwendungen angemessen reagieren, wenn Throttling auftritt.

Verwenden Sie effiziente Partitionierungs- und Benennungsschemata

Entwerfen Sie Partitionsschlüssel, Blob-Namen und andere Identifikatoren, sodass Anfragen über mehrere Partitionen verteilt werden. Vermeiden Sie sequentielle oder nur anhängende Namensmuster, die die meisten Anfragen an dieselbe Partition senden. Siehe Blob-Partitionen und Benennungsschemata optimieren.

Verwenden Sie exponentiellen Backoff bei Wiederholungsversuchen

Wenn Anfragen gedrosselt werden und 503 (Server beschäftigt) oder 500 (Operation Timeout) Fehler zurückgeben, versuchen Sie Anfragen erneut mit einer exponentiellen Backoff-Strategie. Dieser Ansatz reduziert den Druck auf die betroffene Partition und gibt Azure Storage Zeit, die Last neu auszugleichen oder sich von temporären Nachfragespitzen zu erholen.

Das exponentielle Backoff-Retry-Verhalten ist besonders relevant für benutzerdefinierte Anwendungen, die auf Azure Storage zugreifen, indem sie Azure Storage-Clientbibliotheken, SDKs oder REST-APIs verwenden. Viele Microsoft Services, verwaltete Anwendungen und Drittanbieter-Clients implementieren bereits geeignete Wiederholungslogik, sodass Sie möglicherweise nichts Zusätzliches konfigurieren müssen. Wenn Sie eine individuelle Anwendung entwickeln, stellen Sie sicher, dass Retry-Richtlinien aktiviert und gemäß den Best Practices von Azure Storage konfiguriert sind. Lesen Sie auch die folgenden Artikel:

Vermeiden Sie plötzliche Spitzen im Anfragevolumen

Wenn man eine neue Arbeitslast einführt, Leistungstests durchführt oder große Datenmengen verarbeitet, erhöht man die Anfrageraten allmählich, anstatt sofort Spitzenverkehr zu erzeugen. Azure Storage gleicht Partitionen automatisch lastmäßig aus, wenn sich die Auslastung ändert. Abrupte Lastspitzen können eine Partition jedoch vorübergehend überlasten und zu einer Drosselung führen, bis der Dienst Gelegenheit hat, die Lastverteilung anzupassen.

Nächste Schritte

Für detaillierte Implementierungshinweise siehe:

  • Last updated on