Partitions chaudes dans Stockage Blob Azure : détection, surveillance et atténuation

Stockage Blob Azure distribue les données entre les partitions pour offrir des performances évolutives. Lorsque le trafic se concentre sur une seule partition, cette partition peut devenir un goulot d’étranglement, une condition appelée partition chaude. Cet article explique ce que sont les partitions hot, comment les reconnaître via les métriques et les journaux de ressources Azure Monitor, ainsi que les mesures à suivre pour répartir la charge de manière plus égale et réduire les erreurs de limitation.

Comprendre les partitions actives

Stockage Blob Azure distribue automatiquement les données entre les partitions pour augmenter la performance et le débit. Lorsqu’une partition reçoit beaucoup plus de trafic que d’autres partitions, elle devient une partition chaude. Une partition chaude se produit lorsqu’un grand nombre de requêtes de lecture, d’écriture ou de mise à jour sont envoyées à la même partition, limitant ainsi la capacité du service à équilibrer efficacement la charge de travail. En conséquence, les requêtes subissent une latence accrue, des erreurs de limitation et de délai jusqu’à ce que la charge de travail soit redistribuée ou que le schéma d’accès soit optimisé. Les schémas de partitionnement ou de nommage qui concentrent le trafic sur un petit sous-ensemble de données au lieu de répartir les requêtes sur plusieurs partitions provoquent souvent des partitions chaudes.

Symptômes et impact des cloisons chaudes

Lorsqu’une partition de stockage devient chaude, elle ne peut plus traiter les requêtes aussi efficacement. À mesure que la partition approche de ses limites de scalabilité, stockage Azure commence à limiter les requêtes pour protéger le service et maintenir la fiabilité des autres charges de travail. Les applications clientes connaissent une latence accrue, un débit réduit et des échecs de requêtes transitoires.

Les symptômes courants d’une cloison chaude incluent :

• les réponses HTTP 503 (Serveur occupé) qui indiquent que la partition est temporairement incapable de traiter davantage de requêtes.
• HTTP 500 (Operation Timeout) répond lorsque les requêtes mettent trop de temps à être complétées car la partition est sous forte charge.
• Latence accrue des requêtes, même pour les requêtes qui finissent par réussir.
• Les nouvelles tentatives automatiques des clients, qui peuvent encore augmenter le trafic et prolonger les problèmes de performance si de nombreux clients effectuent simultanément une nouvelle tentative.
• Débit réduit, où l’application traite moins d’opérations par seconde que prévu malgré une capacité globale suffisante du compte de stockage.

Les partitions chaudes sont souvent causées par des schémas d’accès qui concentrent le trafic sur une seule partition. Parmi les exemples courants figurent les noms de blobs séquentiels, les charges de travail en ajout seul et les schémas de clés de partition qui dirigent une quantité disproportionnée de trafic vers une seule partition. Lorsque la charge de travail n’est pas répartie uniformément, la partition concernée atteint ses limites avant le reste du compte de stockage, créant un goulot d’étranglement qui impacte la performance de l’application.

Pour de nombreuses applications, la première indication d’une partition chaude est une combinaison d’une latence croissante, d’une augmentation des taux de réessayage et d’un nombre croissant d’erreurs de 503 ou 500 lors de périodes de forte demande.

Détectez les erreurs de limitation à l’aide des métriques et des journaux de ressources d’Azure Monitor

stockage Azure limite les requêtes lorsqu’une charge de travail dépasse les objectifs de scalabilité d’un compte ou d’une partition de stockage. On observe couramment la limitation du débit par des réponses HTTP 503 (serveur occupé) ou 500 (délai d’expiration de l’opération). Les bibliothèques clientes d’stockage Azure réessaient souvent automatiquement les requêtes soumises à une limitation de débit. Il est donc essentiel de surveiller ce phénomène afin de détecter cette limitation avant qu’elle n’affecte significativement les performances des applications.

Utilisez les métriques Azure Monitor pour identifier les erreurs de limitation de la vitesse

Pour détecter le throttling, analysez les métriques Azure Monitor pour un compte de stockage. L’indicateur Transactions , combinée à la dimension ResponseType , offre une visibilité sur le résultat des requêtes de stockage et vous aide à identifier les défaillances liées au throttling.

Indicateurs permettant d’identifier le bridage

Les métriques Azure Monitor suivantes sont utiles pour étudier le throttling :

Une manifestation fréquente de la limitation du débit est une augmentation de la latence, accompagnée d’une augmentation des types de réponses associés à la limitation du débit et d’une diminution de la disponibilité.

Utilisez la dimension ResponseType pour identifier la limitation de la vitesse

La dimension ResponseType est l’outil principal pour identifier les conditions de limitation dans les métriques Azure Monitor. Les valeurs pertinentes incluent :

Suivre ces valeurs dans le temps peut vous aider à identifier les pics de throttling transitoires ainsi que les problèmes de scalabilité durables.

Utilisez les dimensions pour localiser précisément la source de la limitation

Les dimensions métriques d’Azure Monitor peuvent aider à isoler la charge de travail responsable du throttling :

Par exemple, si la limitation du débit se produit principalement sur les opérations PutBlob, la charge de travail peut être intensive en écriture. Si une opération API spécifique présente des taux de limitation élevés, les efforts d’optimisation peuvent se concentrer sur cette opération plutôt que sur l’ensemble de l’application.

Analyser les journaux de ressources Azure Monitor

