Partilhar via

Diagnosticar e resolver problemas de exceções A taxa de pedidos do Azure Cosmos DB é demasiado grande (429)

  • Artigo

APLICA-SE A: NoSQL

Este artigo contém causas conhecidas e soluções para vários erros de código de status 429 para a API para NoSQL. Se você estiver usando a API para MongoDB, consulte o artigo Solucionar problemas comuns na API para MongoDB para saber como depurar o código de status 16500.

Uma exceção "Taxa de solicitação muito grande", também conhecida como código de erro 429, indica que suas solicitações contra o Azure Cosmos DB estão sendo limitadas.

Ao usar a taxa de transferência provisionada, você define a taxa de transferência medida em unidades de solicitação por segundo (RU/s) necessárias para sua carga de trabalho. As operações de banco de dados no serviço, como leituras, gravações e consultas, consomem algum número de unidades de solicitação (RUs). Saiba mais sobre as unidades de solicitação.

Em um determinado segundo, se as operações consumirem mais do que as unidades de solicitação provisionadas, o Azure Cosmos DB retornará uma exceção 429. A cada segundo, o número de unidades de solicitação disponíveis para uso é redefinido.

Antes de tomar uma ação para alterar o RU/s, é importante entender a causa raiz da limitação de taxa e resolver o problema subjacente.

Gorjeta

As diretrizes neste artigo se aplicam a bancos de dados e contêineres que usam taxa de transferência provisionada - dimensionamento automático e taxa de transferência manual.

Existem diferentes mensagens de erro que correspondem a diferentes tipos de exceções 429:

A taxa de solicitação é grande

Este é o cenário mais comum. Ocorre quando as unidades de solicitação consumidas pelas operações nos dados excedem o número provisionado de RU/s. Se você estiver usando a taxa de transferência manual, isso ocorrerá quando você tiver consumido mais RU/s do que a taxa de transferência manual provisionada. Se você estiver usando o dimensionamento automático, isso ocorrerá quando você tiver consumido mais do que o máximo de RU/s provisionado. Por exemplo, se você tiver um recurso provisionado com taxa de transferência manual de 400 RU/s, verá 429 quando consumir mais de 400 unidades de solicitação em um único segundo. Se você tiver um recurso provisionado com escala automática máxima de RU/s de 4000 RU/s (escala entre 400 RU/s - 4000 RU/s), verá 429 respostas quando consumir mais de 4000 unidades de solicitação em um único segundo.

Gorjeta

Todas as operações são cobradas com base no número de recursos que consomem. Estes encargos são medidos em unidades de pedido. Estas taxas incluem pedidos que não são concluídos com êxito devido a erros de aplicação, tais como 400, 412, 449, etc. Ao analisar a limitação ou o uso, é uma boa ideia investigar se algum padrão mudou em seu uso, o que resultaria em um aumento dessas operações. Especificamente, verifique se há tags 412 ou 449 (conflito real).

Para obter mais informações sobre a taxa de transferência provisionada, consulte Taxa de transferência provisionada no Azure Cosmos DB.

Etapa 1: Verifique as métricas para determinar a porcentagem de solicitações com erro 429

Ver 429 mensagens de erro não significa necessariamente que há um problema com seu banco de dados ou contêiner. Uma pequena porcentagem de 429 respostas é normal, quer você esteja usando a taxa de transferência manual ou de dimensionamento automático, e é um sinal de que você está maximizando o RU/s provisionado.

Como investigar

Determine qual porcentagem de suas solicitações para seu banco de dados ou contêiner resultou em 429 respostas, em comparação com a contagem geral de solicitações bem-sucedidas. Na sua conta do Azure Cosmos DB, navegue até Total de solicitações do Insights>>por código de status. Filtre para um banco de dados e contêiner específicos.

