次の方法で共有


Azure ランディング ゾーンをデプロイする

この記事では、プラットフォームとアプリケーションのランディング ゾーンをデプロイするために使用できるオプションについて説明します。 プラットフォームのランディング ゾーンでは、ワークロードで使用される一元化されたサービスが提供されます。 アプリケーションのランディング ゾーンは、ワークロード自体用にデプロイされた環境です。

重要

プラットフォームとアプリケーションのランディング ゾーンの定義と実装の違いについて詳しく知るには、Azure のクラウド導入フレームワークの「Azure ランディング ゾーンとは?」を参照し、そこにある を確認してください。

この記事では、プラットフォームとアプリケーションのランディング ゾーンのデプロイ オプションについて説明します。

プラットフォームランディングゾーンアプローチを選択する

次のプラットフォーム デプロイ オプションは、クラウド導入フレームワークで詳しく説明されているように、azure ランディング ゾーンの概念アーキテクチャ をデプロイして運用するための、意見に基づくアプローチを提供します。 カスタマイズによっては、結果として得られるアーキテクチャが、ここに示されているすべてのデプロイ オプションで同じとは異なる場合があります。 プラットフォームのデプロイ オプションの違いは、さまざまなテクノロジの使用方法、さまざまなアプローチの取り方、カスタマイズ方法に基づいています。

標準の展開オプション

標準的なデプロイ オプションは、一般的なエンタープライズ Azure の使用状況に対処します。

Azure プラットフォーム ランディング ゾーンのデプロイ オプション 説明
Azure ポータルのデプロイ Azureポータルベースのデプロイメントで、Azureランディングゾーンの概念アーキテクチャの完全な実装を提供し、管理グループやポリシーなどの主要なコンポーネントに対して意図的な構成を含んでいます。
Bicep のデプロイ モジュール形式のコードとしてのインフラストラクチャ ベースのデプロイ。各 Bicep モジュールは、Azure ランディング ゾーンの概念アーキテクチャのコア機能をカプセル化します。 モジュールは個別にデプロイできますが、この設計では、オーケストレーター モジュールを使用して、モジュールによって異なるトポロジをデプロイする複雑さをカプセル化することを提案しています。 Bicep デプロイでは、Azure パブリック クラウド、Azure China 21Vianet リージョン、Azure US Government クラウドがサポートされます。
Terraform のデプロイ このコードとしてのインフラストラクチャ ベースのデプロイは、Terraform オーケストレーター モジュールを提供し、各プラットフォーム機能を個別または全体としてデプロイすることもできます。

バリアントと特殊化

標準プラットフォームのデプロイ オプション 一般的なエンタープライズ Azure の使用状況に対応していますが、特定の特殊化に焦点を当てたデプロイ オプションがいくつかあります。

デプロイ オプション 説明
ソブリン ランディング ゾーン ソブリン ランディング ゾーンは、高度なソブリン制御を必要とする組織向けの Azure ランディング ゾーンの一種です。

パートナーの実装

Azure Migrate や Modernize などのパートナー プログラムは、組織のニーズに固有のプラットフォーム ランディング ゾーンを設計して実装するのに役立ちます。 これらの実装は、Azure ランディング ゾーンの概念アーキテクチャ から始まり、クラウド導入戦略、組織トポロジ、および目的の結果に固有の構成を設計するのに役立ちます。

ポリシー管理のためのコードとしてのエンタープライズ ポリシー (EPAC)

コードとしてのエンタープライズ ポリシー (EPAC) は、組織の Azure 資産全体で Azure Policy をデプロイ、管理、運用するための別の方法です。 EPAC を使用して、Azure ランディング ゾーン環境でポリシーを管理できます。これは、標準プラットフォーム オプションや の代わりになります。 統合方法の詳細については、「EPAC と Azure ランディング ゾーンを統合する」を参照してください。

コードとしてのエンタープライズ ポリシーは、より高度で成熟した DevOps およびコードとしてのインフラストラクチャの顧客に最適です。 ただし、どのような規模のお客様でも、EPAC を評価した後、必要であれば使用することができます。 方向性が一致していることを確認するには、まず、「EPACを使用するべき人」を参照してください。

Note

長期的に使用するアプローチを決定する前に、2 つのアプローチのライフサイクルと柔軟性を比較します。 まず、標準プラットフォーム オプションで説明されている既定の実装で提供されるネイティブ ポリシー管理を評価します。 その実装がガバナンス ニーズに最適と思えない場合は、EPAC を使用して MVP または概念実証を実行します。 アプローチを実装する前に、オプションを比較し、検証し、確認することが重要です。これは、いったん確立されたポリシー ガバナンス 方法を変更する複雑なプロセスであるためです。

