私はAzureアーキテクチャに不慣れで、Azureで構築されたアプリケーションの論理デプロイバケットであるAzureリソースグループが、定義時にリージョンに関連付けられる理由を理解しようとしています。
最初は、災害復旧または地理的冗長性のためのグローバルな配布を提供することだと思っていましたが、単一のリソースグループに、Traffic Managerを介してこれらの機能を提供できるさまざまなリージョンのWebアプリを含めることができることに気付きました。個別のリソースグループを使用すると、どのリソースがどのリージョンにあるかを識別しやすくなると思いますが、組織上の目的以外では、リソースグループのリージョン定義が何を意味するのか理解できません。
(編集:より集中するために一般的なアドバイスクエリを削除)
リソースグループの場所を指定する主な理由は、デプロイが格納されるデータ/メタデータの場所を指定することです...これにより、APIの一貫性も確保されます(REST APIのパスを考えてください)呼び出し)が、主な理由は展開時のストレージです。
グループ内のリソースの場所は独立しており、グループ自体の場所とは関係ありません。
リソースグループは基本的に、アプリケーション内のどのリソースをまとめて管理するかを決定するためのものであり、管理することで、リソースをグループとしてデプロイ、管理、監視するので、高レベルではそれらを個別のコンポーネントとして表示しません。
一般に、大きなエコシステムでは、Azureリソースグループは、それらのコンポーネント(リソース)が個別のエンティティとして表示されないものであり、単一のエンティティの関連する相互依存部分として表示されるため、1つのリソースグループに配置しますAzure Resource Group Managerツールを使用して、アプリケーションのすべてのリソースを単一の調整された操作でデプロイ、更新、または削除できます。
デプロイにはテンプレートを使用し、そのテンプレートはテスト、ステージング、本番などのさまざまな環境で機能します。グループ全体のロールアップされたコストを表示することで、組織の請求を明確にすることができます。
Azureリソースマネージャーの詳細については、こちらをご覧ください。Azureリソースグループの背後にある考え方を理解するのに役立つと思います。
https://Azure.Microsoft.com/en-us/documentation/articles/resource-group-overview/
Azureリソースグループのメタデータ(定義)は、どこかに保存する必要があります。したがって、場所。ただし、リソースグループ内のリソースは場所に依存せず、別のリージョン/場所に配置できます。リソース間の依存関係が存在する可能性があることに注意してください。西ヨーロッパの仮想マシンは、明らかに西ヨーロッパにもストレージアカウントを必要としますが、同じリソースグループ内のSQLデータベースを米国西部に存在させることができます。
リソースグループを作成するときは、そのリソースグループの場所を指定する必要があります。 「リソースグループに場所が必要なのはなぜですか。リソースにリソースグループとは異なる場所を指定できるのに、リソースグループの場所がまったく重要なのはなぜですか?」リソースグループには、リソースに関するメタデータが格納されます。したがって、リソースグループの場所を指定するときは、そのメタデータが格納される場所を指定します。コンプライアンス上の理由から、データが特定のリージョンに保存されていることを確認する必要がある場合があります。
https://docs.Microsoft.com/en-us/Azure/azure-resource-manager/resource-group-overview
Azureのすべては物理的な場所/データセンターに関連しており、ARMは違いはありません。少し前まで、すべてのデータセンターがARMをサポートしているわけではないため、選択する理由がより理にかなっています。今、その他のAzureリソースの場合、決定はユーザーが行う必要があります。多くの場合、エンドユーザーへの必要な近接性や法的な地理的要件に基づいています。
リソースグループが作成された後、リソースグループがどのリージョンにあるかを判別する明確な方法はないようです。これは、CDNメタデータの競合に関する問題に遭遇したとき、ここでの議論に従って私を悲しませました。最初からやり直さなければならなかった。次に、リージョンにリソースグループの名前を付けます。例:my-resourcegroup-westus