Azure Resource Manager とは
Azure Resource Manager は、Azure のデプロイおよび管理サービスです。 お使いの Azure アカウント内のリソースを作成、更新、および削除できる管理レイヤーを提供します。 アクセス制御、ロック、タグなどの管理機能を使用して、デプロイ後にリソースを保護および整理します。
Azure Resource Manager テンプレート (ARM テンプレート) については、ARM テンプレートの概要に関するページを参照してください。 Bicep については、Bicep の概要に関するページを参照してください。
次のビデオでは、Azure Resource Manager の基本的な概念について説明します。
一貫性のある管理レイヤー
ユーザーが Azure API、ツール、または SDK のいずれかを介して要求を送信すると、その要求はリソース マネージャーによって受信されます。 要求は、認証および承認された後、適切な Azure サービスに転送されます。 すべての要求は同じ API を介して処理されるため、すべての異なるツールで一貫した結果と機能が得られます。
次の図は、Azure 要求の処理において Azure Resource Manager が果たす役割を示しています。
ポータルで利用できるすべての機能は、PowerShell、Azure CLI、REST API、およびクライアント SDK からも利用できます。 API を介して最初にリリースされた機能は、最初のリリースから 180 日以内にポータルに表示されます。
重要
Azure Resource Manager は、2023 年秋までに、トランスポート層セキュリティ (TLS) 1.2 以降のみをサポートする予定です。 詳細については、「Azure Resource Manager の TLS 1.2 への移行」を参照してください。
用語
Azure Resource Manager には、初めて使う方にとって、あまり馴染みのない用語がいくつか存在します。
- リソース - Azure を通じて管理できる要素。 リソースの例として、仮想マシン、ストレージ アカウント、Web アプリ、データベース、および仮想ネットワークがあります。 リソース グループ、サブスクリプション、管理グループ、およびタグもリソースの例です。
- リソース グループ - Azure ソリューションの関連するリソースを保持するコンテナー。 リソース グループには、グループとして管理するリソースが含まれます。 組織にとって最も有用になるように、どのリソースをリソース グループに含めるかを決定します。 「リソース グループとは?」を参照してください。
- リソース プロバイダー - Azure リソースを提供するサービス。 一般的なリソースプロバイダーの一例として、仮想マシン リソースを提供する
Microsoft.Computeがあります。Microsoft.Storageは、もう 1 つの一般的なリソースプロバイダーです。 リソースプロバイダーと種類に関するページを参照してください。 - 宣言型構文 - 作成するために一連のプログラミング コマンドを記述しなくても、"作成しようとしているもの" を明確に宣言できる構文。 ARM テンプレートや Bicep ファイルは、宣言型構文の例です。 これらのファイルで、Azure にデプロイするインフラストラクチャのプロパティを定義します。
- ARM テンプレート - リソース グループ、サブスクリプション、管理グループ、またはテナントにデプロイする 1 つ以上のリソースを定義する JavaScript Object Notation (JSON) ファイル。 このテンプレートを使えば、リソースを一貫して繰り返しデプロイできます。 テンプレートのデプロイの概要に関するページを参照してください。
- Bicep ファイル - Azure リソースを宣言によってデプロイするためのファイル。 Bicep は、Azure 内のコードとしてのインフラストラクチャ ソリューションに最適な作成エクスペリエンスを提供するように設計された言語です。 Bicep の概要に関する記事を参照してください。
- 拡張リソース - 他のリソースに機能を追加するリソース。 たとえば、ロールの割り当ては拡張リソースの一種です。 ロールの割り当てを他のリソースに適用して、アクセスを指定します。 拡張リソースに関する記事を参照してください。
Azure の用語の詳細については、「Azure 基礎の概念」を参照してください。
Resource Manager には、いくつかの利点があります
Resource Manager を使用すると、以下のことができます。
スクリプトではなく宣言型のテンプレートを使用してインフラストラクチャを管理します。
ソリューションのリソースを個別に処理するのではなく、すべてのリソースをグループとしてデプロイ、管理、監視します。
ソリューションを開発のライフサイクル全体で再デプロイします。リソースは、必ず一貫した状態でデプロイされます。
正しい順序でデプロイされるように、リソース間の依存関係を定義します。
Azure ロールベースのアクセス制御 (Azure RBAC) が管理プラットフォームにネイティブ統合されるため、すべてのサービスにアクセス制御を適用できます。
タグをリソースに適用し、サブスクリプションのすべてのリソースを論理的に整理します。
同じタグを共有するリソース グループのコストを表示することで、組織の課金をわかりやすくします。
スコープを理解する
Azure には、管理グループ、サブスクリプション、リソース グループ、およびリソースという 4 つのレベルの管理スコープが用意されています。 次の図に、これらのレイヤーの例を示します。
これらのスコープ レベルのいずれかに管理設定を適用します。 選択するレベルで、設定の適用範囲が決まります。 上位レベルの設定が下位レベルに継承されます。 たとえば、サブスクリプションにポリシーを適用すると、そのポリシーはサブスクリプション内のすべてのリソース グループとリソースに適用されます。 リソース グループにポリシーを適用すると、そのポリシーはリソース グループとそのすべてのリソースに適用されます。 ただし、別のリソース グループにそのポリシー割り当てはありません。
ID とアクセスの管理の詳細については、Microsoft Entra ID に関するページを参照してください。
テンプレートは、テナント、管理グループ、サブスクリプション、またはリソース グループにデプロイすることができます。
リソース グループとは
リソース グループは、Azure ソリューションの関連リソースを保持するコンテナーです。 リソース グループを使用すると、関連するリソースに対する変更を調整できます。 たとえば、リソース グループに更新プログラムをデプロイし、調整された操作でリソースが更新されるという確信を持つことができます。 または、ソリューションの使用が完了したら、リソース グループを削除し、すべてのリソースが削除されていることを確認できます。
リソース グループを定義する際、次のような考慮すべき要素があります。
リソース グループ内のすべてのリソースで、同じライフサイクルが共有される必要がある。 そのため、これらのリソースは一緒にデプロイ、更新、削除されます。 サーバーなどの 1 つのリソースが、別のデプロイ サイクル上に存在する必要がある場合は、別のリソース グループに含めなければなりません。
各リソースが所属できるリソース グループは 1 つに限られます。
リソースは、いつでもリソース グループに追加したり、削除できる。
あるリソース グループから別のリソース グループへリソースを移動できる。 詳細については、「 新しいリソース グループまたはサブスクリプションへのリソースの移動」を参照してください。
リソース グループ内のリソースは、リソース グループとは異なるリージョンに配置できますが、同じ場所を使用することをお勧めします。 「リソース グループにはどのような場所を使用する必要がありますか?」を参照してください。
リソース グループを使用すると、管理操作のアクセス制御のスコープを設定できる。 リソース グループを管理するために、Azure ポリシー、Azure のロール、またはリソース ロックを割り当てることができます。
リソース グループにタグを適用できます。 リソース グループ内のリソースは、これらのタグを継承しません。
リソースは、他のリソース グループ内のリソースに接続できます。 このシナリオは、2 つのリソースが関連を持っていても、同じライフサイクルを共有していない場合に一般的です。 たとえば、別のリソース グループ内のデータベースに接続している Web アプリがある場合があります。
リソース グループを削除すると、リソース グループ内のすべてのリソースも削除されます。 Azure Resource Manager によってこれらの削除がどのように調整されるかについては、「Azure Resource Manager のリソース グループとリソースの削除」を参照してください。
各リソース グループには、リソースの種類のインスタンスを最大 800 個までデプロイできます。 一部のリソースの種類は、800 インスタンスの制限から除外されています。 詳細については、「リソース グループの制限」を参照してください。
リソース グループの外部に存在するリソースもある。 これらのリソースは、サブスクリプション、管理グループ、またはテナントにデプロイされます。 これらのスコープでは、特定のリソースの種類のみがサポートされます。
リソース グループを作成するには、ポータル、PowerShell、Azure CLI、または ARM テンプレートを使用できます。
リソース グループにはどのような場所を使用する必要がありますか?
リソース グループを作成するとき、その場所を指定する必要があります。
"なぜリソース グループに場所が必要なのか。 リソースがリソース グループとは異なる場所に存在してよいとしたら、いったいなぜリソース グループの場所が問題になるのか" と、疑問に思われるかもしれません。
リソース グループには、リソースについてのメタデータが格納されます。 リソース グループの場所を指定するとき、このメタデータが格納される場所を指定することになります。 コンプライアンス上の理由から、データは特定のリージョンに格納されるようにする必要があります。
リソース グループの状態の一貫性を確保するために、すべてのコントロール プレーン操作はリソース グループの場所を介してルーティングされます。 リソース グループの場所を選択するときは、コントロール操作の発生元に近い場所を選択することをお勧めします。 通常、この場所は現在の場所に最も近い場所です。 このルーティング要件は、リソース グループのコントロール プレーン操作にのみ適用されます。 アプリケーションに送信される要求には影響しません。
リソース グループのリージョンが一時的に利用できない場合、メタデータが使用できないため、リソース グループ内のリソースを更新できない可能性があります。 他のリージョン内のリソースは引き続き期待通りに機能しますが、それらを更新することはできなくなります。 この状況は、Azure DNS、Azure DNS Private Zones、Azure Traffic Manager、Azure Front Door などのグローバル リソースにも当てはまる場合があります。 Azure Resource Graph リソース テーブルの種類の一覧で、どの種類のメタデータが Azure Resource Manager によって管理されているかを確認できます。
リージョン停止の影響を軽減するために、リソース グループと同じリージョンにリソースを配置することをお勧めします。 リソース グループのリージョンが利用できない場合、Azure Resource Manager によってリソースのメタデータを更新することができず、書き込み呼び出しがブロックされる可能性があります。 リソースとリソース グループのリージョンを同じ場所に配置すると、複数のリージョンではなく 1 つのリージョンにリソースとメタデータが存在するため、リージョンが使用できなくなるリスクが軽減されます。
信頼性の高いアプリケーションの設計の詳細については、「信頼性の高い Azure アプリケーションの設計」を参照してください。
Azure Resource Manager の回復性
Azure Resource Manager サービスは、回復性と継続的な可用性を実現するよう設計されています。 REST API での Resource Manager とコントロール プレーン操作 (management.azure.com に送信される要求) は、次のように動作します。
リージョン間に分散されます。 Azure Resource Manager は、Azure の各リージョンに個別のインスタンスを持っています。つまり、あるリージョンでの Azure Resource Manager インスタンスの障害は、Azure Resource Manager や別のリージョン内の他の Azure サービスの利用可能性には影響しません。 Azure Resource Manager は複数のリージョンに分散されますが、一部のサービスはリージョン限定です。 この区別は、コントロール プレーン操作の最初の処理には回復性がある一方で、サービスに転送されるときには要求がリージョンの停止の影響を受ける可能性があることを意味します。
複数の可用性ゾーンを含む場所では、可用性ゾーン (およびリージョン) 間で分散されます。 この分散により、リージョンで 1 つ以上のゾーンが失われたときに、Azure Resource Manager は別のゾーンまたは別のリージョンにフェールオーバーして、リソースに対してコントロール プレーン機能を提供し続けることができます。
単一の論理データ センターに依存しません。
メンテナンスのために休止することはありません。
この回復性は、Resource Manager 経由で要求を受信するサービスに適用されます。 たとえば、Key Vault はこの回復性からメリットを得られます。
同時実行操作を解決する
複数の操作で同じリソースを同時に更新しようとすると、Azure Resource Manager は競合を検出し、1 つの操作についてのみ、正常に完了することを許可します。 Azure Resource Manager は他の操作をブロックし、エラーを返します。
リソースを同時に更新すると、予期しない結果になる可能性があります。 この解決策により、更新を確定的で確実にすることができます。 リソースの状態を把握し、不整合やデータ損失を回避することができます。
同じリソースを同時に更新しようとする 2 つの要求 (A と B) があるとします。 要求 A が要求 B より前に完了した場合、要求 A は成功し、要求 B は失敗します。 要求 B は 409 エラーを返します。 このエラー コードを受け取った後、リソースの更新された状態を取得し、要求 B を再送信するかどうかを決定できます。
次のステップ
Azure のサービス全体に該当する制限については、「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照してください。
リソースの移動の詳細については、「新しいリソース グループまたはサブスクリプションへのリソースの移動」を参照してください。
リソースにタグを付ける方法については、「タグを使用した Azure リソースの整理」を参照してください。
リソースのロックについては、「意図しない変更を防ぐためのリソースのロック」を参照してください。