一般的なサブスクリプションサービスの製品ラインを確立する

[アーティクル]
06/20/2024

サブスクリプションサービスは、組織が Azure 環境の一貫したスケーリング、セキュリティ、ガバナンスに不可欠な Azure ランディングゾーンのサブスクリプションの民主化設計原則を実現するのに役立ちます。サブスクリプションサービスは、組織がプラットフォームエンジニアリングの原則に沿うのにも役立ちます。詳細については、「製品マインドセットを導入する」と「ガードレールを使用したセルフサービスにより開発者を支援する」を参照してください。

多くの組織は、アプリケーションチームにワークロードとサービスを効果的に提供するために必要な柔軟性を提供することに苦労しています。重要な障害の 1 つは、サブスクリプションサービスに対する標準化されたアプローチの欠如であり、混乱、遅延、非効率性につながる可能性があります。

この記事では、プラットフォームチームが、さまざまなアプリケーションチームの多様なニーズに対応する一般的なサブスクリプションサービスの製品ラインを確立する方法について説明します。この記事では、さまざまな製品ラインを提供する利点について説明し、実際の顧客のデプロイに基づく一般的なシナリオの例を示します。また、サブスクリプションサービスに "すべてに適合する" 設計がない理由と、アプリケーションチームにさまざまな製品ラインを提供する必要がある理由についても説明します。

次の図は、Azure 環境内の管理グループとサブスクリプションの編成を示しています。

次のガイダンスでは、さまざまな製品ラインが必要になる理由について説明し、Azure ランディングゾーンとサブスクリプションサービスを使用した顧客向けの製品ラインの例について説明します。

さまざまな製品ラインを活用する

アプリケーションチームがワークロードとサービスを提供するために必要なサブスクリプションには、さまざまな種類とスタイルがあります。アプリケーションチームの外部では、さまざまなコンプライアンスやデータ処理ルール、アーキテクチャパターンなど、Azure サブスクリプションの使用を必要とするその他の要件が組織にある場合があります。

サブスクリプションサービスの設計と実装に対する組織のアプローチを決定する場合は、次の質問をすることを検討してください。

プラットフォームチームは、サブスクリプションサービスプロセスの一環として他にどのようなリソースを販売する必要がありますか?
アプリケーションチームごとに、環境ごとに 1 つなど、複数のサブスクリプションを既定でデプロイしますか?
すべてのアプリケーションについて、スポーク仮想ネットワークを既定で接続ハブにピアリングまたは接続し直しますか?
各サブスクリプション内でロールベースのアクセス制御 (RBAC) をどのように構成する必要がありますか?
サブスクリプション内で使用するアーキテクチャ (アーキタイプ) のリソースとスタイルをどのように管理および制御する必要がありますか?

自販する単一のサブスクリプションの種類またはサブスクリプションスタイルを使用して、すべてのアプリケーションとプラットフォームチームの固有の要件に対処することはできません。プラットフォームチームは、アプリケーションチームに対して、セルフサービスシステムを通じて自販できるサブスクリプションの複数の種類とスタイルから柔軟に選択できるようにする必要があります。これらの種類のサブスクリプションは、製品ラインと呼ばれます。

サブスクリプションサービスに "すべてに適合する" アプローチを提供するだけの組織では、多くの場合、社内の顧客の柔軟性が制限されます。たとえば、柔軟性がない場合、アプリケーションチームのアーキテクチャ設計の選択が制限され、自販されたことが原因で侵害につながる可能性があります。

そのため、プラットフォームチームは、組織のニーズに対応するためにさまざまな製品ラインを提供する必要があります。この柔軟性により、コンシューマーは要件に最も適した製品ラインを選択できます。

アプリケーション環境を管理する

組織は、サブスクリプションサービスプロセスと実装の一部として、アプリケーションチームのアプリケーション環境を管理する必要があります。ただし、アプリケーションチームがアプリケーションを提供する際に必要な方法 (開発/テスト/運用など) をアプリケーション環境で管理できるように、柔軟性も提供する必要があります。詳細については、「環境、サブスクリプション、管理グループ」を参照してください。

