Partições quentes no Armazenamento de Blobs do Azure: deteção, monitorização e mitigação

O Armazenamento de Blobs do Azure distribui dados entre partições para garantir um desempenho escalável. Quando o tráfego se concentra numa única partição, essa partição pode tornar-se um gargalo, uma condição conhecida como partição quente. Este artigo explica o que são partições quentes, como reconhecê-las através de métricas e registos de recursos do Azure Monitor, e que passos pode tomar para distribuir a carga de forma mais uniforme e reduzir erros de limitação.

Compreender partições quentes

O Armazenamento de Blobs do Azure distribui automaticamente os dados entre partições para escalar o desempenho e o rendimento. Quando uma única partição recebe significativamente mais tráfego do que outras partições, torna-se uma partição quente. Uma partição quente ocorre quando um grande número de pedidos de leitura, escrita ou atualização vai para a mesma partição, limitando a capacidade do serviço de equilibrar eficazmente a carga de trabalho. Como resultado, os pedidos sofrem um aumento da latência, limitação e erros de tempo limite até que a carga de trabalho seja redistribuída ou o padrão de acesso seja otimizado. Esquemas de particionamento ou nomenclatura que concentram o tráfego num pequeno subconjunto de dados em vez de espalhar os pedidos por múltiplas partições frequentemente causam partições quentes.

Sintomas e impacto das partições quentes

Quando uma partição de armazenamento se torna quente, deixa de conseguir processar pedidos de forma tão eficiente. À medida que a partição se aproxima dos seus limites de escalabilidade, o Armazenamento do Azure começa a limitar os pedidos para proteger o serviço e manter a fiabilidade para outras cargas de trabalho. As aplicações cliente apresentam maior latência, diminuição da taxa de transferência e falhas transitórias nas solicitações.

Os sintomas comuns de uma partição sobreaquecida incluem:

• Respostas HTTP 503 (Server Busy) que indicam que a partição está temporariamente incapaz de lidar com mais pedidos.
• Respostas HTTP 500 (Operation Timeout) quando os pedidos demoram demasiado tempo a ser concluídos porque a partição está sob carga elevada.
• Aumento da latência dos pedidos, mesmo para pedidos que acabam por ter sucesso.
• Novas tentativas automáticas do cliente, que podem aumentar ainda mais o tráfego e prolongar os problemas de desempenho se muitos clientes fizerem novas tentativas em simultâneo.
• Rendimento reduzido, onde a aplicação processa menos operações por segundo do que o esperado, apesar de ter capacidade total de armazenamento suficiente da conta.

As partições quentes são frequentemente causadas por padrões de acesso que concentram o tráfego numa única partição. Exemplos comuns incluem nomes de blobs sequenciais, cargas de trabalho apenas adicionáveis e designs de chaves de partição que enviam uma quantidade desproporcional de tráfego para uma única partição. Quando a carga de trabalho não está distribuída de forma uniforme, a partição afetada atinge os seus limites antes do resto da conta de armazenamento, criando um estrangulamento que afeta o desempenho da aplicação.

Para muitas aplicações, a primeira indicação de uma partição sobrecarregada é uma combinação de latência crescente, taxas crescentes de novas tentativas e um número crescente de erros 503 ou 500 em períodos de elevada procura.

Detetar erros de limitação utilizando métricas e registos de recursos do Azure Monitor

O Armazenamento do Azure limita os pedidos quando uma carga de trabalho excede os objetivos de escalabilidade de uma conta ou partição de armazenamento. Normalmente observa-se a limitação como respostas HTTP 503 (Server Ocupado) ou 500 (Operation Timeout). As bibliotecas de cliente do Armazenamento do Azure repetem frequentemente automaticamente os pedidos sujeitos a limitação, pelo que a monitorização é essencial para detetar situações de limitação antes que afetem significativamente o desempenho da aplicação.

Use métricas do Azure Monitor para identificar erros de limitação

Para detetar limitação, analise métricas do Azure Monitor para uma conta de armazenamento. A métrica Transactions, combinada com a dimensão ResponseType, permite visibilidade sobre o resultado dos pedidos ao armazenamento e ajuda-o a identificar falhas relacionadas com limitação.

Métricas para identificar estrangulamento

As seguintes métricas do Azure Monitor são úteis ao investigar o throttling:

Um padrão comum de limitação é um aumento da latência, acompanhado por um aumento dos tipos de resposta relacionados com a limitação e por uma diminuição da disponibilidade.

Utilize a dimensão ResponseType para identificar a limitação de taxa

A dimensão ResponseType é a principal ferramenta para identificar condições de limitação nas métricas do Azure Monitor. Valores relevantes incluem:

Monitorizar estes valores ao longo do tempo pode ajudar a identificar picos transitórios de limitação, bem como problemas persistentes de escalabilidade.

Utilize as dimensões para identificar com precisão a origem da limitação

As dimensões métricas do Azure Monitor podem ajudar a isolar a carga de trabalho responsável pela limitação:

Por exemplo, se a limitação ocorrer principalmente em PutBlob operações, a carga de trabalho pode ser intensiva em escrita. Se uma operação específica de API apresentar taxas elevadas de limitação, os esforços de otimização podem focar-se nessa operação em vez de toda a aplicação.

Analisar os registos de recursos do Azure Monitor

