Azure Resource Graph(ARG)は、Azureリソース全体で高速かつ大規模なクエリを行うために構築されています。 ARGは非同期でデータをインデックス付けするため、ARGを直接クエリし、リソース状態の真実のソースであるリソースプロバイダー(RP)にフォールバックするタイミングを理解することが重要です。 この記事では、ARGがAzureのコントロールプレーンにどのように位置づけられるか、ハイブリッドARG+RPクエリ戦略の使い方、RP、ARGのクエリAPI、Get/List APIのどちらを選ぶかについて説明します。
AzureコントロールプレーンにおけるARGの位置づけ
資源制御プレーンは3つの要素から成り立っています。
Azure Resource Manager (ARM) – ARGのリクエストゲートウェイ。 ARMは各リソースプロバイダーに個別に呼び出しを行うことなく、リクエストをARGにルーティングします。
リソースプロバイダー (例えば、コンピュートリソースプロバイダー、CRP)—リソース状態の真実の源です。 リソースプロバイダーのAPIへの直接呼び出しは 、強力に一貫したデータを返します。
Azure Resource Graph(ARG)– コントロールプレーンデータ上の非同期インデックスで、大規模なリソースセット間で高スループットかつスケーラブルなクエリを可能に構築されています。 ARGは ほぼリアルタイムであり、APIをサポートするシステムの分散性により最終的に 一貫したモデルに従います。 真実の情報源からは短時間遅れることがあり、バックエンドの障害があった場合にはそれ以上遅れることもあります。
ARGは2つのメカニズムで同期を維持します。ARMやリソースプロバイダーからの非同期変更通知と、通知が見逃したものを検出する定期的な照合パスです。
Note
ARGは、スケールとスループットを得るために強整合性を犠牲にします。 リソース プロバイダー API は、特定時点での正確性と引き換えにスループットを犠牲にします。 運用に必要なものに応じて選択してください。
重要なシナリオにはハイブリッドクエリ戦略を活用しましょう
データの新鮮さや信頼性が重要な場合は、ハイブリッド戦略を用いましょう:スケールのためにARGにクエリし、データフレッシュネスの問題、インデックス遅延、レイテンシの増加を検出した場合、またはリソース状態に基づく重要なアクションを取る前にリソースプロバイダーAPIにフォールバックします。 このアプローチは、常にRPを直接呼び出すコストと、古いARGデータを現在のものとして扱うリスク(例えば、古い状態に基づいてリソースの再起動やデプロビジョニング)という2つの失敗モードを同時に回避します。
一般的なシナリオ
リソース作成直後のポーリング - 一部のワークフローでは、リソースを作成してから1〜2秒以内にポーリングを行います。例えば、最終状態に達する provisioningState を待ったり、特定のプロパティが応答に表示されるのを待ったりします。 ARGのインデックス作成が完了していない可能性があるため、作成直後に発行されたクエリはリソースが存在していても 404 Not Found 返されることがあります。 偽陰性を避けるためにハイブリッド戦略を用いましょう:書き込み直後にARGが「not found」を返した場合は、エラーとして扱う前にリソースプロバイダーにフォールバックします。
破壊的な操作前の状態検証 - ワークフローがARGを使って操作の候補リソースを特定し、その操作が破壊的なもの(削除、再起動、再提供)であれば、ARGの結果に直接対応しないでください。 バックエンドのレイテンシがARGのリソースビューを古くしてしまうことがあります。 このリスクは、結果として起こった行動を取り消せない場合に非常に重要です。
Important
ARGを使って候補リストを作成し、破壊アクションを実行する直前にリソース提供者に対して強整合性チェックを実行します。
ARGの最終的な整合性を扱うためのガイダンス
すべての投票でではなく、不可逆的な行動の前にのみ確認してください。 顧客に影響を与える、あるいは破壊的なワークフローを行う前に、二次的なリソースプロバイダーチェックを追加しましょう。すべてのARGクエリに対しては不要です。 すべてのポーリングを検証することは、ARG を利用する本来の目的を損なうだけでなく、大規模な運用において調整を誘発する可能性があります。 パターンはこうです:ARGを信頼して識別とスケールを確立し、取り返しのつかないものを起こす前に真実の情報源に確認する。
Tip
事業の規模での検証でスロットリングの懸念が生じた場合は、制限に達する前にMicrosoftに連絡してください。 このパターンを支えるための割当増加は、支持可能な期待される要求であり、例外的なケースではありません。
シナリオが許す場合は、次のARGクエリの間に待ち時間を設けてください。 もしそうなった場合は指数的なバックオフを使いましょう。最初のリトライの数秒前から始め、その後の試みごとに待ち時間を増やします(例:2秒→4秒→8秒→16秒など)。最大で数分まで。 上限に達したら増加をやめ、上限区間でポーリングを続けるか、リソースプロバイダーAPIにフォールバックしてください。
高頻度ポーリング用の ARG Get/List API を検討してみてください。 Get/List APIでのフォールバックの設定については 、このセクション を参照してください。
APIの比較
この表を使って、どのAPIがあなたのシナリオに合うかを判断してください。
| 特徴 | リソースプロバイダーAPI(例:CRP) | ARGクエリAPI | ARG Get/List API |
|---|---|---|---|
| その内容 | リソースプロバイダー自身のAPI(例:VM/VMSS API)に直接呼び出して、リソースや在庫を照会します。 | Azure Resource Graphの一括クエリAPIは、Azureポータル内のResource Graph Explorer、Azure PowerShell、Azure CLI、SDKs、REST APIを通じて利用可能です。 | 既存のコントロールプレーンのGet/List APIを使用し、useResourceGraph=trueを付け加えて、ARGバックエンドを経由して呼び出しをルーティングします。 Azure REST APIおよび一部のSDKを通じて利用可能です。 |
| リファレンス | Azure サービス別にリソース プロバイダーを検索する |
REST API を使用して Azure Resource Graph クエリを実行する。これには POST /providers/Microsoft.ResourceGraph/resources |
ARG GET/LIST API は既存のコントロールプレーンGET APIを活用し、APIにフラグ useResourceGraph=true を付けて呼び出しをこのバックエンドにシームレスにルーティングします。 |
| 最適な用途 | • コントロールプレーンAPIに対する小規模、アドホック、またはまれなクエリ。 • 真実の情報源から直接強力に一貫したデータを必要とするシナリオ。 ・破壊的または不可逆的な操作(削除、再起動、再提供)前の最終チェック。 • ARGデータが古くなった場合のバックアップ。 |
• 複雑な分析シナリオのために複数のテナント、サブスクリプション、リソースグループ、管理グループをまたぐテナントレベルの一括検索。 • 多数 (数千以上) のリソースの状態をスキャンまたはポーリングすること。 |
• 単一のサブスクリプションまたはリソース グループの get/list API 全体を対象とするルックアップ。 • 高並行処理量、高スループットのポーリングシナリオ。 |
| 調整とクォータ | 資源や運用によって異なり、一般的にARGの制限より低くなっています。 例:VMSSのGETはリソースレベルで毎分36回、サブスクリプションレベルでは毎分2,000回の通話です。 | 5秒間に15件のクエリ。 ケースバイケースで提起可能です。 | ARM の制限に準拠 — 最大 4,000 クエリ/分/サブスクリプション/呼び出し元。 これはソフトリミットであり、必要に応じて引き上げることができます。 |
| 整合性レベル | 強く一貫している — これが真実の源です。 | 最終的な整合性モデルに従います。 データはARGバックエンドでインデックスされ、通常は1分未満のレイテンシで処理されます。 | 最終的な整合性モデルに従います。 データはARGバックエンドでインデックスされ、通常は1分未満のレイテンシで処理されます。 |
| 可用性 | コントロールプレーンAPI自体はSLAを持ちませんが、それらを通じて管理されるリソースはSLAを保持します。例えば、Azure VMは冗長性オプションに応じて99.9% 以上のSLAを持っています。 | 公的なSLAはありません。 | 公的なSLAはありません。 |
| 製品ライフサイクル段階 | 一般公開 (GA) | 一般公開 (GA) | 一般公開 (GA) |
| Pricing | お電話は自由です。 これらのAPIを通じて作成または管理されるリソース(VMやストレージなど)には標準的なAzure料金が発生します。 | Free | Free |
Note
スロットリングの制限はリソースの種類や操作によって異なります。 上記の図は例です(リソース提供者の列に示すVMSS)。固定された定数として扱うのではなく、特定のリソースタイプや地域に応じた現在の制限を確認してください。
ハイブリッドフォールバックパターンとGet/List APIの両方が、短時間のデータ新鮮度のギャップに阻まれることなく、利用可能な最も正確なリソース状態を取得するのに役立ちます。