一部の Azure サービスには、デプロイスロット機能を備えた Azure App Service など、単一の Azure サブスクリプション内の単一のリソースインスタンス内で環境を分離するのに役立つネイティブ機能が用意されています。この例では、アプリケーションチームが個別のサブスクリプションを使用するように強制されるため、チームは Azure が提供するサービスのすべての機能セットを利用できません。個別のサブスクリプションを使用すると、運用やメンテナンスのオーバーヘッドなど、アプリケーションの配信コストを増やすこともできます。

サブスクリプションサービスの一般的な製品ラインを設計する

プラットフォームチームが Azure プラットフォームのコンシューマーに対して複数の Azure サブスクリプションの種類とスタイル、または製品ラインを提供する必要があることは理解しているので、このセクションでは、業界や国や地域間で使用できるいくつかの一般的な製品ラインについて説明します。

プラットフォームチームは、これらの一般的なサブスクリプションサービスの製品ラインをベースラインとして使用する必要があります。チームは、顧客のプラットフォームエンジニアリングの原則に優先順位を付けるのに合わせて、すぐに使用できる複数のオプションをコンシューマーに提供できます。このアプローチにより、内部の顧客は、Azure ランディングゾーンの設計原則と設計領域の推奨事項を自由に使用してワークロードとサービスを提供できます。また、Azure プラットフォームガバナンスも提供します。

Note

これらの例を開始点として使用します。組織のニーズに合わせて、これらの製品ラインをカスタマイズおよび拡張できます。

サブスクリプションサービスの一般的な製品ラインには以下が含まれます。

企業接続済み: 接続サブスクリプションを介して他のアプリケーションやオンプレミス環境への従来のレイヤ 3 IP ルーティング接続を必要とするワークロード。
オンライン: Azure Private Link などの最新の接続サービスとアーキテクチャを介して他のアプリケーションと接続するワークロード、または各アプリケーションから公開されている API またはエンドポイントを介した対話。
技術プラットフォーム: 他のアプリケーションを構築できるプラットフォームを構築するワークロード。たとえば、AKS プラットフォームチームが管理するクラスターの Azure Kubernetes Service (AKS) フリートは、他のアプリケーションチームに代わって AKS クラスター内で他のアプリケーションをホストできます。
共有アプリケーションポートフォリオ: 密接に結合されたアプリケーションの一般的なセットに対して、同じアプリケーションチーム間で共有されたワークロード。アプリケーションを単独で、または特定のワークロードでホストしたくない。
サンドボックス: アプリケーションチームが概念実証 (PoC) または実用最小限の製品 (MVP) を構築し、より少ない制御を課すことができる領域です。そのため、チームは、利用可能な Azure サービスのカタログから可能な限り最高のアプリケーションを構築するための開発、発明、自由を促進できます。

企業接続済み製品ライン

アプリケーションランディングゾーンのサブスクリプションサービスの企業接続済み製品ライン (内部またはプライベート製品ラインとも呼ばれます) では、従来のレイヤ 3 IP メソッドを介して接続を提供します。この製品ラインを使用して、次のリソース間の接続を提供できます。

同じアプリケーションランディングゾーン内。
Azure Firewall またはネットワーク仮想アプライアンス (NVA) 経由の異なる企業接続済みアプリケーションのランディングゾーン内。
Azure ExpressRoute または VPN 接続を介したオンプレミスまたは異なるクラウド内。

サブスクリプションサービスを使用する組織では、多くの場合、この製品ラインが組み込まれています。これは、現在のほとんどのオンプレミス環境の仕組みと密接に一致しているためです。ただし、必要な場合にのみ、企業接続済み製品ラインを使用する必要があります。可能な場合は、オンライン製品ラインなど、より最新のクラウドネイティブアプローチを使用することをお勧めします。

ヒント

企業ワークロードとオンラインワークロードの違いについては、「接続、企業、オンライン管理グループの目的は何ですか?」を参照してください。

次の図は、企業接続済みサブスクリプションサービスの製品ラインの例を示しています。このセットアップは、ハブおよびスポークのネットワークモデルに使用して、ネットワークトラフィックとポリシーを効果的に管理するのに役立ちます。

企業接続済み製品ラインを使用する場合

次の場合は、企業接続済み製品ラインを使用します。

