Overview
このページでは、パブリック プレビュー中にMongoDB Atlas Agent Engine に適用される制限を示します。各制限は、影響を受ける機能をカバーする ページにも表示されます。
重要
パブリック プレビューの制限
MongoDB Atlas Agent Engine はパブリック プレビュー段階です。 MongoDB、 プラットフォームで本番ワークロードを実行することは推奨されておらず、パブリック プレビュー中にプラットフォームの可用性のためのサービス レベル契約（SLA）またはサービス レベルのオブジェクト（SLO）を提供していません。
スケーリングと同時実行性
Atlas Agent Engine はエージェントの配置をオートスケールしません。 agent.yamlファイルの scaling.replicasフィールドは固定のサンドボックス数を設定し、各セッションはその有効期間中に 1 つのエージェントサンドボックスと 1 つのツール サンドボックスを予約します。その結果、このフィールドは配置が同時に処理できるセッション数を設定します。
scaling.replicasフィールドは1 から 512 までの値を受け入れ、省略した場合はデフォルトで 4 になります。すべてのサンドボックスが予約されると、新しい呼び出しリクエストはpool full エラーで失敗します。
512 の同時サンドボックス制限は、スコープがプロジェクトに限定され、複数のエージェントをサポートできるオーケストレーション エンジンに適用されます。プロジェクト内のすべてのエージェントの scaling.replicas 値は同じ上限にカウントされます。 1 つのプロジェクトで許可される複数のサンドボックスを実行するには、エージェントを複数のプロジェクトに分散します。
プールが枯渇するリクエストを呼び出すには、リクエスト全体でセッション ID を再利用します。セッションIDを共有するリクエストは 1 つの予約を再利用しますが、セッションIDを省略するリクエストでは新しいサンドボックスのペアが使用されます。セッションID は1 から 128 文字の長さで、文字、数字、アンダースコア（_）、ハイフン（-）を含めることができます。セッションID は、agentengine invoke コマンドの --session オプション、またはAPIリクエストの X-Session-ID ヘッダーで渡します。
呼び出しリクエストに セッションごとの分離が必要な場合は、 セッションID を再利用することはできません。より多くのセッションを同時に処理するには、scaling.replicas の値を増やすか、scaling.agent_idle_ttl_seconds と scaling.tool_idle_ttl_seconds の値を減らして、アイドル状態のセッションがサンドボックスをより早く解放してください。
Atlas Agent Engine はビルド時にscaling の値をスナップショットするため、変更を有効にするにはエージェントを再度ビルドして配置する必要があります。これらのフィールドの詳細については、「 エージェント契約リファレンス 」を参照してください。
オーケストレーション エンジンの容量
オーディエンス エンジンは、プロジェクト内のすべてのエージェントにわたる 1 秒あたり最大 50 の同時要求を処理できます。
ワークロードでより高い同時実行性が必要な場合は、 新しいプロジェクトを作成し 、そのプロジェクトに追加のエージェントを配置するか、 MongoDBサポート にお問い合わせください。
コンピューティング リソース
エージェントまたはオーケストレーション エンジンのコンピューティング リソースを設定することはできません。各エージェントには 0.5 vCPU と 2 GBのメモリがあり、各オーケストレーション エンジンには 0.5 vCPU と 512 MB のメモリがあります。これらの値は固定されており、ワークロードによって変化しません。
ワークロードに異なるリソース割り当てが必要な場合は、 MongoDBサポート にお問い合わせください。
エージェントの構築
プラットフォームでは、 各プロジェクトに対して次のビルド制限が適用されます。
Limit | 値 |
|---|---|
アクティブなビルドの同時実行 | 10 |
ローリング 24 時間にわたる毎日のビルド | 100 |
ビルド制限を超えると、リクエストはRESOURCE_LIMIT_EXCEEDED メッセージとともに 400 Bad Request エラーを返します。
エージェント のビルドと配置の詳細については、「 ビルドの配置 」を参照してください。
GitHub アプリの統合
Atlas Agent Engine GitHub アプリは、パブリック プレビュー期間は利用できません。 GitHub組織にアプリをインストールできないため、 Atlas Agent Engine UIで Connect Repository フローを使用したり、 GitHubリポジトリからワークスペースを作成したり、 GitHub アプリ Webhook イベントを受信したりすることはできません。
パブリック プレビュー中にワークスペースを作成して配置するには、代わりにリポジトリのローカル クローンから agentengine deploy コマンドを実行します。
ローカルクローンから配置する方法については、「 ビルドの配置 」を参照してください。
シークレット
プラットフォームは、シークレットに対して次の制限を強制します。
スコープ | Limit |
|---|---|
プロジェクトごと | 100 |
ワークスペースごと | 100 |
シークレット制限を超えると、リクエストはRESOURCE_LIMIT_EXCEEDED メッセージとともに 400 Bad Request エラーを返します。
シークレットの設定、読み取り、削除の方法については、「 クラウドシークレットのプロビジョニング 」を参照してください。
組織、プロジェクト、ワークスペースのリソース
各組織は最大 100 の組織サービス アカウントを持つことができます。この制限を超えると、リクエストは400 Bad Request エラーと RESOURCE_LIMIT_EXCEEDED メッセージを返します。
次の表は、各プロジェクトのリソース制限を示しています。
Resource | Limit |
|---|---|
ワークスペース | 25 |
API キー | 100 |
認証情報プロバイダ | 100 |
プロジェクト サービス アカウント | 100 |
リソース制限を超えると、リクエストはRESOURCE_LIMIT_EXCEEDED メッセージとともに 400 Bad Request エラーを返します。
これらのリソースを管理する方法については、「 組織の表示 」および「 組織、プロジェクト、ワークスペースの管理 」を参照してください。
パブリックAPI安定性
注意
パブリック プレビュー中のAPI安定性
Atlas Agent のパブリックAPI は、パブリック プレビュー中に変更される可能性があります。エンドポイント、リクエスト形式、レスポンス形式は、下位互換性のある移行パスがないと変更される可能性があります。オートメーションが依存する agentengine CLI バージョンを固定し、アップグレードする前にリリースノートを確認します。
APIリクエストを認証する認証情報の詳細については、 「 APIキーとサービス アカウントの管理 」を参照してください。
サービス アカウント
サービス アカウントが 配置されたエージェントを呼び出す場合、Atlas Agent Engine はサービス アカウントの ID をランタイムメモリの ID として使用します。プラットフォームは、呼び出しリクエストまたは agentengine invoke --user-id フラグが提供するエンドユーザーの user_id 値を無視します。
この解決済み ID は、自動変換、記録、抽出、統合、app.memory 操作で使用されます。その結果、同じサービス アカウントを認証する呼び出しは 1 つのメモリ ユーザー スコープを共有します。
この制限は、サービス アカウントが呼び出す配置されたエージェントにのみ適用されます。スタンドアロンの、プロジェクトスコープのメモリ サービスは影響を受けません。このサービスは、呼び出し元からの明示的な user_id と session_id 値を引き続き受け入れます。
エンドユーザーごとにメモリを分離するには、アプリケーションからスタンドアロンのメモリサービスを呼び出し、各呼び出しに明示的なuser_id とsession_id 値を渡します。詳しくは、「 スタンドアロン メモリ サービスの使用 」を参照してください。
サービス アカウントを使用してアプリケーションを認証する方法については、「 サービス アカウントによる認証 」を参照してください。
セキュリティ
シークレット アクセス
エージェントはプロジェクト内のすべてのシークレットにアクセスできます。新しいシークレットは、デフォルトでは ワークスペース レベルではなくプロジェクトレベルで追加されます。既存のプロジェクトに配置したエージェントは、他のエージェントが使用する MONGODB_URI を含む、プロジェクト内のすべてのシークレットにアクセスできます。
シークレットを 1 つのワークスペースに制限するには、agentengine secret set コマンドを呼び出すときに --workspace-scope フラグを追加します。
データベース アクセス
agentengine atlas setup コマンドを使用して Atlas 接続を作成すると、接続によって宛先クラスターの readWriteAnyDatabase アクセスが許可されます。
より狭い範囲のデータベースアクセスが必要な場合は、Atlas でデータベースユーザーを手動で作成します。次に、MDB_AGENTIC_STORE_DB データベースと MONGOMEM_DB_NAME データベースにスコープが設定された認証情報を持つ MONGODB_URI ワークスペース シークレットを設定します。
エージェントの分離
プロジェクトに配置されたすべてのエージェントは、同じオーケストレーション エンジン、またはエージェントコントロール プレーンを共有します。オーディエンス エンジンは、呼び出し元のエージェントに対して認証や認可を強制しません。
より強力なエージェント分離が必要な場合は、エージェントを独立したプロジェクトに配置します。
ツールの分離
デフォルトでエージェントサンドボックスで実行されるツール。代わりに、ツール サンドボックスでツールを実行するには、 agent.yamlファイルの sandboxes.tool.toolsフィールドにそのツールをリストします。ツール名 または ツール名に一致するグローバル パターンを一覧表示できます。委任された認証情報をリクエストツールは、 ツール サンドボックスでのみ実行できます。
エージェントサンドボックスと ツール サンドボックスは、相互にワークロードを分離します。例、 ツール サンドボックス内の ツールは、エージェントサンドボックス内のエージェントの制御フローとは別に実行されます。ただし、同じサンドボックスで実行されるツールは相互に分離されません。
同じサンドボックス内のツールは、そのサンドボックスに構成したすべてのシークレットと Egress の宛先にアクセスできます。 Atlas Agent Engine は、シークレットやネットワーク アクセスを個々のツールにスコープ設定しません。エージェントサンドボックスで実行されるツールは、エージェントサンドボックスのシークレットと Egress 宛先をエージェントコードと共有します。エージェントがツール間の分離を必要とする場合は、どちらのサンドボックスもツールごとのセキュリティ境界として扱わないでください。
エージェントがツール サンドボックスを使用する場合、セッションがアクティブな間は、各セッションで 1 つのツール サンドボックスが予約されます。 Atlas Agent Engine がそのサンドボックスで実行されるツール サンドボックスにルーティングするセッション内のすべてのツール呼び出し。 Atlas Agent Engine は、ツール呼び出しごとに新しいツール サンドボックスを作成しません。セッションが scaling.tool_idle_ttl_seconds 値を超えてアイドル状態になると、Atlas Agent Engine はそのツール サンドボックスをリリースします。セッションが再度アクティブになると、新しいツールのサンドボックスが使用されます。
サンドボックス シークレットと Egress 宛先を構成するには、「 エージェント YAML スキーマ 」と「 ネットワーク Egress ポリシーの管理 」を参照してください。