Trigger.devがClickHouseを活用して長時間実行AIワークフローのオブザーバビリティをスケールさせる方法

ユーザーが動画をアップロードし、数分後には文字起こしが完成することを期待する。AIエージェントが応答する前に、数十のシステムから文脈を収集する。ワークフローが数百のサブタスクに分岐し、リクエストがブラウザを離れたあとも長時間にわたってドキュメントを読み込み、APIを呼び出し、データを変換し続ける。

AIワークフローに牽引される世界において、かつては単純なバックグラウンドジョブに見えていたものが、現代のアプリケーションの中核的な挙動を支える複雑で長時間実行されるプロセスへと変貌を遂げている。

ここで登場するのが Trigger.dev だ。共同創業者兼CTOのEric Allamはこう表現する。「私たちはサーバーレスな非同期タスクのデプロイに関するワンストップショップです。開発者がコードを書いて私たちのインフラにデプロイすれば、私たちがそれをオーケストレーションし、実行し、リトライし、キューイングし、確実に動作させます」。

Trigger.devは2022年にロンドンでオープンソースプロジェクトとして創業し、当初は開発者がバックグラウンド自動化をより簡単に実行できるようにすることに注力していた。しかし、AIワークフローとエージェントが本番環境で使われるようになるにつれて、プラットフォームの役割は拡大していった。顧客はTrigger.devを単なる自動化用途にとどまらず、アプリケーション内の中核レイヤーとして、長時間実行される計算処理、大規模なデータ処理、複雑な実行チェーンの調整に利用するようになった。

採用が広がるにつれて、それらのワークフローが生成するテレメトリの量も増加していった。すべてのタスク実行が数千のテナントにまたがってログ、トレース、イベントを生成し、可観測性そのものがプラットフォーム最大の技術的課題の一つとなっていった。

私たちはEricに話を聞き、AIワークフローの台頭とともにTrigger.devがどう進化してきたか、なぜチームがデータベースアーキテクチャを見直すに至ったか、そしてなぜClickHouseを選んだのかを聞いた。

Postgresの限界 #

Trigger.devの初期構成は、多くのオープンソースプロジェクトにおなじみのアプローチをとっていた。「とりあえずPostgresを使って、どこまでいけるか見てみよう」というものだ。

初期はうまく機能した。ユーザーはシンプルなPostgresインスタンスでTrigger.devを立ち上げ、すぐにタスク実行を開始でき、プラットフォームは裏側でログとテレメトリを収集していた。しかし採用が広がるにつれて、そのデータの量と性質が変化し始めた。

「大きめの顧客、特にクラウドの顧客の場合、Postgres実装ではスケールしきれなくなってきました」とEricは言う。

すべてのタスク実行がログ、トレース、イベントを生成し、それらは単一のテーブルに流れ込んでいた。Ericの表現を借りれば「延々と大きくなり続ける」テーブルだ。チームはパーティショニングやその他の最適化を導入して管理可能な状態を維持しようとしたが、次々と限界にぶつかった。インデックスの追加は現実的でなくなり、クエリは遅くなり、行数のカウントや利用パターンの把握といった基本的な問いにさえ、確実に答えるのが難しくなっていた。

同時に、このデータベースは運用コストが高くなり、変更にもリスクを伴うようになっていた。重たい分析ワークロードは、顧客のタスク実行を担うシステムの運用安定性を脅かしかねず、信頼性と可視性の間に緊張関係が生まれていた。

もう一つの課題はアクセスパターンだった。Ericの説明によれば、Trigger.devは「極めて動的な」可観測性データを数千のテナントにわたって分析する必要があり、テナントごとに異なる種類のイベントや属性を生成している。Postgresで新しい分析機能をサポートするには、個別のパイプラインと集計システムを構築する必要があり、すでに逼迫していたアーキテクチャにさらなる複雑さを加えることになっていただろう。

テレメトリの量が増加し続ける中、Postgresは運用系ワークロードには適していても、大規模な可観測性分析の基盤としては適していないことが明確になってきた。

なぜClickHouseを選んだのか #

チームは新たなデータベースの検討を開始し、パフォーマンス、スケーラビリティ、オープンソースとの互換性、そしてデプロイモデル間の柔軟性を優先事項に据えた。Ericの言葉を借りれば「私たちが選ぶものは何であれ、セルフホストユーザーとクラウド顧客の両方で機能する必要がありました」。

最初はPostgresエコシステム内にとどまることを検討した。台頭してきたOLAP拡張機能や、DuckDB、ParadeDBといったPostgres隣接の選択肢は、慣れ親しんだツールを手放すことなく分析機能を提供することを約束していた。しかしチームは、分析処理が運用データベースと密結合したままになることを懸念した。「運用系でないもので運用系データベースをダウンさせる可能性があるものは、リスクが高いです」とEricは語る。分析用に別のPostgresインスタンスを運用するのは、根本的な問題を解決せずに複雑さだけを増やすことになる。

同じ頃、Baseline、Highlight、Langfuseといったデベロッパーツーリングカンパニーのピアたちから、大規模な可観測性ワークロードをClickHouseで扱っているという話を聞くようになった。それらの会話は、より広範なオープンソースエコシステムで彼らが目にしていたこと、つまり可観測性に特化したプロジェクトがClickHouseを本番環境で成功裏に運用している例が増えているという事実を裏付けた。実際のスキーマやアクセスパターンを研究できたことで、Ericとチームはこのデータベースが自分たちのワークロードにマッチしているという確信を得た。

