Escolha a estratégia de consulta correta para o Azure Resource Graph

Azure Resource Graph (ARG) foi construído para consultas rápidas e em larga escala em seus recursos do Azure. Como o ARG indexa dados de forma assíncrona, é importante entender quando consultar o ARG diretamente e quando recorrer ao provedor de recurso (RP) que possui o recurso – a fonte de verdade para seu estado de recurso. Este artigo explica como o ARG se encaixa no plano de controle do Azure, quando usar uma estratégia híbrida de consulta ARG + RP, e como escolher entre RP, a API de Consulta do ARG e sua API Get/List.

Como o ARG se encaixa no plano de controle do Azure

O plano de controle de recursos possui três componentes:

• Azure Resource Manager (ARM) – o gateway de requisições para ARG. O ARM roteia requisições para o ARG sem precisar fazer chamadas individuais para cada provedor de recursos.

• Provedores de recursos (por exemplo, o Provedor de Recursos de Computação, ou CRP) – a fonte de verdade para o estado do recurso. Chamadas diretas para as APIs de um provedor de recursos retornam dados fortemente consistentes.

• Azure Resource Graph (ARG) – um índice assíncrono sobre dados de plano de controle, construído para consultas de alta taxa e escalabilidade em grandes conjuntos de recursos. O ARG é próximo de tempo real; ele segue um modelo de consistência eventual, devido à natureza distribuída do sistema que dá suporte à API. O ARG fica um pouco atrasado em relação à fonte da verdade por um breve período, ocasionalmente mais longo em caso de interrupções no back-end.

O ARG permanece sincronizado por meio de dois mecanismos: notificações de alteração assíncronas do ARM e dos provedores de recursos, e passagens de reconciliação periódicas que detectam qualquer informação que uma notificação tenha perdido.

Use uma estratégia híbrida de consulta para cenários críticos

Em cenários onde o frescor e a confiabilidade dos dados importam, use uma estratégia híbrida: consulte o ARG para escala e recorra à API do provedor de recursos quando detectar um problema de atualização dos dados, atraso na indexação, latência elevada ou antes de tomar uma ação crítica baseada no estado do recurso. Essa abordagem evita dois modos de falha ao mesmo tempo – o custo de sempre ligar diretamente ao RP e o risco de agir com dados do ARG obsoletos como se estivessem atuais (por exemplo, reiniciar ou desprovisionar um recurso com base em estado desatualizado).

Cenários comuns

Consulta imediatamente após a criação do recurso - Alguns fluxos de trabalho sondam um recurso em 1–2 segundos após a criação — por exemplo, esperar para provisioningState atingir um estado final ou esperar que certas propriedades apareçam na resposta. Como a indexação ARG pode não estar completa, uma consulta emitida logo após a criação pode retornar 404 Not Found mesmo que o recurso exista. Use uma estratégia híbrida para evitar falsos negativos: se o ARG retornar "não encontrado" imediatamente após uma gravação, consulte o provedor de recursos antes de tratar a operação como um erro.

Verificando o estado antes de uma operação destrutiva - Se seu fluxo de trabalho usa o ARG para identificar recursos candidatos a uma operação, e essa operação for destrutiva (excluir, reiniciar, desprovisionar), não aja diretamente sobre o resultado do ARG. A latência do backend pode deixar a visão do ARG sobre um recurso desatualizada. Esse risco é significativo quando a ação resultante não pode ser desfeita.

Orientações para lidar com a consistência eventual do ARG

• Verifique apenas antes de ações irreversíveis, não em todas as sondagens. Adicione uma verificação secundária do provedor de recursos antes de fluxos de trabalho que impactam o cliente ou são destrutivos — não em toda consulta ARG. Verificar cada consulta anula o propósito de usar o ARG e pode acionar a limitação de taxa em grande escala. O padrão é: confie no ARG para identificação e escalabilidade, verifique com a fonte da verdade imediatamente antes de qualquer ação irreversível.

  Tip

  Se a verificação no volume da sua operação gerar preocupações com a limitação de taxa, entre em contato com a Microsoft antes de atingir um limite. Solicitações de aumento de quota para dar suporte a esse padrão são esperadas e podem ser atendidas — não são um caso excepcional.

• Adicione o tempo de espera entre consultas ARG subsequentes quando seu cenário permitir. Onde acontecer, use o recuo exponencial: comece com alguns segundos antes da primeira tentativa e aumente o tempo de espera a cada tentativa subsequente (por exemplo, 2s → 4s → 8s → 16s...) até um limite de alguns minutos. Pare de aumentar assim que atingir esse limite e continue a sondar no intervalo limitado ou recorra à API do provedor de recursos.

• Considere a API ARG Get/List para pesquisas de alta frequência. Consulte esta seção que fala mais sobre como configurar um plano B com a API Get/List.

Comparação da API

Use esta tabela para decidir qual API se encaixa no seu cenário.

Tanto o padrão híbrido de fallback quanto a API Get/List ajudam a garantir que você obtenha o estado mais preciso possível do recurso, sem ficar bloqueado por lacunas temporárias de atualização dos dados.