Azure ランディング ゾーンを運用する

プラットフォーム ランディング ゾーンをデプロイしたら、それを運用して維持する必要があります。 詳細については、Azure ランディング ゾーンを最新の状態に保つ方法に関するガイダンスを参照してください。

Azure ガバナンス ビジュアライザー

Azure ガバナンス ビジュアライザー は、ドットを接続し、高度なレポートを提供することで、技術的な Azure ガバナンスの実装に関する包括的な概要を得ることを目的としています。

サブスクリプションの自動販売

プラットフォーム ランディング ゾーンとガバナンス戦略が実施されたら、次の手順は、ワークロード所有者のためにサブスクリプションを作成して運用化する方法に関する一貫性を確立することです。 サブスクリプションの民主化は、サブスクリプションを管理とスケールの単位として使用する Azure ランディング ゾーンの設計原則です。 このアプローチにより、アプリケーションの移行と新しいアプリケーション開発が高速化します。

サブスクリプション提供 は、ワークロードチームがサブスクリプションを要求するプロセスと、プラットフォームチームがそれらのサブスクリプションを展開および管理するプロセスを標準化します。 これにより、アプリケーション チームは一貫した管理された方法で Azure にアクセスでき、要件の収集が完了していることを確認できます。

また、組織がテナントに販売できる複数の異なるスタイルのサブスクリプションを持つことも一般的です。これは、業界では "製品ライン" と呼ばれることがよくあります。 組織に推奨される "製品ライン" については、「共通のサブスクリプション サービス製品ラインを確立する」を参照してください。

開始するには、「サブスクリプション サービスの実装ガイダンス」の実装ガイダンスに従ってください。 次に、次のコードとしてのインフラストラクチャ モジュールを確認します。これにより、実装のニーズに合った柔軟性が提供されます。

デプロイ オプション 説明
Bicep サブスクリプション サービス サブスクリプションの自販 Bicep モジュールは、ワークロードごとの構成に基づいて個々のアプリケーション ランディング ゾーンのデプロイを調整するように設計されています。 これらは、手動で実行することも、自動化の一部として実行することもできます。
Terraform サブスクリプション サービス これらのモジュールでは、Terraform を使用して、個々のアプリケーション ランディング ゾーンのデプロイを調整します。

アプリケーションランディングゾーンのアーキテクチャ

アプリケーション ランディング ゾーンは、ワークロードのアプリケーション チーム所有リソースの承認済み宛先としてデプロイされる 1 つ以上のサブスクリプションで構成されます。 ワークロードでは、プラットフォーム ランディング ゾーンにデプロイされたサービスを利用することも、それらの一元化されたリソースから分離することもできます。 アプリケーション ランディング ゾーンは、一元管理されたアプリケーション、アプリケーション チームが所有する分散ワークロード、複数の部署のアプリケーションをホストできる Azure Kubernetes Service (AKS) などの一元管理ホスティング プラットフォームに使用する必要があります。 異常な制約によって強制されない限り、アプリケーション ランディング ゾーンサブスクリプションには、ライフサイクルや重要度分類など、単一のワークロードまたは論理アプリケーション境界からのリソースのみが含まれます。

ワークロード チームは、プラットフォーム チームによって確立された正式なプロセスを通じて、ワークロードの要件を伝達します。 プラットフォーム チームは通常、必要なすべてのガバナンスに登録されている空のサブスクリプションをデプロイします。 その後、ワークロード アーキテクトは、そのアプリケーション ランディング ゾーンの制約内で動作し、共有プラットフォーム機能 (ファイアウォールやクロスプリミシス ルーティングなど) を利用するソリューションを設計します(実用的な場合)。

アーキテクトは、アプリケーションランディングゾーンを念頭に置いて特別に設計されていない参照アーキテクチャを適応させることができます。 ただし、Microsoft Learn には、アプリケーション ランディング ゾーンのコンテキストに特に対処するワークロード チーム向けのアプリケーションとデータ プラットフォームのガイダンスも含まれています。 プラットフォーム チームは、ワークロード チームが組織内に存在する可能性があるワークロードの種類と特性を予測できるように、ワークロード チームが利用できるガイダンスを認識する必要があります。

