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

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

Entenda partições quentes

Armazenamento de Blobs do Azure distribui automaticamente os dados entre as partições para escalar desempenho e throughput. Quando uma única partição recebe significativamente mais tráfego do que outras partições, ela se torna uma partição quente. Uma partição quente ocorre quando um grande número de solicitações de leitura, escrita ou atualização vai para a mesma partição, limitando a capacidade do serviço de balancear efetivamente a carga de trabalho. Como resultado, as requisições apresentam aumento de latência, redução de velocidade 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 nomeação que concentram o tráfego em um pequeno subconjunto de dados, em vez de espalhar as requisições por múltiplas partições, frequentemente causam partições quentes.

Sintomas e impacto das divisórias quentes

Quando uma partição de armazenamento fica quente, ela não consegue mais processar requisições de forma tão eficiente. À medida que a partição se aproxima de seus limites de escalabilidade, o Armazenamento do Azure começa a reduzir a limitação das solicitações para proteger o serviço e manter a confiabilidade para outras cargas de trabalho. Os aplicativos clientes apresentam maior latência, redução de taxa de transferência e falhas de requisições transitórias.

Sintomas comuns de uma partição quente incluem:

• Respostas HTTP 503 (Servidor ocupado) que indicam que a partição temporariamente não consegue processar mais requisições.
• Respostas HTTP 500 (Tempo Limite da Operação) quando as solicitações demorarem muito para serem concluídas porque a partição está sob carga pesada.
• Aumento da latência de requisição, mesmo para pedidos que acabam tendo 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 simultaneamente.
• Taxa de transferência reduzida, onde a aplicação processa menos operações por segundo do que o esperado, apesar da capacidade total suficiente da conta de armazenamento.

Partições quentes são frequentemente causadas por padrões de acesso que concentram o tráfego em uma única partição. Exemplos comuns incluem nomes de blobs sequenciais, cargas de trabalho somente 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 uniformemente, a partição afetada atinge seus limites antes do restante da conta de armazenamento, criando um gargalo que impacta o desempenho da aplicação.

Para muitas aplicações, a primeira indicação de uma partição quente é uma combinação de latência crescente, aumento das taxas de tentativa e números crescentes de erros de 503 ou 500 durante períodos de alta demanda.

Detectar erros de limitação por meio de logs de recursos e métricas do Azure Monitor

O Armazenamento do Azure limita as solicitações quando uma carga de trabalho excede os objetivos de escalabilidade de uma conta ou partição de armazenamento. Você geralmente observa a limitação na forma de respostas HTTP 503 (Servidor Ocupado) ou 500 (Tempo Limite da Operação). As bibliotecas cliente do Armazenamento do Azure frequentemente tentam novamente solicitações sujeitas a limitação automaticamente, portanto o monitoramento é essencial para detectar a ocorrência de limitação antes que ela afete significativamente o desempenho da aplicação.

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

Para detectar a limitação, analise as métricas do Azure Monitor para uma conta de armazenamento. A métrica Transactions, combinada com a dimensão ResponseType, oferece visibilidade do resultado das solicitações de armazenamento e ajuda a identificar as falhas relacionadas à limitação.

Métricas para identificar a limitação

As seguintes métricas do Azure Monitor são úteis quando se investiga a limitação:

Um padrão comum de limitação consiste em um aumento da latência, acompanhado por um aumento nos tipos de resposta relacionados à limitação e uma diminuição na disponibilidade.

Usar a dimensão ResponseType para identificar a limitação

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

Acompanhar esses valores ao longo do tempo pode ajudar a identificar picos de limitação transitória, bem como problemas de escalabilidade sustentados.

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

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

Por exemplo, se a limitação ocorre principalmente em operações PutBlob, a carga de trabalho pode ser de gravação intensiva. Se uma operação específica da API apresentar altas taxas de limitação, os esforços de otimização podem se concentrar nessa operação, em vez de no aplicativo inteiro.

Analisar logs de recursos do Azure Monitor

Enquanto as métricas identificam a presença de limitação, os logs de recursos do Azure Monitor fornecem detalhes no nível da solicitação que podem ajudar a diagnosticar a causa raiz. Os logs de recursos capturam tanto as solicitações bem-sucedidas quanto as solicitações com falha, incluindo erros de limitação, tempo limite, autorização e rede.

Para Armazenamento de Blobs do Azure, os registros estão disponíveis na tabela StorageBlobLogs após os registros de recursos serem enviados para um workspace do Log Analytics.

