Foundry Agent Service ネットワークの詳細

独自の仮想ネットワーク持ち込み (VNet) Microsoft Foundry Agent Service を実行する場合は、委任されたサブネットのサイズ設定、IP 割り当ての計画、およびエージェント トラフィックがプラットフォームを通過する方法を理解する必要があります。 この記事では、ホストおよびプロンプト エージェントの背後にあるネットワーク アーキテクチャ、IP 割り当てモデル、および容量の問題を示すシグナルについて説明します。 これは、Foundry Agent Service 用に Bring Your Own VNet を既に選択しているクラウドおよびネットワーク アーキテクトを対象としています。 ネットワークを構成するには、「 Foundry Agent Service のプライベート ネットワークを設定する」を参照してください。

GitHub Copilotなどのコーディング エージェントを使用して VNet、サブネット、容量モデルを計画する場合、Microsoft Foundry Skill を使用すると、アーキテクチャを推論し、独自の環境で Foundry ネットワーク ガイダンスを適用できます。

ネットワーク アーキテクチャの概要

次の図は、Foundry Agent Service 要求に関係する 2 つのゾーンを示しています。左側の Microsoft マネージド Foundry プラットフォーム ネットワークと右側の顧客 VNet です。

プラットフォーム ネットワークは、Foundry エンドポイント、ホスト されたエージェントを実行するマイクロ VM ホスト レイヤー、ツール サービス、およびデータ プロキシ ホスト 層をホストします。 顧客の VNet には、委任されたサブネット (Micro VM とデータ プロキシが IP を使用する場所) と、ストレージ、データベース、およびKey Vaultに接続するプライベート エンドポイント サブネットが含まれています。

2 つの要求フローがこのアーキテクチャを走査します。

• ホストエージェント: クライアントからFoundryエンドポイントへ、マイクロVM (/invoke)、Tools Service、データプロキシを通り、プライベートエンドポイントを介して顧客リソースへ。
• プロンプト エージェント: クライアントから Foundry エンドポイント、Tools Service からデータ プロキシ、プライベート エンドポイントを介して顧客リソースへ。 このパスにマイクロ VM はありません。

主な概念

トラフィックフローの方法

Foundry エージェント サービスのすべての要求は Foundry エンドポイントに入り、プライベート エンドポイントを介して顧客リソースに終了します。 エージェントの種類によって、その間の動作が決まります。

インバウンドから Foundry エンドポイント

クライアントは、Foundry エンドポイント (たとえば、 <your-resource>.services.ai.azure.com) に HTTPS 要求を送信します。 プラットフォームの API ゲートウェイは、要求を認証し、ターゲット エージェントの種類に基づいてルーティングします。

ホストエージェントのパス

ホストされるエージェントの場合、プラットフォームは、 /invoke プロトコル経由で委任されたサブネット内の Micro VM に要求を転送します。 Micro VM には、次の 2 つのネットワーク インターフェイスがあります。

Micro VM には独自の NIC がある場合でも、ツールの呼び出しはすべてデータ プロキシ経由でルーティングされます。

プロンプト エージェントのパス

プロンプト エージェントの場合、エージェントは Microsoft マネージド コンピューティングで実行されます。 Foundry エンドポイントは、シングルテナント データ プロキシを呼び出す Tools Service に直接要求を転送します。 IP はプロジェクト レベルで割り当てられるため、プロジェクト内のすべてのプロンプト エージェントが同じデータ プロキシ インフラストラクチャを共有します。

顧客リソースへの外部アクセス

データ プロキシからの送信トラフィックは、プライベート エンドポイント サブネット内のプライベート エンドポイントを介してストレージ アカウント、データベース、およびKey Vaultに到達します。 名前解決が VNet 内にとどまるように、対応するプライベート DNS ゾーン (privatelink.blob.core.windows.net、privatelink.database.windows.net、privatelink.vaultcore.azure.net など) を構成します。

サブネットのサイズ設定と IP 割り当て

