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