合理化の 5 R に基づいて、移行とアプリケーションビルドのリホストとリファクターを実行する必要があります。
Azure で体験を開始し、同様のオンプレミスアーキテクチャに精通している必要があります。
Azure にアプリケーションを "リフトアンドシフト" する必要があります。
アプリケーションを独自のランディングゾーンサブスクリプションに分離し、アプリケーションを完全にクラウドネイティブに再設計することなく、ゼロトラストからマイクロセグメント化の原則に移行することで、ワークロード間のセキュリティを強化する必要があります。

企業接続済み製品ラインに関するその他の考慮事項に注意してください。

プラットフォームチームは、仮想ネットワークをアプリケーションランディングゾーンサブスクリプションに自販し、仮想ネットワークをリージョンハブ仮想ネットワークまたは Azure Virtual WAN ハブにピアリングできます。その後、チームは IP アドレス管理 (IPAM) ツールを使用して、IP アドレスの割り当てを制御できます。
プラットフォームチームは、通常、サブネットやその他のリソースを仮想ネットワークに自販しません。代わりに、プラットフォームチームはこれらのアクティビティをアプリケーションチームに割り当ることで、チームはアプリケーションネットワークを好きなように設計できます。
プラットフォームチームは、サブスクリプションの上の管理グループに割り当てられた Azure ポリシーを使用して、すべてのサブネットにアタッチされた標準化されたネットワークセキュリティグループ (NSG) などの目的の動作を適用します。アプリケーションチームはこの Azure ポリシーを継承し、編集することはできません。このアプローチは、サブスクリプションの民主化の Azure ランディングゾーン設計原則に従います。

オンライン製品ライン

アプリケーションランディングゾーンのサブスクリプションサービスのオンライン製品ライン (外部またはパブリック製品ラインとも呼ばれます) では、他のアプリケーションランディングゾーン内のリソース間、または ExpressRoute または VPN 接続を介したオンプレミスのリソース間の従来のレイヤ 3 IP メソッドを介した接続は提供されません。同じオンラインアプリケーションランディングゾーンサブスクリプション内のリソースは、仮想ネットワークを使用してレイヤ 3 IP メソッドを介して相互に通信できます。ただし、通常、仮想ネットワークはリージョン接続ハブやその他のアプリケーションランディングゾーンにピアリングし直されません。

代わりに、次のリソース間のパブリックインターフェイス経由で接続を提供できます。

異なるアプリケーションランディングゾーン内。
オンプレミス。
異なるクラウド内にあるワークロード内。

アプリケーションの構築に使用するさまざまなサービスとしてのプラットフォーム (PaaS) ソリューションによって公開されるネットワーク制御、認証機能、承認機能を使用して接続をセキュリティで保護できます。

Private Link サービスと Azure プライベートエンドポイントを、オンラインアプリケーションのランディングゾーンサブスクリプション内およびオンラインアプリケーションのランディングゾーンサブスクリプション間で使用して、アプリケーション間のプライベートレイヤ 3 ベースの接続を有効にして公開できます。また、アプリケーションランディングゾーン内で使用する PaaS サービス間でこのアプローチを使用して、これらの PaaS サービスのパブリックインターフェイスをセキュリティまたは規制の制御に使用しないようにすることもできます。

プライベートエンドポイントと共に Private Link サービスを使用して、オンラインアプリケーションのランディングゾーン内でホストするアプリケーションを公開し、企業接続済みアプリケーションランディングゾーン、オンプレミスの場所、またはその他のクラウドに発行することもできます。プライベートエンドポイントは、企業接続済みアプリケーションのランディングゾーンまたは接続ハブに直接配置できます。これにより、仮想ネットワークピアリング、ExpressRoute 接続、VPN 接続などの従来のレイヤ 3 接続方法を使用して、これらのプライベートエンドポイントへのアクセスを許可できます。

オンラインアプリケーションのランディングゾーンの製品ラインは、離島と考えてください。既定では、サブスクリプション内のリソースにアクセスできるリソースは、同じオンラインアプリケーションのランディングゾーンサブスクリプション内にデプロイするリソースのみです。前述のように、この記事の手法を使用して、他のアプリケーションランディングゾーン、オンプレミスの場所、またはその他のクラウドへの接続を拡張できます。

ヒント