Por padrão, os SDKs de cliente do Azure Cosmos DB e as ferramentas de importação de dados, como o Azure Data Factory e a biblioteca de executores em massa, repetem automaticamente as solicitações em 429s. Eles tentam novamente normalmente até nove vezes. Como resultado, embora você possa ver 429 respostas nas métricas, esses erros podem nem ter sido retornados ao seu aplicativo.

Gráfico Total de solicitações por código de status que mostra o número de solicitações 429 e 2xx.

Em geral, para uma carga de trabalho de produção, se você vir entre 1-5% das solicitações com 429 respostas, e sua latência de ponta a ponta for aceitável, isso é um sinal saudável de que os RU/s estão sendo totalmente utilizados. nenhuma ação necessária. Caso contrário, vá para as próximas etapas de solução de problemas.

Importante

Este intervalo de 1-5% está assumindo que as partições da sua conta são distribuídas uniformemente. Se suas partições não são distribuídas uniformemente, sua partição de problema pode retornar uma grande quantidade de 429 erros, enquanto a taxa geral pode ser baixa.

Se você estiver usando o dimensionamento automático, é possível ver 429 respostas em seu banco de dados ou contêiner, mesmo que o RU/s não tenha sido dimensionado para o máximo de RU/s. Consulte a secção A taxa de pedidos é grande com a escala automática para obter uma explicação.

Uma pergunta comum que surge é: "Por que estou vendo 429 respostas nas métricas do Azure Monitor, mas nenhuma no meu próprio monitoramento de aplicativos?" Se as Métricas do Azure Monitor mostrarem que você tem 429 respostas, mas você não viu nenhuma em seu próprio aplicativo, isso ocorre porque, por padrão, os SDKs automatically retried internally on the 429 responses de cliente do Azure Cosmos DB e a solicitação foram bem-sucedidos em tentativas subsequentes. Como resultado, o código de status 429 não é retornado ao aplicativo. Nesses casos, a taxa geral de 429 respostas é normalmente mínima e pode ser ignorada com segurança, supondo que a taxa geral esteja entre 1-5% e que a latência de ponta a ponta seja aceitável para seu aplicativo.

Etapa 2: Determinar se há uma partição quente

Uma partição quente surge quando uma ou algumas chaves de partição lógicas consomem uma quantidade desproporcional do total de RU/s devido ao maior volume de solicitação. Isso pode ser causado por um design de chave de partição que não distribui solicitações uniformemente. Isso resulta em muitas solicitações sendo direcionadas para um pequeno subconjunto de partições lógicas (o que implica físicas) que se tornam "quentes". Como todos os dados de uma partição lógica residem em uma partição física e o total de RU/s é distribuído uniformemente entre as partições físicas, uma partição quente pode levar a 429 respostas e ao uso ineficiente da taxa de transferência.

Aqui estão alguns exemplos de estratégias de particionamento que levam a partições quentes:

  • Você tem um contêiner que armazena dados de dispositivos IoT para uma carga de trabalho de gravação pesada que é particionada pelo date. Todos os dados para uma única data residirão na mesma partição lógica e física. Como todos os dados gravados todos os dias têm a mesma data, isso resultaria em uma partição quente todos os dias.
    • Em vez disso, para este cenário, uma chave de partição como id (um GUID ou ID de dispositivo), ou uma chave de partição sintética combinando id e date produziria uma cardinalidade maior de valores e melhor distribuição do volume de solicitação.
  • Você tem um cenário multilocatário com um contêiner particionado por tenantId. Se um locatário é muito mais ativo do que os outros, isso resulta em uma partição quente. Por exemplo, se o maior locatário tiver 100.000 usuários, mas a maioria dos locatários tiver menos de 10 usuários, você terá uma partição ativa quando particionada pelo tenantID.
    • Para esse cenário anterior, considere ter um contêiner dedicado para o maior locatário, particionado por uma propriedade mais granular, como UserId.

Como identificar a partição quente

Para verificar se há uma partição ativa, navegue até Consumo de RU normalizado de taxa de transferência>do Insights>(%) por PartitionKeyRangeID. Filtre para um banco de dados e contêiner específicos.

