はじめに：従来の監査は面倒なプロセスであり、詳細な文書レビューと情報抽出が求められていました。このプロセスを加速するため、CLA（CliftonLarsonAllen LLP）はDatabricks社と協力し、エージェンティックな監査ソリューションを構築しました。このソリューションは完全にDatabricks上に構築されており、Lakebase Postgres、Databricks Apps、Lakeflow Jobs、MLflow、Unity Catalog Volumesを活用し、文書抽出時間を数時間から数分に短縮します。本記事では、その中核コンポーネントの1つであるオーケストレーションレイヤーに焦点を当てます。
オーケストレーションの課題：文書解析を大規模に実行する際、5つの分散システム問題が発生します。タスクレイテンシの予測不可能性、レート制限対応、ワークロードの優先順位付け、タスクごとのコスト帰属、リアルタイムの進行状況可視化です。従来は複数の専用システムを組み合わせる方法がとられていましたが、それぞれに運用負荷が伴います。DatabricksのソリューションはLakebaseを核とし、単一プラットフォームですべての要件を満たします。
ソリューションアーキテクチャ：アプリケーションスタックはDatabricksサービスのみで構成されます。Webアプリケーション（Databricks Apps）は文書のアップロードと解析リクエストを処理し、Lakebaseはオーケストレーターのリレーショナル状態をホストするPostgresデータベースです。オーケストレーター自体もDatabricks Apps上で動作し、ワーカーデーモンとオペレーターダッシュボードを提供します。AIエージェント（Lakeflow Jobs）が実際の文書解析を実行します。外部メッセージブローカーやスケジューラーは不要です。
タスクキューの実装：タスクキューはLakebase内の2つのPostgresテーブル（tasksとtask_attempts）により支えられています。4つのPostgresネイティブパターンにより、堅牢なキューへと変換されます。
- 同時実行優先度対応デキュー：FOR UPDATE SKIP LOCKEDを使用して同時実行安全性を確保し、ORDER BY priority DESC, created_atで優先度順に処理します。
- リースベースのクラッシュリカバリ：デキュー時に有効期限付きリースを記録し、定期的なスイーパーが期限切れタスクを再エンキューすることで、クラッシュ後もタスクが自動的に復旧されます。
- レート制限対応スロットリング：同時実行上限、トークンバジェット、またはその組み合わせの3つのモードをサポートし、デキュー時に動的にチェックしてモデルエンドポイントの制限を超過しないようにします。
- べき等Webhookコールバック：コールバックハンドラーはべき等に設計されており、重複処理のリスクを排除します。
リアルタイムオペレーターダッシュボード：PostgresのLISTEN/NOTIFYとサーバー送信イベント（SSE）を活用し、タスクの状態、入出力トークン数、LLMコスト、計算コスト、応答時間の中央値などのメトリクスをリアルタイムで表示するダッシュボードを構築します。
結論：Lakebase Postgresにより、Databricksは長時間実行されるエージェントワークロード向けの、よりシンプルでスケーラブルなオーケストレーションパターンを提供します。このアーキテクチャはCLAの本番環境で実証され、その実用性が確認されました。