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

O Azure Resource Graph (ARG) foi concebido para consultas rápidas e em grande escala nos seus recursos do Azure. Como o ARG indexa dados de forma assíncrona, é importante perceber quando consultar diretamente o ARG e quando recorrer ao fornecedor de recursos (RP) que detém o recurso – a fonte de verdade para o seu estado de recurso. Este artigo explica como o ARG se encaixa no plano de controlo 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 a sua API Get/List.

Como o ARG se encaixa no plano de controlo do Azure

O plano de controlo de recursos tem três componentes:

• Azure Resource Manager (ARM) – o gateway de pedidos para ARG. O ARM encaminha pedidos para o ARG sem necessidade de fazer chamadas individuais a cada fornecedor de recursos.

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

• Azure Resource Graph (ARG) – um índice assíncrono sobre dados do plano de controlo, construído para consultas de alto débito e escalável em grandes conjuntos de recursos. O ARG é quase em tempo real, segue um modelo eventualmente consistente, devido à natureza distribuída do sistema que suporta a API. Apresenta um breve atraso em relação à fonte fidedigna, ocasionalmente mais prolongado caso ocorram falhas no backend.

O ARG permanece sincronizado através de dois mecanismos: notificações assíncronas de alteração do ARM e dos fornecedores de recursos, e processos periódicos de reconciliação que detetam tudo o que uma notificação possa não ter detetado.

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

Em cenários onde a frescura e fiabilidade dos dados são importantes, use uma estratégia híbrida: consultar o ARG para escalar e recorrer à API do fornecedor de recursos quando detetar um problema de frescura dos dados, atraso na indexação, latência elevada ou antes de tomar uma ação crítica baseada no estado do recurso. Esta abordagem evita dois modos de falha ao mesmo tempo – o custo de chamar sempre diretamente o RP e o risco de agir com dados ARG obsoletos como se estivessem atualizados (por exemplo, reiniciar ou desprovisionar um recurso com base num estado desatualizado).

Cenários comuns

Sondagem imediatamente após a criação do recurso - Alguns fluxos de trabalho sondam um recurso dentro de 1–2 segundos após a sua criação — por exemplo, esperar que provisioningState atinja 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 ser retornada 404 Not Found mesmo que o recurso exista. Utilize uma estratégia híbrida para evitar falsos negativos: se o ARG devolver “não encontrado” imediatamente após uma operação de escrita, recorra ao fornecedor do recurso antes de o tratar como um erro.

Verificar o estado antes de uma operação destrutiva - Se o seu fluxo de trabalho usar ARG para identificar recursos candidatos a uma operação, e essa operação for destrutiva (eliminar, 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. Este risco é significativo quando a ação resultante não pode ser desfeita.

Orientações para gerir 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 fornecedor de recursos antes de fluxos de trabalho que impactem o cliente ou sejam destrutivos — não em todas as consultas do ARG. Verificar todas as sondagens anula o propósito de usar ARG e pode desencadear a limitação em escala. A abordagem é: confiar no ARG para identificação e escalabilidade, e verificar junto da fonte fidedigna imediatamente antes de qualquer ação irreversível.

  Sugestão

  Se verificar o volume da sua operação levantar preocupações sobre limitação, contacte a Microsoft antes de atingir um limite. Os aumentos de quotas para apoiar este padrão são um pedido justificável e esperado — não um caso extremo.

• Adiciona tempo de espera entre consultas ARG subsequentes onde o teu cenário o permite. Onde acontecer, usa o recuo exponencial: começa com alguns segundos antes da primeira tentativa e aumenta o tempo de espera a cada tentativa subsequente (por exemplo, 2s → 4s → 8s → 16s...) até um limite de alguns minutos. Para de aumentar quando atingires esse limite e continua a fazer polling no intervalo limite ou volta à API do fornecedor de recursos.

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

Comparação de API

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

Tanto o padrão híbrido de contingência como a API Get/List ajudam a garantir que está a recuperar o estado do recurso mais preciso disponível, sem ficar bloqueado por breves falhas na atualização dos dados.