Foundry ワーカーと Agent ワーカーの比較

背景

Agent ワーカーは、Foundry で Data Connection ソースを実行するための当初の方法でした。顧客のネットワーク内にある、顧客が管理する Agent ホスト上で機能を実行していました。現在は、すべてのソースに Foundry ワーカーを推奨しています。機能は、コンテナ化されたスケーラブルな Foundry のジョブ実行環境で実行されます。現在、Agent は Agent プロキシエグレスポリシーを介したネットワークプロキシとしてのみ動作し、機能を実行しなくなりました。

接続の種類ごとの構成についてはアーキテクチャ図を、定義についてはコアコンセプトを参照してください。

Foundry ワーカーのメリット

スケーラビリティと分離

Foundry ワーカーは、ジョブに合わせたサイズの専用コンテナで各機能を実行します。ジョブが Agent の共有 JVM ヒープを奪い合うことはなくなり、実行時間の長い同期が、短時間のジョブの並列実行を妨げることもなくなります。コンピューティングリソースは、単一の Agent ホストの容量に制約されるのではなく、ジョブごとに独立してスケーリングします。

安定性とリリース頻度

Foundry ワーカーは、Foundry が管理するコンピューティング環境で実行され、プラットフォームのほかの部分とともに継続的に更新されます。Agent ワーカーは顧客が管理するホストで実行され、通常は週に1回の Agent のメンテナンスウィンドウ中にしかアップグレードできません。そのため、バグ修正や改善が Agent に届くまでに時間がかかります。また、Agent ワーカーはホストレベルの問題（リソースの枯渇、OS や JVM の問題、計画停止）の影響も受けます。一般的な障害の種類については、Agent のトラブルシューティングを参照してください。Foundry ワーカーは、顧客が管理するランタイムを実行経路から外すことで、これらを回避します。

すべての機能と新しい開発へのアクセス

仮想テーブル、仮想メディア、外部トランスフォーム、外部関数、Compute Module からのコード内でのソースの使用、および近年追加されたいくつかの機能は、Agent ワーカーでは実行できません。新しい機能と継続的な機能開発は、Foundry ワーカーのみを対象としています。

運用負担の軽減

Foundry ワーカーを使用すると、Agent の JVM ヒープの調整、Agent ホストの容量計画、OS レベルでの Agent プロセスの監視が不要になります。Agent を引き続き使用する場合も、Agent プロキシを介したネットワークプロキシとしてのみ動作するため、Agent 上でコンピューティングを実行する場合に比べて、運用負担が大幅に小さくなります。

資格情報ライフサイクルの簡素化

Foundry は、ソースの資格情報を特定の Agent に紐付けるのではなく、一元的に管理します。ソースに割り当てる Agent を変更しても、シークレットを再入力する必要はなくなります。Agent ホストを再プロビジョニングしても、資格情報は無効になりません。

よくある質問

Foundry ワーカーは Agent ワーカーと同じくらい安全ですか？

はい。どちらのモデルでも、Foundry はソースの資格情報を保存時および転送時に暗号化します。唯一の実質的な違いは、ソースの資格情報の暗号化キーがどこにあるかです。Agent ワーカーでは Agent ホストのディスク上にあり、Foundry ワーカーでは Foundry 内で安全に管理されます。Agent プロキシを使用する場合、ソースシステムへのネットワーク接続は引き続きアウトバウンドのみで、ネットワーク内の Agent から開始されます。これは Agent ワーカーモデルと同じです。

Foundry ワーカーは Agent ワーカーと同等の性能を発揮しますか？

はい。コンテナ化されたジョブは、単一の Agent のヒープを奪い合うことがなく、ジョブごとにスケーリングできます。

ネットワーク接続モデルは変わりますか？

いいえ。Agent プロキシを使用する場合、Agent は引き続き Foundry へのアウトバウンド WebSocket 接続を開始し、ソースシステムへのすべてのトラフィックは引き続きネットワーク内の Agent から発信されます。ネットワークへの新しいインバウンド経路は追加されず、Agent ワーカーと同じモデルです。変わるのは、機能が実行される場所であり、Foundry がシステムにアクセスする方法ではありません。

既存の Agent ワーカーソースはどうなりますか？

既存の Agent ワーカーソースは引き続き動作します。Agent ワーカーはレガシーですが、完全にサポートされています。準備ができたら、ガイド付きウィザードを使用して移行します。移行後30日間は元に戻せます。

Agent プロキシはどう位置付けられますか？

Agent プロキシは Agent ワーカーと同じではありません。 Agent プロキシは、Foundry ワーカーのネットワークモードであり、ワーカーの種類ではありません。新しいソースについての議論で「Agent」が出てきた場合、ほとんどの場合は Agent プロキシを指しています。アーキテクチャ図については、アーキテクチャを参照してください。

