Choisissez la bonne stratégie de requête pour Azure Resource Graph

Azure Resource Graph (ARG) est conçu pour des requêtes rapides et à grande échelle sur vos ressources Azure. Parce que l’ARG indexe les données de manière asynchrone, il est important de comprendre quand interroger directement l’ARG et quand revenir au fournisseur de ressource (RP) qui possède la ressource – la source de vérité pour son état de ressource. Cet article explique comment l'ARG s'intègre dans le plan de contrôle Azure, quand utiliser une stratégie hybride ARG + RP de requête, et comment choisir entre RP, l'API de requête d'ARG et son API Get/List.

Comment l’ARG s’intègre dans le plan de contrôle Azure

Le plan de contrôle des ressources comporte trois composantes :

• Azure Resource Manager (ARM) – la passerelle de requête pour l’ARG. ARM aroute les requêtes vers ARG sans avoir à effectuer des appels individuels à chaque fournisseur de ressources.

• Les fournisseurs de ressources (par exemple, le Fournisseur de Ressources de Calcul, ou CRP) – la source de vérité pour l’état de la ressource. Les appels directs vers les API d’un fournisseur de ressources renvoient des données fortement cohérentes.

• Azure Resource Graph (ARG) – un index asynchrone sur des données de plan de contrôle, conçu pour des requêtes à haut débit et évolutives sur de grands ensembles de ressources. L’ARG est quasi en temps réel et repose sur un modèle de cohérence à terme, en raison de la nature distribuée du système qui prend en charge l’API. Il présente un léger décalage par rapport à la source de référence, parfois plus important en cas de perturbations du backend.

ARG reste synchronisé grâce à deux mécanismes : des notifications de modification asynchrones provenant d’ARM et des fournisseurs de ressources, ainsi que des cycles périodiques de rapprochement qui permettent de repérer tout élément qu’une notification n’aurait pas signalé.

Utiliser une stratégie de requête hybride pour les scénarios critiques

Dans les situations où la fraîcheur et la fiabilité des données comptent, utilisez une stratégie hybride : interroger l’ARG pour l’échelle, puis revenir à l’API du fournisseur de ressources lorsque vous détectez un problème de fraîcheur des données, un retard d’indexation, une latence élevée ou avant de prendre une action critique basée sur l’état des ressources. Cette approche évite deux modes de défaillance simultanément – le coût d’appeler toujours directement le RP, et le risque d’agir sur des données ARG obsolètes comme si elles étaient actuelles (par exemple, redémarrer ou déprovisionner une ressource sur la base d’un état obsolète).

Scénarios courants

Interrogation immédiatement après la création de la ressource – Certains workflows interrogent une ressource dans les 1 à 2 secondes suivant sa création — par exemple, en attendant d’atteindre provisioningState un état final, ou en attendant que certaines propriétés apparaissent dans la réponse. Comme l’indexation ARG peut ne pas être complète, une requête lancée aussi peu de temps après la création peut être revenguée 404 Not Found même si la ressource existe. Utilisez une stratégie hybride pour éviter les faux négatifs : si ARG renvoie « introuvable » immédiatement après une opération d’écriture, rabattez-vous sur le fournisseur de ressources avant de traiter ce résultat comme une erreur.

Vérification de l’état avant une opération destructrice - Si votre workflow utilise l’ARG pour identifier les ressources candidates à une opération, et que cette opération est destructrice (supprimer, redémarrer, déprovisionner), n’agissez pas directement sur le résultat ARG. La latence du back-end peut rendre obsolète la vue d’ARG sur une ressource. Ce risque est important lorsque l’action résultante ne peut être annulée.

Recommandations pour gérer la cohérence éventuelle d’ARG

• Effectuez une vérification uniquement avant les actions irréversibles, et non à chaque interrogation. Ajoutez une vérification secondaire du fournisseur de ressources avant des flux de travail qui impactent le client ou sont destructeurs — pas sur chaque requête ARG. Effectuer une vérification à chaque interrogation va à l’encontre de l’objectif d’ARG et peut déclencher une limitation à grande échelle. Le schéma est : faites confiance à l’ARG pour l’identification et l’échelle, vérifiez avec la source de vérité juste avant toute chose irréversible.

  Tip

  Si la vérification au volume de votre opération suscite des préoccupations en matière de limitation, contactez Microsoft avant d’atteindre une limite. Les augmentations de quotas pour soutenir ce schéma sont une demande justifiée et attendue — pas un cas particulier.

• Ajoutez le temps d’attente entre les requêtes ARG suivantes lorsque votre scénario le permet. Là où c’est le cas, utilisez un recul exponentiel : commencez avec quelques secondes avant la première tentative, et augmentez le temps d’attente à chaque tentative suivante (par exemple, 2 secondes → 4 secondes → 8 → 16 secondes...) jusqu’à un plafond de quelques minutes. Arrêtez d’augmenter une fois que vous atteignez ce plafond, et soit continuez à sonder à l’intervalle plafonné, soit revenez à l’API du fournisseur de ressources.

• Considérez l’API ARG Get/List pour les sondages à haute fréquence. Consultez cette section qui explique davantage la mise en place d’un plan B avec l’API Get/List.

Comparaison des API

Utilisez ce tableau pour décider quelle API correspond à votre scénario.

Le modèle de secours hybride comme l’API Get/List permettent de récupérer l’état des ressources le plus exact possible, sans être bloqué par des problèmes temporaires d’actualisation des données.