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

  • [アーティクル]

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

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

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

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

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 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 プラクティスを防ぐために、これらのユーザーを軽度に管理し、すべてのサービスへのアクセス権を付与する必要があります。

概要とポイント

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

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

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

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

その他のリソース

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

次のステップ

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

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