アーキテクチャ

Solo Enterprise for agentregistry を構成するコンポーネントと、それぞれの役割を確認します。

Solo Enterprise for agentregistry を構成するコンポーネントと、それぞれの役割について説明します。

Solo Enterprise for agentregistry は、一度インストールして複数のランタイムに接続する単一のコントロールプレーンです。これらのランタイム全体に共通のカタログとコントロールプレーン体験を提供します。一方で、デプロイ、検出、ランタイムポリシー適用、テレメトリの経路はランタイムごとに異なります。レジストリが各プラットフォームとどのように統合されるかについて詳しくは、ランタイムアーキテクチャを参照してください。

コンポーネントアーキテクチャ

次の図は、Solo Enterprise for agentregistry を構成するコンポーネントと、それらの関係を示しています。

Component architecture of Solo Enterprise for agentregistry: clients connect to the registry server, which sits in the control plane with PostgreSQL, ClickHouse, and the OTel Collector; the server validates JWTs with an external identity provider and connects to the runtimes.

クライアント

レジストリは 3 つのインターフェイスから操作できます。いずれもデフォルトではレジストリサーバーによってポート 12121 で提供されます。これらが送信するすべてのリクエストには JWT が含まれ、レジストリは他の処理を行う前にその JWT を検証します。

Registry UI: 視覚的な操作を好むユーザー向けのブラウザーベースのダッシュボードです。カタログの参照と検索、エージェントと MCP サーバーのデプロイ、承認の確認、トレースの調査に使用します。
arctl CLI: 開発者と自動化向けのコマンドラインクライアントです。アーティファクトのスキャフォールド、ビルド、公開、取得、デプロイや、CI/CD パイプラインでのアーティファクトライフサイクルのスクリプト化に使用します。
REST API: UI や CLI と同じ機能を公開する HTTP エンドポイントです。レジストリを独自のツールやポータルに統合するために使用します。

レジストリサーバー

レジストリサーバー (agentregistry-enterprise-server) はコントロールプレーンの中核です。アーティファクトカタログ、アーティファクト承認ワークフロー、デプロイ、ランタイム接続、接続済みランタイム全体の検出を管理します。レジストリとチャットインターフェイスに対するユーザーリクエストでは AccessPolicy リソースを評価します。デプロイ済みエージェントのトラフィックでは、ゲートウェイコンポーネントが該当する AccessPolicy 設定に基づいてランタイム認可を適用します。また、サーバーは Registry UI と、arctl やその他の統合で使用される REST API も提供します。

レジストリサーバーは、永続的なコントロールプレーン状態に PostgreSQL を使用し、トレースデータのクエリに ClickHouse を使用します。また、接続済みランタイムと連携してエージェントと MCP サーバーをデプロイし、既存のエージェントを検出し、管理された MCP アクセスを設定します。

サーバーへのアクセスは OIDC で保護されます。Registry UI、arctl、REST API の 3 つのインターフェイスはすべて、ID プロバイダーで認証し、得られた JWT を各リクエストで送信します。サーバーはプロバイダーの OIDC discovery メタデータと JWKS 公開鍵を使用して、トークン署名と audience を検証します。トークンが検証されてから初めて、サーバーは呼び出し元のアクセスポリシーを評価します。詳しくは、OIDC ID プロバイダーとアクセス制御についてを参照してください。

PostgreSQL

PostgreSQL はコントロールプレーンの信頼できる記録システムです。公開済み AI アーティファクトとバージョン、デプロイ、ランタイム接続、関連メタデータを保存します。デフォルトでは、Helm チャートは開発と評価用に、単一 Pod のバンドル版 PostgreSQL インスタンスをデプロイします。本番環境では、レジストリを外部 PostgreSQL データベースに接続します。詳細については、BYO PostgreSQL databaseを参照してください。

ClickHouse

ClickHouse は、AI ワークロードが生成する大量のトレースデータに適したカラムナデータベースです。デプロイ済みエージェントと MCP サーバーから収集された分散トレースと span を保存します。レジストリサーバーは ClickHouse にクエリを実行して、UI の Tracing ビューをレンダリングします。このビューには、エージェントステップ、LLM 呼び出し、MCP ツール呼び出しにまたがるリクエスト単位の実行フローが含まれます。Helm チャートでは、デフォルトでバンドル版 ClickHouse デプロイが有効になります。PostgreSQL はレジストリ状態の信頼できる記録システムのままであり、ClickHouse はテレメトリの保存とクエリに特化します。

OpenTelemetry Collector

組み込みの OpenTelemetry (OTel) Collector は、ランタイムトレースの取り込みポイントです。デプロイ済みエージェントと MCP サーバーは、Runtime リソースの telemetryEndpoint フィールドに設定されたエンドポイントへ OTLP トレースをエクスポートします。レジストリがエージェントまたは MCP サーバーをデプロイすると、このエンドポイントをワークロード設定に注入します。Collector はポート 4317 の gRPC またはポート 4318 の HTTP で OTLP を受信し、トレースデータを ClickHouse に書き込みます。

