リソースの整合性の意思決定ガイド

Azure のサブスクリプション設計では、組織の構造、会計実務、ワークロードの要件に関連してクラウド資産をどのように編成するかを定義します。 このレベルの構造に加え、クラウド資産全体にわたって組織のガバナンス ポリシー要件に対応するために、サブスクリプション内のリソースを一貫して整理、デプロイ、管理する機能が必要です。

複雑さが最小から最大までのリソースの整合性オプションを表わした図 (対応するジャンプ リンクを下に掲載)

ジャンプ先:基本的なグループ化 | デプロイの整合性 | ポリシーの整合性 | 階層的な整合性 | 整合性の自動化

クラウド資産のリソース整合性要件のレベルに関する意思決定を左右する主な要因: 移行後のデジタル資産のサイズ、既存のサブスクリプション設計方法にうまく適合しないビジネスまたは環境の要件、リソースがデプロイされた後に時間の経過と共にガバナンスを適用する必要性。

これらの要因の重要性が増すにつれて、クラウドベースのリソースを一貫してデプロイ、グループ化、管理することのベネフィットの重要性も増します。 増加する要件を満たすために、より高度なレベルのリソース整合性を実現するには、自動化、ツールの使用、整合性の適用により多くの作業が必要になります。 この作業の結果、変更管理と進捗管理に費やす時間が増えます。

基本的なグループ化: リソース グループ

Azure では、リソース グループはサブスクリプション内でリソースを論理的にグループ化するリソース編成のコア メカニズムです。

リソース グループは、共通のライフサイクルおよび、ポリシーや Azure ロールベースのアクセス制御の要件などの共有管理の制約があるリソースのコンテナーとして使用できます。 リソース グループを入れ子にすることはできません。また、リソースは 1 つのリソース グループにのみ属することができます。 すべてのコントロール プレーン アクションは、リソース グループ内のすべてのリソースに影響します。 たとえば、リソース グループを削除すると、そのグループ内のすべてのリソースも削除されます。

リージョンのリソース組織を設計または更新する場合は、次の要因を考慮してください。 次に当てはまるリソースの論理グループはありますか?

  • 一緒に開発することができる
  • 一緒に管理、更新、監視できる それらのタスクは、同じユーザーまたはチームにより実行できる
  • 1 つのチームが 1 つの地域/リージョン内で使用している
  • 一緒に廃止することができる

これらの質問のいずれかに対する回答がはいの場合は、それらのリソース (リージョン X にデプロイ) をリソース グループ (これらもリージョン X にデプロイ) にまとめて配置することを検討してください。

リージョンの停止の影響を最小限に抑えるために、リソース グループと同じリージョンにリソースを配置することをお勧めします。 詳細については、「リソース グループの場所の配置」を参照してください。

Note

同じリソース グループ内の異なるリージョンにリソースがある場合は、リソースを新しいリソース グループまたはサブスクリプションに移動することを検討してください。

リソースが別のリソース グループへの移行をサポートしているかどうかを判断するには、リソースを相互参照して一覧を作成します。 適切な前提条件を満たしていることを確認してください。

ヒント

Azure Policy を使用してリソース グループの配置を監査します。 を中間ルート管理グループ レベルビルトイン Azure Policy 定義を割り当て、テナント階層内のリソースの場所がそれぞれのリソース グループの場所と一致するかどうかを確認します。

デプロイの整合性

基本的なリソース グループ化メカニズムの上に構築されている Azure プラットフォームは、テンプレートを使用してクラウド環境にリソースをデプロイするためのシステムを提供します。 ワークロードのデプロイ時に、テンプレートを使用して一貫性のある組織と名前付け規則を作成できます。 テンプレートにより、リソースのデプロイと管理の設計におけるこれらのアスペクトが強化されます。

Azure Resource Manager テンプレートを使用すると、事前に定義された構成とリソース グループの構造体を使用して一貫した状態でリソースを繰り返しデプロイすることができます。 Resource Manager テンプレートを使用して、デプロイの基礎として標準のセットを定義できます。