Cada PartitionKeyRangeId é mapeado para uma partição física. Se houver um PartitionKeyRangeId que tenha um consumo de RU normalizado muito maior do que outros (por exemplo, um está consistentemente em 100%, mas outros estão em 30% ou menos), isso pode ser um sinal de uma partição quente. Saiba mais sobre a métrica Consumo de RU normalizado.

Consumo de RU normalizado pelo gráfico PartitionKeyRangeId com uma partição quente.

Para ver quais chaves de partição lógica estão consumindo mais RU/s, use os Logs de Diagnóstico do Azure. Esta consulta de exemplo resume o total de unidades de solicitação consumidas por segundo em cada chave de partição lógica.

Importante

A habilitação de logs de diagnóstico incorre em uma cobrança separada pelo serviço Log Analytics, que é cobrado com base no volume de dados ingeridos. É recomendável ativar os logs de diagnóstico por um período limitado de tempo para depuração e desativá-los quando não for mais necessário. Consulte a página de preços para obter detalhes.

 CDBPartitionKeyRUConsumption
 | where TimeGenerated >= ago(24hour)
 | where CollectionName == "CollectionName"
 | where isnotempty(PartitionKey)
 // Sum total request units consumed by logical partition key for each second
 | summarize sum(RequestCharge) by PartitionKey, OperationName, bin(TimeGenerated, 1s)
 | order by sum_RequestCharge desc

Esta saída de exemplo mostra que, em um minuto específico, a chave de partição lógica com valor "Contoso" consumiu cerca de 12.000 RU/s, enquanto a chave de partição lógica com valor "Fabrikam" consumiu menos de 600 RU/s. Se esse padrão fosse consistente durante o período de tempo em que a limitação de taxa ocorreu, isso indicaria uma partição quente.

Chaves de partição lógicas que consomem a maioria das unidades de solicitação por segundo.

Gorjeta

Em qualquer carga de trabalho, haverá variação natural no volume de solicitações entre partições lógicas. Você deve determinar se a partição quente é causada por uma assimetria fundamental devido à escolha da chave de partição (que pode exigir a alteração da chave) ou pico temporário devido à variação natural nos padrões de carga de trabalho.

Reveja as orientações sobre como escolher uma boa chave de partição.

Se houver uma alta porcentagem de solicitações limitadas de taxa e nenhuma partição ativa:

Se houver uma alta porcentagem de solicitações limitadas de taxa e houver uma partição quente subjacente:

  • A longo prazo, para melhor custo e desempenho, considere alterar a chave de partição. A chave de partição não pode ser atualizada no local, portanto, isso requer a migração dos dados para um novo contêiner com uma chave de partição diferente. O Azure Cosmos DB suporta uma ferramenta de migração de dados em direto para este fim.
  • A curto prazo, você pode aumentar temporariamente o RU/s geral do recurso para permitir mais taxa de transferência para a partição quente. Isso não é recomendado como uma estratégia de longo prazo, pois leva ao superprovisionamento de RU/s e a custos mais altos.
  • A curto prazo, você pode usar o recurso de redistribuição de taxa de transferência entre partições (visualização) para atribuir mais RU/s à partição física que está quente. Isso é recomendado somente quando a partição física quente é previsível e consistente.

Gorjeta

Quando você aumenta a taxa de transferência, a operação de expansão será concluída instantaneamente ou exigirá até 5 a 6 horas para ser concluída, dependendo do número de RU/s para o qual você deseja escalar. Se você quiser saber o maior número de RU/s que pode definir sem acionar a operação de expansão assíncrona (que exige que o Azure Cosmos DB provisione mais partições físicas), multiplique o número de PartitionKeyRangeIds distintos por 10.0000 RU/s. Por exemplo, se você tiver 30.000 RU/s provisionados e 5 partições físicas (6000 RU/s alocados por partição física), poderá aumentar para 50.000 RU/s (10.000 RU/s por partição física) em uma operação de expansão instantânea. Aumentar para >50.000 RU/s exigiria uma operação de expansão assíncrona. Saiba mais sobre as práticas recomendadas para dimensionar a taxa de transferência provisionada (RU/s).