テレメトリエンドポイントは、デプロイ済みワークロードから到達可能である必要があります。レジストリクラスター外のランタイムでは、外部から到達可能なエンドポイントが必要です。Runtime から外部の OTel 互換バックエンドを直接指すことも、組み込み Collector から Jaeger や Grafana Tempo などのバックエンドへトレースを転送するように設定することもできます。詳細については、Tracingを参照してください。

図に示す Collector は、ランタイムトレースのパイプラインです。コントロールプレーン監査イベントは、別の任意の OTLP エクスポートパイプラインを使用し、外部監査バックエンドへ直接送信するか、専用のリレー Collector 経由で送信できます。詳細については、Audit logsを参照してください。

OIDC ID プロバイダー

レジストリには ID プロバイダー (IdP) はバンドルされていません。Keycloak、Okta、Auth0 など、OIDC 準拠のプロバイダーを用意します。OIDC 設定では 4 つのクライアントを使用します。

ar-backend : レジストリサーバーが使用する confidential client です。アクセストークンの aud claim には、このクライアントを含める必要があります。
ar-cli-interactive : arctl が対話型デバイス認可に使用する public client です。
ar-cli-password : arctl が CI/CD パイプラインでのスクリプト化された認証に使用する public client です。
ar-ui : Registry UI が PKCE 付き authorization code flow に使用する public client です。

サーバーはすべてのリクエストで、プロバイダーの JWKS 公開鍵に対して JWT を検証します。トークンがない、期限切れである、署名が無効である、または audience が間違っている場合、ポリシーを評価する前にそのトークンを拒否します。検証済みトークン内の role または group claim は AccessPolicy リソースと照合され、呼び出し元が実行できる操作を決定します。必要なクライアント、claim マッピング、認可レイヤーについては、アクセス制御についてを参照してください。

ランタイム

ランタイムとは、エージェントと MCP サーバーのデプロイ、既存エージェントの検出、またはゲートウェイ経由での MCP サーバー公開のために、コントロールプレーンが接続するプラットフォームです。1 つのレジストリは、同時に複数のランタイムに接続できます。統合モデルはプラットフォームごとに異なります。詳しくは、ランタイムアーキテクチャを参照してください。

デプロイメントランタイムは、カタログ内のデプロイ可能なアーティファクトを実体化します。エージェントは、モデル設定と関連する MCP サーバー、スキル、プロンプトを組み合わせたデプロイ可能ユニットです。MCP サーバーは単独でデプロイすることもできます。プロンプトとスキルはバージョン管理されたカタログアーティファクトのままであり、スタンドアロンのランタイムサービスとしてはデプロイされません。

Solo Enterprise for kagent

Solo Enterprise for kagent は Kubernetes 上の deployment runtime です。レジストリはエージェントと MCP サーバーを Kubernetes ワークロードとしてデプロイし、管理します。Solo Enterprise for Istio と Solo Enterprise for agentgateway がインストールされている場合、ランタイム AccessPolicy ルールはゲートウェイ設定に変換され、MCP ツール呼び出しと agent-to-agent リクエストに対して agentgateway waypoint で適用されます。

AWS Bedrock AgentCore

AWS Bedrock AgentCore は AWS 上の deployment runtime です。レジストリはエージェントと MCP サーバーを、VPC 内の Bedrock AgentCore runtime としてデプロイします。マネージド agentgateway インスタンスが管理対象の MCP トラフィックをルーティングし、ランタイム認可を適用します。

Azure AI Foundry と Microsoft Copilot Studio

Azure AI Foundry と Microsoft Copilot Studio は discovery-only runtimes です。レジストリは、Foundry プロジェクトと Power Platform 環境で既に実行されているエージェントを読み取り、Instances ビューに表示します。レジストリは discovery-only runtime 経由でアーティファクトをデプロイできません。

agentgateway (仮想ランタイム)

仮想ランタイムは、Solo Enterprise for agentgateway を使用して、リモート MCP サーバーを単一の管理対象エンドポイント経由で公開します。他のランタイムとは異なり、ここではレジストリはサーバーのライフサイクルを管理しません。レジストリはサーバーへのネットワークアクセスを管理し、MCP トラフィックをプロキシします。

次のステップ

ランタイムアーキテクチャコントロールプレーンコンポーネントが各ランタイムでどのように現れ、統合されるかを確認します。主要なコンセプトカタログ、アーティファクトタイプ、ランタイム、ガバナンスモデルを理解します。アクセス制御について認証、ユーザー認可、ランタイム認可がどのように連携するかを確認します。トレースエージェント、LLM 呼び出し、MCP ツールにまたがってリクエストをエンドツーエンドで追跡します。

主要な概念ランタイムアーキテクチャ