企業ワークロードとオンラインワークロードの違いの詳細については、「接続、企業、オンライン管理グループの目的は何ですか?」を参照してください。

次の図は、オンラインサブスクリプションサービスの製品ラインの例を示しています。

オンライン製品ラインを使用する場合

次を行う必要がある場合は、オンライン製品ラインを使用します。

合理化の 5 R に基づいて、移行とアプリケーションビルドをリファクター、再設計、再構築、実行します。
ネットワーク構成に関しても、アプリケーションチームに使用する完全に民主化されたアプリケーションランディングゾーンを提供します。
クラウドネイティブのサービスとアーキテクチャを活用します。
ゼロトラスト原則との調整を大幅に強化します。
企業接続済み製品ラインを使用しますが、プライベート IP アドレス空間は使用できないか制限されています。
- このシナリオでは、「Azure における IPv4 の枯渇の防止」のガイダンスを確認する必要があります。

技術プラットフォームの製品ライン

Azure VMware Solution や Azure Virtual Desktop などのテクノロジプラットフォームを使用するチームは、テクノロジプラットフォームの製品ラインを実装する必要があります。技術プラットフォームの製品ラインは、基本的に技術面の要件に非常に適したサブスクリプションサービスの製品ラインです。技術プラットフォームの製品ラインを使用して、通常は、組織全体の他のいくつかのアプリケーションチームに対して複数のアプリケーションをホストする大規模で複雑なワークロードをホストおよび管理できます。この製品ラインは、アプリケーションチームが、基盤となるテクノロジプラットフォームの部分ではなく、アプリケーションパーツのみを管理する場合に使用します。

ヒント

この製品ラインについてより理解を深めるために、次の例を参考にしてください。 AKS チームのようなテクノロジプラットフォームチームは、AKS プラットフォームでアプリケーションを実行する必要がある他のアプリケーションチームに、管理サービスとして AKS を提供することを目的としています。 AKS 技術プラットフォームチームは、AKS の管理、メンテナンス、セキュリティ、構成を提供します。そのため、アプリケーションチームは自分のアプリケーションのみを維持し、プラットフォームにデプロイします。

技術プラットフォームの製品ラインには、次の製品を含めることができます。

App Service Environment。通常は、個別の App Service プランを使用します。
AKS。通常、1 つ以上のクラスター内の名前空間を使用します。
Azure VMware Solution クラスターまたはホスト上の Azure Virtual Machines。
組織全体に仮想デスクトップまたはアプリケーションを提供する Azure Virtual Desktop。

チームが組織内の他のアプリケーションチームにサービスとして提供するテクノロジプラットフォームの要件に応じて、これらの製品を企業接続済み製品ラインまたはオンライン製品ラインに含めることができます。

共有アプリケーションポートフォリオ

アプリケーションランディングゾーンサブスクリプションサービスの共有アプリケーションポートフォリオの製品ラインは、少数の Azure リソースから構築される可能性がある単純なアプリケーションに対して、複数の個別のアプリケーションランディングゾーンサブスクリプションを必要としないワークロード用です。

アプリケーションチームと部門は、この製品ラインを使用して、ストレージアカウントや SQL Server などの複数の小さなアプリケーションや共有コンポーネントをホストできます。チームは、単一サブスクリプションまたは少数のサブスクリプション内の複数の独自のアプリケーション間でこれらのコンポーネントを共有します。

重要

一般的なチームは、この製品ラインの下で自販するサブスクリプションを所有しています。このチームは、この製品ラインに対してこのサブスクリプションにデプロイするアプリケーションの関連ポートフォリオを管理します。個別のアプリケーションポートフォリオ所有者がいる関連のないアプリケーションワークロードの一般的なデプロイには、この製品ラインを使用しないでください。

組織が単一サブスクリプションに変更され、リソースグループを使用してアクセスを委任する場合は、継続的な柔軟性、アクセス制御、ガバナンス、保守容易性を確保するように慎重に計画します。

複数のチーム間で単一サブスクリプションのリソースグループの委任を検討する場合は、最終的な決定を行う前に、次の考慮事項を考慮してください。