サブネットの構成は Foundry アカウント レベルで適用されます。 アカウント内のすべてのプロジェクトは同じサブネット構成を共有し、ホストされるエージェントとプロンプト エージェントは同じ委任されたサブネットを共有します。 推奨されるサイズは、すべてのプロジェクト、プラットフォームのアップグレード、およびスケーリング イベントにわたるエージェントからの IP 使用量の組み合わせに対応する必要があります。

推奨されるサブネット サイズ

運用ワークロードには /24 CIDR 範囲を使用します。 /27 サブネットは小規模なデプロイで機能しますが、余裕はほとんど残しません。 プラットフォームのアップグレード、ロールアウト、スケーリング イベントはすべて一時的な追加 IP を必要とし、これらの操作中に小さなサブネットが使い果たされる可能性があります。

サポートされている IP 範囲

サブネットで RFC 1918 プライベート IPv4 範囲 のみを使用する必要があります。

• 10.0.0.0/8
• 172.16.0.0/12 ( 172.16.x.x から 172.31.x.xをカバー)
• 192.168.0.0/16

パブリック IP 範囲と CGNAT 範囲 ( 100.64.0.0/10 など) はサポートされていないため、ルーティングエラーが発生します。

IP の消費方法

IPs は、約 10 ポッドにつき 1 IP の割合で予約されます。 各 Foundry プロジェクトは、1 つのポッド (1 つのレプリカ) から始まる 1 つのデータ プロキシを取得し、トラフィックでスケールアウトします。

Project容量は動的です。1 projectあたりのトラフィック数が多いほど IP が消費されるためです。

サブネット サイズと同時セッション

サブスクリプションごとに使用できる同時エージェント セッションの数は、リージョンによって異なります。 既定では、同時実行セッションと使用可能なサブネット IP は、リージョンの制限に従って 1:1 にマップされます。

既定の 1:1 マッピングでは、 /26 以上のサブネット を使用して、50 の同時セッションをサポートします。

同じサブネットでより多くの同時セッションをサポートするには、Azure サポート要求を作成します。 要求で、サブスクリプション、リージョン、および予想される同時セッション数を指定します。 要件とリージョンの容量に基づいて、使用可能 な IP (1:10) ごとにマッピングを 10 の同時セッションに増やすことができます。

プロジェクト容量

Foundry インスタンスは、トラフィックが少ない場合に約 250 のプロジェクト をサポートします。 トラフィックが多い場合、エージェントが多数のレプリカにスケーリングされると、有効な制限は 最大 25 個のプロジェクトにまで低下する可能性があります。 IP が使い果たされると、新しいプロジェクトのプロビジョニングが失敗します。

プラットフォームのメンテナンス中の動作

プラットフォームのアップグレードは、古いインフラストラクチャと新しいインフラストラクチャを並行して実行し、IP 消費量を一時的に増加させます。 /24 サブネットは、通常のワークロードと共にこれらの一時的なスパイクを処理するのに十分なバッファーを提供します。 インフラストラクチャのアップグレードは、タイミングを含め、完全にMicrosoft管理されます。

ホストされるエージェントのネットワーク動作

ホストされるエージェントはAzure Container Appsで実行され、CPU とメモリの構成を制御できます。 独自のAzure Container Registryを使用してデプロイします。

リビジョンと IP の使用状況

更新プログラム (新しいイメージ、構成、またはコード) をデプロイすると、プラットフォームによって新しいリビジョンが作成されます。 ロールアウト中、トラフィックが新しいバージョンに移行すると、古いリビジョンと新しいリビジョンが並列に実行され、両方ともサブネットの IP が消費されます。

ホストされるエージェントごとのリビジョン制限:

• エージェントごとに 100 個のアクティブなリビジョン。
• エージェント名ごとに合計 1,000 個のリビジョン。 最も古い非アクティブなリビジョンは、アクティブな制限に達すると自動的に消去されます。
• Foundry インスタンスあたり約 200 個のホストエージェント 。