最終的にClickHouseは、Trigger.devが必要とするすべてを備えていた。実証済みの大規模パフォーマンス、慣れ親しんだSQLインターフェース、可観測性ワークロードを取り巻く急成長中のエコシステム、そして彼らのセルフホスト型・クラウド型デプロイに沿ったオープンソースモデルだ。「ClickHouseで行くと決めました」とEricは言う。

シームレスな移行 #

ClickHouseへの移行を決めた後も、チームはすぐに移行を実行しなかった。Ericによれば、彼らはデータベースの進化を見守り、Trigger.devのワークロードが生成する非常に動的なテレメトリをよりよくサポートする ClickHouseネイティブJSONデータ型 のような改善を待っていた。「もうすぐ実現しそうだと感じていました」と彼は語る。

データベースが自分たちのニーズに合致すると確信できた時点で、チームは中断を回避するよう設計された段階的アプローチで、可観測性ワークロードの移行を開始した。

Trigger.devプラットフォームの基本単位—タスクの1回の実行—は「run」と呼ばれる。移行期間中、ログはそのレベルでルーティングされ、各runのデータをPostgresとClickHouseのどちらにも書き込めるようにした。これにより、プラットフォームを完全に稼働させたまま、実際の本番環境でパフォーマンスと正確性を検証することができた。

新しいワークロードはますますClickHouseへ流れ込み、移行が進むにつれてPostgresに書き込むレガシーrunの割合は減っていった。プラットフォームは全期間を通じて完全に稼働し続け、ダウンタイムも顧客側の対応も必要なかった。「ユーザーにとってはシームレスでした」とEricは言う。「何もする必要はなく、すべて裏側で行われました」。

大規模なリアルタイム分析 #

可観測性ワークロードがClickHouse上で稼働するようになったことで、Trigger.devはプラットフォームの利用状況をはるかに明確に把握できるようになった。Postgresでは実行不可能だったり、リスクが高すぎて実行できなかったクエリが日常的なものとなり、チームは実世界での利用状況を直接把握できるようになった。

Ericの説明によれば、チームは運用系システムへの影響を心配することなく、テレメトリを探索し、利用パターンを分析し、社内インサイトを構築できるようになった。「以前は行数さえ把握できませんでした」と彼は語る。ClickHouseを使うことで、ログがプラットフォームをどのように流れているかをリアルタイムに理解できるようになった。

その可視性はプロダクトの改善にもつながっている。ClickHouseの マテリアライズドビュー を活用して、Trigger.devは顧客に対して、生成されたログ数やアクティビティの経時変化を示す集計利用メトリクスを導入した。「これは非常にシンプルで、ClickHouseでは1時間程度で実装できました」とEricは言う。「Postgresでやろうとしたら大変な苦労でした」。

チームはまた、ストレージフットプリントの大幅な削減も目にしている。「ClickHouseでのデータセットのサイズを以前と比較すると、大きな違いがあります」とEricは語る。

パフォーマンスも、データ量が増え続ける中で強力さを維持している。ClickHouseでは、数万行を取得するクエリのP95レイテンシは約200ミリ秒だ。「これには非常に満足しています」とEricは言う。

制約のない構築 #

長い目で見れば、可観測性をClickHouseに移行したことは、ボトルネックの解消であると同時に、プロダクトに組み込める機能に対する制約を取り除くことでもあった。

Postgresでは、実用的な制約がダッシュボード体験を規定していた。大量のテレメトリは制限しなければならず、複雑なワークフロー全体にわたってログを探索することが常に可能というわけではなかった。ClickHouseによって、そうした制約は消え始めている。Ericの説明によれば、目指すのは開発者が人為的な上限なしにrunを自由に探索できる地点だ。「私たちがやりたいことは、それがなければ実現できません」と彼は語る。「一度に閲覧できるログ数に基本的に制限がないダッシュボード体験を目指して取り組んでいます」。

これはTrigger.devのより広範なビジョンとも一致している。同社の最近のロードマップ に示されているように、拡張されたロギングとログストリーミングから高度なメトリクスや新しいエージェントツールに至るまで、今後の改善は本番環境のAIワークフローの構築、デバッグ、スケーリングをより容易にすることを目指している。可観測性は単なる支援インフラではなく、開発者体験の一部となっていく。

Ericの言葉を借りれば、ClickHouseは「高速でスケーラブルで馴染みやすい」というバランスを実現しており、ユーザーにデータの扱い方の再考を強いることなく、チームがプラットフォームを進化させることを可能にしている。

AIワークフローがより長時間実行され、より複雑になっていく中で、そうした基盤はかつてないほど重要になっている。アプリケーションが自律エージェントや分散実行に依存すればするほど、開発者はそれらのシステムが実際に何をしているのかを把握する必要性が高まる。ClickHouseが可観測性を支えることで、Trigger.devはワークフローが可視性やコントロールを犠牲にすることなく、複雑性とスケールを増していける未来を築いている。

制限なく可観測性をスケールしたいとお考えですか?ClickHouse Cloudを30日間無料でお試しください。