DatabricksはAIエージェントのオーケストレーションを簡素化するが、リスクはPostgresが担う

Databricksは、複数の専門サービスを単一のLakebase Postgresデータベースに置き換える本番設計によって、AIエージェントのオーケストレーションを簡素化している。7月22日の発表では、CLAと構築した監査アプリケーションが、文書処理を数時間ではなく数分で完了させるとしている。この改善は同社による報告結果だが、より重要なのはアーキテクチャの転換だ。

このシステムでは、タスクキュー、リトライ、スケジューリング、コスト配賦、ライブのステータス更新にPostgresを使用する。Databricksによれば、CLAはKafkaやRedisなどの外部ブローカー、AirflowやTemporalなどの個別スケジューラ、専用キャッシュを必要としなくなった。

この統合には明確な緊張関係がある。専門のオーケストレーションシステムは責務を分離し、複雑な障害を吸収する。Databricksはそれらの責務の多くを馴染みのあるデータベースに集約し、インフラを減らす一方で、データベース設計をエージェントの信頼性における中心課題にしている。

Databricksは長時間実行エージェント周辺のスタックを簡素化する

直接的な変化は、新しいモデルやエージェントフレームワークではない。Lakebaseをエージェント作業の管制センターとして扱う、本番運用パターンである。

Databricksとプロフェッショナルサービス企業のCLAは、エージェント支援型監査向けにこのシステムを構築した。監査では通常、スタッフが契約書、請求書、財務報告書、補足文書を確認してから、構造化情報を抽出する必要がある。

このアプリケーションは、Databricks Apps上で稼働するFastAPIインターフェースを通じてPDFアップロードを受け付ける。ファイルはUnity Catalog Volumesに保存され、各抽出リクエストはLakebaseに書き込まれる。

LakebaseはDatabricksのマネージドPostgresサービスだ。Postgres documentationでは、自動スケーリング、データベースブランチ、読み取りレプリカ、即時復元、Unity Catalog統合について説明している。

2つのリレーショナルテーブルが運用の中核を成す。tasksテーブルは、ステータス、優先度、リース情報、エージェント割り当て、最終出力を含む各論理ジョブを記録する。task_attemptsテーブルは、ジョブ識別子、トレース識別子、コストメタデータを含む個別の実行を記録する。

Lakeflow Jobsが文書処理を実行する。各ジョブは保存されたPDFを読み込み、文書処理コンポーネントとモデルを呼び出してから、その結果をLakebaseへ書き戻す。MLflowはモデル呼び出し、トークン使用量、レイテンシー、コスト情報を収集する。

したがってこのアーキテクチャは、別のインフラレイヤーを導入せずに責務を分離する。Lakeflowが処理を実行し、Lakebaseが何を実行すべきか、何が実行中か、何が完了したかを記録する。

Databricksによれば、この設計により品質を落とさず、CLAの抽出プロセスを数時間から数分へ短縮したという。同社はこの主張を裏付ける独立ベンチマーク、ワークロード分布、測定済みエラー率を公表していない。

それでも、この発表は大まかな参照図にとどまらない。Databricksは、この設計を運用するために必要な並行性、リカバリー、スロットリング、コールバック、可観測性、課金のパターンを示している。

この詳細は重要だ。なぜなら、データベーステーブルが自動的に安全なタスクキューになるわけではないからだ。基本的なクエリで保留中の作業を選択できるが、ワーカーがステータスを更新する前に、複数のワーカーが同じ行を選択する可能性がある。

設計は、プロセスがクラッシュした後の作業も回復しなければならない。重複したコールバックが重複した結果を生まないようにし、モデルへのリクエストを外部クォータ内に抑え、緊急文書が一括処理を追い越せるようにする必要がある。

orchestration designは、トランザクションと確立されたPostgres機能によってこれらの問題に対処している。Postgresがエージェントの状態を保存できること自体はニュースではない。開発者は何年も前からそれを行ってきた。

