サブスクリプションの自動販売
サブスクリプションの自動販売は、ワークロードをデプロイする必要があるアプリケーション チームにサブスクリプションをプログラムで発行するためのプラットフォーム メカニズムを提供します。 次の図は、サブスクリプションの自動販売がプラットフォームとワークロードのライフサイクルに適合する場所を示しています。
サブスクリプションの自動販売は、サブスクリプションの民主化の概念に基づいており、アプリケーション ランディング ゾーンにそれを適用します。 サブスクリプションの民主化では、リソース グループではなく、サブスクリプションがワークロード管理とスケーリングの主な単位です。 詳細については、次を参照してください。
- プラットフォーム ランディング ゾーンとアプリケーション ランディング ゾーンの比較
- サブスクリプションに対する民主化されたアプローチ
- Azure でサブスクリプションはいくつ使用する必要があるか (YouTube)
サブスクリプションの自動販売を行う理由
サブスクリプションの自動販売は、Azure にワークロードをデプロイする必要がある組織にいくつかの利点をもたらします。 これにより、アプリケーション ランディング ゾーンのサブスクリプションを要求、デプロイ、管理するためのプロセスが標準化および自動化されます。 サブスクリプションの自動販売によって、サブスクリプションの作成プロセスが簡略化され、組織のガバナンスの下に置かれるため、アプリ チームは、より高い信頼性と効率でワークロードのデプロイに集中できます。
- 合理化されたプロセス: サブスクリプションの自動販売では、アプリケーション チームがサブスクリプションを要求するための公式のフロント ドアが提供されるため、サブスクリプション プロセスを自分で操作する必要がなくなります。
- 速度の向上: アプリケーション チームは、アプリケーション ランディング ゾーンにより早くアクセスし、ワークロードをより迅速にオンボードできます。
- 効率的なガバナンス: プラットフォーム チームが、最小限のオーバーヘッドでアプリケーション ランディング ゾーンにガバナンスを適用できます。
サブスクリプションの自動販売を実装する方法
サブスクリプションの自動販売には、3 つのチームが関係します。 クラウドのセンター オブ エクセレンス (CCoE) が、ビジネス ロジックと承認プロセスを確立します。 準備ができると、アプリケーション チームがサブスクリプション要求を行います。 プラットフォーム チームがその要求を使用してサブスクリプションを作成し、構成してから、アプリケーション チームにサブスクリプションを渡します。 アプリケーション チームでは、予算の更新、ワークロードの展開、運用の確立を行います。 次のガイダンスでは、サブスクリプションの自動販売プロセスの各手順についてさらに詳しく説明します。 詳細については、「サブスクリプションの自動販売の実装ガイダンス」を参照してください。
プラットフォーム チームは、アプリケーション チームに多くのオプションとサブスクリプションの種類を自販できます。 これらのタイプは、プラットフォーム エンジニアリングの原則とプラクティスに関連するため、製品ラインと呼ばれます。 ニーズに最も適したオプションの選択の詳細については、「一般的なサブスクリプション サービスの製品ライン」を参照してください。
ビジネス ロジックと承認プロセスを確立する
サブスクリプションの自動販売モデルを実装するには、重要なサブスクリプション情報を収集する承認プロセスを確立する必要があります。 クラウドのセンター オブ エクセレンス (CCoE) は、承認プロセスをプログラミングし、収集する情報に関するビジネス ルールを確立する必要があります。
プロセスを自動化します。 プロビジョニングの高速化とコンプライアンスの向上のために、サブスクリプション要求の取得と承認のプロセスを自動化する必要があります。
既存のツールと統合します。 サブスクリプションの自動販売の承認プロセスを、既存の IT サービスマネジメント (ITSM) ツールに統合する必要があります。 統合により、承認プロセスの簡素化と手動での作業の削減ができ、さらにエラーを減らしながら効率を向上させることができます。 また、時間の経過と共にメンテナンスが容易になり、監査のコンプライアンス レポートにも役立ちます。
デプロイ パイプラインに接続します。 承認プロセスのビジネス ロジックを、プラットフォーム チームが管理するサブスクリプション デプロイ パイプラインに結び付けるのがベスト プラクティスです。 Azure Pipelines または GitHub Actions ワークフローは、サブスクリプション デプロイ パイプラインの一般的なソリューションです。
取り込み時に要件を収集します。 ビジネス ロジックでは、アプリケーション チームがサブスクリプションを要求し、サブスクリプションの要件を提供できるようにする必要があります。 これらの要件には、予想される予算、サブスクリプション所有者、ネットワークの期待値、ビジネスの重要度と機密性の分類が含まれている必要があります。 プロセスの開始時にこの情報を収集すると、デプロイ パラメーターと関係者の承認の必要性が通知されます。 また、取り込みプロセスでは、管理グループ階層にワークロードを配置するのに十分な情報をプラットフォーム チームに提供する必要があります。
承認プロセスが設定されたら、アプリケーション チームはサブスクリプションの要求を開始できます。
サブスクリプション要求を行う
サブスクリプションの自動販売は、アプリケーション チームがサブスクリプションを要求するための標準プロセスを提供します。 サブスクリプションの自動販売が利用できることを広く知らせて、サブスクリプション要求を簡単に行えるようにすることが重要です。 アプリケーション チームがサブスクリプション要求を送信すると、プラットフォーム チームがプロセスの制御を担います。 プラットフォーム チームは、サブスクリプションを作成し、アプリケーション チームにサブスクリプションを配信するまで制御を維持します。
ネットワークを構成する
サブスクリプションの自動化では、必要なネットワーク コンポーネントを設定する必要があり、この設定には各アプリケーション チームのニーズを満たすのに十分な柔軟性が必要です。 一般的なガイダンスとして、1 つのルーティング ドメインで重複する IP アドレスを使用しないでください。 サイズ要件が変更された場合は、ダウンタイムなしで仮想ネットワークのアドレス空間を追加または削除できます。 詳細については、次を参照してください。
IP アドレス管理 (IPAM) ツールを使用します。 IPAM システムを使用し、自動販売プロセスに統合して、IP アドレスの割り当てを合理化する必要があります。 詳細および IPAM のガイダンスについては、「IP アドレス管理 (IPAM) ツール」を参照してください。
アプリ チームに自主性を与える。 サブネット、さらにはサブスクリプション内の一部の仮想ネットワークも作成する権限をアプリケーション チームに付与する必要があります。 プラットフォーム チームは、中央ハブにピアリングする仮想ネットワークを必ず作成する必要があります。
ネットワーク ガバナンスを適用します。 プラットフォーム チームは、(1) 管理グループ階層に割り当てられた Azure ポリシー、または (2) Azure Virtual Network Manager とセキュリティ管理規則を使用して、仮想ネットワーク ガバナンスを適用する必要があります。 詳細については、「ポリシー主導のガバナンス」およびリスクの高いポートをブロックする方法に関する記事を参照してください。
サブスクリプションの配置を決定する
プラットフォーム チームは、ネットワークとガバナンスの要件を使用して、管理グループ階層にサブスクリプションを配置する必要があります。 また、サブスクリプションの作成前に、サブスクリプションのクォータ制限を確認する必要があります。 詳細については、「要件を満たすように Azure ランディング ゾーンのアーキテクチャを調整する」を参照してください。
適切な管理グループを特定します。 管理グループは、サブスクリプションとワークロードのデプロイを整理および管理するのに役立ちます。 各ワークロードの分類とニーズに必要なポリシーを適用する管理グループを見つけるか、作成してください。
柔軟性の高い自動化を構築します。 自動化は、(1) 複数のサブスクリプションのデプロイと、(2) サブスクリプション サービスの制限への適応を行うのに十分な柔軟性を備えている必要があります。
"複数のサブスクリプション:" 一部のワークロードには、複数のサブスクリプションが必要です。 たとえば、一部のワークロードには、サブスクリプションで区別される複数のインスタンスがあります。 または、顧客ごとに専用リソースを使用する SaaS アーキテクチャでは、多くの場合、数十のサブスクリプションが使用されます。
"サブスクリプション サービスの制限:" 数千のサブスクリプションを持つ企業には、制限を回避するために、古いサブスクリプションにデプロイしたり、サブスクリプション内にワークロードを併置したりすることができる自動化が必要です。 詳細については、「Azure ランディング ゾーンに関する FAQ」を参照してください。
クォータの引き上げは、プロビジョニング後に Azure portal を使用して手動で要求できます。 このプロセスを自動化する場合、利用可能な API を使用すると簡単です。 ただし、クォータ要求は失敗する可能性があるため、スクリプトを実行して、エラーがあればそれを処理する必要があります。 詳細については、Microsoft.Capacity、Microsoft.Quota、Microsoft.Support に関する各記事を参照してください
サブスクリプションを作成して構成する
ここで、要求されたサブスクリプションを作成して構成できます。 目標は、反復可能で一貫性のあるプロセスを作成することです。 サブスクリプションの作成および構成プロセスでできることを可能な限り自動化します。
コードとしてのインフラストラクチャ (IaC) を使用します。 サブスクリプションの自動販売の一般的な戦略は、IaC を使用してプログラムでサブスクリプションを作成および構成することです。 プログラムで Azure サブスクリプションを作成するには商業契約が必要ですが、商業契約なしでサブスクリプション構成のすべての側面を自動化できます。 詳細については、次を参照してください。
サブスクリプションの自動販売の例として Bicep と Terraform のモジュールがあり、商業契約への登録に関係なく、サブスクリプションの自動販売モデルを採用できます。 自動化を調整するには、GitHub のアクションまたは Azure Pipelines を使用する必要があります。
コスト管理にタグを使用します。 Microsoft Cost Management でのコスト管理とレポートの目的で、各サブスクリプションに対するタグの整合性のある割り当てを自動化する必要があります。 商業契約で課金レポートを受け取りますが、Cost Management ではより優れた機能が提供されます。 たとえば、特定のタグを含むサブスクリプションのレポートを作成できます。 詳細については、「コストと使用状況のデータでのタグの使用方法」および「タグの継承を使用してコストをグループ化して割り当てる」を参照してください
運用と非運用のサブスクリプションを使用します。 新しいサブスクリプションの要求では、ワークロードが運用向けか DevTest 向けかを指定する必要があります。 DevTest 環境は、リソース料金は安くなりますが、他の条件があります。 DevTest プランは MPA では使用できないことに注意してください。 詳細については、次を参照してください。
ID とロールベースのアクセス制御 (RBAC) を設定します。 セキュリティで保護された準拠環境を維持するには、Azure サブスクリプション内のリソースへのアクセスを管理することが重要です。 アクセスを制御するには、ID と RBAC の設定が不可欠です。 このセットアップには、サブスクリプション所有者の指定、アクセスを管理するための Microsoft Entra グループの作成、ワークロードをデプロイするためのオートメーション アカウントの確立が含まれます。
サブスクリプション所有者を指定します。 サブスクリプションの自動販売の自動化では、作成時にサブスクリプション所有者を指定する必要があります。 サブスクリプション要求では、取り込み時にこの情報を取得する必要があります。 サブスクリプション所有者に指定できるのは、選んだサブスクリプション ディレクトリ内のユーザーまたはサービス プリンシパルのみです。 ゲスト ディレクトリのユーザーを選択することはできません。 サービス プリンシパルを選択する場合は、そのアプリ ID を入力します。
Microsoft Entra グループを作成します。 サブスクリプション所有者に加え、確実に自動販売プロセスで Microsoft Entra グループ構造を使用してサブスクリプションへのアクセスを管理するようにする必要があります。 昇格された (書き込みなどの) アクセスについては、グループに PIM を使用することをお勧めします。 この作成プロセスの自動化で、サブスクリプション所有者の数を制限する、必要最小限のアクセス レベルを使用するなどのベスト プラクティスに違反しないようにする必要があります。
ワークロード ID を設定します。 ワークロードのデプロイに使用されるワークロード ID (サービス プリンシパル) には、多くの場合、サブスクリプション スコープで昇格されたアクセス許可があります。 サブスクリプション要求プロセスでは、取り込み時にワークロード ID のニーズを収集する必要があります。 自動販売プロセスでこれらの ID を作成し、適切なサブスクリプション アクセス権を割り当てる必要があります。 ワークロード ID では PIM を使用できないため、リソースへの永続的なアクセス権を得る点に注意することが重要です。 シークレットを管理する必要がないように、マネージド ID を使用することをお勧めします。 詳細については、ID の設計領域に関する記事を参照してください。
アプリケーション チームに引き渡します。 プラットフォーム チームは、サブスクリプションを作成した後、サブスクリプションをアプリケーション チームに渡す必要があります。
サブスクリプションの予算を更新する
プラットフォームとワークロードの両チームは、サブスクリプションの財務の健全性に対する責任を共有します。 デプロイでは、サブスクリプション要求の情報に基づいてサブスクリプション予算を作成する必要があります。 アプリケーションでは、サブスクリプションを受け取ったときにニーズを満たすように予算を更新する必要があります。 予算は、現在の使用量と予測の使用量に対して支出を監査する場合に役立ちますが、ハード制限ではありません。 ワークロードが予算のしきい値を超過しそうな場合にサブスクリプション所有者に通知する予算アラートを作成する必要があります。 API Management などの共有サービスの場合は、Azure のコスト割り当てルールを使用して、使用するサブスクリプション間でコストを再配分することを検討してください。
ワークロードをデプロイして運用する
アプリケーション チームは、ワークロードに必要なリソースの作成および操作の管理について自律性を備えている必要があります。 プラットフォーム チームは、引き続きサブスクリプション ガバナンスを担当します。 ワークロードのガバナンス要件が変化するにつれて、プラットフォーム チームは、ワークロードのニーズに最適な管理グループにサブスクリプションを移動させる必要があります。 この移動は、Bicep または Terraform を使用して自動化できます。 詳細については、次を参照してください。
- 管理グループの概要
- 新しい管理グループにサブスクリプションを移動する (Bicep)
- 新しい管理グループにサブスクリプションを移動する (Terraform)
- 要件を満たすように Azure ランディング ゾーンを調整する
次のステップ
アプリケーション チームに販売できるサブスクリプション (製品ライン) を確認します。 さまざまなシナリオに対応できるように、優れた出発点を確立します。