ソースを Agent ワーカーから Foundry ワーカーに切り替える

Agent ベースのソースのほとんどは、Foundry ワーカーに移行する必要があります。Foundry からアクセスできるシステムには直接接続を、別のネットワークでホストされているソースには Agent プロキシ接続を使用します。

前提条件

移行を開始する前に、次の条件を満たしていることを確認してください。

• ソースのシークレット、証明書、および該当する場合は JDBC ドライバーを提供できる正常な Agent が、ソースに1つ以上割り当てられていること。
• エグレスポリシーの作成に必要な権限があること。新しいエグレスポリシーを作成するには、Control Panel の「ネットワークエグレス設定を管理」ワークフローへのアクセス権が必要です。このアクセス権は、情報セキュリティ責任者ロールに付与されています。

移行手順

Foundry ワーカーへの移行を実行するには、次の手順に沿って進めます。

1. 接続設定 > 接続情報に移動し、コンピュート：Agent ワーカーを選択します。ダイアログが開き、Foundry ワーカーに移行を選択できます。

2. 移行の概要を確認します。ウォークスルーダイアログには、実行する手順と、このプロセスを元に戻せることが示されます。続行を選択して進みます。

3. 代表となる Agent を選択します。現在ソースに割り当てられている正常な Agent を選択します。選択した Agent は、シークレットと証明書を Foundry にコピーするために使用されるほか、Agent の現在の設定に基づいて必要なエグレス設定を提案するために使用されます。選択した Agent のシークレットが Foundry に保存されることを了承する必要があります。

4. 証明書をソースにコピーします。Foundry ワーカーでは、証明書を Agent ではなくソースに直接適用する必要があります。代表となる Agent から、データソースに転送する証明書を選択します。Agent に証明書が見つからない場合は、このステップをスキップできます。

5. （任意）ソースの種類で必要とされる場合は、JDBC ドライバーを設定します。代表となる Agent から、Foundry ワーカーで使用するドライバーを選択します。

6. エグレスポリシーを追加します。直接接続または Agent プロキシのエグレスポリシーを設定して、Foundry ワーカーがソースシステムにアクセスする方法を定義します。

7. 確認ステップの内容を確認します。移行を完了する前に、次の点を了承します。

   • 実行中のすべてのジョブ（同期、エクスポート、タスク）は、移行の一環として終了されます。スケジュールされたジョブは、次回のスケジュール実行時に Foundry で実行されますが、スケジュールされていないジョブは手動で再起動する必要があります。
   • 必要に応じて、30日以内であれば以前の設定に戻すことができます。

   移行を選択してプロセスを完了します。

手動で切り替える

ガイド付きの移行ウィザードを使用しない場合は、移行ダイアログで Foundry ワーカーに手動で切り替えるを選択できます。手動で切り替える場合は、Agent からのシークレットの自動転送が行われないため、資格情報を再入力する必要があります。

Agent ワーカーに戻す

移行後30日間は、ソースを以前の Agent ワーカー設定に戻すことができます。

1. 移行したソースの接続設定 > 接続情報に移動します。
2. コンピュートドロップダウンで、Agent ワーカー > 元に戻すを選択します。
3. ソースを Agent ワーカーに戻すダイアログで、次の点を了承します。
   • 資格情報を含むすべての接続設定が、移行前の状態に戻ります。移行後に行った変更は失われます。
   • スケジュールされていないジョブ（同期、エクスポート、タスク）は、手動で再起動する必要があります。スケジュールされたジョブは、次回のスケジュール実行時に移行前の接続設定を使用します。移行後に正常に開始したジョブは、完了するまで移行後の設定で実行を続けます。
4. 移行を元に戻すを選択して確定します。

移行前の設定を復元するのではなく、Agent ワーカーでソースを手動で再設定する場合は、ダイアログで Agent ワーカー経由で接続するように手動で切り替えるを選択します。

トラブルシューティング

このセクションでは、移行中に発生する可能性のある状況と、推奨される解決手順について説明します。なお、移行は30日間であれば元に戻すことができます。

Could not resolve type id as a subtype of 'com.palantir.magritte.api.Source'

推奨される解決方法：

• この問題は、ソースに必要な依存関係が見つからない場合に発生します。そのソースに必要な証明書、プロキシ、およびドライバーがすべて設定されていることを確認してから、移行を再試行します。

UnknownHostException

推奨される解決方法：

• 正しいエグレスポリシーがソースに割り当てられていることを確認します。
• 例外が発生しているエンドポイントに Foundry がアクセスできることを確認します。

Driver class not found

推奨される解決方法：

• 正しいドライバーが JDBC ソースにアップロードされていることを確認します。

PKIX path building failed

推奨される解決方法：

• 正しい証明書がソースに追加されていることを確認します。