200 個のホステッド エージェントの制限は、すべてのエージェントの種類にわたってインスタンス全体に適用される最大 250 個のプロジェクト 上限とは別です。

発信接続

各ホストされるエージェントは、専用のネットワーク インターフェイスを使用して委任されたサブネットに接続されたマイクロ VM で実行され、送信通信に独自の IP を使用します。 ツール呼び出しは、常にシングルテナント データ プロキシ経由でルーティングされます。 ソース コード エージェントのデプロイの場合、プロビジョニング手順では特定のエンドポイントへの送信アクセスも必要です。 プライベート仮想ネットワークのファイアウォール要件を参照してください。

パフォーマンスとスケーリング

ホストされるエージェントをスケーリングしても、待機時間やパフォーマンスの低下は発生しません。 パフォーマンスが影響を受ける唯一のシナリオは、IP 枯渇によってプラットフォームのスケーリングが妨げる場合です。これは、適切なサブネットのサイズ設定で回避できます。 ホストされるエージェントは、カスタム CPU とメモリの構成をサポートします。 エージェント バージョンを作成するときに、使用可能な CPU とメモリのペアから選択します。

Promptエージェントのネットワーク動作

プロンプト エージェントもAzure Container Appsで実行されますが、コンピューティングとスケーリングはMicrosoftによって完全に管理されます。 CPU またはメモリは構成しません。

リビジョンと IP の使用状況

ホストされるエージェントとは異なり、プロンプト エージェントのリビジョンでは IP は使用されません。 データ プロキシは単一リビジョン モードで実行されるため、非アクティブなリビジョンは IP 可用性に影響しません。

発信接続

プロンプト エージェントは、すべての送信接続にシングルテナント データ プロキシを使用します。 IP は プロジェクト レベルで割り当てられるため、プロジェクト内のすべてのプロンプト エージェントが同じデータ プロキシ インフラストラクチャを共有します。

制限とパフォーマンス

Foundry インスタンスごとにデプロイできるプロンプト エージェントの数にハード制限はありません。 コンピューティングとスケーリングは完全に管理されているため、デプロイされたプロンプト エージェントの数に関連する予想される待機時間やパフォーマンスの問題はありません。

VNet ピアリングと IP の重複

IP 範囲が重複するとルーティング エラーが発生するため、ピアリングされたすべての VNet で 一意の重複しない IP 範囲を使用する必要があります。 この規則は、双方向ピアリング構成にも適用されます。 RFC 1918 プライベート IPv4 範囲のみがサポートされています。 CGNAT アドレス (たとえば、 100.x.x.x) ではありません。

IP の重複を回避できない場合は、独自の VNet を持ち込む代わりに マネージド仮想ネットワーク を使用します。 マネージド VNet は、ネットワークのセットアップを自動化し、IP 重複の問題を排除します。

IP 使用状況を監視し、枯渇を検出する

Azure ポータルでは現在、委任されたサブネットの IP 使用率は公開されていないため、直接監視することはできません。 IP 枯渇の主なインジケーターは、 データ プロキシからの HTTP 5xx エラー と、ホストされているエージェントの 場合、セッション作成エラー (4xx エラー) です。 IP が使い果たされると、データ プロキシのスケーリングと新しいプロジェクトのプロビジョニングが失敗し、ホストされているエージェントは新しいセッションにマイクロ VM を割り当てられません。 容量の問題の主要なインジケーターとして、データ プロキシの正常性とホステッド エージェントのセッション作成の成功を監視します。

次のような場合は、新しいサブネットを使用して新しい Foundry インスタンスをデプロイすることを検討してください。

• 5xx エラーを返すデータ プロキシ。
• ホストされたエージェント セッションの作成が 4xx エラーで失敗する。
• 新しいプロジェクトのプロビジョニングエラー。

クイック リファレンス

関連コンテンツ

• Foundry Agent Service のプライベート ネットワークを設定する
• Foundry Agent Service でホストされるエージェント
• マネージド仮想ネットワーク
• プライベート リンクを構成する