Etapa 3: determinar quais solicitações estão retornando 429 respostas

Como investigar pedidos com 429 respostas

Use os Logs de Diagnóstico do Azure para identificar quais solicitações estão retornando 429 respostas e quantas RUs elas consumiram. Esta consulta de exemplo é agregada no nível de minuto.

Importante

A ativação de logs de diagnóstico incorre em uma cobrança separada pelo serviço Log Analytics, que é cobrado com base no volume de dados ingeridos. É recomendável ativar os logs de diagnóstico por um período limitado de tempo para depuração e desativá-los quando não for mais necessário. Consulte a página de preços para obter detalhes.

 CDBDataPlaneRequests
 | where TimeGenerated >= ago(24h)
 | summarize throttledOperations = dcountif(ActivityId, StatusCode == 429), totalOperations = dcount(ActivityId), totalConsumedRUPerMinute = sum(RequestCharge) by DatabaseName, CollectionName, OperationName, RequestResourceType, bin(TimeGenerated, 1min)
 | extend averageRUPerOperation = 1.0 * totalConsumedRUPerMinute / totalOperations
 | extend fractionOf429s = 1.0 * throttledOperations / totalOperations
 | order by fractionOf429s desc

Por exemplo, essa saída de exemplo mostra que, a cada minuto, 30% das solicitações Criar documento estavam sendo limitadas, com cada solicitação consumindo uma média de 17 RUs. Solicitações com 429 em Logs de diagnóstico.

Usar o planejador de capacidade do Azure Cosmos DB

Você pode usar o planejador de capacidade do Azure Cosmos DB para entender qual é a melhor taxa de transferência provisionada com base em sua carga de trabalho (volume e tipo de operações e tamanho dos documentos). Você pode personalizar ainda mais os cálculos fornecendo dados de exemplo para obter uma estimativa mais precisa.

429 respostas em Criar, substituir ou atualizar solicitações de documentos
  • Por padrão, na API para NoSQL, todas as propriedades são indexadas por padrão. Ajuste a política de indexação para indexar apenas as propriedades necessárias. Isso reduzirá as Unidades de Solicitação necessárias por operação de criação de documento, o que reduzirá a probabilidade de ver 429 respostas ou permitirá que você obtenha operações mais altas por segundo para a mesma quantidade de RU/s provisionados.
429 respostas sobre pedidos de documentos de consulta
429 respostas em Executar procedimentos armazenados
  • Os procedimentos armazenados destinam-se a operações que exigem transações de gravação em um valor de chave de partição. Não é recomendado usar procedimentos armazenados para um grande número de operações de leitura ou consulta. Para obter o melhor desempenho, essas operações de leitura ou consulta devem ser feitas no lado do cliente, usando os SDKs do Azure Cosmos DB.

A taxa de solicitações é grande com o dimensionamento automático

Todas as diretrizes neste artigo se aplicam à taxa de transferência manual e de dimensionamento automático.

Ao usar a escala automática, uma pergunta comum que surge é: "Ainda é possível ver 429 respostas com a escala automática?"

Sim. Há dois cenários principais em que isso pode ocorrer.

Cenário 1: Quando o RU/s total consumido exceder o máximo de RU/s do banco de dados ou contêiner, o serviço limitará as solicitações de acordo. Isso é análogo a exceder a taxa de transferência geral provisionada manual de um banco de dados ou contêiner.

Cenário 2: Se houver uma partição quente, ou seja, um valor de chave de partição lógica que tenha uma quantidade desproporcionalmente maior de solicitações em comparação com outros valores de chave de partição, é possível que a partição física subjacente exceda seu orçamento RU/s. Como melhor prática, para evitar partições frequentes, escolha uma boa chave de partição que resulte numa distribuição uniforme tanto do armazenamento como do débito. Isso é semelhante a quando há uma partição quente ao usar a taxa de transferência manual.