より強い主張は、Kafka、Redis、Temporal、Airflow、あるいは別のスケジューラなしでも、マネージドPostgresが本番エージェントワークロードのオーケストレーション基盤になり得るというものだ。

本当の圧力は専門インフラにかかる

Databricksは、あらゆる本番エージェントアプリケーションに個別のブローカー、スケジューラ、キャッシュ、可観測性スタックが必要だという前提に圧力をかけている。

エージェントのデモは、多くの場合、単一プロセス内で1件のリクエストを開始から終了まで実行する。本番システムは異なる。ユーザーが同時に作業を投入し、モデル呼び出しが失敗し、個々のタスクの所要時間が予測不能だからだ。

Databricksは、このばらつきを2種類の文書で示している。2ページの請求書は数秒で完了する場合がある一方、200ページの契約書には数分を要することがある。ワーカーは、タスクが投入順に完了すると想定できない。

モデルのクォータも別の制約を加える。エンドポイントは、秒間リクエスト数、分間トークン数、またはその両方を制限する可能性がある。数百件の文書を同時にディスパッチすると、スロットリングと繰り返しのリトライを引き起こしかねない。

アプリケーションは運用上の問いにも答える必要がある。チームは、どのタスクが失敗したか、どのモデル呼び出しがトークンを消費したか、各試行のコストはいくらか、放棄されたジョブを再実行すべきかを把握する必要がある。

従来のアーキテクチャでは、こうした関心事を別々の製品に割り当てることが多い。メッセージブローカーがタスクを運び、ワークフローエンジンが耐久性のある実行を管理し、キャッシュが高速な状態アクセスを提供し、監視プラットフォームがステータス、レイテンシー、コストを集約する。

この分離は、複雑なワークフローや大規模組織を支え得る。一方で、追加の認証情報、デプロイプロセス、ダッシュボード、障害モード、統合コードも増える。

Databricksは、互いに独立した長時間実行タスクにとって、このオーバーヘッドは不釣り合いだと主張する。通常、ある契約書の結果が別の契約書の結果に依存しないため、文書抽出はこの説明に当てはまる。

Lakebaseは、トランザクション状態をDatabricksアプリケーションの他の要素のそばに置くことで、この計算を変える。同じプラットフォームが、インターフェース、ファイル、ジョブ、モデルのトレース、ガバナンス制御、課金記録を提供する。

このアプローチは2つのグループに圧力をかける。プラットフォームチームは追加する各サービスの必要性を正当化しなければならず、オーケストレーションベンダーは、専門的な保証が適切に設計されたデータベースキューをなぜ上回るのかを示す必要がある。

これは専用システムを時代遅れにするものではない。たとえばAmazonは、AgentCore Runtimeを、セッション分離、スケーリング、ID管理、長時間実行エージェントのサポートを備えるマネージド環境として位置付けている。

このアプローチでは、チームにエージェント専用ランタイムの採用を求める。対してDatabricksは、運用データベースから始め、すでにデータおよび機械学習ワークロードに利用されているサービスへ接続する。

したがって争点はインフラの境界にある。エージェントの実行は専門ランタイムの内部に置くべきか、それともデータベースが耐久性のあるリレーショナル状態を通じて通常のジョブを調整すべきか。

既存顧客の間では、Databricksに構造的な優位性がある。すでにLakeflow、MLflow、Unity Catalog、Databricks Appsを使用しているチームは、別のベンダーやセキュリティモデルを導入せずに統合できる。

同じ優位性はプラットフォーム依存も生む。この完全なパターンを選ぶ企業は、タスク実行、ストレージ、可観測性、ガバナンス、コストレポートをDatabricksのサービスに結び付けることになる。

購入者にとって、「よりシンプル」とは製品名が少ないことだけを意味してはならない。運用タスクの削減、障害責任の明確化、許容可能なリカバリー動作、そして維持可能な移行戦略を意味する必要がある。