たとえば、標準テンプレートを使用して、ロード バランサーと結合した Web サーバーとして 2 つの仮想マシンを含む Web サーバー ワークロードをデプロイし、サーバー間のトラフィックを均等配置できます。 その後、このテンプレートを再利用して、構造的に同一の仮想マシンのセットを作成できます。 この種類のワークロードが必要な場合はいつでも VM にはロード バランサーがあり、関連するデプロイ名と IP アドレスを変更するだけで作成できます。

プログラムでこれらのテンプレートをデプロイして、CI/CD システムと統合することもできます。

ポリシーの整合性

リソース グループ設計の一部には、リソースをデプロイするときに共通の構成を使用することが含まれます。 共通の構成を使用すると、リソースが作成されるときにガバナンス ポリシーが確実に適用されます。

リソース グループと標準化された Resource Manager テンプレートを組み合わせることで、デプロイに必要な設定の標準と、リソース グループまたはリソースそれぞれに適用する Azure Policy 規則の標準を適用できます。

たとえば、サブスクリプション内にデプロイされたすべての仮想マシンが、中央の IT チームによって管理されている共通のサブネットに接続するという要件があるとします。 ワークロード VM をデプロイするための標準的なテンプレートを使用します。このテンプレートにより、ワークロードの別のリソース グループが作成され、必要な VM がそこにデプロイされます。 このリソース グループには、共有サブネットに参加するリソース グループ内のネットワーク インターフェイスのみを許可するポリシー規則があります。

クラウド デプロイ内でのポリシーの決定の適用に関する詳細については、ポリシーの適用をご覧ください。

階層的な整合性

リソース グループを使用すると、サブスクリプション内の組織内で追加の階層レベルをサポートできます。 階層は、リソース グループ レベルで Azure Policy の規則とアクセスの制御をサポートします。 クラウド資産のサイズ拡大に合わせて、さらに複雑なサブスクリプション間ガバナンス要件のサポートが必要となる場合があります。 Azure エンタープライズ契約の企業、部署、アカウント、サブスクリプションの各階層を使用します。

Azure 管理グループ を使用すると、サブスクリプションをより高度な組織構造体に編成することができます。 サブスクリプションをエンタープライズ契約の階層と異なる階層にグループ化できます。 この代替階層では、複数のサブスクリプションと各サブスクリプションに含まれるリソースにまたがって、アクセスの制御とポリシー実施のメカニズムを適用できます。 管理グループ階層を使用して、クラウド資産のサブスクリプションを運用やビジネス ガバナンスの要件に一致させることができます。 詳細については、「サブスクリプション決定ガイド」を参照してください。

整合性の自動化

大規模なクラウド デプロイでは、グローバル ガバナンスがさらに重要で複雑になります。 リソースをデプロイするときにガバナンスの要件を自動的に適用して強制することと、既存のデプロイに対する更新された要件を満たすことは非常に重要です。

Azure Blueprints を使用すると、組織で Azure 内の大規模なクラウド資産のグローバル ガバナンスをサポートできます。 Blueprints は、標準の Azure Resource Manager テンプレートで提供される機能を超えています。 Blueprints はリソースのデプロイとポリシー規則の適用が可能な完全なデプロイ オーケストレーションを作成します。 Blueprints では、バージョン管理、ブループリントが使用されていたすべてのサブスクリプションを更新する機能、デプロイされたサブスクリプションをロックしてリソースの不正な作成および変更を回避する機能がサポートされています。

これらの展開パッケージを使用すると、IT チームと開発チームが、変化する組織のポリシー要件に準拠する新しいワークロードとネットワーク資産を迅速にデプロイできます。 開発チームは、ブループリントを CI/CD パイプラインに統合して、デプロイの更新時に、改訂されたガバナンス標準をそれらのデプロイに適用することもできます。

次のステップ

リソースの整合性は、クラウド導入プロセスでのアーキテクチャに関する意思決定で要求されるコア インストラクチャ コンポーネントの 1 つにすぎません。 アーキテクチャの決定ガイドの概要を参照して、さまざまな種類のインフラストラクチャの設計に関する決定を行うときに使用されるパターンとモデルを確認してください。