面グラフ	考慮事項
関連するアプリケーションポートフォリオの共通の所有権	- 同じエンティティの承認スコープ内に収まるように、部門の部署などの共通の所有者がアプリケーションを管理し、変更管理を簡略化します。 - ログ記録、監視、セキュリティなど、ワークロードがサブスクリプション全体で一貫したポリシー割り当てに従っていることを確認します。
規制に対するコンプライアンス	- IAM ポリシーと Azure ポリシーを使用して、National Institute of Standards and Technology (NIST)、Center for Internet Security (CIS)、Payment Card Industry Security Standards Council (PCI SSC)、業界要件、地域要件など、規制コンプライアンス要件を持つワークロードのサブスクリプションを作成します。詳細については、「Azure ランディングゾーンを調整する」を参照してください。 - ガバナンスにプライバシーとデータ処理の要件を使用するワークロードのサブスクリプションを作成します。個別のサブスクリプションによりアクセスが減ります。
Azure Policy	Azure ポリシーを管理グループ、サブスクリプション、リソースグループ、およびリソースにスコープします。リソースグループにリソースをデプロイするときに効率的なガバナンスを実現するために、高いスコープレベルで Azure ポリシーを割り当てます。リソースグループのスコープレベルで Azure Policy を管理する場合は、次の制約を考慮してください。 - サブスクリプションに新しいリソースグループを追加するときに Azure Policy の割り当てを作成するための管理オーバーヘッドが増加します - ポリシー割り当ての変更を管理するときにワークロードを増やす - リソースグループにポリシーをすぐに割り当てない場合は、セキュリティとガバナンスのギャップを増やす - 管理グループやサブスクリプションなど、高いスコープでコンプライアンスの状態をロールアップする機能を減らします
サブスクリプションの制限	- 制限をチェックして、アプリケーションが成長を妨げるハード制限に達していないことを確認します。各サブスクリプションには、Azure サービスに対してソフト制限とハード制限があります。 - サブスクリプションの制限を満たす大規模な成長パターンを予測するアプリケーション用に、個別のサブスクリプションを作成します。 - ノイズの多い近隣の問題を防ぐために、異なる部署や部門のアプリケーションチームとサブスクリプションを共有しないでください。
Azure サービスと機能の調整	仮想マシン、仮想ネットワーク、単純な PaaS サービスなどの基本的な Azure サービスプリミティブを提供するサービスを、単一のリソースグループ内にデプロイできます。ただし、最新の複合オファリングの複雑さにより、これらのより複雑なサービスを単一のリソースグループの境界外にデプロイする必要がある場合があります。これらのデプロイシナリオでは、この記事で前述した他の民主化サブスクリプションアプローチを使用します。
リソースグループを作成できるのはプラットフォームチームだけです	ビジネスユニットまたは部門間のさまざまなアプリケーションチーム間でサブスクリプションを共有する場合、共有サブスクリプションで新しいリソースグループを作成するチームの機能を制限できます。この制限により、リソースグループのスプロールが制限されます。新しいリソースグループを作成して管理できるのは、プラットフォームチームだけです。このアプローチにより、RBAC の割り当ての複雑さが増し、アプリケーションのデプロイを管理するためのプラットフォームチームへの依存関係が増します。これにより、アプリケーションチームの機敏性と権限が損なわれる可能性があります。

自販したサブスクリプションを、企業またはオンラインの管理グループの下の共有アプリケーションポートフォリオの製品ラインに配置できます。この方法は、Azure ランディングゾーンの既定の推奨階層に合わせて調整されます。または、組織の管理グループ階層が「要件を満たすために Azure ランディングゾーンアーキテクチャを調整する」のガイダンスに従っている場合は、新しい管理グループの下にサブスクリプションを配置することもできます。

次の図は、共有アプリケーションポートフォリオのサブスクリプションサービスの製品ラインの例を示しています。

次の場合は、共有アプリケーションポートフォリオの製品ラインを使用します。

アプリケーションチームは、アプリケーションで共有されるいくつかの小さなリソースまたはコンポーネントを提供する必要がありますが、コンポーネントは専用のアプリケーションランディングゾーンのいずれにも直接適合しません。
同じ部門内のアプリケーション間で共有する必要があるリソースまたはコンポーネントがありますが、コンポーネントは専用のアプリケーションランディングゾーンのいずれにも直接適合しません。
テクノロジプラットフォームチームは、AKS、Azure Virtual Desktop、Azure VMware Solution など、管理されている大規模な共有サービスをホストして、他のアプリケーションチームがサービスでアプリケーションを使用またはホストできるようにする必要があります。

