Lakebase PostgresでAIエージェントの長時間タスクを制御

Databricksは、Lakebase PostgresをAIエージェントのタスクキュー、状態管理、監視へ使い、外部基盤を減らす参照構成を公開しました。

要点

• 二つのLakebaseテーブルを、並行実行、再開、障害復旧に耐える長時間タスクのキューとして使います。
• Databricksアプリ、Lakeflow Jobs、MLflow、Unity Catalog Volumesを文書解析パイプラインへ接続します。
• PostgresのLISTEN/NOTIFYとSSEで、タスク状態と費用を低遅延の運用画面へ反映します。

今回のブログ記事で語られていること

長時間動くAIエージェントでは、要求を受け付けるWebアプリ、順番待ち、実行ワーカー、再試行、結果保存、監視が必要です。一般的にはKafkaなどのブローカー、Redis、専用スケジューラーを組み合わせますが、部品が増えるほど認証、障害対応、整合性確認も増えます。記事はLakebase Postgresをオーケストレーターの唯一の状態源にし、タスクの受付から完了までを表の更新として管理する構成を示します。

参照例は、Databricksアプリが要求を受け、オーケストレーターがLakebaseからタスクを取得してLakeflow JobsのAIエージェント層へ渡し、結果と状態を同じ基盤へ戻します。文書などの成果物はUnity Catalog Volumes、追跡と評価はMLflowへ接続します。Postgresの行ロックと状態遷移を使って重複実行を避け、ワーカー停止後も未完了タスクを回収できる設計です。Lakebaseは計算と保存を分けて需要に応じて伸縮し、短命なOAuthトークンとDatabricksの権限体系を共有します。

監視では、表を頻繁に読み続ける代わりにLISTEN/NOTIFYのトリガーで変更を通知し、SSEを通じて運用画面へ届けます。タスク数、進行状態、費用を同じ状態から表示できます。ただしPostgresをキューに使えば設計が不要になるわけではありません。取得中ワーカーの失効時間、再試行回数、処理の冪等性、優先順位、巨大な滞留、通知欠落からの再同期を決める必要があります。負荷試験では通常処理だけでなく、ワーカー強制終了と同時取得を再現し、タスクが失われず二重反映されないか確認すべきです。

今回のブログ記事が関係する人

Databricks上で文書処理やAIエージェントを運用し、キューと状態管理の外部基盤を減らしたい開発・基盤チームに関係します。

結局、今回のブログ記事をどう読むべきか

Postgresのトランザクションを長時間エージェントの制御面へ使う実装パターンです。構成は簡素になりますが、障害時の再取得と冪等性を負荷条件で証明する必要があります。