Particiones calientes en Azure Blob Storage: detección, monitorización y mitigación

Azure Blob Storage distribuye los datos entre particiones para ofrecer un rendimiento escalable. Cuando el tráfico se concentra en una sola partición, esa partición puede convertirse en un cuello de botella, una condición conocida como partición caliente. Este artículo explica qué son las particiones calientes, cómo reconocerlas mediante métricas y registros de recursos de Azure Monitor, y qué pasos puedes seguir para distribuir la carga de forma más uniforme y reducir errores de limitación.

Comprender las particiones activas

Azure Blob Storage distribuye automáticamente los datos entre particiones para escalar el rendimiento y la capacidad de procesamiento. Cuando una sola partición recibe significativamente más tráfico que otras, se convierte en una partición caliente. Una partición activa ocurre cuando un gran número de solicitudes de lectura, escritura o actualización van a la misma partición, limitando la capacidad del servicio para equilibrar eficazmente la carga de trabajo. Como resultado, las solicitudes experimentan una mayor latencia, limitación de solicitudes y errores de tiempo de espera hasta que la carga de trabajo se redistribuye o el patrón de acceso se optimiza. Los esquemas de particionamiento o nombres que concentran el tráfico en un pequeño subconjunto de datos en lugar de repartir las solicitudes entre varias particiones suelen causar particiones calientes.

Síntomas e impacto de las particiones calientes

Cuando una partición de almacenamiento se calienta mucho, ya no puede procesar las solicitudes de forma tan eficiente. A medida que la partición se acerca a sus límites de escalabilidad, Azure Storage comienza a limitar las solicitudes para proteger el servicio y mantener la fiabilidad para otras cargas de trabajo. Las aplicaciones cliente experimentan mayor latencia, menor rendimiento y fallos en las solicitudes transitorias.

Los síntomas comunes de una partición caliente incluyen:

• Respuestas HTTP 503 (Servidor ocupado) que indican que la partición temporalmente no puede procesar más solicitudes.
• HTTP 500 (Operación Timeout) responde cuando las peticiones tardan demasiado en completarse porque la partición está bajo una carga elevada.
• Mayor latencia de solicitudes, incluso para peticiones que finalmente tienen éxito.
• Reintentos automáticos de clientes, que pueden aumentar aún más el tráfico y prolongar problemas de rendimiento si muchos clientes lo intentan simultáneamente.
• Menor capacidad de rendimiento, donde la aplicación procesa menos operaciones por segundo de lo esperado a pesar de tener suficiente capacidad total de almacenamiento de la cuenta.

Las particiones calientes suelen ser causadas por patrones de acceso que concentran el tráfico en una sola partición. Entre los ejemplos habituales se incluyen nombres de blobs secuenciales, cargas de trabajo de solo anexar y diseños de claves de partición que envían una cantidad desproporcionada de tráfico a una sola partición. Cuando la carga de trabajo no se distribuye de forma uniforme, la partición afectada alcanza sus límites antes que el resto de la cuenta de almacenamiento, creando un cuello de botella que afecta al rendimiento de la aplicación.

Para muchas aplicaciones, la primera indicación de una partición caliente es una combinación de latencia creciente, tasas de reintentos crecientes y un número creciente de errores de 503 o 500 durante periodos de alta demanda.

Detectar errores de limitación de solicitudes mediante las métricas de Azure Monitor y los registros de recursos

Azure Storage limita las solicitudes cuando una carga de trabajo supera los objetivos de escalabilidad de una cuenta o partición de almacenamiento. Normalmente, observará la limitación de velocidad en forma de respuestas HTTP 503 (Servidor ocupado) o 500 (Tiempo de espera de la operación). Las bibliotecas cliente de Azure Storage suelen reintentar automáticamente las solicitudes limitadas, por lo que la supervisión es esencial para detectar la limitación de solicitudes antes de que afecte significativamente al rendimiento de la aplicación.

Usar las métricas de Azure Monitor para identificar los errores de limitación de solicitudes

Para detectar la limitación de solicitudes, analice las métricas de Azure Monitor en una cuenta de almacenamiento. La métrica Transactions, combinada con la dimensión ResponseType, ofrece visibilidad del resultado de las solicitudes de almacenamiento y te ayuda a identificar errores relacionados con la limitación de velocidad.

Métricas para identificar la limitación de solicitudes

Las siguientes métricas de Azure Monitor resultan útiles a la hora de investigar la limitación de solicitudes:

Un patrón de limitación de solicitudes común es un aumento de la latencia acompañado de un aumento en los tipos de respuesta relacionados con la limitación y una disminución de la disponibilidad.

Usar la dimensión ResponseType para identificar la limitación de solicitudes

La dimensión ResponseType es la herramienta principal para identificar condiciones de limitación de velocidad en las métricas de Azure Monitor. Los valores relevantes incluyen:

El seguimiento de estos valores a lo largo del tiempo puede ayudarle a identificar picos transitorios de limitación de solicitudes, así como problemas de escalabilidad sostenidos.

Usar dimensiones para identificar el origen de la limitación de solicitudes

Las dimensiones de las métricas de Azure Monitor pueden ayudar a aislar la carga de trabajo responsable de la limitación de solicitudes:

Por ejemplo, si la limitación de solicitudes se produce principalmente en operaciones PutBlob, la carga de trabajo podría tener un uso intensivo de escritura. Si una operación concreta de la API muestra índices elevados de limitación de solicitudes, los esfuerzos de optimización pueden centrarse en esa operación en lugar de en la aplicación en su conjunto.