4つのPostgresパターンがキューの信頼性を支える

このアーキテクチャが機能するのは、馴染みのあるデータベースプリミティブを、並行性、リカバリー、スロットリング、リトライに関する明示的な保証へ変換しているからだ。

第1のパターンは、並行処理に安全なデキューだ。ワーカーはFOR UPDATE SKIP LOCKEDを使用して対象行を選択し、選択した行をロックする一方で、他のワーカーがそれらをスキップできるようにする。

PostgreSQLは、複数のコンシューマーがキューのようなテーブルへアクセスする際、競合回避にSKIP LOCKEDが有用だと説明している。同時に、このオプションは一貫性のないビューを示すため、汎用クエリには適さないとも警告している。

この区別は設計の強みを捉えている。タスクテーブルは、デキュー中の任意のレポーティングには使われていない。ワーカーには、別のワーカーのロックを待つことなく、利用可能なジョブを排他的に取得する必要がある。

クエリは、優先度の降順、続いて作成時刻で作業を並べる。優先度の高いジョブが先に実行され、同一優先度内では先入れ先出しの順序が維持される。

第2のパターンでは、期限付きリースを使用する。ワーカーがタスクを取得する際、所有権を永久に割り当てるのではなく、リースの有効期限を記録する。

定期的なスイーパーが期限切れタスクをキューに戻す。退避、デプロイ、メモリエラー、プロセスクラッシュによってワーカーが消えた場合でも、別のワーカーが数分以内にそのジョブを回復できる。

リースは放棄された作業を解決するが、同時に要件も導入する。アプリケーションは、通常のタスク所要時間を超える有効期限を選ぶか、処理の継続中にリースを更新しなければならない。

リースの期限が早すぎると、健全な作業が放棄されたように見える可能性がある。長すぎるリースは、実際の障害後の回復時間を延ばす。

第3のパターンは、ディスパッチ前にモデル消費量を制御する。オーケストレーターは、同時タスク数の上限、予測トークン予算、またはその両方をサポートする。

同時実行数の上限は、現在処理中としてマークされている行を数える。データベースがその数を保持するため、この制限はワーカーの再起動や複数のオーケストレーター・レプリカにまたがっても可視のままだ。

トークン予算は、進行中の各タスクの消費量を見積もる。オーケストレーターは、予測トークン数が設定済みの上限内に収まる場合にのみ、次のジョブをディスパッチする。

両方の制御を有効にすると、より厳しい制約が優先される。これにより、多数の小規模な請求書と少数のトークン消費量の多い契約書を行き来するワークロードに対応できる。

第4のパターンは、コールバックを冪等にする。冪等性とは、同じリクエストを繰り返しても変更が二重に適用されるのではなく、同じ実効結果が得られることを意味する。

ネットワーク中断やプロキシにより、コールバックが複数回到着する可能性がある。Databricksは、処理中または再エンキュー済みのジョブに対するコールバックを受け入れる一方、すでに完了している状態は何もしない処理として扱う。

この動作は、重複処理や重複課金のリスクを下げる。ただし、安定したタスクID、慎重な状態遷移、結果更新を含むトランザクション境界に依存する。

これら4つのパターンを組み合わせることで、信頼できるキューが構成される。トランザクションが同時取得を防ぎ、リースが放棄された作業を回復し、予算がディスパッチを制限し、冪等なコールバックが再配信を許容する。

これが、Databricksが一対のテーブルだけで十分だと主張することなく、エージェントタスクキューを簡素化する方法だ。各遷移を統制するポリシーは、依然としてアプリケーションコードが実装する。

この仕組みは、依存関係が比較的単純なジョブに適している。ネストされたワークフロー、補償アクション、人による承認、または長い時間指定イベントの連鎖が必要になると、魅力は薄れる。

専用ワークフローエンジンは、こうした関係を直接表現することが多い。データベースキューでは、開発者がそれらをテーブル、状態遷移、アプリケーションロジックとしてモデル化しなければならない。

