Scegli la strategia di query giusta per Azure Resource Graph

Azure Resource Graph (ARG) è progettato per query rapide e su larga scala sulle tue risorse Azure. Poiché ARG indicizza i dati in modo asincrono, è importante capire quando interrogare direttamente ARG e quando ricorrere al fornitore di risorse (RP) che possiede la risorsa – la fonte di verità per il suo stato di risorsa. Questo articolo spiega come ARG si inserisce nel piano di controllo di Azure, quando utilizzare una strategia ibrida di query ARG + RP, e come scegliere tra RP, l'API di Query di ARG e la sua API Get/List.

Come si inserisce ARG nel piano di controllo di Azure

Il piano di controllo delle risorse ha tre componenti:

• Azure Resource Manager (ARM) – il gateway di richiesta per ARG. ARM instrada le richieste ad ARG senza dover effettuare singole chiamate a ciascun fornitore di risorse.

• Fornitori di risorse (ad esempio, il Compute Resource Provider, o CRP) – la fonte di verità per lo stato della risorsa. Le chiamate dirette alle API di un fornitore di risorse restituiscono dati fortemente coerenti.

• Azure Resource Graph (ARG) – un indice asincrono su dati sul piano di controllo, progettato per query ad alto throughput e scalabile su grandi insiemi di risorse. L'ARG è quasi in tempo reale, segue un modello a coerenza finale, a causa della natura distribuita del sistema che supporta l'API. Rimane indietro rispetto alla fonte di verità di un breve periodo, a volte anche di più nel caso ci siano interruzioni nel backend.

ARG rimane sincronizzato tramite due meccanismi: notifiche di modifica asincrone da parte di fornitori ARM e risorse, e passaggi periodici di riconciliazione che rilevano qualsiasi notifica mancata.

Usa una strategia di query ibrida per scenari critici

Negli scenari in cui la freschezza e l'affidabilità dei dati sono rilevanti, usa una strategia ibrida: consulta ARG per scalare e torna all'API del fornitore di risorse quando rilevi un problema di freschezza dei dati, un ritardo nell'indicizzazione o una latenza elevata o prima di intraprendere un'azione critica basata sullo stato della risorsa. Questo approccio evita due modalità di guasto contemporaneamente – il costo di chiamare sempre direttamente il RP e il rischio di agire su dati ARG obsoleti come se fossero attuali (ad esempio, riavviare o deprovisionare una risorsa basandosi su uno stato obsoleto).

Scenari comuni

Intervistamento immediatamente dopo la creazione della risorsa - Alcuni flussi di lavoro interrogano una risorsa entro 1–2 secondi dalla sua creazione — ad esempio, aspettando che provisioningState raggiunga uno stato finale o aspettando che alcune proprietà appaian nella risposta. Poiché l'indicizzazione ARG potrebbe non essere completa, una query emessa così presto dopo la creazione può restituire 404 Not Found anche se la risorsa esiste. Usare una strategia ibrida per evitare falsi negativi: se ARG restituisce "non trovato" immediatamente dopo un'operazione di scrittura, interrogare il provider di risorse prima di trattarlo come un errore.

Verifica dello stato prima di un'operazione distruttiva - Se il tuo workflow utilizza ARG per identificare le risorse candidate per un'operazione, e quell'operazione è distruttiva (cancella, riavvio, deprovision), non agire direttamente sul risultato ARG. La latenza del back-end può fare in modo che la visualizzazione di una risorsa in ARG non sia aggiornata. Questo rischio è significativo quando l'azione risultante non può essere annullata.

Linee guida per gestire la coerenza finale per ARG

• Verifica solo prima di azioni irreversibili, non su ogni sondaggio. Aggiungere un controllo secondario del provider di risorse prima dei flussi di lavoro che hanno impatto sui clienti o sono distruttivi, non prima di ogni query ARG. Verificare ogni sondaggio vanifica lo scopo dell'uso dell'ARG e può innescare il throttling su larga scala. Lo schema è: affidati ad ARG per l'identificazione e la scalabilità, verifica con la fonte autorevole subito prima di qualsiasi operazione irreversibile.

  Tip

  Se verificare il volume dell'operazione solleva preoccupazioni legate alla limitazione, coinvolgere Microsoft prima di raggiungere un limite. Gli aumenti delle quote per supportare questo schema sono una richiesta supportabile e prevista — non un caso limite.

• Aggiungi tempi di attesa tra le query ARG successive quando il tuo scenario lo consente. Quando succede, usa un backoff esponenziale: inizia con un paio di secondi prima del primo tentativo e aumenta il tempo di attesa ad ogni tentativo successivo (ad esempio, 2 → 4 secondi → 8 → 16 secondi...) fino a un massimo di pochi minuti. Smettere di aumentare una volta raggiunto quel limite e continuare a fare polling all'intervallo limite oppure tornare all'API del provider di risorse.

• Considera l'API ARG Get/List per il polling ad alta frequenza. Fai riferimento a questa sezione che spiega più informazioni su come impostare un fallback con l'API Get/List.

Confronto tra API

Usa questa tabella per decidere quale API si adatta al tuo scenario.

Sia il modello di fallback ibrido che l'API Get/List aiutano a garantire che tu recuperi lo stato delle risorse più accurato disponibile, senza essere bloccato da lacune di freschezza dei dati di breve durata.