Analizar los registros de recursos de Azure Monitor

Aunque las métricas identifican la presencia de limitación, los registros de recursos de Azure Monitor proporcionan detalles a nivel de solicitud que pueden ayudar a diagnosticar la causa raíz. Los registros de recursos capturan tanto solicitudes exitosas como fallidas, incluyendo limitación, tiempo de espera, autorización y errores relacionados con la red.

Para Azure Blob Storage, los registros están disponibles en la tabla StorageBlobLogs después de que los registros de recursos se envían a un espacio de trabajo de Log Analytics.

Consultar los registros de recursos en busca de eventos de limitación de solicitudes

Antes de realizar estas consultas, asegúrate de que los registros de recursos se envían a un espacio de trabajo de Log Analytics.

Use Kusto Query Language (KQL) para identificar solicitudes que devuelvan códigos de estado comunes relacionados con la limitación de velocidad:

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

Extiende esta consulta agrupando los resultados por operación, tipo de autenticación, dirección IP del llamante o identidad de aplicación para identificar la carga de trabajo que genera solicitudes limitadas. Los registros de recursos son especialmente útiles para determinar si la limitación de velocidad se concentra en una aplicación, una operación o un período de tiempo específicos.

Condiciones de alerta para la limitación de solicitudes

Cree alertas de Azure Monitor para:

• Ocurrencias sostenidas de transacciones con ServerBusyError.
• Aumentos en los valores de ResponseType relacionados con la limitación de solicitudes.
• Baja la métrica de Disponibilidad por debajo de un umbral aceptable.
• Aumentos de latencia que se correlacionan con eventos de limitación de solicitudes.
• Aumentos repentinos en el volumen de solicitudes que se acercan a los límites de escalabilidad del almacenamiento.

Flujo de trabajo recomendado para monitorización

1. Monitoriza la métrica de Transacciones y divide los resultados por ResponseType.
2. Busque aumentos en los tipos de respuesta relacionados con la limitación de solicitudes, como ServerBusyError y ClientThrottlingError.
3. Utiliza la dimensión ApiName para identificar las operaciones afectadas.
4. Correlacione los eventos de limitación de solicitudes con cambios en Disponibilidad, Latencia E2E correcta y Latencia correcta del servidor.
5. Utiliza los registros de recursos de Azure Monitor para determinar qué solicitudes, operaciones o aplicaciones están generando tráfico limitado.
6. Configura las alertas de modo que se detecten los problemas de limitación antes de que afecten a los usuarios.

Combinando métricas, dimensiones y registros de recursos de Azure Monitor, puedes detectar rápidamente las condiciones de limitación, identificar la fuente de la demanda excesiva y tomar medidas correctivas antes de que el rendimiento de la aplicación se deteriore.

Mitigar particiones calientes

Para evitar particiones con sobrecarga, distribuye las solicitudes de manera uniforme entre las particiones y asegúrate de que las aplicaciones respondan adecuadamente cuando se aplique una limitación de tasa.

Usar esquemas de nomenclatura y partición eficientes

Diseña claves de partición, nombres de blobs y otros identificadores para que las solicitudes se distribuyan entre múltiples particiones. Evite patrones de nomenclatura secuenciales o de solo anexar que dirijan la mayoría de las solicitudes a la misma partición. Consulte Optimizar las particiones de blobs y las convenciones de nomenclatura.

Usar el retroceso exponencial para los reintentos

Si se limitan las solicitudes y devuelven errores 503 (Servidor ocupado) o 500 (Tiempo de espera de la operación), vuelva a intentar las solicitudes mediante una estrategia de espera exponencial. Este enfoque reduce la presión sobre la partición afectada y da tiempo a Azure Storage para reequilibrar la carga o recuperarse de picos temporales de demanda.

El comportamiento de reintento con retroceso exponencial es más pertinente para aplicaciones personalizadas que acceden a Azure Storage mediante bibliotecas cliente de Azure Storage, SDK o API REST. Muchos servicios de servicios Microsoft, aplicaciones gestionadas y clientes de terceros ya implementan la lógica de reintento adecuada, así que puede que no necesites configurar nada adicional. Si estás desarrollando una aplicación personalizada, asegúrate de que las políticas de reintento estén habilitadas y configuradas según las mejores prácticas de Azure Storage. Consulte cualquiera de estos artículos:

• Implementar una política de reintentos para .NET
• Implementar una política de reintentos para Java
• Implementar una política de reintentos para JavaScript
• Implementa una política de reintentos para Python
• Implementa una política de reintentos para Go

Evitar picos repentinos en el volumen de solicitudes

Al introducir una nueva carga de trabajo, realizar pruebas de rendimiento o procesar grandes cantidades de datos, aumenta gradualmente las tasas de solicitudes en lugar de generar inmediatamente picos de tráfico. Azure Storage equilibra automáticamente la carga de las particiones a medida que cambia la demanda, pero picos abruptos de tráfico pueden saturar temporalmente una partición y provocar limitaciones hasta que el servicio tenga oportunidad de ajustarse.

Pasos siguientes

Para una guía detallada sobre la implementación, véase:

• Escalabilidad y objetivos de rendimiento para Azure Storage
• Optimizar las particiones de blobs y las convenciones de nomenclatura
• Supervisión de Azure Blob Storage
• Mejores prácticas para supervisar Azure Blob Storage
• Documentación de referencia sobre métricas y registros de recursos de Azure Monitor para Azure Storage
• Lista de comprobación de rendimiento para Azure Blob Storage
• Lista de comprobación de rendimiento para desarrolladores (Azure Blob Storage)