Wähle die richtige Abfragestrategie für Azure Resource Graph

Azure Resource Graph (ARG) ist für schnelle, groß angelegte Abfragen über Ihre Azure-Ressourcen ausgelegt. Da ARG Daten asynchron indexiert, ist es wichtig zu verstehen, wann man ARG direkt abfragt und wann man auf den Ressourcenanbieter (RP) zurückgreifen muss, der die Ressource besitzt – die Quelle der Wahrheit für ihren Ressourcenzustand. Dieser Artikel erklärt, wie ARG in die Azure-Kontrollebene passt, wann eine hybride ARG + RP-Abfragestrategie verwendet werden sollte und wie man zwischen RP, ARGs Abfrage-API und seiner Get/List API wählt.

Wie ARG in die Azure-Kontrollebene passt

Die Ressourcenkontrollebene besteht aus drei Komponenten:

• Azure Resource Manager (ARM) – das Anfrage-Gateway für ARG. ARM leitet Anfragen an ARG weiter, ohne individuelle Aufrufe an jeden Ressourcenanbieter tätigen zu müssen.

• Resource Providers (zum Beispiel der Compute Resource Provider oder CRP) – die Wahrheitsquelle für den Ressourcenzustand. Direkte Aufrufe an die APIs eines Ressourcenanbieters liefern stark konsistente Daten.

• Azure Resource Graph (ARG) – ein asynchroner Index über Steuerebenendaten, der für hochdurchsatzfähige, skalierbare Abfragen über große Ressourcenmengen entwickelt wurde. ARG ist nahezu Echtzeit und folgt einem Modell der letztlichen Konsistenz, was auf die verteilte Natur des Systems zurückzuführen ist, das die API unterstützt. Sie hinkt der Wahrheitsquelle nur kurz hinterher, manchmal sogar länger, falls es Backend-Störungen gibt.

ARG bleibt durch zwei Mechanismen synchronisiert: asynchrone Änderungsbenachrichtigungen von ARM und Ressourcenanbietern sowie periodische Abgleichsdurchläufe, die alles erfassen, was einer Benachrichtigung entgangen ist.

Verwenden Sie eine hybride Abfragestrategie für kritische Szenarien

In Szenarien, in denen Datenfrëschheit und Datenzuverlässigkeit wichtig sind, verwenden Sie eine hybride Strategie: Abfragen Sie ARG für Skalierung und greifen Sie auf die Resource Provider API zurück, wenn Sie ein Problem mit der Datenfrart, eine Indexierungsverzögerung oder erhöhte Latenz erkennen oder bevor Sie eine kritische Aktion basierend auf dem Ressourcenzustand ergreifen. Dieser Ansatz vermeidet zwei Ausfallarten gleichzeitig – die Kosten, das RP ständig direkt aufzurufen, und das Risiko, auf veralteten ARG-Daten zu handeln, als wären sie aktuell (zum Beispiel das Neustarten oder Deprovisionieren einer Ressource aufgrund eines veralteten Zustands).

Häufige Szenarien

Umfrage unmittelbar nach der Ressourcenerstellung – Einige Workflows fragen eine Ressource innerhalb von 1–2 Sekunden nach der Erstellung ab – zum Beispiel warten sie darauf provisioningState , einen Endzustand zu erreichen, oder warten darauf, dass bestimmte Eigenschaften in der Antwort erscheinen. Da die ARG-Indexierung möglicherweise nicht vollständig ist, kann eine so kurz nach der Erstellung gestellte Abfrage zurückkehren 404 Not Found , obwohl die Ressource existiert. Verwenden Sie eine hybride Strategie, um falsch negative Ergebnisse zu vermeiden: Wenn ARG unmittelbar nach einem Schreibvorgang „Nicht gefunden“ zurückgibt, greifen Sie auf den Ressourcenanbieter zurück, bevor Sie dies als Fehler behandeln.

Zustand vor einer destruktiven Operation überprüfen – Wenn dein Workflow ARG verwendet, um Kandidatenressourcen für eine Operation zu identifizieren, und diese Operation destruktiv ist (Löschen, Neustart, Deprovision), handle nicht direkt auf das ARG-Ergebnis. Backend-Latenz kann dazu führen, dass ARGs Sicht auf eine Ressource veraltet ist. Dieses Risiko ist erheblich, wenn die daraus resultierende Handlung nicht rückgängig gemacht werden kann.

Leitfaden zum Umgang mit eventueller Konsistenz bei ARG

• Verifizieren Sie nur vor irreversiblen Maßnahmen, nicht bei jeder Umfrage. Fügen Sie vor kundenbeeinträchtigenden oder destruktiven Workflows eine sekundäre Ressourcen-Provider-Prüfung hinzu – nicht bei jeder ARG-Abfrage. Die Überprüfung jeder Poll-Abfrage macht den Zweck des Einsatzes von ARG zunichte und kann in großem Maßstab eine Drosselung auslösen. Das Muster ist: Vertraue auf ARG für Identifikation und Skalierung, verifiziere mit der Wahrheitsquelle direkt vor etwas Unumkehrbarem.

  Tip

  Wenn die Überprüfung bei Ihrem Betriebsvolumen Bedenken hinsichtlich einer Drosselung aufwirft, wenden Sie sich an Microsoft, bevor Sie an ein Limit stoßen. Quotenerhöhungen zur Unterstützung dieses Musters sind eine vertretbare, erwartete Bitte – kein Ausnahmefall.

• Füge die Wartezeit zwischen den folgenden ARG-Abfragen hinzu, wo dein Szenario es erlaubt. Wo es der Fall ist, nutze exponentiellen Backoff: Starte mit ein paar Sekunden vor dem ersten Versuch und erhöhe die Wartezeit mit jedem weiteren Versuch (zum Beispiel 2s → 4s → 8s → 16s...) bis zu einer Obergrenze von wenigen Minuten. Hören Sie auf mit der Erhöhung, sobald Sie dieses Limit erreicht haben, und setzen Sie entweder die Abfrage im begrenzten Intervall fort oder greifen Sie auf die Ressourcenanbieter-API zurück.

• Betrachten wir die ARG Get/List API für Hochfrequenz-Abfragen. Siehe diesen Abschnitt, der weitere Informationen zum Einrichten eines Fallbacks mit der Get/List API enthält.

API-Vergleich

Verwenden Sie diese Tabelle, um zu entscheiden, welche API zu Ihrem Szenario passt.

Sowohl das hybride Fallback-Muster als auch die Get/List API helfen sicherzustellen, dass Sie den genauesten verfügbaren Ressourcenzustand abrufen, ohne durch kurzlebige Daten-Freshness-Lücken blockiert zu werden.