Azure ランディング ゾーンでのアプリケーション開発環境の管理
この記事では、クラウド プラットフォーム チームがガードレールを実装して Azure ランディング ゾーンのアプリケーション環境を管理する方法について説明します。 また、さまざまなアプリケーション開発環境をフレームワークに合わせる方法についても説明します。 適切な環境を作成する際の重要な側面は、適切な管理グループにサブスクリプションを配置することです。
基盤を設定する
開発チームには、迅速に反復する機能が必要です。クラウド ガバナンスチームとプラットフォーム チームは、組織のリスク、コンプライアンス、セキュリティを大規模に管理する必要があります。 ポリシー駆動型のガバナンスとサブスクリプションの一般化という 2 つの主要な Azure ランディング ゾーン設計原則に焦点を当てることで、アプリケーション環境を適切に管理できます。 これらの原則は、基本的なガードレールを提供し、アプリケーション チームに制御を委任する方法を説明します。 アプリケーション チームは、Azure Well-Architected フレームワーク ガイダンスを使用してワークロードを設計します。 独自のランディング ゾーン リソースをデプロイして管理し、プラットフォーム チームは Azure ポリシーを割り当てることでリソースを制御します。
アプリケーション チームがテクノロジと機能をテストすることができるように、半管理リソースにサンドボックス リソースを提供することが重要です。
アプリケーション所有者がサブスクリプション サービスまたはその他のサブスクリプション作成プロセスを使用する場合、複数の開発環境のサブスクリプションを要求する方法を知っている必要があります。
この記事では、管理グループ、ポリシー、共有プラットフォーム アーキテクチャ、ワークロードまたはアプリケーションランディング ゾーンなどの、Azure ランディング ゾーンについて説明します。
Note
この記事のガイダンスは、ワークロードまたはアプリケーションのランディング ゾーンのみを対象としています。 Azure ランディング ゾーン プラットフォーム自体のテストと環境の分離については、カナリア アプローチについて説明する 「Azure ランディング ゾーンのテスト アプローチ」を参照してください。
実際には、任意の数と種類の段階的な環境を使用できます。 この記事では、次の段階的な環境について説明します。
| 環境 | 説明 | 管理グループ |
|---|---|---|
| サンドボックス | プロトタイプの迅速なイノベーションに使用されるが、運用環境にバインドされた構成には使用されない環境 | サンドボックス管理グループ |
| 開発 | 潜在的なリリース候補の構築に使用される環境 | corp や online などの原型管理グループ |
| テスト | 単体テスト、ユーザー受け入れテスト、品質保証テストなど、テストの実行に使用される環境 | corp や online などの原型管理グループ |
| 運用 | 顧客に価値を提供するために使用される環境 | corp や online などの原型管理グループ |
詳細については、「アプリケーション ワークロードの開発、テスト、運用環境の処理」のビデオと、「Azure で使用する必要があるサブスクリプションの数」のビデオを参照してください。
環境、サブスクリプション、管理グループ
このセクションの前提条件として、「リソース組織の設計領域」を参照してください。
Azure ランディング ゾーンのプラクティスを採用するときは、サブスクリプションを適切に整理する必要があります。 理想的には、各アプリケーション環境にはそれ独自のサブスクリプションが必要です。 このメソッドは、環境を分離するセキュリティとポリシーの制御を提供します。 これには、1 つの環境に対する潜在的な問題が含まれています。
個別のサブスクリプションには、アーキタイプ レベルで同じポリシーがあります。 必要に応じて、アプリケーション所有者はサブスクリプション固有のポリシーを割り当てて、アプリケーションと環境固有の動作を適用できます。
一部のアプリケーション アーキテクチャでは、サービスを環境間で共有する必要があります。 その場合は、複数の環境に 単一サブスクリプションを使用できます。 ワークロードの所有者は、クラウド プラットフォーム チームと協力して、複数の環境に対して 単一サブスクリプションが必要かどうかを判断することをお勧めします。
次の場合は、複数のアプリケーション環境で 単一サブスクリプションを使用します。
環境を独自のサブスクリプションに分離することはできません。
環境には、ネットワークオペレーターなどの機能ロールに同じチームが割り当てられます。
この環境では、同じポリシーを使用できます。
アプリケーションまたはサービスのワークロードを 単一サブスクリプションに含める必要があり、各環境に適用されるポリシーを変更する必要がある場合は、次のことができます。
ランディング ゾーン管理グループの下に、アーキタイプにアラインメントされた新しい管理グループを作成します。 詳細については、この記事の「管理グループの階層」セクションを参照してください。
開発アクティビティにはサンドボックス サブスクリプションを使用します。 サンドボックスには、制限の少ないポリシー セットがあります。
管理グループ レベルではなく、サブスクリプション レベルで適用されるポリシーを使用します。 ポリシー定義でタグを使用すると、フィルター処理して適切な環境に適用できます。 また、ポリシーを特定のリソース グループに割り当てたり、特定のリソース グループから除外したりすることもできます。
サブスクリプションの作成プロセス中に、サブスクリプション サービスの一部としてポリシーを割り当てることができます。
コストの制御に役立つポリシーを実装する場合は、必要に応じてサブスクリプション レベルでポリシー定義を適用します。 または、ランディング ゾーンの所有者にコストを担当させ、真の自律性を提供することもできます。 詳細については、「プラットフォームの自動化と DevOps」を参照してください。
警告
管理グループ レベルのポリシーと制御とは異なり、サブスクリプションベースのポリシーとタグは、サブスクリプションに対する昇格されたアクセス許可を持つ個人によって変更できます。 適切なロールを持つ管理イストレーターは、ポリシーを除外したり、ポリシーを変更したり、リソースのタグを変更したりすることで、これらの制御をバイパスできます。
そのため、セキュリティに重点を置いたポリシーの定義にタグを適用しないでください。 また、次のアクションでは、常にアクティブなアクセス許可を割り当てないでください。
Microsoft.Authorization/policyAssignments/*Microsoft.Authorization/policyDefinitions/*Microsoft.Authorization/policyExemptions/*Microsoft.Authorization/policySetDefinitions/*
これらのアクションは、Privileged Identity Management (PIM) を使用して制御できます。
管理グループの階層
複雑な管理グループ階層を避けます。 頻繁な変更、非効率的なスケーリング、価値の欠如が必要な場合があります。 このような潜在的な問題を回避するために、Azure ランディング ゾーン管理グループはワークロードのアーキタイプにアラインされています。 詳細については、「管理グループとサブスクリプションの組織」を参照してください。
「アーキタイプに合わせて調整 」とは、管理グループが異なるワークロード アーキタイプに対してのみ作成されることを意味します。 たとえば、概念アーキテクチャでは、ランディング ゾーン 管理グループには [corp] と [online] の子管理グループがあります。 これらの子管理グループは、それらが保持するワークロードの個別のアーキタイプ パターンに合わせて調整されます。 子管理グループは、内部接続と公開アプリケーションとサービスの比較など、ハイブリッド接続 (VPN/Azure ExpressRoute) の要件に重点を置きます。
サンドボックス環境を除き、さまざまなアプリケーション環境でデプロイに同じアーキタイプを使用する必要があります。 環境が複数のサブスクリプションに分割されている場合でも、管理グループのアーキタイプと要件に基づいて、同じ単一の管理グループ (corp または online) 内に保持されます。
サンドボックス サブスクリプションは、個人ラボなどの非構造化開発や、アーキタイプを持たないワークロードに使用できます。 アプリケーションまたはサービス ワークロード チームは、サンドボックス管理グループを使用して、さまざまな Azure サービスをテストして、要件に最適なものを判断します。 サービスを決定すると、(ランディング ゾーン 管理グループ階層内の適切なワークロード アーキタイプに合わせて調整された管理グループ内で) ランディング ゾーンをチームが使えるように設定できます。
サンドボックス環境は、特定のアプリケーションに使用することも、ワークロード チームが実験に使用することもできます。
詳細については、以下を参照してください:
環境ベースの管理グループの課題
アーキタイプ内の環境の管理グループは、管理オーバーヘッドを追加し、極小値を提供できます。
ランディング ゾーン 管理グループ には、corp と online の両方にガードレールを適用するユニバーサル ポリシーが必要です。 Corp と online には、パブリックおよびプライベート側のワークロードに関する会社のガイドラインを適用するための独自のポリシーがあります。
多くの組織では、ワークロード ソフトウェア開発ライフサイクル (SDLC) 環境用に個別の管理グループを作成して、環境ポリシーと制御を割り当てます。 実際には、このメソッドは、ワークロード チームが解決するよりも多くの課題を生み出します。 SDLC 環境には異なるポリシーを設定しないでください。そのため、個別の管理グループはお勧めしません。
アプリケーション所有者は、昇格された複数の SDLC 環境のポリシーに合わせて、ワークロードのトポロジまたはリソース構成を変更できます。 この方法により、リスクが高まります。 各環境に固有のルールにより、結果的に開発者および品質保証チームの開発エクスペリエンスが低下する可能性があります。 また、アプリケーションに 1 つの環境で動作するガードレール ポリシーのセットが 1 つあり、その昇格サイクルの後半でアプリケーションが別のポリシー セットに公開されている場合にも問題が発生する可能性があります。 コントロールが変更された場合は、アプリケーションの調整が必要になる場合があります。
この余分な作業を防ぐために、SDLC 環境でのコードの昇格全体で一貫したポリシーを作成します。 環境ごとにポリシーを作成するのではなく、サンドボックス環境を除くすべての開発環境に一貫性のあるセットを提供する必要があります。
たとえば、組織が、パブリック ネットワークからのイングレスを防ぐために、ストレージ アカウントを特定のファイアウォール規則で構成する必要があるポリシーを定義しているとします。 代わりに、ストレージ アカウントは、通信のために Azure ランディング ゾーン ネットワーク内のプライベート エンドポイントを使用します。 開発環境にそのようなポリシーがない場合、ワークロードをテストしても、パブリック アクセスを許可するストレージ アカウントの構成の誤りが検出されません。 テストデプロイは開発環境で動作し、反復処理されます。 ソリューションがストレージ アカウント ポリシーを持つ別の環境に昇格されると、ポリシーが適用されたため、デプロイは失敗します。
その結果、アプリケーション開発チームは、既に多大な労力を費やした後、デプロイとアーキテクチャを見直す必要があります。 この例では、さまざまな環境のさまざまなポリシーで問題が発生する方法を示します。
Note
次の式は、環境またはワークロードごとの管理グループがうまくスケーリングできない理由を明らかにするのに役立ちます。N 個のワークロード x Z 個の管理グループ = 管理グループの合計。
開発、テスト、運用環境に対して管理グループと子管理グループが必要なワークロードが組織に 30 個ある場合、組織は次の作業を行う必要があります。
N = ワークロード/アプリの数 = 30
Z = ワークロードと環境の管理グループの数 (ワークロードは 1 個 + 環境は 3 個) = 4
N (30) x Z (4) = 120 個の合計管理グループ
アプリケーションの所有者は、複数の環境に異なる方法で適用するポリシーが必要になる場合があります。 たとえば、アプリケーションの所有者が実稼働環境のバックアップ構成を必要とする場合がありますが、他の環境では必要ありません。
一部のポリシーは、管理グループ レベルで監査ポリシーとして有効にすることができます。 アプリケーション チームは、コントロールを実装する方法を決定します。 この方法ではデプロイが妨げられませんが、認識が作成され、アプリケーション チームが独自のニーズを管理できるようになります。 その後、サブレベル ポリシーを作成したり、これらの要件をコードとしてのインフラストラクチャ (IaC) デプロイ モジュールに組み込んだりできます。
この共有責任モデルでは、プラットフォーム チームがプラクティスを監査し、アプリケーション チームが実装を管理します。 このモデルにより、デプロイの機敏性を向上させることができます。
プラットフォームオペレーターは、各アプリケーションまたはサービス ワークロード チーム (ランディング ゾーン所有者) と協力して、要件を理解することをお勧めします。 プラットフォームオペレーターは、アプリケーションの要件と計画に基づいてサブスクリプションを提供できます。 また、アプリケーションまたはサービス ワークロード チームの共通の要件に基づいてサブスクリプション作成プロセスとツールを構築できるよう、さまざまな種類のワークロードに製品ラインを指定することもできます。
シナリオ: 仮想マシン (VM) ベースのワークロード
Azure ランディング ゾーンの初期ワークロードは、多くの場合、Azure VM で構成されます。 これらのワークロードは、Azure にデプロイすることも、既存のデータセンターから移行することもできます。
1 つのサブスクリプション内の複数の環境に VM をデプロイする代わりに、次のことができます。
各アプリケーション環境のサブスクリプションを確立し、それらすべてを同じアーキタイプ管理グループに配置します。
適切なサブスクリプション内のアプリケーション環境ごとに仮想ネットワークをデプロイします。 仮想ネットワークのサイズは、アプリケーション環境のサイズに基づいて決定できます。
VM を適切なサブスクリプションにデプロイします。 VM では、必要に応じて、環境ごとに異なる SKU と異なる可用性構成を使用できます。
さまざまなアプリケーション環境リソースは、さまざまなアクセス制御によって保護されます。 その結果、アプリケーション開発者がデプロイ パイプラインを設定すると、各パイプラインの ID を環境に制限できます。 この構成は、偶発的なデプロイから環境を保護するのに役立ちます。
シナリオ: Azure App Service
App Service を使用する環境サブスクリプションを持つワークロードでは、課題が発生する可能性があります。 アプリケーション開発者にとって、App Service ベスト プラクティスとは、デプロイ スロットを使用して、Web アプリの変更と更新を管理できるようにすることです。
ただし、この機能は、App Service プランのアプリでのみ使用でき、単一サブスクリプション内でのみ有効です。 プラットフォームオペレーターが、アプリケーション所有者が開発、テスト、運用環境に個別のサブスクリプションを使用することを義務付けている場合、アプリケーションのデプロイ ライフサイクルの管理が難しくなる可能性があります。
この例では、最適なオプションは、アプリケーションまたはサービス ワークロードの 単一サブスクリプションです。 アプリケーション所有者は、セキュリティを強化するために、リソース グループ レベルで PIM で Azure ロールベースのアクセス制御 (RBAC) を使用できます。
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示