トリガー・ドット・デブ、AIワークフローの監視基盤をClickHouseへ移行

非同期タスク実行基盤のトリガー・ドット・デブは、長時間動くAIワークフローのログ、トレース、実行情報を分析する基盤をPostgresからClickHouseへ移行しました。運用データベースと分析負荷を分離し、数万行を返すクエリでP95約200ミリ秒という結果や、保存容量の大幅な削減を公表しています。

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

トリガー・ドット・デブは、サーバーレスの非同期タスクを配置し、実行、再試行、待ち行列を管理するサービスです。AIエージェントや動画処理のように、一つの要求が多数の外部システムや子タスクへ広がり、長時間継続する用途が増えました。その結果、各実行から生じるログ、トレース、イベントが、数千のテナントをまたぐ大規模な分析対象になりました。

当初はPostgresの一つのテーブルへ監視データを保存し、パーティション分割などで対応していました。しかしデータ量の増加に伴い、索引追加や集計が難しくなり、分析クエリが顧客タスクを動かす運用系へ影響する危険も高まりました。テナントごとに属性が異なる動的な監視データへ新しい分析機能を足すには、別の集計処理も必要でした。トリガー・ドット・デブは、運用処理と分析処理を分離し、オープンソース版とクラウド版の双方で使える基盤としてClickHouseを選びました。

移行は一括切り替えではなく、タスクの一回の実行を表す「run」単位で保存先をPostgresかClickHouseへ振り分ける方式で進めました。新しい実行を段階的にClickHouseへ移し、既存分をPostgresに残すことで、本番の正しさと性能を確かめながら停止時間なしで移行したとしています。ClickHouseのJSON型が動的な監視データに適する段階まで待ったことも説明されています。

移行後は、以前は運用影響を懸念して難しかった利用状況の分析を日常的に行えるようになりました。マテリアライズドビューを使ったログ量の集計機能は約1時間で実装できたとされ、数万行を取得するクエリのP95は約200ミリ秒と報告されています。保存容量も大幅に減ったとしていますが、具体的な削減率や比較条件は示されていません。これらはトリガー・ドット・デブの構成とデータにおける事例であり、一般的な性能保証ではありません。

この事例の重要点は、単にデータベースを置き換えたことではなく、顧客タスクを実行する運用系から重い監視分析を分離したことです。AIワークフローが長時間化し、子タスクや外部呼び出しが増えるほど、障害時に何が起きたかを追えるデータと、そのデータを安全に検索できる分析基盤が必要になります。

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

AIエージェントや非同期ジョブの実行基盤を運用するチーム、Postgresに大量のログやトレースを保存している開発者、複数テナントの監視データを分析するSaaS事業者に関係します。運用データベースの安定性と監視画面の自由度が競合している組織にも参考になります。

利用前に確認したいこと

• 運用データと監視・分析データの責任範囲をどこで分けるか
• 二重書きや段階移行中の欠損、重複、順序ずれをどう検知するか
• テナント分離、保存期間、個人情報の削除要件を満たせるか
• JSON属性の検索パターンに合う表設計と並び順になっているか
• P95だけでなく高負荷時の遅延、取り込み失敗、運用費を比較できるか

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

トリガー・ドット・デブの事例は、AIワークフローの監視データが運用系Postgresの規模と設計を超えたときに、ClickHouseへ分析負荷を分けた移行例です。約200ミリ秒という数値だけを一般化せず、run単位の段階移行、運用系との分離、動的なJSONデータへの対応を含めて読むのが適切です。同様の課題がある組織は、自社の保持期間、テナント数、検索条件で小さく比較するとよいでしょう。