Consultar os logs de recursos para eventos de limitação

Antes de executar essas consultas, certifique-se de que os logs de recursos sejam enviados para um espaço de trabalho do Log Analytics.

Use a Linguagem de Consulta Kusto (KQL) para identificar as solicitações que retornam códigos de status comuns relacionados à limitação:

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

Estenda essa 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 requisições limitadas. Os logs de recursos são particularmente úteis para determinar se a limitação está concentrada em um aplicativo, operação ou período específico.

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

Criar alertas do Azure Monitor para:

• Ocorrências recorrentes de transações com ServerBusyError.
• Aumentos nos valores ResponseType relacionados à limitação.
• Queda na métrica de Disponibilidade abaixo de um limite aceitável.
• Aumentos na latência correlacionados a eventos de limitação de taxa.
• Aumentos repentinos no volume de solicitações que se aproximam dos limites de escalabilidade do armazenamento.

Fluxo de trabalho recomendado para monitoramento

1. Monitore a métrica de Transações e divida os resultados por ResponseType.
2. Procure por aumentos nos tipos de resposta relacionados à 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 as alterações na Disponibilidade, na Latência de E2E Bem-sucedida e Latência de Servidor Bem-sucedida.
5. Use os registros de recursos do Azure Monitor para determinar quais requisições, operações ou aplicações estão gerando tráfego limitado.
6. Configure alertas para que problemas de limitação de taxa sejam detectados antes de afetarem os usuários.

Ao combinar métricas, dimensões e logs de recursos do Azure Monitor, você pode detectar rapidamente condições de limitação, identificar a fonte da demanda excessiva e tomar medidas corretivas antes que o desempenho da aplicação piore.

Mitigar partições quentes

Para evitar partições frequentes, distribua as solicitações uniformemente entre as partições e garanta que os aplicativos respondam adequadamente quando ocorrer a limitação.

Use esquemas eficientes de particionamento e nomeação

Projete chaves de partição, nomes de blobs e outros identificadores para que as requisições sejam distribuídas entre múltiplas partições. Evite padrões de nomenclatura sequenciais ou somente de acréscimo que direcionem a maioria das requisições para a mesma partição. Veja Otimizar partições de blobs e esquemas de nomenclatura.

Usar retirada exponencial para as repetições

Se as requisições forem restringidas e retornarem erros 503 (Servidor Ocupado) ou 500 (Tempo limite da operação), tente novamente as solicitações usando uma estratégia de recuo exponencial. Essa abordagem reduz a pressão sobre a partição afetada e dá tempo ao Armazenamento do Azure para reequilibrar a carga ou se recuperar de picos temporários na demanda.

O comportamento de repetições com retirada exponencial é mais relevante para aplicativos personalizados que acessam o Armazenamento do Azure por meio de bibliotecas de cliente, SDKs ou APIs REST do Armazenamento do Azure. Muitos serviços da Microsoft, aplicativos gerenciados e clientes de terceiros já implementam a lógica adequada de repetição, então talvez você não precise configurar nada adicional. Se estiver desenvolvendo uma aplicação personalizada, certifique-se de que as políticas de retentativa estejam habilitadas e configuradas de acordo com as melhores práticas do Armazenamento do Azure. Leia um destes artigos:

• Implementar uma política de retentativas para .NET
• Implemente uma política de retentativas para Java
• Implementar uma política de repetição para JavaScript
• Implemente uma política de repetição para Python
• Implemente uma política de retentativas para o Go

Evite picos repentinos no volume de solicitações

Ao introduzir uma nova carga de trabalho, realizar testes de desempenho ou processar grandes volumes de dados, aumente gradualmente as taxas de solicitação em vez de gerar imediatamente picos de tráfego. O Armazenamento do Azure balanceia automaticamente a carga das partições conforme a demanda muda, mas picos abruptos de tráfego podem sobrecarregar temporariamente uma partição e resultar em redução de carga até que o serviço tenha oportunidade de se ajustar.

Próximas Etapas 

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

• Metas de escalabilidade e desempenho para Armazenamento do Azure
• Otimize partições de blob e convenções de nomenclatura
• Monitorar o Armazenamento de Blobs do Azure
• Melhores práticas para monitoramento do Armazenamento de Blobs do Azure
• Documentação de referência de métricas e logs de recursos do Azure Monitor para o Armazenamento do Azure
• Lista de verificação de desempenho do Armazenamento de Blobs do Azure
• Lista de verificação de desempenho para desenvolvedores (Armazenamento de Blobs do Azure)