このトレードオフは導入判断を左右すべきだ。チームがこのパターンを選ぶべきなのは、自らのワークフローが十分に単純だからであり、Postgresが理論上あらゆるワークフローを表現できるからではない。

1つのデータベースが状態、可視性、コストを結び付ける

この設計で最も特徴的なのはキューイングではない。同じタスク記録から運用上の可視性とコスト配賦を導き出すという判断だ。

オペレーターに必要なのは、完了または失敗というラベルだけではない。CLAダッシュボードは、キュー投入済み、処理中、完了、失敗、キャンセル済みのタスク数を表示する。

また、入力・出力トークン、モデルコスト、コンピューティングコスト、応答時間の中央値、文書ごとの信頼度も可視化する。フィルターでは、期間、タスク状態、個別エージェントを指定できる。

このワークロードでは、レイテンシの中央値が有用な指標となる。リトライ時のバックオフやキューの飽和は極端な遅延を生み、単純平均を歪める可能性があるためだ。

PostgresのLISTEN/NOTIFYが、ライブ更新の仕組みを担う。タスク状態が変わるとデータベーストリガーがイベントを発行し、アプリケーションバックエンドは1本のリスニング接続を維持する。

バックエンドはそのイベントをServer-Sent Events経由でブラウザへ配信する。SSEは一方向のHTTPストリームで、サーバーが持続するブラウザ接続を通じて更新を送信できる。

Databricksによると、ダッシュボードの変更は通常およそ1秒以内に表示される。この設計では、この経路のためにRedis、WebSocketサーバー、メッセージバスを必要としない。

システムは永続的なフォールバックとしてポーリングも維持する。ストリーミングが利用できなくなった場合、ブラウザは10秒ごとに最新データを要求する。

このフォールバックは重要だ。クラウドのイングレスプロキシは、ブラウザに明確なエラーを出さずにストリームを中断することがある。プッシュイベントだけに依存するダッシュボードは、気付かないうちに古くなる可能性がある。

このダッシュボードは、更新速度の異なる情報を組み合わせている。Databricksによれば、Postgresの状態は即時に反映される一方、MLflowのトレースデータは1秒未満で到着する。

請求クエリには数十秒かかる場合がある。そのためアプリケーションは通常の更新では高速な状態クエリを実行し、低速な請求クエリはユーザー操作時に限定する。

コスト帰属には、もう一段階のフィルタリングが必要となる。Databricksの請求テーブルにはアカウント全体のアクティビティが含まれるため、生のクエリでは無関係なジョブやアプリケーションの支出まで集計されてしまう。

オーケストレーターは、各タスクに割り当てた特定のDatabricks Job実行を記録する。請求クエリはその後、アカウント全体のアクティビティをこれらの識別子に絞り込む。

これにより、1つのSQLウェアハウスで複数のアプリケーションを支えながら、各ダッシュボードには自身のワークロードだけを表示できる。オペレーターは、状態、エージェント、日付によってさらに結果を絞り込める。

この設計は、汎用的なモニタリングでは見えにくくなりがちな実務的な問いを支える。チームは7日間にわたる失敗タスクのコストを確認したり、エージェント間の支出中央値を比較したりできる。

タスクIDとコストの結び付きは、監査にとどまらず重要である。AIアプリケーションでは、ユーザーリクエスト、それによって発生した試行、最終的なモデル請求書の関係が失われがちだ。

永続的なタスクレコードは、チームに安定した結合キーを提供する。ビジネス上の意図、実行履歴、モデルのトレース、コンピューティング活動、最終出力を結び付ける。

知識集約型のチームは、実行後にも関連する問題に直面する。自動化された作業を取り巻く文書、意思決定、出力を、検索可能な文脈で保持する必要がある。

構造化されたエンジニアリング・ナレッジベースは、インシデントや設計判断の背後にある人間的な文脈を保持することで、ランタイムトレースを補完できる。