アプリケーション ランディング ゾーンのアーキテクチャ 説明
Azure App Service 環境 参照実装を使用したマルチテナント環境と App Service 環境のユース ケースの両方で実証済みの推奨事項と考慮事項。
Azure API Management (APIM) 参照実装の一部として内部 API Management インスタンスをデプロイするための実証済みの推奨事項と考慮事項。 このシナリオでは、Azure Application Gateway を使用してセキュリティで保護されたイングレス制御を提供し、バックエンドとして Azure Functions を使用します。
ハイブリッドとマルチクラウドのシナリオに Azure Arc を Azure Arc 対応サーバー、Kubernetes、Azure Arc 対応 SQL Managed Instance。
Azure Container Apps この Azure Container Apps ガイダンスでは、戦略的な設計パスの概要を説明し、Azure Container Apps をデプロイするためのターゲットの技術的な状態を定義します。 専用のワークロード チームがこのプラットフォームを所有し、運用します。
Azure Data Factory 従来のメダリオン レイクハウスをアプリケーション ランディング ゾーン内でホストする方法を学びます。
Azure OpenAI チャット ワークロード Azure ランディング ゾーン内の一般的な Azure OpenAI チャット アプリケーション を統合して、一元化された共有リソースを利用しながら、ガバナンスとコスト効率に準拠し、デプロイと管理に関するワークロード チーム向けのガイダンスを提供する方法について説明します。
Azure Kubernetes Service (AKS) アプリケーション ランディング ゾーン内で実行されている AKS デプロイの戦略的な設計パスとターゲット技術状態を表すコード テンプレートとしてのガイダンスと関連インフラストラクチャ。
Azure Red Hat OpenShift Azure と Red Hat の両方のリソースを含む最適な Azure Red Hat OpenShift デプロイを表す Terraform テンプレートのオープンソース コレクション。
Azure Synapse Analytics Azure Synapse Analytics の一般的なエンタープライズ デプロイ用にアプリケーション ランディング ゾーンを準備するためのアーキテクチャ アプローチ。
Azure Virtual Desktop ホスト プール、ネットワーク、ストレージ、監視、アドオンの作成など、Azure Virtual Desktop デプロイの設計時に参照する必要がある ARM、Bicep、Terraform テンプレート。
Azure Virtual Machines このアーキテクチャは、Azure 仮想マシン (VM) ベースライン アーキテクチャ からアプリケーション ランディング ゾーンにガイダンスを拡張し、サブスクリプションのセットアップ、パッチ コンプライアンス、およびその他の組織のガバナンスに関する問題に関するガイダンスを提供します。
Azure VMware Solution Azure VMware Solution プライベート クラウド、ジャンプ ボックス、ネットワーク、監視、アドオンなど、VMware デプロイの設計に役立つ ARM、Bicep、Terraform テンプレート。
Citrix on Azure Azure エンタープライズ規模のランディング ゾーンでの Citrix Cloud 向けのクラウド導入フレームワークの設計ガイドラインでは、多くの設計領域について説明しています。
Azure での Red Hat Enterprise Linux (RHEL) Azure 上の Red Hat Enterprise Linux (RHEL) のランディング ゾーンは、Microsoft Azure で RHEL ベースのワークロードを設計するために使用されるアーキテクチャ ガイダンスと参照実装に関する推奨事項のオープンソース コレクションです。
ハイ パフォーマンス コンピューティング (HPC) ワークロード Terraform、Ansible、Packer などのツールを使用した Azure のエンド ツー エンドの HPC クラスター ソリューション。 ID の実装、ジャンプ ボックス アクセス、自動スケーリングなど、Azure ランディング ゾーンのベスト プラクティスに対処します。
ミッションクリティカルなワークロード ミッション クリティカルとして分類されたワークロードを、アプリケーション ランディング ゾーン内で実行するように設計する方法に対処します。
SAP ワークロード Azure ランディング ゾーンのベスト プラクティスに沿った SAP ワークロードのガイダンスと推奨事項を提供します。 SAP システムのコンピューティング、ネットワーク、ストレージ、監視、ビルドなどのインフラストラクチャ コンポーネントを作成するための推奨事項を提供します。

ワークロードは、多くの場合、さまざまなテクノロジと分類のコレクションです。 ワークロード内のすべてのテクノロジに関連する参照資料を確認することをお勧めします。 たとえば、Azure OpenAI チャットと Azure API Management からのガイダンスを理解することは、生成型 AI シナリオが API ゲートウェイを追加することでメリットを得られるかどうかを理解することが重要です。

次の手順