Azure ランディング ゾーンでのベースライン Azure AI Foundry チャット参照アーキテクチャ
この記事は、 ベースライン AI Foundry チャット参照アーキテクチャに基づくシリーズの一部です。 Azure アプリケーション ランディング ゾーン サブスクリプションにデプロイする前に必要な調整を特定できるように、ベースライン アーキテクチャを確認します。
この記事では、ベースライン チャット アプリケーションをデプロイするが、ワークロード チームのスコープ外のリソースを使用する生成型 AI ワークロード アーキテクチャについて説明します。 プラットフォーム チームはリソースを一元的に管理し、複数のワークロード チームがリソースを使用します。 共有リソースには、クロスプレミス接続、ID アクセス管理システム、ポリシー用のネットワーク リソースが含まれます。 このガイダンスは、Azure ランディング ゾーンを使用する組織が一貫したガバナンスとコスト効率を維持するのに役立ちます。
Azure AI Foundry では、アカウントとプロジェクトを使用して AI の開発とデプロイを整理します。 たとえば、ランディング ゾーンの実装では、ビジネス グループ レベルで一元化されたリソースとしてアカウントを使用し、そのビジネス グループ内の各ワークロードの委任されたリソースとしてプロジェクトを使用する場合があります。 リソース編成の要因とコストの割り当ての制限のため、このトポロジはお勧めしません。この記事ではそれに関するガイダンスを提供していません。 代わりに、このアーキテクチャでは、ワークロードが Azure AI Foundry インスタンスの所有者として扱われます。これが推奨されるアプローチです。
ワークロード所有者は、ワークロード開発作業に集中できるように、共有リソース管理をプラットフォーム チームに委任します。 この記事では、ワークロード チームの視点を示し、プラットフォーム チームの推奨事項を指定します。
Von Bedeutung
Azure ランディング ゾーンとは何か
Azure ランディング ゾーンは、組織のクラウド フットプリントを次の 2 つの重要な領域に分割します。
アプリケーション ランディング ゾーンは、ワークロードが実行される Azure サブスクリプションです。 アプリケーション ランディング ゾーンは、組織の共有プラットフォーム リソースに接続します。 この接続により、ネットワーク、ID アクセス管理、ポリシー、監視など、ワークロードをサポートするインフラストラクチャへのアクセス権がランディング ゾーンに提供されます。
プラットフォーム ランディング ゾーンは、複数のプラットフォーム チームが管理できる様々なサブスクリプションのコレクションです。 各サブスクリプションには特定の機能があります。 たとえば、接続サブスクリプションでは、プラットフォーム チーム向けに一元化されたドメイン ネーム システム (DNS) の解決、クロスプレミス接続、ネットワーク仮想アプライアンス (NVA) が提供されます。
このアーキテクチャの実装に役立つよう、 Azure ランディング ゾーン、その 設計原則、および 設計領域を理解します。
記事のレイアウト
| アーキテクチャ | 設計上の決定 | Azure Well-Architected Framework のアプローチ |
|---|---|---|
| ▪ アーキテクチャの図 ▪ ワークロード リソース ▪ フェデレーション リソース |
▪ サブスクリプションの設定 ▪ ネットワーク ▪ データ サイエンティストのアクセス ▪ リソースの監視 ▪ 組織のガバナンス ▪ 変更管理 |
▪ 信頼性 ▪ セキュリティ ▪ コストの最適化 ▪ オペレーショナル エクセレンス ▪ パフォーマンス効率 |
ヒント
Azure AI Foundry Agent Service のチャット ベースラインリファレンス実装は、この記事で説明されているベスト プラクティスを示しています。 設計上の決定を選択して実装する前に、これらのデプロイ リソースを確認して試してください。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
コンポーネント
すべての Azure ランディング ゾーン アーキテクチャは、プラットフォーム チームとワークロード チームの間で所有権を分離します。これは サブスクリプションの民主化と呼ばれます。 アプリケーション アーキテクト、データ サイエンティスト、DevOps チームは、この部門を明確に理解して、直接的な影響や制御の下にあるものとそうでないものを判断する必要があります。
ほとんどのアプリケーション ランディング ゾーンの実装と同様に、ワークロード チームは主に、このアーキテクチャの AI サービスを含むワークロード コンポーネントの構成、デプロイ、監視を管理します。
ワークロード チーム所有のリソース
次のリソースは、 ベースライン アーキテクチャとほとんど変わりません。
Azure AI Foundry アカウントとプロジェクト を使用すると、ワークロード チームは、生成 AI モデルをサービスとしてホストし、コンテンツの安全性を実装し、ナレッジ ソースとツールへのワークロード固有の接続を確立できます。
組織の AI センター オブ エクセレンスが AI モデルのデプロイへのアクセスを制限している場合、ワークロード チームはプロジェクトやアカウントでモデルをホストしない可能性があります。 代わりに、 一元化された AI リソースを使用する必要がある場合があります。 このシナリオでは、すべてのモデル消費は、通常、AI プラットフォーム チームが提供するゲートウェイを通過します。
この記事では、このシナリオの生成 AI モデルがワークロード所有のリソースであることを前提としています。 そうでない場合は、モデル ホストまたはモデルへのゲートウェイがワークロードの依存関係になります。 プラットフォーム チームは、API への信頼性の高いネットワーク接続を維持する必要があります。
Foundry Agent Service は、モデルの依存関係を特定の方法で処理するため、一元的にホストされるモデルを使用するときに課題が発生する可能性があります。 代替オーケストレーターを使用することが必要になる場合があります。
Foundry Agent Service は、チャット操作用のオーケストレーション レイヤーを提供します。 ユーザー要求を処理するチャット エージェントをホストおよび管理します。
このアーキテクチャでは、 標準エージェントのセットアップ を使用します。 エージェントをスポーク仮想ネットワーク内の専用サブネットに接続し、接続サブスクリプション経由でエグレス トラフィックをルーティングします。
ワークロード チームは、エージェントの状態、チャット履歴、およびファイル ストレージ用の専用の Azure リソースを提供します。 これらのリソースは、NoSQL、Azure Storage、Azure AI Search 用の AzureCosmos DB です。 Foundry Agent Service インスタンスは、これらのリソースとそのデータを排他的に管理します。 ワークロード内の他のアプリケーション コンポーネントや組織内の他のワークロードでは、それらを使用しないでください。
Azure App Service は、チャット ユーザー インターフェイス (UI) を含む Web アプリケーションをホストします。 App Service には、異なる Azure ゾーンに 3 つのインスタンスがあります。
Azure Storage アカウントは、Web アプリケーションのコードを ZIP ファイルとしてホストし、App Service 内にマウントします。
AI Search は、アプリケーション ユーザー クエリの関連するインデックス付きデータを取得します。 AI Search は、 検索拡張生成パターンのワークロード ナレッジ ストアとして機能します。 このパターンでは、プロンプトから適切なクエリを抽出し、AI Search にクエリを実行し、その結果を生成 AI 基盤モデルのグラウンド データとして使用します。
Azure Application Gateway は 、App Service でホストされているチャット UI にユーザー要求をルーティングするリバース プロキシとして機能します。 選択した SKU では、悪意のある可能性のあるトラフィックからフロントエンド アプリケーションを保護するために、Azure Web アプリケーション ファイアウォールもホストされます。
Azure Key Vault には 、アプリケーション ゲートウェイのトランスポート層セキュリティ (TLS) 証明書が格納されます。
Azure Monitor、Azure Monitor ログ、Application Insights は、 監視データを収集、格納、視覚化します。
Azure Policy では 、ワークロード固有のポリシーを適用して、大規模な制御の管理、セキュリティ保護、適用に役立ちます。
ワークロード チームは、次のリソースも保持します。
スポーク仮想ネットワーク サブネットとそれらのサブネット上のネットワーク セキュリティ グループ (NSG) は 、セグメント化を維持し、トラフィック フローを制御します。
プライベート エンドポイントは、 サービスとしてのプラットフォーム (PaaS) ソリューションへの接続をセキュリティで保護します。
プラットフォーム チーム所有のリソース
プラットフォーム チームは、次の一元化されたリソースを所有し、維持します。 このアーキテクチャでは、これらのリソースが事前にプロビジョニングされ、それらを依存関係として扱うことを前提としています。
ハブ ネットワーク内の Azure Firewall は、エージェント トラフィックを含め、ワークロードから送信されるエグレス トラフィックをルーティング、検査、および制限します。 ワークロードのエグレス トラフィックは、インターネット、クロスプレミスの宛先、または他のアプリケーションのランディング ゾーンに流れていきます。
ベースラインからの変更: ベースライン アーキテクチャでは、ワークロード チームがこのコンポーネントを所有しています。 このアーキテクチャでは、プラットフォーム チームが接続サブスクリプションで管理します。
ハブ ネットワーク内の Azure Bastion は、ワークロード コンポーネントへの安全な運用アクセスを提供し、Azure AI Foundry コンポーネントへのアクセスを許可します。
ベースラインからの変更: ベースライン アーキテクチャでは、ワークロード チームがこのコンポーネントを所有しています。
スポーク仮想ネットワーク は、ワークロードがデプロイされる場所です。
ベースラインからの変更: ベースライン アーキテクチャでは、ワークロード チームがこのネットワークを所有しています。
ユーザー定義ルート (UDR) は 、ハブ ネットワークへのトンネリングを強制します。
ベースラインからの変更: ベースライン アーキテクチャでは、ワークロード チームがこのネットワークを所有しています。
Azure Policy ベースのガバナンス制約 と
DeployIfNotExists(DINE) ポリシーは、ワークロード サブスクリプションに適用されます。 これらのポリシーは、プラットフォーム チーム所有の管理グループ レベルで、またはワークロードのサブスクリプションに直接適用できます。ベースラインからの変更: これらのポリシーは、このアーキテクチャで新規のものです。 プラットフォーム チームは、ワークロードを制限するポリシーを適用します。 一部のポリシーは、既存のワークロード制約を複製したり、新しい制約を導入したりする可能性があります。
Azure プライベート DNS ゾーンは、 プライベート エンドポイントの
Aレコードをホストします。 詳細については、 Azure Private Link と DNS の大規模な統合に関するページを参照してください。ベースラインからの変更: ベースライン アーキテクチャでは、ワークロード チームがこのネットワークを所有しています。 このアーキテクチャでは、プラットフォーム チームは接続サブスクリプションでこのコンポーネントを管理します。
DNS 解決サービス は、スポーク仮想ネットワークとクロスプレミス ワークステーションをサポートします。 このサービスでは、通常、DNS プロキシまたは Azure DNS プライベート リゾルバーとして Azure Firewall が使用されます。 このアーキテクチャでは、サービスはスポークからのすべての DNS 要求のプライベート エンドポイント DNS レコードを解決します。 Foundry Agent Service の DNS 解決特性により、プラットフォーム チームがこのアーキテクチャ解決要件を有効にするための推奨される方法は、DNS プライベート リゾルバーとリンクされたルールセットです。
Azure DDoS Protection は、 分散攻撃からパブリック IP アドレスを保護するのに役立ちます。
ベースラインからの変更: ベースライン アーキテクチャでは、ワークロード チームが DDoS Protection を購入します。
Von Bedeutung
Azure ランディング ゾーンは、プラットフォーム ランディング ゾーン サブスクリプションの一部として、上記のリソースの一部を提供します。 ワークロード サブスクリプションは、他のリソースを提供します。 これらのリソースの多くは接続サブスクリプションに存在します。これには、Azure ExpressRoute、Azure VPN Gateway、DNS プライベート リゾルバーも含まれます。 これらのリソースは、クロスプレミス アクセスと名前解決を提供します。 これらのリソースの管理は、この記事の範囲外です。
サブスクリプションの設定
ワークロード チームは、このアーキテクチャを実装するために、プラットフォーム チームに特定のランディング ゾーン要件を通知する必要があります。 また、プラットフォーム チームは、その要件をワークロード チームに伝える必要があります。
たとえば、ワークロード チームは、必要なネットワーク領域に関する詳細情報を提供する必要があります。 プラットフォーム チームはこの情報を使用して、必要なリソースを割り当てます。 ワークロード チームは要件を定義し、プラットフォーム チームは仮想ネットワーク内の適切な IP アドレスを割り当てます。
プラットフォーム チームは、ワークロードのビジネスの重要度と技術的なニーズに基づいて管理グループを割り当てます。 たとえば、このアーキテクチャのように、ワークロードがインターネットに公開されている場合、プラットフォーム チームは適切な管理グループを選択します。 ガバナンスを確立するために、プラットフォーム チームは管理グループを構成して実装します。 ワークロード チームは、このガバナンスの制約内でワークロードを設計して運用する必要があります。 一般的な管理グループの区別の詳細については、「 Azure ランディング ゾーン アーキテクチャの調整」を参照してください。
プラットフォーム チームは、このアーキテクチャのサブスクリプションを設定します。 次のセクションでは、サブスクリプションの初期セットアップに関するガイダンスを提供します。
ワークロード要件とフルフィルメント
ワークロード チームとプラットフォーム チームは、管理グループの割り当て、Azure Policy ガバナンス、ネットワーク設定などの詳細について共同作業する必要があります。 プラットフォーム チームとの話し合いと交渉を開始するために、要件のチェックリストを準備します。 次のチェックリストは例として機能します。
| 設計上の考慮事項 | このアーキテクチャのワークロード要件 | |
|---|---|---|
| ☐ | スポーク仮想ネットワークの数とそのサイズ: プラットフォーム チームは、仮想ネットワークを作成して構成した後、それをリージョン ハブにピアリングしてスポークとして指定します。 また、ネットワークが将来のワークロードの増加に対応できるようにする必要もあります。 これらのタスクを効果的に実行するには、必要なスポークの数を把握している必要があります。 | すべてのリソースを単一の専用スポーク仮想ネットワークにデプロイします。 連続 /22 アドレス空間を要求して、大規模な操作やサイド バイ サイドデプロイなどのシナリオをサポートします。 ほとんどの IP アドレスのニーズは、次の要因によって決まります。 - サブネット サイズ (固定サイズ) に対する Application Gateway の要件。 - PaaS サービス用の単一 IP アドレスを持つプライベート エンドポイント (固定サイズ)。 - ビルド エージェント用のサブネット サイズ (固定サイズ)。 - Foundry Agent Service には、 /24 プレフィックス内のサブネットが必要です。 |
| ☐ | 仮想ネットワーク アドレス プレフィックス: 通常、プラットフォーム チームは、既存の規則、ピアリングされたネットワークとの重複の回避、IP アドレス管理 (IPAM) システム内での可用性に基づいて IP アドレスを割り当てます。 | エージェント統合サブネットでは、172.または 192. などの192.168.45.1/24で始まるアドレス プレフィックスを使用する必要があります。 Foundry Agent Service 機能ホストのランタイム制限により、この要件が適用されます。 Foundry Agent Service では、 10.を使用するサブネットはサポートされていません。 エージェント サブネットの有効なアドレス プレフィックスを持つスポークを提供するようにプラットフォーム チームに依頼します。 |
| ☐ | デプロイ リージョン: プラットフォーム チームは、ワークロード リソースと同じリージョンにハブをデプロイする必要があります。 | ワークロードの選択したリージョンと、基になるコンピューティング リソースのリージョンを伝えます。 リージョンが可用性ゾーンをサポートしていることを確認します。 Foundry Models の Azure OpenAI には、リージョンの可用性が制限されています。 |
| ☐ | トラフィックの種類、ボリューム、パターン: プラットフォーム チームは、ワークロードの共有リソースのイングレスとエグレスの要件を決定する必要があります。 | 次の要因に関する情報を提供します。 - ユーザーがこのワークロードをどのように消費するか。 - このワークロードが周囲のリソースをどのように消費するか。 - 構成されるトランスポート プロトコル。 - トラフィック パターン、および想定されるピーク時間帯とオフピーク時間帯。 インターネットへの同時接続の数が多い (おしゃべりな) 場合や、ワークロードで最小限のネットワーク トラフィック (バックグラウンド ノイズ) が生成されると予想される場合に通信します。 |
| ☐ | ファイアウォールの構成: プラットフォーム チームは、正当なエグレス トラフィックを許可するルールを設定する必要があります。 | エージェント トラフィックなど、スポーク ネットワークからの送信トラフィックに関する詳細を共有します。 ビルド エージェントとジャンプ ボックス マシンには、通常の OS 修正プログラムが必要です。 エージェントは、インターネット の接地ソース、ツール、またはワークロードの外部でホストされている他のエージェントとやり取りする必要がある場合があります。 |
| ☐ | 特殊なロールからのイングレス トラフィック: プラットフォーム チームは、指定されたロールにワークロードへのネットワーク アクセスを提供し、適切なセグメント化を実装する必要があります。 | プラットフォーム チームと協力して、次のロールに対して承認されたアクセスを許可する最善の方法を決定します。 - 企業ネットワーク接続上のワークステーションから Azure AI Foundry ポータルにアクセスするデータ サイエンティストと開発者 - ワークロードで管理されるジャンプ ボックスを使用してコンピューティング レイヤーにアクセスする演算子 |
| ☐ |
ワークロードへのパブリック インターネット アクセス: プラットフォーム チームは、リスク評価にこの情報を使用します。これにより、いくつかの決定が行われます。 - 適切なガードレールを持つ管理グループへのワークロードの配置 - ワークロード チームによって報告されたパブリック IP アドレスに対する分散型サービス拒否 (DDoS) 保護 - TLS 証明書の調達と管理 |
イグレス トラフィック プロファイルをプラットフォーム チームに通知します。 - Application Gateway 上のパブリック IP アドレスをターゲットとするインターネットソース トラフィック - TLS 証明書調達のパブリック IP アドレスに関連付けられている完全修飾ドメイン名 (FQDN) |
| ☐ | プライベート エンドポイントの使用: プラットフォーム チームは、プライベート エンドポイント用に Azure プライベート DNS ゾーンを設定し、ハブ ネットワーク内のファイアウォールが DNS 解決を正しく実行するようにする必要があります。 | 次のリソースを含め、プライベート エンドポイントを使用するすべてのリソースについてプラットフォーム チームに通知します。 - AI Search - Azure Cosmos DB for NoSQL - Key Vault - Azure AI Foundry - ストレージ アカウント ハブが DNS 解決をどのように処理するかを理解し、プライベート DNS ゾーン レコードと DNS プライベート リゾルバールールセット リンクの管理に対するワークロード チームの責任を定義します。 |
| ☐ |
一元化された AI リソース: プラットフォーム チームは、モデルとホスティング プラットフォームの予想される使用方法を理解する必要があります。 この情報を使用して、組織内の一元化された AI リソースへのネットワークを確立します。 各組織は独自の AI 導入とガバナンス計画を定義しており、ワークロード チームはこれらの制約内で運用する必要があります。 |
使用する予定の AI と機械学習リソースについてプラットフォーム チームに通知します。 このアーキテクチャでは、Azure AI Foundry、Foundry Agent Service、および Azure AI Foundry でホストされている生成基盤モデルを使用します。 使用する必要がある一元化された AI サービスと、それらの依存関係がワークロードに与える影響を明確に理解します。 |
Von Bedeutung
プラットフォーム チームは、構造化された一連の質問を使用してワークロード チームから情報を収集するサブスクリプションの自動販売機プロセスに従う必要があります。 これらの質問は組織によって異なる場合がありますが、目標は、サブスクリプションを効果的に実装するために必要な入力を収集することです。 詳細については、 「サブスクリプション サービス」を参照してください。
Compute
オーケストレーション レイヤーとチャット UI ホスティングは、 ベースライン アーキテクチャと同じままです。
ネットワーク
ベースライン アーキテクチャでは、ワークロードは 1 つの仮想ネットワークでプロビジョニングされます。
ベースラインからの変更: このアーキテクチャでは、ワークロードが 2 つの仮想ネットワークに分割されます。 1 つのネットワークがワークロード コンポーネントをホストします。 もう 1 つのネットワークは、インターネットとハイブリッド接続を管理します。 プラットフォーム チームは、ワークロードの仮想ネットワークを組織の大規模なネットワーク アーキテクチャと統合する方法を決定します。これは通常、ハブスポーク トポロジに従います。
このアーキテクチャの Visio ファイルをダウンロードします。
ハブ仮想ネットワーク: この仮想ネットワークは、同じリージョン内のワークロード リソースと通信する一元的な共有サービスを含むリージョン ハブとして機能します。 ハブは 接続サブスクリプションに存在します。 プラットフォーム チームがこのネットワークのリソースを所有します。
スポーク仮想ネットワーク: このアーキテクチャでは、ベースライン アーキテクチャの単一の仮想ネットワークが、基本的にスポーク仮想ネットワークになります。 プラットフォーム チームは、このスポーク ネットワークをハブ ネットワークとピアリングします。 ピアリングや DNS 構成など、スポーク ネットワークを所有および管理します。 ワークロード チームは、サブネットを含め、このネットワーク内のリソースを所有しています。 このネットワークには多くの ワークロード リソースが含まれています。
この管理と所有権の分割により、ワークロード チームは ワークロードの要件を プラットフォーム チームに明確に伝える必要があります。
Von Bedeutung
プラットフォーム チームの場合: ワークロードで特に必要な場合を除き、スポーク ネットワークを別のスポーク ネットワークに直接ピアリングしないでください。 この方法では、ワークロードのセグメント化目標を保護します。 チームは、推移的な仮想ネットワーク接続をすべて容易にする必要があります。 ただし、アプリケーションランディングゾーンチームがセルフマネージドプライベートエンドポイントを使用してネットワークに直接接続する場合、チームはこれらの接続を管理しません。
外部チームが管理するワークロード リソースを理解します。 たとえば、チャット エージェントと、別のチームが管理するグラウンド コンテキスト ベクター データベースの間のネットワーク接続を理解します。
仮想ネットワーク サブネット
スポーク仮想ネットワークでは、ワークロードの要件に基づいてサブネットを作成して割り当てます。 セグメント化を提供するには、サブネットとの間のトラフィックを制限する制御を適用します。 このアーキテクチャでは、 ベースライン アーキテクチャのサブネットを超えるサブネットは追加されません。 ただし、プラットフォーム チームがサブスクリプションでこの機能をホストする可能性が高いため、ネットワーク アーキテクチャでは、 AzureBastionSubnet または AzureFirewallSubnet サブネットは不要になります。
Azure ランディング ゾーンにワークロードをデプロイするときは、依然としてローカル ネットワーク制御を実装する必要があります。 組織では、データ流出から保護し、中央セキュリティ 運用センターと IT ネットワーク チームの可視性を確保するために、さらにネットワーク制限を課す場合があります。
イングレス トラフィック
イングレス トラフィック フローは、ベースライン アーキテクチャと同じままです。
ワークロードへのパブリック インターネットイングレスに関連するリソースを管理します。 たとえば、このアーキテクチャでは、Application Gateway とそのパブリック IP アドレスは、ハブ ネットワークではなくスポーク ネットワークに存在します。 一部の組織では、一元化された境界ネットワーク (DMZ、非武装地帯、スクリーン サブネットとも呼ばれます) の実装を使用して、イングレスに接続されたリソースを接続サブスクリプションに配置します。 その特定のトポロジとの統合は、この記事の範囲外です。
受信トラフィックを検査する代替アプローチ
このアーキテクチャでは、受信トラフィックを検査するために Azure Firewall を使用しませんが、組織のガバナンスで必要になることもあります。 このような場合、プラットフォーム チームは、侵入検出と防止の追加レイヤーをワークロード チームに提供する実装をサポートします。 このレイヤーは、不要な受信トラフィックをブロックするのに役立ちます。 このトポロジをサポートするには、このアーキテクチャにより多くの UDR 構成が必要です。 詳細については、「 Azure Firewall と Application Gateway を使用した Web アプリケーションのゼロ トラスト ネットワーク」を参照してください。
DNS の構成
ベースライン アーキテクチャでは、すべてのコンポーネントが DNS 解決に直接 Azure DNS を使用します。
ベースラインからの変更: このアーキテクチャでは、通常、ハブ内の 1 つ以上の DNS サーバーが DNS 解決を実行します。 仮想ネットワークが作成されると、それに応じて仮想ネットワーク上の DNS プロパティが既に設定されている必要があります。 ワークロード チームは、DNS サービスの実装の詳細を理解する必要はありません。
このアーキテクチャでは、次の方法で DNS を使用してワークロード コンポーネントを構成します。
| コンポーネント | DNS の構成 |
|---|---|
| Application Gateway | 仮想ネットワークから継承 |
| App Service (チャット UI) | 仮想ネットワークから継承 |
| AI検索 | オーバーライドできない、Azure DNS を使用する |
| Azure AI Foundry | オーバーライドできない、Azure DNS を使用する |
| ファウンドリー エージェント サービス | オーバーライドできない、Azure DNS を使用する |
| Azure Cosmos DB | オーバーライドできない、Azure DNS を使用する |
| ジャンプ ボックス | 仮想ネットワークから継承 |
| ビルド エージェント | 仮想ネットワークから継承 |
このアーキテクチャでは、送信通信を開始しないコンポーネントの DNS 設定は構成されません。 これらのコンポーネントには DNS 解決は必要ありません。
このアーキテクチャの多くのコンポーネントは、ハブの DNS サーバーでホストされている DNS レコードに依存して、このワークロードのプライベート エンドポイントを解決します。 詳細については、「 Azure プライベート DNS ゾーン」を参照してください。
ハブベースの DNS 解決が不可能な場合、これらのコンポーネントには次の制限があります。
プラットフォーム チームは DNS 要求をログに記録できません。これは、組織のセキュリティ チームの要件に違反する可能性があります。
ランディング ゾーンまたはその他のアプリケーションランディングゾーンで Private Link で公開されているサービスへの解決は不可能な場合があります。
プラットフォーム チームが DNS をどのように管理するかを理解しておくことをお勧めします。 詳細については、「Private Link と DNS の大規模な統合」を参照してください。 Azure DNS に直接依存するコンポーネント機能を追加すると、プラットフォームによって提供される DNS トポロジに複雑さが生じる可能性があります。 複雑さを最小限に抑えるために、コンポーネントの再設計や例外のネゴシエートを行うことができます。
エグレス トラフィック
ベースライン アーキテクチャでは、すべてのエグレス トラフィックが Azure Firewall 経由でインターネットにルーティングされます。
ベースラインからの変更: このアーキテクチャでは、プラットフォームは、ホストする Azure Firewall インスタンスを指す UDR を提供します。 この UDR をベースライン アーキテクチャの同じサブネットに適用します。
エージェント統合サブネットからのトラフィックを含め、スポーク仮想ネットワークを離れるすべてのトラフィックは、エグレス ファイアウォール経由でピアリングされたハブ ネットワークを経由して再ルーティングされます。
このアーキテクチャの Visio ファイルをダウンロードします。
Key Vault、Azure AI Foundry、およびその他のサービスのプライベート エンドポイントへの東西クライアント通信は、 ベースライン アーキテクチャと同じままです。 上の図には、そのパスは含まれていません。
ファイアウォールへのインターネット トラフィックのルーティング
スポーク ネットワーク内のすべてのサブネットには、すべてのインターネットにバインドされたトラフィック (または 0.0.0.0/0 トラフィック) をハブの Azure Firewall インスタンスに転送するルートが含まれます。
| コンポーネント | インターネット トラフィックをハブ経由で強制するメカニズム |
|---|---|
| Application Gateway | なし。 このサービスから送信されたインターネットにバインドされたトラフィックは、プラットフォーム チームのファイアウォールを介して強制することはできません。 |
| App Service (チャット UI) | リージョン仮想ネットワーク統合 と vnetRouteAllEnabled 設定が有効になっています。 |
| AI検索 | なし。 このサービスから送信されたトラフィックを強制的に、ファイアウォールを通過させることはできません。 このアーキテクチャではスキルは使用されません。 |
| ファウンドリー エージェント サービス | snet-agentsEgress サブネットに適用される UDR。 |
| ジャンプ ボックス | snet-jumpbox サブネットに適用される UDR。 |
| ビルド エージェント | snet-agents サブネットに適用される UDR。 |
このアーキテクチャでは、送信通信を開始しないコンポーネントの強制トンネリングは構成されません。
ハブ経由でエグレス トラフィックをルーティングできないコンポーネントまたは機能の場合、ワークロード チームは組織の要件に合わせる必要があります。 これらの要件を満たすには、補正コントロールを使用するか、サポートされていない機能を除外するようにワークロードを再設計するか、正式な例外を要求します。 データ流出と不正使用を軽減する責任があります。
サブネットに送信トラフィックがあるとは思わない場合でも、プラットフォームによって提供されるインターネット ルートをすべてのサブネットに適用します。 この方法により、そのサブネット内の予期しないデプロイで、定期的なエグレス フィルター処理が行われます。 プライベート エンドポイントを含むサブネットの場合は、ネットワーク ポリシーで完全なルーティングと NSG 制御をサポートできるようにします。
このルート構成により、App Service、Azure AI Foundry およびそのプロジェクト、およびワークロードの仮想ネットワークから送信されたその他のサービスからのすべての送信接続が検査および制御されます。
Azure プライベート DNS ゾーン
東西トラフィックにプライベート エンドポイントを使用するワークロードには、構成された DNS プロバイダーの DNS ゾーン レコードが必要です。 Private Link をサポートするために、このアーキテクチャは、Key Vault、Azure AI Foundry、Azure Storage などのサービスに対して多くの DNS ゾーン レコードに依存しています。
ベースラインからの変更: ベースライン アーキテクチャでは、ワークロード チームがプライベート DNS ゾーンを直接管理します。 このアーキテクチャでは、プラットフォーム チームは通常、プライベート DNS ゾーンを維持します。 ワークロード チームは、プラットフォーム チームの要件と、プライベート DNS ゾーン レコードの管理に対する期待を明確に理解する必要があります。 プラットフォーム チームは、プライベート DNS ゾーン レコードの代わりに他のテクノロジを使用できます。
このアーキテクチャでは、プラットフォーム チームは、次の Azure AI Foundry FQDN API エンドポイントの DNS を設定する必要があります。
privatelink.services.ai.azure.comprivatelink.openai.azure.comprivatelink.cognitiveservices.azure.com
プラットフォーム チームは、Foundry Agent Service の依存関係である次の FQDN の DNS も設定する必要があります。
privatelink.search.windows.netprivatelink.blob.core.windows.netprivatelink.documents.azure.com
Von Bedeutung
Foundry Agent Service の機能ホストをデプロイする前、および Foundry Agent Service の操作中に、DNS 解決がスポーク仮想内から正しく機能する必要があります。 Foundry Agent Service の機能では、スポーク仮想ネットワークの DNS 構成は使用されません。 そのため、プラットフォーム チームは、DNS プライベート リゾルバーでワークロードのプライベート DNS ゾーンのルールセットを構成し、それらのルールをアプリケーション ランディング ゾーン スポークにリンクすることをお勧めします。
Azure AI Foundry とそのエージェント機能をデプロイする前に、Foundry Agent Service の依存関係がスポーク ネットワーク内からプライベート エンドポイントに完全に解決できるようになるまで待つ必要があります。 この要件は、DINE ポリシーが DNS プライベート ゾーンの更新を処理する場合に特に重要です。 プライベート DNS レコードがサブネット内から解決される前に Foundry Agent Service 機能をデプロイしようとすると、デプロイは失敗します。
プラットフォーム チームは、このアーキテクチャ内の他のワークロード依存関係のプライベート DNS ゾーンもホストする必要があります。
privatelink.vaultcore.azure.netprivatelink.azurewebsites.net
データ サイエンティストとエージェントの開発者アクセス
ベースライン アーキテクチャと同様に、このアーキテクチャにより、Azure AI Foundry ポータルやその他のブラウザー ベースのエクスペリエンスへのパブリック イングレス アクセスが無効になります。 ベースライン アーキテクチャでは、ジャンプ ボックスをデプロイして、さまざまなワークロード ロールが使用する仮想ネットワークからのソース IP アドレスをブラウザーに提供します。
ワークロードが Azure ランディング ゾーンに接続すると、チームはより多くのアクセス オプションを利用できます。 プラットフォーム チームと協力して、仮想マシン (VM) を管理せずに、さまざまなブラウザーベースの Azure AI Foundry ポータルにプライベート アクセスできるかどうかを確認します。 このアクセスは、既存の ExpressRoute または VPN Gateway 接続からの推移的なルーティングを通じて可能な場合があります。
ネイティブ ワークステーション ベースのアクセスには、クロスプレミスのルート指定と DNS 解決が必要であり、プラットフォーム チームがこれを提供するのを支援できます。 サブスクリプションの自動販売機要求にこの要件を含めます。
これらのポータルへのネイティブ ワークステーション ベースのアクセスを提供すると、VM ジャンプ ボックスの管理と比較して生産性が向上し、メンテナンスが簡素化されます。
ジャンプ ボックスの役割
このアーキテクチャのジャンプ ボックスは、実行時や AI と機械学習の開発ではなく、運用サポートの価値を提供します。 ジャンプ ボックスは、外部からアクセスできないコンポーネントへの内部ネットワーク アクセスを提供するため、これを使用することで DNS やネットワーク ルーティングの問題をトラブルシューティングできます。
ベースライン アーキテクチャでは、Azure Bastion が管理するジャンプ ボックスにアクセスします。
このアーキテクチャでは、Azure Bastion は、プラットフォーム チームが管理する共有リージョン リソースとして接続サブスクリプションにデプロイされます。 このアーキテクチャのユース ケースを示すために、Azure Bastion は接続サブスクリプションにあり、チームはそれをデプロイしません。
ジャンプ ボックスとして機能する VM は、VM の組織の要件に準拠している必要があります。 これらの要件には、Microsoft Entra ID の企業 ID、特定の基本イメージ、修正プログラムの適用管理方法などの項目が含まれる場合があります。
リソースの監視
Azureランディング ゾーン プラットフォームでは、管理サブスクリプションの一部として共有監視リソースが提供されます。 ただし、ワークロードの所有権の責任を容易にするために、独自の監視リソースをプロビジョニングすることをお勧めします。 このアプローチは、 ベースライン アーキテクチャに合わせて調整されます。
次の監視リソースをプロビジョニングします。
Application Insights は、チームのアプリケーション パフォーマンス管理 (APM) サービスとして機能します。 このサービスは、チャット UI、Foundry Agent Service、およびモデルで構成します。
Azure Monitor ログ ワークスペースは、ワークロード所有の Azure リソースからのすべてのログとメトリックの統合シンクとして機能します。
ベースライン アーキテクチャと同様に、すべてのリソースは、チームがプロビジョニングする Azure Monitor ログ ワークスペースに Azure 診断ログを送信する必要があります。 この構成は、リソースのコードとしてのインフラストラクチャ (IaC) デプロイの一部です。 また、中央の Azure Monitor ログ ワークスペースにログを送信する必要がある場合もあります。 Azure ランディング ゾーンでは、通常、そのワークスペースは管理サブスクリプションに存在します。
プラットフォーム チームには、アプリケーション ランディング ゾーン内のリソースに影響を与えるプロセスが増える可能性があります。 たとえば、DINE ポリシーを使用して診断を構成し、一元管理サブスクリプションにログを送信します。 また、ポリシーを使用して Azure Monitor ベースライン アラートを適用することもできます 。 実装によって、これらの追加のログ記録とアラート フローがブロックされないようにします。
Azure Policy
ベースライン アーキテクチャでは、ワークロードの管理に役立つ 一般的なポリシー が推奨されます。 このアーキテクチャをアプリケーションランディングゾーンにデプロイする場合、追加のポリシーを追加または削除する必要はありません。 ガバナンスを適用し、このワークロードのセキュリティを強化するために、サブスクリプション、リソース グループ、またはリソースに引き続きポリシーを適用します。
ワークロードをデプロイする前であっても、アプリケーションランディングゾーンのサブスクリプションに既存のポリシーがあることを想定してください。 ポリシーの中には、デプロイにおいて特定の構成を監査またはブロックすることで、組織的なガバナンスに役立つものもあります。
次のポリシー例は、ワークロードのデプロイの複雑さにつながる可能性があります。
Policy:Secrets [in Key Vault] には、指定された最大有効期間が必要です。
錯綜： Azure AI Foundry は、接続された Key Vault にナレッジとツールの接続に関連するシークレットを格納できます。 これらのシークレットには、サービスによって設定された有効期限はありません。 ベースライン アーキテクチャでは、これらの種類の接続は使用されませんが、アーキテクチャを拡張してサポートすることができます。
Policy:AI Search サービスでは、保存データを暗号化するためにカスタマー マネージド キーを使用する必要があります。
錯綜： このアーキテクチャでは、カスタマー マネージド キーは必要ありません。 ただし、アーキテクチャを拡張してサポートすることもできます。
Policy:AI Foundry モデルをプレビューにすることはできません。
錯綜： 運用環境のワークロードでエージェント機能を有効にした時点で一般公開される予定のプレビュー モデルを使用して、開発中である可能性があります。
プラットフォーム チームは、アプリケーション ランディング ゾーン サブスクリプションへの自動デプロイを処理するために、DINE ポリシーを適用する場合があります。 プラットフォームによって開始される制限と変更を、IaC テンプレートに事前に組み込み、テストします。 プラットフォーム チームがアプリケーションの要件と競合する Azure ポリシーを使用している場合は、解決策をネゴシエートできます。
時間と共に変更を管理する
このアーキテクチャでは、プラットフォームによって提供されるサービスと操作が外部の依存関係として機能します。 プラットフォーム チームは引き続き変更の適用、ランディング ゾーンのオンボード、コスト管理の適用を行います。 プラットフォーム チームは、個々のワークロードに優先順位を付けない場合があります。 ファイアウォールの変更など、これらの依存関係に対する変更は、複数のワークロードに影響を及ぼす可能性があります。
すべての外部依存関係を管理するには、効率的かつタイムリーにプラットフォーム チームと通信する必要があります。 ワークロードに悪影響を及ぼさないように、事前に変更をテストすることが重要です。
ワークロードに影響するプラットフォームの変更
このアーキテクチャでは、プラットフォーム チームが次のリソースを管理します。 これらのリソースに対する変更は、ワークロードの信頼性、セキュリティ、運用、およびパフォーマンスのターゲットに影響する可能性があります。 プラットフォーム チームがそれらを実装する前に、これらの変更を評価して、ワークロードに与える影響を判断します。
Azure ポリシー: Azure ポリシーの変更は、ワークロード リソースとその依存関係に影響する可能性があります。 これらの変更には、直接ポリシーの更新や、ランディング ゾーンの新しい管理グループ階層への移動が含まれる場合があります。 これらの変更は、新しいデプロイが発生するまで気付かない可能性があるため、十分にテストする必要があります。
例： ポリシーでは、カスタマー マネージド キー暗号化を必要とする Azure Cosmos DB インスタンスのデプロイが許可されなくなり、アーキテクチャでは Microsoft マネージド キー暗号化が使用されます。
ファイアウォール規則: ファイアウォール規則の変更は、ワークロードの仮想ネットワークまたはすべてのトラフィックに広く適用される規則に影響を与える可能性があります。 これらの変更により、トラフィックがブロックされたり、プロセスのサイレント障害につながったりすることさえあります。 これらの潜在的な問題は、エグレス ファイアウォールと Azure Virtual Network Manager が適用する NSG 規則の両方に当てはまるものです。
例： Bing API へのトラフィックがブロックされると、インターネットの接地データに対するエージェント ツールの呼び出しが失敗します。
ハブ ネットワークでのルーティング: ハブでのルーティングの推移的本質の変化は、ワークロードが他の仮想ネットワークへのルーティングに依存している場合、ワークロードの機能に影響する可能性があります。
例： ルーティングの変更により、Azure AI Foundry エージェントが別のチームによって運営されているベクター ストアにアクセスできなくなるか、データ サイエンス チームがワークステーションから AI Foundry ポータルにアクセスできなくなります。
Azure Bastion ホスト: Azure Bastion ホストの可用性や構成に対する変更。
例: 構成の変更により、ジャンプ ボックスへのアクセスとエージェント VM のビルドが禁止されます。
プラットフォームに影響するワークロードの変更
次の例では、プラットフォーム チームに伝える必要があるワークロードの変更について説明します。 プラットフォーム チームは、新しい変更を有効にする前に、プラットフォーム サービスの信頼性、セキュリティ、運用、パフォーマンスの目標を検証する必要があります。
ネットワーク エグレス: ネットワーク エグレスの大幅な増加を監視して、ネットワーク デバイスでワークロードがノイズの多いネイバーにならないようにします。 この問題は、他のワークロードのパフォーマンスまたは信頼性のターゲットに影響する可能性があります。 このアーキテクチャはほとんど自己完結型であり、送信トラフィック パターンに大きな変化が生じる可能性は低いです。
パブリック アクセス: ワークロード コンポーネントのパブリック アクセスを変更するには、追加のテストが必要になる場合があります。 プラットフォーム チームは、ワークロードを別の管理グループに再配置する場合があります。
例: このアーキテクチャでは、Application Gateway からパブリック IP アドレスを削除し、このアプリケーションを内部のみにした場合、ワークロードによるインターネットへの公開が変更されます。 もう 1 つの例は、ブラウザーベースの AI ポータルをインターネットに公開することですが、これはお勧めしません。
ビジネスの重要度の評価: ワークロードのサービス レベル アグリーメント (SLA) を変更するには、プラットフォームチームとワークロード チーム間の新しいコラボレーション アプローチが必要になる場合があります。
例： 導入と成功の増加により、ワークロードが低いビジネスから高いビジネスに重大に移行する可能性があります。
エンタープライズ アーキテクチャ チーム
一部の組織には、ワークロードとそのアーキテクチャの設計に影響を与える可能性があるエンタープライズ アーキテクチャ チームがあります。 そのチームは、企業の AI 導入 戦略と、Azure 設計上の AI ワークロード の原則と推奨事項を理解しています。 このチームと協力して、このチャット ワークロードがシナリオ固有の目標を満たし、組織の戦略と推奨事項に合っていることを確認します。
考慮事項
これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「 Well-Architected Framework」を参照してください。
信頼性
信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。
このアーキテクチャでは、 ベースライン アーキテクチャでの信頼性の保証が維持されます。 コア ワークロード コンポーネントの新しい信頼性に関する考慮事項は導入されていません。
重要な依存関係
プラットフォームとアプリケーションのランディング ゾーンでワークロードが実行するすべての機能を依存関係として扱います。 各依存関係の連絡方法とエスカレーション パスを含むインシデント対応計画を維持します。 これらの依存関係をワークロードの障害モード分析 (FMA) に含めます。
次のワークロードの依存関係と、発生する可能性があるシナリオの例を考えてみましょう。
エグレス ファイアウォール: 一元化されたエグレス ファイアウォールは、ワークロードとは無関係に変更されます。 複数のワークロードがファイアウォールを共有します。
DNS 解決: このアーキテクチャでは、プラットフォーム チームが提供する DNS をほとんどのリソースに使用し、Foundry Agent Service の Azure DNS およびリンクされた DNS プライベート リゾルバー ルールセットと組み合わせて使用します。 その結果、ワークロードは、プライベート エンドポイントの DNS レコードのタイムリーな更新と DNS サービスの可用性に依存します。
DINE ポリシー: Azure プライベート DNS ゾーンまたはその他のプラットフォームによって提供される依存関係に対する DINE ポリシーは、 ベスト エフォート ベースで動作し、SLA は含まれません。 たとえば、このアーキテクチャのプライベート エンドポイントの DNS 構成が遅れていると、チャット UI がトラフィック対応になるのを防いだり、エージェントが Foundry Agent Service クエリを完了できなくなる可能性があります。
管理グループ ポリシー: 環境間の一貫性のあるポリシーは、信頼性をサポートします。 実稼働前環境が運用環境と一致することを確認して、正確なテストを提供し、デプロイまたはスケールをブロックできる環境固有の逸脱を防ぎます。 詳細については、「Azure ランディング ゾーンでのアプリケーション開発環境の管理」を参照してください。
これらの考慮事項の多くは、Azure ランディング ゾーンがない場合があります。 これらの問題に対処し、すべての要件を確実に満たすために、プラットフォーム チームと協力して作業する必要があります。 詳細については、「依存関係の 識別」を参照してください。
セキュリティ
セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。 詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。
イグレス トラフィック制御
組織内の他のワークロード スポークからワークロードを分離するには、サブネットに NSG を適用し、リージョン ハブの非推移的な性質または制御を使用します。 アプリケーションとそのインフラストラクチャの受信ネットワーク要件のみを許可する包括的な NSG を構築します。 セキュリティのために、ハブ ネットワークの非推移的本質だけに依存しないことをお勧めします。
プラットフォーム チームは、セキュリティのための Azure ポリシーを実装します。 たとえば、ポリシーによって、確実に Application Gateway の Web アプリケーション ファイアウォールを 拒否モードに設定し、サブスクリプションで使用できるパブリック IP アドレスの数が制限されるようにできます。 これらのポリシーに加えて、イングレス セキュリティ体制を強化するワークロード中心のポリシーをデプロイする必要があります。
次の表に、このアーキテクチャのイングレス コントロールの例を示します。
| 情報源 | 目的 | ワークロード制御 | プラットフォーム制御 |
|---|---|---|---|
| インターネット | アプリケーション トラフィック フロー | パブリック トラフィックがチャット UI のプライベート トラフィックに移行することを許可する前に、NSG、Web アプリケーション ファイアウォール、ルーティング規則を介してすべてのワークロード要求をファネルします。 | 無し |
| インターネット | Azure AI Foundry ポータルアクセスとデータ プレーン REST API アクセス | サービス レベルの構成を通じてすべてのアクセスを拒否します。 | 無し |
| インターネット | Application Gateway を除くすべてのサービスへのデータ プレーン アクセス | NSG ルールとサービス レベルの構成を使用して、すべてのアクセスを拒否します。 | 無し |
| Azure Bastion | ジャンプ ボックスとビルド エージェント アクセス | ソースがプラットフォームの指定された Azure Bastion サブネットでない限り、リモート アクセス ポートへのすべてのトラフィックをブロックする NSG をジャンプ ボックス サブネットに適用します。 | 無し |
| クロスプレミス | Azure AI Foundry ポータルアクセスとデータ プレーン REST API アクセス | すべてのアクセスを拒否します。 ジャンプ ボックスを使用しない場合は、データ サイエンティストの許可されたサブネット内のワークステーションからのアクセスのみを許可します。 | 非トランザクション ルーティングを適用するか、Azure Virtual WAN のセキュリティで保護されたハブで Azure Firewall を使用する |
| その他のスポーク | 無し | NSG ルールを介してブロックします。 | 仮想 WAN のセキュリティで保護されたハブで非推移的ルーティングを適用するか、Azure Firewall を使用する |
エグレス トラフィック制御
ソリューションの必要な送信接続要件を表す NSG ルールを適用し、それ以外をすべて拒否します。 ハブ ネットワークコントロールだけに依存しないでください。 ワークロード オペレーターは、望ましくないエグレス トラフィックを可能な限りソースの近くで停止する必要があります。
仮想ネットワーク内でワークロードのサブネットを所有しているが、プラットフォーム チームは、キャプチャした要件をサブスクリプションの自動販売機プロセスの一部として具体的に表すファイアウォール規則を作成した可能性があります。 アーキテクチャの有効期間中のサブネットとリソースの配置の変更が、元の要求と互換性を保っていることを確認します。 ネットワーク チームと協力して、最低アクセス数のイグレス制御の継続性を確保してください。
次の表に、このアーキテクチャのエグレス コントロールの例を示します。
| エンドポイント | 目的 | ワークロード制御 | プラットフォーム制御 |
|---|---|---|---|
| パブリック インターネット ソース | エージェントでは、Foundry Models 要求で Azure OpenAI を作成するためにインターネット検索が必要になる場合があります | エージェント統合サブネットに NSG を適用する | 外部ナレッジ ストアとツールにファイアウォール アプリケーション規則を適用する |
| Azure AI Foundry データ プレーン | チャット UI がチャット エージェントと対話する | App Service 統合サブネットから Azure AI Foundry プライベート エンドポイント サブネットへの TCP/443 を許可する | 無し |
| Azure Cosmos DB | Foundry Agent Service からメモリ データベースにアクセスするには | Azure Cosmos DB プライベート エンドポイント サブネットへのすべてのポートで TCP を許可する | 無し |
ワークロードの仮想ネットワークを離れるトラフィックの場合、このアーキテクチャでは、NSG 経由のワークロード レベルと、ハブ ネットワーク ファイアウォール経由のプラットフォーム レベルで制御が適用されます。 NSG は、初期の広範なネットワーク トラフィック ルールを提供します。 プラットフォームのハブでは、ファイアウォールによってセキュリティを強化するためのより具体的な規則が適用されます。
このアーキテクチャでは、ハブ ネットワークを経由してルーティングするために、Foundry Agent Service とその依存 AI Search インスタンスなどの内部コンポーネント間の東西トラフィックは必要ありません。
DDoS Protection
ソリューションのパブリック IP アドレスをカバーする DDoS Protection プランを適用するユーザーを決定します。 プラットフォーム チームは、IP アドレス保護プランを使用するか、Azure Policy を使用して仮想ネットワーク保護プランを適用する場合があります。 このアーキテクチャには、インターネットからのイングレス用のパブリック IP アドレスがあるため、DDoS Protection カバレッジが必要です。 詳細については、 「ネットワークと接続の推奨事項」を参照してください。
ID およびアクセス管理
プラットフォーム チームのガバナンス自動化に追加の制御が必要でない限り、このアーキテクチャでは、プラットフォーム チームが関与しているため、新しい承認要件は導入されません。 Azure ロールベースのアクセス制御 (RBAC) は、最小限の特権の原則を引き続き満たす必要があります。最小限の特権は、必要な場合にのみ、それを必要とする個人にのみ制限付きアクセスを許可します。 詳細については、「ID およびアクセス管理に関する推奨事項」をご覧ください。
証明書と暗号化
チームは通常、Application Gateway でパブリック IP アドレスの TLS 証明書を調達します。 プラットフォーム チームと協力して、証明書の調達と管理のプロセスが組織の期待に沿う方法を理解します。
このアーキテクチャのすべてのデータ ストレージ サービスは、Microsoft が管理する暗号化キーまたはカスタマー マネージド暗号化キーをサポートします。 ワークロードの設計または組織でより詳細な制御が必要な場合は、カスタマー マネージド暗号化キーを使用します。 Azure ランディング ゾーン自体では、特定の方法は必須ではありません。
コストの最適化
コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。
ベースライン アーキテクチャのすべてのコスト最適化戦略は、このアーキテクチャのワークロード リソースに適用されます。
このアーキテクチャは、Azure ランディング ゾーン プラットフォーム リソースから大きなメリットを得られます。 たとえば、Azure Firewall や DDoS Protection などのリソースは、ワークロードからプラットフォーム リソースに移行します。 チャージバック モデルを使用してこれらのリソースを使用する場合でも、追加されたセキュリティとクロスプレミス接続は、それらのリソースを自己管理するよりもコスト効率が高くなります。 プラットフォーム チームの他の一元化されたオファリングを利用して、サービス レベルの目標、目標復旧時間、または目標復旧ポイントを損なうことなく、それらの利点をワークロードに拡張します。
Von Bedeutung
Azure AI Foundry の依存関係をプラットフォーム リソースとして統合してコストを最適化しないでください。 これらのサービスは、ワークロード リソースのままである必要があります。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスのデザイン レビュー チェック一覧」を参照してください。
ベースライン アーキテクチャからのすべてのオペレーショナル エクセレンスに関する考慮事項について、引き続き責任を負います。 これらの責任には、監視、GenAIOps、品質保証、安全なデプロイプラクティスが含まれます。
複数のシンクからのデータを関連付ける
ワークロードの Azure Monitor ログ ワークスペースには、ワークロードのログとメトリックとそのインフラストラクチャ コンポーネントが格納されます。 ただし、中央の Azure Monitor ログ ワークスペースには、多くの場合、Azure Firewall、DNS プライベート リゾルバー、Azure Bastion などの一元化されたサービスからのログとメトリックが格納されます。 複数のシンクからのデータの関連付けは、複雑なタスクになる可能性があります。
相関データは、インシデント対応をサポートするのに役立ちます。 このアーキテクチャのトリアージ Runbook では、この状況に対処し、問題がワークロード リソースを超える場合は、組織の連絡先情報を含める必要があります。 ワークロード管理者は、エンタープライズ ネットワーク、セキュリティ、またはその他のプラットフォーム サービスからのログ・エントリーを関連付けるために、プラットフォーム管理者の支援を必要とする場合があります。
Von Bedeutung
プラットフォーム チームの場合: 可能であれば、関連するプラットフォーム リソースのログ シンクのクエリと読み取りを行う RBAC アクセス許可を付与します。 ネットワークおよびアプリケーション ルールの評価と DNS プロキシのためのファイアウォール ログを有効にします。 アプリケーション チームは、この情報を使用してタスクのトラブルシューティングを行うことができます。 詳細については、「監視と脅威検出に関する推奨事項」を参照してください。
ビルド エージェント
このアーキテクチャの多くのサービスでは、プライベート エンドポイントが使用されます。 ベースライン アーキテクチャと同様に、この設計にはビルド エージェントが必要な場合があります。 チームは、ビルド エージェントを安全かつ確実にデプロイします。 プラットフォーム チームはこのプロセスに関与していません。
ビルド エージェント管理が組織の標準に準拠していることを確認します。 これらの標準には、プラットフォームで承認されたオペレーティング システム イメージの使用、パッチ適用スケジュール、コンプライアンス レポート、ユーザー認証方法が含まれる場合があります。
パフォーマンス効率
パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。 詳細については、「パフォーマンス効率の設計レビュー チェックリスト」を参照してください。
ベースライン アーキテクチャのパフォーマンス効率に関する考慮事項も、このアーキテクチャに適用されます。 チームは、プラットフォーム チームではなく、アプリケーション フロー内のリソースを制御できます。 ワークロードとコストの制約に従って、チャット UI ホスト、言語モデル、およびその他のコンポーネントをスケーリングします。 アーキテクチャの最終的な実装に応じて、パフォーマンス目標に対してパフォーマンスを測定するときは、次の要因を考慮してください。
- エグレスとクロスプレミスの待機時間
- コストコンテインメント ガバナンスからの SKU の制限
このシナリオのデプロイ
この参照アーキテクチャのランディング ゾーンの実装をデプロイします。
貢献者達
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
主要な著者:
- ビラル・アムジャド
|Microsoft クラウド ソリューション アーキテクト - Freddy Ayala | Microsoft クラウド ソリューション アーキテクト
- チャド・キットテル |プリンシパル ソフトウェア エンジニア - Azure パターンとプラクティス
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。
次のステップ
プラットフォーム チームと技術的な詳細を共同作業する方法について説明します。
関連リソース
- Azure での
AI ワークロードに関する Well-Architected Framework の観点