Embora as métricas identifiquem a presença de limitação, os registos de recursos do Azure Monitor fornecem detalhes de cada pedido que podem ajudar a diagnosticar a causa principal. Os registos de recursos captam tanto pedidos bem-sucedidos como falhados, incluindo limitação, timeout, autorização e erros relacionados com a rede.

Para Armazenamento de Blobs do Azure, os registos estão disponíveis na tabela StorageBlobLogs depois de os registos de recursos serem enviados para um espaço de trabalho Log Analytics.

Consultar registos de recursos para eventos de limitação

Antes de executar estas consultas, certifique-se de que os registos de recursos são enviados para um espaço de trabalho do Log Analytics.

Use a Linguagem de Consulta Kusto (KQL) para identificar pedidos que retornam códigos de estado comuns relacionados com a limitação:

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

Estenda esta consulta agrupando os resultados por operação, tipo de autenticação, endereço IP do chamador ou identidade da aplicação para identificar a carga de trabalho que gera pedidos limitados. Os registos de recursos são particularmente úteis para determinar se a limitação está concentrada numa aplicação, numa operação ou num período de tempo específico.

Condições de alerta para a limitação

Crie alertas do Azure Monitor para:

• Ocorrências persistentes de transações com ServerBusyError.
• Aumentos nos valores de ResponseType relacionados com condicionamento.
• Quedas na métrica Disponibilidade abaixo de um limite aceitável.
• Aumentos de latência que se correlacionam com eventos de limitação.
• Aumentos súbitos no volume de pedidos que se aproximam dos limites de escalabilidade do armazenamento.

Fluxo de trabalho de monitorização recomendado

1. Monitorize a métrica de Transações e divida os resultados por ResponseType.
2. Procure aumentos nos tipos de resposta relacionados com a limitação, como ServerBusyError e ClientThrottlingError.
3. Use a dimensão ApiName para identificar as operações afetadas.
4. Correlacione eventos de limitação com alterações na Disponibilidade, Latência E2E de Sucesso e Latência do Servidor de Sucesso.
5. Use os registos de recursos do Azure Monitor para determinar quais pedidos, operações ou aplicações estão a gerar tráfego limitado.
6. Configure alertas para que problemas de limitação sejam detetados antes de afetarem os utilizadores.

Ao combinar métricas, dimensões e registos de recursos do Azure Monitor, pode detetar rapidamente condições de limitação, identificar a origem da procura excessiva e tomar medidas corretivas antes que o desempenho da aplicação se deteriore.

Mitigar partições quentes

Para evitar partições sobrecarregadas, distribua as solicitações uniformemente pelas partições e assegure que as aplicações respondam adequadamente quando ocorrer limitação de taxa.

Utilizar esquemas eficientes de particionamento e nomeação

Desenhar chaves de partição, nomes de blobs e outros identificadores para que os pedidos sejam distribuídos por múltiplas partições. Evite padrões de nomes sequenciais ou de apenas acrescento que encaminham a maioria dos pedidos para a mesma partição. Veja Otimizar as partições de blobs e os esquemas de nomenclatura.

Utilize retrocesso exponencial para novas tentativas

Se os pedidos forem sujeitos a limitação e devolverem erros 503 (Servidor Ocupado) ou 500 (Tempo Limite da Operação), tente novamente os pedidos utilizando uma estratégia de intervalo de espera exponencial. Esta abordagem reduz a pressão sobre a partição afetada e dá tempo ao Armazenamento do Azure para reequilibrar a carga ou recuperar de picos temporários na procura.

O comportamento de repetição com recuo exponencial é mais relevante para aplicações personalizadas que acedem ao Armazenamento do Azure utilizando bibliotecas de cliente do Armazenamento do Azure, SDKs ou APIs REST. Muitos serviços da Microsoft, aplicações geridas e clientes de terceiros já implementam a lógica de repetição adequada, pelo que poderá não precisar de configurar mais nada. Se estiver a desenvolver uma aplicação personalizada, certifique-se de que as políticas de retentativa estão ativadas e configuradas de acordo com as melhores práticas do Armazenamento do Azure. Veja qualquer um destes artigos:

• Implementar uma política de novas tentativas para o .NET
• Implementar uma política de nova tentativa para Java
• Implementar uma política de repetição para JavaScript
• Implementar uma política de repetição para Python
• Implementar uma política de repetição para o Go

Evite picos súbitos no volume de pedidos

Ao introduzir uma nova carga de trabalho, realizar testes de desempenho ou processar grandes quantidades de dados, aumente gradualmente as taxas de pedidos em vez de gerar imediatamente o pico de tráfego. O Armazenamento do Azure equilibra automaticamente a carga das partições à medida que a procura muda, mas picos abruptos de tráfego podem sobrecarregar temporariamente uma partição e resultar em limitação até que o serviço tenha oportunidade de ajustar.

Passos seguintes

Para orientações detalhadas de implementação, veja:

• Metas de escalabilidade e desempenho para Armazenamento do Azure
• Otimizar partições de blob e esquemas de nomenclatura
• Monitorizar o Armazenamento de Blobs do Azure
• Melhores práticas para monitorizar Armazenamento de Blobs do Azure
• Documentação de referência sobre métricas do Azure Monitor e registos de recursos do Armazenamento do Azure
• Performance checklist for Armazenamento de Blobs do Azure
• Lista de verificação de desempenho para desenvolvedores (Armazenamento de Blobs do Azure)