したがってLakebaseパターンの価値は、サービス数の削減にとどまらない。提出からリトライ、コスト、結果に至るまで、各タスクに一貫した運用上のストーリーを与える。

よりシンプルなインフラはリスクをデータベース設計へ移す

Databricksは統合のオーバーヘッドを減らすが、分散システムの複雑さを取り除くわけではない。その複雑さを、スキーマ、トランザクション、リース、アプリケーションコードへ移し替える。

「外部インフラ不要」という表現は慎重に読むべきだ。このアプリケーションは、Apps、Lakeflow Jobs、MLflow、Unity Catalog Volumes、Lakebaseを含む複数のDatabricksサービスに依存している。

簡素化は単一のマネージドプラットフォーム内で実現される。アーキテクチャを単一プロセスや単一サービスにまで縮小するものではない。

この違いは障害時に重要になる。Lakebaseのキューはジョブサービスが利用できない間も永続性を保てるかもしれないが、アプリケーションには遅延したディスパッチと復旧に対するテスト済みの挙動がなお必要だ。

また、コールバックが成功した一方で周辺の操作が失敗した場合に何が起きるかも定めなければならない。冪等性が繰り返し配信を守れるのは、すべての副作用で一貫した識別子と境界を用いる場合に限られる。

レート制限の制御にも不確実性がある。予測トークン予算は、モデルが処理する前に文書の消費量を見積もることに依存する。

見積もりは複雑な文書を過少評価したり、単純な文書を過大評価したりする可能性がある。過少評価はプロバイダーのスロットリングを引き起こし、過大評価は利用可能なモデル容量を未使用のまま残しかねない。

公開された設計には、スループット結果、キュー深度の上限、障害率、データベース負荷、比較運用データは示されていない。また、専用ワークフローエンジンとの直接比較も行われていない。

Databricksは、抽出時間が数時間から数分に短縮されたと報告している。しかし、文書サンプル、人手レビューのプロセス、精度指標、モデル構成、ベースラインのワークフローは開示していない。

読者はこの結果を、統制されたベンチマークではなく、本番環境の顧客事例として扱うべきだ。普遍的な性能向上を証明しなくても、このアーキテクチャは有用であり得る。

Postgres自体が競合点になる可能性もある。頻繁なデキュー、ステータス更新、トークン予算計算、ダッシュボード読み取り、請求結合は、いずれも関連する運用レコードから発生する。

Lakebaseは自動スケーリングするコンピュートと独立した永続ストレージを提供する。これらの機能はキャパシティ計画を軽減し得るが、自動スケーリングによって非効率なクエリやロック競合が解消されるわけではない。

キューテーブルは通常のアプリケーションテーブルとは異なる成長をする。試行履歴は蓄積し、完了済みレコードは監査にとって価値を持ち、インデックスはライブスケジューリングと履歴分析の双方を支える必要がある。

したがって、保持・アーカイブポリシーもキュー設計の一部となる。これらがなければ、運用クエリは徐々にレポーティングのワークロードと競合し得る。

セキュリティにも同等の注意が必要だ。タスクテーブルには、文書の場所、抽出結果、信頼度スコア、エージェント割り当て、実行識別子が含まれる場合がある。

Databricksによると、Unity Catalogは共通のID管理と権限を提供する。それでもチームは最小権限アクセスを徹底し、Webhookエンドポイントを保護し、どのオペレーターが機密性の高い結果を確認できるかを決めなければならない。

データベースブランチは、隔離環境での不具合再現に役立つ場合がある。一方で、機密性の高い運用データも複製され得るため、監査ワークロードに適したマスキングとアクセス制御が必要になる。

より広い競争上の問いは、なお未解決だ。GoogleのAlloyDB AIも、ベクトル検索やハイブリッド検索を含むAIアプリケーションの基盤として、PostgreSQL互換インフラを位置付けている。

