AI のアーキテクチャとガバナンス

この記事では、AI ワークロードが Azure ランディング ゾーンとエンタープライズ アーキテクチャにどのように適合するかについて説明します。 これは、AI 導入が拡大するにつれて、組織が考慮する必要がある追加のプラットフォーム機能を識別します。

AI ワークロードにも、他のワークロードと同様に Azure ランディング ゾーンの原則とベスト プラクティスを適用します。 AI ワークロードには、Azure ランディング ゾーン アーキテクチャやガバナンス モデルを別にする必要はありません。 プラットフォーム チームは、既存のガバナンス ベースラインを使用し、必要に応じて拡張して、組織が使用する予定の AI サービスとモデルを考慮する必要があります。

結果: アーキテクチャとガバナンスの計画が終了するまでに、Azure で使用する予定の AI テクノロジをサポートする最新のガバナンス ベースラインが整備されているはずです。

アーキテクチャとデシジョン ツリー

プラットフォームランディングゾーン

AI の導入は、別のプラットフォーム構造を導入するのではなく、既存の Azure ランディング ゾーンに基づいて構築する必要があります。 AI ワークロードでは、他のAzure ワークロードと同じ管理グループ階層とプラットフォーム機能が使用されます。 組織では通常、AI 固有の管理グループは必要ありません。 代わりに、プラットフォーム チームは、既存のガバナンスと接続機能を拡張して、AI ワークロードが使用するAzure サービスに対処する必要があります。

ガバナンス ベースライン: 既存の Azure ランディング ゾーン ガバナンス ベースラインは、AI ワークロードの開始点のままである必要があります。 プラットフォーム チームは、既存のポリシーで対処できない要件が AI サービスによって導入されたときに、そのベースラインを拡張する必要があります。

• Azure Policy: 組織は、プラットフォーム ランディング ゾーン アクセラレータからのベースライン ポリシーから開始する必要があります。 プラットフォーム チームは、Microsoft Foundry モデル、Foundry Tools、Azure AI 検索、Azure 仮想マシン など、組織が承認する AI サービスの Azure Policy 定義を追加する必要があります。 既存の管理グループ階層を通じてこれらのポリシーを適用すると、別のガバナンス モデルを必要とせずに、AI ワークロードに一貫性のあるガードレールが提供されます。 Microsoftガイダンスでは、ランディング ゾーン管理グループ階層を通じて AI 固有のポリシーを適用して、ワークロード リソースがそれらを継承できるようにします。

• ネットワーク: 既存のAzureランディング ゾーンのネットワーク パターンも、AI ワークロードの基盤のままである必要があります。 プラットフォーム チームは、AI ワークロードによって、特にインターネットに接続するサービスやオンプレミスのデータへのアクセスに関して追加の要件が生じる場合、共有接続とネットワーク保護を拡張する必要があります。

  • DDoS Protection: インターネットに接続する AI ワークロードでは、Azure DDoS Protection を使用する必要があります。 プラットフォーム チームは、個々のワークロード チームが独自のプラットフォーム レベルのアプローチを確立することを要求するのではなく、組織の共有ネットワーク機能の一部としてこの保護を提供できます。

  • ハイブリッド接続: Azure AI ワークロードからオンプレミスデータにアクセスする組織は、パフォーマンスと可用性の要件に基づいて接続を選択する必要があります。 Azure ExpressRouteはプライベート接続を提供し、組織がAzureへの予測可能な接続を必要とする場合に適しています。 Azure VPN Gatewayは、パブリック インターネット経由で暗号化された接続を提供し、要求の少ない接続要件に対応できます。 既存のAzureランディング ゾーンのガイダンスでは、ハイブリッド接続パターンとしてVPN Gatewayと ExpressRoute もサポートされています。

ワークロード ランディング ゾーン

AI ワークロードでは、他のAzure ワークロードと同じワークロード ランディング ゾーンの原則が使用されます。 各ワークロードは、独自のワークロード ランディング ゾーンを持ち、1 つ以上の Azure サブスクリプションを使用して、組織のガバナンスと分離の要件に基づいて環境を分離する必要があります。 Azure サブスクリプションは、クォータ、コスト、ガバナンス、セキュリティなどの領域の境界を提供します。

プラットフォーム チームは、適切なガバナンス制御を提供する既存の管理グループの下に、AI ワークロードのワークロード ランディング ゾーン サブスクリプションを配置する必要があります。 インターネット向けの AI ワークロードは、通常、オンライン管理グループの下に属します。 内部 AI ワークロードは、通常、内部 ("Corp") 管理グループに属します。 プラットフォーム チームは、AI 専用の管理グループを作成するのではなく、これらの既存の境界を使用する必要があります。 管理グループ レベルでの Azure Policy の割り当てにより、AI やその他のワークロード全体で一貫したプラットフォーム ガードレールが提供されます。

Reliability

AI ワークロードでは、組織の既存の可用性とディザスター リカバリー標準を使用する必要があります。 プラットフォーム チームは、ビジネス継続性の要件によって追加のコストと複雑さが正当化される場合に、ワークロード チームがリージョン間で AI ワークロードをデプロイできるように、複数のリージョンをサポートするために、Azureランディング ゾーンを準備する必要があります。 Azureランディング ゾーンリージョンのガイダンスでは、マルチリージョンワークロードランディングゾーンをサポートできるようにプラットフォームを設計することが特に推奨されています。

• データの場所: データの場所もリージョン設計の一部である必要があります。 ワークロード チームは、待機時間とパフォーマンスが重要な場合、取得データを消費する AI サービスの近くにそのデータを配置する必要があります。 地域配置は、組織のデータ所在地の要件も満たす必要があります。

• 可用性と容量: サービスの可用性、モデルの可用性、容量は Azure リージョンによって異なる可能性があるため、AI により、リージョンに関する追加の考慮事項が生じます。 組織は、承認された AI サービスとモデルをサポートするリージョンを特定してから、それらのリージョンを AI ワークロードで使用できるようにする必要があります。

• フェールオーバー: リージョンのフェールオーバーを必要とするワークロード チームは、モデルのデプロイや取得データなど、ワークロードが依存する AI 資産も考慮する必要があります。 復旧設計では、ワークロードの復元に必要なリソースとデータがセカンダリ リージョンにあることを確認する必要があります。

エンタープライズ統合

AI ワークロードは、他のワークロードと同じアーキテクチャ原則を使用して、エンタープライズ プラットフォームと統合する必要があります。 AI 固有の主な考慮事項は、信頼できる組織データへのアクセスです。

組織は、すべてのワークロード チームが個別のデータ統合パターンを構築する必要なしに、管理されたデータを AI ワークロードで使用できるようにする、データに対する統一されたアプローチを確立する必要があります。 Microsoft Fabricは、分析および AI シナリオ用の組織データを準備して提供できます。 Azure AI ワークロードは、承認された統合パターンを通じて適切なデータを取り込めます。 この基盤の確立に関する詳細は、統合データプラットフォームを参照してください。

次のステップ

ワークロード ランディング ゾーンのアーキテクチャとガバナンスに関する考慮事項は、ワークロードが使用する AI プラットフォームとテクノロジによって異なります。 次のガイダンスでは、さまざまな AI 導入パターンに関するアーキテクチャに関するより深い推奨事項を示します。