Por exemplo, se você selecionar a opção de taxa de transferência máxima de 20.000 RU/s e tiver 200 GB de armazenamento com quatro partições físicas, cada partição física poderá ser dimensionada automaticamente até 5000 RU/s. Se houver uma partição quente em uma chave de partição lógica específica, você verá 429 respostas quando a partição física subjacente em que reside exceder 5000 RU/s, ou seja, exceder 100% de utilização normalizada.

Siga as orientações na Etapa 1, Etapa 2 e Etapa 3 para depurar esses cenários.

Outra pergunta comum que surge é: Por que o consumo de RU normalizado é 100%, mas a escala automática não foi dimensionada para o máximo de RU/s?

Isso normalmente ocorre para cargas de trabalho que têm picos temporários ou intermitentes de uso. Quando você usa o dimensionamento automático, o Azure Cosmos DB só dimensiona o RU/s para a taxa de transferência máxima quando o consumo normalizado de RU é de 100% por um período de tempo sustentado e contínuo em um intervalo de 5 segundos. Isso é feito para garantir que a lógica de dimensionamento seja econômica para o usuário, pois garante que picos únicos e momentâneos não levem a escalonamentos desnecessários e custos mais altos. Quando há picos momentâneos, o sistema normalmente escala até um valor maior do que o anteriormente dimensionado para RU/s, mas menor do que o máximo de RU/s. Saiba mais sobre como interpretar a métrica de consumo de RU normalizada com o dimensionamento automático.

Limitação de taxa em solicitações de metadados

A limitação da taxa de metadados pode ocorrer quando você está executando um grande volume de operações de metadados em bancos de dados e/ou contêineres. As operações de metadados incluem:

  • Criar, ler, atualizar ou excluir um contêiner ou banco de dados
  • Listar bancos de dados ou contêineres em uma conta do Azure Cosmos DB
  • Consulta de ofertas para ver a taxa de transferência provisionada atual

Há um limite de RU reservado pelo sistema para essas operações, portanto, aumentar o RU/s provisionado do banco de dados ou contêiner não terá impacto e não é recomendado. Consulte Limites de serviço do plano de controle.

Como investigar

Navegue até Solicitações de metadados do sistema>Insights>por código de status. Filtre para um banco de dados e contêiner específicos, se desejar.

Solicitações de metadados por gráfico de código de status no Insights.

  • Se seu aplicativo precisar executar operações de metadados, considere implementar uma política de backoff para enviar essas solicitações a uma taxa menor.

  • Use instâncias de cliente estáticas do Azure Cosmos DB. Quando o DocumentClient ou CosmosClient é inicializado, o SDK do Azure Cosmos DB busca metadados sobre a conta, incluindo informações sobre o nível de consistência, bancos de dados, contêineres, partições e ofertas. Esta inicialização pode consumir um elevado número de RUs e deve ser realizada com pouca frequência. Utilize uma única instância do DocumentClient e utilize-a durante a vida útil da sua aplicação.

  • Armazene em cache os nomes de bancos de dados e contêineres. Recupere os nomes de seus bancos de dados e contêineres da configuração ou armazene-os em cache na inicialização. Chamadas como ReadDatabaseAsync/ReadDocumentCollectionAsync ou CreateDatabaseQuery/CreateDocumentCollectionQuery resultarão em chamadas de metadados para o serviço, que consomem a partir do limite de RU reservado pelo sistema. Estas operações devem ser realizadas com pouca frequência.

Limitação de taxa devido a erro de serviço transitório

Este erro 429 é retornado quando a solicitação encontra um erro de serviço transitório. Aumentar o RU/s no banco de dados ou contêiner não terá impacto e não é recomendado.

Repita o pedido. Se o erro persistir por vários minutos, registre um tíquete de suporte no portal do Azure.

Próximos passos