Si les métriques permettent de détecter la présence d’une limitation du débit, les journaux de ressources Azure Monitor fournissent des détails sur chaque requête qui peuvent aider à diagnostiquer la cause racine. Les journaux de ressources enregistrent à la fois les requêtes réussies et les échecs, y compris la limitation des données, le timeout, l’autorisation et les erreurs liées au réseau.

Pour Stockage Blob Azure, les enregistrements sont disponibles dans la table StorageBlobLogs après l’envoi des journaux de ressources à un espace de travail Log Analytics.

Interroger les journaux des ressources pour les événements de limitation du débit

Avant d’effectuer ces requêtes, assurez-vous que les journaux de ressources sont envoyés à un espace de travail Log Analytics.

Utilisez le langage de requête Kusto (KQL) pour identifier les requêtes qui renvoient des codes d’état courants liés à la limitation du débit :

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

Prolongez cette requête en regroupant les résultats par type d’opération, type d’authentification, adresse IP de l’appelant ou identité d’application pour identifier la charge de travail générant des requêtes ralenties. Les journaux de ressources sont particulièrement utiles pour déterminer si la limitation du débit se concentre sur une application, une opération ou une période donnée.

Conditions d’alerte pour la limitation de la vitesse

Créez des alertes Azure Monitor pour :

• Occurrences prolongées de transactions avec l’erreur ServerBusyError.
• Augmentation des valeurs de ResponseType liées à la limitation du débit.
• Baisse de la métrique Disponibilité en dessous d’un seuil acceptable.
• Augmentation de la latence corrélée à des événements de limitation du débit.
• Des augmentations soudaines du volume de requêtes qui approchent les limites de scalabilité du stockage.

Flux de travail de suivi recommandé

1. Surveillez la métrique Transactions et divisez les résultats par type de réponse.
2. Recherchez une augmentation des types de réponses liés à la limitation du débit, comme ServerBusyError et ClientThrottlingError.
3. Utilisez la dimension ApiName pour identifier les opérations affectées.
4. Corréliez les événements de limitation de vitesse avec les changements de disponibilité, de latence E2E de réussite et de latence serveur de réussite.
5. Utilisez les journaux de ressources Azure Monitor pour déterminer quelles requêtes, opérations ou applications génèrent un trafic limité.
6. Configurez les alertes pour détecter les problèmes de limitation avant qu’ils n’affectent les utilisateurs.

En combinant les métriques, dimensions et journaux de ressources d’Azure Monitor, vous pouvez rapidement détecter les conditions de limitation, identifier la source d’une demande excessive et prendre des mesures correctives avant que les performances de l’application ne se dégradent.

Atténuer les partitions chaudes

Pour éviter les partitions surchargées, répartissez les requêtes de manière uniforme entre les partitions et assurez-vous que les applications réagissent correctement lorsqu’une limitation du débit se produit.

Utiliser des schémas de partitionnement et de nommage efficaces

Concevez les clés de partition, les noms de blobs et d’autres identifiants afin que les requêtes soient réparties sur plusieurs partitions. Évitez les schémas de nommage séquentiels ou à ajout seul qui dirigent la plupart des requêtes vers la même partition. Voir Optimiser les partitions blob et les schémas de nommage.

Utilisez un délai exponentiel entre les tentatives

Si les requêtes sont soumises à une limitation du débit et renvoient les erreurs 503 (Serveur occupé) ou 500 (Délai d’expiration de l’opération), réessayez en utilisant une stratégie de temporisation exponentielle. Cette approche réduit la pression sur la partition affectée et laisse à stockage Azure le temps de rééquilibrer la charge ou de se remettre de pics temporaires de demande.

Le comportement de nouvelle tentative avec temporisation exponentielle concerne surtout les applications personnalisées qui accèdent à stockage Azure à l’aide des bibliothèques clientes, des kits SDK ou des API REST d’stockage Azure. De nombreux services services Microsoft, applications managées et clients tiers implémentent déjà une logique de réessayage appropriée, donc vous n’aurez peut-être pas besoin de configurer quoi que ce soit de plus. Si vous développez une application personnalisée, assurez-vous que les politiques de réessai sont activées et configurées selon les meilleures pratiques d'stockage Azure. Consultez ces articles :

• Implémenter une politique de réessai pour .NET
• Implémenter une politique de réessai pour Java
• Implémenter une politique de réessai pour JavaScript
• Implémentez une politique de réessai pour Python
• Mettre en place une politique de réessai pour Go

Évitez les pics soudains du volume de demandes

Lors de l’introduction d’une nouvelle charge de travail, de la réalisation de tests de performance ou du traitement de grandes quantités de données, augmentez progressivement les taux de requêtes au lieu de générer immédiatement des pics de trafic. stockage Azure équilibre automatiquement la charge des partitions à mesure que la demande change, mais des pics de trafic soudains peuvent temporairement submerger une partition et entraîner un throttling jusqu’à ce que le service ait l’occasion de s’ajuster.

Étapes suivantes

Pour des conseils détaillés sur la mise en œuvre, voir :

• Objectifs de scalabilité et de performance pour stockage Azure
• Optimiser les partitions blob et les schémas de nommage
• Monitor Stockage Blob Azure
• Meilleures pratiques de surveillance du Blob Storage d'Azure
• Documentation de référence sur les métriques Azure Monitor et les journaux de ressources pour stockage Azure
• Liste de contrôle des performances pour stockage Blob Azure
• Liste de contrôle des performances pour les développeurs (Stockage Blob Azure)