AWSは、マネージドランタイム、メモリ、ID、オーケストレーションサービスを用いて、よりエージェント特化型のアプローチを取っている。専用ワークフローシステムは、複雑なプロセスグラフにまたがる耐久性の高い実行に引き続き焦点を当てている。

Databricksは、Postgresが意味のある中間領域をカバーできることを示した。しかし、データベース中心のオーケストレーションが、あらゆるエージェントワークロードでそれらのシステムを置き換えるべきだとは示していない。

最も強い導入ケースは、既存のDatabricksプラットフォーム上で動作する、独立した長時間実行タスクである。最も弱いケースは、複雑な依存関係と厳格なポータビリティ要件を持つクロスシステムワークフローだ。

3つのシグナルがLakebaseオーケストレーションの妥当性を試す

次の試金石は、CLAアーキテクチャが、慎重に設計された顧客実装ではなく、再現可能な本番パターンになるかどうかだ。

最初のシグナルは、文書抽出以外への導入である。Databricksは、コーディングエージェント、顧客業務、データ修復、リサーチワークフローに関する事例を公開すべきだ。

これらのワークロードでは、タスクサイズ、依存構造、ツール権限、人間による承認要件が異なる。類似した結果が得られれば、Lakebaseが汎用的なエージェント状態ストアであるという主張は強まる。

今後の事例が独立した文書ジョブに限られるとしても、この設計はなお有用だ。その実用的な適用範囲が、より広範なオーケストレーションという表現が示唆するものより狭くなるだけである。

2つ目のシグナルは、比較可能な運用データだ。チームには、持続的な負荷下でのキュースループット、復旧時間、データベース使用率、障害率、ディスパッチレイテンシが必要である。

Redisをバックエンドにしたワーカーや耐久性の高いワークフローエンジンとの比較は、特に有用だろう。統合作業の削減が、アプリケーション内部の追加的な状態機械ロジックをいつ上回るのかを示せるからだ。

透明性のあるデータは、Databricksの簡素化に関する主張を強める。このようなデータがなければ、購入者はアーキテクチャの説明と顧客報告の成果に依存することになる。

3つ目のシグナルは、製品化だ。現在のパターンは、ロック、リース、スロットリング、コールバック、ダッシュボードストリーミング、請求帰属を実装するアプリケーションコードに依存している。

Databricksはこの設計の一部を、テンプレート、マネージドコンポーネント、リファレンスライブラリ、あるいは組み込みのLakebase機能に変えられる。それにより、各顧客が保守する正確性が重要なコードの量を減らせる。

製品化はまた、Databricksがデータベース機能とワークフロー機能の境界をどう定義するかも明らかにする。より大きなマネージドレイヤーは、エージェントランタイムやオーケストレーションプラットフォームとより直接的に競合することになる。

このパターンを評価するチームは、自らのワークフローの形から始めるべきだ。明確な終端状態を持つ独立タスクは、CLA設計とよく適合する。

次に、スループットを最適化する前に障害時の挙動をテストすべきだ。ワーカーを停止し、コールバックを遅延させ、リクエストを重複させ、モデルのクォータを使い切り、ダッシュボードのストリームを中断する。

最後に、運用負荷を1つの専門的な代替案と比較する。削減できるサービス数を数えるだけでなく、追加されるカスタム遷移、復旧ルール、テスト、ランブックも数える。

Databricksはエージェントオーケストレーション周辺の目に見えるインフラを簡素化し、Lakebaseはこの設計に信頼できるトランザクションの中核を与える。未解決の問いは、あなたのアプリケーションが、その統合がなおシンプルであり続けられるほど単純かどうかだ。

そうであれば、データベース中心のキューは、プロトタイプから観測可能な本番システムまでの道のりを短縮できる。そうでなければ、欠けているブローカーやワークフローエンジンはアプリケーションコードとして再び現れる。次の適切な一歩は、実際のタスクサイズ、実際のクォータ、実際の復旧目標を用いた、障害重視のパイロットである。