サンドボックス

アプリケーションランディングゾーンサブスクリプションサービス用のサンドボックス製品ラインを使用して、安全で軽度に管理された目に見えるテスト領域を提供し、Azure で PoC または MVP を構築します。

詳細については、「ランディングゾーンサンドボックス環境」と「Azure ランディングゾーンでのアプリケーション開発環境の管理」を参照してください。

サンドボックスは、多くの場合、タイムボックス化または予算に制約があります。つまり、制限時間または予算制限があります。このような場合は、サンドボックスを拡張または削除して使用を停止する必要があります。

アプリケーションチームや他のユーザーが Azure のサービスをテストおよび実験するためのサンドボックス製品ラインを組織が提供していない場合、チームはシャドウ IT セットアップに頼る可能性があります。その場合、組織は、ビジネスユーザーがプラットフォームチームの管理と監視の外部で作成するサブスクリプションにレポートと可視性を提供し、ガバナンスを適用するのに苦労する可能性があります。

プラットフォームチームは、組織のユーザーとチームに対して、簡単にアクセスでき、望ましくはセルフサービスで、サンドボックスサブスクリプションへの自動承認されたアクセスを提供する必要があります。プラットフォームチームがアクセスまたは制御できないシャドウ IT 環境がリスクを発生させることを防ぐために、プラットフォームチームが表示および管理できる環境へのアクセス権をユーザーとチームに提供します。

サンドボックスは、サンドボックスのサブスクリプション境界外の他の仮想ネットワークとピアリングしないため、多くの場合、オンライン製品ラインサブスクリプションのネットワーク構成アプローチに従います。また、多くの場合、サンドボックスには、オンプレミスの場所やその他の場所へのハイブリッド接続を防ぐための追加の制御があります。不明なソースがサンドボックスから未承認の場所にデータを流出できないように、これらの制御を使用します。 Azure ポリシーを使用して、これらのコントロールを適用できます。

共有アプリケーションポートフォリオやテクノロジプラットフォームの製品ラインと同様に、同じ部署のチーム間で同じ考慮事項でサンドボックス製品ラインを共有することもできます。 1 つのサンドボックスサブスクリプションを作成し、リソースグループを介してチーム間で共有しないでください。代わりに、追加のサンドボックスサブスクリプションを作成します。

Azure で実験、PoC の作成、または MVP の作成を行う組織全体のユーザーに、安全でセキュリティー保護され管理された Azure サブスクリプションを提供する必要がある場合は、サンドボックス製品ラインを使用します。 シャドウ IT プラクティスを防ぐために、これらのユーザーを軽度に管理し、すべてのサービスへのアクセス権を付与する必要があります。

概要とポイント

この記事では、複雑なサブスクリプションサービスプロセスをナビゲートし、実装に進むのに役立つ規範的なガイダンスについて説明します。

将来のアプリケーションチームの要件を決定して、最適なサブスクリプションサービスの製品ラインを選択します。構築または移行するワークロードの初期セットの要件を特定します。これは、セルフサービスインターフェイスを介して有効にして公開するサブスクリプションサービスの製品ラインの優先順位を付けるのに役立ちます。

各製品ラインには、実装コストとメンテナンスコストがあります。長期的なコストと長期的な利点と使用状況を評価します。

通常、顧客は最初に次のサブスクリプションサービスの製品ラインを有効にします。

サンドボックス
企業接続済み
オンライン

その他のリソース

プラットフォームエンジニアリングアプローチをさらにサポートするには、組織のサブスクリプションサービスの製品ラインとオファリングを設計して実装するときに、次のリソースを確認します。

次のステップ

最適な結果を得るには、サブスクリプションの自動販売プロセスを可能な限り自動化する必要があります。サブスクリプションサービスの自動化の実装に関するコンパニオンガイダンスを使用します。

サブスクリプションの自動販売の実装ガイダンス

次の方法で共有

一般的なサブスクリプションサービスの製品ラインを確立する